Software agents succeed when codebases have fast, explicit, automated ways to verify their work.
2
Teams can improve agent performance by strengthening linters, tests, documentation, and other validation systems instead of spending weeks comparing tools.
3
Better agents improve the environment, and a better environment gives agents stronger feedback, creating a cycle that can support more autonomous software delivery.
Summary
Eno Reyes argues that the main limit on software agents is the codebase around them. Human engineers can work with incomplete tests, flaky builds, undocumented dependencies, and informal practices. Agents need those expectations made explicit and mechanically verifiable. Reyes frames this as a shift from traditional specification-driven development toward development built around verification: define constraints, generate a solution, run automated checks, and iterate. Strong validation lets teams use agents for larger workflows, including parallel tasks, code review, testing, and modernization work. It also gives organizations a way to find and fix weaknesses in their engineering environment. Reyes says the resulting feedback loop improves both agents and the codebase. He is direct that this requires investment in engineering practices, rather than a procurement decision or a better model alone. The talk presents agent readiness as an operational discipline built from reliable checks, clear documentation, and measurable improvement.
Software becomes more automatable when its results are easy to verify
Reyes uses Andre Karpathy's idea of Software 2.0 to describe a shift toward automation through verification. Traditional development starts with a specification such as an algorithm that maps input X to output Y. A verification-oriented approach asks whether an objective can be specified and whether possible solutions can be searched and checked. Reyes points to tasks that are easier to verify than to solve, especially when they have objective truth, quick validation, scalable checks, low noise, and continuous signals rather than only yes-or-no outcomes. He says software development fits this pattern unusually well because decades of work have produced tests, QA systems, API specifications, and other automated checks.
Human tolerance for weak checks becomes an agent failure mode
Many codebases work for human teams despite incomplete validation. Reyes describes test coverage around 50% or 60%, flaky builds that fail every third time, and undocumented practices that engineers quietly understand. People can fill in the gaps through manual testing and experience. Agents cannot reliably do that. Once agents work across coding, review, documentation, and testing, missing or weak checks reduce their ability to produce dependable changes. Reyes says organizations with rigorous validation can use agents more effectively than an average developer working in a less prepared repository.
Agents need explicit validation criteria before teams can scale their workflows
Reyes describes an agent workflow that starts by specifying constraints and the desired outcome, generates a solution, verifies it with automated checks and human judgment, then iterates. This enables more than a single coding task. If a pull request cannot be checked automatically for likely correctness and production safety, a team will not confidently run several agents in parallel or split a large modernization project into many subtasks. Agents may improve at finding tests, running linters, and searching for solutions, but Reyes says they will not invent the organization's validation criteria from nothing. Those criteria have to be supplied by the engineering environment.
Engineering teams should improve the environment before choosing among agents
Reyes questions whether an organization should spend 45 days comparing coding tools to find one that scores slightly better on a benchmark such as SWE-bench. He recommends changing organizational practices so that different agents can succeed, then choosing a tool developers like or allowing people to choose among available tools. He describes eight areas of automated validation, including the quality of a linter and the presence of AGENTS.md files, an open standard supported by most coding agents. Measuring these areas can reveal where a repository is holding agents back.
Agent readiness can expose missing practices that affect less experienced developers
Reyes says teams can compare agent reliability across developers and investigate why some people get less value from the tools. The cause may be missing automated checks for niche practices, rather than a developer's ability or knowledge of the tool. He compares this with large organizations such as Google or Meta, where extensive validation makes it possible for a change with little context to reach production without bringing down a service used by a billion people. Agents can help find these gaps, improve linter rules, and generate tests that encode the intended behavior.
Reyes quotes Factory engineer Alvin saying, "A slop test is better than no test." He argues that a first test can still provide a check that passes when a change is correct and roughly matches the desired specification. Engineers can improve it, and later agents can follow its patterns. The more opinionated the repository becomes, the faster this cycle can continue. Reyes describes a loop in which better agents improve the environment, the improved environment makes agents more effective, and the resulting time savings allow engineers to improve the environment again.
Reyes calls this the new DevX loop and says it benefits every software tool an organization buys, including code review tools and coding agents. Leaders can invest in the environment feedback loop alongside hiring people for engineering work. An agent that actively looks for linters, tests, and other validation criteria will perform better than one that does not. Reyes also says an opinionated engineer can extend their influence across an entire business when the organization can measure and improve the resulting practices.
The limit on fast autonomous delivery is organizational validation
Reyes describes a possible flow in which a customer issue becomes a ticket, an agent fixes it, a developer approves the change, and the code reaches production within an hour or two. He says this flow is technically feasible today, while the limiting factor is the organization's validation criteria. In his view, the required work will not appear automatically through AI. Teams must choose to invest in it. He presents that investment as the source of much larger gains than simply adding another tool, while acknowledging that it requires sustained engineering work.
"The limiter is not the capability of the coding agent. The limit is your organization's validation criteria."14:28
Who should watch
Your team is trying coding agents in production, but flaky builds, partial test coverage, or undocumented practices make their output unreliable.
You are deciding whether to spend time comparing agent products or improve the repository's linters, tests, documentation, and development environment first.
You lead engineering and want a way to support larger agent workflows, such as parallel changes or automated issue-to-production pipelines.
