You buy a coding-agent subscription and get a working prototype. Then you buy another tool to fix the bugs, a reviewer to check the fixes, and an orchestrator to coordinate them.
Every tool reports progress. The application still cannot complete a critical workflow reliably. You spend another week prompting, rewriting, and upgrading plans. Your budget shrinks while the release remains out of reach.
This is a failure mode founders should take seriously: a development process that keeps generating activity without producing evidence that the product is ready.
By vibe coding here, I mean accepting generated implementation without enough understanding or verification to take responsibility for it. Used this way, it can become an expensive dead end.
More agents, higher bills
In its June 2025 account of building a multi-agent research system, Anthropic reported roughly 15 times the token use of ordinary chat interactions. That measurement concerns its research architecture, rather than a universal multiplier for coding bills. It illustrates why delegation has a resource cost.
Google Research’s January 2026 analysis found that multi-agent variants improved some parallelizable tasks, while degrading performance by 39–70% on the sequential reasoning tasks tested. More agents can mean more coordination overhead and less useful progress.
The documentation paradox
A mistake can acquire authority through repetition.
Consider this hypothetical chain in a booking application:
- An agent assumes that appointment conflicts can be prevented entirely in the frontend.
- It implements that assumption and documents the booking workflow as complete.
- A fresh agent reads the documentation and treats it as an established design decision.
- It builds rescheduling, payments, and notifications around that workflow.
- Tests reproduce the same assumption, and subsequent reviewers see apparently consistent code and documentation.
- Two customers submit requests for the same slot concurrently. Both receive confirmation, and several connected workflows now need correction.
The initial mistake has become a dependency. Consistency across the code, tests, and documentation makes it harder to notice because each appears to confirm the others. This example illustrates a possible failure mechanism, rather than a documented incident in a particular product.
Anthropic’s November 2025 engineering report documented related handover problems: agents inheriting incomplete work, guessing what happened, and declaring features complete without adequate end-to-end testing. Its remedies included incremental changes, progress records, version control, and testing the running application.
Documentation remains essential. Important statements in it need an evidence trail: an agreed requirement, a reproducible test, an observed result, or a reviewed decision. An agent-generated summary should not silently become proof of correctness.
The verification paradox
More checking can produce more confidence without testing the right thing.
A second agent can catch a bug. But if its review and tests inherit the same mistaken requirement, agreement does not establish that the requirement is correct.
In the same Google Research experiments, independent multi-agent systems showed 17.2-fold error amplification, compared with 4.4-fold amplification under centralized coordination. These are architecture-specific research findings, not failure rates for coding products. They demonstrate why validation and coordination need deliberate design.
For the booking example, an engineer must define the invariant—conflicting reservations must not both be confirmed—and verify it with competing requests against the actual data model. Depending on that model, the solution may require transactions, locking, database constraints, or a combination.
AI can implement those mechanisms and help test them. Someone still needs to establish what correctness means and whether the evidence is sufficient.
The spending paradox follows: more generated code creates more material to review, integrate, and maintain. Unless that work resolves validated requirements, a higher bill can buy a larger unfinished system.
What the construction analogy explains
Give an experienced builder a new tile-cutting machine and training on its operation, and they can combine it with skills they already have. Give the same machine to a lawyer with no building experience, and operating it successfully will not establish that they can construct a durable house.
The lawyer can learn. What they need is knowledge of materials, structural requirements, workmanship, and inspection. The machine does not supply all of that merely because it is easier to operate.
Software also requires learning. Formal education, self-directed study, mentorship, and real delivery can all contribute. An AI-generated interface tells you little about transaction integrity, permissions, migrations, or recovery after a failed deployment.
For a landing page, a disposable prototype, or a narrow internal tool, AI can be a practical starting point. Templates, website builders, and managed platforms already made many such projects accessible. The level of engineering should match the consequences of failure.
A product handling customer money, sensitive information, or business-critical operations needs evidence that its important failure modes have been addressed.
AI-generated code still needs engineering
In When AI builds itself, Anthropic reported that more than 80% of the code merged into its codebase in May 2026 was authored by Claude. It also described engineers directing and reviewing that work. That is one company’s reported experience, not a measure of the whole industry.
A revealing example is Nicholas Carlini’s compiler experiment. Sixteen Claude agents produced a 100,000-line C compiler over nearly 2,000 sessions, at approximately $20,000 in API costs.
Carlini described substantial work designing the tests, execution environment, and feedback mechanisms. When agents repeatedly collided with the same Linux compilation problem, he developed a different testing approach so they could isolate failures and make progress. He also documented limitations in the resulting compiler.
The project demonstrates substantial AI capability and the engineering needed to make autonomous work useful. It does not establish a typical budget for application development.
Experience must be demonstrated
In a June 2026 analysis of roughly 400,000 Claude Code sessions, Anthropic found that greater domain expertise was associated with more successful sessions. It also found that users outside software occupations could achieve coding-session success rates close to those of software professionals.
That evidence supports learning and understanding the problem. It does not support dismissing every non-programmer. The study measured sessions, rather than the long-term security, maintainability, or commercial success of the resulting products.
Twenty years spent launching, maintaining, and improving products can provide valuable knowledge: failed migrations, duplicate payments, unreliable integrations, incidents, and decisions that became expensive years later.
The value lies in applying that experience to the current system and continuing to learn as tools change. We cannot responsibly promise that AI will never replace a particular task or role. We can require evidence of competence today, regardless of how many years someone lists on a profile or which subscription they hold.
What business failures and copyright cases actually show
Builder.ai’s collapse is a real warning about promises of easy application development. Companies House records compulsory liquidation of its UK entity, Engineer.ai Global Limited, with winding up commencing on September 10, 2025. The record establishes insolvency; it does not establish that AI-generated code caused it.
Copyright consequences are real too. In Bartz v. Anthropic, a court granted final approval to a $1.5 billion settlement on July 20, 2026; the official documents include the approval order. The dispute involved copies of books obtained from pirate libraries. It was a model-provider settlement, rather than a fine against a developer for generated application code.
For product teams, these examples reinforce the need to evaluate business viability and review third-party code, assets, and licences. They do not justify predicting that every AI-built product will fail or receive a fine.
What hiring data does and does not tell us
Stanford’s August 2026 update found employment among 22–25-year-olds in highly AI-exposed occupations approximately 19% below the level implied by keeping pace with less-exposed peers. Experienced workers showed no comparable gap. The adjustment appeared mainly through reduced hiring, rather than increased separations.
The authors describe these as observational patterns, not a definitive causal estimate of AI’s effects. They do not establish that companies are firing only inexperienced or ineffective developers.
Individual announcements need the same care. In its July 6, 2026 statement about approximately 4,800 eliminated roles, Microsoft explicitly said those roles were not being replaced by AI. A layoff announcement alone cannot establish somebody’s competence.
Can your team take responsibility for the product?
If the development agent becomes unavailable tomorrow, can another engineer obtain the repository, build the application, investigate a defect, deploy a fix, and restore the data without reconstructing months of chat history?
An AI feature inside the product may still depend on a model provider at runtime. That dependency needs an explicit budget, failure behaviour, and continuity plan. It is separate from using AI to help write the application.
Tool choices and expenses should be agreed with the client. A delivery partner remains responsible for the agreed result; an expired development subscription should not become an explanation for why nobody can maintain the software.
At Kavita Systems, our recommendation is to evaluate a team through architecture it can explain, critical workflows it can test, systems it can recover, and software it can hand over.
Ask for a demonstrated permission boundary, a payment-retry test, a tested backup restoration, reproducible deployment instructions, and a clear account of third-party dependencies and licences.
The shift we advocate is to buy demonstrated product readiness, with accountable engineering behind it. AI can contribute enormously to that work. The team must be able to establish when it has succeeded.
Top comments (0)