I was wrong about vibe coding on greenfield projects.
3 comments
it's not that simple.
llms can handle greenfield stuff fine; it's just more important at that stage of development for the operator of the LLM to specify constraints where possible. If the operator is unaware of what constraints should be considered then they have an LLM right in front of them that is familiar with the idea premise that can help create constraints with the operator either via investigation, suggestion, or interrogation.
If the goal is "Claude plz make me a SOTA db system." , well -- 'garbage in, garbage out.'
llms can handle greenfield stuff fine; it's just more important at that stage of development for the operator of the LLM to specify constraints where possible. If the operator is unaware of what constraints should be considered then they have an LLM right in front of them that is familiar with the idea premise that can help create constraints with the operator either via investigation, suggestion, or interrogation.
If the goal is "Claude plz make me a SOTA db system." , well -- 'garbage in, garbage out.'
I agree. But I believe I need to do more baby sitting on a greenfield project than an existing project.
"garbage in, garbage out" applies at every step.
If you don't care about the code and all you want to do is just to test your idea, then it is merely a throw-away PoC not a project. And yes, vibe coding is great for that.
However, as harnesses and models got better over the time, agents started working better on existing codebases. Often times, agents discover existing approaches/code style in the codebase and they start coding accordingly.
I realized that in a greenfield project it is important to set the data models and data flow and general structure of the codebase before handing it off to AI blindly. Otherwise it becomes an unmaintainable mess, and you never want to look at that code again.