The most interesting thing AI does isn't building new things cover image

The most interesting thing AI does isn't building new things

Jon Milsom •
Updated

Categories ai engineering

Everyone's talking about AI building new things. Agents coordinating agents, full orchestration, Steve Yegge's Gas Town [1] running 30+ Claude Code instances simultaneously. David Heinemeier Hansson's take [2]:

"The most exciting thing we've made computers do since we connected them to the internet."

He's right. But most of the conversation focuses on building from scratch, pushing boundaries, greenfield. Right now, I'm more interested in what AI does to everything that already exists, the old stuff, the "legacy", the systems that actually run businesses and pay everyone's wages. That's where I spend a good chunk of my time at Pitchero: a small team, a huge platform, ever competing priorities. And it's also the reality for government, healthcare, and every other organisation sitting on decades of accumulated software.

The hard bit was never the code

The slow bit, maybe. The expensive bit, probably. But the hard bit was always the decision-making, market knowledge, customer feedback, experience, the distillation of dozens of possible paths into the one you actually ship. Operating at scale, handling edge cases you'd never predict, encoding institutional knowledge into software that works.

In The Mythical Man-Month, Fred Brooks laid out how software time actually breaks down: ⅓ planning, ⅙ coding, ¼ component testing, ¼ system testing. Coding was one sixth. The Pragmatic Engineer's modern equivalent puts coding and tests combined at about 40% of the total, with planning, code review, and production readiness making up the rest [3]. AI is primarily accelerating the coding segment, but this was never the majority of the work.

George Sivulka made this point well in In Defense of Vertical Software on the a16z Substack [4]: the value doesn't come from the code itself, it comes from understanding the process and organisation well enough to make the software do exactly the right thing. Software is a stored social contract. It encodes shared expectations, institutional memory, team muscle memory. You can't rebuild that from scratch because load-bearing software contains social agreements for how a team will cooperate.

Good process compounds

My key takeaway from 18 months of using this technology, lightly at first, then aggressively, is this: if you were using good process and tooling with humans, it's now good for AI agents too. Good documentation, test coverage, fast CI, repeatable CD pipelines, disciplined product management with acceptance criteria and well-documented workflows, all of it transfers directly.

Matthew Skelton explains this concisely [5]:

"The organizations best placed to take advantage of agentic AI are those that already focus on clear definitions, bounded scopes, and guardrails for humans."

"If you can bound the amount of knowledge and focus the scope of work, it is better for human cognitive load, and it is better for AI agents."

I'd guess many reading this acknowledge that it's not the reality everywhere. Most businesses have a range of quality across their applications, we certainly do at Pitchero: some bleeding edge, easy to work with; some legacy, hard to change. The challenge is getting everything in shape to take advantage of the technology, but happily AI can help with that too.

One person, more surface area

Individuals can now cover ground that used to require handoffs. Product managers doing mockups. Designers building frontend. Full-stack engineers who are now actually full-stack. One Pragmatic Engineer report [6] cites a traditional company already shrinking engineering teams from "two-pizza teams" to "one-pizza teams." The direction of travel is clear.

An HBR field study [7] found exactly this pattern. Over eight months at a tech company, workers didn't do less, they took on responsibilities outside their roles because AI made unfamiliar tasks feel accessible. Product managers started coding. Researchers did engineering. The study calls it "task expansion." I'd call it the team-of-one effect in action.

This matters most for the work that never gets done. Every organisation has a backlog of tasks that never quite meet the ROI threshold, not urgent enough, not valuable enough relative to the cost. Legacy codebases that need documentation. Test coverage that would make changes safe. Dev environments that need containerising. Package updates and vulnerability patches. Without a driving need like security or compliance, they sit there forever.

AI lowers the barrier on all of it. Whatever your constraint, money, time, cognitive capacity, it's more tractable with an agent working alongside you. Josh Nesbitt recently used Claude Code to upgrade a legacy Rails app with a stack of vulnerabilities [8]:

"Moments like this can feel a lot like cheating, and I for one am very happy to cheat in this area."

This is exactly what I've been doing on one of our legacy codebases. Write documentation where there was none. Add tests so you can change things with confidence. Dockerise the dev environment so you can actually run it locally. Then make the changes that seemed impossible a few hours ago.

The making-impossible-possible bit is exciting, sure. But the most transformative thing about AI isn't what it builds from scratch. It's what it finally lets you do with everything that already exists.


References

  1. S. Yegge, "Welcome to Gas Town," Medium, 2025. [Online]. Available: https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04
  2. G. Orosz, "When AI writes almost all code, what happens to software engineering?," The Pragmatic Engineer, 2025. [Online]. Available: https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what
  3. G. Orosz, "How AI will change software engineering," The Pragmatic Engineer, 2025. [Online]. Available: https://newsletter.pragmaticengineer.com/i/154200840/a-good-time-to-refresh-what-software-engineering-really-is
  4. G. Sivulka, "In Defense of Vertical Software," a16z, 2025. [Online]. Available: https://www.a16z.news/i/188396680/the-last-mile-is-the-entire-problem
  5. M. Skelton, "Unlock the benefits of AI by designing for humans," matthewskelton.com, 2025. [Online]. Available: https://matthewskelton.com/blog/unlock-the-benefits-of-ai-by-designing-for-humans
  6. G. Orosz, "The future of software engineering with AI: six predictions," The Pragmatic Engineer, 2025. [Online]. Available: https://newsletter.pragmaticengineer.com/p/the-future-of-software-engineering-with-ai
  7. "AI doesn't reduce work — it intensifies it," Harvard Business Review, Feb. 2026. [Online]. Available: https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it
  8. J. Nesbitt, LinkedIn post on Claude Code and legacy work, 2025. [Online]. Available: https://www.linkedin.com/posts/josh-nesbitt_a-lot-of-the-recent-coverage-on-claude-code-activity-7425553708538621952-r4c2

Did you find this interesting? Share it.