Loop engineering how AI work gets better every time round

AI can now do in minutes what used to take days: research, writing, design, code. But most people using it are still hoping it got things right. Loop engineering is a way of working that replaces the hope with a process. The AI checks and improves its own work in loops, people keep the decisions, and a harness of rules, checks and workflows holds it all to a standard. Here is how it works, with a real example: a mobile app I led, now live in the app stores.

Field report · October 2026 · Steven Smith

A climber in an orange helmet abseils down a wall of phone-screen blocks on an orange rope and a navy rope, while small yellow helpers fit the blocks in place.
The problem

Most AI work runs on hope. You prompt, it produces something, and you hope it got it right.

On its own, AI is only as good as the person checking its work. If you can’t read code, you can’t tell whether it’s secure. If you’re not a designer, you can’t tell whether a screen will hold up. If you don’t know the subject, you can’t tell whether the research is sound. So you ship and hope, or you don’t ship at all.

What loop engineering changes

Work that checks itself. The AI does the work, checks it, fixes it, and learns from what went wrong.

Loop engineering is the process. You hand the AI a whole task instead of step-by-step instructions. It works out what the task needs, gathers what’s missing, does the work, checks it and fixes what it finds, and stops to ask a person only when it can’t decide. People make the decisions, and every repeated mistake becomes an improvement to the harness. A harness is what makes it possible: the rules, guardrails, guides, skills, checks and memory the AI works with, drawn from people who know what good looks like. With both in place, you can take on work beyond your own skills and spend your time on the decisions.

The idea

Work in loops, not lines

Loop engineering works for anything AI can help with: research, writing, design, analysis, operations, software. The shape stays the same. In the middle are the goal and the direction, owned by a person. Loops come off it, each at its own speed, and each one feeds back into the middle. Around all of it is the harness. To try it outside software, Harness Kit sets up a harness around the folder, repo or workspace where your work already lives.

For example · building a product

A centre with three loops next to it, inside the harness. In the middle: requirements and direction, owned by a person. Define and refine with stakeholders takes days: people evaluate the directions and decide. The AI builds and checks in minutes. Review and approve takes hours: the AI reviews each change and a person approves it. Every loop starts and ends in the middle. The harness is the rules and design guide every loop follows, and anything learned can become a new rule. The harness · rules and design guide every loop follows Anything learned can become a new rule Define and refine ~ days Stakeholders evaluate and decide AI builds and checks ~ minutes The AI builds and fixes Review and approve ~ hours A person approves after the AI’s review Requirements + direction a person: needs, design, next A centre with three loops next to it, inside the harness. In the middle: requirements and direction, owned by a person. Define and refine with stakeholders takes days: people evaluate the directions and decide. The AI builds and checks in minutes. Review and approve takes hours: the AI reviews each change and a person approves it. Every loop starts and ends in the middle. The harness is the rules and design guide every loop follows, and anything learned can become a new rule. The harness · every loop follows it Anything learned can become a new rule Requirements + direction a person: needs, design, next Define and refine ~ days Stakeholders evaluate and decide AI builds and checks ~ minutes The AI builds and fixes Review and approve ~ hours A person approves after the AI’s review
  1. Define and refine ~ days

    The AI gets the requirements, specs, design and any other context it needs, and builds a clickable prototype. People evaluate the directions it shows, sometimes one design, sometimes several, and decide which way to go. That can change a design, change a whole requirement, or add a new feature. The requirements are updated, and round again until they’re settled.

    Your part: be the bridge between the people the product is for and the AI. Expect this loop to take most of your time.

  2. AI builds and checks ~ minutes

    The AI builds from the requirements. It checks its work against the requirements and the harness, fixes what’s wrong, and repeats. No one needs to watch.

    Your part: set it up well, with clear requirements and a good harness, and decide what it builds next.

    The smaller loop: self-improve. Beside the build loop, the harness gets better from experience. The AI can find a problem itself, or a person can flag one and give it feedback. Either way, the harness can improve: a rule, a skill, a check or a workflow, so the next build starts from a better place.

  3. Review and approve ~ hours

    This is AI-assisted QA: quality checks. The AI sends each change for approval. A reviewing AI tests it and sends it back for fixes or improvements. A person looks over that review before approving. Once approved, the change goes in.

    Your part: look over the AI’s review, approve, and turn problems that keep coming up into harness improvements.

The harness surrounds all three loops, and anything learned in one loop can become a rule for all of them. On my project, building and reviewing were quick. Defining and refining with stakeholders was the slow part, and it was where the important decisions got made.

Adapted from Andrew Ng, “Three Key Loops for Building Great Software”. The timings are from my project.

The proof

How it ran on a real app

The example is a mobile app I led for a large organisation. I worked out what to build and why, directed the AI’s work, and gave it feedback so it did better next time. I made most of the changes, roughly two and a half for every one of the engineer’s. An AI review checked each of mine before the engineer approved it, and I reviewed the engineer’s changes the same way. The back end belonged to a separate team, and the app connected to it. The harness, everything the AI works with, kept all of it on track. The four steps below walk through the loops above: step 2 is Define and refine, step 3 is the build, and step 4 is Review and approve.

  • Me, directing and reviewing
  • Stakeholders and users, trying each version
  • An engineer, reviewing changes and looking after the technical rules
  • AI, doing the building
Choose a step in the picture, or below, to see what happened.
How the project ran: who does the work Four steps across three levels of control: people decide and do, people working with AI, and AI working on its own. Step 1, I organise the requirements with AI, then stakeholders and I prioritise them. Step 2, define and refine: I direct the AI, the AI builds a clickable prototype on its own, design and development together, checking its own work, and stakeholders and I evaluate it and decide. We change and improve it, round again, until it is done. Step 3, I direct the AI, and it migrates the finished prototype to the real phone app, checking its own work as it builds. Step 4, review and approve: the AI sends each change for approval. A separate AI and the reviewer do the quality checks together. The reviewer approves or asks for changes; changes go back to the AI to fix and send again. Once approved, the AI or I merge it into the main version. PEOPLE decide and do PEOPLE + AI with AI AI on its own 1 · Sort out needs 2 · Define and refine 3 · Build the real app 4 · Review and approve every change, of every kind Organiserequirementsme, with AIPrioritiseme + stakeholders Direct the AIme, with AIBuild prototypedesign + developmentEvaluateand decideme + stakeholders Direct the AIme, with AIMigrate to thephone app Send forapprovalfixes if askedAI-assisted QAAI + reviewerApproveor ask for changesMerge tomainAI or me prototype change, improve checks its own work, fixes done checks its own work, fixes asks for changes approved How the project ran: who does the work, step by step 1 · Sort out needs Organise requirementsme, with AIPrioritiseme + stakeholders 2 · Define and refine Direct the AIme, with AIBuild prototypedesign + developmentEvaluate and decideme + stakeholders checks its own work prototype change, improve done 3 · Build the real app Direct the AIme, with AIMigrate to the phone app checks its own work 4 · Review and approveevery change, of every kind Send for approvalfixes if askedAI-assisted QAAI + reviewerApproveor ask for changes asks for changes approved Merge to mainAI or me

Swipe sideways to see all four steps →

The harness

How I worked with the harness

My job was to make sure the AI had the context it needed, and then to direct its work. I couldn’t check every detail myself, so I wrote down what good looks like and let the AI check itself against it. When something went wrong, I fixed the harness as well as the screen.

Give the AI the context it needs

The AI can only do good work with the right context. My job was to make sure it had that context, and that it understood the task before it started.

  • What’s already in the harness: rules, guardrails, guides, skills, workflows, checks, the design system and its memory, plus the other things the harness needs to run well. This list keeps evolving.
  • The bigger picture: the goal, the requirements and the product.
  • The task itself: what to do, and what “done” looks like.

The harness isn’t one thing. It’s a growing collection of rules, guardrails, guides, skills, workflows, checks and more. The engineer and I both looked after it, and I often noticed things to improve outside design too.

Then the AI works until it’s done

With the context, the task and a clear idea of done, the AI does the work, checks it, fixes what’s wrong and keeps going until it’s done. I still checked the details myself, especially the final screens.

The AI gets context from two places: the harness (rules, guardrails, guides, skills, checks, the design system and memory) and from me (the goal, requirements, product, the task and what done looks like). With that, the AI works in a loop: does the work, checks it, fixes it, and repeats until done. The harness rules · guardrails · guides skills · checks · memorydesign system From me goal · requirements · product the task · what done looks like The AI does the work, checks, fixes, repeats until done Done as agreed The AI gets context from two places: the harness (rules, guardrails, guides, skills, checks, the design system and memory) and from me (the goal, requirements, product, the task and what done looks like). With that, the AI works in a loop: does the work, checks it, fixes it, and repeats until done. The harness rules · guardrails guides · skillschecks · memory design system From me goal · requirements product · the task what done looks like The AI does the work, checks, fixes, repeats until done Done as agreed

How the harness improved over time

This is the self-improving loop. Problems were spotted in two ways.

  • The AI remembersIt had a memory that carried over from one task to the next. So it noticed problems linked to the harness, or things that had happened more than once, and suggested how to improve the harness.
  • I noticeEspecially when the AI made the same mistake again. I gave it feedback, we worked out the cause together, and then improved the harness.

Either way, the harness improves: a new or better rule, skill, check or workflow. It goes through approval like any other change, so the next task starts from a better place.

Two ways the harness improves: the AI remembers past work and suggests an improvement, or I spot a repeated mistake and give feedback. Either way, together we improve the harness, whether a rule, skill, check or workflow, so the next task starts better. The AI remembers and suggests a fix I spot a repeat and give feedback Improve the harness rule, skill, check, workflow approved like any change, so the next task starts better Two ways the harness improves: the AI remembers past work and suggests an improvement, or I spot a repeated mistake and give feedback. Either way, together we improve the harness, whether a rule, skill, check or workflow, so the next task starts better. The AI remembers and suggests a fix I spot a repeat and give feedback Improve the harness rule, skill, check, workflow approved like any change, so the next task starts better

  1. Write it down

    What good design looks like, in plain words the AI can follow. If it’s only in my head, the AI can’t use it.

  2. Look at the real screens

    Automatic checks can’t tell if a screen feels right. That part stayed with me.

  3. Turn repeated problems into rules

    If I correct the same thing twice, it becomes a rule. I also keep the harness short, so the AI can follow it.

Every check passed, and two of them were testing nothing

This one comes from Harness Kit, one of my open-source harnesses. A green test suite felt like proof, so I tried something blunter: delete each check, one at a time, and run the suite again. Two checks could be removed with every test still passing. One of them was the only thing stopping a file name from forging a record the harness trusts.

Two rounds of careful review had missed both. One deletion run found them in minutes. Now it’s a rule: for every check, delete it and confirm a test goes red. It’s the same lesson as looking at the real screen: a pass only means something if a failure would have been caught.

Two test runs compared. With the check in place, every test passes. With the check deleted, every test still passes, which shows that nothing was testing it. check in place check deleted check A check B check C check D check A check B · gone check C check D tests: all passed tests: still all passed
Same green result. Only deleting the check showed that nothing was testing it.
What it enables

Skills you don’t have, built in

A harness also gives you the judgement of specialists you may not have. For writing, that might be a style guide and fact checks. For research, rules about sources. For a product, you don’t need to know how to change a database safely, or what makes a log-in secure. The harness knows, and the AI is held to it. Across the layers of a product, it looks like this.

  • UX…that it built what people actually need.Requirements and decisions live in one place, “done” is written so it can be checked, and prototypes are tried with real people.
  • UI…that the screens look consistent and on-brand.A design guide and design tokens set colour, type and spacing. Checks catch anything off-system, and a person still looks at the real screen.
  • Front end…that the code is sound and the next change won’t break it.Coding rules, lint and tests run on every change, so you don’t have to read the code to know it meets the bar.
  • Back end…that a data change won’t lose anything.Rules for data and the contracts the app relies on are written before they’re needed. Some databases can’t undo a change, so recovery is planned in advance.
  • Security…that nothing private has leaked.Protected files, no secrets in code, and log-in and personal-data checks before anything ships, with a named person approving.
  • Workflow…that someone actually reviewed it.Every change follows one path: built, checked, reviewed, approved. Mistakes become new rules, so the process improves itself.

That’s how I worked on the app above. I’m not a front-end developer by trade, but I took UX, UI and front end to production quality because the harness held the AI to standards I could direct and judge without writing every line myself. The back end was another team’s. My open-source Universal Harness is built to cover every layer in this list, across web, mobile and back-end stacks, and each of its gates ships with a self-test that sets up the violation on purpose and confirms it gets caught.

My part

What I did, and what the AI did

I don’t see my role as a fixed job title. It follows what the project needs. Here that was requirements, design and directing the AI: work that would usually be split across several specialists.

When you work with AI agents, the job title matters less. What matters is knowing where the lines are: which work people decide and do, which work people do with AI, and which work the AI does on its own. Then you decide when a person needs to step in, and why.

For example, say a screen design needs to be built. You don’t necessarily need a UI designer to direct the AI. Someone else can do that first step. But you might want a UI designer to check the finished screen. On another project, automatic checks might be enough. It depends on the project and what it needs.

What I did on this project

  • Worked out with stakeholders what to build and why
  • Organised the requirements with AI, and prioritised them with stakeholders
  • Created the design guidelines and design system, with AI
  • Directed the AI: what to build next, and how
  • Made most of the pull requests and fixed what reviewers asked for, with AI
  • Looked at the real screens, and reviewed the engineer’s changes with AI
  • Decided which problems became harness improvements

What I didn’t do: the AI did it

  • Build the prototype
  • Migrate it to the real phone app
  • Review its own work and correct it until done
  • Save what it learns to memory
  • Suggest harness improvements from its own mistakes and memory

What stayed with people

  • What to build, and whyMe, with stakeholders
  • Which requirements come firstMe, with stakeholders
  • What good design looks like, written down for the AIMe
  • Looking at the real screen always a named personMe, with stakeholders
  • Directing the AI to review changes and fix its workThe engineer and me, both with AI
  • Which problems become harness improvementsMe and the engineer

Some things must always have a name next to them, like looking at the real screen. If no one does, work that passes every check can still go out looking wrong, and nothing warns you.

See every responsibility, compared with a typical job-title split

“As long as a person knows something the AI does not, a person needs to stay involved.”Paraphrased from Andrew Ng, “Three Key Loops for Building Great Software”

My work

How my work transformed

I split my time into two kinds of work. Building, including making the screens. And strategy, exploration and improvement: working out the requirements, exploring designs, and testing ideas with stakeholders and users.

Two panels. Left: the climber struggles uphill under a huge pack of bricks. Right: yellow helpers carry the bricks while the climber walks upright reading a map toward the summit flag.

“AI frees up time for more valuable work” is easy to say. On this project it was concrete: the split flipped, and the work itself changed shape.

What the work turned into:

Requirements that only looked settled. Much of the brief turned out to be open, unprioritised or still changing, and I had time to find that out early.

Several designs for each problem, built as working prototypes, instead of one design argued over in a document.

Testing with stakeholders and users, often enough that it changed what we built.

A change of direction we could afford. Halfway through, the heart of the app changed. It cost about two weeks, because building was no longer where the time went.

On a typical project, getting the same result would mean spending as much time on building, or more. More often, teams cut back on this higher-value work instead.

It also showed the new slow point: the people steps. When the AI builds in minutes, waiting days for feedback or sign-off matters much more.

Speed was the smaller part of the change. I could cover more ground on my own, and more of my time went to the judgement calls that make a product worth using.

The evidence

What the numbers say

These figures are measured results from real production apps built with loop engineering: an earlier mobile app with more than 60 screens, and the app I led. Both are live. The products aren’t named.

Faster, without trading away quality

Earlier app · six months without AI vs six months with

0

pieces of made-up code from the AI, across the whole period. It’s one of the failures people worry about most with AI-written code.

93%

of the test improvements the AI wrote on its own were accepted. It wrote 82 of them in a single month.

80.4/100

overall code quality score, measured the same way for both periods.

→ 0

type errors, an early sign of bugs. Duplicated code also fell, from 9.4% to 8.1%.

Not everything kept pace. Clearing out unused code fell behind new work. The same scoring that shows the gains shows this too.

One person leading, with AI doing the building

The app I led · first three weeks

65%

of my changes (26 of 40) were sent back by the AI review at least once, so the review was doing real work.

1.7

review rounds per change on average: flag, fix, review again, until it passed.

25 → 2

A look back over the review comments on 25 changes found 2 recurring problems. Both became new rules.

+1

A second look back added a real-device check that code review can’t catch: how forms behave with the keyboard open.

Where the engineer’s time went. Their work moved somewhere less visible: maintaining the harness, writing down rules and building the automation that let me move fast safely. Whether the new rules reduce repeat problems is still being measured.

With and without a harness

from my experience

There’s no measured comparison here: no one built the same app without a harness. But the difference in how the work runs is clear. Without a harness, you have to direct the AI more, it’s easy to forget a step, and the build probably wouldn’t save as much time.

How the work runs without a harness compared with with one, from my experience
AspectWithout a harnessWith a harness
Steps like “review your own work”You remember to ask, every timeBuilt in, and happens automatically
Forgotten stepsEasy to miss oneWritten down once
QualityDepends on who’s directing the AISame rules and checks for everyone
Lessons learnedStay in one person’s headSaved in the harness for next time
My timeSpent directing each stepSpent deciding, reviewing and giving feedback

What other projects gain

A harness doesn’t have to be built from scratch each time. Start from a core harness, give each project its own copy (a fork), and shape it around that project’s work. Improvements found on one project can go back into the core, so they reach the other projects too.

  1. 1

    A new project doesn’t start from zero

    The rules, skills, checks and design guidance are there from day one. My open-source Universal Harness is built to be that starting point.

  2. 2

    A fix made once is fixed everywhere

    When a mistake is fixed in the core harness, every project built on it gets the fix.

  3. 3

    Quality depends less on one person’s AI skills

    Someone newer to AI works with the same rules and checks, so steps are harder to skip and the bar stays the same.

  4. 4

    Improvements add up across teams

    A fix or addition from any project can go back into the core, so even a project with nothing else in common with yours can end up improving the harness you work with.

What I’d strengthen next

For the most part, the harness fit what my project needed, and because it’s flexible, it can be added to, improved or scaled as a project needs. The base harness included some product and design context, but it focused mostly on development and the more technical areas. So as I went along, I added the project’s own product context and its design and brand context. These feel like core parts of a harness. One idea is for the initial harness setup to gather that information, or ask for it if it’s available.

On a larger or more varied project, one that also includes research or product planning, that could mean more skills and guides to cover the wider work. Not every harness needs to cover every kind of work, though. You add what the project needs.

These lessons come mainly from one project. The next projects to use the harness are the real test. Two things are worth measuring: how quickly they get started, and whether review rounds drop over time.

Tips

Things to be mindful of

Most of these apply to any work with AI. They matter more when you’re building a production app for a company.

A trail rest stop. The climber kneels and checks, with a magnifying glass, the knot where an orange and a navy rope are tied together. A yellow helper locks a wooden chest. Behind them, a tired helper puts down a heavy backpack, another hands a note to a fresh helper by a tent, and a signpost shows an eye and a padlock.
  1. 1

    Never just trust the output

    The AI can still get things wrong, however good the harness is. Many other things affect the result. Check what you can yourself, and where the work is outside your skills, make sure the right person or check looks at it.

  2. 2

    Keep it away from secrets and sensitive data

    Set things up so the AI can’t read or use keys, passwords or access tokens, or paste them into the chat. The same goes for personal data and anything else sensitive. Even with that in place, never assume it won’t. Stay watchful.

  3. 3

    Make sure “done” is written down

    The AI works best when it knows what done looks like. You don’t need to write it in every prompt. Make sure it’s in the issue, the PRD or the spec, or ask the AI to add it there.

  4. 4

    Ask for a plan on bigger jobs

    For a feature or a larger change, have the AI lay out its plan and ask about anything unclear before it builds. For a small fix, this can be overkill.

  5. 5

    Keep the context under control

    The longer a session goes on, the more each step costs, and the worse the AI’s work gets, because it has more and more to keep track of.

  6. 6

    One session, one job

    I keep one session for one job, like one feature or one page design. It also makes pull requests (PRs) easier to manage: with 10 or more open, remembering which session is working on which is a nightmare. One PR per session is a simple way to think of it, but not a hard rule. Two small PRs in one session is fine.

  7. 7

    Be careful when merging

    Merging is an easy place for the AI to make a mistake and lose or undo work. Make sure it knows there may be other work in progress, and that the main branch may have moved on since the last merge. Harness guardrails help, but they’re not a 100% guarantee, so check the result.

  8. 8

    Hand over, don’t drag on

    When a session runs long, ask the AI to write a short handover note: what’s done, what’s next and what to watch out for. Then start a fresh session from that note.

  9. 9

    Use GitHub issues for the work

    Issues are great for keeping track of tasks, especially bug fixes and design improvements. The AI can help you review, sort and prioritise them, and it’s easy to link each pull request to its issue.

Your work

Questions for your own project

  1. Where are the lines on your project?

    Which work should people do, which should people do with AI, and which can the AI do on its own? When does a person need to step in, and why?

  2. Which decision has no name next to it?

    Who looks at the real screen before a change is approved? Who decides what becomes a new rule?

  3. Does the AI have the context it needs?

    The goal, the requirements, the task and what “done” looks like. What’s missing today?

  4. What is slowest: building, or deciding?

    If building takes minutes and a decision takes a week, the building isn’t what to speed up.

  5. Which layer has nothing written down?

    If your rules cover screens but not data or security, that’s where the AI will guess. Start with the layer that would hurt most if it went wrong.

  6. What do you correct again and again?

    That’s a chance to improve the harness, with a rule, skill, check or workflow, so the AI gets it right next time without being told.

For later

More detail

Background for anyone who wants to go deeper.

These cycles aren’t new: how teams already worked
CycleWhat teams already didWhat changes with AI
BuildingBuild a little, check it, repeatAI does it in minutes. People step out of it.
CheckingColleagues review each other’s workAI does the first check. People keep the judgement calls.
Learning from usersTry it with users, then improveThe same, but now it’s the slowest part.
Improving how we workLook back together and agree changesChanges must be written down so the AI follows them.

Others describe these cycles in more detail. Andrew Ng groups them by how long each takes (minutes, hours, weeks). This page looks at them from the side of the person directing the work: what they do while the AI builds.

Inside the build: where the AI stops and asks

Inside the build loop, a good harness decides in advance where the AI must stop and ask instead of guessing. One plan goes in. What comes out is a change ready for approval, or the exact reason the AI stopped. Stopping early feels slow, but it’s the cheapest moment to fix anything.

The build loop inside a harness. People write the plan and design guide. The AI then checks the plan, does a safety check, designs the screens, builds, checks its work, and sends it for approval. It stops and asks if the plan has gaps or clashes with the design guide, and stops if a check fails. A person looks at the real screen and approves. Afterwards, the team looks back and adds new rules to the harness. Plan + design guide · people Check the planis anything missing? Safety checklog-in, personal data Design screensfrom the design guide Buildwrite the code Checkautomatic checks Send forapproval gaps → stop and ask clashes with harness → ask check fails → stop Look at screen · approve Look back · new rules
  • AI does everythingPeople write the plan and the design guide. If those are empty, the AI stops.
  • We don’t need people to review any morePeople still review. It just focuses on one place: the finished change.
  • If every check passes, it’s fineNo automatic check asks whether a screen is good enough to show anyone.
  • Stopping means something brokeStopping is on purpose. Guessing and carrying on costs more.