[flagged]
(You're welcome to make your substantive points thoughtfully, of course.)
Response: Try experimenting in a low stakes environment
From Google: "Exposure therapy is a psychological treatment designed to help people confront their fears, break cycles of avoidance, and reduce anxiety."
It's those who don't do it who'd need a talk..!
And I say this with the bitterness of someone having lost a big part of what made me enjoy this line of work.
But I have no interest in working as a vibecoder, there are many other jobs that I'd enjoy more
However, I suspect there are teams that are making different choices. In the most obvious example, I can do whatever I want on my personal projects (I hope you agree). And if I started a business and hire in programmers, I have some expectation on defining the culture, making hiring decisions based on my preferences, etc.
Whether or not such teams succeed will be a matter of fact, which I do not believe has been decided at this time.
How does "low-stakes environment" fix that?
Last time I chose to vibe code, I did it in a language I didn’t know so that I wasn’t tempted to try and comprehend the choices the robot made. I ended up with the application I wanted.
Caveat: it was code I would never have to touch again, I ran a script to generate the 140,000 static html pages that the rails app provided and then just uploaded them all to R2 buckets (million reads per month on free tier)
No, they are saying "who cares if all those issues with code are true, just don't review it"
> Caveat:
It's not really a caveat. I also have throw-away code. But we're not talking about throw--away code. We're talking about the systemic issues in LLM-produced code, which are completely ignored and the answer is always "who cares, close your eyes and don't review the code".
The classic consideration is, this code will need to be maintained, built on top of… but it’s not like that was ever a solved problem, big projects remain fragile and corporate turnover means no one knows the entire stack. So I see the vibe code out there as just another imperfect way to build barely good enough software.
I’ve also written code I built slowly and intentionally as a piece of art, beautiful code I was proud of. Didn’t make me any money :)
LLM output isn't compiler output. It's a lot of shitty code that contains duplication, subpar algorithms, bad data access patterns etc. We were complaining about awful software before LLMs. Why is it now absolutely okay to write shitty software just because it's LLMs?
Also: literally no one is talking about "writing software as art". We 're talking about this: "many things (redundant code, duplicate code, overly complex architecture, etc.)"
For example, for all the claims of how LLMs are better than humans, or how you can ship gazillion LoC easily, we've yet to see any significant number of actual good software to come out of this slopathon. Even the frontier labs with unrestricted access to their own models who boasting how they merge 30000 PRs per day [1] ship unbelievable buggy shit. But it's okay because it's LLMs who cares?
[1] https://claude.dev/blog/solving-code-review-at-anthropic/
The person is saying "I am still unable to stop" and that is most likely because they feel a sense of responsibility. If they choose a project where there is no responsibility, where it literally doesn't matter if the project fails, they may feel able to stop. And if they manage to make that project work, if they can succeed, then they will build up confidence.
It seems better to be able to work both on projects where they review all code as well as projects where they do not review any code. In fact, keeping their job in the long term may (or may not) require having both skills.
They are not overblown. LLMs do all the things the person described.
> Or they may learn that they cannot build any kind of software without reviewing every line of code.
We already had bad horrendous software before the onslaught of LLM-slop. Why contribute to that?
> And if they manage to make that project work, if they can succeed, then they will build up confidence.
Confidence in what? It doesn't fix the underlying issue. And the underlying issue isn't "I can't stop" but "redundant code, duplicate code, overly complex architecture, etc." that LLMs regularly produce.
> It seems better to be able to work both on projects where they review all code as well as projects where they do not review any code.
"If I close my eyes maybe this goes away"
Do you think it's better to experiment with high stakes projects? Do you think it'll be easier to avoid defaulting to line by line auditing of a project that is high stakes?
Ah yes. "all the magic the people say work 100% of the time"
> Do you think it's better to experiment with high stakes projects?
This again assumes that people working on high stakes projects only work on one single project.
This again assumes that people finding issues with LLM-generated code have not tried every magic recipe under the sun from people claiming their hair growth elixir is 100% a working solution.
This again assumes that people experiencing something different from the others are inevitably stupid.
etc. etc.
I don't see how this rebutts the implication.
> This again assumes that people working on high stakes projects only work on one single project.
No it doesn't. It's a very straightforward yes or no question.
> This again assumes that people finding issues with LLM-generated code have not tried every magic recipe under the sun from people claiming their hair growth elixir is 100% a working solution.
He's just describing very common failure modes that come from a lack of structure/linting.
You're framing things like this is some grand conspiracy. OP is literally describing flat tires and your rebuttal is "these magical round tires i keep hearing about." It's very strange.
LLMs will dedupe code if you give them structures to find the duplication. It's not magic. I do it every day.
It's not. OP is literally stating a fact that he sees in his work with LLMs. Without even saying what he's working on.
Your (and others') immediate assumptions:
- he only works on one project
- this only project is high stakes
- they are not magicking their project with right magicks. Sorry, not "harnessing agents"
- they lack structure/linting
Ah yes. It's very strange of me to call out these assumptions.
Now, let me step in the OP's shoes as a person who sees the same issues across multiple projects and doesn't believe in magic (and has tried all of them, except the very expensive ones).
Here's the entirety of OP's text, emphasis mine: "Here I am still unable to stop myself from doing line-by-line code review. I notice too many things (redundant code, duplicate code, overly complex architecture, etc.) by doing it that I feel it would be careless not to."
So:
- no amount of "harnessing the coding agent very strongly" will fix those issues.
Also, "harnessing an agent strongly" is as meaningless as "there's some magic that will fix it". Agents will always continue with code duplication and sloppy architecture. It's a fact of reality.
You can run a "swarm of review agents" that will catch some of that, but this is just a) acknowledging the problem, and b) handing off the problem to the same LLMs that produced the problems in the first place and hoping that they will magically fix them
- no amount of linting will help with things like code duplication, redundant code, or overly complex architecture. No linter catches bad architecture. Very few languages have tools to do semantic code analysis and catch duplicate or redundant code.
- no idea what you mean by "structuring". To structure code correctly you need human input because <see issues described>. Any other "structure" is just running a bunch of the same LLMs on top of various markdown files telling them "make no mistakes" in various ways.
I am not kidding or lying that just today I was "structuring" Opus 5.5 to remove duplication from code it was creating as I was watching it. Despite all the "structuring" and "harnessing" etc. And catching previous duplication introduces by Fable and Astra despite all the "structuring" and things like https://github.com/elixir-vibe/ex_dna