Rob Zuber - CircleCI
When the Cost of Code Collapses, Everything Built Around That Cost Must Change
Rob Zuber has spent over a decade building software at CircleCI, long enough to watch the same lesson repeat itself in different packaging. Teams optimize for the bottleneck. The process shapes itself around whatever is most expensive. For most of software engineering history, the expensive thing was writing the code. Now it isn’t, and that changes almost everything else.
That is the tension running through every decision Rob is making as CTO at CircleCI right now. The pipelines, the review gates, the team ratios, the way companies manage technical debt, all of it was designed for a world where writing a line of code carried real cost. Strip that cost away, and the scaffolding built around it no longer makes sense.
The Builder at the Center
Rob joined his first startup in the late 1990s, not as a trained engineer but as someone willing to learn. “A pulse was more important than your pedigree,” he said. Working out of a house in Toronto with about 10 colleagues, he was assigned one of his first tasks: automating the build process. He has been doing some version of that work ever since, across different titles: systems engineering, DevOps, SRE, and platform. The label changed; the core problem stayed the same. How do you help people deliver software faster and with more confidence?
That question is what keeps him at CircleCI after 11 years, a tenure long enough to carry real weight. “A lot of engineering leaders go from team to team, organization to organization, and are super proud of the things that they did,” he said. “Maybe they didn’t stick around long enough to find out if that actually worked out. When you change the structure of an organization, the pain comes in five years.” Rob has lived those five years, more than twice over.
Today, he is not managing from a distance. He is actively writing code with a small team, using AI coding tools himself, because he believes that direct experience is the only credible foundation for leading engineers through a period when the ground shifts weekly. “Being at least very experienced in the tooling, to be able to speak competently about what we’re trying to do, has felt very important,” he said.
The System Was Built for Different Assumptions
CircleCI’s core mission has stayed consistent: give customers the confidence to deliver quickly. “We believe that speed wins in the marketplace,” Rob said. “In order to ship effectively, you need fast feedback loops, working product in front of customers, and learning how they respond.”
What has changed is the pace of software creation, and that pace now exposes a structural problem in how most CI/CD pipelines are designed. Rob describes the current model as “a downstream gate.” Teams do all the upstream work: design reviews, customer research, prototyping, making decisions, writing code, and then pushing it through CI as a final check. The feedback arrives very late.
“The running joke inside our company is, how am I finding out in CI that my linting failed?” he said. “That is way too late to be getting that level of feedback.”
The deeper issue is not just about linting. It is about why those downstream processes exist at all. “Many of the things that we do in software are designed around the fact that actually writing the code is expensive and time-consuming,” Rob said. “So we spend a lot of time building paper prototypes, going through design reviews, picking the one we’re going to build. But if you can build five alternatives for basically nothing, then why are we following that process?”
CircleCI is working to bring CI-grade feedback into the development flow itself, not as a gate after the fact. Rob described how his team is using Claude Code’s stop hooks to run tests, linting, and validation checks automatically at the end of each AI coding session. “The way I’m working now is: I ask it to do something, it finishes, then it runs all the tests in a CI-like environment, it runs the linter, it does all these things, and then fixes all of those problems and doesn’t even say it’s done until the stuff is basically ready to get through a CI cycle.” The PR as a surface for human-to-human review, he argues, was designed for a different world. “We have agents interacting with agents on a web form that doesn’t add any value in that world.”
The Ballooning Interest Rate
Rob has a particular way of thinking about technical debt that clarifies why this moment is forcing so many engineering organizations to reckon with decisions they made years ago. The original metaphor, he notes, was a financial one: you borrow against the future because the opportunity in front of you is worth the interest payments. “What tech debt has become is ‘I don’t like that, therefore it’s tech debt.’ It just means nothing to anyone anymore.”
But the underlying calculation is still real, and AI has changed the math sharply. “In a sense, AI has increased the interest rate really significantly,” he said. “I took out a mortgage, I knew it was going to be 2.5 percent, and today it’s 13 percent. I can’t afford that anymore.”
The logic is straightforward. If a task that used to take 10 days now takes half a day, but a piece of legacy friction still adds a full day of overhead, that overhead has gone from a 10 percent tax to a 200 percent one. “The overhead is the same, but the cost of doing the thing is so much smaller,” Rob said. “Everyone is piling metrics on their engineering organizations right now, and everyone is not sure if they’re laughing or crying about the fact that we’re really motivated to clear blockers for the machines that we didn’t clear when they were blockers for the humans.”
CircleCI’s State of Software Delivery Report captures what this looks like in practice. Teams with solid delivery foundations, good CI, continuous delivery, progressive delivery, and production monitoring are accelerating. Teams without those foundations are moving fast into problems. “They’re driving their Ferraris into brick walls,” Rob said. “They’re so fast. Everything’s broken. They can make mistakes so much faster and have no safety net anywhere to manage it.”
Who Belongs on the Team
The question of who to hire and how to structure teams is one Rob answers with candor about what he does not yet know. “No great answers at the moment, which is not to say we’re not thinking about it, but rather we’re experimenting.”
His view on senior engineers is that deep experience matters more, not less, because the failure modes of AI-generated code show up in production, not in the editor. “When it collapses in production, someone needs to know how it works.” But he also flags something that senior engineers have to consciously work against: the instinct to rewrite code because it looks unfamiliar. “What I care about in the structure of software is not the way the software looks,” he said. “If I am optimizing for an LLM to be able to do that, then the structure and shape of my software might be different.”
For junior engineers, the challenge is different and more open. The toil that once built a foundational understanding is largely gone. “Teaching someone to effectively utilize an LLM to generate or build a piece of software is a very different skillset,” he said. “We’re all learning it together.” Rob described checking in with junior team members who said they weren’t sure if the work they were producing was good, just that they had typed something into the tool and things had happened. That is not a failure of the individual. It is a genuine open question about how to develop engineering judgment in a generation that didn’t earn it through the same path.
What Rob keeps coming back to as a durable foundation is curiosity and the willingness to treat engineering as problem-solving rather than code production. “The people I’m seeing shift effectively are the ones who are, ‘I am an engineer. I am engineering the solution to using an LLM to build something.’ Not ‘I am a writer of lines of code.’”
Where the Leverage Goes Next
The organizational bet Rob is watching most carefully is what he calls the “re-soloing” of software engineering, a term he credits to Kent Beck. In that model, a single person leads a collection of agents and ships at a pace that once required a full team. He is not dismissing the possibility, but he is skeptical of treating it as the goal.
“A single person making all the decisions is probably going to end up in a sad place,” he said. “We want diverse teams with diverse perspectives. An agent is not going to say to me, ‘that’s actually not a very good way to come at this.’”
The system’s question he keeps returning to is not how to go faster in a straight line. It is how to redesign the entire delivery process now that the constraint it was built around has been largely removed. CI moves inside the loop. Feedback comes earlier. The code architecture needs cleaner boundaries so multiple agents can work in parallel without creating a mess come Monday morning.
“We want to rethink the system,” Rob said. “Tool around that process so that we can give you everything you need to feel confident as early and quickly as possible, so that you can maintain that speed as you go.”
After 11 years at the center of how software gets delivered, Rob’s argument is simple: the pace changed, so the process has to change with it. The teams watching their competitors pull away are, in many cases, not losing because they lack the AI tools. They are losing because everything they built around the old cost of coding is still in place, and now it costs them more than they can afford.











