You still have to cook: what agents changed about how we build

This summer, I pointed an agent at a track of work one evening, left my laptop in the office, and went home. The next morning, 32 merge requests were waiting for me. Some tiny, some big, pipelines green, the agent's own review comments already handled.

Sounds great, right? And in some ways it was. We planned four weeks for that project and shipped it in about two. Those two weeks were also the most draining I've had as an engineer, and part of the design wasn't what I wanted. This post is about how we got there with Specto, the plugin we built to go from a spec to reviewed merge requests, and about what still needs a human in the kitchen. Let me start with that night.

TL;DR

Agents now write most of our code, so we built Specto: a Claude Code plugin with 21 skills that takes a rough idea all the way to reviewed merge requests. Here is what changed, what still breaks, and what we would do differently.

• The bottleneck moved. Coding went from the slowest step to the fastest. Specs and review are where the time goes now.
• AI-written specs are our weak spot. They are too long and dense, and a vague line gets built before anyone notices.
• Review is the new bottleneck. A night of agent work can mean dozens of merge requests by morning. That is a lot of reading, and it changes how you learn a codebase.
• Use it in pieces. Every skill works on its own, so you pick where the agent helps and where you do it yourself.

One prompt, one night

Those 32 merge requests came from our export builder: the part of our product where customers schedule their data exports, choose where they land and when they run. We wanted it more self-serve, more reliable and easier to observe, and we had planned four weeks for it.

It didn't start with Specto. I brainstormed with an agent first, interview style, so it would pull out of me what I already knew and what I still had to decide. Then I let it draft the spec. That draft was too long, too technical and not clear enough to work from, so I rewrote most of it myself. The tickets came from a skill I had written before Specto existed, which meant they had no explicit acceptance criteria and no link back to a spec section.

The night itself was one prompt. I pointed the agent at the track, where the tickets were grouped per milestone with their dependencies linked, and asked it to work through them one by one with implement-ticket: implement, review its own merge request until it stopped finding things, and watch the pipeline until it was green. I also added two rules that weren't in Specto yet: keep comments to the non-obvious why, and don't over-engineer.

By morning it had worked through the whole track. That was the good part. The rest of those two weeks went into reading it.

The bottleneck flipped

When I started at TechWolf, AI meant Copilot finishing a line of code and ChatGPT in another tab. Then came Cursor. You were still deep in the code, going file by file with the AI because it couldn't hold much context. You were still the one coding, with a short feedback loop.

Specs were written by hand, in a separate tool, and that took a long time. But a spec could stay a bit open. Implementation was the slow part, so if you hit a wrong design halfway, there was time to fix it, discuss it, and sometimes even update the spec.

Agents changed that. A big ticket now takes about an hour, so you implement ten of them in a row and they depend on each other. An agent only asks when it notices something is unclear. When it thinks it understood, it builds its own interpretation, and it builds it everywhere at once. You don't find the wrong design halfway anymore. You find it at review, already implemented across a stack of merge requests you now have to redo.

What Specto is

Specto, short for spec to implementation, is a Claude Code plugin our engineers built for our engineers, on top of the open-source superpowers plugin. It covers the flow from a rough idea to reviewed merge requests: brainstorm, product and engineering spec, tickets, implementation, review. You decide where you step in. Sometimes you write the spec yourself and let it plan and implement. Sometimes you let it draft and you rewrite.

What it mainly brings us is a shared way of working. A spec, a ticket and a merge request look the same no matter who ran the skill, and nothing goes through without something or someone checking it. Each main authoring skill has a separate reviewer, so nothing grades its own homework: new-spec has review-spec, implement-ticket has review-mr and a test critic, and the branch gets a definition-of-done check before it reaches a human.

The repo is the source of truth. Specs live in a docs folder in the repo, next to the code, so the agent has the context without anyone pasting it in. Every ticket links back to the spec section it came from, and the plan in between is temporary and gitignored.

The skills don't let an agent run loose. They call vetted scripts for GitLab and Jira, so the agent can only do what we decided it may do. Anything we pull in from Slack or Notion gets scanned for personal data first. And before any AI reviews a spec, a plain linter checks it for the usual tells of AI-written text, like em-dashes.

You don't need the whole flow. Every skill runs on its own. You can brainstorm with your team at a whiteboard, write the spec yourself, and use implement-ticket for a single ticket. That is how most of us actually use it: implement-ticket, review-mr and create-jira-ticket are used a lot, the spec skills a lot less. We track which skills people use, and that tells us what to fix next.

What still breaks

The specs. An agent follows the recipe exactly, even when the recipe is wrong. And the recipes new-spec writes are long, technical and hard to read: a lot of one-liners, a lot of difficult words, few real sentences. You could write the same thing in a third of the length. Recently I reviewed three specs a colleague had written by hand, and they were super clear. After reading them I knew the design, which endpoints we needed and what would change in the system. That is what a spec is for.

A dense spec isn't just annoying, it's risky. An export runs in two steps: we generate the file, then we upload it. I wrote that failed exports should be retried, and to me that meant the whole thing. The agent read the same sentence and retried only the upload. It didn't ask, because to the agent nothing was unclear.

The gap wasn't inside one ticket, it sat between milestones. Each milestone made sense on its own, but the agent never looked at what the others were doing. And part of this was on me: the spec still had AI slop in it, I didn't really review the tickets, and the spec wasn't merged yet, so the tickets pointed at a merge request the agent couldn't find in the repo.

What works better for us now: write the first draft yourself, then run review-spec on it and let the agent challenge it. The agent is a better reviewer than author.

Review. That many merge requests is a lot to read, and agent code is often more complex than it needs to be, with a lot of comments. You read and read without really understanding. As a junior, reviewing line by line was how I learned our codebase. At this volume that isn't possible anymore. You focus on the design and whether it matches the spec, you trust the author was critical of their agent, and you skip things you would rather read, like the tests. That is faster, but it also means less shared understanding of the system, and keeping that understanding gets harder every month.

Today I start review-mr, which checks spec adherence, acceptance criteria, best practices and security, and while it runs I read the merge request myself for the design and the flow. It helps. We're not done figuring this out.

What works

The speed is real, and the mechanical work (pipelines, review comments, ticket plumbing) is mostly gone.

What I like most is that the recipes are ours. When a skill annoys you, you log it with plugin-feedback, or you change the skill yourself and open a merge request on the plugin repo. The next person cooks with the better version without ever knowing there was a problem. The skills are reviewed like code, and they get a bit better every week.

The skills are also ours to shape. There is even reconcile-spec, which compares a shipped spec with the merged code and flags where they drifted apart, so a spec doesn't quietly go stale like ours used to.

If you are building something similar

• Merge the spec before you create tickets. The agent looks in the repo, not in your open merge requests.
• Review the tickets, not only the spec. That is where the interpretation happens.
• Put your preferences in the skills, not in your prompt, so everyone gets them.
• Plan for review. If one person produces 32 merge requests in a night, someone has to read them.

You still have to cook

Agents are not a microwave meal. The effort didn't disappear that night, it moved: from writing the code to being clear, and to making the work reviewable for someone else. So keep talking to your colleagues, and don't let the agent decide for you. It will follow whatever recipe you give it, exactly.