False dichotomy. There is a happy medium where you can orchestrate the agent to give you the code you want even when the spec changes
After two years of vibecoding, I'm back to writing by hand
11–20 of 652 posts
Re: After two years of vibecoding, I'm back to writing by hand
#12> Not only does an agent not have the ability to evolve a specification over a multi-week period as it builds out its lower components, it also makes decisions upfront that it later doesn’t deviate from. That's your job. The great thing about coding agents is that you can tell them "change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttl…
> (And the automated test suite will help them confirm that the refactoring worked properly, because naturally you had them construct an automated test suite when they built those original features, right?)
I dunno, maybe I have high standards but I generally find that the test suites generated by LLMs are both over and under determined. Over-determined in the sense that some of the tests are focused on implementation details, and under-determined in the sense that they don't test the conceptual things that a human might.
That being said, I've come across loads of human written tests that are very similar, so I can see where the agents are coming from.
You often mention that this is why you are getting good results from LLMs so it would be great if you could expand on how you do this at some point in the future.
Re: After two years of vibecoding, I'm back to writing by hand
#13> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM. LL…
> My way is to understand my own codebase and look at the output of the LLM. Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
I don't think the OP was using the classic definition of vibe coding, it seemed to me they were using the looser definition where vibe coding means "using AI to write code".
Re: After two years of vibecoding, I'm back to writing by hand
#14I'm impressed that this person has been vibecoding longer than vibecoding has been a thing. A real trailblazer!
GitHub copilot was released in 2021, and Cursor was released around October 2023[0]. [0]: https://news.ycombinator.com/item?id=37888477
At the earliest, "vibecoding" was only possible with Claude 3.5, released July 2024 ... maaaybe Claude 3, released in March of that year...
It's worth mentioning that even today, Copilot is an underwhelming-to-the-point-obstructing kind of product. Microsoft sent salespeople and instructors to my job, all for naught. Copilot is a great example of how product > everything, and if you don't have a good product... well...
Re: After two years of vibecoding, I'm back to writing by hand
#15Re: After two years of vibecoding, I'm back to writing by hand
#16> Not only does an agent not have the ability to evolve a specification over a multi-week period as it builds out its lower components, it also makes decisions upfront that it later doesn’t deviate from. That's your job. The great thing about coding agents is that you can tell them "change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttl…
> That's your job.
Exactly.
AI assisted development isn't all or nothing.
We as a group and as individuals need to figure out the right blend of AI and human.
Re: After two years of vibecoding, I'm back to writing by hand
#17> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM. LL…
> My way is to understand my own codebase and look at the output of the LLM. Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
I think this is my main confusion around vibe coding.
Is it a skill for the layman?
Or does it only work if you have the understanding you would need to manage a team of junior devs to build a project.
I feel like we need a different term for those two things.
Re: After two years of vibecoding, I'm back to writing by hand
#18Earlier quoted context omitted.
> My way is to understand my own codebase and look at the output of the LLM. Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
I don't think the OP was using the classic definition of vibe coding, it seemed to me they were using the looser definition where vibe coding means "using AI to write code".
The blog appears to imply that the author only opened the codebase after a significant period of time.
> It’s not until I opened up the full codebase and read its latest state cover to cover that I began to see what we theorized and hoped was only a diminishing artifact of earlier models: slop.
This is true vibe coding, they exclusively interacted with the project through the LLM, and only looked at its proposed diffs in a vacuum.
If they had been monitoring the code in aggregate the entire time they likely would have seen this duplicative property immediately.
Re: After two years of vibecoding, I'm back to writing by hand
#19The title alone reads like the "digging for diamonds" meme.
Re: After two years of vibecoding, I'm back to writing by hand
#20> Not only does an agent not have the ability to evolve a specification over a multi-week period as it builds out its lower components, it also makes decisions upfront that it later doesn’t deviate from. That's your job. The great thing about coding agents is that you can tell them "change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttl…
> Going back to typing all of the code yourself (my interpretation of "writing by hand") because you don't have the agent-managerial skills to tell the coding agents how to clean up the mess they made feels short-sighted to me.
I increasingly feel a sort of "guilt" when going back and forth between agent-coding and writing it myself. When the agent didn't structure the code the way I wanted, or it just needs overall cleanup, my frustration will get the best of me and I will spend too much time writing code manually or refactoring using traditional tools (IntelliJ). It's clear to me that with current tooling some of this type of work is still necessary, but I'm trying to check myself about whether a certain task really requires my manual intervention, or whether the agent could manage it faster.
Knowing how to manage this back and forth reinforces a view I've seen you espouse: we have to practice and really understand agentic coding tools to get good at working with them, and it's a complete error to just complain and wait until they get "good enough" - they're already really good right now if you know how to manage them.