From Babysitting AI to Developing the Factory
Babysitting agents leaves little room for the troubleshooting that engineers enjoy. The harder challenge is developing a system that needs less babysitting.
Insights Topic
Generating code is nearly free now. Turning intent into a trusted change and a real customer outcome is not. The lifecycle has to be built for both.
This is the delivery and engineering side of my AI work: how to get past both the vibe-coding slot machine and the burnout of babysitting ten parallel agent threads, how to treat your prompts, skills, and workflow rules as source code, and how to extend your lifecycle past the pull request to real product outcomes. For the enterprise and business-wide side of the same problem, see the companion topic below.
Start here · Cornerstone read
Next Insurance broke its product development lifecycle into agent skills while keeping sprints, roadmaps, and Jira intact. Why changing who writes the artifacts comes before redesigning your process.
Read the full article
Current POV · Product, Factory, Company
Moving from vibe coding to a trusted engineering loop is step one. The harder loops are turning code into product outcomes, developing the factory, and developing the company.
Operating model · Team shape & coordination
Why the pitch to flatten into tiny one-to-three-person teams overnight fails when teams are still aligned to systems, and how to actually flip the coordination pyramid.
Insights Database
Browse the complete archive of articles and case studies related to agentic development lifecycle.
Babysitting agents leaves little room for the troubleshooting that engineers enjoy. The harder challenge is developing a system that needs less babysitting.
Vibe coding can come full circle through a trusted engineering loop. Then the challenge expands: useful product outcomes, improving the factory, and helping the company work better.
Next Insurance broke its whole product development lifecycle into agent skills and deliberately kept sprints, roadmaps, Jira and the role split. Why authorship is the first thing to change in an agentic rollout, and how you know when the process change is finally due.
Shay Mandel's teams turned every step of product development into a skill an agent runs, then told two hundred people to stop writing the artifacts and start fixing the thing that writes them. His account of what worked, what the agents get wrong, and what they deliberately did not change.
Why I pivoted from Scaling with Agility to Scaling AI from Activity to Impact. Agility is the "Powered by Intel" inside the AI-Native organization, and the lessons from scaling it are what turn AI ambition into impact.
AI agents make it remarkably easy to start and generate work. Here is how I would use WIP, work item age, cycle time, and throughput when code review and customer learning cannot keep up.
Does your board stop at deliverable and output, or does it go towards outcome: the changed behavior for somebody? Most boards stop at deployed, and that is what teaches people deployment is success.
Flow metrics aren't useful because metrics are good. They're useful when important work is slow, blockers show up late, and forecasts keep missing. Agentic development made all of that sharper, and your agents can be taught to watch for it.
Starting numbers for active work and queues, covering solo and multiplayer spec-driven development, pod topology, flow buffers, and replenishment cadence.
The real magic of spec-driven-development frameworks is how they make the code of the system running the agentic/human development lifecycle explicit, and opens the door to evolving this code to coach agents and humans towards more effective choices much more effectively than ever before.
Token-maxing mandates produce AI theater: lots of activity, no change in impact. Invite people instead of inflicting AI on them, and ask what becomes possible once engineering stops being the bottleneck.
The flattening pitch assumes your teams can deliver an outcome alone. Most cannot. Agents make them faster, not necessarily independent. Here is how agents CAN help you accelerate the descaling process
Don't ask whether you still need Sprint Planning. Ask whether you still have an alignment problem. Separating the mechanism from the capability is the whole game right now.
Spec-driven development points an agent at a deliverable. Goal-based loops let you point it at a condition instead: the question is whether the condition you picked is an outcome or just green tests.
You can 10x engineering and still not 10x the business. AI creates speed, not automatic value, and if engineering was not the constraint, that speed just moves the congestion somewhere else.
Practical patterns for using AI across the product development flywheel: from discovery and validation to faster build cycles and better feedback loops.
Turning AI capability into impact takes work at three levels: the product, the software factory, and the company around them.
Assess your agent harness for outcome orientation, trustable output, and continuous improvement. Extend spec-driven development through the product lifecycle.
AI made starting work nearly free. It did not make finishing free: deciding what is worth doing, reviewing, shipping, and closing the loop still cost the same judgment they always did. So the bottleneck moved, and what you get is not more impact but a pile of half-finished threads. I built a personal kanban board for my own AI coding threads and the first thing it showed me was the size of my own pile.
A Lean sensei could tell an organization had stopped improving by looking at one document. In spec-driven development your harness is that document, and the measurement takes one git command.
Most of your scaling apparatus is now optional. Your first principles are not. A companion for leaders running SAFe while adopting AI-native, spec-driven development, and trying to tell the difference.
Is Scrum still relevant when agents write the code? Yes, and more than before, provided you are willing to customize it. A companion to the Scrum Guide walking the accountabilities, events, artifacts, and values for a team running an AI-native, spec-driven lifecycle.
A companion to the Kanban Guide for Scrum Teams for AI-native product teams. What changes in your Definition of Workflow, WIP limits, flow metrics, and Scrum events once agents do the building, and what happens to scaling when the old dependencies start dissolving.
AI agents write code faster than ever, but the bottleneck moved to human decision latency and review capacity. Here is the operating model that closes it: roles, rituals, and metrics.
Your PR queue tells you what is waiting, not how spec-driven agentic work is actually flowing. A draft-first Git flow gets real flow metrics out of the metadata you already have.
When AI coding raises the arrival rate of pull requests, telling reviewers to work faster is the wrong move. Fix reviewability and end-to-end flow instead.
Why the rise of Forward Deployed Engineering is the next agility problem, and how to scale "unreasonable agility" without it eating itself.
Spec-driven development looks like a step backward if you read it as requirements theater. The better frame: the spec is a higher-level language for intent.
Spec-driven development can be a smarter way to steer AI coding agents, or waterfall with more tokens. The difference is whether the spec creates learning.
When you are running specs through coding agents, the spec is the work in progress. WIP limits are the valve that keeps agentic throughput from piling up in front of the humans who still have to review it.
AI tools promise to speed up product discovery, but do they? A close look at where AI actually helps, and where the bottleneck is still human judgment.