The Criticality Shift, Part 2.

In the first article in this series, I introduced the concept of software criticality, a framework for why talking about "software" as one thing makes no sense, particularly in the context of AI.

A bash script is not a todo list app is not Skyrim is not a Mars rover is not AWS.

These things are not the same. And at the same time, AI is simultaneously: creating a massive opportunity in low criticality software that never made economic sense to build before, and eating its way up the ladder, slowly being able to create more and more high criticality software.

This is affecting people in real ways.

Specifically, it's impacting software developers: their processes, their identities, and their sense of what it means to be good at their job.

The economics of producing software are changing. And any time the economics change for creators, it hits the psychology of the industry and the people in it.

I believe deeply that the devs who get on board here will be even more valuable. But the road there is going to be uncomfortable, and the craft will change. It always does when the tools change. As Peter Steinberger put it: "It's okay to mourn our craft. And a part of me very strongly resonates with that because in my past I spent a lot of time tinkering, just being really deep in the flow, cranking out code, finding really beautiful solutions. And yes, in a way it's sad because that will go away. But you can get a similar state of flow by working with agents and building and thinking really hard about problems. It is different. And it's okay to mourn it, but that's not something we can fight."

This piece is about that collision, what it means for developers, and what it means for how we build software from here.

The developer hour. The entire dev process was built to optimize a single scarce resource: the developer hour.

All the tools we know and love—code review, pairing, PR workflows, backlog grooming, standups—exist because dev time has been precious.

Historically, it's really hard to find good developers; they have been expensive, thus every hour of their time is super valuable.

So we built systems to make great use of the dev hour. We planned carefully so developers wouldn't build the wrong thing. We wrote detailed specs so they wouldn't have to guess. We reviewed each other's code to catch mistakes early, because fixing bugs later was expensive. We coordinated constantly, because miscommunication meant wasted effort, and wasted effort meant wasted money.

This wasn't bullshit process, it was rational. It was the correct response to the constraints of the system. Just like Agile and Lean emerged as process frameworks to optimize around particular constraints, every piece of developer workflow was shaped by the reality that developer hours were the bottleneck.

That was just the way it was. Until it wasn't.

The world of AI coding tools has broken this constraint. People are building in hours what it used to take whole sprints. Many of them aren't even devs. Whole working applications are standing up in a day, getting feedback, getting torn down, and getting rebuilt.

The constraint that shaped every process we know has evaporated. Every process and every tool was built around a constraint that no longer holds. And that is a big, big deal.

This change happened fast.

So if that's true, and the constraint has changed, that means all the old processes are up for question. At best they're overhead. At worst they're drastically slowing things down.

And this is something we are seeing in many organizations. Developers are waiting for PR reviews when the code is written faster than the review, for specs when they could have built the thing and gotten feedback, and for questions to be answered on Slack when they could have built some options and instead asked "which one?"

Devs who are moving fastest aren't collaborating around documents and specs, but instead are collaborating around working software. They build something, show it, get a reaction, and adjust or throw it away. The entire feedback loop collapses from weeks to hours.

Christensen's Innovator's Dilemma tells a specific story: established companies don't fail because they're bad at what they do. They fail because they're too good at it. They keep improving for their most demanding customers, overshoot what the broader market actually needs, and get eaten from below by something cheaper and "worse."

Human developers are trained to think about scale, maintainability, and edge cases. All the principles: DRY, extensive unit testing, strong architectural patterns. You absolutely need this for a high-criticality system like a banking ledger or a massive database, but when a developer applies that same framework to a simple, low-criticality workflow, they overshoot. They build way more than the situation calls for.

And they do this because they are craftspeople. They have been taught that "messy" or brute-force code is bad, shameful, or amateurish.

When a traditional software engineer looks at code an AI agent spit out in one shot, their instinct is often to scoff. It might be redundant, it might not scale, and it might lack elegant architecture.

AI code generation enters the market at the exact bottom of the criticality spectrum. It thrives in the long tail because it optimizes for speed and zero marginal cost, not elegance or scale.

For a user who just needs a problem solved right now, a messy but functional Python script generated in ten seconds is infinitely more valuable than a perfectly architected SaaS application that costs $50 a month and takes three days to configure.

AI most likely won't stay at the bottom. Agentic systems are already past simple scripts. They're coordinating multi-step workflows, debugging their own errors, and managing state. The "inferior toy" eventually stops being both inferior and a toy.

It pains me to say this, because I love craft. And there are times when it's valued and will win. But if you give the average consumer the option of buying a $40 chair at IKEA vs a $1500 lovingly hand crafted chair, most are gonna choose that IKEA chair. There's still room for both. But most people just need something to sit their asses on.

What makes this hard for developers specifically is that the instinct to be cautious, to build things right, and to worry about what happens when something breaks... that instinct isn't wrong. It was trained by decades of real experience where bugs were expensive and building was slow. It was the correct instinct under the old constraints.

It's just that the constraints changed. And an instinct that was adaptive is now, in a lot of cases, holding people back.

Let's try a thought experiment. Here are two scenarios:

Case 1: AI continues to climb the criticality spectrum. The tools keep getting better. What's possible today with agentic coding expands into more complex systems, higher reliability requirements, larger scale. In this world, developers who haven't adapted to working with these tools are progressively squeezed. The work they can uniquely do keeps shrinking. Adaptation isn't optional.

Case 2: AI freezes exactly where it is right now. No more improvement. The models plateau. The tools stop getting better. Even in this world, a massive new category of software just opened up. Low-criticality, high-value, bespoke tools and applications that weren't economically feasible to build before. And that software is being built right now, by people using AI tools, at a pace that traditional development can't match.

In Case 1, developers must adapt and build new processes to stay relevant. In Case 2, a giant new opportunity exists and developers are in the best position to seize it.

Either way, the answer is the same. Even frozen at today's capability, the world is already different enough that standing still isn't an option.

And so far we are NOT in Case 2. Most devs I know made fun of the recent C compiler project Anthropic did. Yes it was a stretch. But could it do that last year? Hell no. And here we are.

Last year these tools struggled with basic tasks. They aren't struggling any more.

At the end of the day one thing matters: outcomes. Code that doesn't fall down is valuable. Code that solves my problem sooner is more valuable. People put up with stuff that falls down, so long as it solves a pain point at least somewhat well. They don't put up with stuff they have to wait for when someone else will get it to them sooner.

Right now, the most interesting work isn't happening at the code level, but rather at the harness level: the software that controls and guides the LLM tools you use, and the infrastructure that lets you go faster, produce better architecture, and maintain quality without slowing down. All the clever people I know are building tools to help them use these tools. That's where the leverage is.

New processes are emerging whether we like it or not. The ones that work won't look like the old ones, because the constraints are completely different. Just like Agile and Lean emerged to optimize around their era's constraints, something new is forming now.

It's still very early. We don't know how everything will shake out. But whatever is happening is real and impacting all of us.

That's the landscape. Next time: what to actually do about it. New processes, new skills, and what businesses need to understand about the teams they're building.