Twice last month, a founder told me their entire MVP had been written by an AI agent over the course of a long weekend. Both times, in the same conversation, they asked us to help them save it. I don't say that to dunk on either of them. I say it because that's the state of the industry in 2026, and we should be honest about what it means.
Vibe coding is the best thing to happen to early-stage product building in the twenty years I’ve been doing this. It’s collapsed the distance between a hunch and a working prototype to something close to zero. It lets non-technical founders prove demand without raising a round first. It lets engineers move past the boring parts of a backlog in an afternoon. We use these tools at Counterpart every day. We’re not arguing with the moment.
The argument we are making is more specific. It’s this: the kind of software you can vibe-code is not the kind of software our clients pay us to build. Our clients have hard problems: regulated data, real money, legacy integrations, customers who already trust them. The thing that ships in a weekend is not the thing that survives the third customer, the first audit, or the second engineer. The shape of the work changes once your product starts mattering.
01 · The new questionWhere does the prompt stop being enough?
Every Counterpart conversation now starts with some version of the same question. It’s asked in different words, by founders and CTOs at very different stages of company, but underneath it’s the same thing:
"We built our MVP with AI in a weekend, and now real customers are using it. Where does that stop being a good idea?" Every founder we've talked to since January
The honest answer is that there’s no single line. There’s no exact day on the calendar where vibe coding becomes irresponsible. What there is, instead, is a set of conditions, and once enough of them are true at once, the math of generated code stops working in your favor. Here’s the short list of those conditions, in roughly the order I see them appear:
- Real money moves through the product. Payments, payouts, accounts. Once that’s true, a refactor that loses a row is a chargeback or a lawsuit, no longer a bug report.
- A regulator can call you. HIPAA, SOC 2, PCI, the patchwork of state privacy laws. Generated code doesn’t produce an audit trail. You can ask it to. It will lie politely.
- You have customers, not users. The first time someone calls you at 7am to ask why their data is gone, the calculation around speed versus stability has already changed. You just haven’t done the math yet.
- The rules live outside the schema. Eligibility, custody, ledgers, entitlements. The hard parts of the business are exactly the parts the prompt doesn’t know.
If two of these are true for you, you’re in the borderline zone. If four are true, you’ve outgrown vibe coding and you probably already feel it. The lead engineer on the project is the one whose face goes still when you talk about adding a second region. The CEO is the one who’s started saying “we should really get this audited” as a joke that nobody finds funny.
02 · What we actually mean by "by hand"The cooking school analogy.
Whenever I talk about writing code by hand, somebody assumes I mean we have a moral objection to LLMs. We don’t. The phrase isn’t literal. We’re not turning off our editor’s autocomplete and writing assembly. What we mean by “by hand” is closer to what a serious restaurant means when they say a sauce is made by hand.
Aside · The cooking school analogy
A serious restaurant uses an industrial mixer. It doesn't pretend not to. The "made by hand" claim was never about the tools. It's about who decided what goes in, who tasted it, who corrected it, and who put their name on it. A chef who only presses the start button isn't a chef. A chef who refuses to use the mixer isn't a chef either. The skill is in everything around the machine.
That’s how we use AI tools at Counterpart. They’re the industrial mixer. They scaffold the well-understood, the boilerplate, the bits that have been written ten thousand times before. They draft the test cases. They write the docstrings. They translate a senior engineer’s intent into a first pass at code, sometimes very fast.
What they don’t do, in our shop, is pick the architecture. They don’t own the data model. They don’t decide what gets shipped. They don’t sit on the phone with the integration partner whose API you have to live with for the next six years. They don’t get paged at 2am. The work that determines whether your software is good, the work you actually pay a firm to do, is still done by people. AI gets to be the mixer.
03 · The taxonomyWhat people still do better than the prompt.
I want to be specific about this because “humans matter” is a useless sentence on its own. Here’s the actual list of jobs that, as of mid-2026, no AI tool has been able to take from a senior engineer working on a real production system:
- Choosing the architecture.
- Picking the right shape of system for a problem requires understanding constraints that are nowhere in the codebase: regulatory, financial, organizational. A model will pick a stack it has seen succeed in similar code. That's not the same as picking the right one.
- Owning the data model.
- The schema is the contract that survives every refactor. Getting it right means understanding the business deeply enough to know what the invariants are. The model will normalize what it sees. It won't invent the constraint you needed and forgot to mention.
- Negotiating an integration.
- Real systems integrate with real partners. Real partners have an API that doesn't match their documentation, a sales engineer who's on vacation, and a workaround that requires a phone call. The prompt has no phone.
- Drawing the safety boundary.
- What's safe to ship today, what's safe to ship after a review, and what's not safe to ship at all. A senior engineer makes this call by reading the room as much as the diff. The model will tell you it's safe because that's statistically what its training data said.
- Being on call.
- When something's on fire at 2am, the engineer who fixes it is the one who actually understands the system, not the one who can describe it eloquently to a chatbot. Production is the moment the keystrokes stop and the judgment starts.
Notice what these five have in common. Each one is the kind of work where being wrong has a cost that compounds: over months, over customers, over audits. Each one is the kind of work that, when it’s done well, is invisible and feels easy. And each one is the kind of work where you can’t tell from the outside whether anybody did it at all, until the day you suddenly can.
Use AI to type faster.
Use people to think harder. Counterpart engineering principle
04 · The economicsWhy this isn't actually a price-up-front argument.
Here’s the part of the conversation that the AI-only firms have a hard time with, because it’s the part that requires showing up in year two of an engagement. The real cost of vibe-coded software shows up after the build: the cost of replacing it, the cost of explaining it to the next engineer, and the cost of every customer-impacting bug that the original team’s optimism didn’t catch.
We’ve run the numbers on dozens of rescue projects over the last two years. The shape of it is depressingly consistent. A vibe-coded MVP that gets traction takes three to six months of senior engineering work to bring up to a state where a real team can extend it. That work usually costs two to four times what the original build cost, depending on how many customers you’re protecting in the meantime. And the security number, that something like seventy percent of generated code lands with known vulnerabilities, is published research, not our editorial. Even discounting that number by half, it’s more than a CTO can ignore.
A note on those numbers
We share these ranges because we want to be honest about what we see, not because we think your numbers will match. Yours will be different. The point is the order of magnitude. The point is that the bill is bigger than the prompt suggested.
The reason this matters for the buying conversation is that a Counterpart engagement only looks more expensive because the visible part of the alternative is so small. When the founder compares our quote to the monthly cost of an AI coding subscription, they’re comparing two different lines on two different P&Ls. The honest comparison is what each path costs by the end of year two. By that measure, partnership is the cheap option for our kind of client. We haven’t lost a head-to-head on the year-two math.
05 · What "partner" actually meansThe flexible-engagement model.
I want to address one objection that gets raised in every first meeting, because it’s reasonable and it deserves a real answer. The objection is roughly: “if we hire you, are we hostages to Counterpart for the next five years?”
The answer is no, and the long version of the answer is the most important thing I’ll say in this piece. We work in your repos, with your tools, on a flexible engagement that’s structured to make you durable without us. The engagement gives us no reason to be the indispensable layer. Our incentive is to leave behind a system that your in-house team, when you eventually hire one in year two or three, can take over without rewriting.
That means our deliverables include documentation we’d actually read ourselves. It means architectural decisions are recorded with the reasoning, not just the result. It means tests that catch real regressions, observability that surfaces the right alarm, and runbooks that work when the engineer who wrote them is on vacation. It means we hand you a thing that you own.
06 · The closing thoughtWhat we are not.
I want to end with what we are not, because the inverse is sometimes the clearest way to be precise. We’re not an AI replacement. We’re not a code-by-the-line shop. We’re not the elite white-glove firm that costs three times what it needs to and treats your engineering team like a service desk. We’re not whimsical or transactional or surface-level, to crib from our own brand book.
What we are is a small team of senior people who’ve built complicated things before, who know which problems an AI tool will accelerate and which problems it’ll quietly make worse, and who’ll sit with you in the room while you decide what to do next. We use the mixer. The recipe is still ours. The sauce is yours.
If you’re reading this because the timing rings true, because you can feel that your prototype has started to matter and you don’t yet have the team to match, that’s the right moment to write us. Even if the answer is that you don’t need us yet, which is sometimes the answer, you’ll leave the conversation with a clearer map of what you’re about to do.
Thanks for reading. The fastest way to reach the team is to start the conversation.