These are the perfect size projects vibe coding is currently good for.

At some point you hit a project size that is too large or has too many interdependencies, and you have to be very careful about how you manage the context and should expect the llm to start generating too much code or subtle bugs.

Once you hit that size, in my opinion, it's usually best to drop back to brainstorming mode, only use the llm to help you with the design, and either write the code yourself, or write the skeleton of the code yourself and have the llm fill it in.

With too much code, llms just don't seem able yet to only add a few more lines of code, make use of existing code, or be clever and replace a few lines of code with a few more lines of code. They nearly always will add a bunch of new abstractions.

I agree with you as far as project size for vibe-coding goes - as-in often not even looking at the generated code.

But I have no issues with using Claude Code to write code in larger projects, including adapting to existing patterns, it’s just not vibe coding - I architect the modules, and I know more or less exactly what I want the end result to be. I review all code in detail to make sure it’s precisely what I want. You just have to write good instructions and manage the context well (give it sample code to reference, have agent.md files for guidance, etc.)

Or you can apply software architecture methods that are designed to help humans with exactly the same type of problems.

Once your codebase exceeds a certain size, it becomes counter-productive to have code that is dependent on the implementation of other modules (tight coupling). In Claude Code terms this means your current architecture is forcing the model to read too many lines of code into its context which is degrading performance.

The solution is the same as it is for humans:

  "Program to an interface, not an implementation." --Design Patterns: Elements of Reusable Object-Oriented Software (1994)

Suddenly, you've freed up large chunks of context and Claude is now able to continue making progress.

Of course, the project could continue to grow and the relatively small interface declarations could become too many to fit in context. At that point it would be worthwhile taking a look at the application to see if larger chunks of it could be separated from the rest. Managing the number and breadth of changes that Claude is tasked with making would also help since it's unlikely that every job requires touching dozens of different parts of the application so project management skills can get you even further.

Engineering code now is not just binary, it's a spectrum from vibe-coding through copilot-style (design and coding assistance) to your help-with-design-only to no-AI.

The capabilities now are strong enough to mix and match almost fully in the co-pilot range on substantial projects and repos.

  These are the perfect size projects vibe coding is currently good for.

Reminds me of Ken Miles saying 7000 rpm quote. At what size do you think this happens? Whatever is the most relevant metric of size for this context.

I think this limitation goes away as long as your code is modular. If the Ai has to read the entire code base each time, sure but if everything is designed well then it only needs to deal with a limited set of code each time and it excels at that.

> make use of existing code, or be clever and replace a few lines of code with a few more lines of code

You can be explicit about these things.

[dead]