AI-codeassistenten maken in seconden plausibele code. Voor een op zichzelf staande functie of een bekend patroon is dat werkelijk nuttig. In een bestaand product heeft een wijziging echter pas waarde als ze doet wat bedoeld was, in de architectuur past, door het team te onderhouden is en via het normale leveringsproces bij gebruikers terechtkomt. Code genereren en een geaccepteerde wijziging opleveren hangen samen, maar zijn niet dezelfde taak.
Wie één verzoek volgt van intentie tot release, ziet waar het verschil zit. Het voorbeeld hieronder is illustratief en beschrijft geen echte klant of echt project.
Productintentie en acceptatiecriteria
Een productteam vraagt om een nieuwe functie: klanten moeten hun factuurhistorie kunnen exporteren als bestand voor hun boekhoudsoftware. Voordat er code wordt geschreven, moet het verzoek precies worden gemaakt. Welk bestandsformaat, welke velden, welke periode? Wat gebeurt er bij een zeer omvangrijke historie? Wie mag exporteren, en wordt de export vastgelegd? Heldere acceptatiecriteria maken van een wens iets wat te controleren is. Zonder die criteria kan noch een engineer noch een AI-systeem weten wanneer het werk af is.
Repository- en architectuurcontext
De volgende vraag is waar de wijziging thuishoort. In een bestaande codebase worden facturen misschien al door een bepaalde service afgehandeld, met vaste afspraken voor datatoegang, rechten, achtergrondtaken en foutafhandeling. Een export die om die afspraken heen werkt, kan in een demo prima functioneren en later toch problemen veroorzaken. Bruikbare AI-ondersteuning hangt daarom af van context: de relevante delen van de repository, de architectuurkeuzes erachter en de randvoorwaarden waarbinnen het team werkt. Als de context onvolledig is, kan gegenereerde code er goed uitzien en toch niet passen.
Voorgesteld ontwerp en codewijzigingen
Met intentie en context op orde kan een ontwerp worden voorgesteld: bijvoorbeeld een achtergrondtaak die het bestand opbouwt met de bestaande rechtencontroles en opslagdienst, en een melding stuurt zodra de export klaar is. Pas daarna is het zinvol de codewijzigingen te genereren. Door het ontwerp apart te presenteren, kan een engineer de aanpak beoordelen voordat hij of zij honderden regels code reviewt. Sommige voorstellen zullen ongeschikt zijn: te breed, met wijzigingen in ongerelateerde bestanden, of met een afhankelijkheid die het team liever vermijdt. Dat op ontwerpniveau opvangen is goedkoper dan in de review.
Tests en relevante controles
Vervolgens heeft de wijziging tests nodig die de acceptatiecriteria weerspiegelen, naast de gebruikelijke controles van het team, zoals linting, typecontroles en securityscans. Testresultaten moeten worden geïnterpreteerd. Een geslaagde testsuite laat zien dat de code voldoet aan de controles die er zijn; ze bewijst niet dat die controles volledig zijn, dat de code veilig is of dat alle randgevallen zijn afgedekt. Zijn de tests samen met de code gegenereerd, dan hoort een reviewer na te gaan of ze de eis toetsen of alleen de implementatie bevestigen.
Menselijke review
In de review ligt de verantwoordelijkheid. Een engineer, of een andere bevoegde rol, beoordeelt of de wijziging aan de acceptatiecriteria voldoet, in de architectuur past en onderhoudbaar is. Dat werkt alleen als de reviewer kan zien wat er is veranderd en waarom: de oorspronkelijke eis, het voorgestelde ontwerp, de relevante context en de testresultaten. Reviewen kost echt tijd. Zijn ondersteunde wijzigingen groot, slecht toegelicht of vaak ongeschikt, dan kan reviewen langer duren dan de code zelf schrijven, en een workflow die die kosten negeert, houdt geen stand.
Release via het bestaande proces
Tot slot hoort een geaccepteerde wijziging het bestaande leveringsproces van het team te volgen: dezelfde branchingstrategie, pipelines, goedkeuringen en releaseprocedures als iedere andere wijziging. AI-ondersteuning moet in dat proces passen en geen parallelle route naar productie openen. Besluiten over architectuur, acceptatie en productierelease blijven bij engineers en andere bevoegde rollen.
Gespecialiseerde agents, en hun grenzen
Sommige aanpakken gebruiken meerdere gespecialiseerde AI-agents: een om eisen aan te scherpen, een om de codebase te analyseren, een om wijzigingen voor te stellen, een om tests te schrijven. Het werk verdelen kan iedere stap gerichter en beter controleerbaar maken. Maar meer agents maken het resultaat niet vanzelf correct. Agents kunnen dezelfde onvolledige context delen of elkaars fouten versterken. Wat vertrouwen geeft, is hetzelfde als in ieder engineeringproces: heldere criteria, relevante controles en een menselijke review met een verantwoordelijke.
Waar CodeChat past
CodeChat, een venture in ontwikkeling en validatie bij Xablu Venture Studio, werkt aan een AI-ondersteund ontwikkelplatform dat rond deze volgorde is opgebouwd: het verbindt eisen, architectuur, code, tests, review en levering, in plaats van codegeneratie als losse stap te behandelen. Het werk tot nu toe omvat discovery, een blueprint, de architectuur, een prototype en een eerste technische basis. Welke delen van die keten betrouwbaar werken in verschillende codebases en teams, is precies wat de validatie moet uitwijzen. Engineers blijven daarbij verantwoordelijk voor de besluiten die ertoe doen.
Heeft u een bestaande codebase waarin AI-ondersteunde ontwikkeling het testen waard is? Kies één afgebakende ontwikkeltaak, leg vooraf de acceptatie- en reviewcriteria vast, en beoordeel het resultaat zoals u iedere andere wijziging zou beoordelen. We bespreken graag hoe u dat opzet.
Bespreek een ontwikkeltaak →