Fitra Kacamarga
← Blog

Loop Engineering: When Prompting Stops Being the Job

The next AI craft is designing loops, harnesses, and verifiers that make work converge.

aiagentsengineeringautomation

There is a line from Boris Cherny’s Acquired Unplugged conversation that stayed with me longer than the rest of the interview.

It was not the kind of line people usually turn into a product thesis. It did not sound like a launch announcement. It did not even sound like advice. He was just describing his day.

He said he does not really prompt Claude directly anymore. He has loops running. The loops prompt Claude, decide what to do next, and keep moving. His job is to write the loops.

I kept thinking about that sentence because it names a shift many builders are already feeling but have not yet described cleanly.

At first, AI feels like a better text box.

You ask. It answers.

You ask better. It answers better.

For a while, this is enough. It feels like cheating. A blank page becomes a draft. A vague feature becomes code. A messy idea becomes a structured memo. The distance between intention and artifact collapses.

Then the real work arrives.

The code does not compile. The test fails. The essay sounds technically correct but emotionally dead. The customer feedback summary misses the complaint that actually matters. The chart is clean but the metric does not reconcile. The claim recommendation sounds plausible, but the evidence would not survive audit.

This is the moment most people return to prompting.

They make the prompt longer. They add rules. They add examples. They tell the model to be careful. They say, in one form or another: please do not make mistakes.

I have done this too.

But after enough sessions with coding agents, writing agents, research agents, and data workflows, the problem started to feel different.

The issue was not that the prompt was too short.

The issue was that I was still the loop.

I was the one remembering the goal. I was the one reading the failure. I was the one deciding whether to retry, what to change, what counted as good enough, and what lesson should carry into the next run.

The AI was doing the work inside each turn.

I was doing the work between turns.

That gap is where loop engineering lives.

The first crack in the prompt era

The prompt era taught us something useful: models are incredibly sensitive to the shape of instruction.

A bad prompt produces noise. A better prompt produces structure. A great prompt can make the model feel like a competent collaborator.

But prompts have a ceiling because prompts are usually linear.

They assume the work can be solved by asking once, or asking again with more detail.

Serious work does not behave that way.

Software is not linear. Research is not linear. Product discovery is not linear. Claims operations are not linear. Writing is not linear either, even though people pretend it is because the final page looks clean.

The real shape of work is uglier.

You try something. Reality pushes back. You revise. Another problem appears. You learn that your first framing was wrong. You cut a section. You add a test. You ask a user. You check the logs. You realize the output was correct in the abstract and useless in the real system.

This is why Boris’s line feels important.

He is not saying, “I found a better way to prompt Claude.”

He is saying the work moved up one level.

The job is no longer to manually ask the model every time something needs to happen.

The job is to design the process that asks, checks, retries, remembers, and knows when to stop.

That is a different craft.

The night the loop became obvious

The easiest place to see this is coding.

A coding agent always begins with confidence. It reads the files, edits the code, and gives you a clean summary. The summary has the tone of completion. It says what changed. It says why. It often sounds like the task is done.

Then you run the test.

The test fails.

The first few times this happens, it is annoying. You feel like the agent wasted your time. The output looked so convincing. The explanation sounded so organized. Why did it miss something so basic?

But eventually the emotional response changes.

A failing test stops feeling like an interruption and starts feeling like the first honest sentence in the conversation.

The model guessed. The codebase answered.

Now the system has reality in it.

Read the error. Find the mismatch. Patch the code. Run the test again. If it fails again, read the next error. If it passes, run the next check. If the diff is suspicious, ask a reviewer. If the reviewer finds a design problem, revise again.

This is not an exotic AI workflow.

This is just engineering.

The only new thing is that more of the cycle can now be delegated.

That realization changed how I judge agent output. I care less about whether the first answer is impressive. I care more about whether the system around the model can converge.

A one-shot answer can be brilliant and still be dangerous.

A loop can start messy and still produce something trustworthy.

The difference is feedback.

The human as connective tissue

Most AI usage still depends on the human being the connective tissue.

The human copies context from one tool to another. The human reads the output. The human decides if it is good. The human asks for a revision. The human remembers the last failure. The human turns a repeated judgment into a new prompt every single time.

This feels normal because it is how we have been using software for decades.

But it is also a waste of the new medium.

If the same task happens three times in a week, something strange is happening. The human has already revealed a pattern, but the system has not captured it.

That is the place to build a loop.

Not the most glamorous task.

The most repeated one.

The support tickets that always need the same categorization.

The customer feedback that always needs the same summary.

The code review that always checks the same avoidable mistakes.

The draft that always needs the same anti-slop pass.

The data report that always needs the same reconciliation check.

The claim review that always needs the same evidence boundary.

A loop begins when you stop treating those repetitions as individual requests and start treating them as a process trying to become explicit.

Underfunding as a forcing function

One of the more interesting ideas around Boris’s workflow is the underfund principle.

When a project looks like it needs four engineers, put two on it.

At first, this sounds like austerity. It sounds like management pretending scarcity is strategy.

But used correctly, the point is not to make people suffer.

The point is to make manual work impossible.

A fully staffed team can keep paying human attention for everything. Someone will review every output. Someone will copy-paste into the next system. Someone will make the same judgment call again. Someone will become the glue.

The work gets done, but the machine does not improve.

A constrained team has to ask a different question:

What are we doing for the third time that should become a loop before the fourth?

This is why token spend is often misunderstood.

If tokens only produce a single artifact, then yes, the cost is consumed. You paid for a draft, a patch, a summary, a one-off analysis.

But if tokens produce a reusable workflow, the accounting changes.

A test suite is not just output.

A rubric is not just output.

A saved failure mode is not just output.

A reviewer agent, a memory file, a repeatable prompt, a small automation, an eval harness — these are not artifacts in the normal sense. They are future discounts.

The first run may be expensive.

The second run should be cheaper.

The tenth run should feel unfair.

That is the compounding effect people miss when they calculate AI ROI only as “tokens in, code out.”

The real question is not whether the model saved an hour today.

The real question is whether today’s run made tomorrow’s work structurally cheaper.

Taste before it disappears

There is another uncomfortable part of this conversation.

For now, human taste is still a moat.

You can feel it when reading AI output. The model can produce something coherent, but coherence is not the same as judgment. It can write a product idea, but the idea might be boring. It can summarize feedback, but miss the emotional center. It can refactor code, but make the system less legible. It can produce a blog post, but the whole thing smells like a competent ghost wrote it.

This is where taste matters.

Taste says: this is technically fine and still not good.

Taste says: the argument is there, but the opening has no blood in it.

Taste says: this abstraction is clever, but the customer will not care.

Taste says: this claim recommendation may be plausible, but it is not yet evidence.

The mistake is treating taste as something that must stay trapped inside the human forever.

Some taste cannot be automated. But a surprising amount can be encoded.

Examples help. Negative examples help more. Rubrics help. Golden cases help. A reviewer that knows your usual failure modes helps. A checklist that says “remove generic AI phrasing” helps. A rule that says “if evidence is missing, escalate instead of guessing” helps.

That is how taste becomes a system.

Not perfectly.

But enough to compound.

This is why waiting is dangerous. If model taste improves every cycle, then the window where human taste creates leverage is not infinite.

The answer is not to wait for better models.

The answer is to pour your taste into loops while it still gives you an edge.

Build for the next model, not this one

A lot of people overfit to the current model.

They discover a prompt shape that works. They build a brittle chain around it. Then a new model arrives and the old incantation behaves differently.

This is the wrong layer to optimize.

Models will keep improving. That is the part of the system most builders do not control.

What we can control is whether our workflows can absorb the improvement.

A good loop should get better when the model gets better.

If the next model can categorize feedback more accurately, the loop should route fewer cases to humans.

If the next model writes better code, the loop should pass more tests before review.

If the next model has better judgment, the verifier should reveal which decisions can move from human approval to automated approval, and which ones still cannot.

This is the ladder of autonomy.

You do not go from manual work to blind trust in one jump.

You remove yourself one decision point at a time.

First the agent drafts.

Then it checks.

Then it fixes obvious failures.

Then it flags ambiguity.

Then it handles routine cases.

Then it proposes new work.

Then it runs overnight.

The human does not disappear.

The human changes jobs.

From operator to architect.

From reviewer of every output to designer of the system that decides which outputs deserve review.

Why harness matters

None of this works if the model has no environment.

A model trapped in a chat box can only perform confidence.

A model inside a harness can touch reality.

It can read files. Run tests. Open a browser. Inspect logs. Compare screenshots. Query data. Call tools. Save memory. Hand work to another agent. Return with evidence.

This is why harness engineering and loop engineering belong together.

The harness gives the model a workplace.

The loop gives the work a rhythm.

Without the harness, the loop has no reliable feedback.

Without the loop, the harness becomes a fancy one-shot tool.

The serious systems combine both.

They give the model access to reality, then force it to listen when reality disagrees.

That is what separates useful autonomy from theatrical autonomy.

The part I do not want agents to decide alone

There is one place where I become much less romantic about loops.

Authority.

A loop can decide what to try next.

It should not automatically decide what it is allowed to change.

This matters in software deployment, payments, production data, compliance, healthcare, and especially claims workflows.

An agent can inspect a BPJS claim. It can read the policy. It can compare diagnosis codes and procedure codes. It can notice a mismatch. It can draft an explanation that looks better than what a tired operator would write at 11 p.m.

That still does not mean it should mutate claim status.

A fluent answer is not authorization.

A green check is not always permission.

A plausible recommendation is not a verified decision.

This is where verifier engineering becomes the companion to loop engineering.

Loop engineering asks:

What should the agent do next?

Verifier engineering asks:

Is the evidence sufficient for the system to accept this as done?

For low-risk work, the verifier can be simple. A test passes. A format check succeeds. A rubric score is high enough.

For high-risk work, the verifier must be stricter. Deterministic rules. Typed decisions. Audit trails. Human approval gates. Explicit pass, retry, escalate, or block outcomes.

This is the boundary I care about in ClaimMind.

Let the agent gather evidence.

Let it find contradictions.

Let it draft the ticket.

Let it recommend the next action.

But no verified ticket, no state mutation.

That principle is not anti-AI.

It is what makes stronger AI usable in serious workflows.

LLMs propose.

Deterministic verifiers dispose.

Humans approve where the stakes demand it.

The generalist gets a new machine

Boris also said something that feels optimistic: this is the golden age of the generalist.

I think that is true, but only for a specific kind of generalist.

Not the shallow generalist who uses AI to produce average work in ten domains.

The useful generalist is the person who can hold the shape of a problem across domains and design loops around it.

A founder can now research, prototype, write, analyze, test, and ship in the same day. Not because they are suddenly a world-class engineer, designer, analyst, and operator at once, but because they can orchestrate systems that borrow competence from many places.

The bottleneck moves.

It is no longer only skill execution.

It is goal selection, taste, verification, sequencing, and authority.

What should we build?

What does good look like?

What feedback matters?

What can be automated?

What must be reviewed?

What should never happen without approval?

These questions are not going away.

They are becoming more important.

The question I keep returning to

The next time I catch myself prompting the same thing for the third time, I try to stop.

Not always successfully.

The habit of being the loop is strong.

It feels productive to keep asking. It feels responsible to keep reviewing. It feels safer to remain in the middle of every step.

But the question is becoming harder to avoid:

Why am I still the loop?

If the task is repeated, it wants a process.

If the process has standards, it wants an eval.

If the eval finds failures, it wants memory.

If the action touches risk, it wants a verifier.

If the verifier passes, it wants a stop condition.

That is the new craft.

Prompt engineering was about making the model speak better.

Loop engineering is about making the system work better.

Harness engineering gives the model a workplace.

Loop engineering gives the work a rhythm.

Verifier engineering gives the system an authority boundary.

Together, they move AI from answer machine to work system.

The future advantage will not belong only to people who can write clever prompts.

It will belong to people who can design loops good enough that the prompt disappears into the machinery.

Prompt asks.

Loop works.

Verifier decides.

And somewhere between those three sentences is the next job description for builders.

References