Having used Claude Code in anger for a while now, I agree that given the state of these agents, we can't stop writing code by hand. They're just not good enough.
But that also doesn't mean they're useless. Giving comparatively tedious background tasks to the agents that I check in on once or twice an hour does feel genuinely useful to me today.
There's a balance to be found that's probably going to shift slowly over time.
Contrary to what most devs belief: Most code is not shipped to hundreds of millions of users and passing the test and actually implementing a feature is worth more that drowning in backlog.
The video is spot on for codebases of products that are critical systems: payment, erp etc -> single source of truth.
Simple Crud apps/ Frontends for ecom that abstracted away the critical functionality to backend APIs (ERP, shop system, payment etc) benefit from vibe slop vs no shipping cadence
I think the points about code ownership and responsibility are spot on. Management wants you to increase velocity with these agents so inevitably there is pressure to ship crappy code. You then will be responsible for the code, not the AI. It’s the idea of being a reverse centaur.
I also like the comments on how developers should be frequently reading the entire code and not just the diffs. But again there is probably pressure to speed up and then that practice gets sacrificed.
While I greatly dislike the hype and don't believe most of what people say is real or that whatever they're building is just bullshi, I can definitely see the improvement of productivity, specially when working with agents.
I think the problem is that people:
* see the hype;
* try to replicate the hype;
* it fails miserably;
* they throw everything away;
I'm on call this week on my job, one of the issues was adding a quick validation (verifying the length of a thing was exactly 15). I could have sat and done that but I just spun an agent, told it where it was, told it how to add the change (we always add feature flags to do that), read the code, prompted it to fix a thing and boom, PR is ready. I wrote 3 paragraphs, didn't have to sit and wait for CI or any of the other bullshit to get it done, focused on more important stuff but still got the fix out.
Don't believe the hype but also don't completely discount the tools, they are incredible help and while they will not boost your productivity by 500%, they're amazing.
It’s now ship shit but it’s the right way to do. We need to figure out how to make it ship high quality code as possible as we can. Not just give it up.
Try implementing something that is too hard for you. Usually that'll involve implementing math in a high performance language or with parallelization. Then try going back to "writing by hand".
if it’s too hard for you to write, it’s too hard for you to understand and comprehend. how are you going to take responsibility for that code and maintain it if needed?
Recently I've seen coworkers frequently turn what should be a <10 line bugfix into a 500+ line refactor across multiple files. I suspect it's due to AI.
There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.
There is a balance to be struck. Not everyone is going to be comfortable with ralph loops. Some are going to be OK with running a single agent, some with advanced code completion or code generation for specific functionality and so on.
The tooling is going to change how we do development no doubt, but people are going to find their comfortable spot, and be productive.
"If you're a software developer and you're worried about your job, you haven't spent enough time actually using these AI agents. Anyone who spent eight hours plus a day over the last year using these agents is not at all scared of these agents taking their jobs. They're not... Your job is not going anywhere."
I agree with this take... for now. I wouldn't be surprised if the AI agents improved exponentially (in the next few years) to the point where his statement is no longer true.
I really appreciate all of his message -- responsibility and actual engineering are critical and can't be (deceptively) lost even though Pull Request and CI/CD workflows exist. I hate the term vibe-coding because it seems flippant, and I've leaned into LLM-assistance to frame it better.
Multiline autocomplete is still the biggest productivity boost for me. This works well in a familiar codebase with reasonably consistent patterns.
After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions.
Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs.
Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines.
Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.
i am new to llm assisted coding, but i dont like the way it try to add more stuff when fixing thing, instead of going simplest less code possible, it recreate bunch of already coded logic, it also mostly try to code workaround and accumulate spagetti-esque codes. any advise? appreciate it
All of these “go back to handcoding” posts seem to be done by very experienced coders. The fact that a less than mediocre coder like me can have sql statements or Python ETL written and tested for me in seconds rather than hours is all I need to see.
> "in isolation this code makes a lot of sense"..."what is this junk"
I mean I am left with two thoughts:
1. programming language skill issue. Some languages are simply much better at composition than others. I find that yes, this happens, but actually on the order of a day, and once the code is "good", it doesn't really change that much in the grand scheme of things?
2. Even for languages where composition is better, this is exactly what happens with human development too?
From my attempts, still, it takes more time to fix the code than it would if writing it all by hand.
BUT!
It's getting better and I look at it as just the next abstraction layer we will get used to.
Think of it. Back in University I had to write code on PAPER. To think of memory allocation manually!
Then came out managed code..
Then huge SDKs..
Then smart IDEs with intellij/intellisense..
And some us even remember riding the CPU with mov rcx, 5.
We were just shifting our focus byte by byte from the nits and bolts towards the actual problem we are solving. In other words going less "hard"-ware, more and more "soft"-ware.
AI is just continuing this evolution, adding another abstraction layer in soft dev process.
The mistake here was the expectation that LLM code would not be junk.
It's the same junk produced by fast-growing startups. It was always here, now there's more of it.
I'm convinced that people will continue to use it. Therefore, I need to be able to deal with it, maybe even leverage it somehow (there should be coding skills that I possess that people in that realm of fast-growing startups do not bother to learn).
it's usually the balance and middle that is most beneficial. you can't deny the value LLM code generation and research provides. But the extreme of using only LLMs or mostly LLMs. or not using LLMs at all is self-harming.
So far, LLM generated code hasn't lived up to my standards. I'll use it for things that aren't critical as-is, but mostly I use it as a reference, an example, a starting point. Essentially, where in the past I'd find a code base that does things and I'd try to do something similar, now I let the LLM generate the code base. There are to questions it helps me answer:
1) What are the possible ways of solving problems?
2) What are the pros and cons of each approach?
That said, there are people successfully deploying apps that are entirely vibe coded. How many fail or succeed, that I don't know. But there are enough, and you can't deny the evidence.
Artisanal engineering is the only true way to code. No autocomplete. No linting. No prettifying. No colored brackets, braces, or nesting lines. If you're not instinctually converting your Rust to assembler in your head as you insert it into vi, can you even really call yourself a real developer?
I posted this comment using only curl by the way. Don't bother replying because I only engage in bidirectional conversation via SSH tunnel and netcat. I doubt that you could figure it out.
I've been trying Google antigravity. Despite VS code being total dogshit compared to Intellij I'm pretty sure I won't be renewing any more (after 15 years, sorry jetbrains).
There are some managers and developers out there who would charge and ship whatever code AI provides no matter what multidimensional horror there is inside. As long as these people point to test and say "look, the checkbox is green" they will sign on it without taking a single look at the codebase.
So what if tests don't actually cover important parts of the functionality. Checkbox is green and AI review agent said it's fine - so it must be fine.
I've noticed a similar pattern. AI assistants are incredible at kinetic coding i.e. generating boilerplate, refactoring, writing tests. But they are detrimental to potential coding especially at the architectural thinking that happens before you touch the keyboard.
Writing by hand (or whiteboarding) forces you to load the entire context into your working memory. AI allows you to be lazy with your working memory. The code gets written faster, but the mental model of the system in my head is significantly weaker.
31 comments
[ 3.2 ms ] story [ 42.1 ms ] threadBut that also doesn't mean they're useless. Giving comparatively tedious background tasks to the agents that I check in on once or twice an hour does feel genuinely useful to me today.
There's a balance to be found that's probably going to shift slowly over time.
The video is spot on for codebases of products that are critical systems: payment, erp etc -> single source of truth.
Simple Crud apps/ Frontends for ecom that abstracted away the critical functionality to backend APIs (ERP, shop system, payment etc) benefit from vibe slop vs no shipping cadence
I also like the comments on how developers should be frequently reading the entire code and not just the diffs. But again there is probably pressure to speed up and then that practice gets sacrificed.
I think the problem is that people:
* see the hype;
* try to replicate the hype;
* it fails miserably;
* they throw everything away;
I'm on call this week on my job, one of the issues was adding a quick validation (verifying the length of a thing was exactly 15). I could have sat and done that but I just spun an agent, told it where it was, told it how to add the change (we always add feature flags to do that), read the code, prompted it to fix a thing and boom, PR is ready. I wrote 3 paragraphs, didn't have to sit and wait for CI or any of the other bullshit to get it done, focused on more important stuff but still got the fix out.
Don't believe the hype but also don't completely discount the tools, they are incredible help and while they will not boost your productivity by 500%, they're amazing.
Who is going to be responsible for the code? AI is definitely not responsible.
There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.
The tooling is going to change how we do development no doubt, but people are going to find their comfortable spot, and be productive.
I agree with this take... for now. I wouldn't be surprised if the AI agents improved exponentially (in the next few years) to the point where his statement is no longer true.
After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions.
Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs.
Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines.
Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.
I know what I want before I type it. Having to parse the auto-completion disrupts the thought process of what I _wanted_ to write.
I mean I am left with two thoughts:
1. programming language skill issue. Some languages are simply much better at composition than others. I find that yes, this happens, but actually on the order of a day, and once the code is "good", it doesn't really change that much in the grand scheme of things?
2. Even for languages where composition is better, this is exactly what happens with human development too?
And some us even remember riding the CPU with mov rcx, 5.
We were just shifting our focus byte by byte from the nits and bolts towards the actual problem we are solving. In other words going less "hard"-ware, more and more "soft"-ware.
AI is just continuing this evolution, adding another abstraction layer in soft dev process.
It's the same junk produced by fast-growing startups. It was always here, now there's more of it.
I'm convinced that people will continue to use it. Therefore, I need to be able to deal with it, maybe even leverage it somehow (there should be coding skills that I possess that people in that realm of fast-growing startups do not bother to learn).
So far, LLM generated code hasn't lived up to my standards. I'll use it for things that aren't critical as-is, but mostly I use it as a reference, an example, a starting point. Essentially, where in the past I'd find a code base that does things and I'd try to do something similar, now I let the LLM generate the code base. There are to questions it helps me answer:
1) What are the possible ways of solving problems?
2) What are the pros and cons of each approach?
That said, there are people successfully deploying apps that are entirely vibe coded. How many fail or succeed, that I don't know. But there are enough, and you can't deny the evidence.
I posted this comment using only curl by the way. Don't bother replying because I only engage in bidirectional conversation via SSH tunnel and netcat. I doubt that you could figure it out.
I've been trying Google antigravity. Despite VS code being total dogshit compared to Intellij I'm pretty sure I won't be renewing any more (after 15 years, sorry jetbrains).
There are some managers and developers out there who would charge and ship whatever code AI provides no matter what multidimensional horror there is inside. As long as these people point to test and say "look, the checkbox is green" they will sign on it without taking a single look at the codebase.
So what if tests don't actually cover important parts of the functionality. Checkbox is green and AI review agent said it's fine - so it must be fine.
Writing by hand (or whiteboarding) forces you to load the entire context into your working memory. AI allows you to be lazy with your working memory. The code gets written faster, but the mental model of the system in my head is significantly weaker.