Sharad and I have worked together on enough projects that we ended up with names for startup moods. During an earlier cycle he kept describing the people around us as happy confused. They knew they were winning but couldn’t explain why. Last week in SF I caught myself using the phrase again. It didn’t fit anymore. We needed a new one: happy afraid.
I saw it at the AI Engineer World’s Fair last week. It’s probably the closest thing we have to an annual census of what builders actually believe, as opposed to what they tweet. A survey ran across the attendees, and everyone quoted the result without really stopping to think about it. Engineers overwhelmingly said AI had made their work better. Most said they enjoyed their jobs more. And a majority of those same people also said they were afraid of what they were shipping.
Not different camps. The same people. Happy and afraid at the same time, about the same code.
I’ve watched a few of these cycles and I haven’t seen that combination before. Sharad’s happy confused made perfect sense at the time. People knew something extraordinary was happening, but nobody could quite explain the wave they were riding. The confusion is gone now. These engineers have a much clearer picture of what’s happening. That’s exactly what makes them uneasy. When optimism and pessimism stop belonging to different groups of people and start living inside the same person, something structural has changed.
I wrote about this conference last year in State of AI 2025: Death of Code. My argument then was that coding as a manual craft was becoming less valuable, the scarce skill was moving from implementation to specification, and value would accrue to whoever owned the orchestration layer. Reading it again, what surprised me wasn’t what I got right. It was that I’d been tracking the wrong scarcity. So had most of the industry.
A year ago everyone wanted to know whether AI could write enough code. That question is basically over. Nobody on stage was debating it anymore. By mid-2026 it’s normal for agents to write a large share of the code at serious companies, normal for them to have write access to production systems, normal for people who aren’t engineers to ship features. The phrase that kept coming up was “software factory”: a codebase with a floor of AI workers continuously producing software, much like CI/CD quietly produces builds today. Last year people argued about whether that future was real. This year every talk simply assumed it.
So code generation is mostly solved. The question that replaced it is trust. Can you believe what the machines built quickly enough to keep shipping it?
Every plenary session arrived at some version of that question independently. That’s usually how you know a problem is real. People who haven’t coordinated start describing the same thing from different directions.
My first explanation was job fear. It’s the obvious one, and there was an entire talk about engineers worrying they’ll be replaced. But after talking to people, that explanation stopped fitting. The engineers reporting the most fear were often the same ones saying they enjoyed their work more than ever. Their concern wasn’t unemployment. It was long-term responsibility for systems they were shipping today. You don’t spend much time worrying about the long-term health of a codebase if you think you won’t be around to maintain it. These people expected to stay. What worried them was being accountable for software they no longer built line by line.
For most of the history of software, the hard part was building the thing. If you managed to make it work, you usually understood it, because making it work required understanding it. Understanding wasn’t something you optimized for. It came bundled with building the software.
Between 2023 and 2026 that bundle came apart.
Now you can build things you don’t fully understand. That sounds harmless at first because we all use systems we don’t completely understand. But software is different. You’re not just using it. You’re responsible for it. When something breaks at midnight, the phone rings on your desk, not the model’s.
That’s why engineers can honestly be both happy and afraid. Building got dramatically easier. Responsibility didn’t.
Those used to be tightly coupled. Now they aren’t.
Why didn’t responsibility get easier too? I think the answer is uncomfortably simple: whatever we can measure, we eventually automate.
Does the code compile? A machine checks that.
Do the tests pass? Also automated.
Will this codebase quietly become impossible to maintain six months from now? Nobody at the conference claimed they knew how to measure that—not even the people building the models. One speaker put it better than I can: code is provable, software isn’t.
Everything we don’t know how to prove eventually lands back with a human reviewer. As machines generate more software, that pile gets larger. That’s a strange kind of productivity gain, and I’m not sure we’ve fully understood what it does to engineering careers.
Once I started looking for it, the same pattern showed up everywhere.
One speaker described the progression over the last year almost casually: first I ran out of tokens, then I ran out of compute, and then I hit the wall behind both. I can’t simply add more attention.
Another speaker, talking about something completely different, arrived at almost the same conclusion. Their bottleneck wasn’t inference anymore. It was the human ability to understand what they were building. You send someone a pull request and eventually they look up and say, “I don’t know, man.”
That may have been the most honest code review of 2026.
Tokens got cheap much faster than I expected. Compute is something you rent. For a surprising number of tasks, even the choice of model matters less than it did a year ago. The thing that stubbornly refuses to scale is judgment. Nobody has figured out how to manufacture another senior engineer’s attention.
An agent that writes ten pull requests hasn’t really eliminated work. It’s changed the work. Instead of writing one implementation yourself, you’re deciding which of ten plausible implementations deserves your name.
The industry’s answer this year was verification. Move checking into the development loop instead of bolting it on afterward.
That feels directionally right. It’s also, admittedly, the problem we’re building around.
But verification doesn’t remove the bottleneck. It protects it. The bottleneck always sits wherever measurement ends. Good verification filters out the obvious failures so human judgment gets spent on judgment instead of checking whether someone remembered to run the tests.
At first I assumed this was temporary—that eventually we’d figure out how to measure maintainability too, automate it, and move on.
Maybe we will.
But even if that happens, the frontier just moves. Something else becomes difficult to measure, and that’s where human responsibility shifts next. The unmeasurable keeps moving, and increasingly that’s where software engineers spend their careers.
That’s why I’ve come around to thinking the afraid engineers are seeing the situation more clearly.
They’re not afraid because the tools are weak. The tools are astonishing.
They’re afraid because responsibility has become detached from understanding, and they can feel the distance growing. That’s a reasonable thing to worry about.
One study mentioned during the conference found something even more concerning. When people received incorrect answers from AI, they didn’t merely accept them. They became more confident in them.
Borrowed confidence may turn out to be the defining failure mode of this era.
Not using AI.
Borrowing certainty from it.
So that’s what mid-2026 felt like from inside.
People really were happier. Building software has become dramatically more enjoyable.
They were also genuinely worried, and not because they misunderstood the technology. They understood it well enough to see where responsibility was accumulating.
Sharad’s builders were happy confused.
This generation is happy afraid.
The confusion disappeared once people understood the wave.
The fear won’t disappear quite so easily.
Last year I said we were at the Netscape moment: protocols forming, use cases obvious, business models unformed.
This year the seven thousand engineers spent three days agreeing on how the machine should work.
The question the whole industry left San Francisco without answering is older than the machine: who signs?