Zelf software bouwen met AI: wat je daarna nog moet regelen

Een demo beantwoordt maar één vraag

Een prototype kan aantonen dat een idee technisch mogelijk is. Het laat nog niet zien hoe de toepassing zich gedraagt bij verkeerd gebruik, ontbrekende gegevens of een storing. Dat is geen reden om niet te experimenteren. Het is een reden om de conclusie bij de proef te laten passen.

Gebruik je de tool alleen zelf met testgegevens, dan kan een ruwe versie heel leerzaam zijn. Gaan klanten of collega’s erop rekenen, dan veranderen de eisen. Zij moeten bijvoorbeeld weten wat er is opgeslagen en wat zij kunnen doen als een handeling niet lukt. Een fout die jij herkent, is voor een ander misschien onzichtbaar.

Schrijf daarom op waarvoor de eerste versie bedoeld is. Welke handelingen mogen ermee worden uitgevoerd? Welke gegevens mogen erin? Wie kijkt de uitkomst na? Die begrenzing voorkomt dat een geslaagde demonstratie ongemerkt de status krijgt van een volledig beheerd product.

Vergelijk de hele verantwoordelijkheid

Zelf bouwen kan aantrekkelijk zijn wanneer een proces specifiek is of bestaande pakketten veel onnodige functies bevatten. Kopen kan aantrekkelijk zijn wanneer je vooral een stabiele standaardfunctie nodig hebt. Er is geen algemene winnaar. De afweging hangt af van de taak en van wat je zelf kunt onderhouden.

Vergelijk daarom meer dan abonnementskosten en de tijd voor het eerste ontwerp. Denk aan aanpassingen, ondersteuning, toegangsbeheer, gegevens exporteren en herstel na fouten. Een kleine wijziging kan later verschillende onderdelen raken. De eerste versie is vaak het zichtbare deel van een langere afspraak met jezelf.

Je kunt ook tussenvormen onderzoeken. Misschien is een bestaand pakket met één beperkte koppeling voldoende. Of kun je eerst het proces vereenvoudigen, waardoor maatwerk niet meer nodig is. Het doel is dat het bedrijfsprobleem wordt opgelost, niet dat zoveel mogelijk van je software zelfgemaakt is.

Maak controleerbaar wat ‘werkt’ betekent

Een vaag verzoek aan AI levert moeilijk toetsbare software op. Beschrijf liever een concrete uitkomst. Welke invoer hoort bij welke berekening? Wat mag een gebruiker zien? Wat gebeurt er wanneer een veld leeg blijft? Je hoeft niet alle code zelf te schrijven om zulke verwachtingen helder te maken.

Test daarbij zowel de normale handeling als de grenzen. Kan een gebruiker gegevens van iemand anders openen? Blijft een wijziging bestaan na opnieuw inloggen? Komt hetzelfde bedrag terug wanneer je de berekening onafhankelijk narekent? Een groen vinkje van de tool die de code schreef is geen vervanging voor die inhoudelijke controle.

GitHub benoemt in zijn documentatie dat agentuitvoer onnauwkeurig of onveilig kan zijn en dat menselijke beoordeling relevant blijft. Dat is aanvullende leveranciersinformatie bij het gesprek, geen bewijs dat iedere gegenereerde regel fout is. Het onderstreept dat plausibele code nog steeds moet worden beoordeeld in de toepassing waarin je haar gebruikt. GitHub Docs

Beveiliging eindigt niet bij de lancering

Een toepassing verandert. Bibliotheken krijgen updates, gebruikers wisselen en er worden kwetsbaarheden ontdekt. Daarom is de vraag niet alleen of je bij de start hebt gekeken, maar ook hoe je problemen later signaleert en oplost. Wie ontvangt een melding, en wie kan handelen als jij afwezig bent?

Het Secure Software Development Framework van NIST behandelt beveiliging als onderdeel van de ontwikkelcyclus en het aanpakken van kwetsbaarheden. Het is een algemeen kader, geen garantie of verplichte checklist voor ieder klein project. De relevante gedachte is dat veilig ontwikkelen doorloopt na de eerste oplevering. NIST · SP 800-218

Maak voor je eigen toepassing een eenvoudig beheerblad. Noteer waar zij draait, welke diensten nodig zijn, wie toegang heeft en hoe een werkende versie kan worden teruggezet. Bewaar geheime sleutels niet in openbare code. Zorg dat iemand met passende kennis kan begrijpen wat er bestaat en welke onderdelen aandacht vragen.

Gegevens moeten ook weer weg kunnen

Een dashboard dat prettig oogt, kan alsnog onhandig zijn wanneer je gegevens niet kunt exporteren of herstellen. Vraag vooraf wat de bron is van belangrijke informatie. Als dezelfde klant op drie plekken anders staat geregistreerd, moet duidelijk zijn welke versie leidend is en wie dat kan corrigeren.

Probeer herstel ook echt uit met geschikte testgegevens. Een reservekopie hebben en die succesvol kunnen terugzetten zijn verschillende dingen. Hetzelfde geldt voor verwijderen: verdwijnt een gegeven alleen van het scherm, of weet je wat er in gekoppelde systemen gebeurt? Zulke vragen worden belangrijker naarmate meer mensen van het systeem afhankelijk zijn.

Voor een webshop komen daar concrete verplichtingen aan klanten bij. In het artikel bij aflevering 68 staat die klantreis centraal. Bij interne software is de ontvanger anders, maar blijft de vraag hetzelfde: wie merkt een fout op en hoe herstel je haar zonder nieuwe verwarring?

Bouw iets dat je kunt blijven dragen

AI kan de afstand tussen een idee en een eerste uitvoering kleiner maken. Daarmee wordt kiezen belangrijker. Niet iedere mogelijke toepassing verdient ook een blijvende plek in je bedrijf. Een eenvoudiger proces of een bestaand product kan net zo goed een slimme uitkomst zijn.

Luister aflevering 69 en kies daarna één software-idee. Beschrijf naast de gewenste functie ook wie het onderhoud, de controle en de ondersteuning gaat dragen. Als die kant nog onduidelijk is, heb je een gerichte volgende stap voordat je de demo als onmisbare bedrijfssoftware gaat gebruiken.

Bronnen en verantwoording

Dit artikel vertrekt vanuit het podcastgesprek. De gelinkte onderzoeken en officiële informatie vormen aanvullende context. Broncontrole: 29 oktober 2026.

1. Aflevering 69: AI verandert alles: van websites tot complete bedrijven — Mindshift Podcast · Bram en Ricardo
2. Application card: GitHub Copilot Agents — GitHub Docs
3. Secure Software Development Framework (SSDF), version 1.1 — NIST · SP 800-218 (2022)