Vibe Coded or Automated? The Question Nobody’s Asking Correctly
The decision isn’t technical. It’s about who owns the logic — and what happens when it breaks.
There’s a version of this conversation happening in every design and product team right now. Someone built a custom app over a weekend using AI assistance — a handful of prompts, a few iterations, a surprisingly functional thing that does exactly what the team needed. Someone else hooked up Zapier and had the same problem solved in forty minutes without writing a line of code.
Both worked. Both broke eventually. The teams that chose well understood something the others didn’t.
The question isn’t “should we vibe code this or automate it?” The question is: what kind of problem do you actually have?
What Vibe Coding Actually Is (and Isn’t)
Let’s be precise before we go further. Vibe coding — the practice of building functional software through conversational AI prompting rather than conventional development — is not a shortcut to real engineering. It’s a different kind of tool entirely. It excels at producing bespoke, single-purpose applications that fit a specific workflow like a custom-cut piece of trim. It is not suited for infrastructure, for anything that scales unpredictably, or for systems where the failure mode involves someone else’s data.
What it produces, at its best, is a piece of software with a very short distance between the problem and the solution. No middleware. No third-party schema. No feature you didn’t ask for accidentally creating a dependency you’ll find six months later.
That specificity is its superpower and its liability in equal measure.
When the Custom Build Wins
The right time to reach for a vibe-coded custom app is when the automation tool would require you to contort your actual workflow to fit its abstraction.
Every automation platform has a mental model baked in. Zapier thinks in triggers and actions. Make thinks in modules and routers. These are good mental models for a huge range of problems — and genuinely terrible fits for a different range of problems. When you spend more time figuring out how to describe your process in the platform’s terms than you would spend just building the thing, that’s a signal.
Custom builds also win when the interface matters. Automation tools are invisible by design; they run in the background and the human never touches them. But some workflows need a human in the loop — a screen to review, a button to approve, a view that surfaces the right information at the right moment. You can bolt a UI onto automation, but it tends to look like exactly what it is: a bolt-on.
Finally: when the logic is genuinely novel. If nobody has built a connector for what you’re trying to do, that’s either a sign that your workflow is unusual enough to warrant custom tooling, or a sign that you should reconsider the workflow. Usually it’s the former.
When Automation Tools Win
The automation tool wins when the problem is a commodity problem wearing a custom costume.
Most workflows that feel unique are actually variations on a small number of patterns: receive data, transform it, send it somewhere, notify someone. If your problem fits that shape — and most do — an automation platform handles it better than a custom build will, because the platform was designed to do exactly that, has been stress-tested by thousands of teams, and has a support ecosystem you didn’t have to build.
The other decisive case for automation: team handoff. A vibe-coded app is a document of the conversation that produced it. It reflects the mental model of whoever built it, in the moment they built it. When that person leaves — or when the AI that powers it changes — the app becomes archaeology. Automation tools, for all their limitations, are readable by the next person.
There’s also the maintenance question, which people consistently underestimate at the point of building. Custom code rots — not dramatically, just gradually drifting out of alignment with the systems around it. An automation workflow also requires maintenance, but the scope is contained; you’re updating a connection, not debugging a system.
The Framework I Actually Use
When I’m evaluating which approach to take, I run through three questions in order:
01 — Will someone besides me need to understand or modify this in the next year?
If yes, lean toward automation tooling. Legibility has compounding value.
02 — Does the interaction design matter?
If a human needs to navigate it and make decisions in it — not just receive output from it — build it. Automation tools are not interface tools.
03 — Is the logic genuinely mine, or am I reinventing something that exists?
If your workflow is a variation on a known pattern, use the tool that knows that pattern. If it’s truly specific to how your team operates, the abstraction cost of fitting it into someone else’s model isn’t worth it.
There’s a fourth question I’ve started adding recently, because the AI moment has made it relevant: what happens when the underlying model or platform changes? Vibe-coded apps carry more fragility here, not less. The faster you can build something, the faster it can become unmaintainable when the tools shift underneath it.
The real cost of getting this decision wrong isn’t the build time. It’s the maintenance belief system it creates.
Custom-everything teams accumulate the belief that they can build their way out of any problem. Automation-only teams accumulate the belief that every problem has a connector. Both beliefs are expensive.
Know which tool you’re reaching for before you pick it up — and why.
Linda Brown
Systems Architect building intelligent structures for creative teams — at the intersection of design systems, AI infrastructure, and the stubbornly human parts of creative practice.