The /goal Function Made Loop Engineering Click for Me

The /goal function in Codex made something click for me: the job is moving from prompting an AI one step at a time to setting up a loop where a competent system can keep working until the evidence says it is done.

That sounds grander than it feels in practice.

In practice, it feels like writing a clearer ticket. Or setting up a test harness. Or giving a good engineer access to the debugger, the logs, the failing test, and the definition of done, then getting out of the way long enough for them to think.

A few weeks ago, a lot of people were making fun of Boris Cherny for saying that his job was now to write loops. I get why it sounded funny. It has the slightly absurd ring of a 2026 tech quote that escaped containment. Peter Steinberger had a similar line about not prompting coding agents anymore, but designing loops that prompt agents. Addy Osmani later wrote about this as loop engineering: replacing yourself as the person constantly nudging the agent with a system that can keep the work moving.

I do not think the meme version quite captured the useful part.

The useful part is not that prompts are dead. The useful part is that prompting is becoming less like typing commands into a terminal and more like managing a small research process.

The model still needs direction. It still needs judgment. It still needs constraints. But the unit of work is changing.

Not: "Edit this function. Now run this test. Now inspect this file. Now try this other idea."

More like: "Here is the objective. Here are the tools. Here is how you can tell whether you are right. Keep going until the result holds up."

The manager metaphor is suddenly less annoying

I used to dislike the "AI as junior engineer" metaphor because it gave people the wrong instincts.

A junior engineer needs mentorship, context, review, and taste. An LLM needs all of that too, but it also has weird failure modes that no human junior has. It can be brilliant for 30 minutes and then confidently glue two unrelated facts together. It can pass a test for the wrong reason. It can overfit to your phrasing. It can decide that the thing it just wrote is probably correct because it wrote it.

So no, it is not simply "manage a junior engineer."

But the /goal workflow makes the better version of the metaphor feel real. You are managing a competent engineer inside a very particular operating environment.

Your job is to shape that environment.

Give it tools it can actually use. Give it a clear objective. Give it a way to measure progress. Give it permission to iterate. Give it a stopping condition. If the work is risky, put a human gate in front of the irreversible parts.

That is much closer to engineering management than chat.

The difference is that the loop has to be explicit. A person can infer a lot of social context from the team, the product, and the codebase. A model needs more of that context made executable: tests, scripts, harnesses, fixtures, logs, repro steps, evals, and written criteria.

The better your loop, the less you have to babysit the prompt.

My baseball project made the quote less funny

The thing that changed my mind was not a normal CRUD feature. It was the recent Starting Lineup Talking Baseball project.

I was trying to reverse engineer a 1980s electronic baseball game. The game runs on an old 8051-style microcontroller. It talks through a tiny speaker. It stores roster data, player ratings, baserunners, innings, scores, speech routines, and game state in a ROM and memory map that were not exactly eager to explain themselves.

In March, I had gotten partway there. By July, the models were better and, more importantly, the workbench was better.

Codex had access to the emulator. It could write analysis scripts. It could generate Ghidra exports. It could run the game in a harness. It could capture audio. It could send audio through ASR. It could compare transcripts against roster data. It could patch the harness and try again.

That is the part that matters.

I was not sitting there saying, "Now inspect byte 0x0580. Now compare it to this player. Now run this scenario. Now decode this waveform."

I was trying to set up a loop: interact with the artifact, observe what changes, form a hypothesis, build a test, and keep going until the memory map made more sense.

The model used disassembly, runtime traces, audio, baseball rules, and player knowledge as evidence. At one point I had to laugh because it was using ordinary knowledge about 1980s baseball players to reason about rating bytes. Rickey Henderson should look fast. Tim Raines should look fast. Sluggers should look different from speedsters. Pitchers who were starters should probably have different endurance-like values from relievers.

That sounds hand-wavy until the model builds a harness and checks the pattern against the table.

That was the moment where "my job is to write loops" stopped sounding like a goofy quote and started sounding like a pretty accurate description of the work.

The loop needs instruments, not vibes

The bad version of this idea is: tell an agent to go do a big thing, come back later, and hope.

The good version is instrumented and gives the model a concrete way to see if progress is being made.

For coding, that usually means tests, type checks, linters, fixtures, local servers, screenshots, CI logs, and maybe a second model acting as a skeptical reviewer.

For research, it might mean a simulation, a data pipeline, a parser, a benchmark, a replay harness, or a human-in-the-loop checkpoint.

For the baseball project, the instruments were weird because the system was weird. The game did not have a nice API. It had a speaker. So audio capture and transcription became part of the debug loop. The model could listen to what the game said, compare it with the roster, and use that as another signal.

That is the piece I think people underweight.

When models get smarter, the bottleneck is not only "write a better prompt." The bottleneck is whether the model has a reliable way to touch reality.

A good loop gives the model contact with the system. It turns guessing into experimentation.

/goal is a small interface for a bigger shift

I do not want to overstate one command. A slash command is not magic.

But interfaces matter because they teach a habit.

The habit /goal encourages is: stop decomposing every task manually, and start describing the objective plus the evidence that will prove it.

That is a different muscle.

When I use Codex this way, I find myself writing instructions like:

• Here is the outcome I want.
• Here are the files, APIs, or tools that matter.
• Here are the tests or checks that should pass.
• Here are the boundaries: do not publish, do not delete, ask before spending money, stop if the evidence contradicts the assumption.
• Here is what the final answer should contain.

It's similar to what you have to do with a growing business. It's not feasible to do everything yourself but you try to hire smart people, put them in a situation where they have access to the resources they need and have some sort of way for them to get feedback to make sure the actions they take are aligned with your goals.

But operational clarity is the point. The agent can do much more if the environment gives it something to push against.

A vague prompt produces vibes. A goal with a harness produces work.

This changes what skill looks like

I still care about reading code. I still care about taste. I still care about understanding the domain deeply enough to know when the model is fooling itself.

If anything, those things matter more.

The shift is that a growing share of the leverage is in designing the work system around the model. The valuable skill is not just knowing what to ask. It is knowing what feedback loop to build.

The pattern is the same: objective, tools, feedback, iteration, stop condition.

This is also why the loop-engineering discourse gets people annoyed. Some people hear "loops" and imagine infinite token burn, agents approving their own bad work, and humans laundering responsibility through automation.

They are not wrong to worry.

Loops without verification are dangerous. Loops without budgets are expensive. Loops without ownership are a mess. Loops that can mutate production without gates are asking for trouble.

But those are reasons to design the loop better, not reasons to pretend the abstraction is not arriving.

The future feels more like lab management

The more I use these tools, the less I think of myself as writing prompts and the more I think of myself as setting up little labs.

Sometimes the lab is a repo with tests.

Sometimes it is a browser and a screenshot harness.

Sometimes it is an old baseball game talking through a DAC while an AI model tries to infer what a byte means.

That last one is strange, but it made the broader point clearer than a normal app would have.

The model was not just completing text. It was interacting with a system, noticing patterns, using domain knowledge, writing tools, and checking itself. It was still wrong sometimes. It still needed constraints. But it could keep a research loop moving in a way that felt meaningfully different from prompting one step at a time.

That is the part I want to explore more.

Not because I think agents are done. They are obviously not.

Because the shape of the work is changing. The interesting frontier is not only smarter models. It is better loops around smarter models: better harnesses, better evals, better memory, better human gates, better ways to let the model discover things without letting it drift into nonsense. Even smarter objectives so that the model can minimize costs. I've seen some interesting work lately on how to cut Fable 5 costs by helping it triage tasks and offload those that are more straightforward to smaller models while saving Fable tokens for high level architecture and things like that.

The old workflow was: ask, answer, ask again.

The new workflow is closer to: define the goal, wire up the instruments, and manage the loop.

I am still learning how to do that well. But after watching Codex use baseball knowledge, emulator traces, ASR, and tests to reason about a 1980s toy, I am much less inclined to laugh at the phrase "my job is to write loops."

I think that might be the job now.