The /goal Function Made Loop Engineering Click for Me

rss_feed

LinkedIn<br>GitHub

rss_feed

menu

LinkedIn<br>GitHub

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...