I've known Nathan Foreman for around ten years. We've been through the trenches together, and he was the one who sat me down at a barbecue in Nashville with a burger, a beer and a laptop and showed a product guy how to "write code" with AI. Back then it felt like magic.
So when Nathan told me he now writes perhaps five to ten per cent of his code by hand, and that he'd let an agent swarm loose on a project and come back to something he couldn't step into, I wanted to hear the whole story. Nathan is a principal engineer at Roller, which does venue management, and he's further down this road than most people I talk to. What struck me is that the lessons he's learnt aren't new at all.
You can listen to the full episode at aiforhumanit.com.
From autocomplete to reviewer
Nathan's journey will sound familiar to a lot of developers. It started with early GitHub Copilot in VS Code, which he described as a super-powered IntelliSense. You'd write a comment saying you wanted to check every user was over 18, and it would draft the loop, the age check and the error.
Then came a long stretch, maybe a year, where he built proofs of concept with AI and lifted the bits he liked into the real code by hand. Only in the last six months or so has he let it work straight on the code base and raise pull requests that he reviews.
He put the evolution neatly: IntelliSense, then "you do it, I'll spot check it", then "you do the work and I'll review it". His own work now is shaping almost whiteboard-level flows and letting the AI fill them in.
One use I particularly liked is research. On large code bases he'll ask it to trace a call and list everywhere it reaches out to Azure or AWS. That used to be a spike, a time-boxed window to understand what you'd been asked to do. Now it's a set of threads spun up to come back with a breakdown.
The eager builder
You might expect less reviewing as the tools improve. Nathan finds it can be more, precisely because the AI can now go further before it makes a mistake.
His comparison with a junior developer stayed with me. Juniors tend to find the quickest solution and stop, so you nudge them to add one more thing. He's never had a junior where he had to say: you wrote six times more than we need, remove at least half.
His example was a small system to pull work down and run it with a local agent for two or three days. What he got was atomic handoffs, job tracking and version history on every job, the lot. All working, none of it needed. What he wanted was the old PowerShell pattern: check SQL, anything in ready, do it.
I've seen the same as a product person, where a casual idea comes back with database technology wildly over-specced for something plain SQL would handle.
What happened with the swarm
The heart of our conversation was multi-agent workflows. Nathan has used GitHub's Spec Kit for specification-driven development. You have a back-and-forth conversation to flesh out a full spec, and it's broken into small pieces that individual agents pick up. Some agents write code, others review it, and others run QA with tools such as Playwright, feeding problems back before anything merges. As he said, it starts to behave like a team.
Then he gave it permission to approve its own PRs and raise new ones. When he came back there were roughly 800,000 lines of code. It was a fully working system that did a lot of cool things, and he couldn't realistically step into it. He likened it to joining a five-year-old project.
His fix was the old one. He needed to stop being lazy at the start and check each step. If you ask the AI to raise an issue and ask for clarification, it will. When you stay in the loop it takes feedback happily. The trouble comes when you say "do what you think is good", and it reaches for patterns from enormous enterprise code bases, including seventy-five checks for Chinese characters on a project with two people who can't type them.
Nathan reminded me of the drinking bird Homer Simpson leaves pressing Y. No green screen anymore, same problem.
Write the decisions down
So how do you keep humans in at the right level? Nathan is borrowing from enterprise architecture: architecture decision records, significant requirements, rules of operation.
When we worked together in a small company, we just knew things, such as always building on Microsoft products. Those rules lived in our heads. An agent can't read your head. You need a record that says all new development should use .NET. It's simple, and the AI will follow it, but only if it's written down.
He's used plain Markdown in GitHub and Confluence for this, with Confluence easier for humans to contribute to. That balance between something a machine reads and a human writes is going to matter.
He also mentioned Hindsight from Vectorize, an MIT-licensed open source project with a commercial offering, which uses graphs to build memory over time. Tell it often enough not to overwork something and it starts anticipating that you'll send it back.
Governance as a dial
Nathan described governance as a dial rather than a switch. In his localisation work, which brushes against legal and tax requirements, one end is telling the AI to read every law ever and burning your tokens. The other is going with what feels right and getting sued.
From my side, the problem I keep hitting is secrets. With computer-using agents for testing, something has to log in. Our approach hands off to deterministic automation to fetch a secret from a key vault, but the agent can still see the screen. Nathan made the fair point that putting a password in an environment variable mostly makes us feel comfortable, because an agent could just echo it. I don't think the industry has this solved.
What I took away
Nathan's closing advice was to search before you build. People can build so quickly now that someone has probably already written the PDF parser or the skill you're about to start. It's build versus buy again, just faster.
That was the thread through the whole conversation. Separation of roles, review checkpoints, written architecture decisions, attention to design: none of it is new, and AI makes all of it more important.
If you work in IT, my suggestions are modest. Before handing work to agents, write down the rules you currently carry in your head. Decide where a human signs off, and don't let the agent approve its own work. And before building, have a look at what already exists.
Listen to the episode on Spotify