Code Became Cheap. Attention Became Expensive.

Engineering management has never looked easier and never been harder. The toil that used to fill an EM’s week is now handled by AI, so from the outside the job looks lighter. What is left is the part that was always the real job: the decisions nobody will let software own. And because execution got cheap, those decisions arrive faster than we can comfortably make them.

The teams that compound in this environment are the ones that changed their central question. Not “how fast can we build this” but “is this the thing we want, and how would we know”. Teams that use agents to type faster inside a process designed when code was expensive get something else entirely: more artifacts to be confused by.

That inversion creates work that will never show up in a demo. When everyone’s output multiplies, someone has to decide what the organization will not pay attention to. Filters and deciding mechanisms need to be designed as systems, not carried by whoever feels heroic that quarter. This work rarely appears on a roadmap and it’s ours to build anyway.

Meanwhile the boundary of who builds software has dissolved. A product manager can now show up with a working prototype instead of a PRD. So can a designer, a support lead, or anyone with an idea. This is genuinely good: a running prototype settles arguments that forty pages of a doc never could. It is also genuinely dangerous, because a prototype that demos well makes invisible everything it lacks: error handling, security, scalability, operability, maintainability.

So a new problem lands on our desks. We need a pipeline that converts vibecoded prototypes into production systems without rubber-stamping them and without insulting the people who built them. Both failure modes cost us. One ships fragile software, the other teaches our most engaged colleagues to stop bringing ideas.

And one thing worth saying plainly: getting the right people in the right places matters more, not less, when each person’s output is amplified. Amplification has no opinion about direction. It scales good judgment and bad judgment with equal enthusiasm.

None of this requires waiting for permission. It requires treating our own management practice the way we treat production systems: as something to redesign when the constraints change. The constraints changed.

I will be writing more on this in the coming weeks, mostly the practical side of running an engineering team in this new shape of the SDLC. If any of the above matches what you are seeing in your own org, I would genuinely like to hear about it.