Everyone discovered the loop this year. NASA has been running it since the nineties.

Every second conversation I've had this year has ended up in the same place. Goals. Test-driven development. Loop programming. Somebody explains, with real enthusiasm, that the trick with AI is to define what "done" looks like up front, let the thing iterate, check the result against your definition, and go around again.

And they're right. It does work. I told a room of engineers earlier this year that their job wasn't to write code anymore, it was to create loops, and I still think that's the most useful thing I said to them all summer.

But I keep having this itch during those conversations, and it took me a while to work out what it was.

We've done this before. We just did it with people.

For anyone who hasn't run into it: concurrent engineering is what you get when you stop having specialists sit in separate rooms optimising their own piece and sending documents to each other. In that arrangement every question costs a round trip — you ask on Monday, you get an answer Thursday, and by Thursday the question has changed. Concurrent engineering puts all of them in one room, at the same time, with the thing they're arguing about in the middle where everybody can see it. Every question now costs about nine seconds.

NASA's Jet Propulsion Laboratory has been running this since the early nineties. Team X. A mission concept study that used to take months and a small fortune gets done in a few sessions, because the propulsion person and the thermal person and the cost person are watching the same model change in front of them, live, and the second one of them breaks something the others see it break.

That is loop programming. Same shape exactly. Short cycle, shared definition of done, check, adjust, go again. The only difference is that the participants were humans and the "compiler" was a room.

So when I hear that we've discovered iterative development with AI in 2026, my honest reaction is that we rediscovered something aerospace has been doing since before I could drive.

Which is fine. But it means the interesting question isn't the loop.

Here's what I think everyone is skipping.

A loop closes against something. That's the whole mechanism — you compare what you got against a reference, and the gap tells you what to change next. In test-driven development the reference is a test. At JPL the reference was a shared model of the spacecraft that every discipline could see.

The reference is doing all the work. Not the iteration speed.

And this is where it gets uncomfortable, because a fast loop closing against a bad reference isn't neutral. It's actively worse than a slow one. You converge — quickly, cleanly, with everything appearing to function — on a confidently wrong answer. I've watched two extremely capable AI systems, pointed at the same out-of-date planning spreadsheet, produce two beautifully argued plans that were both nonsense, and neither of them had any way of knowing.

(This, incidentally, is why I get twitchy when someone tells me their agent workflow is "running beautifully." Running beautifully against what?)

At JPL the reference was a model of a spacecraft that didn't exist yet, built carefully, by people whose job it was to make sure it behaved like the real thing would. Nobody in that room was iterating against a document somebody exported in March.

So what do you point an AI loop at?

If your loop involves anything physical — a plant, a network, a building, a grid, a supply chain, an organisation with actual people in it — then the reference has to be a live model of that thing, kept current from its own data, honest about what it doesn't know.

That's a digital twin. Not a 3D picture of your factory for the reception area. A place where a change can be rehearsed and where the loop has something true to close against.

And that's the combination I've started calling Loop Twinning: humans and AI iterating together, against a shared model of reality, toward value for whoever actually owns the need.

Four parts, and I'd argue all four have to be there or you've got something else:

Humans and AI together. Not a person babysitting a tool, not agents running loose overnight. Both in the loop with different jobs — the machine is faster and never gets tired, the person is the one who knows when the output is rubbish. You need domain knowledge in the loop or you can't tell.

Iterating. Short cycles, real deliveries, feedback arriving while you can still do something about it. Feedback that shows up after you've stopped being able to act isn't feedback, it's a post-mortem.

Against a shared model of reality. The room, and the thing in the middle of it. This is the part being skipped and it's the part that decides everything.

Toward value for whoever owns the need. Not the sponsor, not the steering group, not whoever signed the purchase order. The person who has to live with the result on a Tuesday six months from now. Loops optimise toward whatever you point them at, which means that person has to be inside the loop rather than receiving a summary of it afterwards — and in my experience they are almost never in the room.

One test, if you want a quick one

Swap an input. Change the source file, the sensor, the vendor, the data feed.

Does the whole thing still work?

If yes, you built a method. If no, you built a demo with good lighting — and I've built plenty of those, so this isn't me being clever at anyone's expense.

Everybody has the loop now. It's essentially free. The scarce thing, and the thing worth actually building this year, is what goes in the middle of the room.