I think it’s impressive that an LLM can take you to a local maxima in one-shot.

But once you start maintaining it, improving it and fixing bugs, you’ll eventually need to rip it apart and put it back together again while understanding how it all works.

This is why I think the better approach isn’t to one-shot but to have the architecture in your head and build it up piece by piece, with the AI accelerating the code writing.

▲

dools 10 hours ago | parent | next [-]

I’ve found it very easy to maintain, add features to and fix bugs in software I’ve written entirely with LLMs, and in languages and frameworks with which I’m unfamiliar. You just ask the LLM to explain the code and then work with it to come up with the fix.

▲

ai_fry_ur_brain 9 hours ago | parent [-]

How big are those projects.. I dont think this is good for your mental health or physicaly your brains health. Problem solving keeps your brain strong. The laziness in us is inclined to take shortcuts, don't do it. Its like driving your car 3 blocks instead of walking, your physical health will suffer.

▲

dools 9 hours ago | parent | next [-]

> How big are those projects

Define big I guess. They're non-trivial, mix of internal enterprise tools, a multiplatform app (android/ios/mac/windows/web currently headbutting its way through review), including a billing system for my small telecommunications business.

> I dont think this is good for your mental health or physicaly your brains health

I find the experience of doing it without writing the code to be intellectually pretty similar. I still solve a lot of problems, the LLM couldn't, for example, one shot the event sourcing model I built for synching data between devices. It took quite a few iterations and I had to define a lot of the architecture, but I did it at a level that wasn't "here is a class, here is a module, this module does XYZ", more at the "whitepaper" level or describing how specific bits of the app needed to work in order to solve some problem.

It's also very similar to managing other developers.

> Its like driving your car 3 blocks instead of walking, your physical health will suffer

It's more similar to having staff rather than doing everything yourself. The problem solving just shifts to a different area, and you get more done.

	▲	7 hours ago \| parent [-]
		[deleted]

▲

matwood 9 hours ago | parent | prev | next [-]

> Problem solving keeps your brain strong.

Coding is not the sole problem solving skill. In fact, coding may be one of the easier skills much of the time. Deciding what to build, where to focus efforts, understanding a customer's needs, could all be just as if not more challenging than the coding part.

	▲	dools 9 hours ago \| parent [-]
		Also what the code should do and how it should do it. LLMs regularly cannot come up with the best way to approach something. Once those decisions are made, codifying them is kind of the least interesting part of the entire exercise.

▲

boredhedgehog 8 hours ago | parent | prev | next [-]

> Its like driving your car 3 blocks instead of walking, your physical health will suffer.

And be sure to only walk barefoot. Relying on artificial shoes weakens the muscles and the skin of your feet.

	▲	mycocola 7 hours ago \| parent [-]
		A reasonable compromise in the face of frostbite and hookworm. I suppose critical thinking skills are also as bad, making you question the state of the world. Problem solving is another one, deluding one into believing there are solutions to suffering.

▲

yogthos 3 hours ago | parent | prev [-]

I've been working on a project that's over 150k loc of Rust at this point. https://dirge-code.github.io

You absolutely can have the LLM write maintainable code. A few tricks I use are to ask it to plan out features in phases, and then do a branch and a PR for each focused piece of work. It makes it a lot easier to review and understand what's happening.

I also ended up making a tool which lets the LLM get a high level perspective of the codebase, and then see parts that are structurally gnarly. I've been using it to do refactors and clean things up periodically. It helped a lot with keeping the architecture clean.

https://github.com/yogthos/wavescope-mcp

Adding features and evolving the codebase has not been a problem even at this scale.

▲

hurtigioll 10 hours ago | parent | prev | next [-]

LLMs are good now at looking at existing project and suggesting big refactors for technical debt removal and new better architectures after the project grew organically for a while

	▲	9 hours ago \| parent [-]
		[deleted]

▲

MrScruff 9 hours ago | parent | prev | next [-]

I think this is true for projects beyond a certain complexity. I have 100% vibe coded projects with tens of thousands LOC, and haven't seen any real issues with fully automated maintenance. Will that approach work in every scenario, absolutely not, but the size and complexity of projects where it does is growing with each new model release.

▲

danlugo92 3 hours ago | parent | prev | next [-]

> you’ll eventually need to rip it apart and put it back together again while understanding how it all works.

This is what spec .md files are for, skill issue

▲

rahulmax 6 hours ago | parent | prev [-]

Strongly agree, well said. The one-shot is sexy purely because that first demo is so impressive. Going from zero to working app in minutes.

Like you said, working and maintainable are very different things. One-shot hits a wall the moment you need to do anything non-trivial after the initial generation. Bug fixing is extremely hard, even with AI assistance. Same with feature additions. It's pretty much black box at this point on. AI that wrote it now goes in loops wasting tokens without being able to can't reliably fix it either, because it has no memory of the architectural decisions it made (or didn't make, for that matter) the first time round.

What I realized is that the failure here is the absence of a shared mental model between you and the code.

I'm a product designer with average front-end know-how, and a solid understanding on HTML/CSS and how the web works, coming from the era of hand-coding html/css files. After vibe-coding a few products early this year, purely to learn how AI works, how to design AI interaction patterns etc., I built something called Intent Model. (largely inspired by SDD / BDD.

Intent model is a structured, typed artifact (basically a JSON contract) that captures actors, entities, journeys, rules, and constraints before I write (or make the AI write) any code. It sits upstream of everything. Think of it like a condensed, strict distillation of your PRD / BRD / requiremnt doc.

When you hand the AI a well-defined intent file instead of a vague brief, this one-shot becomes structured and bound by rules. Now you're giving it an architecture and to conform to. You define (or make the AI define) the precise variable names, their types, lifecycle, user roles, responsibilities, business rules and constraints in the file. Every generated artifact can trace back to a decision you made deliberately, reviewd and signed-off.

In the design world, we already do this by using design tokens. We can tell the AI that it needs to strictly use design tokens and not use stray properties like a hex color value or raw values not defined in the token contract. This is easily auditable by AI as well.

The result is you can still move absurdly fast and still maintain the understanding, which the one-shot approach throws away. This way, you know why every piece exists because you defined the intent before the AI implementated it.

AI is the accelerant, and you're the architect. The intent is the blueprint you generate to guide/harness the AI.

The best part is, once you have an intent contract at the heart of your project, it becomes impossible to break things too, logically or experience-wise.