I’ve reviewed a lot of pull requests in my career. I know what that feels like: line by line, looking for the bug, the missed edge case, the abstraction that won’t survive contact with the next requirement. So I noticed the difference immediately when I sat down to review hours of unattended work by an AI agent. This wasn’t that. I wasn’t reading a diff. I was looking at the outcome of the work and asking a different question entirely: is this right, and would I stand behind it? Somewhere in that moment I realized my job had quietly changed, and I don’t think it’s changing back.
Recently I participated in an internal AI accelerator program where we built an application architecture around an agentic loop — an AI system that takes a goal, plans its own steps, executes them against a defined set of tools, checks its work, and keeps going until the goal is met. Long-horizon tasks, not chat turns. And that capability is what enabled us to rapidly prototype directly in the product: an agent that can carry a goal across hours of work can carry a prototype from idea to running in the application.
Two constraints made this more than a science project. First, everything had to run inside our existing governance and privacy guardrails. No exceptions, no “we’ll add compliance later.” Second, the accelerator only counted as a success if it produced a deliverable with real business benefit. Not a demo or a hackathon toy — something a stakeholder would actually use.
We hit both constraints, and the experience changed how I think software will be developed going forward. Here’s what we built, what the guardrails taught us, and what I think it means.
What We Actually Built
I’m going to describe the architecture at the pattern level rather than naming specific models or frameworks. Partly that’s discretion, but mostly it’s because the pattern is the durable part. The vendor landscape will look different in six months; the loop won’t.
The loop works like this. A goal goes in — the kind of work that would take a developer days. What made our version different is what that goal looked like: not a ticket or a technical spec, but a business goal, with the application’s source code supplied as context. The agent worked out the rest itself: decomposing the goal into steps, executing them against a deliberately limited set of tools we gave it, evaluating its own output against the definition of done, and iterating. Human checkpoints sit where decisions have real consequences rather than at every step.
If you’ve used AI coding assistants in a chat workflow, the contrast is the point. In a chat workflow, you drive every iteration. I wrote about that cycle in my post on GenAI prompting — write the test prompt, get the implementation, refactor, repeat. It works, but the human is the loop. An agentic architecture takes that same cycle and runs it itself, over hours, across dozens of steps. The human moves from the driver’s seat to the design and review seat. You stop writing the iterations and start designing the system that iterates.
The rapid prototyping piece deserves a mention because it’s the part that would have terrified me a few years ago: we could stand up a working prototype inside the actual product, not a sandbox that sort of resembles it. What made that acceptable instead of reckless is the subject of the next section.
The Guardrails Were the Architecture
The industry framing on this topic is consistent: governance and privacy controls are the things slowing AI adoption down. Wait for legal, wait for security, wait for the guardrails to loosen. Our experience was closer to the opposite. The guardrails didn’t constrain the design. They were the design.
Privacy boundaries defined the tool surface. The agent couldn’t have unrestricted access to anything, which meant we had to decide precisely what it could touch and through what interfaces. Every tool we exposed was a deliberate choice with a defined scope. That forced a clarity we would never have imposed on ourselves voluntarily.
I’ve seen this dynamic for years in ordinary engineering — constraints produce better interfaces — but I’ve never seen it as starkly as here. An agent with access to everything is an incident report waiting to be written. An agent with a carefully scoped tool surface is a system you can reason about.
Governance defined the checkpoints. The places where a human had to review and approve weren’t bolted on to satisfy a policy. They turned out to sit at exactly the points where the agent most needed judgment injected — the consequential decisions, the outputs about to touch something real. The approval gate and the quality gate were the same gate. We didn’t design it that way because we were clever. We designed it that way because we had to, and then discovered it was correct.
The tradeoff was real: working inside the guardrails was slower at the start. Scoping tool access takes real work. Getting the checkpoints in the right places takes iteration. But it’s front-loaded work, and it’s the entire reason we could prototype in the product without anyone losing sleep. The teams moving “fast” without this discipline aren’t skipping the work. They’re deferring it to the incident.
So my advice to other engineering leaders is this: if you’re waiting for governance to get out of the way before trying agentic approaches, you have it backwards. Design to your guardrails. They’re your requirements. And they’re better requirements than “move fast.”
Validation: A Deliverable, Not a Demo
The rule we set going in was simple. The accelerator succeeded only if it produced something with measurable business benefit. For us, that turned out to be velocity itself: six product-level proofs of concept, built inside our actual application, in a matter of hours. Not mockups, not slideware — working prototypes running in the product, inside the guardrails, each one demonstrating concretely what was possible. The business benefit had less to do with writing more software than with answering more questions: six prototypes meant six business questions taken from idea to evidence in the time we’d normally spend debating one. Instead of speculating about what an agentic approach might someday do for us, the business could look at six real options running in the real product and decide which ones deserved investment.
Something else changed that I didn’t fully anticipate: the tone of the conversation with the business. When a stakeholder is looking at a working prototype in the actual product, the discussion stops being “do we think this will work?” and becomes “we’ve seen it work — should we invest further?” Trust stopped resting on promises and roadmaps and started resting on evidence. I’ve sat through a lot of years of the first kind of conversation. The second kind is better.
That rule shaped the build more than any technical decision we made. When the bar is “a demo,” you optimize for looking impressive. When the bar is “a stakeholder uses this,” you optimize for being trustworthy. Those goals produce different systems. The agent’s output had to survive contact with people who didn’t know or care how it was made, which meant vague success criteria weren’t an option.
In practice, validation looked a lot like test-driven development at a higher altitude. Before the loop ran, we defined what “correct” meant for the deliverable — explicitly, in terms someone could check. Then the agent’s work was measured against that definition, not against a vibe. The validation criteria played the role tests play: write the definition of done first, then make the loop satisfy it. If you’ve internalized red-green-refactor, this will feel familiar. The cycle didn’t disappear. It got promoted.
Agentic content has a credibility problem, so I’ll be precise about what I’m claiming. I am not saying agents work everywhere. I’m reporting that one worked here, on this class of task, under these constraints, with this result — a smaller and, I think, more useful claim than the demos make.
What This Changes About How Software Gets Built
I came out of the accelerator with a handful of shifts I now actually believe, having watched them happen on a real team with real constraints. I’ll state them as specifically as I can, because sweeping predictions about software are always wrong in the specifics.
The engineer’s job moves up a level. Less time writing code; more time designing loops — decomposing goals, defining tool surfaces, placing checkpoints, writing validation criteria. That’s still engineering, and it’s more architectural than what most of us spend our days on today. The skill that mattered most on the accelerator team wasn’t typing speed or framework knowledge. It was the ability to specify a problem precisely enough that a system could pursue it unattended.
Architecture matters more, not less. This one surprised me. The agent’s input was a business goal plus our source code as context, which means the quality of that source code conditioned everything the agent did with it. A well-factored system with clear boundaries is a system an agent can extend sensibly. A tangled one invites the agent to tangle it further, at machine speed. Cheap implementation doesn’t make architecture cheap; it makes the cost of poor boundaries visible in hours instead of quarters.
Specs and evals become first-class artifacts. By evals I just mean the written criteria an agent’s output gets checked against. The agent executes against whatever definition of done you give it. A vague requirement used to cost you a sprint before anyone noticed. Now it costs you instantly and visibly, because the loop optimizes for exactly what you asked instead of what you meant. The spec starts to behave like code: it runs, it fails visibly, and it gets debugged. The people who write precise specs and validation criteria become the leverage points on a team. We’ve said “requirements matter” for decades. Agentic development is the first time I’ve watched the feedback arrive the same afternoon.
The bottleneck moves from writing to reviewing. When generation is cheap, judgment is the scarce resource. I’ve written before about what I look for when hiring — the ability to think through unfamiliar problems and the drive to ship. I’d now add a third thing I always undervalued in that post: taste. The ability to look at plausible work and say “this is wrong, and here’s why.” That was always a senior skill. Now it’s the job. And reviewing is only where the constraint lands first. Technology rarely removes bottlenecks — it relocates them — and I’d expect this one to keep moving upstream, into problem definition, prioritization, and deciding what to build at all.
Prototyping compresses, which changes what’s worth trying. When a working prototype costs hours instead of weeks — we built six in less time than a typical sprint planning meeting cycle — the economics of “let’s just find out” change. More ideas get tested. More bad ideas die cheap, before anyone gets attached to them. That’s a portfolio-level change in how an engineering organization spends its time, not just a speed boost, and I don’t think most planning processes have caught up to it yet.
What doesn’t change: the fundamentals. I made this argument in my career advice post and the accelerator only strengthened it. You cannot review what you don’t understand. Every shift above raises the value of knowing what correct looks like — in code, in architecture, in data. The fundamentals aren’t becoming optional; if anything, they’re becoming the differentiator.
Step back from the individual shifts and a larger one comes into focus. For decades we’ve organized software work around the assumption that implementation is expensive — requirements were costly to change because code was costly to write. Agentic development breaks that assumption. When implementation gets cheap, the scarce resources become judgment, business understanding, architectural clarity, and alignment on what’s worth building. Put differently, AI changes the economics of learning. An organization that can go from idea to evidence to decision in hours will out-learn one that takes weeks, and I suspect that gap will matter more than any difference in raw engineering velocity.
Where I Think Team Shape Goes
Everything in the last section I watched happen on a real team. This next part is speculation — but it’s the speculation I keep coming back to.
If you’ve read Team Topologies by Matthew Skelton and Manuel Pais, you know the stream-aligned team: a small, cross-functional group owning a slice of the product end to end, with platform teams underneath reducing their cognitive load. It’s the sanest model for organizing software work I’ve encountered, and it’s roughly where modern engineering organizations have been converging.
What I think shrinks is not the whole team but something more specific: the smallest unit capable of taking a business idea to validated evidence. Platform engineering, SRE, security, operations, and data teams don’t disappear. The unit of discovery is what changes — and I think it becomes a pair: an engineer and a business domain expert, working side by side, rapidly prototyping directly in the product. The engineer designs and supervises the agentic loop. The domain expert supplies the things the loop can’t generate: what’s actually worth building, and what “right” looks like to the business. The pair’s real output is less the prototype than the answer it produces: does this idea deserve further investment?
During the accelerator, the moments that felt most like the future weren’t engineer-plus-agent. They were engineer-plus-domain-expert-plus-agent, with the domain expert’s judgment counting for just as much as the engineer’s.
The mechanism that makes this pair safe at production speed already exists: feature flags and A/B testing. Prototype behind a flag, expose it to a slice of real users, measure, then roll it forward or turn it off. It’s the same discipline that made our guardrails work — small blast radius, cheap correction — applied to rollout. Six POCs in a few hours is impressive inside an accelerator. Flags and experimentation are what turn that velocity into something you can do safely, every week, in production.
What this model doesn’t eliminate is the platform. If anything, the pair leans harder on Team Topologies’ platform teams than today’s squads do. The agentic infrastructure, the guardrails, the tool surfaces, the flagging and experimentation systems — someone has to build and own that paved road, because the pair certainly isn’t stopping to build it themselves. The unit of discovery shrinks because the platform absorbs the complexity, not because the complexity disappears.
I’ll be upfront about the size of this claim: I haven’t run an organization this way. There are unresolved questions: who hardens the winning prototypes for the long haul, who carries on-call, how quality ownership works when discovery and hardening sit with different people. But the direction feels right to me — smaller units, closer to the business, prototyping in the product, protected by flags and experiments rather than by process. The org chart follows the economics eventually. It always does.
The Honest Cost
If I stopped here, this would read like every other agentic post: architecture, success story, bold predictions. So let me tell you where it hurt.
The loop didn’t break down dramatically. I don’t have a spectacular failure story to tell you, and I’m not going to invent one. What I do have is this: we had to redirect the agent’s planning from time to time. That was the consistent pattern. On long horizons, the plan would start to wander — the agent confidently pursuing something adjacent to what we’d actually asked for — and a human had to step in, point at the goal, and get it back on course.
Each individual redirection was small. Collectively, they were the strongest argument for the checkpoints, because an unattended loop compounds its own drift: the further a plan wanders before someone looks at it, the more work gets thrown away. The checkpoints earned their keep not by catching disasters, but by keeping the cost of correction small.
The review burden is not free, and nobody talks about this part. Reviewing hours of agent work is a different skill from reviewing a pull request. A PR is a diff with a narrative. Agent output is a destination, and you have to reconstruct whether the journey was sound. We were not good at this on day one. We got better by demanding the agent show its work — intermediate artifacts, decisions, evidence — which, not coincidentally, is the same thing I’d ask of a developer.
There are tasks I would not hand this architecture yet. Anything where the definition of done resists being written down. Anything where a subtle error is expensive and hard to detect at a checkpoint. Anything touching our most sensitive boundaries, guardrails or no guardrails. Being specific about that line is, I think, what makes the enthusiasm in the rest of this post worth anything.
And one question I don’t have a full answer to: if agentic loops absorb the work junior developers used to learn on, where does the next generation of judgment come from? If the unit of discovery shrinks toward the pair I described above, the question gets sharper still — there’s no obvious seat at that table for someone who’s still building their judgment. The whole model depends on people who can review, specify, and catch what’s wrong — skills traditionally built by doing the work the agents now do.
I’m not the only one worried about this. Mark Russinovich and Scott Hanselman recently argued in Communications of the ACM that agentic tools give senior engineers a boost while imposing what they call an “AI drag” on early-career developers, who don’t yet have the judgment to steer and verify agent output. The economics that follow are exactly the ones I’m describing: hire seniors, automate juniors — and followed to their conclusion, they collapse the profession’s talent pipeline. Their proposed fix is an apprenticeship model borrowed from medical education: keep hiring early-career engineers, accept the short-term capacity cost, and design the organization so their development is deliberate rather than incidental. That matches my experience — the tools can accelerate learning for people who use them to understand rather than to avoid understanding, but nobody grows into that use of them by accident. I’d still be lying if I said we’ve solved the pipeline problem. We haven’t.
Next Step
If you lead an engineering organization, here’s the experiment I’d run. Pick one long-horizon task that is genuinely useful, well-bounded, and has a definition of done you can write down. Design the loop to your existing guardrails instead of around them — let your privacy boundaries define the tool surface and your governance gates define the checkpoints. Set the success bar at “business deliverable” before you start, not after. Then pay attention to every place a human had to intervene. Those interventions aren’t failures; they’re your architecture telling you where the checkpoints belong.
The day I described at the top of this post — the day the work under review stopped being code and became outcomes — is coming for most of us. Sooner than the skeptics expect. Later than the demos imply. The teams that will handle it well aren’t the ones waiting for the guardrails to come down. They’re the ones learning to build inside them.
Resources
- Master GenAI Prompting for Better Coding Outcomes — my post on the human-driven version of this loop
- What I Actually Look for When Hiring Software Developers — judgment and shipping, the two skills this future rewards most
- What I’d Tell Someone Starting a Software Development Career Today — the fundamentals argument, extended here
- Team Topologies by Matthew Skelton and Manuel Pais — the stream-aligned and platform team model I’m extrapolating from
- Redefining the Software Engineering Profession for AI by Mark Russinovich and Scott Hanselman, Communications of the ACM — the pipeline problem from The Honest Cost, named and given a proposed treatment
- Building Effective Agents (Anthropic) — a clear, pattern-level taxonomy of agentic architectures, including when not to use one
- ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) — the research foundation for the plan-act-observe loop
