The Pull Request Nobody Wrote
Autonomous coding loops are teaching software to maintain itself. The hard part is telling the machine when to stop.
At four minutes past nine on a Tuesday morning, an engineering team logs in to find a pull request waiting for review. The documentation for yesterday’s changes has been rewritten, the formatting has been tested, and a tidy summary sits in the team channel. It was opened at three in the morning. Nobody on the team wrote it. Nobody on the team was awake.
The first two essays in this series examined machines with bodies: humanoids on factory floors and the regulations chasing them. This one concerns machines with none, and it may describe the more consequential shift. Because while the world watches robots learn to walk, software engineering is quietly crossing a different threshold: from artificial intelligence that assists, to artificial intelligence that is delegated to.
From the copilot to the loop
For the past few years, generative artificial intelligence in software development has meant an interactive dance. The developer writes code, hits a wall, prompts an assistant, inspects the suggestion, and continues. The human never leaves the loop; the machine merely accelerates the human.
The emerging pattern, known in engineering circles as the AI loop, removes the human from active development entirely. A coding agent, running through command line tools, operates independently until a defined objective is met. It writes a change, observes the result, reads its own errors, and tries again, drawing on the reasoning of a large language model rather than a fixed script. Readers of my earlier work on agentic reasoning will recognise the structure immediately: perception, action, observation, and back to perception. The loop is the agency. Remove it and you have autocomplete. Preserve it and you have a colleague who never sleeps.
Every production loop reduces to two components. A trigger starts it: a manual command, a scheduled job that fires at midnight, or an event such as an engineer opening a pull request. A goal ends it, and here the design space splits in a way that deserves careful attention.
Thermostats and food critics
The first category is the verifiable goal: a deterministic, measurable target. Optimise until test coverage reaches one hundred percent. Refactor until every page loads in under fifty milliseconds. This is the thermostat model of autonomy. The system compares its state against a number, and the number, not the machine’s opinion, decides when the work is done.
The second category delegates termination to the model itself: refactor this module until you are satisfied the architecture is clean and simple. Practitioners call this the judge approach, where the model evaluates its own output. This is no longer a thermostat. It is asking a food critic to cook until the dish tastes right, with all the subjectivity that implies. The result can be excellent, but the termination condition now lives inside a reasoning process that no one can fully inspect.
The distinction matters far beyond engineering aesthetics. In the verifiable case, human intelligence is concentrated into the metric; in the judgment case, it is diffused into a hope. Organisations adopting loops will discover, sometimes expensively, that the craft has migrated from writing code to writing termination conditions
Where the loops earn their keep
The early returns are strongest exactly where human motivation is weakest: technical debt, tuning, and maintenance, the work engineers describe as important and treat as optional.
The overnight documentation sweep is the canonical example. Documentation decays the moment a fast moving team ships features. A loop that wakes nightly, scans every code change from the previous twenty four hours, rewrites the affected documentation, verifies the formatting, and opens a pull request converts a chronic organisational failure into a background process.
Continuous error remediation goes a step further. A loop monitors production error logs, and when a serious exception appears, it traces the stack back to the root cause, drafts a patch, runs the full test suite to confirm nothing else broke, opens a pull request, and posts the summary to the team. Compounding enough of these automations, a codebase begins, in a meaningful sense, to heal itself while its maintainers sleep.
The two ways it goes wrong
The enthusiasm deserves two sharp qualifications, and both are structural rather than teething problems.
The first is cost. An autonomous agent does not call a model once; it converses with itself recursively, feeding its own errors back into its own context, sometimes for ten hours at a stretch. Without programmatic guardrails, a single runaway agent chasing a minor bug can burn through thousands of dollars in application programming interface charges over an unattended weekend. The economics of the loop are the economics of a taxi with no meter and no destination.
The second failure is subtler: algorithmic aimlessness. Loops excel at optimising existing systems toward explicit metrics and struggle badly when told to create something new, to loop until a feature is complete. Lacking product intuition or awareness of business context, agents wander into logic traps, building sprawling and redundant subsystems that satisfy no actual user. Asked to replicate complex software by brute force, agents have run for days without converging on anything resembling parity. The lesson generalises: autonomy amplifies the clarity of its objective, including the absence of one.
Readers who followed the earlier essay on European machinery regulation will notice something uncomfortable here. A physical robot whose behaviour evolves after deployment must pass independent conformity assessment. A software agent rewriting a production codebase at three in the morning faces no equivalent regime. Its entire safety architecture is whatever budget cap and termination condition its designer remembered to write. For now, the guardrail is voluntary.
The engineer becomes the architect of stopping conditions
Which points to where the profession is heading. As loops move from experiment to enterprise infrastructure, the elite engineer’s value shifts away from tracking memory leaks and writing boilerplate tests, and toward designing tight, cost bounded, verifiable guardrails for autonomous agents. The builder who laid individual bricks becomes the architect of systems that build themselves.
I would frame the shift more pointedly. Writing a verifiable goal is an exercise in epistemology: deciding what counts as evidence that a job is done, and what could fool you into believing it. That has always been the hardest question in delegation, whether the delegate is a junior engineer or a reasoning model on a recursive budget. The organisations that thrive with AI loops will be those that treat the human machine boundary as a deliberate design decision, placing humans where judgment is genuinely required and machines where verification is genuinely possible.
The pull request from three in the morning is a preview of that equilibrium. It is also a test: whoever reviews it at four minutes past nine is now the last human in the loop, and the quality of their attention is the system’s real safety margin. The machines have learned to work through the night. Our job is to remain worth waking up for.
If this analysis was useful, subscribe for future essays on robotics governance, hybrid intelligence, and the strategy of intelligent systems. I read every reply.