Wanneer iedereen opgaat in de hype, focus jij op de basis.

Mocht het je ontgaan zijn: AI is hot. En begrijp me niet verkeerd, dat is volkomen terecht. Het is de grootste technologische vooruitgang sinds het world wide web en wereldwijde connectiviteit. We geven honderden euro's uit aan AI-tools, en dat zullen we blijven doen.

Echter, wanneer je enthousiast wordt van alle wekelijkse nieuwe releases, moet je de basis niet uit het oog verliezen. Zeker niet in softwareontwikkeling. Dit is waar bureaus, zoals We Do Dev Work, het verschil kunnen maken.

Dankzij AI kunnen we sneller applicaties bouwen met functies die tien jaar geleden ondenkbaar waren. Maar hoe gebruiken we AI om oplossingen te bouwen die blijvend, schaalbaar, veilig en gebruiksvriendelijk zijn?

Het is niet omdat je het kunt bouwen, dat je het ook moet bouwen

Voordat je ook maar één regel code schrijft, moet je een stap terug doen en de essentiële vragen stellen: Wat bouwen we? Waarom bouwen we het? Voor wie bouwen we het?

Dezelfde principes die softwareontwikkeling al decennia lang sturen, zijn vandaag de dag nog steeds van kracht. Specificaties en planning blijven cruciaal; we kunnen ze nu gedetailleerder dan ooit opstellen en verfijnen, dankzij die nieuwe AI-tools.

Voor SaaS-producten moet elke nieuwe functie de algemene strategie en langetermijnvisie versterken, en niet alleen een gat op de korte termijn dichten. Zorg er bij volledig nieuwe producten voor dat wat je bouwt nuttig en origineel is, en iets waar je echt in gelooft.

Want het schrijven van code is slechts de helft van de reis. De andere helft is alles wat volgt: marketing, distributie, hosting, schaling en onderhoud op de lange termijn. AI kan de ontwikkeling versnellen, maar de fundamenten van het bouwen van duurzame producten zijn niet veranderd.

Begin bij je database, begrijp de bewegende delen

AI kan een waardevolle copiloot zijn bij het ontwerpen van een database: het kan velden suggereren die je over het hoofd hebt gezien, ontbrekende relaties aanstippen of je zelfs helpen bij het instellen van de juiste Row Level Security (RLS) policies (in Supabase, uiteraard).

Maar voordat je Cursor, Lovable of een andere tool opent, moet je zelf je datamodel begrijpen. Hoe zijn je tabellen gerelateerd? Wat is de oorsprong van je data? Hoe communiceren deze onderdelen binnen je applicatie? Zonder dat fundament zal zelfs het beste door AI gegenereerde schema falen.

Een slecht ontworpen database vertraagt je niet alleen, het creëert technische schuld nog voordat je applicatie gelanceerd is. Zorg dat de structuur vroegtijdig goed staat, en alles in je product zal daarvan profiteren.

Beveiliging is geen 'nice to have'

AI is ontspoord op manieren die we ons nooit hadden kunnen voorstellen. Elon Musk's Grok-chatbot lekte een enorme dataset van meer dan 300.000 privégesprekken, met gevoelige informatie waaronder medische vragen en zelfs wachtwoorden. Dit gebeurde omdat de "deel"-functie publiekelijk indexeerbare URL's genereerde die zoekmachines oppikten zonder de gebruikers te waarschuwen. Lees er hier meer over: https://www.bbc.com/news/articles/cdrkmk00jy0o

Aan de andere kant zien we ook nog steeds incidenten van volledig vermijdbare datalekken veroorzaakt door het gebruik van AI. Om snel te kunnen leveren, vertrouwen ontwikkelaars blindelings op door AI gegenereerde code en volgen ze AI-instructies op zonder een onderliggend begrip van wat ze daadwerkelijk hebben gedaan.

Als je niet technisch bent, is het belangrijk om inzicht te krijgen in de applicatiestack voordat je een productieomgeving aan het internet koppelt en enorme hoeveelheden gebruikersdata verzamelt. Als dat te veel tijd kost, huur dan een onafhankelijke security auditor in. Snel leveren mag nooit ten koste gaan van veilig leveren.

Push geen code naar productie die je niet begrijpt

AI-ondersteund coderen is krachtig! Tools zoals Claude, Grok of ChatGPT kunnen functies genereren in enkele minuten. Maar snelheid is betekenisloos als je niet begrijpt wat er wordt uitgerold. Code die je niet kunt uitleggen, is code die je niet kunt vertrouwen.

Zelfs als de output in een taal is die je minder goed kent, neem de tijd om te begrijpen wat de functie doet. Een goede gewoonte is om je AI-assistent te vragen zijn eigen code uit te leggen, en vervolgens kritisch te kijken of het echt bij jouw use-case past en of er mazen of risico's zijn. Zie het als het beoordelen van het werk van een junior developer: de verantwoordelijkheid ligt nog steeds bij jou.

Je hoeft niet elk detail te begrijpen, maar het uitrollen van code die je niet kunt interpreteren, met als enige validatie "het lijkt te werken", is roekeloos. Voor prototypes of interne proof-of-concepts is dit acceptabel. Voor productiesystemen die aan het web zijn blootgesteld, is dat het niet.

Conclusie

De echte winnaars in productontwikkeling zijn degenen die de kracht van AI omarmen zonder de fundamenten uit het oog te verliezen. Het beheersen van zowel snelheid als discipline creëert producten die niet alleen innovatief zijn, maar ook veilig, betrouwbaar en gebouwd om lang mee te gaan.

Bij We Do Dev Work is dit precies hoe we te werk gaan. We gebruiken moderne tools om snel te schakelen, maar we nemen nooit korte bochten. We leveren kwaliteit en vermijden de shortcuts die leiden tot slordige resultaten.