AI coding tools have made writing code faster, but three pieces published on 12 October show the delay moving to checking, debugging and running that code. Each describes a different response: measuring quality instead of output, planning around assumptions that can expire, and redesigning operations so that people supervise AI agents.
Chris Stokel-Walker (13 Oct · 01), a freelance technology journalist writing for LeadDev, reports on a survey by Undo, a company that sells debugging tools. Undo asked 300 senior engineering leaders at large US and UK companies about code written with AI tools. Eighty-one per cent said their organisation had a production incident or outage linked to those tools in the last six months. Engineers in the survey spend 16.9 hours a week debugging and 9.8 hours writing code, and 79% report release cycles no faster than before. Undo's report recommends measuring defect rates and time to resolve problems rather than lines of code, and the figures come from a vendor that sells debugging software.
Robert Kimani (13 Oct · 02), a site reliability engineer and consultant writing for LeadDev, describes how an engineering strategy fails when AI changes the conditions it was built on. In his example, a leader approves five hires, an internal AI platform and a reorganisation of two teams. Six months later, developers produce more code, but pull requests take longer to review and build queues grow. Kimani recommends a short list of the assumptions behind each major plan. Each assumption gets a signal to watch, a named person responsible and a condition that triggers a fresh review, such as review capacity growing slower than implementation.
Zichuan Xiong (13 Oct · 03), writing for Thoughtworks, a technology consultancy, describes two years of its AI practice building AI agents for IT operations work. In late 2024 the agents only suggested replies to support tickets, and a person stayed in charge. In 2025, agents handled simple requests first, and a person stepped in when the agent's confidence was low. Xiong writes that the next risk was "whether reviewers were still checking the output or simply approving it," and he treats it as the problem of that stage. Since early 2026, agents have planned fixes, opened pull requests, tested them in a sandbox and closed tickets. In September the team moved its triage agents to decision models, which are AI models that classify and decide rather than write text, because they cost less.
All three pieces place the slow step after the code is written: in debugging, in review queues and in supervising agents that act on their own. The survey supplies the scale, the strategy essay a way to notice when a plan's premise breaks, and the Thoughtworks account a team that redesigned roles around supervision. This issue infers, and none of the authors claims, that a team adopting AI agents needs to fund checking and debugging as deliberately as it funds code generation.
The strongest numbers come from Undo, which sells debugging tools, and the Thoughtworks account reports no measured results. The slowdown may also be a temporary adjustment that better review tools will remove.
A survey by Undo, a debugging company, finds 81% of 300 engineering leaders linked a production incident to AI coding tools in the past six months.
Robert Kimani, a site reliability consultant, argues engineering strategies built on AI productivity should list their assumptions, each with a signal, a responsible person and a review trigger.
Thoughtworks moved its IT operations AI agents from suggesting replies to opening and testing fixes, and Zichuan Xiong says people now supervise the agents instead of doing the work.