back
128 comments
I have come to the conclusion that many people are going to live this AI period pretty much like the five stages of grief: denial that it can work, anger at the new robber barons, bargaining that yeah it kinda works but not really well enough, catastrophic world view and depression, and finally acceptance of the new normality.

I'm still at the bargaining phase, personally.

What's the 'new normality' in the fifth stage? Do you think you'll start to believe it actually works 100%? Or that you won't change your assessment that it works only sometimes, but maybe pulling the lever on the slot machine repeatedly is better/more efficient than doing it yourself?
Business will start accepting bad uptime to be the norm. Following the lead of Github: https://mrshu.github.io/github-statuses/
People will accept it as a way to build good software.

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.

When you resolve bottlenecks, new bottlenecks become apparent. Right now, it's looking like assessment and evaluation are massive bottlenecks.
I'm not sure, but I think it boils down to accepting that some things we were attached to are no longer important or normal (not just software building).

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...

It doesn't have to work 100% of the time to be ubiquitous! This is just the strangest point of view. People don't work 100% of the time either, and they wrote all the code we had until a couple of years ago. How did we deal with that? Many different kinds of checks and mitigations. And sometimes we get bugs in prod and we fix them.
The new normal will be: Everything will get worse and far more unstable (both in terms of UI/UX and reliability), and many of us will loose their jobs. Also the next generation of the programmers will have shallower understanding of the tools they use.
AI doesn't need to outrun the bear; it only needs to outrun you.

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.

I’m at the fucking loom smashing stage personally.

We don’t have to accept things.

I hear you, but let me point out that Ned Ludd didn't stop the industrial revolution.

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.

How long can you afford to stay in this phase? Is there some framework you can suggest where this path works?
> yeah it kinda works but not really well enough

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.

This is true for things you already understand. It works for implementing yet another CRUD view because I've done it a million times before. I know exactly what the code should look like, but it takes a while to type it in. When my typing speed is the bottleneck then of course LLMs win (and I use them for that all the time).

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.

I think it's still true, but very domain specific. I am not confident it will stay true.
Less than 6 months ago I would say about 50% of HN was at the denial phase saying it's just a next token predictor and that it doesn't actually understand code.

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.

> I hated writing software this way. Forget the output for a moment; the process was excruciating. Most of my time was spent reading proposed code changes and pressing the 1 key to accept the changes, which I almost always did. [...]

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.

>reviewing the code later on without 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.

> 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.

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...

I think that those permissions are largely security theater anyway.

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.

I'm legitimately curious - could you elaborate on the difference? Speaking as someone who has always preferred the commit-by-commit focus of a rebase instead of all-at-once merge conflict resolution, auditing all the changes together later doesn't sound more appealing than doing things incrementally.
I think it's too far to say you need YOLO mode — the author was correctly pointing to the "auto-accept all changes" setting. They should have just turned that on and then reviewed the changes in larger chunks. You don't have to let it go for half an hour and review the mess it cooked up — you can keep an eye on things and even manually make commits to break the work into logical pieces.

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.

Even if you don't want to do yolo mode, there are things like Copilot Autopilot or you can make the permissions for Claude so wide that they can work for an hour and let you come back to the artifact after lunch.
Yesterday I had it get the length of a word in characters by doing `word.len()`. In Rust. In 2026. Using Opus.

This again showed me that I can't go in YOLO mode. Things like this are disastrous if left to fester in a codebase.

...and then you get "the agent just git resetted --hard 12 hours of my work!", because AI bros can't be bothered to make their tooling actually good and version the changes at filesystem level, because it needs more than putting another variation of "pretty please don't break things" in the prompt.
The door is really opening for programmers who like getting stuff made, and really closing for those who like making stuff at a low level.

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.

I recently spoke to a very junior developer (he's still in school) about his hobby projects.

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.

> stuff that is levels above what I ever made

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.

You can still survive without using generative tools. Just not writing crud apps .

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 .

Your experience may be valuable, and in fact made me think, but I also think the brashness of framing everything in the "adapt or die" ultimatum is unnecessary and off-putting.
The way I see it, the kid has a dangerous dependency on at least one expensive service, cannot solve problems by himself and highly likely doesn't understand core concepts of programming and computers in general.

Yeah I dread the software landscape in 10 years, when people will have generated terabytes of unmaintainable slop code that I need to fix.

Maybe adapt and still die anyway?
Psychopaths running the circus
The author has arrived at resentful acceptance of the models power(eg: "negative externalities", "condemn those who choose").

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.

They really shouldnt have read all the changes individually. What you gotta do is set up your VC properly so these changes are seperated from good code, and then review the whole set of changes in an IDE that highlights them, like a proto PR. Thats far far less taxing since you get the whole picture
giving partial credit to Rust, the language, for shipping production code because you "hate" the experience of agent-driven development so much is an amazing move. i didn't think we could push things forward so fast. i guess Rust is just that powerful
> I have no reason to expect this technology can succeed at the same level in law, medicine, or any other highly human, highly subjective occupation.

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.

I was just talking to some friends in medicine the other day. They are getting more and more AI stuff and they love it.

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.

I wouldn’t trust a tool that advises people to put glue on pizza to make medical decisions.
Don't care. It's no longer up for debate: this is the future. Shape up or ship out.
Why even responding then? And are we not allowed to talk about how doing our jobs makes us feel?
These takes are growing increasingly tiresome, I have to admit. They are pretty much all just tacit admissions of some kind of skill issue with this new class of tool, but presented with a sheen of moral outrage. I don’t think anyone’s buying it anymore. Figure it out.
What kind of skill does it require to let LLMs write 100% of your code? I'm genuinely asking, what's the hard part that a pre-LLM developer is fundamentally incapable of doing? Is it running the agents in a loop? Or along a state machine? Running them in parallel? Because honestly none of that sounds like anything an experienced software dev shouldn't be able to pick up in two weekends.
The worst are the anecdotal poster claiming that they are faster and more correct than an LLM nearly all the time.

If that's not delusional thinking I don't know what is.

Did you not read the linked blog post? Author admits that Claude did a good job