The tight feedback loop was the foundation of how we learned to code. Change something, observe what happens, adjust. Each iteration was small enough to fit comfortably in your head — a line changed, a function modified, a behaviour observed. You could hold the entire scope of what you’d just done, understand its implications, and course-correct instantly if something felt wrong. The loop was so tight that thinking and doing blurred together into a single continuous activity. This wasn’t just a convenient way to work. It was how the craft of programming developed over decades, how IDEs evolved to support us, how we trained our intuitions about what good code looks like and how systems behave.
Traditional development had a particular cadence that shaped everything about how we approached problems. You typed a line, you saw what happened, you adjusted and tried again. The feedback was immediate, the changes were small, and the cost of being wrong was negligible. A bad keystroke could be undone in seconds. A mistaken approach could be abandoned and restarted before lunch. This tight coupling between action and feedback shaped how we learned, how we debugged, how we designed. IDEs optimised for exactly this rhythm — syntax highlighting showed errors as you typed, autocomplete suggested the next character, tests ran on save. The entire environment assumed you were there, watching, present and ready to respond to what you saw. The cost of changing direction was near zero. If you started down the wrong path, you noticed within minutes — before much had been invested, before the wrong approach had propagated through the codebase, before anyone else had built on top of your mistaken foundation. Pivoting was cheap because iterations were small.
The shift in scale
Asynchronous, agent-assisted work operates at a fundamentally different granularity. Instead of keystroke-by-keystroke, changes arrive commit-by-commit. Instead of line-by-line adjustments, you’re reviewing feature-by-feature, sometimes system-by-system. The amount of change between feedback moments grows dramatically — not incrementally more, but categorically different. When an agent works overnight, it doesn’t produce a few lines for you to review in the morning. It might produce hundreds of lines across dozens of files, implementing a feature that would have taken you a week of tight loops to build yourself. A draft of something substantial, awaiting your judgment. But you weren’t there for the small iterations. You weren’t adjusting keystroke by keystroke, watching for the subtle signs that something was drifting off course. You wake to the accumulated result of work you didn’t witness.
The economics of pivoting shift in an interesting way. In the old loop, abandoning a wrong approach cost minutes — you noticed the problem early, backed out, tried something else. The investment lost was trivial. In async work, the generated output might be substantial, but discarding it costs little because regenerating is cheap. Tweak the requirements, adjust the direction, and a new implementation appears in minutes. The code itself becomes disposable. What changes is not the cost of pivoting but the cognitive cost: you have to review enough of the output to realise it’s wrong in the first place. The challenge isn’t losing work — it’s recognising when to redirect before you’ve invested attention in the wrong direction, when the signal that something is off might be buried in a large diff you haven’t fully absorbed.
Implementation as exploration
Something counterintuitive emerges from this shift in economics. When implementation is cheap — when agents can build quickly and tirelessly — the cost structure of exploration changes in ways we’re still learning to navigate. You can build to learn, not just build to ship. A working prototype doesn’t require weeks of your time anymore. You can describe an approach, see it realised as actual running code, evaluate whether it works the way you imagined, and refine your understanding based on what you learned from seeing it concrete rather than abstract. Then update the requirements based on that learning. Then implement again. Working software becomes a tool for discovering requirements, not just fulfilling them. The iteration loop moves upstream: build, learn, refine the spec, build again. Prototyping shifts from low-fidelity mockups and wireframes to actual working systems that you can use, test, and react to.
This is genuinely new territory. When building was expensive — when every feature required days or weeks of careful human effort — you specified carefully first because rework was costly. You invested in upfront design because mistakes discovered late were expensive to fix. The entire discipline of software engineering developed around managing this cost: requirements gathering, design documents, architecture reviews, all aimed at getting things right before the expensive implementation phase began. When building becomes cheap, specification can emerge from exploration rather than preceding it. You don’t have to get the requirements perfectly right upfront — you can discover them through rapid, disposable implementation. The trade-off, though, is significant: each iteration produces a large change, a substantial delta from where you were before. The feedback is valuable, but digesting it requires more than glancing at a single line of code or a simple test result.
The context gap
This is where human cognition becomes the constraining factor, though not quite in the way you might expect. AI context windows have grown enormous — 100,000 tokens, 200,000, a million or more. An agent can hold an entire codebase in working memory, every file, every function, every edge case, all present and accessible simultaneously. Human working memory operates on a completely different scale. We hold perhaps four to seven items at a time, a few thousand words at best if we’re really stretching. This sounds like a crippling limitation, but it’s not quite that simple. Humans don’t need to hold code line by line. We work in abstractions, in patterns, in architectural understanding. We can hold a system conceptually — its shape, its flows, its key decisions — even when we couldn’t recite its implementation. An experienced developer can reason about a large codebase without having every line loaded, because they understand the structure and can navigate to details when needed.
The real asymmetry isn’t code comprehension. It’s something broader and more consequential. An AI can hold — or will soon be able to hold — the entire business context in which the code operates. Domain knowledge, industry regulations, competitor approaches, historical patterns in customer behaviour, standards and conventions that took years for humans to learn. Context that no single human fully possesses, that exists distributed across teams and documents and institutional memory. The gap isn’t “the agent knows your codebase better than you.” It’s “the agent might know your industry better than you, your regulations better than you, your customers’ historical patterns better than you, the full implications of your architectural choices across contexts you haven’t considered.” This changes what alignment means between human direction and AI execution. You’re not just worried about whether the agent understood your instructions. You’re wondering whether the agent understood implications you didn’t even think to mention.
The alignment question
When you work synchronously, alignment happens naturally through the tight feedback loop. You type, you see, you adjust. Misunderstandings surface immediately because feedback is immediate. If you meant one thing and the code does another, you notice within seconds. The loop is tight enough that drift gets corrected before it compounds, before a small misunderstanding becomes a large structural problem. You and your tools are in constant conversation, each small step validated before the next begins. Async work introduces a gap into this conversation. You direct at the level of intent and architecture — “implement a caching layer” or “refactor this module for testability.” The agent works at the level of implementation — specific classes, specific methods, specific decisions about how to realise your intent. You often can’t verify alignment at the detail level; your context is too limited for that, and the output is too large to review exhaustively. You have to trust the patterns, trust the process, trust the abstractions.
This creates risk of false agreement that’s difficult to detect until it causes problems. Both you and the agent think you understand each other. Neither fully does. You said “caching layer” and meant one thing; the agent interpreted it and built something subtly different. The words matched; the mental models didn’t. This kind of misalignment surfaces late, as bugs that don’t quite make sense, as behaviour that’s “not what I meant” in ways hard to articulate, as architectural decisions that feel slightly off without being obviously wrong. When the feedback loop was tight, these misunderstandings resolved in minutes — you saw the wrong behaviour immediately and corrected course. When the loop stretches across hours or days, the cost compounds. More gets built on the misaligned foundation before anyone notices the drift.
When change exceeds review capacity
This is worth sitting with as a set of questions rather than assertions, because the answers likely depend on context in ways we’re still discovering. Can you still hold the whole diff in your head? At what scale does that stop being possible — a hundred lines, a thousand, ten thousand? Does review become sampling — checking representative parts rather than examining everything? Or can comprehensive review still happen, just differently, with different tools and techniques? Do you trust patterns over line-by-line inspection, relying on consistency and convention rather than verifying each decision? Does experience become “knowing where to look” rather than “seeing everything”? If you’ve been doing this long enough, do you develop intuitions about where problems hide, which parts of a large change deserve close attention and which can be trusted?
What role do tests, linting, and CI play in this new dynamic — safety net, or substitute for understanding? If the automated checks pass, how much do you need to understand the implementation? Does the skill shift from “reading code” to “triaging risk,” from comprehensive understanding to probabilistic assessment? These aren’t rhetorical questions with obvious answers. They’re genuine uncertainties that different teams, different contexts, different kinds of work will likely answer differently. A safety-critical system demands different review practices than an internal tool. A team with deep domain expertise operates differently than one exploring unfamiliar territory. The answers are still being discovered through practice.
What this means for upfront work
If iteration is cheap and implementation is fast, what happens to the traditional emphasis on getting requirements right before building? Perhaps upfront clarity becomes less critical — not because direction doesn’t matter, but because the cost of learning through building has dropped so dramatically. You can discover what you actually need by seeing what you get. You can build three different approaches and compare them, rather than trying to reason about which would be best in the abstract. Specification becomes iterative rather than front-loaded, emerging from exploration rather than preceding it.
But there’s a counterweight to this optimism. If each iteration produces a large change that’s difficult to fully review, then direction matters more even if details matter less. You need enough clarity to avoid wasted cycles, even if you don’t need complete clarity to begin. A wrong direction pursued through three rapid iterations still costs time and attention, even if implementation is cheap. The cognitive load of reviewing those iterations isn’t free. The balance is genuinely unclear, and different kinds of work will find different answers. Perhaps the new discipline is knowing how much direction is “enough” to start — not so much that you’re over-specifying, not so little that you’re wandering.
Where this leaves us
The tight feedback loop fit human cognition beautifully. Each change was small enough to understand completely. You could hold it, evaluate it, adjust it before moving on. The rhythm matched how we think, how we learn, how we build confidence that what we’re creating is actually what we intended. Async work changes the scale of that loop in ways that challenge our cognitive capacity. Changes arrive in larger chunks. Feedback stretches across longer intervals. The amount you’re asked to evaluate exceeds what fits comfortably in working memory, even when you’re working in abstractions rather than line-by-line detail.
But quality, learning, and accountability aren’t negotiable. They’re not nice-to-haves that we can trade away for speed. They’re requirements that any AI-assisted process must meet, regardless of how the underlying work gets done. The question isn’t whether we need quality — of course we do. The question is how we achieve it when the old mechanisms no longer fit. When the tight loops that gave us confidence and control have stretched into something less familiar, something that requires new skills and new disciplines to navigate well. We’re still learning what review looks like at this scale. Still learning what “understanding” means when you can’t trace every line. Still learning how to maintain accountability when you weren’t there for the building. The feedback loop hasn’t disappeared. It’s stretched. And we’re stretching with it, developing new intuitions to replace the old ones, new practices to maintain the quality that never stopped mattering.