A Redistribution of Code Ownership

For years, non-engineers had to get their ideas through an engineer just to move a button, change some copy, or fix a small bug. That made sense when code changes were slow and only engineers could touch the codebase. The article argues that both of those assumptions are starting to fall away, and the way cross-functional teams work should change with them.

The old workflow was built around heavy upfront planning. Product managers and designers would write detailed specs, line up estimates, get sign-off, and hand everything to engineering. Engineers would build to the spec, then the team would come back with fixes once the product existed. That process was partly about control, but mostly about cost: if the build was expensive, people wanted to know exactly what they were buying.

The newer version is looser at the start and tighter at the point of change. Estimates are cheaper because agents can do much of that work. Specs can stay rough. Engineers still own the build, but they focus on the important parts and let agents handle the rest. Then PMs or designers can open the branch in their own dev environment and use an agent to polish the front end or make small adjustments themselves. Engineering reviews the result and merges it.

That shifts the bottleneck. Instead of every tiny tweak going through a middleman conversation, the change can be made directly in code and communicated through a pull request. The author says this worked well with a couple of PMs who also designed, especially for small changes where the overhead of asking an engineer outweighs the value of involving one earlier. One front-end-only feature even proved useful during an incident because it had already been built by a PM in response to a customer request.

The idea could extend beyond product and design. Analysts might add events. QA might fix bugs they find. Copy editors might change text. But none of that works unless the codebase is ready for it. The stack has to be opinionated and consistent, the dev environment has to start with one command, integrations need to be mocked, and nothing there should be able to touch production. Just as important, the people involved have to actually want this arrangement. Otherwise engineering gets stuck cleaning up everyone else’s agent-generated code, which is a funny way to save time.

What the piece is really asking for is a redistribution of ownership. Engineers still review, stabilize, and keep things maintainable. But they stop being the mandatory courier for every small change. That’s less romantic than the old gatekeeping model, and probably more useful.