From What Code to Write to What to Build

Over the last 20–25 years of writing software, I’ve seen plenty of debate about the software development lifecycle. From waterfall to agile, we’ve kept revisiting how to organize the work, manage uncertainty, and get software out the door.

Now AI is changing how much of that work we do ourselves. Between the models and the coding harnesses around them, what feels normal today was far from possible more than a year ago.

Working with these tools, I’ve felt the change before I could clearly articulate it. Anthropic’s AI-Native SDLC playbook helped put words to it: when implementation gets dramatically faster, the surrounding stages become the bottlenecks.

Their diagram captures this well. The build phase shrinks, while planning, review, and deployment still take time.

Diagram from Anthropic’s AI-Native SDLC playbook.

There’s room for AI throughout that process. I particularly like the idea of combining deterministic checks with steps that need interpretation: tests and scripts enforce known rules, while an agent investigates a failure or reviews a change in context.

But the most transformative part for me is still writing code. As the distance from spec.md to a working implementation gets shorter, more of my attention moves upstream.

From what code to write to what to build.

Deciding what to build was always hard. The cost of implementation often limited how many of those decisions we could act on. As that cost falls, choosing the problem, setting the scope, and knowing whether the result is useful take up more of the work.

Getting the code written is becoming easier. Deciding what deserves to become software is becoming the bottleneck.