Skip to content
← Back to Articles

My Sister Shipped 5 PRs in an Hour

· 8 min read
Agentic Development Platform Engineering GitHub Copilot Developer Experience Opinion
My Sister Shipped 5 PRs in an Hour

My sister Sofia is a marketing graduate. She works the front desk at our dad’s diesel mechanic shop, answers calls, books appointments, hands customers their keys. She had never opened a pull request. She did not know what a pull request was. She had never heard the words “worktree”, “migration”, or “preview deployment”.

Last week she shipped five PRs in one hour. By the end of the night she had shipped around twenty. Each one was a real change against a real codebase, gated by GitHub Actions CI, isolated in its own git worktree, previewed on its own Vercel deployment, merged through an approval gate she controlled from her phone. She never saw a terminal. She talked to a Telegram bot she named “Daniella” — apologized to it when she changed her mind, thanked it when it finished — and the harness underneath did the rest.

This is not a no-code story. Sofia is a non-technical product owner shipping real production changes. The thesis of this article is exactly one sentence: converting a vibe coder into a production workflow engineer is enabled, almost entirely, by platform harness engineering. The model is not the lever. The prompt is not the lever. The harness is the lever.

What Sofia Actually Did

Sofia opened Telegram. She typed what she wanted. A few minutes later she got a URL. She clicked it, looked at her app in a real browser tab, and replied “I like it” or “add this” or “change the color”. When she was happy, she tapped an approve button. The change went live. She repeated that loop twenty times.

That is the entire user-facing surface. There is no IDE. No git command. No staged hunks. No conflict resolution. No CI dashboard. There is a chat window, a preview URL, and an approval button. That surface is what most people call “vibe coding”. On its own, it produces toys. Wired to a real harness, it produces shipped software.

What Sofia Never Saw

Every one of those twenty PRs went through machinery she has never heard of:

Sofia’s mental model is: I asked, I checked, I approved. That model is honest. The harness is what makes it true.

Two-layer diagram: Sofia's chat-and-approve surface above; the invisible harness (worktrees, CI gates, Vercel previews, HookFlow merge) below. Sofia operates on the top layer. The bottom layer — six pieces of platform engineering — is what makes the top layer honest.

The Merge Conflict That Forced a Better Architecture

Around PR number six, things broke. She had six, seven, eight open PRs at once — all touching adjacent surfaces, all racing each other. Classic merge-conflict pile-up. A normal developer would notice, rebase, resolve, push. Sofia had no concept of any of those verbs. She just kept tapping approve.

That night forced the single biggest platform improvement I have shipped this year: I built agent-merge, a tool that splits “intent of approval” from “execution of merge”. The human signals intent — one tap, “ship it” — and a separate governed agent picks up approved PRs and does the actual git work: rebase against the latest main, wait for CI to finish, resolve trivially mergeable conflicts, escalate the ones that aren’t, and merge everything sequentially in a deterministic order. Sofia kept tapping approve. Agent-merge made sure each approval landed cleanly, one at a time, no pile-up.

I wrote the long version in Agent Merge: Speed Without Losing Control. The supporting mechanics are in Stop Trusting AI Agents with Git — Start Governing Them and Aspect-Oriented Programming for AI Agents. The short version: the bottleneck stopped being “the agent making mistakes” and started being “the harness not catching them yet”. Agent-merge was the harness that caught the merge-conflict pile-up before it caught Sofia.

Approval intent vs merge execution diagram: human signals "approve" on one side; the agent-merge tool rebases, waits for CI, resolves conflicts, and merges sequentially on the other. The split that became agent-merge: Sofia signals intent with a tap; the merge-agent handles rebase, CI waits, conflict resolution, and sequential merging.

Daniella

Sofia named the bot Daniella. I don’t name my bots. I never have. To me they are tools — important tools, but tools. When the agent finishes a task I close the loop and move on. When Sofia’s agent finished a task she typed “thank you, Daniella”. When she changed her mind mid-feature she typed “sorry, Daniella, can we go back”.

That difference is not trivia. It is a real signal about how non-technical users relate to agents. Developers project tool-ness onto an agent. We see the API, we see the loop, we see the prompt template. Non-developers project colleague-ness. They form a working relationship with the thing on the other side of the chat. That changes everything about how the agent should communicate — error messages, status updates, refusal patterns, even pacing. The colleague metaphor is more accurate to what is actually happening underneath, and we developers may be the ones with the wrong mental model.

It also means a non-developer’s tolerance for ungoverned agent behavior is much lower than ours. They take “I’ll do that” literally. They don’t second-guess. When Daniella says it’s done, Sofia believes it is done. So Daniella had better not be wrong. The only way to make sure she isn’t is the harness.

The Harness Is the Developer Multiplier

Here is the part the industry keeps getting backwards. The discourse is overwhelmingly about the model (which is bigger, which is smarter, which writes cleaner functions) and the prompt (how to phrase, what to include, which framework to use). Both matter at the margin. Neither is the lever.

The lever is the harness around the agent:

I wrote What Is Harness as Code to give this discipline a name. Sofia’s night is the clearest proof I have that the name matters. Every additional PR she pushed, I was on the platform side adding another HookFlow, tightening another scope, codifying another piece of context. I was not coaching her. I was not reviewing her code. I was engineering the harness underneath her in real time, and the harness was what scaled.

Pull the harness away and Sofia ships nothing. Hand the same harness to a senior engineer and you get a developer who is suddenly 5–10x faster, because the same machinery that absorbs Sofia’s inexperience absorbs their context-switching, fatigue, and 2 AM mistakes. The harness is not a beginner’s tool. It is everyone’s tool. Sofia is the proof that it works at the floor; senior teams are where it pays the rent.

Side-by-side comparison: Sofia ships ~20 PRs/evening with the harness and 0 without; a senior engineer goes from 1× to 5–10× throughput with the same harness. Same lever, two starting points. The harness raises the floor and the ceiling at the same time.

The Skill of the Next Decade

If you lead a platform team, a DevOps function, or an SRE org, this is the part to internalize. The skill that decides who wins the next decade of software is not “knows how to prompt”. It is harness engineering: HookFlows, deterministic gates around non-deterministic agents, scoped contexts, audit-friendly approval flows, isolation primitives like worktrees and ephemeral environments. This is real engineering work, with real testability, real observability, real on-call implications. It is also where almost all of the leverage in agentic development lives.

I’ve argued versions of this before — in Three Pillars of Agentic DevOps, in The Agentic Development Maturity Curve, in Your God Prompt Is the New Monolith. Sofia’s night is the cleanest data point I have. A marketing grad with no programming background, on her phone, shipped twenty production PRs in an evening because someone had spent months engineering the harness around the agent. Without that harness she ships zero. With it, she out-ships most senior developers I have worked with on raw PR count, with comparable per-PR quality.

If you take one thing from this article, take the sentence I keep going back to in my own head: converting a vibe coder into a production workflow engineer is enabled almost entirely by platform harness engineering. Stop optimizing prompts. Stop chasing the next model. Start engineering harnesses. That is where the next class of developers — Sofia, and everyone like her — is going to come from. And it is where your existing developers are going to find the next order of magnitude.

I am very proud of my sister. I am even more sure, after watching her work, that the discipline I have been building toward is the right one. The harness is the lever. Build the lever.

Resources

← All Articles