Same Loop, Different Name?

ThoughtWorks recently published The Future of Software Engineering—a synthesis from a multi-day retreat where senior engineering practitioners gathered under the Chatham House Rule to talk about the question that’s eating every engineering organization alive right now: if AI handles the code, where does the engineering go? I highly recommend reading the excellent report to everyone working in software engineering.

I read it cover to cover, then went back to my own code.talks talk from a few weeks earlier and thought: wait, I know this.

ThoughtWorks found a loop

The retreat’s strongest first-mover concept, as the authors call it: a middle loop. A new category of supervisory engineering work sitting between the inner loop (writing code) and the outer loop (CI/CD, deployment, operations). “Nobody in the industry has named this yet,” they write.

The middle loop involves directing and evaluating agent output, decomposing problems into agent-sized work packages, calibrating trust, recognizing when agents produce plausible-looking but wrong results, and maintaining architectural coherence across parallel streams of generated work.

“We kept asking the same question in every room: if AI handles the code, where does the engineering actually go? Nobody had the same answer. But everybody agreed the question is urgent.”

I’d been calling this the elastic loop. Different angle—I modeled it as a spectrum from tight (you review every agent turn) to loose (you delegate and check later) rather than a distinct new layer. But we’re clearly looking at the same thing here.

The timing is close enough that nobody “got there first.” Seems like it’s convergent evolution. Usually a sign there’s something to it!

The overlaps between the “middle loop” and the “elastic loop”

ThoughtWorks describes three traits of practitioners who excel at this new work: they think in delegation and orchestration, they have strong architectural mental models, and they can rapidly assess output quality without reading every line. In my talk, I called this building taste—developing intuition for when you need to look closely and when you don’t. Same skill, different metaphor.

The paper introduces a term I find genuinely useful: cognitive debt. Not technical debt—the gap between system complexity and human understanding. In my framing, this is what happens when loops don’t close. Drive-by prompting, never-reviewed papercut PRs, forgotten ambient agent outputs. Different word for the same accumulating problem.

Different lenses on the same problem

What I find most interesting is how the two framings complement each other—not where they compete, but where each one sharpens something the other leaves blurry.

The retreat paper goes deep on the technical infrastructure of this new loop. Their TDD section is sharp: test-driven development prevents a specific failure mode where agents write tests that verify their own broken behavior. When tests exist before the code, agents can’t cheat. I concur! TDD becomes deterministic validation for non-deterministic generation. Going to be shamelessly stealing this framing.

The “agent subconscious” is a concept I hadn’t thought of before—a knowledge graph built from years of post-mortems that gives agents historical context for interpreting signals.

“We optimized the software delivery process for humans. Now that it’s not just humans, we have to ask what organizing actually means.”

Senior engineers carry decades of pattern-matching for incident response that lives nowhere but their heads. Making that explicit and machine-readable is a hard problem and a good one. Their security section is sobering too. Granting an agent email access enables password resets and account takeovers. The security session at the retreat had low attendance. Of course it did.

The elastic loop, meanwhile, focuses more on the human operating model. How do you decide when to tighten and when to loosen? What does a daily rhythm look like—loose loops for papercuts in the morning, tight loops for deep work, review in the evening? And the cultural dimension: the distinction between autonomy and agency, where you can bury people in autonomy and they still won’t use it if they lack the agency to act on it. The trust question that makes rooms go genuinely quiet: is it okay to ship agent-written code that replaces an Excel table nobody ever reviewed?

What I take away

I’m so glad ThoughtWorks organized this. The Chatham House Rule was the right call—it lets senior practitioners speak honestly about what’s breaking without the corporate filter. The result is one of the most useful documents on agentic engineering I’ve read this year.

When people working independently arrive at the same structural insight from different directions, it’s probably real. Whether you call it the middle loop or the elastic loop, the work is the same: decompose, delegate, calibrate trust, close the loop. Curious what happens when we put these framings next to each other more deliberately.