Field notes — agentic delivery
An engineering manager's job when the bottleneck moves
Agents make one lane of the software factory cheap — usually generation. They do not make my job simpler. They make finding the truth harder, because everyone can point at a fast upstream metric while work still piles up somewhere I am not looking.
Agents accelerate code, tests, docs, and dashboards on the programs I lead. The work I care about as an engineering manager is not "enable AI." It is research the line, find where throughput actually stops, and change the operating model once I have an answer I can defend — not once I have a vendor slide that says review is the bottleneck.
What I publish here are field notes from that job: short, dated, anchored to git — written while I am still investigating, not after I have polished the story.
Here's what this piece covers: what the EM job becomes when agents widen the first lane, how I research where the constraint moved, what I do with the answer, and three habits I use before I invest in the wrong fix.
If you only remember one sentence: my job is to find where the line stops — then elevate that station, not the one that already looks fast.
1. The job is investigation, not acceleration
I spend time on queues, staffing, and "why did this release slip?" Agents did not replace that work. They changed what I have to investigate.
The easy story is always upstream: more PRs, more lines, more demos. The honest story is downstream: where do changes wait after they leave the fast lane? Review? Validation? A release train? A product call nobody can make? If I optimize the wrong step, I feel busy and throughput does not move.
Manufacturing calls this the Theory of Constraints: one slow station caps the whole line. AI researchers call what happens next constraint migration — the scarce step moves when generation gets cheap. I do not need the paper to see it in standup. I need it to stop guessing.
Wrong: "We 10x'd engineering — look at PR count."
Right: "Generation sped up. I am tracing where work batches before I fund another codegen tool."
That is the engineering manager job in an agentic world: researcher of the line, then designer of the fix — not cheerleader for the station that already won the headline metric.
2. How I research where the pile-up is
I treat this like a lead doing field work, not like a strategist reading hot takes. The line has visible queues and hidden ones. Review backlogs are visible. "Pending deployment" batches and manual verification everyone accepts as normal are often hidden — a point The New Stack makes well about mistaking review for the constraint when work still accumulates afterward.
My research kit is boring on purpose:
| Question | Where I look |
|---|---|
| Where do changes wait longest? | MR age, column time, release calendar |
| Where do batches grow after a step looks "done"? | Post-review queues, staging dwell time |
| Does faster output change idea → prod? | Deployment frequency, change failure |
| Who is saturated — and doing what work? | Walk the floor; ask QA, release, support |
| Do our metrics lie? | Reconcile definitions before staff meeting |
The batch-size question is the one I keep coming back to: if I speed step n, does work flow through step n+1, or does it stack there? If it stacks, n was not the constraint. Industry data backs the pattern — faster code output, flat lifecycle delivery in many orgs — but my answer has to come from my line this month, not a survey.
When generation accelerated on my program, the first hypothesis was "review." I traced batches. Proof and integration work saturated before trust scaled. The answer was not one role. It was the line was never designed for machine-speed input — and I only knew that after looking, not after assuming.
Creation is cheap. Finding where trust breaks is my job. I am not paid to celebrate the fast lane. I am paid to find the answer and change how we work once I have it.
3. What I do once I know where the line stops
Research without action is another unread doc. Once I believe I know the constraint, I run a loop I stole from Goldratt and adapted for software:
Exploit might mean: stop flooding the slow station with unverified bundles. Subordinate might mean: cap WIP until validation keeps pace. Elevate might mean: mechanical gates, shift-left validation, specs agents must meet before merge — whatever makes trust scale at the station that actually limits us this quarter.
The manager role shifts with that loop — less "unblock typing," more operating-model design:
| I spend less time on | I spend more time on |
|---|---|
| Velocity proxies that lie | Queue health and idea → prod |
| Funding the fast lane again | Elevating the station I found |
| Hero review at the end | Judgment at intent; mechanical proof at volume |
| Announcing AI adoption | Naming what "green" means in one place |
Humans on judgment. Agents on volume. Machines on conformance. That division only works if I researched which station needs elevation first — not if I copied someone else's bottleneck story.
4. Three repos — how I keep finding honest answers
I organize work across three repos because an EM who guesses from one dashboard is just doing speed theater. I need evidence I can re-check when the constraint moves again:
| Repo | Question I am trying to answer |
|---|---|
| Planning | Can we prove integration before we argue about dates? |
| github-analysis | Is throughput up — or only output? |
| agentic-framework | Do agents work under human merge authority? |
Agents help me build the instruments faster. I still own whether the answer is true — reconcile the metric, walk the journey, merge the spec. I call that engineering-led, agent-accelerated: agents accelerate the research artifacts; humans retain architecture, priority, and what counts as evidence.
This blog is one output of the same job: when I find something checkable about where the line stops, I publish a field note — one screen, git-anchored, while the investigation is still live.
5. Named pattern: follow the constraint
The phrase I reuse:
Follow the constraint — research where work waits, elevate that station, research again when it moves.
Anti-pattern: answer shopping — funding review because the queue is visible, never asking where batches grow after review.
Anti-pattern: speed theater — PR count and demo velocity while idea → prod and change failure tell the truth.
6. What I'd do as a lead
Three habits — steal one this month:
- Research before you fund. Sketch generate → review → validate → deploy. Mark where work accumulates this week. Talk to whoever owns the next station. Do not buy tooling for the fast lane until you can name the slow one.
- Ask the batch-size question. If we speed step n, does step n+1 absorb it or stack? If it stacks, your constraint is downstream. Invest there.
- Publish what you found, briefly. One field note with a date and an anchor beats a wiki nobody updates. The point is not volume of writing — it is a record of the answer while the line is still moving.
Agents widen the first lane. I research where the line stops, change the model, write down what I found. Each post here is for engineering managers who need answers, not another story about transformation.
Further reading
- Constraint migration (Zenodo, 2026)
- The bottleneck has moved (Jim Grey, 2026)
- AI hasn't shifted the bottleneck to code review (The New Stack, 2026)
- Harness engineering (OpenAI, 2026)
