Vibe coding killed Zapier - what replaces it is not another Zapier

You finally deleted the last zap. An AI wrote you a cleaner replacement in about ninety seconds, it runs, and the per-task invoice is gone. So who gets paged when the invoice sync quietly stops on a Saturday?

That question is the entire succession battle for middleware, and almost everyone is answering the wrong half of it. I made the case in vibe coding killed the integration marketplace that describing an integration in plain English beats browsing thousands of pre-built connectors. I stand by that. But “the marketplace dies” and “nothing replaces it” are very different claims. Something replaces it. The replacement just doesn’t look like a marketplace, and the teams figuring this out early are mostly the ones tracking what AI changes about the software a business runs on rather than shopping for a cheaper Zapier.

Here’s the short version up front. Zapier sold you two products under one price tag: the integration logic, and the operational substrate that logic ran on - stored credentials, retries, monitoring, somebody to blame. Vibe coding made the first product nearly free. It did nothing whatsoever to the second. The replacement for Zapier is whatever supplies that second product for code a model wrote on request.

Which half of Zapier is dead?

In February 2026, a16z general partner Anish Acharya went on the 20VC podcast and threw cold water on the maximalist story. “But the general story that we’re going to vibe code everything is flat wrong, and the whole market is oversold software,” he said, in remarks Business Insider wrote up. His math: software accounts for 8% to 12% of a company’s expenses, so aiming your shiny code generator at rebuilding internal tools caps your savings at pocket change. “Why would you point it at rebuilding payroll or ERP or CRM,” he asked.

Worth keeping the scope of the claim honest, too. When the story hit Hacker News - submitted by paulpauper in February 2026 - a commenter called nylonstrung noted this wasn’t “a16z monolithically speaking as a firm”; it was one general partner on a podcast, one the commenter pegged as focused on fintech. Fine by me. The argument stands or falls on its own, and it half-stands.

He’s right about payroll. Nobody sane regenerates their ERP because a model can now write Java.

But integrations sit in a different bucket from the systems they connect, and the bucket matters. The same thread didn’t spend much energy defending vibe-coding-as-ERP-replacement. It fought over a sharper question: what does AI-generated software still lack even when the code itself is fine? Commenter rwmj put the inventory in one sentence: AI makes it easier to create something, “but that thing is not enterprise software with support contracts and conformance to mandatory regulations and 4 hour bug turnarounds and real people on the end of the phone who understand how it works.”

Read that list again. Not one item on it is code.

That’s the split that decides the Zapier succession, so let me state it cleanly. Every integration platform was selling two distinct things: the connector logic, and the substrate underneath it. The logic - field mappings, API calls, transformations - is the half vibe coding killed, because a model now produces it on demand, tailored to your exact case, in minutes. The substrate is everything rwmj listed, scaled down from enterprise contracts to the daily questions of one automated process: where the credentials live, what happens on a failed call, who notices the silent stop, whose name is on the fix. Vibe coding made the first half nearly free and left the second half exactly as expensive as it always was. Worse than expensive: orphaned, because the vendor who used to carry it is the thing you just cancelled.

Logic became the cheap half

The uncomfortable arithmetic for every connector marketplace is that its catalog was mostly frozen logic. A connector is somebody else’s guess about how you’d want two APIs wired, written once, maintained centrally, rented monthly. Useful when bespoke code was expensive. Absurd when bespoke code costs a sentence of English and a minute and a half of patience.

Acharya’s 8-to-12% framing cuts in an interesting direction here, and it’s one his own soundbite undersells. If software is a sliver of company cost, the win from regenerating big systems is small - but integration glue was never priced like a big system. It was priced per task, per zap, per row moved, a meter running on top of logic that a model now writes for free. The meter is the part that became indefensible. The glue work itself was always tiny; that’s exactly why metering it annoyed everyone.

What kept the meter defensible for a decade was the bundle. You weren’t really paying for the mapping between a form field and a CRM column. You were paying for OAuth tokens that refresh themselves, retries you never saw, a dashboard with a green light on it, and a vendor whose pager - not yours - went off when an API version rolled over. The zombie zaps that outlive their creators hang around precisely because that bundle made automations easy to create and unaccountable to own.

The bundle, not the logic, was the moat.

Unbundling is what vibe coding really did. It tore the cheap half out of the package and handed it to anyone who can type. The expensive half - the substrate - is still standing there, unpriced and unowned, and most teams won’t notice they lost it until the first quiet failure. That’s also why “we’ll just generate our integrations now” is a budget line that lies to you. The subscription you cancelled was mostly buying the substrate; the line item you kept - nothing - is what’s now carrying it.

Could you vibe code the substrate too? Kind of - you could generate a retry queue, a secrets vault, and an alerting system from prompts. Now you get to cobble together a bespoke operations platform nobody on your team has read, wrapped around a 40-line sync script. Congratulations on the world’s most artisanal way to rebuild Zapier.

Auth, retries, observability, ownership

Name the substrate precisely, because it’s only four things.

Authentication is the first and the stickiest. An integration acts on systems, which means credentials, which means storage, rotation, scoping, and revocation. The HN thread’s counterweight voice, zozbot234, argued AI makes bespoke niche software viable and that maintenance could be shared the way open source shares it - fair as far as it goes, but notice that shared maintenance is itself a substrate answer, not a code answer. Somebody still holds the keys. Tallyfy is building Tallyfy Vault for exactly this gap - per-user credentials so an automated step acts as a person, not as an all-powerful service account - and I’ll be straight with you: it’s coming soon, not shipped today. The need showed up well before the product did.

Retries are the second thing, and they’re where generated code is most charmingly naive. The happy path a model writes will call the API, get a 200, and move on. Real systems return 429s at month-end, time out behind VPNs, and rate-limit you mid-backfill. How reliability multiplies down a chain of AI steps is its own post, but the one-line version: chain ten 95% steps and the whole job finishes cleanly only about six runs in ten, and retry-with-escalation is what bends the math back.

Observability is the third. A zap that fails sends an email someone ignores; a generated script that fails does nothing at all, which is worse. In the same thread, re-thc was blunt about why this layer resists casual generation: “I don’t see AI easily creating a DataDog. You need it for reliability for example.” The point survives even if you never buy a monitoring product - someone has to be able to glance at one screen and answer “did the Friday invoices go out?”

What nobody warned us about when we put a production MCP server in front of Tallyfy was how much of the operational work would be about edges rather than logic. The model-facing part behaved. The substrate part is where the surprises lived: we’ve watched a single user confirmation fan out into well over a hundred delete calls because nothing in the run was bounded, and we’ve cleaned up orphaned AI subprocesses that quietly ate a server’s memory until an external sweeper - not the AI, and not the code it wrote - noticed and killed them. None of that is the model writing bad code. All of it is what happens when working code runs somewhere with no edges, no caps, and no named owner. The logic was fine. The room it ran in wasn’t.

Ownership is the fourth thing, and it’s the one that decides whether the other three get fixed.

Who owns the retry queue now?

In the Zapier era you half-owned your automations: the vendor owned uptime, you owned configuration, and the ambiguity was annoying but survivable. In the vibe-coded era, the ambiguity is fatal, because there’s no vendor in the loop at all.

A script with no owner is a liability with a cron schedule.

And ownership is the substrate item teams skip first, because it’s the only one that can’t be generated - you can prompt your way to a retry loop, but you can’t prompt a person into caring about a failure they’ve never heard of. The fix isn’t a tool. It’s a name attached to a failure mode before the failure happens.

Give the surviving half a home

So what replaces Zapier? Not a smarter marketplace. Not a prompt box bolted onto the old meter. The honest answer is: a defined process that generated code runs inside, because a process is the cheapest packaging of all four substrate items that ordinary teams already understand.

Walk the mapping. A process step has an assignee, so ownership is solved by the same mechanism that assigns expense approvals - when the sync step fails, it doesn’t vanish into a log, it becomes a task with a face on it. Steps have deadlines and escalation rules, so retries and timeouts live in conditional rules a non-engineer can read. The process has a live tracking view, so observability comes free with the furniture - you see the stuck step the same way you see a stuck hire in onboarding. And credentials attach to the people or the workflow, which is the Tallyfy Vault approach, rather than floating in whatever .env file the generated script happened to mention.

The counterintuitive part of running AI steps for real teams is that the integration code turns out to be the least interesting line item. In our own customer workflows, the AI work that holds up in production is narrow and bounded - a step that reads and extracts, a step that classifies, a step that drafts, a step that triages and routes - and it’s still early days for all of it. The glue between systems wants the same shape. Our MCP server already exposes 100+ tools so an AI client can search tasks, launch processes, and complete steps through natural language; the roadmap - and I do mean roadmap, not a shipped feature - is that the integration code itself gets described in English and generated, then lives inside one named step of one named process. That placement, not the generation, is the case for putting AI inside defined workflows: the step boundary is what turns clever code into an operable system.

Acharya would call that boring. He’d be right.

Boring is the compliment infrastructure earns.

The process layer doesn’t compete with the model on intelligence; it supplies the dull guarantees the model can’t: this runs second, this stops here, this person hears about it. We tried writing those guarantees into prompts. They don’t hold. Tell a model “always stop for approval above ten thousand dollars” and you’ve expressed a preference; put an approval step between the draft and the send and you’ve built a fact. A prompt is a request; a workflow is a constraint, and constraints are the part of the system that still deserves to be hand-built.

If you own a wall of zaps today

The migration question lands on operations leaders, not developers, so here’s the operations version.

Inventory first.

Every zap, every scenario, every scheduled script - and for each one, two columns: what’s the logic, and what substrate is it silently borrowing? A Slack notification borrows almost nothing and can be regenerated by anyone, anytime; let those live wherever they like. An invoice sync borrows credentials, retry behavior, and an owner, whether or not anyone wrote those down. The second column is your real migration plan, and it’s the column the Zapier alternative conversation tends to skip when it fixates on per-task pricing.

How many of your zaps could anyone on the team explain today?

Then migrate in order of borrowing, heaviest first. The financial syncs, the access-granting flows, the anything-that-touches-customers: those become steps inside defined processes, where a failure turns into an assigned task instead of a quiet gap in a spreadsheet. The throwaway glue stays throwaway - part of being honest about this shift is admitting that plenty of automations never deserved infrastructure in the first place.

What you should not do is replace one connector subscription with another and call it a strategy. The next Zapier, if that phrase even means anything, won’t win by having more connectors. There’s nothing left to win there; the connector is now the output of a sentence. The competition moved down a layer, to the substrate - and the substrate question is the one Acharya’s 8-to-12% math never reaches, because the cost of an unowned failure was never in the software budget to begin with. It was in the missed invoices, the access nobody revoked, the customer who found the gap before you did.

The marketplace is dead. Long live the place the generated code reports to.