[all2]

I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.

[yencabulator]

I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.

But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.

Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".