AI in Software Engineering: What 60+ CTOs Have Actually Learned

CTO Studio is a live interview series for the engineering leaders running companies you've heard of — and a lot you haven't. Over the past two years we've sat down with more than sixty CTOs, VPs of Engineering, and founders in Austin and San Francisco. No keynotes, no panels, no thought-leadership theater. Just the questions you'd ask if you grabbed them in the hallway after a conference.

If you read the transcripts back to back (we have; you don't have to), a pattern emerges. The engineering leaders who are most credible on AI right now are saying remarkably similar things. They're not saying AI will replace their teams. They're not saying AI is a fad. They're saying something quieter, and more interesting: AI is a force multiplier — and what it multiplies most of all is the truth about your engineering organization.

The Ferrari problem

The clearest articulation of this came from Rob Zuber, who has been the CTO of CircleCI for nearly twelve years. Asked how AI was changing the way his team ships, he didn't talk about productivity gains. He talked about preconditions.

If you're good, AI can make you great. If you have well-structured architecture, well-written code with documentation — code documents itself to an LLM. But if you're missing anything critical in that flow, you're just driving a Ferrari into a ditch.

Several CTOs articulated the same idea in different words. Teams that already had clean APIs, thoughtful test coverage, and senior engineers with strong opinions about what "right" looks like reported real, compounding productivity wins. Teams that were already swimming in undocumented services and load-bearing prayer? AI accelerated their entropy.

The new technical-debt accelerant

The compounding-debt problem came up so often in interviews that it has its own gallows-humor running joke. David Walters described what is now happening inside organizations that have rushed AI into their daily workflow:

Organizations now have the ability to accumulate technical debt at an exponential rate. You have engineers running ten parallel agents, and junior engineers reading code that's better than what they would have written — that they don't understand. So they just approve it.

A year ago the worry was that AI would replace junior engineers. The leaders we talked to now worry about a different failure mode: AI is shipping production code that no human on the team actually understands. The code review pipeline still exists, but it has quietly stopped being a review of comprehension and started being a review of vibes. Engineers approve PRs because the diff looks reasonable, not because they could explain it on a whiteboard. Every approval is another brick in a tower nobody can later tear down.

What the mature teams actually do

The interviews that left us most optimistic weren't from the loudest AI evangelists. They were from leaders in regulated industries — finance, healthcare, defense — who can't afford to ship code they don't understand because the downstream cost is, in some cases, a federal investigation. These teams have already moved past the honeymoon phase. They've built guardrails, named methodologies, and developed an actual taste for what AI is good at.

Jake Moilanen, whose team operates under heavy financial regulation, described what this looks like in practice:

Within weeks, we saw a 4.5× increase in net lines of code per developer. But you can't roll back a bad trade — we're liable. So we treat AI like a research partner, not a coder. We coined it Research-Driven Development.

"Research partner, not coder" turned out to be a remarkably durable mental model. The teams getting the most out of AI weren't asking it to write production code unsupervised. They were asking it to draft, to summarize, to map unknowns, to generate options that a human could evaluate and discard. The 4.5× number isn't a productivity gain from delegation — it's a productivity gain from offloading the work that engineers were never that great at anyway: reading documentation, exploring unfamiliar libraries, prototyping the first ten versions of a function before knowing what the eleventh should look like.

The most honest thing anyone said

The most quotable line we recorded all year was almost certainly Rich Robinson's, delivered with the patience of someone who has watched the AI discourse cycle through five overlapping hype waves:

Anyone who says they know exactly how this is working is suffering from a Dunning-Kruger effect right now.

This is the consensus, such as it is. The CTOs we trust most aren't the ones with a five-year AI roadmap. They're the ones running experiments in two-week loops, throwing out half the results, and keeping the other half because they actually shipped something useful. They are humble about what they don't know, opinionated about what they've personally observed, and quietly skeptical of anyone selling certainty.

The pattern, in three lines

If you compress sixty interviews into three sentences, this is what you get. AI is a multiplier on the engineering culture you already have — for context, for taste, for judgment. The bottleneck has moved from typing speed to deciding what's worth building, and to maintaining enough context across an exponentially larger surface area of generated code to know whether it's right. And the leaders worth listening to are the ones willing to say, out loud, that they're still figuring it out.

If there's a meta-quote in there somewhere, it's that the job of a CTO in 2026 is less about knowing the answer and more about knowing which question to ask next. We'll keep recording the questions. Subscribe to CTO Studio if you want the next round.