Comment by Maxion
19 days ago
A lot of more senior coders when they actively try vibe coding a greenfield project find that it does actually work. But only for the first ~10kloc. After that the AI, no matter how well you try to prompt it, will start to destroy existing features accidentally, will add unnecessary convoluted logic to the code, will leave benhind dead code, add random traces "for backwards compatibility", will avoid doing the correct thing as "it is too big of a refactor", doesn't understand that the dev database is not the prod database and avoids migrations. And so forth.
I've got 10+ years of coding experience, I am an AI advocate, but not vibe coding. AI is a great tool to help with the boring bits, using it to initialize files, help figure out various approaches, as a first pass code reviewer, helping with configuring, those things all work well.
But full-on replacing coders? It's not there yet. Will require an order of magnitude more improvement.
> only for the first ~10kloc. After that the AI, no matter how well you try to prompt it, will start to destroy existing features accidentally
I am using them in projects with >100kloc, this is not my experience.
at the moment, I am babysitting for any kloc, but I am sure they will get better and better.
It's fine at adding features on a non-vibecoded 100kloc codebase that you somewhat understand. It's when you're vibecoding from scratch that things tend to spin out at a certain point.
I am sure there are ways to get around this sort of wall, but I do think it's currently a thing.
You just have another agent/session/context refactor as you go.
I built a skribbl.io clone to use at work. We like to play eod on Friday as a happy hour and when we would play skribbl.io we would try to get screencaps of the stupid images we were drawing but sometimes we would forget. So I said I'd use claude to build our own skribbl.io that would save the images.
I was definitely surprised that claude threaded the needle on the task pretty easily, pretty much single shot. Then I continued adding features until I had near parity. Then I added the replay feature. After all that I looked at the codebase... pretty much a single big file. It worked though, so we played it for the time being.
I wanted to fix some bugs and add more features, so I checked out a branch and had an agent refactor first. I'd have a couple context/sessions open and I'd one just review, the other refactored, and sometimes I'd throw a third context/session in there that would just write and run tests.
The LLM will build things poorly if you let it, but it's easy to prompt it another way and even if you fail that and back yourself into a corner, it's easy to get the agents to refactor.
It's just like writing tests, the llms are great at writing shitty useless tests, but you can be specific with your prompt and in addition use another agent/context/session to review and find shitty tests and tell you why they're shitty or look for missing tests, basically keep doing a review, then feed the review into the agent writing the tests.
Meanwhile, in the grandparent comment:
> Somehow 90% of these posts don't actually link to the amazing projects that their author is supposedly building with AI.
You are in the 90%.
I think this is unfair, they could be referring to proprietary projects at their job or something.
When you create a blog post about it though, I do agree that showing the projects will greatly increase the value of your claims.
I’m using it in a >200kloc codebase successfully, too. I think a key is to work in a properly modular codebase so it can focus on the correct changes and ignore unrelated stuff.
That said, I do catch it doing some of the stuff the OP mentioned— particularly leaving “backwards compatibility” stuff in place. But really, all of the stuff he mentions, I’ve experienced if I’ve given it an overly broad mandate.
Yes, this is my experience as well. I've found the key is having the AI create and maintain clear documentation from the beginning. It helps me understand what it's building, and it helps the model maintain context when it comes time to add or change something.
You also need a reasonably modular architecture which isn't incredibly interdependent, because that's hard to reason about, even for humans.
You also need lots and lots (and LOTS) of unit tests to prevent regressions.
> But only for the first ~10kloc
Then let me introduce you to a useful concept:
https://en.wikipedia.org/wiki/Separation_of_concerns
This X 100.
I've learned with LLM coded apps to break stuff into very small manageable chunks so they can work on the tiny piece and not get screwed by big context.
For the most part, this actually produces a cleaner codebase.
Where are you getting the 10kloc threshold from? Nice round number...
Surely it depends on the design. If you have 10 10kloc modular modules with good abstractions, and then a 10k shell gluing them together, you could build much bigger things, no?
I agree with you in part, but I think the market is going to shift so that you won’t so many need “mega projects”. More and more, projects will be small and bespoke, built around what the team needs or answering a single question rather than forcing teams to work around an established, dominant solution.
How much are you willing to bet on this outcome and what metrics are you going to measure it with when we come to collect in 3 years?
This is the way: make every one of these people with their wild ass claims put their money where their mouths are.
7 replies →
I wonder if you can up the 10kloc if you have a good static analysis of your tool (I vibecoded one in Python) and good tests. Sometimes good tests aren't possible since there are too many different cases but with other forms of codes you can cover all the cases with like 50 to 100 tests or so
Could you elaborate on the static analysis?
Don't you think it has gotten an order of magnitude better in the last 1-2 years? If it only requires another an order of magnitude improvement to full-on replace coders, how long do you think that will take?
Who is liable for the runtime behavior of the system, when handling users’ sensitive information?
If the person who is liable for the system behavior cannot read/write code (as “all coders have been replaced”), does Anthropic et al become responsible for damages to end users for systems its tools/models build? I assume not.
How do you reconcile this? We have tools that help engineers design and build bridges, but I still wouldn’t want to drive on an “autonomously-generated bridge may contain errors. Use at own risk” because all human structural engineering experts have been replaced.
After asking this question many times in similar threads, I’ve received no substantial response except that “something” will probably resolve this, maybe AI will figure it out
Who is responsible now when human coding errors leak user's sensitive information? I'm not seeing programmers held up as the responsible party. The companies who own the code are vaguely responsible, so it will be the same.
The bridge scenario is simply addressed: Licensed Engineer has to approve designs. Permitting review process has to review designs. Not sure it matters who drafted them initially.
1 reply →
You’re right, but on the other hand once you have a basic understanding security, architecture, etc you can prompt around these issues. You need a couple of years of experience but that’s far less then the 10-15 years of experience you needed in the past.
If you spend a couple of years with an LLM really watching and understanding what it’s doing and learning from mistakes, then you can get up the ladder very quickly.
I find that security, architecture, etc is exactly the kind of skill that takes 10-15 years to hone. Every boot camp, training provider, educational foundation, etc has an incentive to find a shortcut and we're yet to see one.
A "basic" understanding in critical domains is extremely dangerous and an LLM will often give you a false sense of security that things are going fine while overlooking potential massive security issues.
Somewhere on an HN thread I saw someone claiming that they "solved" security problems in their vibe-coded app by adding a "security expert" agent to their workflow.
All I could think was, "good luck" and I certainly hope their app never processes anything important...
1 reply →
But if you are not saving "privileged" information who cares? I mean think of all the WordPress sites out there. Surely vibecoding is not SO much worse than some plugin monstrosity.... At the end of the day if you are not saving user info, or special sauce for your company, it's no issue. And I bet a huge portion of apps fall into this category...
> If you spend a couple of years with an LLM really watching and understanding what it’s doing and learning from mistakes, then you can get up the ladder very quickly.
I don't feel like most providers keep a model for more than 2 years. GPT-4o got deprecated in 1.5 years. Are we expecting coding models to stay stable for longer time horizons?
This is the funniest thing I've read all week.