I'm still at the bargaining phase, personally.
Many are still in denial that you can do work that is as good as before, quicker, using coding agents. A lot of people think there has to be some catch, but there really doesn’t have to be. If you continue to put effort in, reviewing results, caring about testing and architecture, working to understand your codebase, then you can do better work. You can think through more edge cases, run more experiments, and iterate faster to a better end result.
But specifically to your examples, the latter: I think the "brute force the program" approach will be more common that doing things manually in many cases (not all! I'm still a believer in people!).
Edit: Well, I wrote a bad blog post on this some time ago, I might as well share it: I think the accepting means engaging with the change rather than ignoring it.
https://riffraff.info/2026/03/my-2c-on-the-ai-genai-llm-bubb...
Once the tools outperform humans at the tasks to which they were applied (and they will), you don't need to be involved at all, except to give direction and final acceptance. The tools will write, and verify, the code at each step.
We don’t have to accept things.
I think in the foreseeable future we have open models running on commonly available hardware, and that is not a change that can be stopped (and arguably it's the commons getting back their own value). What we can do is fight for proper taxation, for compensatory fees, for regulation that limits plagiarism, for regulation of the most extreme externalities.
But it makes no sense, to me, to fight the technology tout court.
I mean, at some point it was true.
I remember that around 2023, when I first encountered colleagues trying to use ChatGPT for coding, I thought "by the time you are done with your back-and-forth to correct all the errors, I would have already written this code manually".
That was true then, but not anymore.
But the interesting stuff where you don't understand the problem yet, it doesn't make it quicker. Because then the bottleneck is my understanding. Things take time. And sleep. They require hands-on experience. It doesn't matter how fast LLMs can churn out code. There's a limit to how fast I can understand things. Unless, of course, I'm happy shipping code I don't understand, which I'm not.
To all of you I can only say, you were utterly wrong and I hope you realize how unreliable your judgements all are. Remember I'm saying this to roughly 50% of HN., an internet community that's supposedly more rational and intelligent than other places on the internet. For this community to be so wrong about something so obvious.... That's saying something.
You gonna give some predictable answer about next token prediction and probability or some useless exposition on transformers while completely avoiding the fact that we don’t understand the black box emergent properties that make a next token predicted have properties indistinguishable from intelligence?
They weren't wrong though. It objectively is just a next turn predictor and doesn't understand code. That is how the thing works.
That's why they hated it. Approving every change is the most frustrating way of using these tools.
I genuinely think that one of the biggest differences between people who enjoy coding agents and people who hate them is whether or not they run in YOLO mode (aka dangerously-skip-permissions). YOLO mode feels like a whole different product.
I get the desire not to do that because you want to verify everything they do, but you can still do that by reviewing the code later on without the pain of step-by-step approvals.
I found that Claude likes to leave some real gems in there if you get lazy and don't check. Gently sprinkled in between 100 lines of otherwise fine looking code that sows doubt into all of the other lines it's written. Sometimes it makes a horrific architectural decision and if it doesn't get caught right there it's catastrophic for the rest of the session.
It's a well-known truth in software development that programmers hate having to maintain code written by someone else. We see all the ways in which they wrote terrible code, that we obviously would never write. (In turn, the programmers after us will do the same thing to our code.)
Having to get into the mindset of the person writing the code is difficult and tiring, but it's necessary in order to realise why they wrote things the way they did - which in turn helps you understand the problems they were solving, and why the code they wrote actually isn't as terrible in context as it looked at first glance.
I think it makes sense that this would also apply to the use of generative AI when programming - reviewing the entire codebase after it's already been written is probably more error-prone and difficult than following along with each individual step that went into it, especially when you consider that there's no singular "mindset" you can really identify from AI-generated output. That code could have come from anywhere...
It would be better if an LLM coding harness just helped you set up a proper sandbox for itself (containers, VMs etc.) and then run inside the isolated environment unconstrained.
In setup mode, the only tool accessible to the agent should be running shell scripts, and each script should be reviewed before running.
Inside an isolated environment, there should be no permission system at all.
If you launch it in YOLO mode in a separate branch in a separate worktree (or, preferably, in total isolation), you can instead spend time reviewing changes from previous tasks or refining requirements for new tasks.
With auto-accept edits plus a decent allowlist for common commands you know are safe, the permission prompts you still get are much more tolerable. This does prevent you from using too many parallel agents at a time, since you do have to keep an eye on them, but I am skeptical of people using more than 3-5 anyway. Or at least, I'm sure there is work amenable to many agents but I don't think most software engineering is like that.
All that said, I am reaching the point where I'm ready to try running CC in a VM so I can go full YOLO.
This again showed me that I can't go in YOLO mode. Things like this are disastrous if left to fester in a codebase.
He doesn't have our bagage. He doesn't feel the anxiety the purists feel.
He just pipes all errors right back in his task flow. He does period refactoring. He tests everything and also refactors the tests. He does automated penetration testing.
There are great tools for everything he does and they are improving at breakneck speeds.
He creates stuff that is levels above what I ever made and I spent years building it.
I accepted months ago: adapt or die.
How is that measured? Is his stuff maintainable? Is it fast? Are good architectural decisions baked in that won't prevent him from adding a critical new feature?
I don't understand where this masochism comes from. I'm a software developer, I'm an intelligent and flexible person. The LLM jockey might be the same kind of person, but I have years of actual development experience and NOTHING preventing me from stepping down to that level and doing the same thing, starting tomorrow. I've built some nice and complicated stuff in my life, I'm perfectly capable of running a LLM in a loop. Most of the stuff that people like to call prompt/agentic/frontier or whatever engineering is ridiculously simple, and the only reason I'm not spending much time on it is that I don't think it leads to the kind of results my employer expects from me.
There is plenty of code that require proof of correctnesss and solid guarantees like in aviation or space and so on. Torvalds in a recent interview mentioned how little code he gets is generated despite kernel code being available to train easily .
Yeah I dread the software landscape in 10 years, when people will have generated terabytes of unmaintainable slop code that I need to fix.
“He automated his job so well the company doesn’t need him anymore.”
If that's not delusional thinking I don't know what is.
I mean, if anything, I would expect it to help bring structure to medicine, which is an often sloppy profession killing somewhere between tens of thousands and hundreds of thousands of people a year through mistakes and out of date practices.
As medicine is currently very subjective. As a scientific field in the realm of physical sciences, it shouldn't be.
Just basic stuff like smart dictation that listens to the conversation the practitioner is having and auto creates the medical notes, letters, prescriptions etc saving them time and effort to type that all up themselves etc. They were saying that obviously they have to check everything but it was (and I quote) "scarily perfectly accurate". Freeing up a bunch of their time to actually be with the patient and not have to spend time typing etc.
No need to get out the chisel to carve those intricate designs in your chair back. We can just get that made by pressing "1". Sorry, those of you who took pride in chiseling.
I'm definitely in the latter group. I can and do use AI to build things, but it's pretty dull for me.
I've spent hours and hours putting together a TUI window system by hand recently (on my own time) that Claude could have made in minutes. I rewrote it a number of times, learning new things each time. There's a dual goal there: learn things and make a thing.
Times change, certainly. Glad to be in semi-retirement where I still get to hand carve software.
But the next step for many is championing acceptance. Eg "that the same kind of success is available outside the world of highly structured language" .. it actually is visible when you engage with people. I'm myself going through this transition.
