Igor Minarkov on AI Engineering: Why the Pull Request Is Dying
Igor Minarkov — Senior Software Engineer & AI Engineering Strategist
Igor Minarkov is a Senior Software Engineer and AI Engineering Strategist whose thinking sits at the cutting edge of how AI agents are restructuring the software development lifecycle. His central thesis: that the pull request is no longer fit to be the primary unit of trust in an AI-native world, challenges assumptions that most engineering teams have not yet had to confront.
Igor is careful with his provocation. "When I say 'the pull request is dying,' I don't mean code review is dying. I think the pull request as the primary unit of trust is dying." The traditional PR workflow made complete sense when humans produced most of the code: a developer writes a change, a colleague reviews it, CI runs checks, and someone clicks approve. But that logic breaks down when AI agents are on both sides of the transaction.
If an AI agent implements a feature, another agent reviews it, tests run automatically, security checks execute automatically, and the application is deployed into an isolated environment where its actual behaviour is verified; what, exactly, is the human being asked to do? As Igor put it, reading 3,000 lines of AI-generated code and clicking "Looks good to me" is not scalable.
His proposed shift is from reviewing code to reviewing evidence. Rather than asking whether someone read every line, teams will increasingly ask: Did the tests pass? Did behaviour match the specification? Did performance change? Was a security issue introduced? Can the change be safely rolled back? "The review doesn't disappear. The trust model changes," he says, and he considers that a far bigger transformation than simply using AI to write code faster.
If execution is becoming dramatically cheaper, the scarce and expensive thing is judgment. Igor makes the economics plain: where it once took days to explore five different implementation approaches, an AI agent may soon produce five working implementations in twenty minutes. The new engineering challenge is not how to build something; it is which of these things should exist at all.
"A strong engineer needs to understand architecture, product requirements, business constraints, security, maintainability, and the second-order effects of a technical decision," he explains. Crucially, the best engineering decision is sometimes to write no code: because the feature should not exist, because a system already solves the problem, or because an additional abstraction makes the architecture worse.
His conclusion is direct: "AI is very good at answering: 'How can I build this?' But somebody still needs to ask: 'Should we build this?' That's why I think the value of engineers gradually moves higher up the decision stack. When execution becomes cheap, judgment becomes expensive."
Igor rejects any single universal answer in favour of a risk-calibrated framework. The key variable is what he calls the blast radius: the potential scope of damage if something goes wrong. An agent adjusting button spacing within a visual regression test suite warrants a high degree of autonomy. An agent proposing a database migration in production is an entirely different conversation.
So the right question, in his view, is not "Should AI be autonomous?" but "Under what conditions is autonomy safe?" He outlines several requirements for safe autonomy: the agent must have the right context and clearly defined permissions; it should operate inside a sandbox where appropriate; its output needs automated verification; the team needs observability into what the agent actually did; and there must be a reliable rollback path.
He is equally clear about what the goal is not: "I don't think the future is humans manually approving every action an AI takes. That would destroy much of the leverage we're trying to create." The objective is to build systems where removing a human from certain loops is demonstrably safe, not to keep humans in every loop by default.
Asked to allocate a $10 million founding investment, headcount would not be Igor's first move. "I'd invest in the system that multiplies the capability of every person I eventually hire."
He draws a sharp line between companies that layer AI tools on top of an existing organisation. Useful, but not truly AI-native, and companies designed from day one with AI agents as part of the workforce. That design means investing early in internal context and documentation, agent infrastructure, automated testing and evaluation, observability, permissions, and human-agent collaboration workflows. Only then would he hire a small number of exceptionally strong engineers and product people: people who are good at making decisions and designing systems, not just writing code.
The reframe he offers is telling: instead of asking "How many engineers can I hire with $10 million?", ask "How much execution capacity can each great engineer control?" If one excellent engineer with the right AI infrastructure can coordinate the execution capacity that previously required an entire team, the economics of building software change fundamentally.
Igor sees implementation (the manual translation of requirements into code) as the layer most likely to be unrecognisable within five years. He expects that much of that work will be generated and executed by machines: you describe the outcome, define constraints and architecture, and agents implement, test, verify, and potentially maintain significant parts of the system.
But he is notably optimistic about what stays human. Intent, judgment, taste, responsibility, understanding people, understanding the business, and deciding which problems are worth solving. Those, he argues, will remain stubbornly human. "AI may become incredibly good at answering: 'How do we build this?' But humans will still have to answer: 'Should we build this? Why? And what happens if we're wrong?'"
The engineer does not disappear in his telling. The engineer moves up a level — from manually producing every piece of code to designing, directing, and taking responsibility for increasingly powerful systems.
Comments
No comments yet — be the first to share your thoughts.