This article is knocking down a very expansive claim that most serious (ie: not vibe-coding) developers aren't making. Their point is that LLM agents have not yet reached the point where they can finish a complicated job end-to-end, and that if you want to do a completely hands-off project, where only the LLM generates any code, it takes a lot of prompting effort to accomplish.
This seems true, right now!
But in building out stuff with LLMs, I don't expect (or want) them to do the job end-to-end. I've ~25 merged PRs into a project right now (out of ~40 PRs generated). Most merged PRs I pulled into Zed and cleaned something up. At around PR #10 I went in and significantly restructured the code.
The overall process has been much faster and more pleasant than writing from scratch, and, notably, did not involve me honing my LLM communications skills. The restructuring work I did was exactly the same kind of thing I do on all my projects; until you've got something working it's hard to see what the exact right shape is. I expect I'll do that 2-3 more times before the project is done.
I feel like Kenton Varda was trying to make a point in the way they drove their LLM agent; the point of that project was in part to record the 2025 experience of doing something complicated end-to-end with an agent. That took some doing. But you don't have to do that to get a lot of acceleration from LLMs.
It’s almost like unrealistic expectations of LLMs driven by those working for companies who have something to gain by labeling any skepticism as “crazy” does significant damage to our perception of it’s usefulness.
I'm sorry, I read this comment like 3 times and I still don't understand what it's trying to say. Who are the companies you're talking about and are they too positive on LLMs or too negative?
Just that blind fanaticism leads to things like constant goal post moving when the product doesn’t live up to the hype. This damages people’s perception of the tool and causes them to be burnt out on it when it isn’t in fact magic.
Instead we should be accepting that people will or wont find uses for it depending on their competency (CRUD app churn VS somewhat novel creations) and accept that without telling them they’re nuts, luddites, etc.
Then again like I said the people doing that usually have something to gain such as a product related to the hype generating product.
I wrote that article, and I don't believe "any" skepticism of "AI" is nuts. As an existence proof: I think "vibe coding" produces results as bad as skeptics say it does. The article is pretty specific about what it says the nutty claims are.
It's just that... Framing your post in terms of the opinions of devs that you personally know, and not those of the AI-assistance community at large* resolved your issue with ofjcihen. for me (only, it seems :().
*explicitly including e.g., Lisp, Haskell (radical futurists?),
Could you restate it? My whole point in this thread is that the article is knocking down an argument many supporters of "AI coding" aren't making. As I've just demonstrated, it's easy to find a skeptical argument that this "supporter" agrees with.
I mean I could but I think a better way to get to the heart of this discussion is to ask why you put quotations around supporter when describing the author.
Do you think he’s secretly against the tool itself or do you acknowledge that maybe the tool just doesn’t work for him and his use case and maybe he’s not nuts for finding fault with it?
Let's repeat this process for 100 coding examples and see how many it can complete "hands-off" especially where (a) it isn't a case of here is a spec and I need you to implement it and (b) it isn't for a a use for which there is already publicly available code.
Otherwise your claim of "this seems true, right now!" is baseless.
I think more specifically, if you don't have strong guidance to the LLM on how a project is organized and where things should go, things go pretty far off the rails.
I tried to have an LLM fully write a Python library for me. I wrote an extensive, detailed requirements doc, and it looked close enough that I accepted the code. But as I read through it more closely, I realized it was duplicating code in confusing ways, and overall it took longer than just getting the bones down myself, first.
Some coding agents are now more actively indexing code, I think that should help with this problem
This seems true, right now!
But in building out stuff with LLMs, I don't expect (or want) them to do the job end-to-end. I've ~25 merged PRs into a project right now (out of ~40 PRs generated). Most merged PRs I pulled into Zed and cleaned something up. At around PR #10 I went in and significantly restructured the code.
The overall process has been much faster and more pleasant than writing from scratch, and, notably, did not involve me honing my LLM communications skills. The restructuring work I did was exactly the same kind of thing I do on all my projects; until you've got something working it's hard to see what the exact right shape is. I expect I'll do that 2-3 more times before the project is done.
I feel like Kenton Varda was trying to make a point in the way they drove their LLM agent; the point of that project was in part to record the 2025 experience of doing something complicated end-to-end with an agent. That took some doing. But you don't have to do that to get a lot of acceleration from LLMs.