What vibe coding is good at
It is good, and it is not going away. Describe an application, watch it appear, change it by asking. For a prototype, a tool for yourself, a script that does one job, an internal thing five people use, it is the fastest route that has ever existed.
It stops in the second week.
The demo works. Then somebody asks who is allowed to see which rows. Then it needs to survive a restart halfway through a multi-step job. Then two people edit the same record. Then an auditor asks who changed the figure in March. Then it has to talk to the system next door, and be deployed somewhere, and keep working when the model that wrote it is a version newer and would write it differently.
None of that was the interesting part, and all of it is most of the work. A generated codebase comes with none of it, and the only way to audit one is to read it, which nobody does at the size it reaches by the second month.
Where your code belongs
Use Claude, use Codex, use whatever you write with. The question is what you are writing it for.
What you are not writing, ever again:
- a permission model, and the row-level and field-level rules on top of it
- a query engine, a semantic layer, or the caching in front of them
- a comment system, mentions, notifications and the delivery into Slack, Telegram and email
- an audit trail, and the discipline to keep it complete
- a workflow engine that survives a restart, with timers, retries and compensation
- an org structure with substitution, or a double-entry ledger, or a master-data store
- a deployment pipeline, a tenancy model, a login, a page renderer
That list is most of what a bespoke internal system costs, and none of it is the part anybody hired you to build.
What you do write is the thing that is yours: the calculation nobody else performs, the connector to the system only your industry has, the chart your analysts have been drawing by hand, the agent skill that encodes how your company decides something. Small, specific, and the part with the value in it.
And then you embed it. Your service sits behind a node in the automation palette; your chart type joins the ones the dashboards already draw; your skill becomes something the agents can use. From that point it is a brick like the others: reusable across every application, versioned with them, and inside the same permissions and the same audit trail as everything else. You write it once and use it everywhere, instead of pasting it into three systems and maintaining it in none.
What you build is repeatable. It deploys with the platform, connects without an integration project, and reaches data the way everything else does, so it passes the same security review.
What it comes to
It costs a fraction, in tokens, in hours and in money. Most of what a generated application consists of is not generated here at all. The permission model, the query engine, the process engine that survives a restart, the notification delivery, the audit trail, the deployment: none of that gets written once per application and paid for again on every regeneration. It is the platform. What the assistant produces is a description of what is specific to you, a short document rather than a codebase, and changing it is an edit, not another pass over a source tree that has grown since the last one.
And your applications are not a zoo. Ten vibe-coded tools are ten codebases, ten data models, ten opinions about what a customer is, and ten places to patch when the company changes something. Ten applications here share one org structure, one catalogue, one data model, one set of access rules and one audit trail. Each one adds to a single description of how your company works, so the eleventh is easier to build than the first was, and any of them can report on, or start work in, the others.
One approach accumulates artefacts. The other accumulates a company that knows itself. See Company knowledge base.
Next
AIpril vs BI - the same question asked about analytics: where a separate BI tool still wins, and where analysis belongs inside the work instead.