Luca Rossi has spent five years running Refactoring, a newsletter and community about software engineering read by more than 170,000 engineers and managers. Before that, he spent a decade as a CTO and startup founder. He’s not a commentator watching AI happen to other people. He’s building an open source app called Tolaria, writing about it in real time, and using that firsthand experience to ground everything he publishes.
Rob sat down with Luca to talk about what high-performing teams are actually getting right with AI in 2026, why code review was always more questionable than we admitted, and how Luca built a three-part framework: guides, gates, and guards, to keep AI agents honest in production code.
1. 2026 is the year of reckoning, not adoption
Last year, AI tooling spread fast. Most teams added something. Some added everything. This year, the question has shifted from “are we using AI?” to “what are we actually getting for it?”
Luca has been watching this across a wide range of teams, and the diversity is striking. There’s no consensus, no single playbook, and the gap between teams who are extracting real value and teams who are just spending tokens keeps widening.
“2025 was more like the year of adoption. Eventually we got to: ‘AI is everywhere, 95 plus percent of engineers using AI’. And this year is more like okay, show me what you’re getting out of it, as the token spending keeps growing for everybody.”
Luca Rossi, Founder, Refactoring.fm
The teams pulling ahead are the ones who’ve gotten specific about where AI actually helps and where the friction still lives.
2. You have to know your SDLC before you can improve it
This sounds obvious. It isn’t. Luca’s observation is that the single biggest differentiator between the teams getting results and those who aren’t is whether engineering leaders actually have visibility into what’s happening in their delivery process. It’s about real awareness of where things slow down, where handoffs break, and where decisions stall.
“Just being aware of what’s going on in your developer process. Which means talking with your engineers, knowing where the problems are, where the bottlenecks are, having a good feedback loop where you can actually work on things that you know can be improved.”
Luca Rossi, Founder, Refactoring.fm
Rob noted that this insight has been true for 30 years. But the AI era has made it more consequential because improvements compound faster when you know where to aim them.
3. Guides, gates, and guards: a framework for trusting AI agents
Luca has been building Tolaria largely without writing code himself, directing AI agents through the full development workflow. That experiment forced him to get precise about trust. The result is a three-part framework he calls guides, gates, and guards.
Guides are the instructions agents follow: rules in the agents.md file about how code should be written, covering things like TDD, the Boy Scout rule, analytics instrumentation, and localization.
Gates are deterministic checks that run before anything gets committed. Because agents ignore the guides roughly 10% of the time, you need enforcement that doesn’t rely on the agent’s judgment. Luca uses local hooks to check code health, quality, and security and blocks commits that don’t clear a threshold.
“AI can happily ignore these rules every now and then, like ten percent of the time they just don’t care and do things how they like to do. And so you need deterministic gates to avoid [the fact that] bad things happen in production and get committed and pushed.”
Luca Rossi, Founder, Refactoring.fm
Guards are nightly or weekly audits that catch judgment calls and bigger-picture issues. Did the agent forget to write an architecture decision record? Have performance metrics degraded since the last release? Are there refactoring opportunities the agent couldn’t see at the task level?
4. Velocity without visibility is just faster drift
One of the clearest tensions in the conversation: AI compresses the coding loop, but that doesn’t automatically speed up software delivery. It can just mean you’re drowning somewhere else.
Luca pointed to code reviews and product planning as the two places teams tend to hit the ceiling. Code gets written faster, but review queues get longer. Requirements get built faster, but upstream work to define what to build doesn’t scale with the throughput.
“We’re just getting faster at coding, but people are drowning either in code reviews or are too slow at creating new requirements or measuring what’s been done. So we have to take a holistic view about the whole thing.”
Luca Rossi, Founder, Refactoring.fm
The teams breaking through aren’t asking “how do I make each stage better?” They’re asking “what am I actually trying to get out of this process?” and redesigning from that question with the tools they now have.
5. Code review was already questionable. Now it’s untenable.
Luca has been skeptical of traditional code review for longer than AI has been part of the conversation. The asynchronous process was a time sink before agents started generating code at scale. Teams would fight to shave 10 minutes off CI times while PRs sat idle for 18 hours. And the assumption that humans reliably catch important issues by scanning unfamiliar code quickly has always been optimistic.
Rob agreed: We were never that excited about reviewing our colleagues’ code. We tolerated it because it was the best available option.
“Even if you don’t account for the quantity, it’s just a miserable experience. You don’t want to corner people into spending a lot of their time at work doing miserable things like reviewing AI code.”
Luca Rossi, Founder, Refactoring.fm
Now that AI agents can generate code far faster than any team can review it, the math is clearly broken. But the answer isn’t faster humans. It’s rethinking what “review” is actually trying to accomplish and finding better mechanisms for that. Deterministic gates, paired programming for high-stakes changes, and automated quality enforcement upstream before anything reaches a human.
6. Building for yourself is a cheat code with limits
Luca’s most consistent lens across everything he talked about, including the newsletter, the app, and the AI workflow, is that building something you personally need gives you a feedback loop most teams don’t have. You know the problem because you’re living it. You know when the solution works because you feel it.
He’s explicit that his experience building Tolaria is privileged. He’s working alone, with no legacy code, and can afford to experiment in ways that most real-world teams can’t. But the underlying principle transfers: the teams getting the most out of AI tools right now are the ones with enough self-knowledge to know what they’re actually trying to solve.
Confident Commit is CircleCI’s podcast for engineering leaders who want to understand how software delivery is actually changing. Subscribe at confidentcommit.com to get every episode plus companion posts like this one.
