Building in the Agentic Era, Part 1. By Mike
Agents have made building software a lot faster. I don't think anyone who's used them seriously still argues that. What they haven't done is take the human out of it. The time you used to spend writing code doesn't vanish. It moves, and you get to decide where it goes.
I caught myself on the wrong end of this not long ago. I was working through a spec-driven build where the agents asked me questions at every stage. Through the requirements, the design, and the first specs, I was sharp. I read every question and thought through every answer. But somewhere in the later specs, I noticed I just wanted the work to get going. I'd answered hundreds of questions by then. The agents had plenty of context, and I was playing the approval game. That's when it clicked for me that more approvals don't automatically mean more control.
On Tuesday, Rishi wrote about governance at the org level: keep it continuous, and give agents more room as they earn it. I want to come at the same problem from the builder's chair. Once agents are doing most of the building, where do the human hours actually go?
New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.
Review is the new slow part
I'm not the only one seeing this. Qodo surveyed 500 developers and 300 engineering leaders last week, and both groups put reviewing and validating AI-generated code at the top of their bottleneck list. Only 3.7% of the leaders thought their current process could hold quality as agents take on more work. I'd bet most of the other 96% already know that. They just haven't had time to fix it.
Anthropic's AI-native SDLC playbook lands in about the same place. The build runs at machine speed now, but planning, review, and release still run at human speed. Writing the code used to be the long pole. Now it's deciding what to build and checking that it got built right.
Where the approvals actually happen
Day to day, I see approvals land in two places.
The first is the plan. Sometimes that's a quick plan you hash out in a single session with a coding agent. Sometimes it's the full stack: a requirements doc, a technical design, a prototype, architecture decision records, and specs. Either way, somebody has to look at it and say yes.
The second is the outcome. Did the agents build the thing that solves the problem?
The tricky part is everything in between, and how much governance you put there. Go light and the build is off to the races, but you'll spend more time at the end approving outcomes and dragging the work back to where you meant for it to go. Go heavy and you'll catch drift sooner, but you're in the loops all day.
Make no mistake, if you're building enterprise systems, you're going to spend the time. When and where is the whole game.
How I decide how much governance
There are a lot of ways to handle this, and every company has to work out its own. For me it comes down to classifying the work before anyone starts.
I ask two things. First, what happens if we get this wrong? Is this a P0 app tied directly to revenue? Is it a major feature? Will customers feel it? Second, how fast will we find out, and how fast can we back it out? That one is really about how mature your platform and your CI/CD are. If a user hits a problem, how long until you hear about it, and how long until you can roll back or respond?
Put those side by side and you get something like this:
Fast to detect and roll back
Slow to detect or roll back
High cost if wrong
Moderate plan, strong outcome checks
Heavy plan, governance in the loops, a defined way to validate outcomes
Low cost if wrong
Light plan; let outcome checks and rollback carry it
Light plan, but fix the feedback loop before adding more agents
Most teams get the top row right. The box that bites people is the bottom right: a change that looks small, so it gets almost no planning, on a platform where nobody hears about problems quickly.
Bug fixes are a good example. It's tempting to treat every bug the same. I'd rather take a couple of minutes to classify it first. A small bug in a minor feature you can roll back quickly doesn't need much ceremony. A bug in a revenue-critical flow with slow feedback deserves a real plan, even if the fix ends up being two lines.
Both ends of the dial hurt
With too much governance, the process gets rigid. You still get gains, but your engineers get pulled into every loop and asked close to the same questions over and over. That wears people out.
That's what happened to me on that spec run, and it's the version that worries me most. Imagine a rule that a developer has to sign off on every change to every document. With a handful of agents running, that can be hundreds of sign-offs. Nobody reads hundreds of anything carefully. Eventually the person in the loop just starts agreeing, and now you're paying for governance without getting any protection from it.
Too little governance hurts in a different way. The work drifts from the architecture and the outcomes you started with, and it drifts fast. Run a long loop on a complex app with little planning and you'll spend a lot more time at the end working out the kinks. Do the same while adding features or fixing bugs on a product people already use, and you'll ship new problems and make the experience worse.
So where's the right mix? Honestly, it tends to show itself as you go. In my experience it's usually wherever the architecture or the expected outcomes are changing. That's where I'd put governance, and I'd ease off where things are stable. Addy Osmani makes a related point in his loop engineering piece: a loop that runs on its own also makes its mistakes on its own, so checking the work is still your job.
What I'm actually checking
Approving a plan takes experience. You start simple. There's a problem to solve, and the plan should lay out the best path to solving it. Knowing whether it really is the best path comes from having built platforms and applications before. That makes this a leadership problem as much as a process one. Hire people with that judgment, and give the people you have chances to build it, small ones first and then bigger ones. It's the same thing Rishi said on Tuesday about not skipping the apprenticeship.
Approving an outcome takes understanding. You need to know the problem you set out to solve and how the platform or app is supposed to behave. This is where all that planning pays you back. Did we write down use cases and user stories? Can the builder and the reviewer both use them to check the result?
One question I keep coming back to: could someone who knows nothing about the project read the plan and quickly tell whether the outcome is right? If they can't, the plan isn't done.
A checklist you can steal
Here's the short version. Copy it, change it, make it yours.
Before the work starts:
Classify it. What does it cost if it's wrong, and how fast can you catch it and roll it back?
Set your governance level from where it lands on the grid.
Write the problem down first, then the path.
Write the use cases and user stories the outcome will be checked against.
Get the plan approved by someone who's built this kind of thing before.
While the agents work:
Put governance where the architecture or outcomes are changing. Ease off where they're stable.
Watch for rubber stamps. If approvals come back fast and nothing ever gets sent back, people stopped reading a while ago.
At the outcome:
Check the result against the use cases, not just green tests.
Run the newcomer test on the plan.
If you want to go deeper
The 2026 State of AI Code Quality Report from Qodo, where the review numbers above come from.
The AI-native SDLC playbook from Anthropic, a stage-by-stage look at the lifecycle once agents write the code.
Loop Engineering by Addy Osmani, on designing the loop instead of writing the prompt.
Running a Software Factory Efficiently at Uber Scale from Uber Engineering, on running managed agents with human review and tracking quality for each one.
I'm curious where other teams have landed on this. Where is your team spending its approval time today: on the plan, in the loops, or at the outcome? Hit reply and tell me. The best answers will turn into future issues.
This was Part 1 of Building in the Agentic Era. Subscribe free to get the next part in your inbox. You can also reply to any issue, and the best questions become future issues.
The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.
Till next time,