The bottleneck moved: product engineering without losing controlSkip to content

On this page<br>← WritingHow this was written This post is AI-generated from thoughts I wrote down, then fully reviewed and edited by me before publishing.<br>SourceSource notes (draft)<br>Skillshape-blog-post — Shape raw notes or a draft into a plain engineering blog MDX post for this site.

Writing software with coding agents is a different experience than it was a few years ago. Processes changed, ways of working changed, and the effort we put into writing and reviewing code has shifted.

In product engineering especially, we used to spend a lot of time designing features, talking to product managers, and finding compromises. Now that writing the code costs less, the real work is making the right decisions and parallelizing what can run at once.

A lot of engineers, managers, and C levels I work with have asked how I approach this and how I set up the day. One of them asked more than a year ago. I avoided sharing “my setup” until now, mostly because other people pushed me over the last couple of days.

Take this with a pinch of salt. Most of what follows is subjective, with a bit of objectivity where it earned it.

It is how I moved from the old engineering loop into product and software work where I can multiply throughput without sacrificing quality, and without losing control.

If you spend a lot of time with coding agents and throughput is flat, if skills feel like they should work but do not, if speed went up and quality went down, or if you feel you are losing control of what you are shipping, this might help you find a way through.

Disclaimer This post is entirely personal. It is my own way of working. It does not represent the company I work at, and it does not claim that colleagues or companies I work with treat this as a standard.

How we used to work

Staff engineering is its own job, and this post is aimed at software engineering and product development. As a staff engineer you can create impact by writing code or by unblocking others.

The daily shape below is still the product path most teams know.

On a web application (desktop and mobile differ a bit, embedded is another world), teams usually have some backend engineers and some frontend engineers, or a mix of full stack and product engineers.

After the ceremonies, agile or otherwise, the daily outcome was almost always the same. An engineer worked on one task, maybe two or three, followed requirements, and delivered a task, a story, or a slice of an epic.

Whether that feels familiar or not, the point I care about is simple.

On a normal day our focus sat on a small number of concurrent topics. When the work was feature development, the bottleneck was writing the code.

The bottleneck moved

At first, coding agents showed up as autocomplete that was sometimes surprisingly good and sometimes weird. We felt that was the way forward.

Slightly later, models got good at something many of us disliked doing: writing tests. Happily, we started handing that work over.

In my view, for at least a year now we have had coding agents that can manage actual work, not only the next few tokens.

Did the bottleneck go away? Not really. It moved somewhere else.

For roughly the last nine months the hype train has said that telling the agent what to do is enough for perfect execution. Reality is more mixed.

The part I believe is true is that agents are extremely good at doing what you tell them to do. The harder part is telling them precisely what you want.

Ambiguity kicks in fast. A clear idea in your head becomes a clunky implementation that barely matches what you meant.

Understanding where it went wrong can be difficult, and sometimes it is hard to recover at all.

The rest of this post is how I keep that from becoming normal, how I improve what I already have, and what I learned the hard way.

What the goal is

With AI, my goal is to figure out how the tool increases my productivity, and how to get maximum output while everything stays under control.

Whether that lands as 2x, 10x, or more is less interesting than the pattern that produces the multiplier, and the variables that raise or lower it.

We are not talking about yoloing a personal product like this blog, which took one spec with the workflow below. We are talking about enterprise scale product development.

Most of us are fine at yoloing prototypes and pretty HTML. When a large organisation and real complexity show up, “just give the agent context” is not enough on its own.

Context helps. It is not the whole answer.

Where the human stands

Something that still surprises me is how few people ask where they should take action when using AI.

I have watched a lot of people try different placements, and a lot of those approaches fail for a while. That is part of learning.

Today the human can sit in different places in the software development lifecycle:

YOLO mode: ask the agent to do something with almost no...