The Loop Doesn't Need You Anymore
In May of 2026, Aetheron's Slack workspace was overrun by coding agents. Over the next two months, we rebuilt our engineering workflow from the ground up. Throughput rose, our comms came back, and we stopped spending all day babysitting our agents. The important change was moving human review upstream from implementation to intent.
I could see the same loop running across the team's local machines. Claude implemented a change and requested a review in Slack, review agents filled the PR with comments, then Claude picked up the fixes and requested another review. Code, request, review, repeat, and every step produced another Slack message. We had become meat proxies, shuttling context between agents that could not yet coordinate themselves.
I found myself avoiding the walls of text in our dev channels as human conversation became harder to find. Standup became the only place I could understand what was going on, and even there questions were increasingly answered with "I'll have to ask Claude."
The uncomfortable part was that, in some sense, it was working. Code was moving faster, but everything around it was deteriorating. Reviews that once took one or two rounds could run for five or ten, with progressively less meaningful comments arriving each round. The working norms that had brought a review to an end had dissolved: what should block, what should be deferred, and when a PR was ready were no longer clear. We had created an “autonomous” system with a human orchestration layer, and that layer was buckling under the load.
Hitting the eject button
The obvious response was to regain control through policy: redefine review norms, implement comment budgets, move the agent messages elsewhere. That might have worked for a while, but what would happen in another three months when AI would write the same code in half the time? The bottleneck was now well and truly our finite attention, and we weren't going to solve that just by directing traffic. So instead we decided Anthropic were right, coding was solved, and it was time to get out of the agents' way.
We kept the loop that had emerged organically, but moved human review upstream of it and bounded the iterations. Now, our time is spent deciding what is worth building and why. We write a spec covering the problem, context, constraints, and high-level design, and this is what the team reviews — the intent, not the result. This becomes a contract against which the finished work is judged, much the same way we use acceptance criteria to judge when a user story is complete.
We don’t always use the pipeline to write the first version. When we want more control, we build locally with an agent, then hand the PR to the pipeline for the review-and-fix loop. We still pretty much always start with a spec in Jira.
We built a panel of judges that aggregates the team's various review methods and perspectives. Findings are iterated on inside the loop, and repetitions are bounded by finding severity and cycle caps. If the loop cannot resolve the findings within its budget, it stops for a human.
The judges check both the implementation and its conformance with the agreed spec. Concrete defects go back through the loop to be fixed. Unresolved product decisions come back to us. Once the judges approve, the checks pass, and there is no outstanding human decision, eligible changes merge automatically. A human has already approved the intent. We are not there to review the whole implementation again, but to settle the questions the spec did not answer.
Checking against the spec
- Requirements: Does the implementation satisfy the acceptance criteria, promised behaviour, and important boundary cases?
- Scope: Did the change stay inside the requested boundaries and honour the spec's explicit non-goals?
- Approach delta: Where did the implementation depart from the agreed approach, and is the rationale adequate?
- Verification: Do the checks and supplied evidence cover the risky paths, environments, and rollout claims?
Example: One recent change let an assistant end a call silently through the API. All three judges approved the change, but the review surfaced a question: the settings form still required a closing message. Should the UI allow silence too, or was this intended to be API-only? Rather than quietly expanding the scope, the pipeline brought that decision back to a human.
What we got back
The process now moves substantially more work with far less coordination around each change. We spend far less time managing reviews, and ideas reach merge much faster. Obviously, this is not a clean causal experiment — demand, work mix, and models have changed, and a PR is not a unit of customer value — but the direction is hard to miss. What I can say anecdotally is that I haven't seen a corresponding increase in production incidents or hotfixes.
Uncertainties aside, the thing I care most about is that we've been able to restore team communication. We're by no means slop-free when it comes to discussing technical decisions, but productive discourse has returned. With less implementation work and far less context switching, we have the space to think together again in a way we haven't since agentic development took off. Babysitting agents is no longer the core of our engineering day. The work has shifted towards deciding what to build, for whom, and where to point all the new throughput to actually deliver results.
Our experience before and after this shift has really highlighted a critical fact of our new agentic development world: faster implementation makes good team communication more important, not less. We can build the wrong thing so fast we won't even realise someone is working on it until it's in prod. Having more time to talk about and think about the what and the why is already having a hugely positive impact on our culture, product and customers, and I am really excited about what the team can do as we get to spend even more time on these parts of the job.
Expanding the loop
For us, Dev may be dead, but Ops is back in a big way. More throughput means more release, incident, and operational work. The next step is therefore to bring the path to production inside the loop so we can begin to understand how to make improvements and automate further.
We have closed the loop around implementation, but we have not yet closed the loop between the system and the world. Our instrumentation can describe what happened inside a run, but not whether its output improved the product. To really improve from here we need to be able to start with a production bug or a quiet success and trace it back to the run that produced it. Until we can, our judgements about which prompt, model and workflow changes are good are educated guesses at best.
Closing that outer loop will be hard. Outcomes emerge from collections of compounding changes, attribution is murky, and success unfolds over long timescales. I don't know how we solve that yet, but that is where the work has moved: from producing code to improving the system that produces it.