What is a loop?
A prompt is one instruction. You ask, AI answers, and it stops. It does not know if the answer was right. It just waits for your next message.
A loop works differently. You set a goal once. After that, the system checks its own work against clear rules, finds what is wrong, fixes it, and checks again. This repeats on its own until the goal is met, with no one watching each step.
The real difference is what happens after a mistake. A prompt hands the mistake back to you. A loop is built to catch its own mistake and try again, on its own, before it ever reaches you.
At Synodus, this distinction shapes how we scope a project from day one: which parts can run safely as a loop, and which parts still need a person watching each step.
From prompt to loop: how we got here
This shift did not happen overnight. It moved through a few stages, and each one removed a little more manual work from the developer’s day.
- Prompt engineering (2023) was about writing a good instruction. Word choice mattered. A slightly different phrase could get a much better answer.
- Context management came next. Developers learned that the instruction alone was not enough. AI also needed the right background: the right files, the right examples, the right details about the project.
- Harness engineering (late 2025) built the structure around the work: the tools AI could use, the rules it had to follow, the checks it had to pass. But a person still sat there, approving each step before the next one started.
- Loop engineering (2026) is the first stage where a person can step away completely. The goal is set once, and the system runs the full plan-build-check-fix cycle on its own.
Each stage solved a real problem, but each one still needed a person in the room. Loop engineering is the point where that stopped being true. Our own delivery teams moved through these same stages over the past two years, and loop engineering is where most of our AI-assisted builds sit today.
Part of why this became possible is a practical trick, not a mystery. Developer Geoffrey Huntley described something he calls the “Ralph loop” earlier this year: give an AI agent the same goal again and again, and let it run for hours. AI cannot hold everything in its head at once because its short-term memory fills up. So instead of trying to remember, it writes its progress to files and to version history. When its memory runs out, a new agent picks up the file, reads what happened, and keeps going exactly where the last one stopped.
Anthropic’s own research described something similar: agents working in shifts, each one starting with no memory of the last shift, relying only on notes saved to disk. The lesson is simple, and it is one we apply in our own pipelines: loop engineering is not really about making AI smarter. It is about teaching the system to write things down, so nothing gets lost between runs.
Four steps of a loop
Most AI coding loops follow four steps, repeated over and over:
- Plan: AI looks at the goal and writes out a plan first. This stops guesswork and forces a clear target before any code gets written, the same way a person would sketch an approach before building anything.
- Execute: AI writes the code. This step moves fast, often just minutes, because it is not weighing business decisions here. It is only building what the plan says.
- Verify: The code is tested against clear, strict rules. This step decides whether the work is actually done or only looks done. The rules do the judging, not AI’s own opinion of its work. At Synodus, this is the step where a client’s actual industry rules get built in, so a banking client’s tests check for things a generic project never would.
- Iterate: If a test fails, the agent reads exactly what went wrong, fixes that part, and runs the check again. It does not start over. It only redoes what failed.
This cycle can run for a few minutes or a few hours, depending on the size of the task, until every test passes.
Loops inside loops: why speed matters
The four-step loop above is fast. But it is not the only loop running. AI researcher Andrew Ng points out that real software work actually runs on three loops, each moving at a different speed.
- The coding loop runs every few minutes. This is the Plan → Execute → Verify → Iterate cycle above. AI writes, tests, and fixes its own code.
- The feedback loop runs every few hours. A person looks at what has been built and decides what the agent should work on next. This is where product judgment lives.
- The outside loop runs over days or weeks. Real users try the product. Their reactions, complaints, and requests shape what gets worked on next.
Each loop feeds the one above it. The fast loop handles the doing. The medium loop handles the deciding. The slow loop handles the learning. If the medium loop is missing, the work keeps moving quickly, but it drifts away from what people actually need, because no one is steering it. If the slow loop is missing, a team ships fast but never finds out if the product actually works for real users until it is too late.
This is the structure we build into every Synodus engagement: a fast loop for the agent, a medium loop for our engineers, and a slow loop for the client’s own users.
What a loop actually needs to run
Setting up a working loop takes more than telling AI to “keep going.” A few pieces need to be in place first, and none of them are complicated on their own.
- Something to catch new work: A simple check that runs on a schedule, finds new requests, and sorts them, so nothing sits unnoticed.
- Separate workspaces: If more than one agent is working at the same time, each one needs its own copy of the project, so they do not overwrite each other’s changes.
- Written-down project knowledge: The rules of the project, and the mistakes to avoid, written once and saved in a file, so the agent does not re-learn the same lesson every single run.
- Connections to real tools: The loop needs to reach further than just the code. It needs access to the issue tracker, the database, the messaging tool, wherever the real work actually happens.
- A separate checker: The model that writes the code should not be the only one grading it. A second, independent check catches things the first pass missed.
- A memory file: A plain, simple file that tracks what is done, what failed, and what is next, so a new run can pick up exactly where the last one stopped.
None of these are new AI tricks. They are basic project habits: write things down, keep work separated, get a second opinion. Good teams did all of this before AI existed. These are the same habits we build into every Synodus loop before a single line of client code gets touched.
Why people still matter
If AI can plan, build, test, and fix its own code, what is left for a human developer to do?
A lot. AI works fast, but it only sees one file, one function, one task at a time. It does not know your business. It does not know what your users actually want. It does not know why an old system was built a certain way, or what will quietly break if that reason is ignored.
Andrew Ng calls this the human context advantage. It shows up differently depending on the industry, which is exactly where our work at Synodus comes in:
- In banking and fintech, legacy systems carry rules that were added years ago for reasons the code itself does not explain. Regulations dictate exactly what must be logged, reported, and kept unchanged. AI can write correct code, but it cannot know which shortcuts are actually forbidden by law.
- In healthcare, patient data comes with strict privacy rules, and a small error in a form field is not just a bug, it can affect real care decisions. Knowing which mistakes matter most takes someone who understands the stakes, not just the syntax.
- In retail, catalogs, prices, and promotions change constantly. The goal can shift before a single loop even finishes its cycle. What counts as “done” this week may not count next week.
- In public sector, procurement rules and approval steps outlast any one project team, and systems often need to run for a decade or longer. A shortcut that saves time today can become an expensive problem years from now.
None of this can be picked up by AI on its own. It has to be told, by someone who was there. This is the exact gap our engineers are trained to fill on every Synodus project.
Loop engineering at Synodus
Across our client work, this all comes together as two loops running side by side.
The micro-loop is where AI works: It handles repeated setup work, standard security checks, and first-pass testing, with the industry-specific rules from the section above built directly into the verify step.
The macro-loop is where our engineers work: Instead of manually checking code line by line, our senior developers focus on system integration with older software, alignment with the client’s actual business goals, and the judgment calls that come from having worked inside a specific industry before.
This split is what we call performance-led engineering: let AI carry the repeatable work, and keep people in charge of the decisions that need real judgment. It also cuts down what our CEO, Cong Nguyen, calls uncertainty cost – the price a business pays for not knowing whether something works until it is too late. A strict verify step, run over and over inside the loop, catches problems early, while they are still cheap to fix, instead of after launch, when they are not.
The bottom line
Loop engineering will not replace developers. But it does change what a developer’s day looks like. Less time spent manually testing code line by line. More time spent deciding what should be built, and why it matters, and whether it is even ready for the loop in the first place.
At Synodus, we believe the strongest software comes from AI handling the repeatable work, and people making the calls that need real judgment and real industry knowledge. That is performance-led engineering in practice, and it is why we keep this loop running for every product we build.
