Fixes / Vibe Coding
Vibe coding got you to a demo. Now it has to hold up.
I don’t throw the code away. I find what’s actually risky, fix that, and tell you honestly what’s fine as it is.
Does this sound like you?
- “I vibe-coded the MVP. It demos beautifully. I have customers waiting and nobody making sure the production version won’t embarrass me.”
- “The freelancer who built it with AI is gone. It works for the happy path. I can’t extend it or debug it.”
- “My team built this in a sprint with Cursor or Claude Code. It’s business-critical now, and keeping it alive is a part-time job for the wrong people.”
What I’d do.
Read the actual code, not the demo.
I audit what’s there before deciding anything: security boundaries, structure, load paths, the parts nobody’s touched since the AI wrote them.
Tell you what’s actually risky, not everything.
A written diagnosis: what needs fixing before real customers touch it, and what’s genuinely fine to leave alone.
Fix what’s risky, keep what works.
Most of the time this is hardening, not a rewrite. You keep the documentation and a runbook. Who owns what is agreed in writing before any work starts, so nobody has to guess later.
Five places it actually breaks.
Security
API keys in the frontend bundle, secrets in git history, endpoints with no auth check. Automated scanners find a public AI-built app within days. I built and still run Authentikor, a live cybersecurity platform, so I know what a real security review looks like from both sides.
Structure
Every change creates two new bugs because nothing has a clear boundary. This is the same shape of problem I rebuilt for Mr Porky’s WooCommerce store: front end and logic tangled together with no update-safe seams.
Scaling
Light use is fine. Real load surfaces race conditions and missing indexes the demo never exercised. My own production proof at scale is the recycling POS: 7 branches, 350 employees, 5,000 transactions a day, built and running since 2022.
Maintenance
Every change gets more fragile because nobody trusts the code enough to extend it safely. BX1X is my counter-proof: 37+ production modules, still growing, without that kind of drift.
Support
The original AI session is gone. Whoever picks it up next can’t orient. Authentikor, a cybersecurity platform I built and still run, is the standard I hold hardening work to: documented, auditable, supportable by someone who isn’t me.
Proof.
How it starts.
A paid assessment: I read the code, give you a written diagnosis, and tell you which of hardening, partial rewrite or full rebuild is actually cheapest. You keep the diagnosis whether or not you book the fix.
For your technical person
The hardening sprint
The existing AI-built code is not thrown away. It is audited, restructured where needed, and given the missing scaffolding: tests, types, deployment, monitoring, secrets handling.
- Assessment: paid, written architecture diagnosis returned within a week.
- Diagnosis: which failure modes are present, how severe, what to fix first.
- Fix path: hardening, partial rewrite, or full rebuild, with a cost shape for each.
- Hardening sprint: the work itself, scoped to the named outcome.
- Documented handover: the docs, the runbook, and code ownership agreed in writing.
Pro-AI. Governance-first.
I use AI heavily and audit everything it produces. The SEO AI Toolbox on this site runs on deterministic eval gates before any article publishes. The same engineer who reviews your AI-built prototype designed those controls.
Questions owners ask.
Is vibe coding bad?
No. It is great for prototypes. It becomes a problem the moment the prototype starts taking real customer money or storing real customer data.
Does the existing code stay, or do you rewrite it?
Usually it stays. The hardening sprint audits the existing code, restructures the parts that fight every change, and adds the scaffolding the AI did not write. The goal is to keep what works.
Will I have to rewrite from scratch?
Sometimes. The assessment tells you which path is cheaper. Usually it is hardening, not rewrite.
Who owns the code afterwards?
Who owns what is agreed in writing before any work starts, so nobody has to guess later. Documented handover is part of the engagement.
Is this a long retainer?
No. Each hardening sprint is scoped to a named outcome with a defined end.
What if my prototype was built by an in-house person, not a vendor?
Same engagement, same approach. The audit does not blame; it produces a path forward.
Related help.
Tell me what your prototype does and where it is breaking.
+27 87 150 9305Monday to Friday, 09:00 to 20:00 SAST. Or email info@antondevilliers.com.