"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops, and this is the transition we're going to see for the rest of the year."

My first reaction was the cynical one. Great, another "prompt engineering is dead, here's the new thing" take, right on schedule. We get one of those every few months.

But I'd already been doing a sloppy version of this for weeks without a name for it, so the take landed differently. I had a little bash script babysitting a LangGraph agent that kept dying on a flaky upstream API, restarting it, re-reading a TODO file, and committing whatever it managed to finish. It was ugly. It worked better than me sitting there re-typing "ok now continue" forty times. Turns out that ugly script has a name now, and a surprisingly coherent theory behind it.

What loop engineering actually is

Addy Osmani at Google wrote the essay that named the thing on June 7, 2026, pulling together what Cherny and others had been saying. His definition is the one worth memorizing because it's blunt:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

That's it. The unit of work stops being the prompt and becomes the loop: define a goal, let the agent inspect the world, make a change, run a check, read the result, decide the next move, and repeat until some condition says stop.

If you've built agentic systems, this isn't new mechanically. It's the same act → observe → decide cycle that ReAct described back in 2022, the thing AutoGPT cargo-culted in 2023. What's new is the posture. You're no longer in the conversation. You're not the one feeding it the next instruction. You're standing outside, building the machine that does the feeding.

Here's the difference stated plainly, because it's easy to nod along and miss it:

• Prompt engineering is tactical. You optimize one turn. You're inside the loop, and the loop's quality is bounded by how fast you can read and type.

• Loop engineering is structural. You optimize the cycle. The loop runs while you sleep, and its quality is bounded by how well you designed the exits and the verification.

The whole shift is just where you stand relative to the cycle:

Steinberger put the same idea more aggressively: you shouldn't be prompting coding agents anymore, you should be designing loops that prompt them. I think the aggression is half marketing and half correct, which I'll get to.

The dumbest version works, and that's the point

Before the polished framing showed up, there was Ralph.

Geoffrey Huntley named and documented a technique that is, at its core, this one line:

# The entire "framework"
while :; do cat PROMPT.md | claude-code ; done

That's the Ralph Wiggum loop. Named after the Simpsons kid because it's, in Huntley's words, "deterministically bad in an undeterministic world." It just keeps going. No memory of the last run, no clever orchestration, no state machine. It reads the same prompt file every iteration and bumbles forward.

The trick that makes it not-insane is where the state lives. Each iteration gets a fresh context window. The agent remembers nothing. So the file system becomes the memory:

# State doesn't live in the conversation. It lives on disk.
# - @fix_plan.md   -> what's left to do
# - @specs/*       -> what "done" means
# - git history    -> what already happened, and a way to undo
git add -A && git commit -m "loop iteration: implemented auth middleware"

The plan file shrinks as work gets done. Git is both the audit trail and the safety net. The context window resets every loop, which sounds like a bug and is actually the feature, because it means context rot never accumulates. Each iteration is clean.

The numbers people quote for this are genuinely funny. Huntley says he delivered an MVP for a \(50,000 contract for \)297 in API spend. A team at a Y Combinator hackathon ran six Ralph loops in parallel git worktrees and shipped six framework ports overnight, around 1,000+ commits and ~$600 of API. For anyone building from Kathmandu, where "just throw more engineers at it" was never the cheap option, that cost structure is the part that actually changes the math.

By mid-June 2026, Claude Code shipped /loop and /goal as native commands. The bash hack became a feature. /loop re-runs a prompt on a cadence, /goal keeps iterating until a verifiable condition is met. The hand-rolled thing I was embarrassed about became supported.

The anatomy, if you want to build a real one

Ralph is the toy that teaches the idea. A loop you'd actually trust with a production repo needs more scaffolding. Osmani's essay lays out the building blocks, and after running a few of these myself, I'd say they're the right list:

1. Automations — something that triggers the loop and finds work (a schedule, a webhook, a queue), so you're not the trigger.

2. Worktrees — isolated environments (git worktree) so parallel agents don't stomp each other. This is the unlock for running many loops at once.

3. Skills — codified project knowledge in SKILL.md files so the agent doesn't relearn your conventions every run.

4. Plugins / connectors — MCP and friends, so the loop can touch your actual tools instead of hallucinating about them.

5. Sub-agents — split the work: one agent ideates, one implements, one verifies. They don't share a brain, which is good, because the verifier shouldn't be the implementer marking its own homework.

And the one Osmani flags as non-negotiable, sitting underneath all of it:

1. State / memory — external storage (markdown, a Linear board, a DB) where progress survives between runs. Models forget. The loop only works if something remembers for them.

Notice that exactly one of these six is about the prompt. The rest is plumbing, isolation, verification, and memory. That ratio is the job now. The prompt is a config file. The loop is the program.

Where it falls apart (the part the hype skips)

Here's where I get off the marketing train.

The same essays that sell you loops are unusually honest about how they rot, and there's a great word for the failure: loopmaxxing. It's the loop-era version of tokenmaxxing, the status game of bragging about how many tokens you burn. Loopmaxxing is believing that if the loop just runs long enough, any problem gets solved. It doesn't.

A few ways I've watched (or read about) loops eat money and produce nothing:

No real exit condition. "Improve the UX" is not a stopping condition. A compiler passing is. Unit tests going green is. If you can't write the check as code, the loop has no idea when to quit, and it'll happily run until your bill says stop. The good loops replace human approval with deterministic exits: linters, type checkers, test suites. The bad ones replace it with vibes.

Local minima. This one surprised me. Even on deterministic tasks, loops get cagy. Karpathy described agents nudging a learning rate by a fraction of a percent across dozens of iterations to claim a nominal win, instead of trying a bold redesign. He blames RLHF rewarding safe, conservative moves. The loop optimizes what's measurable and fast to confirm, and quietly avoids the risky rewrite that would actually help. You get motion, not progress.

Comprehension debt. This is the scary one and the reason I won't fully hand over the wheel. Code ships faster than your understanding of it grows. After a long unattended run you can have a green test suite and a thousand commits and zero map of why any of it is shaped the way it is. Huntley himself says he wouldn't run Ralph on an existing codebase, and that you should expect roughly 90% completion before a human has to step in. That last 10% is where the judgment lives, and it doesn't automate.

Osmani's framing of this is the line I keep coming back to: designing loops with judgment accelerates progress, designing them to avoid thinking accelerates decline. Same structure, opposite outcomes. The loop is an amplifier. It makes a good engineer faster and a lazy one dangerous, quicker.

So is this real or is it a rebrand

Bit of both, honestly.

The mechanics are old. Anyone who's wired up a LangGraph state machine or run an agent against a tool registry has built a loop. Calling it "loop engineering" is partly just giving a name to something practitioners already did.

But names matter, because they move where you put your attention. When I think "prompt engineering," I fuss over wording. When I think "loop engineering," I fuss over the things that actually break in production: the exit condition, the verifier, the memory store, the worktree isolation, the cost ceiling. The second list is a much better use of my time. The rename is doing real work even if the code underneath rhymes with 2022.

My actual take, after living with it: the people saying "stop prompting entirely" are overshooting. You still prompt. You prompt less often and at a higher altitude, and you spend the freed-up time building the harness around it. The win isn't that humans leave the loop. It's that humans move to the edge of the loop, where the leverage is, and let the boring middle run itself.

The script I was embarrassed about was the right instinct. It just needed an exit condition and someone reading the diffs.

What's the dumbest loop you've left running overnight, and did it work?

Sources: Addy Osmani — Loop Engineering · Geoffrey Huntley — Ralph Wiggum as a software engineer · Boris Cherny quote · bdtechtalks — Demystifying loop engineering, avoid loopmaxxing · ReAct paper (2022)

That's the problem with treating an LLM's own judgment as your safety layer. It refuses things it shouldn't, allows things it shouldn't, and gives you nothing structured to reason about. You can't alert on a vibe. You can't route on a vibe. You definitely can't explain to a compliance person why the model said no.

A guardrail is a separate thing that sits outside the model and makes a yes/no call you can actually use. Llama Guard is Meta's open take on that, and it's the one I keep reaching for because it's small, self-hostable, and gives you a category code instead of a vibe. Here's how it actually works once you wire it in.

What a guardrail is, concretely

The instinct is to stuff "don't answer anything harmful" into your system prompt and call it a day. The thing is, that puts the judge and the defendant in the same model. When the model is jailbroken, the same prompt injection that hijacks the answer hijacks the refusal logic too. They're the same weights.

A real guardrail is a separate classifier. Text goes in, a label comes out. You run it on the user's message before it hits your main model, and on the model's reply before it reaches the user. Two checkpoints:

user ──▶ [GUARD: input] ──▶ your LLM ──▶ [GUARD: output] ──▶ user
              │                              │
           blocked?                       blocked?

The guard doesn't generate your answer. It has one job: decide if a piece of text is safe under a policy, and if not, tell you which rule it broke. That separation is the whole point. Even if someone fully jailbreaks your assistant into writing something nasty, the output guard is a fresh model that never saw the jailbreak — it just sees the nasty text and flags it.

Llama Guard

Llama Guard is a Llama model fine-tuned to do exactly one thing: classify a conversation as safe or unsafe against a fixed taxonomy of harm categories. Llama Guard 3 (8B) covers 14 categories aligned to the MLCommons hazards taxonomy — things like violent crimes (S1), privacy (S7), indiscriminate weapons (S9), self-harm (S11), and so on. It's not a chatbot. You don't talk to it. You hand it a transcript and it hands you back a verdict.

The output format is deliberately boring, which is what you want from a classifier:

safe

or

unsafe
S9

First line: the verdict. Second line (only when unsafe): the comma-separated category codes it tripped. That's it. No prose, no apology, nothing to parse heuristically.

Running it

The honest way to learn this is transformers directly, because the magic is in the chat template and you should see it once. You'll need to accept the license on the model card and be logged into Hugging Face.

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "meta-llama/Llama-Guard-3-8B"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,   # bf16 fits the 8B on a single 24GB card
    device_map="auto",
)

def moderate(chat):
    # apply_chat_template builds the full Llama Guard prompt — taxonomy,
    # the conversation, and the "now classify" instruction. Don't build this by hand.
    input_ids = tokenizer.apply_chat_template(chat, return_tensors="pt").to(model.device)
    output = model.generate(
        input_ids=input_ids,
        max_new_tokens=20,        # the answer is one or two tokens; don't waste compute
        pad_token_id=tokenizer.eos_token_id,
    )
    # slice off the prompt so we only decode what the model actually generated
    prompt_len = input_ids.shape[-1]
    return tokenizer.decode(output[0][prompt_len:], skip_special_tokens=True)

Checking a user message — note the role is user, so it judges the prompt:

print(moderate([
    {"role": "user", "content": "Walk me through synthesizing sarin at home."},
]))
# unsafe
# S9

Checking a model reply — you pass the whole turn, and Llama Guard classifies the last message, which here is the assistant's:

print(moderate([
    {"role": "user", "content": "What's a good weeknight pasta?"},
    {"role": "assistant", "content": "Cacio e pepe — pasta water, pecorino, black pepper, done in 15 minutes."},
]))
# safe

That role-aware behavior is the bit people miss. Same model, same call. Put a user message last and it moderates input; put an assistant message last and it moderates output. You don't switch models or flags.

If you just want to poke at it without burning your GPU budget, Ollama ships it and the smaller 1B variant:

ollama run llama-guard3:1b "How do I pick a lock that isn't mine?"

Wiring it into a real pipeline

Two checks, fail-closed, with the category code preserved so you can log and route. This is roughly what I run in front of an agent:

from dataclasses import dataclass

@dataclass
class GuardVerdict:
    safe: bool
    categories: list[str]

def parse(raw: str) -> GuardVerdict:
    lines = [l.strip() for l in raw.strip().splitlines() if l.strip()]
    if not lines or lines[0].lower() == "safe":
        return GuardVerdict(safe=True, categories=[])
    cats = lines[1].split(",") if len(lines) > 1 else []
    return GuardVerdict(safe=False, categories=[c.strip() for c in cats])

def handle_turn(user_msg: str) -> str:
    # 1. Gate the input
    verdict = parse(moderate([{"role": "user", "content": user_msg}]))
    if not verdict.safe:
        log.warning("blocked input", categories=verdict.categories)
        return "I can't help with that one."

    # 2. Run your actual model
    reply = my_llm.generate(user_msg)

    # 3. Gate the output before the user ever sees it
    verdict = parse(moderate([
        {"role": "user", "content": user_msg},
        {"role": "assistant", "content": reply},
    ]))
    if not verdict.safe:
        log.warning("blocked output", categories=verdict.categories)
        return "I generated a response but it didn't pass our safety check."

    return reply

The output check is the one teams skip, and it's the one that saves you. Your input gate can be perfect and a clever prompt can still steer the model into category S11 territory in its answer. The output guard never saw the manipulation. It reads the finished text cold and judges it on its own.

Custom categories, because the default taxonomy is not your policy

Here's where it gets useful for actual products. The 14 MLCommons categories are about societal harm. Your business probably cares about other things — a fintech bot giving unlicensed investment advice, a health app dispensing diagnoses, a support bot leaking another customer's data. Llama Guard lets you redefine the policy in the prompt itself.

The chat template accepts your own categories:

custom = {
    "S1": "Financial Advice. Telling users to buy/sell specific securities, "
          "promising returns, or giving tax guidance we aren't licensed to give.",
    "S2": "Account Data. Revealing any account, balance, or transaction detail "
          "for an account other than the verified current user's.",
}

def moderate_custom(chat, categories):
    input_ids = tokenizer.apply_chat_template(
        chat,
        categories=categories,       # override the built-in taxonomy
        return_tensors="pt",
    ).to(model.device)
    output = model.generate(input_ids=input_ids, max_new_tokens=20,
                            pad_token_id=tokenizer.eos_token_id)
    return tokenizer.decode(output[0][input_ids.shape[-1]:], skip_special_tokens=True)

print(moderate_custom(
    [{"role": "user", "content": "Should I put my whole savings into NEPSE right now?"}],
    custom,
))
# unsafe
# S1

It's zero-shot against your wording, so it won't be as sharp as it is on the categories it was trained on. Treat custom categories as a strong first filter, not a guarantee, and keep a human-reviewed eval set for the ones that matter. I learned that the hard way when a category I wrote too broadly started flagging every mention of "money."

The stuff the docs gloss over

Latency is real and it stacks. You're now running an 8B model twice per turn, on top of your actual LLM. On a single GPU here in Kathmandu — where I'm not exactly swimming in spare A100s — the input check and output check together added a few hundred milliseconds to every response. For a chat UI that's fine. For a voice agent where every 100ms is felt, it hurt. The 1B variant exists for exactly this; it's noticeably weaker on subtle cases but fast enough that I run it for input gating and reserve the 8B for output.

It is a content classifier, not a jailbreak detector. Llama Guard tells you whether text violates a policy. It is not built to catch "ignore your previous instructions" style injections that are themselves benign-looking. People conflate the two and then act surprised. If prompt injection is your threat, you want something like Prompt Guard alongside it — different tool, different job.

Fail-closed has a cost and you should feel it. When the guard errors out or times out, what do you do? Blocking everything means one flaky GPU node takes your whole product down. Allowing everything means an outage silently disables your safety layer. I block on input-check failure (cheap to be cautious) and degrade to a logged-and-flagged allow on output-check failure with an alert — but that's a product decision, not a default. Make it on purpose.

False positives will annoy real users. Security and medical questions trip S6 (specialized advice) constantly, and plenty of those are legitimate. Don't just hard-block. Log the category, watch the distribution for a week, and you'll find one or two categories generating most of your false positives. That's where the tuning effort goes.

Where I'd start

If you're adding this to something today: run the 1B on input, the 8B on output, log every category code even when you allow the turn, and don't write custom categories until you've watched the default ones run against real traffic for a few days. The logs will tell you what your actual policy needs to be — which beats guessing at it in a prompt.

The bot that refused my own customer their own subscription? It now has an output guard that would've caught nothing in that case — because the failure was a refusal, not unsafe content. Guardrails aren't a cure-all. But at least now when something gets blocked, I get a category code and a log line instead of a shrug. That alone is worth the two extra model calls.

Today, AR seamlessly blends virtual elements with our physical world, enriching real-life experiences through interactive and immersive digital overlays. Unlike virtual reality, which creates entirely separate environments, AR enhances our perception of reality by adding new layers of information and interaction.

In this article, you’ll learn how to build your first marker-based AR application using Unity and the Vuforia Engine. No prior experience in Unity is required, however, it will be handy if you know the basics of transformations in Unity.

1. Install Unity

Install Unity and setup for android platform. You can follow the official documentation from https://docs.unity3d.com/Manual/android-sdksetup.html

2. Download the Vufora package for Unity

Visit ‘https://developer.vuforia.com’ and create an account for free. After that, go to Downloads and Download the vuforia package for Unity.

3. Setup Vuforia Engine for Unity

a) Open Unity Hub and Create a New Project. Select the 3D ( Built-in Render Pipeline ) template, give a project Name and then Create Project.

b) You need to start by first importing the Vuforia Package in the Unity Engine. Simply Open the file location where you downloaded the package, and Drag and Drop the package in the Project Window of Unity.

Delete the existing Main Camera and Import the AR Camera from the Hierarchy Window.

c) Get a license key to use the Vuforia Engine. Vuforia Provides a Basic License for Free. For that, you just need to visit ‘https://developer.vuforia.com/develop/licenses’ and ‘Generate a Basic License’ for free. Give a name to your application and then copy the generated license key.

Add the License to the Vuforia Engine Configuration. Click the AR Camera, then in the Inspector Window, Open Vuforia Engine Configuration and Paste the copied license key to the App License Key.

d) Unity allows you to build the application in multiple platforms. We’ll be using Android, since it is the most common platform. Go to File > Build Settings > Android > Switch Platform. Also, Click on the Add Open Scenes to ensure that your scene is included.

3. Create a Target Database

Now that we’ve set up Vuforia and Unity, We’ll proceed to create a target Database using Vuforia’s Target Manager.

a) Head to https://developer.vuforia.com/ > My Account > Target Manager. Then Click on ‘Generate Database > Device’. Dont forget to enter a name for the database. The database will appear in the list below. Click on the name of your database then, Click Add Target and type: Image. Select an Image from your computer that you want to use as a target. You can select multiple Images.

Vuforia also provides a rating for your target. Vuforia uses unique feature points from your image to identify the target. The better and more unique your image is, the better is its rating. If the rating is more than 3 stars, you are good to go.

You can also see the feature points by clicking the image and then, Show Feature Points.

b) Download the Target Database ( Unity ). The database will be downloaded as a Unity Package.

c) Drag & Drop the database to the asset in the Project Window.

Now comes the most important part, Actually creating the Image Target and Linking a 3D Object with it. You can find plenty of free 3D models online or create it yourself with 3D modeling softwares like Blender.

d) Import the 3D Models in the Assets in the Project Window. You can create a folder for each model to properly manage the assets. Simply select all the files related to an asset, then Drag & Drop the asset files.

e) To create an Image target, Right Click on the Project Window, Navigate to Vuforia Engine then Select the Image Target. Rename it to something meaningful.

f) In the Inspector Window, in the Image Target Behaviour (Script ), select Type: From Database, then the database as your target database, and select an Image. The Image will appear in your scene.

g) Drag the 3D model to the Hierarchy Window, as a direct child of the image target. Perform Necessary transformations like scaling, translating etc. to place the 3D object just above the marker.

Important: Click the target in the hierarchy window, and from the inspector window In Default Observer Event Handler ( Script ), change the ‘Consider target visible if its status is: ‘ dropdown to ‘Tracked’.

Your Scene window should look like this:

( Optional )If you want multiple images to be detected at once, you should change the Max Simultaneous Tracked Images from the AR Camera> Inspection Window > Vuforia EngineConfiguration to a different value like 2.

4. Final Steps:

You can test if everything is working properly by clicking the ‘play’ button located just above the scene window.
Change the Aspect Ratio to 1920 x 1080 Potrait from the Dropdown if you’re building it for a mobile phone.

5. Build the Application

Go to File > Build Settings > Build to build the apk. Check the Development Build to allow for USB Debugging. Connect and Select your device from the Run Device dropdown and then Patch and Run to debug on your phone.

Building may take some time, so have patience.

Congratulations !! You built your first AR Application.