Goal-driven engineering: the software factory nobody has to ask.

Most teams that adopt AI coding agents land in the same place. The agent is good, the harness around it is decent, and work moves faster once somebody has decided what the work is. That last part did not change, and it is where the queue sits now.

A software factory does not change it either. You hand it a spec, it plans, writes, tests, and hands back a pull request. Real throughput, and still a fulfilment system: it starts when a person asks. Everything nobody has asked about keeps slipping one merge at a time. A dependency goes four majors behind. The checkout page's largest contentful paint creeps from 2.1 seconds to 3.4 and stays there, because the person who would have caught it was shipping something else.

Goal-driven engineering closes that gap. You describe the finish line once, and a system keeps the codebase on the right side of it.

Executive summary

Every component, and the loop that makes it a loop.

Four things to build, in this order. Each one is a section below.

1. 01

   Write one goal properly

   Ten fields, including the command that measures it and the person who owns it. If you cannot write the command, what you have is a wish.

2. 02

   Run the loop with no agent in it

   A trigger, the signal, and a file it appends to. You are checking whether the signal is stable and the threshold is right before anything can act on either.

3. 03

   Add the goal manager

   An observer, a memory of what was already tried, a planner that is allowed to choose nothing, and a guard that enforces authority and budget. This is the only part you have to build.

4. 04

   Grant autonomy one rung at a time

   Report, then issues, then drafts, then pull requests, then merges. Per goal, against evidence, never all at once.

The definition

Goal-driven engineering makes the unit of work a standing goal: a plain-language statement of something that has to be true about a system, with a signal that measures it and a target that decides it. A monitoring agent runs the signal on a trigger, compares the reading against the target, and acts on the difference.

That is a control loop, and the control-theory words fit without stretching. The goal is the setpoint, the signal is the sensor, the monitoring agent is the controller, the software factory is the actuator. The codebase is what gets controlled, and every merge is a disturbance.

Two kinds of goal

"Goal" is doing two jobs here, and a system that runs both through the same loop gets one of them wrong.

An invariant goal has to keep holding. Coverage above a floor. No critical advisory open longer than 72 hours. It never completes: it is met today, and tomorrow a change nobody connected to it can breach it. That is the reason something has to keep watching.

A terminal goal has a finish line. Move all eleven services off the deprecated auth client. Implement this spec. Progress is the measure, and when it lands you retire the goal.

Terminal goals need a stopping rule and an attempt limit, or an agent that cannot reach the line keeps trying. Invariant goals need the opposite. They have to survive being met, and they have to stay cheap, because they will run thousands of times and act almost never.

What a goal is made of

Everything downstream reads this record. Every agent, every gate, every issue it files can only be as good as what is written here.

One goal, written out. Plain files in the repository, reviewed in a pull request like anything else that can change your code.

id: perf-entry-routes
intent: >
  The three routes that carry our signups have to stay fast on a mid-range
  phone. Historically they regress through images and third-party tags, not
  through our own JavaScript, so look there first.
scope:
  repos: [web]
  paths: ["app/(marketing)/**", "next.config.ts"]
signal: npm run lighthouse:ci -- --routes / /pricing /checkout --metric performance
target: ">= 90 on every route"
guard: npm run bundle:report          # a route made lazy to win the score gets caught here
triggers:
  - on: merge
    branch: main
  - on: schedule
    cron: "0 3 * * *"
authority: draft-pr                   # L2 on the ladder
budget:
  pull_requests_per_week: 2
  turns_per_attempt: 25
escalation:
  after_failed_attempts: 2
  notify: "@alfonso"
owner: "@alfonso"
review: 2027-03-01

Goals and wishes

Most first attempts are wishes. They are sentences everybody agrees with, which is a much weaker property than it sounds.

One question settles it: can you write the command that measures this? If you cannot, you have a wish, and handing a wish to an autonomous system buys you confident pull requests against a standard nobody stated.

Look at the fourth one. Coverage on its own is an instruction to raise coverage, and the cheapest way to raise coverage is to delete the failing test. Any goal expressed as one number is a number the system will move, by the cheapest route it can find.

How you would build one

Nothing here needs a model that does not exist yet. Four bands, one of them new work.

Triggers are events you already emit. The execution plane is a software factory you either run already or can buy. The record layer is your issue tracker plus a page that reads the ledger. The control plane is the missing piece, and it is small: a registry of goal files, something that runs a command on a trigger, a store of what happened before, and a planner that picks the next action or picks none.

Watch the planner, because it is where people over-build. Its job is to pick the cheapest action that could close the gap, with doing nothing on the list, or it will generate work for its own sake.

Memory is what separates it from a linter

Take the memory out and you have a scheduled check that files a ticket, which is about a decade old.

Memory holds, per goal: what the signal read over time, what was proposed, what landed, what was rejected and why, and what is now out of bounds. That is what stops the second attempt at a problem from being a rerun of the first. The agent can open an issue saying coverage on services/billing has fallen for the fourth sprint running, that it proposed generated tests in March and you rejected them as meaningless, and that this drop sits in the two files that handle refunds. A linter repeats one sentence forever, at the same volume, until people learn to scroll past it.

Record the decision, not the discussion. Memory that stores threads rots within a quarter.

The autonomy ladder

The first thing people ask is whether an agent should be allowed to open pull requests on its own. Autonomy belongs to each goal rather than to the system, and it is granted one rung at a time against evidence.

A dependency bump can reach level 4 in a month. A schema migration may never leave level 1. Leaving a goal one rung too low costs somebody a button click. Putting it one rung too high costs you a merge at two in the morning, into a gate that was weaker than it looked.

The rungs are mine, and the bar on each one is a starting point rather than a measurement. I would expect a team that ran this for a year to move them, and to end up with different bars for different kinds of goal.

One goal, end to end

The performance goal above, over two weeks: p75 LCP on /checkout at or under 2.5 seconds.

Day 6 is the part to look at. With nothing watching, day 6 is invisible. The pull request that caused it was reviewed, approved and merged by people checking whether the feature worked, and the regression surfaces weeks later through a complaint or somebody opening Lighthouse for another reason, by which point it is tangled up with thirty other merges.

With the goal registered, the observer runs on the merge event, reads 3.42 against a target of 2.5, checks the memory, and opens this.

A threshold alert cannot write that issue. It names the commit, because it measured either side of one. It remembers March. And its proposal is the glob change, which fixes the next hero image as well as this one.

Multiply that across a handful of goals and repositories, and you get the layer a person looks at.

What quietly breaks it

None of these are bugs.

The first one kills most pilots. Human review is already the constraint in most teams, and a system built to generate more work to review finds that constraint in week one. Budget the queue before you budget anything else.

You cannot start here

This sits on top of a harness. The signal has to be a command that runs the same way on your laptop and in CI. The gates have to be trustworthy enough that a passing pull request means something, because from level 2 up they are what stands between an autonomous agent and your main branch. And you need a fast way to undo a change, because the system will eventually be wrong in a way nobody predicted.

Without those, goal-driven engineering will faithfully automate a process you do not trust. The harness guide covers what to put in the repository and what to wire around it, the baby steps put that work in order, and the Readiness Analyzer scores where you stand in about ninety seconds.

The smallest version worth running

Start with one goal, not with the control plane.

1. 01

   Pick the boring regression

   The thing that has slipped twice already and that you can measure with a command you already have: coverage, bundle size, a Lighthouse score, dependency lag. Pick the most measurable goal you have rather than the most important one.

2. 02

   Write the record, all ten fields

   Owner and review date included. If you cannot fill the signal field with a real command, stop and go write that command. It is worth having whether or not any of this follows.

3. 03

   Run it at level 0 for two weeks

   A cron job, the command, and a file it appends to. No agent yet. You are finding out whether the signal is stable and whether the threshold is right, and you will almost certainly move the threshold.

4. 04

   Move to level 1 and read every issue

   Now let it file issues, with the evidence and the commit it blames. Track one number: of the issues it opened, how many you are glad to have. My own cutoff would be about two thirds, though that figure is a guess and I would revise it after a month of real issues.

5. 05

   Add the memory before you add the second goal

   The first time it proposes something you already rejected, you have found the thing that decides whether any of this scales. Fix it while you still have one goal.

6. 06

   Then a second goal, and only then a factory

   Two goals running honestly at level 1 beats six at level 3 that everybody has stopped reading.

Where this goes

The dark factory is the usual end state for all of this: a spec in one end, a tested change out the other, almost nobody in the middle. It is a real destination, and parts of it already work on tasks whose intent is easy to write down and whose correctness a machine can judge.

Somebody still has to decide what should be true. Goal-driven engineering is the claim that the decision is the durable artifact, more durable than any ticket, and that once it is written down properly the same machinery that builds everything else can enforce it.

That moves your job one more step. You stopped writing all the code and started running the line that writes it. Now you write the goals the line is held to, decide how much rope each one gets, and read the few things that need you.

The book goes deeper into the machinery: the goal pattern and the dark factory in the orchestration chapter, and the gates that make any of it safe to run in the verification chapter. It is out now in Early Release.