The Three Shifts That AI Created

AI changed three things about building software: who does the work, how fast decisions pile up, and how much a small team can take on.

Role Collapse

For about the last two decades, the common shape of a software organization put one engineer at the keyboard with a ring of other people around the work: product managers, designers, security reviewers, QA, DevOps engineers, legal. Each brought a viewpoint the engineer did not have, and together they held the memory of why the system was built the way it was.

Each of those roles earned its place through real competence. AI changes the economics of having them. One engineer with a capable assistant can now produce what several people used to produce together, and much faster. Measured as output per hour, that is a clear gain. It also forces a degree of Role Collapse, because the work those roles used to do now sits with one person. Code now arrives faster than the surrounding organization can react, which means it can no longer be the source of those viewpoints.

At the current rate of generation, the engineer has to supply those viewpoints deliberately, or the assistant will fill them in by default. Generating code takes a complete specification, and that has to come from somewhere. Either the engineer states it, or the assistant fills in whatever was left unsaid. The decisions get made either way, which leaves the engineer at the keyboard owning all of them, the ones made on purpose and the ones the assistant made in the gaps. The work still holds as many decisions as it ever did. Only the maker of each one has changed, the engineer or the assistant.

Time Compression

The second shift is about how fast decisions enter a codebase.

Before AI, decisions arrived at the pace of typing and meetings. People complained that this was slow. The slowness turned out to do real work. It kept new decisions roughly in step with the feedback on earlier ones.

That feedback has rarely been fast, and it has not sped up. Product validation takes weeks. Design flaws show up only after a pattern is on several screens. Security problems surface in review, or in an incident. Operational problems appear under real load. Users find things at the pace of their own work.

Writing the code sped up. An engineer with AI tools can lay down in a day what used to take weeks, and each line is a decision. So the decisions now outrun the feedback. A piece of feedback still comes back, but the code it was about is already buried under later work.

This is Time Compression: decisions enter the codebase faster than feedback on them can return.

Code written this way usually runs, which is why the problem is easy to miss. The reasoning behind it suffers. The feedback that would have tested that reasoning arrived too late to use. Change the system later, and you have to dig the decisions out, because the code around them no longer explains why they were made.

Ambition Expansion

Role Collapse and Time Compression are usually told as a productivity story: one engineer now produces what a small group used to. That is true, and it undersells the bigger change: what a small team can attempt at all.

For most of software’s history, the size of a team tracked the size of its product. Some things needed a bigger team than a small group could assemble. A medical-records system, a logistics platform, or a research tool for a million scientists took a team two people could not pay for, whatever they knew.

That is changing. A two-person team still cannot build what two hundred can, but it can now build what a much larger team could have a few years ago, and the range keeps climbing. The work worth reaching for is the kind that used to be out of range, the system a small team could not have staffed. This book is about that reach.

As of this writing, in the middle of 2026, there is a reasonable case that most companies have not caught up to this yet. They are pointing the tools at familiar work and getting it done faster. That reading is safe. It also misses the bigger change. In some places the change is being taken for job loss, which gets the cause backward: how many engineers a company needs follows how much it sets out to build, and the new reach gives it more worth building.

This follows the ordinary shape of a productivity jump. When a kind of work gets cheaper, the gain has usually gone into doing more of it rather than into doing the same amount with fewer people. Farming fell from most of the workforce to a sliver while total employment grew, and cheaper software has so far meant more software and more software jobs. Role Collapse is the early part of the adjustment, the stretch where capability arrives faster than the organizations around it can re-form. As it settles, teams and roles will likely look broadly familiar, doing more than before. The jump this time is large, so the adjustment takes longer to feel normal, and a shift this size can land unevenly along the way.

The reach is not safe by default. The same speed that lets a small team aim higher also lets it ship a large pile of code that is badly understood, hard to maintain, and ultimately unused. A small team can now make that mess faster, and bigger, than it could before. The four qualities apply on the way up the same as before, and discipline decides whether you can stand behind what you reached for once you have it.

---