Pair-build mode: how we work with vibe coders without taking over their project
Most agencies eat the codebase. We don't. Here's how EdsDev runs pair-build engagements with vibe coders shipping in Cursor and Claude Code — without hijacking the keyboard or the vision.
The problem with hiring help when you’re already shipping
You’ve got a half-built app in Cursor. The auth kind of works. The Stripe webhook fires twice sometimes. You know exactly where the duct tape is — because you put it there at 1am last Tuesday.
Then you hire an agency. Two weeks later they’ve rewritten your folder structure, replaced your ORM, introduced a monorepo, and you can’t find your own login page. The thing still doesn’t ship.
This is the default failure mode of dev-for-hire when the client is a builder. We’ve seen it from both sides. So at EdsDev we run something different on these engagements. We call it pair-build mode.
What pair-build actually is
Pair-build is a working agreement, not a methodology with a capital M. The shape:
- You stay the primary author. Your name is on the commits that matter. We push to branches, not main.
- We work in your stack, your conventions, your AI tools. If you’re in Cursor with a specific
.cursorrules, we use it. If your prompts to Claude Code follow a pattern, we follow it too. - We pick lanes, not the whole highway. Usually we take the parts you don’t want to touch: auth edges, payment reconciliation, background jobs, deploys, the schema migration you’ve been avoiding.
- We pair live for the hard parts. 60-90 minute sessions, screen-shared, one of us driving the AI, the other reading diffs and catching the hallucinations.
That’s it. No Jira. No two-week sprints. No “discovery phase.”
Why this works for vibe coders specifically
If you’re shipping fast with AI tooling, you’ve built up a tacit model of your own codebase that doesn’t live in any document. You know that lib/db.ts is sacred and lib/utils.ts is a graveyard. You know the LLM keeps trying to add Zod schemas you don’t want.
A traditional agency engagement requires you to externalize all of that. Which takes weeks. Which is why you didn’t hire one in the first place.
Pair-build skips externalization. We learn your codebase the same way you did: by editing it, getting things wrong, and watching you correct us in real time. The first session is usually rough. The third session we’re moving faster than you alone.
The rules we follow on someone else’s repo
These are non-negotiable on our side:
1. No silent refactors
If we want to change a pattern you established, we ask. In a comment, in a Loom, in chat. We don’t ship a PR that quietly renames your User model to Account because we think it’s cleaner. Your code, your call.
2. Match the AI tool, don’t fight it
If you’re using Claude Code and we prefer Cursor, we use Claude Code. The point is your future self can reproduce what we did with the tools you already pay for. We’ve watched too many handoffs die because the outgoing dev used some bespoke prompt chain nobody else could run.
3. Commits explain themselves
We write commit messages like we’re writing to you specifically, because we are:
fix(stripe): handle webhook idempotency via event.id
Webhook was firing 2x on subscription.updated because Stripe
retries on any non-2xx. Added idempotency check against
processed_events table. Migration in 0007.
Left your existing error logging untouched.That last line matters. It’s the difference between a collaborator and a contractor.
4. We document the trap doors
Every codebase has them. The env var that breaks prod if you change it. The seed script that wipes the DB. We write these down in NOTES.md as we find them. You get to keep that file.
A real example (anonymized)
Client came to us with a B2B SaaS, ~8k lines, built mostly in Cursor over six weeks. Working product, three paying customers. The problem: Postgres on Supabase was eating their lunch on a specific dashboard query — 4-6 seconds.
What a normal agency would do: propose a two-week “performance audit,” rebuild the data layer, suggest Redis, charge $20k.
What we did:
- Session one (90 min): paired in their editor, used their existing AI setup to read the query, ran
EXPLAIN ANALYZE, found a missing index on a join column and a N+1 in the controller. - Shipped the index migration and a
selectrewrite. Query dropped to 180ms. - Session two (60 min): set up a basic query log so they’d catch the next one themselves. Wrote three paragraphs in their
NOTES.mdabout how to readEXPLAINoutput.
Total: ~3 hours of our time. Their codebase looks almost identical to before. They can now diagnose the next slow query without us.
That’s the goal. Make ourselves less necessary, not more.
When pair-build is wrong
It’s not the right mode for every engagement. Skip it if:
- You want someone to own a thing end-to-end and not bug you. That’s a different contract — full delivery, we run it our way.
- You don’t actually want to learn. If the goal is “make it work and don’t explain,” pair-build wastes everyone’s time.
- The codebase is genuinely unsalvageable. Sometimes the honest answer is rewrite, and we’ll tell you.
We turn down maybe a third of pair-build inquiries for one of these reasons. Usually we route them to a fixed-scope build instead.
The pricing thing
We charge for pair-build by the session, not by the sprint. A session is 60-90 minutes plus whatever async follow-up the work needs (code review, a small PR, a Loom walkthrough). Most clients buy them in packs of four.
This aligns incentives correctly. We don’t make more money by dragging things out. You don’t pay for a Slack channel where nothing happens for three days.
What you should ask any collaborator before they touch your repo
Steal these questions. Use them on us, use them on anyone:
- Will you push to main or only branches?
- If you disagree with a pattern in my code, what do you do?
- What AI tools will you use, and can I see the prompts?
- At the end, what artifacts do I keep that explain what changed?
- How do I fire you with two days’ notice and not be stuck?
If the answers are vague, you’re about to lose control of your project.
The short version
Vibe coders don’t need to be rescued. They need a second pair of hands that respects the work already done, knows the AI tooling, and leaves the codebase more legible than it was found. That’s the entire job.
If you’re shipping something and want a collaborator who won’t try to take the wheel, come talk to us.
Related posts
MVP software development when the prototype already exists
A field guide to finishing what Cursor, v0, and Claude Code started. How to take a half-working vibe-coded prototype and ship it as a real MVP without rewriting from scratch.
The vibe coder pre-launch checklist: what actually breaks in production
You shipped it in a weekend with Cursor. Now it has users. Here's the unglamorous list of things that break when AI-generated code meets real traffic, real money, and real people.
An AI lead generation agent that books meetings while you sleep
How we build AI lead generation agents that actually book meetings: the workflow, the prompts, the guardrails, and the bits that quietly break at 3am.