> ## Content Index > Fetch the complete content index at: https://contextfirst.blog/llms.txt > Use this file to discover other available public pages before exploring further. # Field notes — agentic delivery - URL: https://contextfirst.blog/field-notes-agentic-delivery/ - Published: 2026-08-23T18:22:38.000Z - Updated: 2026-08-23T21:21:02.000Z - Description: An engineering manager's job when the bottleneck moves - Author: Iheatu Chris Wogu - Tags: Field Notes, Engineering Management, Agentic Delivery, Learning Journey 2026 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](https://en.wikipedia.org/wiki/Theory%5Fof%5Fconstraints?ref=contextfirst.blog): one slow station caps the whole line. AI researchers call what happens next [constraint migration](https://doi.org/10.5281/zenodo.20768264?ref=contextfirst.blog) — 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**. The line — simplified agents Intent Generate Review Validate Deploy Where does work wait? (EM must find out) **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](https://thenewstack.io/ai-code-bottleneck-myth/?ref=contextfirst.blog) 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 | No Yes Observe queues + talk to owners Hypothesis: X is the constraint Measure batch size & dwell time Work piles up after X? Act on X — elevate, don't starve downstream **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. Accelerate generation EM research Visible: review queue Hidden: validation batch Hidden: release / deploy serial Easy to fund more review Harder to see — often the real constraint More work hits G faster **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: Identify the constraint Exploit — stop wasting it Subordinate — align other steps to its pace Elevate — automation, policy, envs Constraint migrates — research again **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 | Mechanical trust Agent volume Human scarcity Intent & architecture What green means Merge / release judgment Generate & propose CI / contracts / policy 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: agentic-framework — how do agents run? Specs as contracts Review & merge gates Repo navigation github-analysis — what does the line show? Merge vs proof pace Metric definitions Audit agent-built tools Planning — what must be true? Journey maps Integration proof Triage when proof fails EM research question | 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. EM job — agentic deliveryResearchDecideElevateRepeatWalk the queuesBatch-size questionReconcile metricsIntent & green definitionRisk vs mechanical gateTrust at the slow stationWIP aligned to capacityConstraint migratesField note the finding **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: 1. **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. 2. **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. 3. **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. Observe the line Hypothesis + measure Name the constraint Elevate that station Field note the answer Constraint moves --- 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)](https://doi.org/10.5281/zenodo.20768264?ref=contextfirst.blog) - [The bottleneck has moved (Jim Grey, 2026)](https://dev.jimgrey.net/2026/05/06/the-bottleneck-has-moved-redesigning-the-sdlc-for-ai/?ref=contextfirst.blog) - [AI hasn't shifted the bottleneck to code review (The New Stack, 2026)](https://thenewstack.io/ai-code-bottleneck-myth/?ref=contextfirst.blog) - [Harness engineering (OpenAI, 2026)](https://openai.com/index/harness-engineering/?ref=contextfirst.blog) --- --- ![Iheatu Chris Wogu](https://avatars.githubusercontent.com/u/3457705?s=176&v=4) ## About the author **Iheatu Chris Wogu** is an engineering manager focused on launch programs, honest engineering metrics, and **engineering-led, agent-accelerated** delivery — researching where work queues up when agents widen dev output, then building proof, gates, and measurement that scale. Field notes live on [First Context](https://contextfirst.blog/). Values treatise: [engineering manager values](https://contextfirst.blog/engineering-manager-values/). **LinkedIn:** [linkedin.com/in/iheatu-chris-wogu](https://www.linkedin.com/in/iheatu-chris-wogu/?ref=contextfirst.blog)