Waarom jouw vibe-gecodeerde app het niet doet

Je beschreef wat je wilde in gewone taal en een AI schreef het. De app zag er goed uit in de preview en je lanceerde hem tevreden. Nu is er iets kapot en weet je niet eens waar je moet beginnen te zoeken.

Dit is de vibe coding kloof, en die overvalt veel mensen. De tools die code genereren vanuit prompts zijn echt indrukwekkend geworden. Maar indrukwekkend uitziende output en productieklare code zijn twee verschillende dingen.

Deze gids legt de meest voorkomende redenen uit waarom vibe-gecodeerde apps vastlopen. Het is niet geschreven om je te ontmoedigen AI-tools te gebruiken. Het is geschreven om je te helpen begrijpen wat er misgaat en wat het werkelijk oplost.

Wat vibe coding is

Vibe coding is software bouwen door in gewone taal te beschrijven wat je wilt. Je typt een prompt, de AI genereert de code en je voert hem uit. Tools zoals Cursor, v0, Bolt en GitHub Copilot hebben dit echt snel gemaakt.

Voor prototypes en vroege experimenten werkt het verrassend goed. Je gaat van idee naar iets klikbaars in uren in plaats van weken. Die snelheid is echt en verandert hoe mensen ideeën testen.

Het probleem verschijnt wanneer je van prototype naar iets gaat dat mensen echt gebruiken. De AI genereert code die de prompt bevredigt, niet code die doordacht is. Een prompt bevredigen en iets solide bouwen zijn niet hetzelfde.

Het hallucinatieprobleem

AI-modellen genereren soms code die verwijst naar functies of pakketten die niet bestaan. Dit heet hallucination, en het gebeurt vaker dan mensen verwachten. De code ziet er correct uit, draait prima in één omgeving en crasht in een andere.

Gehallucineerde afhankelijkheden zijn een veelvoorkomende schuldige wanneer een vibe-gecodeerde app breekt op echte apparaten. Een pakket dat de AI vol vertrouwen importeerde was verouderd, hernoemd of nooit echt. Je ontdekt het pas wanneer de app het probeert te laden en een fout krijgt.

De oplossing is niet voor de hand liggend als je de code niet zelf hebt geschreven. Dat vereist begrijpen wat de code probeert te doen, niet alleen wat hij zegt. Iemand moet de importketen traceren, de slechte verwijzing vinden en vervangen.

Geen foutafhandeling

Vibe-gecodeerde apps hebben vaak geen plan voor wanneer dingen misgaan. Eén onverwachte actie van een gebruiker en het valt om. Dit is omdat de prompt succes beschreef, niet mislukking.

Foutafhandeling is de code die bepaalt wat er gebeurt wanneer een API-aanroep mislukt. Het draait wanneer een formulier leeg wordt ingediend of een netwerkverzoek een time-out krijgt. AI-gegenereerde code slaat dit vaak volledig over tenzij je er specifiek om vroeg.

In productie gaan dingen voortdurend op kleine manieren mis. Een gebruiker heeft een trage verbinding. Een externe dienst geeft een onverwachte reactie terug. Een app zonder foutafhandeling maakt elk klein probleem tot een zichtbare crash.

State management breekt bij echt gebruik

State is de live data die je app bijhoudt terwijl hij draait. Welk scherm de gebruiker op zit, wat ze hebben getypt, of ze ingelogd zijn. State correct beheren is een van de moeilijkere onderdelen van het bouwen van een app.

Vibe-gecodeerde apps beheren state vaak op een manier die breekt met meerdere gebruikers. Voeg twee gebruikers toe, of laat één gebruiker twee dingen tegelijk doen, en het breekt. Race conditions, verouderde data en onverwachte re-renders zijn allemaal state management-fouten.

Deze bugs zijn notoir moeilijk te reproduceren omdat ze afhankelijk zijn van timing en volgorde. Je klikt iets, wacht een halve seconde, klikt iets anders en de app crasht. De AI had geen concept van die volgorde toen hij de code schreef.

Beveiligingsgaten

Dit is het onderdeel waar de meeste mensen niet over nadenken totdat er iets misgaat. Vibe-gecodeerde apps lekken regelmatig API-sleutels, slaan authenticatiecontroles over en vertrouwen gebruikersinvoer. De AI werd niet gevraagd over beveiliging na te denken, dus deed hij dat niet.

Een blootgestelde API-sleutel in een mobiele app is geen klein probleem. Iedereen die de app decompileert kan hem vinden en gebruiken. Als die sleutel facturering eraan heeft, kom je het op de harde manier te weten.

Gebruikerstekst direct doorgeven aan een databasequery zonder het eerst te controleren is een kwetsbaarheid. SQL-injectie en vergelijkbare aanvallen misbruiken precies dit soort snelkoppelingen. Code die beveiliging overslaat is geen prototype. Het is een aansprakelijkheid.

Het werkt op jouw machine maar niet op die van hen

Dit is een van de meest frustrerende vibe coding storingen. Het draait prima op jouw laptop en crasht op een andere telefoon of browser. De oorzaak is bijna altijd een omgevingsaanname die stil in de gegenereerde code is ingebakken.

AI-modellen genereren code op basis van patronen die ze leerden tijdens training. Die patronen nemen vaak een specifiek besturingssysteem, schermgrootte of API-versie aan. Geen van die aannames staat ergens in de code vermeld.

Een prestatie-optimalisatie pass op een vibe-gecodeerde app onthult deze aannames regelmatig. De app werd nooit getest op iets anders dan de machine van de ontwikkelaar. Echte gebruikers hebben oudere telefoons, tragere verbindingen en verschillende besturingssysteemversies.

Het contextvensterprobleem

Elke AI-sessie heeft een contextvenster, het stuk code dat het in gedachten houdt. Voor kleine apps is dit prima. Voor alles met echte complexiteit wordt het een probleem.

Dit creëert een situatie genaamd context drift. De code geschreven in sessie tien spreekt de code van sessie twee tegen. Niemand vangt het op omdat niemand het zorgvuldig las.

Je eindigt met een codebase die groeide door accumulatie in plaats van ontwerp. Het werkt in stukken. Elk stuk conflicteert licht met de stukken eromheen. Debuggen van zo'n codebase is echt pijnlijk omdat de problemen structureel zijn.

Wat het werkelijk oplost

Het goede nieuws is dat de meeste vibe-gecodeerde apps te repareren zijn. Het slechte nieuws is dat correct repareren vereist dat je de code leest en begrijpt. Dat is het deel dat de oorspronkelijke prompt niet voor je kon doen.

Bug fixing op een vibe-gecodeerde app begint met een doorlezen van de hele codebase. Niet om hem te herschrijven, maar om te begrijpen welke beslissingen de problemen veroorzaken. De meeste apps hebben drie of vier hoofdoorzaken achter een lange lijst van oppervlaktesymptomen.

Los de hoofdoorzaken op en de meeste symptomen verdwijnen. Herschrijf alleen de secties die niet gepatcht kunnen worden zonder de rest erger te maken. Die aanpak is sneller en goedkoper dan helemaal opnieuw beginnen.

Wanneer herbouwen

Sommige vibe-gecodeerde apps zijn te ver heen om te patchen. State management is verstrengeld, beveiligingsgaten zijn structureel en afhankelijkheden zijn een puinhoop. Op dat punt is herbouwen op een schoon fundament het snellere pad.

Een technische architectuur review vertelt je in welke situatie je zit voor de kosten groeien. Het kijkt naar de structuur en vertelt je wat salvageable is en wat niet. Dat antwoord bepaalt de tijdlijn, kosten en aanpak voor enig werk begint.

Een goede MVP bouwen vanaf het begin vermijdt de meeste van deze problemen. Het doel is hetzelfde als vibe coding: snel bewegen en het idee testen. Het verschil is dat de code standhoudt wanneer echte gebruikers aankomen.

Waarom dit ons interesseert

Bij Techneth zien we vibe-gecodeerde apps regelmatig omdat mensen naar ons komen wanneer ze breken. Het patroon is consistent: het werkte in de demo, het werkt niet voor gebruikers. Meestal is het idee goed en heeft de uitvoering een engineering-pass nodig.

We doen mobiele app-ontwikkeling van nul en repareren apps die op een andere manier zijn gebouwd. Beide hebben hetzelfde nodig: iemand die de code leest en begrijpt wat die doet. AI-gegenereerde code is gewoon code. Het heeft dezelfde problemen als alle code.

Als jouw vibe-gecodeerde app kapot is of bijna werkt maar niet helemaal, is het oplosbaar. Breng hem naar ons en we vertellen je wat hij nodig heeft. Gewoon een duidelijk beeld van wat er mis is en hoe het repareren eruitziet.

Klaar om jouw vibe-gecodeerde app te repareren?

Praat met Techneth over mobiele app-ontwikkeling goed gedaan, of breng je kapotte app naar ons voor een bug fix en troubleshooting sessie.

Ook relevant: Technische Architectuur Review | App Redesign en Modernisering | Onderhoud en Support

FAQ

Wat is vibe coding?

Vibe coding is beschrijven wat je wilt aan een AI-tool in gewone taal. De AI schrijft de code op basis van jouw beschrijving en jij voert hem uit of implementeert hem. Het is snel voor prototypes maar heeft vaak verborgen gaten die opduiken bij echt gebruik.

Waarom breken vibe-gecodeerde apps wanneer echte gebruikers ze proberen?

De meest voorkomende problemen zijn ontbrekende foutafhandeling, blootgestelde beveiligingsgaten en kwetsbaar state management. Apps breken ook omdat AI-code omgevingsaannames maakt die falen op echte apparaten. Dit zijn tekenen dat de code een engineering review nodig heeft, niet dat het idee verkeerd is.

Kan een vibe-gecodeerde app gerepareerd worden of heeft het een volledige herbouw nodig?

Soms ja, soms nee. Een doorlezen van de codebase geeft het antwoord. Apps met structurele problemen in de architectuur hebben gewoonlijk een herbouw nodig. Apps met oplosbare bugs en een goede onderliggende structuur kunnen worden gepatcht zonder opnieuw te beginnen.

Hoe vermijd ik deze problemen bij het gebruik van AI om code te schrijven?

Vraag de AI specifiek om foutafhandeling, invoervalidatie en beveiliging bij elke functie. Test op echte apparaten, niet alleen op jouw eigen machine, voor je het aan iemand laat zien. Behandel AI-gegenereerde code als een eerste concept dat beoordeling nodig heeft, geen afgewerkt product.

Wat is code hallucination?

Code hallucination betekent dat de AI verwees naar functies, pakketten of API's die niet bestaan. De code ziet er goed uit maar mislukt tijdens runtime omdat het iets aanroept dat er niet is. Het is lastig omdat de foutmelding zelden naar de werkelijke oorzaak wijst.