The Middle Loop Is Where Engineering Actually Lives Now

Someone finally named the thing.

There’s a word now for the work I’ve been doing for the last two years without a vocabulary for it. The middle loop. Supervisory engineering. The thing that sits between writing code and shipping it. The thing that didn’t exist before agents started producing code faster than any human could read it.

I’ve been in this business for over two decades. Twenty years of Rails alone. Built payment systems. Scaled fintech platforms. Watched three hype cycles promise to end programming and then create more programmers. So when I say this particular shift feels different, I’m not talking from a place of panic. I’m talking from a place of “yeah, this one is real, and most orgs are not ready.”

Let me walk you through what’s actually happening, what it means if you’re a CTO or an engineer or a founder, and where the industry is quietly breaking.

The loops, briefly

We’ve always talked about two loops in software engineering.

The inner loop is you and your editor. Write, run, fix, run again. The outer loop is everything that happens once you push: CI, review, staging, deploy, monitor, on-call. Every engineering culture I’ve ever worked in had these two loops, named or not.

There’s a third one now. Sitting between them. Directing agents, evaluating their output, catching the plausible-looking-but-wrong results, keeping the pieces architecturally coherent across parallel streams of agent work.

Nobody named it for a while. Everyone was doing it. That’s usually how these things go.

Why this matters more than the usual “AI will change everything” take

I’ve written before about vibing fatigue. The mental tax of operating in an environment where companies measure AI output as if coding was ever the bottleneck. It wasn’t. Meetings were. Coordination was. Unclear specs were.

The middle loop is the other side of that coin.

Agents took over one part of the job. The part that felt like engineering to a lot of developers. Now those developers either move up into supervision or get squeezed out. The constraint shifts from production capacity to decision-making capacity.

Read that twice. It’s the whole story.

If an agent can write a hundred lines of code while you’re reading twenty, the bottleneck is you. Not the AI. You. Your capacity to decide what’s right. What’s shippable. What’s quietly broken. What’s architecturally coherent with the other four streams of agent work happening in parallel.

Most engineers were never trained for this. Most career ladders don’t recognize it. Most management structures pretend it doesn’t exist.

What the middle loop actually demands

The people who do this well share three traits.

They think in terms of delegation and orchestration, not implementation. They carry strong mental models of system architecture. They can assess output quality without reading every line.

That last one breaks most engineering review cultures. “Looks good to me” PRs were already a problem. Now the PRs come in at three times the rate, written by an agent that has no shame about shipping something that almost works. You can’t LGTM your way through that. You also can’t read every line. Something has to change, and the thing that changes is how you read code at all.

You start looking at shape. At boundaries. At what the code is doing to the rest of the system. Not at syntax. Not at style. Structural comprehension at speed.

It’s a skill. It’s teachable. It’s also not what most of us spent our first decade learning.

Twenty years of Rails helps here in a specific way. When you’ve seen the same conventions applied across thousands of apps, you stop reading line by line. You read the deviation. The place where the code stops looking like Rails and starts looking like someone’s cleverness. That’s where agents tend to go wrong. That’s where you learn to look first.

Where the rigor goes

If agents write the code, where does the engineering discipline migrate to? There are five destinations, and I’ve seen all of them play out on real client engagements.

Upstream to the spec. The highest-leverage place to catch errors is before a single line gets generated. User stories are too vague. Teams are rediscovering old techniques like state machines, decision tables, and structured requirement formats. Not because they’re fashionable. Because an agent will produce exactly what you specify, at scale, including the parts you got wrong.

Into the test suite. TDD turns out to be the strongest form of prompt engineering anyone has found. The mechanism is specific. Without tests first, an agent will happily write a test that confirms whatever broken thing it just generated. With tests first, the agent can’t cheat. The test becomes a contract between what you said you wanted and what got built. Rails people already have the tooling for this. Minitest, RSpec, system tests that read like prose a non-technical founder can approve. If you’re building with agents and you’re not running tests first, you’re leaving the biggest lever on the floor.

Into type systems and constraints. Make incorrect code unrepresentable. Pick languages and frameworks that carry the guardrails so the agent has fewer ways to be wrong. Rails does this with convention over configuration. Every convention is a decision the agent doesn’t have to make, a misunderstanding eliminated before it starts. Sorbet or RBS on top of that, and you’ve cut the agent’s surface area for creative error to a fraction of what it’d be in a more expressive environment.

Into risk mapping. This is the reframe I keep coming back to. The old question was “did someone review this code?” The new question is “what’s the blast radius if this code is wrong, and is our verification proportional to that risk?” Not every line deserves the same attention. A settings page and a payments settlement service are not the same animal. Review them like they are and you’ll burn the team out and still miss the thing that matters.

Into continuous comprehension. If code changes faster than humans can read it, the old model of building understanding through code review breaks. You need architecture retrospectives. Ensemble programming. AI-assisted comprehension tools that generate system overviews on demand. Or, bluntly, you pair program all the time. Not just for the tricky bits.

The parts that matter most if you’re running the org

There’s a lot of ground here that doesn’t get airtime in the usual commentary. A few of the pieces that should.

Cognitive debt. Technical debt has a new cousin. The gap between how complex your system is and how well humans actually understand it. Agents widen this gap every day. Your codebase gets bigger. Your collective understanding doesn’t keep pace. Eventually you hit a wall where nobody can explain why the monolith works, and nobody can safely change it. I’ve seen this already in client orgs. It compounds silently.

Agent drift. Put the same database agent on two different teams. Give it six months. The one working on the e-commerce backend and the one working on the ERP system will develop different habits and preferences. They started identical. They’re not identical anymore. Conway’s Law, but accelerated, because agents pick up local norms without any of the human friction that used to slow that divergence. Do you standardize it out or let teams optimize locally? Most orgs won’t settle that question for a while.

Security is dangerously behind. This one needs to be said loudly. The industry pattern is to fix security later. With agents, later is too late. Give an agent email access and you’ve just handed it password resets and account takeovers. Full machine access for dev tools means full machine access for whatever the agent decides to do. Platform engineering needs to drive secure defaults. Individual developers making security-conscious config choices is not a strategy.

The productivity/experience decoupling. This one is ugly. For decades, developer experience and developer productivity moved together. Happy teams shipped more. With agents, the two are coming apart. Orgs can squeeze more output from environments where developers report higher cognitive load and lower satisfaction. Which means the business case for investing in developer experience gets weaker, unless the definition changes. Reframing it as “agent experience” gets the wallets open faster. Weirdly, the conditions that help agents perform well overlap almost completely with the conditions that help humans perform well. Same investments, better framing for the CFO.

Stability is regressing. A decade of DORA research showed that smaller batch sizes correlate with higher stability. Agents make it trivially easy to produce enormous changesets. Teams are drifting back toward waterfall-shaped releases because the agent can keep up and the human review cadence can’t. This is an active regression that very few people are talking about.

Staff engineers under pressure. Staff engineers use AI less often than juniors. When they do use it, they save more time per use. Their context makes them better supervisors. They’re also the ones most likely to be drowning in coordination work that doesn’t need them. They should become “friction killers.” Fix the things that slow both humans and agents. Most staff engineers I know have been told for years that there’s no budget for the improvements they keep suggesting. Now those improvements are existential.

The mid-level squeeze. The one I keep warning people about. Juniors are more valuable than ever because AI got them past the net-negative phase faster and they haven’t built up habits that resist new tools. Seniors are more valuable because their judgment is the moat. Mid-levels who came up during the hiring boom and never built the fundamentals are in the worst position in the industry. Retraining them is hard. No org has solved it. If you’re mid-level, don’t wait for your company to figure it out.

The decision-fatigue problem, up close

I want to come back to this one because it’s where the middle loop bites hardest.

You can feel it if you’re supervising agents for real. PRs stack up. Each one looks plausible. Each one needs a call. Ship. Don’t ship. Fix. Revert. Flag. Approve. Approve. Approve. By mid-afternoon your judgment starts to go. By Thursday you’re rubber-stamping things you’d have caught on Monday.

This is the new organizational bottleneck. Middle managers who used to be coordination points become approval bottlenecks. Agents generate job specs, code fixes, feature implementations faster than any human can say yes.

The honest answer nobody wants to give: you need fewer decisions per human, not more humans.

That means clearer risk tiers so low-risk things don’t hit your desk at all. It means better tests so the test suite says yes or no for you. It means agent permissions tight enough that some categories of decision never reach you. It means cultural permission to say “good enough to ship” instead of chasing a moving target of cleanliness.

That last one is the hardest. When one review tool flags an issue, the fix triggers another tool, which triggers another. Clean code is a moving target. Somebody has to be the grown-up and call it. “This ships. We’re done.” If nobody plays that role, you burn weeks and tokens on cosmetic perfection while the business waits.

The role mutation that’s actually happening

PM and developer roles are converging. Developers are now thinking more about what to build and why. That’s PM work. Meanwhile, some PMs are being trained to work in Markdown inside developer tools.

Large tech companies are researching whether the PM role needs a new name. They should. What used to be “I write specs and you implement them” is now “we co-own the spec, and the agent implements it.” Completely different shape. Needs a new word.

The old line between product and engineering was never that clean anyway. AI didn’t create this dysfunction. It exposed it. Knowledge fragmentation between disciplines, unclear role boundaries, cultural gaps. All of it was there. All of it got more expensive to ignore.

If you’re a PM in 2026 and you can’t write a precise spec that an agent can execute, you’re in trouble. If you’re an engineer who refuses to own the “what” and wants to stick to the “how,” you’re in trouble. The roles are merging whether anyone wants them to or not.

What I tell the founders on my calls

Most of the founders I advise don’t have a team yet. They have an idea, a budget, and a pile of agent output they can’t fully evaluate. They are the inner loop and the outer loop at the same time. The middle loop is the gap nobody fills.

My job when I take on these clients is not to write better code than Claude or GPT. That’s not the value. The value is knowing which code matters. Where the blast radius is. Which corner of the system is quietly rotting and which looks scary but is fine. When to stop fixing and start shipping.

This is also why I’m careful with founders who come to me saying they want me to replace their engineering team with agents. That’s not a strategy. That’s a wish. The middle loop still needs a human. Maybe one day it won’t. That day is not this year.

What to do on Monday

If you’re a CTO, start risk-tiering your code. Not perfectly. Just enough that you stop treating all changes as equally important.

If you’re a senior engineer, learn to read code without reading every line. Get comfortable with structural comprehension at speed. The skill is teachable. It just isn’t taught.

If you’re a mid-level engineer, your survival strategy is either going deeper into systems and architecture or going broader into spec writing and review. Staying a ticket-translator is not a strategy anymore.

If you’re a junior, you are in a better position than the discourse suggests. Pair with seniors. Use the agents fearlessly. Ask why at every turn. You are the most productive configuration in the org right now and nobody talks about it.

If you’re a founder building solo with agents, get someone who knows code to look at what got built. Before you raise. Before you launch. Before you scale. The audit is cheaper than the rewrite.

The map is being redrawn. The people best positioned to draw it are the ones willing to admit how little they know.

Engineering didn’t get easier. It got more honest about what engineering always was.

A lot of the framing in this piece was sharpened by reading ThoughtWorks’ “The Future of Software Engineering: Retreat Findings” (February 2026). Worth a read if you want the full industry-level view.

Final Words

I’m curious whether this matches what you’re seeing. If you agree, push back on something anyway. If you disagree, push back harder. The middle loop is forming right now and the vocabulary is still being built.

You can find me on LinkedIn (linkedin.com/in/ivanturkovic), X (x.com/ithora), and Threads (threads.com/@ithora). I read everything, even when I don’t reply right away.

If you’re working through this in your own org and want a second set of eyes, reach out at ivanturkovic.com/contact. I work with founders and CTOs on exactly this kind of transition.

If you’d rather just grab 30 minutes and talk it through, book directly at cal.eu/ivan-turkovic/30min.

Question for you: who owns the middle loop in your org today, and do they know they own it?