The question I keep coming back to

The question I keep coming back to

A senior software architect pushed back on something I wrote recently. His public comment was short. His private follow-up was longer, and I've been turning it over for a couple of weeks.

He described a bug from earlier in his career. An operand reordering inside a function, the same calculation written two ways, silently changed whether values landed on the stack or in a register. Under specific timing conditions, that placement decision corrupted a 64-kilobyte page that another thread was actively reading. A cache poisoning failure, three layers below where any review reached, surfacing as a ghost at three in the morning.

His point: this class of failure doesn't show up in modern review. Not because the people writing the code are bad. Because the people who can see this class of failure aren't in the room anymore, and the people who are in the room have no way of knowing what they can't see.

He was responding to a piece I wrote about a senior product manager learning to build. My argument was that experience doesn't disappear when AI compresses the cost of shipping. It relocates. Permission, not capability, was the bottleneck. And the bottleneck just fell.

His response, distilled: you're cheering the new shippers. Who's checking what they ship?

That argument deserves to be sat with longer than a comment thread allows.

I've been holding it next to another image from the last few weeks. A schoolteacher in Israel, a close friend of mine for almost forty years, is building a math app for her sixth graders. The app makes percentages click for a kid who'd been staring at worksheets for months. She wrote to me on WhatsApp: my creativity is the code. I quoted that line in my closing piece because it captured something I'd been trying to articulate for two years. It still does.

The architect and the teacher are both right. That's the part I keep coming back to.

What the argument is and isn't

It's tempting to read his pushback as a defense of gatekeeping. It isn't. He isn't arguing that fewer people should build. He's arguing that something has been quietly going wrong in our industry for a long time, and the new wave of building has made it visible in ways that are hard to look away from.

His argument has a sharper edge than I gave it credit for in the comment thread. He came back to it a few days later, this time in public, replying to another reader who was talking about a cohort of students taught to fear AI by teachers who were quietly using it themselves. His addition to that conversation was a single sentence that I've been turning over since: people don't even know when they should consider it or ask for expertise.

Read that twice. The failure mode he's naming isn't a competence gap. It's a recognition gap. You can survive not knowing how the memory allocator works if you know when to flag the question and pull in someone who does. The senior engineer's actual job, the one that took thirty years to build, is less about holding the answers and more about recognizing the shape of a problem that needs an answer they don't have. That instinct is the part that takes longest to develop. And it's the part that's hardest to replicate when the people building no longer come up through the systems that taught it.

So the question I started with, where does the rigor go when it's no longer carried by the builder by default, has a second half I didn't see at first. Where does the recognition go? Who's holding the instinct that says: I need to stop, this is the kind of thing I shouldn't be deciding alone.

I want to be careful here, because it's easy for an argument like this to slide into something it isn't. The teacher in Israel is not the problem. She's the proof of concept. The question isn't whether she should build. She should, and the kid who finally understood percentages is the answer to whether she should. The question is what the systems around her owe her, and what she owes them. Those are good questions to be asking. They are not gatekeeping questions.

The thing going wrong is not that people are shipping who shouldn't be. The thing going wrong is that we've spent fifteen years lowering the floor on who can build, and we've spent the same fifteen years not really keeping up on the other side.

Frameworks, package managers, low-code, cloud abstractions, and now AI-assisted coding. Each of these layers made it possible for a wider population to ship working software. We celebrated this, correctly. More builders means more solved problems.

At the same time, systems got more complex. Dependency graphs got deeper. The supply chain became a real attack surface. The number of failure modes a careful engineer needs to hold in their head expanded faster than the number of careful engineers being trained to hold them.

For a while, you didn't notice. The systems mostly worked. The bugs that surfaced were patched. The people who had been in the field for thirty years kept catching the worst of it.

And then someone made a 3 a.m. call.

Here's the part that surprised me when the architect kept writing. He didn't trace this to AI. He traced it to 2007. Somewhere around then, in his account, the industry quietly changed the contract. Engineering used to be consulted during design. Then, in stages, it became something you called after release, when something had already gone wrong, to find out what the heck happened. Two decades of that drift left large segments of the industry without the muscle memory for the failure modes that show up below the test layer. AI didn't break this. AI revealed it. The new wave of building is the accelerant on a fire that's been burning slowly for a long time, in rooms most of us never walk into.

That reframes the whole question. The recognition gap isn't a side effect of letting more people build. It's a condition the industry was already in.

What changes

For most of my career, the people closest to the work were also, by training and necessity, the people closest to the rigor of the work. Senior engineers caught the cache poisoning bugs because they had earned the right to be in the room when the design happened. The discipline lived inside the same people who lived inside the work.

What changes when the people building are not the same people who were trained in that discipline? Not better or worse. Different. A teacher building a math app. A salesperson shipping a browser extension. A product manager pushing to a company repo for the first time. None of them are wrong to be building. All of them are doing things that, until very recently, were structurally impossible for someone in their seat.

But the rigor that used to be implicit in who built it is no longer implicit. The discipline didn't disappear. It just stopped being co-located with the builder.

And the recognition, the instinct to stop and ask, didn't transfer with the tools.

What I don't believe

I don't believe the answer is to slow down. The market has already decided. The shippers will keep shipping, and the floor on who can ship will keep dropping. That's not a trend you reverse by writing a sober article about it.

I don't believe the answer is to add more humans to the review queue. The senior engineers I respect most are already overcommitted. Asking them to review more code from more builders is exactly the wrong use of their time. They are the most expensive verification resource we have, and using them as a check on everything that ships is how you guarantee they stop having time for the work only they can do.

I don't believe the answer is to assume AI will handle it. The senior architect who DM'd me is right that current AI cannot catch the kind of failure he was describing. Some of the most dangerous classes of bug are exactly the ones that require decades of pattern recognition to see at all. Pretending otherwise is the kind of false confidence that produces the next 3 a.m. call.

And I don't believe the recognition gap closes on its own. Tools can prompt for a checklist. They cannot teach an engineer to feel, in their chest, that something is wrong before they can articulate what.

What I do believe

I believe the senior engineers in our industry are pointing at something the rest of us would be wise to listen to. Not because they're against the new builders. Because they've been carrying a quiet load for a long time, and the new building rate makes the load impossible to hide.

I believe the most interesting work in the next few years will happen at the intersection of two questions that the industry has been treating as separate: how do we let more people build, and how do we make sure what gets built can be trusted.

Those aren't opposing questions. They're the same question. You don't get the benefits of one without solving the other. The conversation that treats them as separate, builders on one side, gatekeepers on the other, was always going to age badly.

I'm in that intersection a lot these days, talking to people on both sides of it. I don't have a clean answer yet. But I'm increasingly convinced that the people who are going to matter most in the next chapter of software are the ones who can hold both questions in their head at the same time. The ones who can build fast and know, in their gut, when to stop and ask.

The senior PM I wrote about is going to keep building. He should. The teacher is going to keep shipping math apps for her students. She should. The architect who DM'd me is going to keep being right about the failure modes nobody else can see. He should too. None of those three things contradict each other. The work is figuring out what we owe each of them, and what they owe each other, in a world where they're all in the room.

The shippers will keep shipping. That's settled. The interesting question is what we owe on the other side of the equation, and how we pay it before it pays us.

That's where I am. Still turning it over.