Goal is the GOAT
The end of legacy software?
A year ago, I wrote a post called “Fear of Coding Out” about the mind-blowing increase in my professional productivity. The short version: AI coding tools had changed the slope of my personal output curve. In 2013, my most productive year at the keyboard, I averaged 952 lines of code a day. In 2022, it was 602. By the winter of 2024/2025, with AI assistants, 4,068. In my first four days with coding agents in May 2025: 8,804.
At the time, 8,804 lines per day felt absurd.
I just reran my GitHub script for the first week of July. From July 1 through July 7, I averaged 214,364 lines of code changed per day.
That is more than 1.5 million lines in a single week. It is roughly 24x the number that felt absurd a year ago, and about 350x my 2022 self.
Here is the embarrassing part. I started drafting this post in mid-May, when my peak day hit 53,747 lines, and my weekly average hit 17,249. I did not publish fast enough. Today’s average day is four times May’s peak day. The post kept going obsolete while it sat in my drafts folder.
And I am not even the interesting data point:
At the Claude Fable 5 launch in June, Anthropic published a stat from Stripe: in a 50-million-line Ruby codebase, the model performed a codebase-wide migration in one day that “would otherwise have taken a whole team over two months by hand.”
Ryan Waliany’s startup ran 200+ autonomous coding agents over 30 days, landed 8,000+ commits and 3.6 million lines of code, and rebuilt fifteen SaaS applications from scratch along the way.
One person is doing hundreds of thousands of lines a day. A small startup is doing millions a month. A public company is moving a fifty-million-line codebase before lunch.
These numbers are ridiculous. Ridiculous in a good way. But ridiculous enough to demand two questions: what changed, and what breaks next?
What changed: the loop closed
It helps to see the last five years of AI coding tools as a staircase.
Tab completion (2021). The model finished your line. Magical, but you were still the author.
A function at a time (2022). ChatGPT could write a whole routine on request. You pasted it in, fixed it up, and asked for the next one.
Multi-file changes (2023–2024). Tools like Cursor could hold enough context to modify a real codebase — a feature, not a snippet.
Agents (2025). Codex, Claude Code, Cursor. The tools could finally run the code: reproduce a bug, attempt a fix, execute the tests, and open a pull request. But a human still drove. I prompted, reviewed, and prompted again. The AI worked inside my attention span.
Goal loops (2026). This year, Claude Code, OpenAI Codex, and now Grok have shipped a deceptively simple command: /goal.
You type a completion condition. “All tests in test/auth pass and lint is clean.” “Every call site compiles against the new API.” “The issue backlog labeled bug is empty.” The agent works. After each turn, a separate model checks whether the condition is true. If not, the agent keeps going — no human prompting between steps. The loop runs until “done” is actually done, or until the budget you set runs out.
That sounds like a small product feature. It is not. Every previous step on the staircase made the model a better tool within a human’s attention span. This step removed the human attention span as the unit of work.
There is already a name for the craft that replaces prompting: loop engineering. You stop telling the model what to do next and start designing the conditions under which it decides for itself: the goal, the context it can see, the checks it must satisfy, the tripwires that stop it. Prompt engineering was imperative. Loop engineering is declarative.
Andrej Karpathy put it this way in January:
“LLMs are exceptionally good at looping until they meet specific goals, and this is where most of the ‘feel the AGI’ magic is to be found. Don’t tell it what to do, give it success criteria and watch it go.”
And on why the loops win:
“They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day.”
Stamina, it turns out, was a bigger bottleneck than talent.
Stop counting lines
Which brings me to an uncomfortable admission about the chart above: it has stopped measuring anything about me.
Lines of code was always a goofy metric. Some of the best engineering days delete more than they add. But for decades, it at least correlated with something scarce — engineer-hours at a keyboard. That correlation is now gone. When one person’s average day is 214,364 changed lines, you are not measuring the person. You are measuring how many loops they left running.
So if you are still evaluating developers by output volume, stop. You do not ration what is abundant. Code — the production of it, the modification of it, the testing of it — is no longer a constraint on anything. I wrote about unlearning scarcity in “Abundance Mindset”; this is that post’s punchline arriving ahead of schedule.
The constraint has moved: to judgment, to taste, to knowing which goals are worth pursuing. This change has consequences well beyond engineering org charts.
Three ripples
/goal looks like a niche command for geeky software developers. Here is why it will not stay niche. Three ripples, in increasing order of importance.
1. Legacy software is no longer a constraint. Or a moat.
Twenty years of accumulated code used to be both a millstone and a fortress. A millstone because every change meant archaeology. A fortress because any competitor would need twenty years to re-dig your moat.
Goal loops drain both at once. I can point agents at a crufty old codebase and say “/goal every deprecated API call is gone, and the test suite passes” — and the archaeology does itself. That is the good news. The bad news: a competitor can point the same agents at your category and rebuild your twenty-year feature set in a quarter. Stripe’s 50-million-line migration and Waliany’s fifteen rebuilt SaaS apps are the same fact viewed from opposite sides of the moat.
I can fix my old code fast now. I can also duplicate your old code fast and become your competitor. Which one do you want to be true? Because both are.
This upsets the entire software ecosystem, but especially the corners priced on code scarcity: B2B SaaS with its switching costs and integration timelines, and specialty software for military, government, healthcare, and other regulated niches, where a small vendor’s ancient codebase has quietly been the whole barrier to entry. As I argued in “The Meat Moat,” what remains defensible was never really the code — it is trust, compliance, distribution, and accountability. Everyone whose moat was actually the code is about to find out.
2. “/goal get me 100 customers”
Nothing about the loop is code-specific. The recipe is: a measurable outcome, tools the agent can use, and a checker that can tell whether the outcome holds. Software merely went first, because its feedback loops are fast, cheap, and testable — compilers and test suites are the world’s most cooperative referees.
But “100 paying customers” is measurable too. So is “every support ticket older than a day has a response,” “the books are reconciled,” and “every trial user who went quiet got a personal follow-up.” Give the loop a CRM, an ad account, and an inbox instead of a compiler, and the same staircase — completion, function, multi-step, agent, goal — gets climbed by sales, support, finance, and operations.
The referees are messier outside software, and the failure modes are more public. It will be bumpier. It is also obviously coming; the pattern is too simple and the payoff too large.
Now, before anyone runs off to literally try “get me 100 customers”, I should caution that it may NOT be a good idea depending on your product and the nature of the outreach. Generating a variety of digital ads and testing them could be a good goal. Spamming thousands of people with AI-slop marketing emails is probably not! As the world gets inundated with more and more AI-produced marketing messages, I do think that effective sales and marketing will increasingly rely on authentic human connection. But that’s a topic for a different post!
3. The human is leaving the loop
This is the big one.
Every earlier era of AI — including the “agentic” one we just left — had a human driving. The AI might have been doing the work, but a person initiated each step, reviewed each result, and supplied the momentum. Human attention was the engine, and human attention is the scarcest thing there is.
Goal loops break that coupling. Work now continues while no one is watching. I can set a goal, disappear into a board meeting, and come back to finished, tested work; the loop did not care that I was gone. I have three running right now as I write this!
Follow the implications:
AI usage decouples from human attention. Demand is no longer bounded by seats or hours. It is bounded by outstanding goals and computing budgets. That is a much, much larger number.
Jobs shift from doing the work to specifying and auditing it. Writing a good completion condition — precise, measurable, with the right tripwires — is becoming the highest-leverage skill in the building. So is the willingness to check what the loop actually did.
Accountability gets interesting. When work happens with nobody watching, “Who approved this?” needs a real answer. The companies that figure out audit trails, gates, and rollbacks for autonomous work will be able to use far more of it than the companies that don’t.
We spent seventy years building computers that wait for instructions. We just stopped waiting with them.
Deep dive: how to actually modernize legacy code
Ripple One on legacy software deserves a how-to. The honest summary of the playbook: it is less magic and more checklist. That is a good thing: checklists scale!
Step 0 — Set the target before you start. Decide what you are porting to before any agent touches anything: the target architecture, and the constraints you care about — multi-tenant from day one, your identity and authorization approach, your data rules and constraints, your cloud platform, etc. Then write them down where the agents actually look: the AGENTS.md and skills files that steer every loop you are about to run. The agents /goal run will happily produce an architecture. Step 0 is how you make sure it is your architecture.
Step 1 — Archaeology. For any non trivial software system, nobody really knows what a twenty-year-old product actually does. Not the docs, not the comments, not the last engineer standing. So do not ask one source — triangulate from four:
Point a computer-use agent at the running product and have it click every button, open every screen, and write down everything it finds.
Have a second agent read the documentation — what the product was supposed to do.
Have a third read the code — what the product actually does.
Have a fourth probe the API — what the product promises other software it does.
Merge the four into one feature list. Here is the part that matters: each entry is not a bullet point, it is a mini spec — what the feature does, the steps to reproduce it, what “working” looks like. Detail is good. Detail is what the loops will run on.
Step 2 — Human review of the list. This is the step people want to skip, and it is the most important one. The AI will build exactly what the list says, so make sure the list says what you want. If you can at all afford it, run this step mechanical-turk style: every feature spec gets two independent human reviews, and a third if either reviewer made edits. It is tedious. It is also the highest-leverage tedium in the whole project — you are editing what a fleet of agents is about to spend millions or billions of tokens building.
Step 3 — Carve out the bad behavior. My strong recommendation: match the existing functionality first, then fix and improve later from a good base. Porting and redesigning at the same time gives the loop a moving target. But some features genuinely should not survive the trip no matter what — say, an authentication shortcut that is now a security gap, or a third party library that is no longer available. Carve those out of the list explicitly, and either write them a fresh spec with its own tests, or consciously park them for later. The reason is mechanical, not aesthetic: a goal loop needs an anchor to verify against. A straight port has the perfect anchor — the old system itself. A carve-out has no reference implementation, so it gets built the normal AI way — spec first, tests as the anchor, no reference. In practice, expect a lopsided split: the overwhelming majority of features port straight across, and a small, stubborn minority needs the carve-out treatment.
Step 4 — Stand up the reference, then let the loops run. Keep the legacy system running side by side as the reference environment; it is about to be demoted from product to answer key. Then set the goal: “Implement every feature on the list — testing, debugging, and fixing as you go — until every page matches the reference environment.” Fan the work out, roughly an agent per feature, and let the loops grind. They build, they test against the reference, they fix, they keep going. You review at the gates.
That is the whole playbook, and it doubles as the punchline of ripple one: your legacy system stops being the thing you have to maintain and becomes the spec for the thing that replaces it. The millstone becomes the answer key.
The catch—shifting bottlenecks
The obligatory cold shower: more code is still not better code. A huge diff can mean progress or churn. Karpathy, in the same post quoted above, says he still watches the agents “like a hawk,” and the industry is bracing for a flood of new software. My own loops only count because they end at gates — tests, CI, review. (In May’s sample, roughly one in six of my changed lines was test code; the loops write their own referees.) The number is not the point. The outcome is—software is meant to serve its customers! It’s either doing that or not!
That creates the next bottleneck—the rest of the organization. If you can build software features crazy fast, how do your sales and marketing teams keep up? What about your customers? I personally eagerly download every update of Claude and Codex. But if I were running the software that handled bank transactions, I would be a bit more cautious! Not every customer wants weekly or even daily software updates.
It’s not just a simple “how fast can you sell?”. Increasing the speed of one function can expose bottlenecks elsewhere. In one company I spoke with recently, they started writing code with AI. But they kept their hierarchical decision making process: every change had to go through a series of approval meetings. Even if a feature could be implmented in an hour, it would still take weeks to get it shipped by the time the half a dozen or more vice presidents could get through the review meetings!
Conversely, another organization I’m familiar with is shipping features incredibly quickly. But all that’s happening is their product is becoming more and more unusable: an increasingly unweildy mess of disjointed features. Just because you can ship fast, doesn’t mean you should! Steve Jobs famously focused on removing not just features, but whole product lines! That same discipline and user focus is relevant here.
Thus, if the bottleneck in your organization is a Steve Jobs like “tastemaker”—keep that person! The tastemaker role can be crucial!
There is no universal solution here except for a very simple observation. If you look at literally any company, and software companies in particular, you will find an organization and set of processes optimized around a set of historical constraints. In the past, writing code was expensive. As a result, you would have a whole other team of people (the product team) ruthlessless prioritize any and every feature request. Sales teams got used to a yearly (or longer!) release cadence. Finance teams would allocate resources to projects through yearly budgeting cycles.
With looping, all of the costs and constraints that used to exist are changing. And thus, the organization and processes need to change as well. Exactly how really depends on the specifics of the company, products, and customers (as above, please don’t update the nuclear power plant software every day!).
But change is coming, and it’s not going to be limited to just engineers. The humble and geeky /goal command has set the stage for a broader transformation of corporate life.
Buckle up!