The 2026 content cycle loves the cheap V1: an internal tool generated in an afternoon, demoed on Friday, adopted by a whole team the week after. That story is real, and it is only chapter one. The bill that decides whether the tool was a good idea arrives in year two, when the tool is load-bearing, the person who prompted it has changed roles, and the stack underneath it has aged twelve months. Almost nobody prices that second year, so this piece does, as cost categories and typical patterns, not invented ledgers. Plug in your own hours and rates; the structure is the point.
Why is the AI-generated V1 so cheap, and why does that mislead your budget?
The V1 is cheap because generation collapses the cost of typing code, which was never the expensive part of software. Requirements, integration, security, and long-term ownership were, and generation defers those costs rather than deleting them. A budget anchored on the V1 price will systematically underestimate the tool's lifetime cost.
Two dynamics make the anchoring worse. First, because building is nearly free, teams build more: one clever ops tool becomes eleven, and the maintenance surface multiplies while the maintenance capacity does not, the pattern we unpack in Internal Tool Sprawl Is the New SaaS Sprawl. Second, the V1 usually skips exactly the work that keeps year two cheap: tests, review, dependency curation, documentation. As we argued in Vibe Coding Is Not Engineering: The 2026 Reckoning, the artifact looks finished long before it is engineered. The cost did not disappear; it moved to a later quarter and gained interest.
What does maintenance look like for vibe-coded logic nobody reviewed?
Expect a steady stream of small breakages: edge cases the generator never considered, silent data issues from loose validation, and behavior that shifts when someone regenerates a function instead of editing it. Maintaining unreviewed AI code typically starts with re-deriving intent, you are reverse-engineering your own tool before you can fix it.
Typical patterns in generated codebases:
- ▸Duplicated logic that drifts. The same business rule implemented three ways in three files; a fix lands in one and the others quietly disagree.
- ▸Inconsistent error handling. Some paths throw, some return nulls, some swallow errors entirely, so failures surface far from their cause.
- ▸Hidden data-shape assumptions. The tool worked on the sample it was built against and breaks on the first export with a renamed column.
- ▸Regeneration as repair. Asking the model to rewrite a module fixes the reported bug and silently changes three behaviors nobody re-tested.
None of this is exotic, it is ordinary technical debt, accumulating at generation speed. The Technical Debt Time Bomb of AI-Written Code covers why the compounding runs faster than with human-written shortcuts.
How do you patch security issues in code nobody wrote?
Security has two layers here. Dependency vulnerabilities are patchable with normal tooling, scanners, lockfiles, upgrade pull requests. Flaws in the generated logic itself appear on no advisory feed: injection-prone string building, missing authorization checks, secrets committed to the repository. Finding those takes a human-led review, not a scanner alone.
Internal tools get a dangerous discount on scrutiny because they sit behind the VPN or SSO and are considered safe by location. Auditors consistently disagree: the highest-privilege, least-reviewed code in a company is usually an internal panel, which is why we wrote What Security Auditors Find in Admin Panels. Public analyses of AI-generated code have repeatedly reported high rates of classic OWASP-category flaws in unreviewed output; treat the exact percentages with caution and verify against scans of your own repositories, but treat the direction as settled. Budget a real review pass for any generated tool that touches customer data or money, our remediation playbook for vibe-coded repos is a usable starting order.
What is dependency rot, and why does it hit generated tools harder?
Dependency rot is the widening gap between the versions your tool was generated against and the versions the ecosystem still supports. Generated projects typically start heavier than a careful engineer would build, more packages, sometimes outdated pins, so the gap opens faster, and a security advisory eventually forces an upgrade on the codebase you understand least.
The mechanics are mundane: framework majors ship, transitive dependencies pick up CVEs, an API the model learned from its training data gets deprecated. What makes the rot expensive is that upgrades in an untested codebase are blind, without tests, you learn what broke from your users. There is also a supply-chain edge: models occasionally suggest packages that are obsolete or that never existed at all, a vector we cover in Supply-Chain Attacks 2.0: Hallucinated Packages and Poisoned Models. A quarterly upgrade window with a smoke-test checklist is cheap insurance; discovering rot during an incident is not.
Who fixes the tool when the prompt author leaves?
The bus factor of a vibe-coded tool is usually one, and the one is not exactly a person, it is their chat history. When intent lives in prompt sessions instead of commits, tests, and a README, the successor rebuilds understanding from raw generated output, which commonly costs more than the original build did.
Cheap mitigations, best applied while the author is still around:
- ▸Archive the prompts. The conversation that produced the tool is the closest thing it has to a design document; store it next to the code.
- ▸Write the one-pager. What the tool does, for whom, its data sources, its deploy path, and its known sharp edges.
- ▸Let tests carry intent. Even a dozen end-to-end assertions turn folklore into an executable spec.
- ▸Name an owner. A tool with no name against it in the registry is already abandoned; the incident simply has not happened yet.
When is rework cheaper than repair?
Rework wins when the cost of understanding the old code exceeds the cost of restating the requirements. If the tool's behavior fits on a page and its data exports cleanly, rebuilding against that spec, with review, tests, and CI this time, is often cheaper than archaeological patching of the original.
Signals that you have crossed the line: fixes routinely cause regressions elsewhere; nobody will deploy on a Friday; closing the dependency gap needs a migration guide older than the tool itself. The trap is rebuilding with the same process, a second disposable V1 buys you the same year-two bill with a new start date. The rebuild is exactly the moment to add the discipline the first version skipped; How to Turn a Prototype Into a Production-Ready Product describes that hardening pass. And if the tool exists to replace a SaaS subscription, size the rebuild inside a real migration plan, see Escaping SaaS: The Complete Guide to Migrating to Custom Software, rather than as another weekend artifact.
How do you budget year two honestly?
Budget by category, not by gut: routine fixes, security review and patching, dependency upgrades, infrastructure and access management, knowledge continuity, and a rework reserve. We deliberately publish the categories rather than a fake ledger, plug in your own hours and rates, then re-measure quarterly. The structure transfers; the numbers must be yours.
A workable method: for each tool, estimate hours per quarter in each category, multiply by a loaded engineering rate, and add your infrastructure invoices. Then compare the total against what the tool actually saves or earns, the same honest-ledger exercise we apply to full products in Custom Software Is Also a Subscription, to Yourself. Two hedged patterns worth knowing: teams commonly find that a portfolio of generated tools costs more to keep than any single tool suggests, because context-switching across eleven small codebases is expensive; and the tools worth keeping usually justify promotion onto a standard stack, the architecture step we describe in Nine AI Internal Tools Worth Building, and the Architectures That Keep Them Cheap.
How TuniCyberLabs helps
We take over AI-generated internal tools the way you would want your own team to: a security and dependency triage first, then tests around current behavior, then CI, then a maintenance retainer with the year-two categories priced explicitly, or a written verdict that a rebuild is cheaper, argued with the method above. If a generated tool has become load-bearing, we can harden it into a real product.
Got a generated tool the whole team now depends on? Talk to an engineer before the year-two bill writes itself.