Why Real Life Autonomous Agents Began in the World of Coding

Every few weeks someone asks me the same question in a different costume: "Where do agents actually work, for real, not in a demo?" They usually expect me to point at a chatbot or a summarizer. I point at our software development process instead, because it's the one place in the business where I can show you the receipts.

Here's the thing that took me a while to say out loud, even to myself: coding wasn't the destination. It was the on-ramp. Software engineering happened to be the easiest place to prove that agents can run inside a real process, at real stakes, without a human babysitting every step. That's not because coding is special. It's because coding already had the one ingredient agents need to be trusted with real work: decades of refined process.

Process is the thing that was actually hard to build

Ask any engineering leader who's been doing this for twenty years and they'll tell you the code was never the hard part. The hard part was building a process disciplined enough to let dozens of engineers move fast at the same time without stepping on each other, and forgiving enough to catch the mistakes that inevitably happen when humans move fast.

Left alone, most engineers, myself included, would happily ship a 3am brainstorm straight into production. Some of our best ideas show up at 3am. So do some of our worst. The entire discipline of software engineering process exists to let the good 3am ideas through and stop the bad ones before they reach a customer. That's not bureaucracy for its own sake. It's risk management that has been stress-tested for decades, and it's why software engineering, as an industry, ships more changes per year, per person, than almost any other function in a company.

Strip away the tooling and the jargon and that process reduces to a short, boring sequence:

1. A business idea shows up.
2. Someone turns it into engineering strategy and architecture.
3. That strategy becomes a specification.
4. The specification gets broken into pieces small enough to build, test, and review independently.
5. Someone implements each piece.
6. Someone else reviews, tests, and validates it.
7. It merges into the larger project.

That's it. Every methodology, framework, and ceremony your engineering org has ever adopted is just a different way of executing those seven steps with more discipline and less waste. It's a genuinely elegant piece of institutional design, refined by an entire industry over decades, and it's the reason software organizations can safely ship thousands of small changes a week instead of one terrifying change a quarter.

The insight: automate what humans are slow at or bad at

Once you see the process as seven discrete stages, the mistake most people make with agentic AI becomes obvious: they try to hand the whole thing to a model at once, idea to production, and act surprised when it goes sideways. That's not where agents earn their keep.

Agents earn their keep on the stages, and the parts of stages, where humans are either too slow or genuinely bad at the work. A human can watch a queue of ready-to-build tickets, but not tirelessly, not at 2am, and not without getting bored and skipping steps. A human can run a full test suite against a change, but grudgingly, and usually not as exhaustively as they'd run it on someone else's code as their own. A human is, frankly, a mediocre bug-finder when the code in front of them is their own, because we're all a little too generous with our own work.

None of that is a knock on engineers. It's just a description of where human attention is a scarce, valuable resource and where it isn't. The stages that require judgment, taste, and context, like setting business direction or making an architecture call, still belong to humans and probably always will. The stages that require relentless, literal, tireless execution of a well-defined process are exactly where an agent should be doing the work instead of a person.

How we actually run this

Here's the version of that pipeline we run today, not a hypothetical one.

Ideas start where ideas always start: in a room, in a conversation, in front of a whiteboard. We record those conversations, and AI turns the transcript and the whiteboard photos into a first draft of discrete action items. From there, an engineer takes ownership of a component of the effort and works with AI to turn a rough action item into a specification with no open questions. That specification becomes a GitHub issue, and our internal proprietary roadmap system stays in sync with GitHub the whole way so nothing lives in two places with two different truths.

That last part matters more than it sounds. Our issues aren't written as tickets for a person to interpret. They're written as prompts for an agent to execute. The engineer's job shifts from "write the code" to "write a specification precise enough that an agent can't misread it." That's a genuinely different skill, and it's one we're actively building across the team, because a vague issue produces a vague agent and a vague agent produces work nobody wants to review.

Once an issue is marked "ready for agent," it drops into a queue that a team of coding agents works continuously. When an agent finishes one issue, it picks up the next. No standup required, no context switching cost, no Monday morning to shake off.

Here's the part that surprised me even after I expected it: finished agent work is not review-ready work. A second, looping agent monitors everything the coding agents finish and runs it through a gauntlet of tests before a human ever sees it. It almost always finds something. Agents wrote the code, agents wrote tests for the code, and there are still bugs waiting for a second agent to catch. That's not a knock on the technology. It's the same reason your engineering org has never let anyone merge their own pull request without a second set of eyes. Independent verification catches things the original author, human or agent, is structurally bad at catching in their own work.

Only after that gauntlet passes does a human pick the work up. They test it, they review it, and they merge it into the main branch, where it runs through yet another round of automated and human testing. Then it moves behind our release markers: first into a test environment, then out to early adopters, and finally, after roughly a week with no major complaints, out to everyone. Nothing skips a gate just because an agent, instead of a person, wrote the code that's moving through it.

What it's actually bought us

The plain result: this pipeline has saved us tens of thousands of development hours, and our velocity keeps accelerating as we add more, better, and more efficient agents into it. Not because we cut corners. Because we finally have enough tireless attention to run our own process at full strength, all the time, instead of the reduced strength a finite team of humans can sustain on their best week.

Coding wasn't easy, but it was an obvious place to begin

I want to be direct about why I picked software development to make this case instead of some other function in the business: it was low-hanging fruit. Engineering already had seven decades' worth of refined process, sitting there, ready to be executed by something more tireless than a human. We didn't have to invent the discipline. We just had to hand the existing discipline to agents built for it.

That's the real lesson for a COO or a CIO reading this, and it has almost nothing to do with code. Any process in your organization that has real process, defined stages, clear handoffs, a way to check work before it ships, is a candidate for the same treatment. Finance close, vendor onboarding, incident response, compliance review, customer escalation handling: wherever there's an actual sequence of steps with real gates between them, and not just tribal knowledge in one person's head, agents can be built to execute the tireless, literal, repeatable parts of it while people keep the judgment calls.

Coding was first because the process already existed. Where we take this next is on us: finding the other processes in the business disciplined enough to earn the same trust, and having the creativity, determination, and care to build for them the way we built for engineering. That's the actual opportunity here, and it's bigger than any one function.