Een idee voor een app hoefde nog nooit zo kort op de plank te liggen. Tools als Lovable, Bolt en Replit vertalen een beschrijving in gewone taal naar schermen, formulieren en een database erachter. Wie helder kan uitleggen wat een applicatie moet doen, heeft binnen een middag iets dat je kunt aanklikken en aan collega’s kunt laten zien.
Voor jou als beslisser is dat goed nieuws met een kanttekening. Zodra zo’n zelfgebouwde app de organisatie in wil, verschuift de vraag van “werkt het?” naar “kunnen we hierop vertrouwen?”. Die twee vragen hebben minder met elkaar te maken dan de demo doet vermoeden.
Wat je zonder programmeerkennis voor elkaar krijgt
Het sterkste gebruik van deze tools is verkennen. Een klikbaar prototype maakt in één dag duidelijk of een flow logisch is, collega’s kunnen ermee spelen en de discussie gaat niet langer over een document maar over iets dat bestaat. Ook een demo voor een klantgesprek of een wegwerptool die één klus moet klaren, is langs deze weg sneller gemaakt dan ooit.
De kwaliteit van de uitkomst hangt vooral af van de kwaliteit van je vraag. Een scherpe omschrijving van wie de app gebruikt en welk probleem hij oplost, levert een bruikbaar prototype op; een vage opdracht levert een vaag prototype. Klein beginnen en per stap uitbreiden werkt beter dan alles in één keer laten genereren.
De grens ligt bij serieus gebruik
AI-tools optimaliseren op werkende output, niet op veiligheid of houdbaarheid. Inloggen, gebruikersrechten en de omgang met persoonsgegevens vragen bewuste keuzes die geen tool uit zichzelf maakt; de AVG stelt daar sinds 2018 wettelijke eisen aan. De gegenereerde code mist bovendien vaak een doordachte structuur, waardoor elke volgende aanpassing zwaarder wordt dan de vorige. Een prototype dat vlot draait voor vijf collega’s, kan bij groei alsnog vastlopen.
Trek de grens daarom vooraf. Een AI-gegenereerde app hoort niet in productie zodra een van deze punten speelt:
- er gaan klantgegevens of andere persoonsgegevens doorheen;
- meerdere mensen krijgen verschillende rechten in het systeem;
- een bedrijfskritisch proces gaat ervan afhangen;
- de app moet gegevens uitwisselen met je bestaande systemen.
Voor verkennen en testen is geen van deze punten een bezwaar. Voor dagelijks gebruik zijn ze dat stuk voor stuk.
Je bestaande systemen zijn de lakmoesproef
Vooral dat laatste punt wordt onderschat. Een app staat in een organisatie zelden op zichzelf: klanten staan in het CRM, orders in het ERP, uren in de planning. Een prototype met een eigen database wordt zo een eiland, waar kopieën van bestaande gegevens langzaam gaan afwijken van de bron. Handmatig overtypen houdt niemand vol, en juist in het verkeer tussen systemen luistert veiligheid nauw.
Hier houdt de doe-het-zelfroute op. Betrouwbare koppelingen tussen systemen vragen kennis van beide kanten: van de app en van het systeem waarmee hij praat, inclusief wat er moet gebeuren als een van de twee er midden in een uitwisseling mee stopt. Dat soort randgevallen vangt een taalmodel niet vanzelf af; een engineer wel.
AI als gereedschap werkt, AI als eindproduct niet
We schrijven dit niet vanaf de zijlijn. We werken zelf AI-assisted: AI genereert code, iemand met vakkennis beoordeelt, test en tekent ervoor. Zo halen we de snelheid binnen zonder de kwaliteit aan het toeval over te laten. Pure vibe coding, waarbij niemand met verstand van software meekijkt, levert dat vertrouwen niet op; het verschil tussen die twee werkwijzen is het verschil tussen een prototype en een product.
Is je prototype inmiddels serieus geworden? Gooi het dan niet weg: het is een uitstekende beschrijving van wat de software moet doen. Wij maken er een applicatie van die veilig, gekoppeld en te onderhouden is, en nemen daarna desgewenst de doorontwikkeling en het beheer op ons. Stuur het prototype mee met je bericht; dan hebben we meteen iets concreets om over te praten.