.png){kind=logo}
Most debates about AI in software still ask how much code a machine can write. Jaime Leo Mizrachi thinks that question is already out of date. Agents like Devin, Cognition’s autonomous AI software engineer, are moving from writing code to carrying out whole outcomes: completing a migration, closing a vulnerability, shipping a feature end to end. Once that happens, he argues, the scarce thing inside an engineering organization stops being code, or even review, and becomes confidence that the outcome is right.
Mizrachi, Deployed Engineering Lead for Latin America and Spain at Cognition, the maker of Devin, puts it simply: whatever you can verify, you can delegate. People stop reading every line an agent writes and start checking results. Did the migration preserve behavior? Is the vulnerability actually gone? Companies that can answer those questions quickly can hand agents far more work than companies that can’t, regardless of how many engineers they have.
He came to the idea through deployment work, not theory. Since joining Cognition as its first Forward Deployed Engineering hire, he has run enterprise rollouts where agents had to work inside real banks and engineering organizations, and he kept seeing the same split. Where a team had agreed in advance on what “done” meant, agents took on more and more of the work. Where it hadn’t, every result needed a person to inspect it line by line, and the speed gain disappeared.
“Buying an agent is easy compared with integrating it into real engineering work,” Mizrachi said. “Teams need the right use cases, the right context, and a process that makes delegation routine.”
He points to two public Cognition customers. Itaú, Brazil’s largest bank, uses Devin to resolve about 70% of the vulnerabilities its security scanners flag, and the same scanners confirm each fix. Nubank built the check before the work: ahead of migrating its eight-year-old core ETL monolith, the team turned migrations its engineers had already done by hand into a benchmark, and business units went on to finish their migrations in weeks instead of months or years.
That leads to his most forward-looking claim. The frontier of automation will follow the frontier of verification. Work with well-defined, testable outcomes gets delegated first; work whose results are hard to check stays with people until someone figures out how to check it. In his view, the best engineering investment a company can make right now goes into the acceptance criteria, test suites, evals and production signals that let it trust results at scale.
“Better specifications and stronger evaluation matter more than generating code faster,” he said. “The assignment has to be clear enough for the agent to perform and for the engineer to judge.”
The same lens explains agent mistakes. Mizrachi tells teams to read an error that keeps coming back as a signal about the system around the agent: a vague definition of success, missing context, or a check that can’t catch the problem.
“Recurring patterns can show where the team needs to investigate more closely,” he said. “The issue may involve the agent, the available context, or the way the task was defined.”
It also changes what return on investment means. Counting tickets closed or lines written says little when one engineer directs several agents at once, so Mizrachi pushes the teams he works with to measure verified outcomes instead: how much faster a migration finished, what it cost, and whether the fixes held up in production.
His view of deployment started before Cognition. At Palantir, Mizrachi worked on mission-critical systems and led a five-person Forward Deployed Engineering team, which taught him how much engineering and organizational work stands between a capable technology and something an institution can depend on.
He expects the engineer’s job to tilt toward defining what “done” means and proving that it happened. Technical depth still matters, though more of it goes into designing checks and judging evidence than into typing code.
“The real shift is how human attention is allocated,” he said. “Engineers will spend more time deciding what should be built, how the work should be structured, and whether the result meets the standard required for production.”
His advice to engineering leaders follows from that: treat verification as a strategic asset rather than a step at the end of the process, because the companies that build it first will be the ones able to hand agents their hardest work.