The current buzzword in AI is “Loop Engineering,” and I’m not even mad about it. A lot of smart people have written sharp posts on why working in loops is a great way to get the most out of frontier models, even if they might financially ruin you. A few examples:
- @addyosmani gave a clear overview of the core components required for loop engineering.
- @sydneyrunkle broke down different kinds of loops and discussed hill-climbing loops to rewrite the agent harness with improved configurations.
- @RLanceMartin showcases how the late Claude Fable 5 excelled at long-horizon tasks that can be orchestrated through loops.
As an ML & AI engineer, I try to understand how the ideas behind Loop Engineering can help me in my daily work orchestrating coding agents. I believe that harnessing the power of these agents, and the loops that drive them, will set apart the next generation of builders.
That belief is what pushed me to get my hands dirty with loops in the first place. They’re amazing when they work as intended, but in practice I’ve found harnessing and directing that power far more challenging than the posts let on. As models get more capable, the complexity of the problems they can solve expands; especially once you wrap them in self-correcting loops. But so does the volume of their output, and the number of implicit and explicit decisions they make on your behalf.
That is also what makes them dangerous. The loop produces faster than I can understand what it produced, and the gap between the two is where the trouble starts: within hours I can ship a complex feature I don’t fully understand, on top of a system I don’t understand either.
Comprehension Debt
Every loop leaves you with something you haven’t done yet: understood what it built. I’m not suggesting to understand every line of code written (that is not realistic at this pace anyway), but thoroughly understanding the changes you are shipping and the decisions being made along the way, the explicit ones and the quiet ones. Skip that and the problem doesn’t disappear, it accrues. Like tech debt, except what you owe is understanding. I call this the comprehension debt.
Where the debt comes from
I’ve been speaking to a lot of engineers lately about their struggles with comprehension debt. From where I stand, it’s a symptom of one common root cause: context pollution, not of the AI model, but of our own human brains. Overload that context window and there’s no room left to properly understand what you’re building, which only accrues more debt. Every engineer has experienced this in some form, and I found there are 4 main culprits for this:
- Delivery Speed. As engineers adopt more AI in their day-to-day, the expectation from their employer rises right along with it: deploy, support, and iterate on features at breakneck speed. Even more so if you’re at a company building AI-native tooling or products (godspeed to you).
- Parallel Problem Solving. On top of shipping at lightspeed, not one developer I’ve spoken to is working on a single feature at a time (guilty myself). So I’m juggling three or four problems at once, each with its own context and stakeholders, designing a solution for each. Rotating between them also means rehydrating my own context every time I switch back. It’s slow, and honestly soul-crushing.
- A codebase that won’t sit still. You’re not the only one fighting this. Everyone in your org is going through the same motions, shipping thousands of lines a day under the same expectations and context constraints. Systems can change overnight, and the assumptions you had on Monday don’t survive to the end of the week. On top of that, you still have to dock your own solution onto a system that keeps moving, like that docking scene in Interstellar where Cooper has to match a spinning ship.
- AI slop essays. This is the one I’ve heard echoed the most by engineers and non-engineers alike: the shameless verbosity AI comes with. You can diligently read three whole paragraphs it produced only to realize you didn’t learn a single new thing. Or worse, your attention gets yanked in ten new directions it happened to mention along the way. My firm belief is that this kind of output is written for other AI agents, not for our human minds.
Repeat these patterns daily and the debt grows faster than you can ever pay it down. The danger isn’t falling behind on the reading; it’s what you start doing to keep up: you let things through.
Architecture by Ratification
Keep letting things through, and the debt curdles into something specific: it turns you into a rubber stamp. You still own the delivery and approve every design, but you’ve stopped deciding; you’re just ratifying what the agent hands you. This is the failure mode I’m trying to avoid, and comprehension debt is what gets you there. Each approval feels manageable, so you grant it. But the gap between what the agent built and what you actually understood widens with every cycle. You start skimming the plans, then trusting the summaries instead of the plans, then approving because nothing has obviously broken yet; which is not the same as knowing why it’s right. There’s no single moment when you decide to stop being the architect; you just drift, one approval at a time, into architecture by ratification.
What that costs is the thing that made us excellent engineers in the first place: knowing a system inside out, owning it, and being able to criticize it from every angle. That’s the first thing the debt takes.
Stay the Architect-in-the-Loop
A loop is only as powerful as your understanding of what it’s meant to build. The objective, then, is to aggressively reduce context pollution and repay comprehension debt with due diligence, so you truly understand the changes being made. Done right, momentum tips in your favor: you ship fast, and you understand and stand behind every change you make. You stop being the human-in-the-loop approving an architecture driven by agents. You become the architect-in-the-loop: designing the solution with the AI, owning the decisions and trade-offs, and leading the changes it implements.
In my own hill-climb to become and stay the architect-in-the-loop, I’ve crafted a set of skills aimed squarely at keeping context pollution and comprehension debt in check. The philosophy is simple: humans understand far more slowly than agents can produce, so any plan a loop is about to implement must be fully comprehended by the human before a single change is made. I’ve open-sourced these core skills in the architect-in-the-loop repository.
pair— sets the tone and style of the conversation to cut down on AI prose.teach— sets the pace so you can get up to speed on a concept, component, or system, one step at a time.goal-alignment— the loop design itself, and the heart of the repo. It ensures you understand the design decisions before anything runs, then sets up the loop with pre-flight checks, subagents, critics, and loop evaluators.
In the next post, I’ll describe how I use these skills day-to-day, where they pay off and where they still fall short. These are working notes, so if you’re fighting the same thing, I want to hear what’s working for you.