Andrej Karpathy coined "vibe coding" in early 2025 for the habit of accepting whatever the model writes without reading it. A year later he wrote that the professional version deserved a different word, and offered agentic engineering:

"agentic" because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. "engineering" to emphasize that there is an art & science and expertise to it.

I'm not sure the name will stick. The distinction will. Vibe coding is when you don't care about the code. This is when I care exactly as much as I always did and have stopped being the one typing it. Getting there meant dropping seven habits, most of which I was quite attached to.

1. Starting with code

The most expensive thing I ever handed an agent was a sentence like "add auth to this endpoint". I knew what I meant. The agent didn't, so it decided for me, one small decision after another, and I spent the afternoon in the review undoing the ones I disagreed with, one comment at a time. I did this more than once before it sank in that the afternoon was my fault.

So now the first thing I do is get interrogated. An agent asks me one question at a time, never a batch, until nothing about the idea is still an assumption I haven't said out loud. Which roles can hit this endpoint. What happens on token expiry. How a test proves an unauthorized call was refused. It does this because a skill tells it to. I use Claude Code, where a skill is a markdown file of instructions the agent loads when I type its name, so the same procedure runs the same way every time, including on the days I'd rather skip it. Only after the questions does anything get written down, and what gets written is a record of decisions, not a wish list. Matt Pocock, whose skills mine are forked from, is blunter about it than I'd be on the page for to-spec, his skill that turns the interrogation into a written spec:

Anything the spec asserts that you never actually said is a defect.

My job was always deciding. I'd just been doing it in the wrong order, with the code as the medium, which is the slowest and most expensive medium there is for finding out you were wrong.

2. Keeping the conventions in my head

A new hire onboards once. An agent onboards every session, from zero, and it does not remember yesterday. Every "we don't do it that way here" that lived in my head got violated at the start of each run, and every time I was surprised, which in hindsight is the surprising part.

So the conventions go in a CLAUDE.md, a text file at the root of the repo that the agent reads at the start of every session. I'll call it the steering file. Boris Cherny, who built Claude Code, describes his setup as "surprisingly vanilla", and the part that does the work is one file:

Our team shares a single CLAUDE.md for the Claude Code repo. We check it into git, and the whole team contributes multiple times a week. Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time.

Mine is longer than I'd like and I edit it most weeks. The same pressure lands on the code itself. An agent wants clear module boundaries, strong types, fast builds, and errors that say what actually went wrong. I've known this was good for humans for as long as I've done this job. It took a machine to make me do it.

3. Being the test runner

When the agent couldn't run the tests, it handed me code that didn't work, and I ran the tests. Prompt, wait, paste the error back, wait again. It felt like pairing. It wasn't. It was me being a slow, expensive shell script.

So the agent gets everything I use to check my own work: the linter, the unit tests, a headless browser it can drive from the command line. All of it has to be fast, because a slow loop for me is a slow loop for the agent, multiplied by every attempt it makes, and it makes a lot. An agent that can see its own failure loops on it until the tests pass. One that can't will tell you, with total confidence, that it's done.

4. Watching it work

One agent, one task, me staring at the terminal, is the same throughput as me typing, minus the typing. I did this for a while and called it a productivity gain. The gain showed up when the tasks got longer and the agents more numerous. "Implement this, write the tests, run them, don't come back until they pass" is a thirty-minute task. I can have up to seven of those running, a cap I set in my own tooling and haven't felt the need to raise. I stayed at one for longer than I should have, partly because it felt like losing control and partly because I was afraid of what seven of them would do with my credentials. The second fear was the right one and gets its own section. The first went away when I read Gergely Orosz's observation that overseeing parallel agents comes naturally to senior engineers, because they've spent years being the reviewer for a team's parallel work. That stung a little. I'd been that reviewer for years and hadn't made the connection.

An epic, a feature big enough to need a dozen tickets, gets cut into those tickets by another skill, and the tickets have dependency edges between them. The set of tickets whose blockers have all closed is the frontier, and every ticket on the frontier gets its own agent in its own git worktree, a separate checkout so they can't step on each other's files. When one merges, the frontier moves and the next batch goes out. Per-ticket merges land on an integration branch for the epic, and the one pull request from that branch into main is the one I review by hand. The skill is called /implement-with-agent-team; the mechanics are a post of their own. Reading the frontier and dispatching the next batch was never the hard part. I'd been doing it by hand for a month before that occurred to me.

Some numbers, because I'd distrust this post without them. Last ten weeks, the two repos I spend most of my time in. Five hundred and forty pull requests merged, about four hundred and ninety of them opened under my name by an agent I dispatched. Most were single tickets; eight epics account for about a hundred, each ending in one hand-reviewed pull request into main. Two of the five hundred and forty needed a follow-up fix within a day of merging, and nothing was rolled back. Two is low, and I'd have guessed higher. The integration branch catches most of the damage before main, and the eight epic pull requests are where I found the rest. Roughly four in five tickets built on the cheaper model; the rest went to the expensive one on purpose, for tickets where the spec left a judgment call the cheaper one kept getting wrong. The busiest week landed seventy-two merges in one repo. I read seventy-two pull requests that week, against seventy-two specs I'd already argued with an agent about. I was tired. It was a good week.

5. Approving tool calls one at a time

Clicking "approve" on every tool call is supervision theatre. I wasn't reading those calls. I was adding latency and telling myself it was oversight, and I kept it up for longer than I'll admit here.

Now I decide once which files an agent may write, which commands it may run, what it may reach on the network, and which credentials it holds, and Claude Code's permission settings enforce that instead of me. Production credentials are never on the list unless I've said so out loud that day. I started narrow and widened as the limits proved themselves, and the only thing that still needs a human is the action that can't be undone.

The most useful fence I have is a small hook, a script that runs right before a tool call and can block it. Mine runs whenever /implement-with-agent-team starts a new agent, and refuses the start if the model that agent will run on hasn't been named. It exists because the model defaults to whatever the spawning agent is running, so an expensive model would otherwise end up on a ticket sized for a cheap one, with nothing in the run's output ever saying so. Nothing told me. I noticed by accident.

6. Fixing the mistake instead of the cause

When an agent took a wrong turn, I used to correct it and move on. The turn came back the next session, because nothing about the session had changed, and I'd correct it again, slightly more irritated. Mitchell Hashimoto, who created Terraform, calls the fix "harness engineering", the harness being everything the agent runs inside: "anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."

The run that taught me this was an epic of eleven tickets in July. Two of them each added a column to the same table, and the ticket graph had no edge between them, because I didn't notice they touched the same migration when the epic was cut. Both built cleanly in their own worktrees. Both merged onto the integration branch within a minute of each other, and the second one's migration fell over on the first one's schema. Nothing reached main. But I spent an hour finding out why, and the fix was not "be more careful next time", because I'd have been exactly as careless the next time. The fix was a check in the ticket-cutting skill that lists every file each ticket expects to touch, flags any two tickets that name the same migration or model, and refuses to finish until I've added a blocking edge or said out loud that the overlap is fine. It has fired four times since. Three of those I would have missed again.

The harness rots, too. When a new model ships, half the workarounds in it are for a weakness the model no longer has, and I'm bad at pruning them. This is the habit I put off longest, and it's the one that makes the other five cheaper the longer I keep it up.

7. Thinking this was about code

The same loop runs the design doc, the sprint summary, this post. Decide, hand off, verify, fix the harness. I resisted that for a while too, on the grounds that writing was different. It isn't, particularly.

The one I kept

None of this is permission to stop caring. If anything the bar goes up, because the volume goes up. Simon Willison's rule, from the piece where he drew the line around vibe coding, is the one I hold to: don't commit code you couldn't explain to someone else.

I still review every pull request. What changed is what I read for. Early on I read every line, to learn where the model was reliable and where it wasn't, and I'd tell anyone starting now to do the same for a while. That stopped being possible with several running at once. Now the agent that wrote the code reviews it itself before opening the pull request, checking what a checklist can check. My eyes go to what a checklist can't: whether the design will hold up at production traffic, what the change does to the systems upstream and downstream, whether the security boundary still holds. If it regresses in production, it's mine, whoever typed it.

My first weeks were slower and I nearly gave up twice. I spent them writing steering files and cutting modules until they explained themselves. Writing the code got cheap. Deciding what to write still takes the whole afternoon, and I don't think that's going to change.

That wasn't recklessness. By the time a ticket ever reached /implement, it had already been through three rounds of scrutiny. I'd been grilled about it one question at a time until nothing was still a guess. That got folded into a spec. The spec got cut into a slice sized to fit one context and worth merging on its own. What the agent received wasn't a request so much as a decision I'd already made and written down. /implement just had to go execute it, test-first, against a checklist it wrote for itself and re-checked before ever calling the work done. Once I saw that clearly, the question stopped being "can I trust this output" and became "why am I still doing this one ticket at a time."

An epic is rarely one ticket. It's a dozen, with real edges between them: three that can start today, four that can't start until the first three close, one at the bottom of the graph that everything else quietly depends on. Running that manually meant becoming, personally, the scheduler: watching what had merged, figuring out what it unblocked, typing /implement again. /implement-with-agent-team is what happens when you take that job away from the person holding it, because the person was never the part doing anything hard. The skill calls me the lead: I dispatch, verify, and merge. It calls each agent it spawns a teammate: the teammate only writes code.

The problem with a shared to-do list

Before this skill, "run a few tickets in parallel" meant writing a prompt myself every time: here are the tickets, here's roughly what depends on what, go. I did that for over a month before I ever formalized it. It worked, but it was bespoke labor for every batch, and it depended on me keeping the dependency graph straight, from memory alone.

The tempting fix is a shared to-do list: some file sitting alongside the repo that every teammate reads from and writes back to, tracking which tickets are done, in flight, or blocked. It's also the wrong fix. That file would sit next to two records that already exist and already have to agree with each other: the git branches, and the issue tracker itself. A third record of the same facts doesn't remove that disagreement, it adds a third way for it to happen, and every drift is its own small debugging session. That's exactly the kind of state-sync bug that's tedious to find and depressingly easy to reintroduce the next time you change the code.

GitHub is already the state machine

The real fix is structural, not a smarter sync algorithm. GitHub already is the state machine:

• The dependency graph already exists, as the tickets' native "blocked by" links.
• Progress already exists, as open versus closed.
• Completion already exists, because a merged pull request that references a ticket closes it.

So there's no second copy. A small script the skill carries with it, tickets.mjs, reads all of this fresh from the tracker on every call and writes exactly one thing back: a plain, readable comment on the ticket itself, the only claim mechanism it has. Something a person skimming the ticket later understands right away, not a code only the script can decode. A missed notification or a stale read stops being a bug, because the next call just re-derives the truth from the tracker instead of trusting something cached from a moment ago.

What you actually type

I invoke the skill myself; it never invokes itself mid-task. I tell it, in plain language, what to work on, an epic or a specific set of tickets, and it figures out the rest:

/implement-with-agent-team #1125
/implement-with-agent-team backend tickets of #1125
/implement-with-agent-team tickets 948 949 950

That second form matters more than it looks. When an epic spans two repositories, saying "backend tickets" is enough to scope one run to the backend half and leave the frontend half for a separate session, instead of one run trying to do both at once.

Reading the frontier

The skill's central idea is the frontier: every open ticket whose blockers have all closed. That's the set of work that can start right now, and tickets.mjs frontier recomputes it from the tracker on every call. Nothing about it is stored.

Each ticket carries exactly one status, and only three of them expect anything from me:

The loop

I run this until the frontier reports the epic closed. It's genuinely cyclical: every merge can unlock new tickets, which is why a run keeps going instead of stopping after one pass.

1. Read the frontier. The first action each time, including when resuming yesterday's run.
2. Claim every ready ticket, up to seven at once. Claiming a ticket records the model it'll build with, sonnet by default, and the branch it should build against, and is what stops the next read from giving the same ticket to two teammates.
3. Dispatch them all in one message, one fresh teammate per ticket, each in its own worktree, an isolated copy of the repo it can build in without affecting anyone else's. This is where the actual parallelism happens; spawning one at a time and waiting between each would make the whole run serial for no reason.
4. Take each return: verify the pull request actually does what it claims, record it, merge it, confirm the merge actually closed the ticket rather than trusting the report that it would.
5. Back to the top.

A teammate's brief is deliberately short. It names the ticket as owner/repo#number, so the teammate reads the real thing instead of my paraphrase of it. It says to invoke /implement and follow it, and it gives the branch and base I just claimed. It requires the pull request to say Closes #<number> in the body, and to come back with the PR number, what ran and its counts, and the teammate's own code-review output verbatim. If a rule in the ticket turns out to be wrong or impossible, the brief asks it to say so with evidence, not quietly work around it. I spawn every ticket in the batch this way, including the one that looks too small to bother with and the one in the repository I'm already sitting in. A ticket that looks too hard to delegate gets a missing fact added to its brief, not a decision I make myself instead.

By default a run doesn't target the org's actual default branch at all. The first ticket that needs one creates an integration branch named after the epic, and every ticket in the run builds against it. Merging a ticket's pull request onto that branch needs no approval from me, because it isn't shared history, nobody depends on it yet, and a bad merge there costs nothing but a follow-up ticket. The one pull request that does get reviewed by a human is the single one opened from that integration branch into the org's real default branch once the whole epic is done, and I open it, I never merge it myself. That's the one review that still happens manually, because it's the only merge in the whole run that actually changes the branch other people's work depends on.

When a ticket stops

When a ticket comes back without a working pull request, there are only two honest outcomes, and just one of them needs me. Either the teammate found a real dependency the graph was missing, in which case it gets recorded as a native "blocked by" link and frees itself automatically once that blocker closes, or nothing available can move the ticket forward, in which case the run reports it and continues without it rather than stalling the whole epic over one ticket.

Why a missed notification doesn't stop the run

Agent notifications occasionally just don't arrive. Because nothing about this skill is remembered between turns, a missed notification can't corrupt anything; the next frontier read just sees the pull request and continues. The real risk is quieter: the run can keep waiting, unaware the news already happened. So I keep a change feed running alongside the work, watching the epic and printing one line per status change, and it exits on its own once the epic is done. That still leaves one failure mode neither a notification nor a status change would ever reveal: a teammate that stopped before ever opening a pull request. There's no event for that, so the feed doesn't wait for one. A ticket sitting BUILDING for twenty-five minutes with no result yet gets flagged stale on its own, told apart from a build that's merely slow, and given to a fresh teammate instead of being abandoned.

Keeping the cost visible

Every teammate spawn has to name the model it's running on. That's a deliberate, enforced choice: the parameter is optional and inherits from whatever's running the skill, so an expensive model could easily work through a ticket sized for a cheap one, quietly, with nothing in the run's output ever saying so. A PreToolUse hook, code that runs right before a tool call and can block it, is set up automatically when the skill is installed. It refuses any spawn under this skill that hasn't stated its model explicitly, and it separately refuses one spawned as a fork, a lightweight spawn mode that always inherits the lead's own model regardless of what's asked for, so it can never actually be made cheap. The hook only looks at spawns this skill makes, so it never affects anything else running on the same machine. Most tickets are specced tightly enough that sonnet, the cheaper model, builds them correctly; the ones that need real judgment the spec can't pre-make get opus instead, deliberately, and the split gets reported at the end of the run.

What it deliberately doesn't do

This skill has a short list of jobs it deliberately refuses, and the refusals are as much the design as anything it does do:

• It doesn't plan. Tickets arrive already specced, with blocking links already in place. A ticket set with no dependency edges at all gets returned rather than ordered by guesswork.
• It doesn't write the brief. A teammate reads the ticket itself; the ticket is the spec.
• It doesn't triage for me. Judging whether a review finding actually matters is my job, not something this skill decides for me.
• It doesn't keep state. That's the one that made the rest of this possible: not tracking anything of its own is what lets the whole skill reduce to something small enough to actually reason about.

Everything that happens before it is where the actual trust gets built, one step at a time, long before any teammate writes any code.

When I have an idea worth turning into tickets, I start by getting grilled about it, with the grilling skill. That means one question at a time, never a batch, each one checked against a running tree of decisions, until nothing about the idea is still an assumption I never stated explicitly. If a question needs a fact rather than a choice, say, whether a piece of code already does something, or a table already has a column, a sub-agent checks it. I'm never asked to search for anything I don't have to. Only the real decisions come to me, one at a time, with a recommendation attached.

Once that conversation is done, to-spec synthesizes it, with no second interview, straight into a spec: a problem statement, user stories, the implementation and testing decisions we actually made, and what's explicitly out of scope. to-tickets then cuts that spec into tickets. Each one is a vertical slice through every layer the feature affects, sized to fit one context, and each one states exactly which other tickets have to finish before it can start. I get quizzed back on that breakdown before any of it ships, because getting the blocking edges wrong here is the one mistake that would break everything /implement-with-agent-team does afterward.

By the time a ticket reaches a teammate, the teammate invokes /implement to actually build it, and that adds one more layer of self-checking. Before writing any code, /implement turns every acceptance criterion into a gate in its own ledger, stated as something it can observe directly. It isn't allowed to call the work done while any gate is still unmet. It builds test-first at the seams the spec already agreed on, and it ends by running its own code review and committing.

Five things happen before an epic turns into code, and only the last one actually writes any of it. grilling interrogates the idea. to-spec writes the spec. to-tickets cuts the tickets. implement-with-agent-team runs the resulting graph to completion, one merge at a time. implement, running inside every teammate it spawns, is the one that writes the code. That order is what let me stop rereading every diff by the time it reached me. The ticket a teammate gets was never really a request. It was a decision I'd already made, several skills earlier, deliberately.

For a single ticket with nothing depending on it, I still just run /implement directly and skip all of the steps above. This skill is worth using specifically when there's a batch with real dependency structure between the pieces.

How to get it

It ships as a Claude Code plugin, in my fork of Matt Pocock's skill repo, bundled alongside to-spec, to-tickets, implement, grilling, and the rest of the set it depends on:

claude plugin marketplace add Odame/skills
claude plugin install odame-skills@odame

That fork-specific install matters: implement-with-agent-team is my own addition and only exists in Odame/skills, so Matt's own marketplace listing (claude plugin install mattpocock-skills, no @odame) won't have it. The plugin id is odame-skills, but every skill and slash command inside it still keeps the name Matt documents in his own repo; only the id differs. Everything else in the bundle is his, tracked against mattpocock/skills with any local changes recorded in PATCHES.md.

Reusing the existing content pipeline

The constraint I set myself: no new dependencies. This site already runs gatsby-source-filesystem and gatsby-transformer-remark to pull markdown into the homepage: job history, project descriptions, the about section all work this way. A blog is just more of the same content pipeline, pointed at a new folder.

So a post here is a directory:

src/content/blog/2026-09-02-hello-world/index.md

From folder to URL

The date prefix is cosmetic; it makes the folder list in order on disk. gatsby-node.js strips it before turning the folder into a URL, so this post lives at /blog/hello-world/, not /blog/2026-09-02-hello-world/. Slugs come from createFilePath, one of Gatsby's node APIs; page creation happens in createPages, which runs a GraphQL query over allMarkdownRemark and calls createPage once per result.

Minimal frontmatter, on purpose

Frontmatter is small on purpose: title, date, description, tags. Nothing about the blog needed more than that yet. If it does later, I'll add a field when there's an actual page that reads it, not before.

That's the whole setup. More posts to come, on whatever I'm building at the time.