Comment by fg137
14 hours ago
I was just looking at some user-facing error messages Claude generated for me which contained unnecessary/irrelevant technical details while failed to provide clear instructions or fix.
Earlier, I reviewed code that does way more than specified scope, changes public API and introduces new behavior. I had to almost redo the whole thing.
I thought to myself, no way I am going to ship the code as written without actually reading through it (or as some people put it, only looking at the "intent"). I'll get more complaints from users while having absolutely no idea what's going on with the code or actual behavior.
It's a puzzle to me how these orgs can pull it off.
It really depends on the kind of product you're working on. A lot of developers (and managers and business leaders) assume that their workflows will apply to other kinds of products; and are often very wrong.
For example: A few days ago I saw a quote that over 90% of current Y-Combinator startups vibecode their products. The problem is the author misunderstands context: Startups sacrifice quality for time to market. In other cases, if you're building something that isn't technically challenging, (because it's 80% similar to many other products out there,) you can probably vibecode it.
In contrast, if you're doing something technically challenging, it's to your benefit to be a lot more hands-on. I recently started getting excellent reviews from copilot of my hand-written code. (Or, I should say, the hand-written parts of an AI-assisted pull request.)
I think it also depends on how well defined requirements are. I can have Claude nearly one shot a Terraform provider but it's just taking 2 API contracts and combining them together (the provider contract and the API you're automating)
On the other hand, some things are incredibly product intensive and poorly defined and it seems LLMs will latch on to an arbitrary direction with much lower success rate.
It is also worse in "brown field" where there's lots of tribal knowledge and technical debt. Two systems may both exist that look very similar but oftentimes there's the one on life support that almost no one uses or cares about and the LLM doesn't know it should largely ignore that until it's thoroughly documented (which can be a significant undertaking)
The people / orgs that can actually codify their strong software engineering principles and practices into "a harness"[1] are the people / orgs that find success with these tools.
The rest are just marketers.
[1] Whatever that means to them
Even then, the actual development of a harness for interesting problems is a difficult task. It requires more skill & experience than people realize, and gets harder as you scale things up.
Yes
> no way I am going to ship the code as written without actually reading through it
Interestingly agents can help, not replace, this process
These tools will make us more productive, they will disrupt (have disrupted) our industry, but they will not replace us because they cannot