I Stopped Prompting Coding Agents. I Started Engineering the Loop.

For a while, I thought getting better results from coding agents was mostly a prompting problem.

Give the agent more context. Write a clearer specification. Add examples. Ask it to think through edge cases. Tell it to run the tests.

That helped.

It also left the hardest problem untouched.

The agent would say the task was done, but the code might still be sitting on a branch. A test could be green locally while production used a different route. The visible feature might work while a backend contract quietly broke. A fix could solve the reported example and leave the entire class of failures intact.

"Code written" and "work done" were not the same state.

Once I saw that clearly, I stopped spending most of my energy on individual prompts. I started designing the system around the agent: how work enters, what context it receives, which actions it may take, how results are checked, where state persists, and what proof is required before anything can be called done.

That is the practical meaning of Loop Engineering for me.

The Agent Was Not the Bottleneck Anymore

I build Wimemo, an iPhone app that turns travel photos into a private map and memory system. I run it as a one-person company, with AI assisting product work, engineering, testing, operations, support, and content.

The product spans four repositories:

• an iOS app
• a backend
• a public website
• an HQ repository for product decisions, operating rules, and cross-repository work

Modern coding agents are capable enough to make useful changes across all four. That is exactly where the new risk begins.

When implementation becomes cheap, unfinished coordination becomes expensive.

What branch contains the actual fix? Did another agent leave compatible backend changes elsewhere? Were existing local edits preserved? Did the change reach main? Did the release gate run? Was production deployed? Did anyone test the real public URL rather than the local copy? Was the issue closed because the work was finished, or because the agent ran out of context?

Those are not prompting questions. They are system-design questions.

A Recent Release Made the Difference Obvious

I recently asked an agent to fix five SEO problems on the Wimemo website.

The list looked straightforward:

1. localized utility pages redirected to URLs that did not exist
2. English articles contained hidden versions of several other languages, creating multiple H1 elements in the canonical HTML
3. internal language links passed through unnecessary redirects
4. many articles had weak contextual links to the main topic pages
5. the site lacked independent editorial authority

A prompt could produce patches for the first four. It could not make the whole job complete by itself.

The real workflow needed to:

• inspect every repository before release
• preserve unrelated work already in progress
• change the localization generator, not patch hundreds of pages by hand
• add regression rules for language purity, H1 count, canonical links, and contextual linking
• run the backend release gate even though the visible change was on the website
• merge the intended work into main
• deploy the actual Nginx configuration
• follow every locale route in production
• fetch every sitemap URL
• submit the final canonical set to IndexNow
• close engineering issues with evidence
• keep external editorial outreach open because publication depends on another human organization

The release eventually passed 128 backend tests. The production verifier fetched 270 sitemap URLs and checked 63 articles.

Then something useful happened: the verifier reported 55 remaining redirected language links.

At first glance, the release had failed.

On inspection, the product code was correct. The verifier's regular expression was matching the zh prefix inside zh-Hant. Traditional Chinese links were being counted as Simplified Chinese links.

The checker was wrong.

That small incident captures a central truth about agentic development:

A loop is not reliable merely because it contains a test. The evaluator is part of the system, and it can fail too.

We corrected the check, reran the production crawl, and got the result that actually mattered: 270 unique URLs returned successfully, the canonical English pages contained one language and one H1, and stable localized links no longer passed through redirects.

The loop did not end when code was generated. It ended when the production claim was supported by evidence.

The Loop I Use Now

My current workflow has six parts.

1. Intake: turn a sentence into durable work

A request begins as a tracked issue, not as context that exists only inside one chat.

The issue records the outcome, repository, risk, and acceptance conditions. If the work crosses iOS, backend, web, or product strategy, it starts in the HQ repository and links to execution work in the code repositories.

This is the first boundary of the loop: conversation is temporary; product memory must be durable.

2. Context: give the agent rules, not just background

Each repository contains instructions about architecture, testing, release requirements, privacy boundaries, and decisions that must not be casually reversed.

This is more useful than pasting a giant project summary into every prompt.

Good agent context answers operational questions:

• Where does this change belong?
• Which existing pattern should it follow?
• What must never be broken?
• Which tests scale with the risk?
• What counts as a completed release?

Context is not documentation sitting beside the loop. It is executable policy for the loop.

3. Execution: isolate work without losing the real workspace

Agents need room to act, but they also need boundaries.

Before changing code, the workflow inspects branches, worktrees, and uncommitted files. Work that belongs to another task is preserved. The agent edits the smallest responsible surface, follows existing abstractions, and records any cross-repository dependency explicitly.

Autonomy without workspace awareness is just a faster way to overwrite someone else's work.

4. Verification: separate claims from evidence

"It should work" is not a result.

The verifier asks for observable evidence appropriate to the change:

• unit and integration tests
• migration tests
• static SEO invariants
• browser checks at desktop and mobile sizes
• performance signposts on a real device
• production HTTP behavior
• screenshots or pixel checks when visual output matters

The important design choice is that the implementation path does not get to define success after seeing its own output. Acceptance conditions should exist before the patch, and independent checks should challenge the agent's story.

5. Release: make main and production part of "done"

In a multi-repository product, a correct local diff is an intermediate artifact.

My release loop reconciles local work, runs the required gates, commits the intended scope, pushes main, deploys, and verifies the public result. If any of those steps are intentionally skipped, the task must say so plainly.

This prevents one of the most common forms of AI-assisted self-deception: a beautiful patch that no user is running.

6. Feedback: let production create the next input

The loop does not close permanently. It produces the next observation.

Analytics, support reports, App Store feedback, search data, performance traces, and production failures become new intake. They are not instructions to blindly change the product; they are evidence to compare against the original decision.

The output of one loop is often the context for the next.

Human in the Loop Is Not a Failure Mode

There is a temptation to describe better loops as removing the human.

That is not my goal.

I want to remove repetitive supervision, not product responsibility.

AI can inspect repositories, implement a localization invariant, run 128 tests, deploy a static site, and crawl 270 URLs. It cannot decide on my behalf whether a visible map-pin behavior is worth a performance tradeoff. It cannot promise that an independent publication will cover Wimemo. It should not quietly send a message, spend money, change pricing, or reinterpret a privacy boundary because those actions are convenient for the loop.

The human gate belongs where judgment, identity, money, trust, or irreversible external effects begin.

The purpose of Loop Engineering is not maximum autonomy.

It is bounded autonomy with proof.

A Minimal Loop for an Independent Developer

You do not need a multi-agent platform to start.

A useful minimum is:

1. Durable task: write the outcome and acceptance conditions somewhere that survives the conversation.
2. Scoped workspace: define the repository, files, and constraints before editing.
3. Implementer: let the agent make the change and explain affected behavior.
4. Evaluator: run deterministic checks and inspect the real user surface.
5. Stop rule: do not allow "done" while required evidence is missing.
6. Release receipt: record commit, deployment, test results, and anything deliberately left open.

That is already a loop.

Scheduling, multiple agents, fresh worktrees, model routing, budgets, and automatic retries can come later. Adding orchestration before you can define proof only makes uncertainty run faster.

What Loop Engineering Does Not Solve

Loops have costs.

They can overfit to what is easy to test. They can repeatedly reinforce a bad specification. They consume tokens and compute. They create maintenance work in the harness itself. A large rulebook can become stale context that every agent reads and nobody questions.

And a green loop can still produce a mediocre product.

Tests can prove that a button works. They cannot prove that the button should exist.

The more capable agents become, the more important it is to distinguish execution quality from product judgment. I use loops to make execution more reliable so I can spend more of my own attention on the parts that remain irreducibly human.

The Shift That Changed My Work

I still write prompts. They still matter.

But I no longer treat the prompt as the main unit of engineering.

The unit is the loop:

intent → context → action → verification → release → observation

The agent sits inside that loop. It is not the loop.

For an AI-native one-person company, this distinction is the difference between generating a lot of code and operating a real product.

I am building Wimemo this way in public: a private travel memory system, shipped by one founder with AI assistance and explicit human responsibility. I will keep writing about the patterns that work, the ones that fail, and the receipts that separate the two.

Wimemo: https://wimemo.com/about.html