Itamar Friedman

Your code diff might be small, but the blast radius is not. In the latest Qodo release, AI code review can now reason across connected repos. That means a backend PR can surface risk in the frontend, contracts, workers, or infra that inherit the change. This is the AI code governance shift I care about: not more comments, BETTER context.

@nnennahacks Context visibility means trust

Had a wonderful conversation with @nnennahacks on The Agentic Review podcast. We covered a lot of ground in this one: ∙ rolling out AI agents across a large engineering org ∙ why one tool rarely fits every team ∙ the need for neutral open standards ∙ what junior engineers can bring to AI-native development ∙ shifting code review earlier in the workflow ∙ testing in the AI era ∙ and yes, why software development is still a team sport, even with AI A thread running through the whole conversation was the practical side of AI adoption. The one with compliance reviews, skeptical engineers, messy codebases, strong opinions, and teams trying to figure out how to move faster without lowering the quality bar. 🙃 Thanks to Nnenna and the @QodoAI team for having me. Nnenna, you were brilliant and led such a thoughtful conversation 🙏🏽 Listen the episode here: lnk.to/Nonx0eAJ

Good engineering culture is not about asking every developer to remember the right thing. It is about building systems where the right thing becomes hard to skip. In this clip from The Agentic Review, @techgirl1908 (Angie Jones) makes a great point: if you want people to behave like “good humans” in the development workflow, encode those practices into the system. This is where code quality moves from preference to governance. And that's the kind of agentic engineering conversation we want more of.

@QodoAI @techgirl1908 @steipete Regarding build vs. buy, we are moving toward a world of build-to-buy. First, build if you have the resources, see what you can achieve, and then you will know what you need to buy.

So don’t think about building “a loop”. Build harnesses, with loops and a system. The difference shows up when something goes wrong. A loop fails silently. A harness fails with a signal. A loop lets the agent run until it’s too late. A harness has a circuit breaker. Most teams haven’t built that infrastructure yet. Not because they don’t care about reliability. Because the conversation about loops has just begun, and more focus actually needs to be on harnesses.

When I brainstorm with engineering leaders on their code review pain points + solutions, it always comes back to the "blast radius" problem I wrote about in a whitepaper at the beginning of 2026. In “How Do You Define Code Quality?”, I argued that code quality is a governance system: a practical way to decide what “good enough to ship” means for different parts of your stack, under real‑world constraints. For months, my argument has been to risk‑profile your repos so you stop treating mission‑critical payment flows the same way you treat internal scripts or experimental tools. Once you have that risk map, several things change: - You apply dynamic attention to PRs based on business impact. Not every PR deserves the same level of scrutiny. - You push context‑aware, deterministic checks and agent earlier in the workflow (IDE, CLI, pre‑commit, pre‑PR) to catch functional, structural, and process issues before they become review noise. - You treat AI review as verification: independent, enforceable checks tied to explicit governance rules. I’m also a big proponent of closing the loop with prod data. If your logs tell you exactly where users are getting hurt, that should directly drive where you invest in stronger tests and tighter rules. Tools like LogMiner-QA (production‑log‑driven test generation) and @EntireHQ (injecting intent as first‑class context for code changes) are signals of where this is going. At @QodoAI, we take this further with a rules system and context engine that encodes your standards and historical PR patterns so AI can enforce them consistently across IDE, CLI, and PRs, more customized to what your team cares about. Agentic code review is process + governance + automation working together: Risk‑profiled repos → clear blast radius. Full‑context integration early → fewer surprises at PR time. Deterministic + AI checks throughout the pipeline → less entropy when you finally sit down to review. Prod data and PR activity feeding back into rules, tests, and how AI improves precision + recall for the very next code review → your governance model evolves as fast as your codebase.

@filip_hric @nnennahacks haha, feeling some 2023 vibes here

Fable is just "a bit" from achieving world peace. 🤏 Fun moment from our livestream with @nnennahacks yesterday 😊

A really good read by @GergelyOrosz: newsletter.pragmaticengineer.com/p/ideas-slow-d… This situation of engineers who care about quality being underserved must change, and it will be changed

For some industries and dev orgs, this will happen already in 2026. For others, it may take until 2030. A short list of key differences for whether orgs will reach that level soon or later: • How much engineering context is codified, including the tribal knowledge • Enabling AI code/software review/verification/validation agents to govern and enforce policies, standards, architecture, and security • The maturity of automated tests and runtime verification, with data and environments that are very close to production • Observability, rollback mechanisms, and progressive rollout discipline • Trust in a well-established AI code governance layer that manages all of the above This is the direction. Between “AI wrote it” and “production-ready”, there will be an AI continuously learning SYSTEM that engineers will nurture to enable much higher velocity, without losing control and actually improving it. Human review won’t disappear. But reviewing every line, in every PR, will stop being the default.

“We used to review every line of code before it went into production.” Within 12 months, mandatory human review of pull requests will become optional. Not because quality matters less. Because verification will move from manual inspection to governed, automated review.

@levie At least for the next few years. As memory-related technologies improve and reach their inflection point, the question of job security will arise again

Coding is basically the pinnacle of what you could reasonably automate with AI, and yet we still need human engineers to oversee agents for them to be effective. The AI models are trained on an incredible amount of sophisticated code. The users are highly technical and can use the latest tools quickly. The work is “verifiable” because you can test an app. The outcomes are often removed from the quality of the code (you can have sloppy code but the app can still work). And the context for the agent is often already digitized and sitting in the codebase. That’s an incredible amount of benefits that AI coding agents get to work with. Some of those apply to knowledge work, but most don’t in areas where the work needs to be fully reviewed to be useful, or where data isn’t as abundantly digitized. This makes the job for agents in knowledge work more complicated. So if with all of that, engineers still remain in very high demand, the risks are going to be less than what’s perceived for other areas of knowledge work. Agents will let people do far more than they did before, but the people don’t go away.

@nicktindle I believe in hope! Wherever necessary

@itamar_mar You just gotta believe in hope

Bold take. You only need prod. But you also need: • excellent code review • excellent observability • excellent rollback • excellent code verification • excellent governance Otherwise you’re replacing staging with hope. And it becomes even more interesting in the age of AI-generated code, where change volume is growing faster than our ability to manually verify it.

In many cases, I stopped answering my agents. Instead, I give them my criteria and let them answer

@levie Despite being the CEO I take at least one feature or bug fix all the way to production and beyond. We must understand what’s happening on the floor and last mile to make relevant decisions

CEOs are uniquely prone to AI psychosis because they’re sufficiently distant from the last mile of work that still has to happen to generate most value with AI. So when they play with AI, they see the happy path results, often not considering the next 10 or 20 things that have to happen to get sustainable results from agents. “Look I made this awesome product prototype”. Yes but you didn’t have to review the code before it went into production and fix a bunch of issues. “Look I generated a contract”. Yes but you didn’t verify all the terms before it goes out to the counterparty and didn’t have to wire up all the past contracts to work with. The best thing you can do as a CEO is to use AI a *ton* to figure out the real implications of agents in the enterprise, and come out the other side with an appreciation for both the upside and the real work that goes into them.

Shipper’s “After Automation” is the best framing I’ve read of why AI keeps generating more work, not less. The line that stuck with me: the frame is not the framer. Models climb whatever benchmark we draw. The moment they saturate it, humans redraw the edge one level up. That’s not a temporary lag. That’s the structure. One analogy that might work for this. The microwave didn’t kill dinner. It made dinner instant. The frame “make food edible” got cheap. So the frame moved to “make food meaningful.” Now we work harder than ever to plate it. That’s the part people miss. Humanity’s response to the microwave was to invent the $400 tasting menu, where a guy in a beard places a single foraged radish on a slate and explains its emotional journey. AI is the microwave for everything else. Each new model nukes a category of work in ninety seconds. We invent the foraged-radish version and act surprised the kitchen is busier. But I have to push back on my own analogy. Fine dining survived the microwave because eating is a status ritual humans evolved over millennia to care about. Most knowledge work isn’t. Nobody pays a premium for an artisanal expense report. The frame-moves-up story quietly assumes infinite appetite for differentiation in domains where buyers actually want the radish microwaved and on their desk by Tuesday. There’s also a survivorship problem. Shipper is writing from inside a 30-person media company of unusually agentic people who turn every new tool into a new craft. Scale that to the real economy and you don’t necessarily get more senior analysts framing harder problems. You get one senior analyst doing the work of five. And four people looking for roles that haven’t been invented yet. The frame moves. The real question is whether the displaced people get to move with it.

This is the automation opportunity: Auto review → auto fix → auto verify. But the hard part is not just running agents in sequence. It requires: 1.AI-enabled staging environments 2.Tribal knowledge codified into context and skills 3.Dedicated review, fix, and verification agents Generation is cheap. Verified change is the bottleneck.

Here’s a key line in this mythos update. This is precisely an example of why engineers don’t go away, ever. We’ve made it far easier to create and find security issues, which means the new bottleneck is our ability to actually review, respond to, and fix the issues. Far from AI magically solving all of this, there still is major triage work and human judgment required to do the follow on work to actually protect systems. As a result, we’re about to enter a security engineer boom. Jevons paradox all over again.