agents

Drag a label, get a pull request

A CTO showed me an agent system he spent three months refining. I wondered how much of it one developer could rebuild in a day, on the subscription he already pays for. Quite a lot, it turns out. What worked, what broke, and why my job changed more than my codebase.

Last week I was at an Agentic Frontrunners meetup hosted by New Orange. Their CTO demoed something that stuck with me: a system he had spent three months fine-tuning, built on OpenAI's open-source Symphony spec. Issues go into their tracker, agents pick them up, working code comes out.

Impressive. And my first honest reaction was probably the same as yours: three months of engineering by a team that does this for a living. Nice for them.

But driving home, a question kept nagging. Symphony is a public spec. How much of that value is really locked behind three months of work? And how much could a solo developer get running in a day, without OpenAI, on the Claude subscription he already pays for?

The next evening I had an answer.

How much of this is really locked behind three months of engineering?

The problem this actually solves

"AI writes code" is not it. I can already generate code faster than I can review it. That is not the bottleneck.

The bottleneck is that every piece of AI work needs a babysitter. You open a chat, explain, answer questions, press enter, steer. Each task got faster, but you are still the runtime.

The idea behind Symphony, and the reason it clicked: move the steering wheel from the chat to the issue tracker. Work gets defined once, properly, as an issue. An agent picks it up, does the job in isolation, and comes back with a pull request and a written report. You stop supervising sessions and start managing work. That is a different job. A much more scalable one.

What I built in a day

Every part is off the shelf:

My backlog lives in Linear, as ordinary epics and user stories.
I drag one label onto an issue: agent-go.
A scheduled job claims the issue and hands it to a headless coding agent, which builds the feature and runs the tests.
A pull request appears with a report: what was done, which acceptance criteria are covered, and (my favourite part) a section called ASSUMPTIONS.
The report lands back on the Linear issue, CI independently runs the tests again, and I review and merge.

No servers. No API metering: the agent runs on my existing Claude Max subscription, which is officially supported. The orchestrator that took three months in the demo is, in my budget version, a 60-line workflow and a handful of labels. Even their per-task model routing exists here in miniature, as a label on the heavy architectural issues.

Total setup time: one day, detours included.

What broke (because something always breaks)

I promised the honest version.

GitHub's organisation permissions ate an hour. The first pull request got stuck behind an approval banner because GitHub, sensibly, does not trust bot-created PRs without human sign-off. All solvable, all part of the detours.

The failure that mattered came later. The very first real run returned a report that said, in its entirety: "No report." The pipeline had worked flawlessly. Issue claimed, runner started, comment posted. And the agent at the centre of it had produced precisely nothing, while every status light stayed green.

Every status light stayed green. The agent had produced nothing.

The cause was mundane: the agent process failed early and its error vanished into a log nobody captured. The real fix was not fixing the run. It was redesigning the pipeline to fail loudly, so that silence can never look like success again. That one lesson has been worth more than the rest of the setup.

Then the second run. Thirteen minutes after I re-applied the label, there was a pull request with a complete application skeleton and 33 passing tests, including a smoke test for every acceptance criterion. One criterion could not be verified in the pipeline, and instead of silently skipping it, the report said so and offered the closest proof it could produce. I have worked with humans who do less.

Not perfect, though. My review caught that it had built on last year's major framework version: the model trusted its memory instead of checking, and an AI loses every memory contest against the present. I wrote the correction on the issue, re-applied the label, and 33 minutes later the fixed version came back and merged. The lesson became a permanent project rule, which makes this mistake extinct in this repo.

One review, one process improvement. That is the loop working.

What actually changed

If you run a team or an agency, this is the part that matters, and it has nothing to do with which model is best.

The moment agents do the building, two other skills become the job. Writing issues: user stories now need acceptance criteria precise enough for a builder that cannot ask questions. That is not AI overhead. That is the discipline we always claimed to have. And reviewing: my role shifted from writing code to judging it. Feedback, in this setup, is literally a comment and a label.

The three-month system from the meetup is better than mine: more robust, smarter routing, tuned to their organisation. Mine is one day old and deliberately minimal. That is exactly the point. The entry ticket is far cheaper than the impressive demos suggest. What is scarce is not the tooling. It is clear specifications and honest review. Which was always the scarce part.

The entry ticket is far cheaper than the impressive demos suggest.

What's next

Here is what I have not told you yet.

That cloud pipeline, elegant as it sounds, had a dirty secret: even a small task took around fifteen minutes, and most of that was machines booting and queues waiting. My autonomous workforce was slower than just doing the work myself.

So I did something that sounds like a step backwards. I took the agents out of the cloud and moved them into my own house, onto the Mac Studio that was already on my desk. Runs now start within thirty seconds of dragging the label. And there is a small robot in my menu bar now: it shows me which issue is being worked on, how long the agent has been at it, and when it will next check for work. I catch myself just watching it.

Whether this setup survives a full MVP backlog, what the first ten pull requests reveal, and the one skill that matters more than all the tooling combined: that is the rest of this series.

Part 2: how to write user stories an agent can actually build. That turned out to be the whole game.

Thanks to the New Orange team for the demo that kicked this off; their Agentic Frontrunners meetup is worth your time if you are in the Netherlands. And if you are wondering what this way of working could look like for your team: my inbox is open.