Apps onderhouden die met AI zijn gebouwd: wat niemand je vertelt over week twee

Het eerste weekend met Proyecta lanceer je iets echts. Het werkt. Je gebruikers (of je team, of je toekomstige zelf) beginnen het te gebruiken. En dan is het maandag en mailt een klant: “Kun je een dropdown toevoegen om op regio te filteren?”

Welkom bij onderhoud. Dit is het deel van het bouwen van een AI-app waar niemand over praat, en het deel waar de meeste projecten óf een langlopend bezit worden óf stilletjes van een klif vallen. Het goede nieuws is dat een met AI gebouwde app onderhouden een andere ervaring is dan traditionele code onderhouden. Het eerlijke nieuws is dat “anders” niet “gratis” betekent.

Wat onderhoud echt betekent

Wanneer professionele ontwikkelaars “onderhoud” zeggen, bedoelen ze min of meer vier dingen:

Kleine functies toevoegen waar mensen na de lancering om vragen.
Dingen repareren die braken of vanaf het begin verkeerd waren.
Bijblijven met veranderingen buiten je app — een betalingsprovider werkt zijn API bij, een nieuwe browser komt uit, je datavorm verandert.
Opruimen zodat de codebase niet langzaam in een moeras verandert.

Voor een met AI gebouwde app gebeuren alle vier nog steeds. Wat verandert, is wie ze doet en hoe het werk voelt.

Het goede nieuws: je kunt ermee praten

Hier is het deel dat niemand je vertelde toen je code aan het kopiëren-en-plakken was uit oude tutorials. Met een AI-appbouwer onderhoud je de app op dezelfde manier als je hem bouwde: door te beschrijven wat je wilt.

Een echt voorbeeld. Een oprichter die we kennen bouwde een klein CRM voor haar coachingpraktijk — klanten, sessies, betalingsregistratie, de hele mikmak. Drie weken na de lancering zei een klant dat ze graag zou zien hoeveel sessies ze dat jaar hadden gedaan. Ze opende de app, zei: “Voeg een ‘sessies dit jaar’-teller toe aan elke klantkaart, die put uit de sessietabel waar de datum in 2026 valt.” Twaalf minuten later stond het live. Ze was terug aan het coachen.

Dat verhaal klinkt normaal totdat je je het alternatief herinnert: een freelancer benaderen, twee dagen wachten, $300 betalen, een PR beoordelen die ze niet helemaal begreep, en bidden dat er niets anders brak. De onderhoudslus is niet sneller omdat de AI slimmer is dan de freelancer. Hij is sneller omdat de lus minder mensen erin heeft.

Het moeilijkere nieuws: kleine dingen stapelen op

Hier is het deel dat mensen overrompelt. Met AI gebouwde apps lijken makkelijk te veranderen omdat dingen toevoegen makkelijk is. Wat niet makkelijk is, is het hele ding coherent houden naarmate het groeit.

Een paar patronen die we mis zien gaan:

De toevallige knoop. Je vraagt om “voeg een kortingsveld toe aan de checkout”. Zes revisies later leeft de kortingslogica op drie plekken, en slechts een ervan is juist. Er is nog niets gebroken, maar de volgende wijziging gaat verwarrend worden.
De vergeten eis. Je voegde “gratis verzending boven $50” toe in maart. In mei vraag je de AI om “de checkout opnieuw te doen om cadeaubonnen te ondersteunen”. Hij doet het. De gratis-verzendregel is weg. Niemand merkte het twee weken lang.
De drift. Je app begon als “een tool voor mij”. Hij wordt nu door je team gebruikt. Het mentale model waar de AI vanuit werkt, is nog steeds “voor mij”, want dat is wat je oorspronkelijk zei. Nieuwe functies voelen vreemd af, en je kunt de vinger er niet op leggen.

Geen van deze zijn falen van AI-appbouwers. Het zijn falen van geheugen en gedeelde context — dezelfde problemen die een team van menselijke ontwikkelaars heeft, alleen in een andere vorm.

Hoe je jezelf inricht

De teams die het goed doen met onderhoud delen een paar gewoonten. Het zijn meestal geen technische gewoonten. Het zijn gewoonten over hoe je beschrijft wat je app is en wat er veranderde.

Houd een “wat deze app is”-document bij. Eén pagina. Het publiek, de doelen, de regels (“gratis verzending boven $50”, “we mailen gebruikers nooit op zondag”, “telefoon is de primaire sleutel, niet e-mail”). Wanneer je de AI vraagt iets te veranderen, plak de relevante regel in de prompt. Je omzeilt de intelligentie van de AI niet; je voedt hem de context die hij onmogelijk kan onthouden.

Beschrijf wijzigingen in termen van gedrag, niet code. “Ik wil dat gebruikers hun regiofilter onthouden zien tussen sessies” is een veel beter verzoek dan “voeg localStorage toe aan het filter”. Het eerste beschrijft wat je wilt; het tweede schrijft een van de vijftien manieren voor om het te doen, en waarschijnlijk niet de beste.

Maak wijzigingen één voor één. Twee wijzigingen in één prompt betekent dat er een stilletjes kan falen en je weet niet welke. De snelste manier om een AI-app te onderhouden is je iteraties klein genoeg houden dat je in één oogopslag kunt zien of het resultaat juist is.

Kijk naar wat er veranderde. De meeste AI-appbouwers tonen je een preview. Gebruik hem. De dertig seconden die je besteedt aan rondklikken om te bevestigen dat de nieuwe functie werkt en de oude functies nog steeds werken, is de goedkoopste verzekering die je dit jaar koopt.

Wat je niet kunt doen (en waarschijnlijk niet zou moeten)

Er is een verleiding, zodra je een app met AI hebt gebouwd, om te denken dat hij de app ook voor je kan bedienen. Dat kan niet, en het gat is echt:

Hij vertelt je niet wanneer er iets stilletjes brak. Logs, monitoring, oproeproosters — die zijn nog steeds een aparte zorg. De meeste AI-appbouwers houden je productie-app niet in de gaten zoals een backend-engineer zou doen.
Hij weet niets over de wereld buiten je app. Als een betalingsprovider een API uitfaseert, weet de AI dat niet totdat je het hem vertelt. Abonneer je op de changelogs van je providers. Lees je e-mail.
Hij kan geen productbeslissingen voor je maken. Of je een functie toevoegt, welke afweging je maakt, wat je gebruikers echt willen — dat blijf jij. De AI is een heel snel paar handen; het brein is van jou.

Het realistische plaatje

Na zes maanden met een met AI gebouwde app belanden de meeste mensen waarmee we praten ergens als dit: ze besteden misschien twee tot vier uur per maand aan wijzigingen, bijna allemaal conversationeel. De grote herbouwen waar ze vroeger tegenop zagen — “ik wil een hele nieuwe sectie toevoegen” — voelen als één goede middag. Het saaie spul — “het datumformaat is verkeerd op de export” — voelt als één goede prompt.

Wat ze niet hebben, is de constante achtergrondruis van een traditionele codebase: dependency-updates, frameworkmigraties, beveiligingspatches, buildconfiguraties. Die ruis is geabsorbeerd in het platform. Je betaalt het platform om het af te handelen, wat een veel betere deal is dan een ontwikkelaar betalen om het af te handelen.

Als je op het punt staat je eerste app te bouwen, is de post over wat je eerste met AI gebouwde app zou moeten zijn het lezen waard voordat je begint. En als je al een paar weken bezig bent en wat van de patronen hierboven voelt, is dat normaal. Schrijf dit weekend je “wat deze app is”-document. Toekomstige-jij, drie maanden van nu, die om een nieuw dashboard vraagt, zal er erg blij mee zijn.