Hoe wij met AI bouwen

Wat het u oplevert

Werk dat eerder weken kostte, staat nu vaak binnen dagen te draaien. Het belangrijkste daarvan is niet de snelheid, maar wat er ineens wél uit kan: een intern hulpmiddel voor één afdeling, een koppeling die een handjevol mensen gebruikt, een versie van een systeem die eindelijk toegankelijk is. Dat soort werk sneuvelde altijd op de businesscase.

Onze c-clients zijn daar het bewijs van. Drie systemen die in de praktijk een muis en een beeldscherm vereisen, opnieuw ontsloten voor wie met een schermlezer of brailleleesregel werkt. Als apart project was dat nooit rond te rekenen geweest — zo wel.

Wat de machine doet, en wat wij doen

De AI schrijft het leeuwendeel van de code. Wij bepalen de richting, de architectuur, de smaak en wanneer iets af is — en wij lezen wat eruit komt. Er gaat niets naar productie omdat een model zegt dat het klopt; het gaat naar productie omdat wij het beoordeeld hebben én de controles groen staan.

U koopt dan ook geen AI. U koopt werkende software, met ons als aanspreekpunt. Wie het getypt heeft, verandert niets aan wie ervoor instaat.

De regels gaan vooraf, niet achteraf

Een model dat vrij mag associëren levert verrassingen op waar u niets aan hebt. Daarom begint elke opdracht met dezelfde geschreven huisregels — niet als goede bedoeling, maar als instructie die de AI letterlijk meekrijgt:

• Nooit iets verzinnen. Wat niet is nagekeken, wordt niet als feit opgeschreven — niet in code, niet in documentatie, niet tegen u.
• Toegankelijkheid is het uitgangspunt, geen extra ronde: semantische HTML, bruikbaar met toetsenbord en schermlezer, leesbaar zonder JavaScript.
• Git is de bron. Werk begint op een aparte tak en gaat pas naar productie via de pipeline — nooit een snelle wijziging op de server zelf.
• Passen bij wat er al staat: dezelfde stijl, dezelfde patronen, geen bibliotheek erbij zonder reden.
• Niets stilletjes weggooien. Wat draait, blijft staan tot is aangetoond dat het niet meer nodig is.

Die regels zijn geen theorie: ze staan op schrift, ze gelden voor elke sessie, en ze zijn ontstaan uit fouten die we niet nog eens wilden maken.

Niet één model, maar een ploeg met rollen

We laten niet één model alles doen. We werken met een vaste set rollen, elk met een eigen taak en een eigen blik, en zetten ze in waar het werk erom vraagt:

• Een architect die eerst nadenkt en een plan maakt, vóór er één regel code is.
• Een bouwer die dat plan uitvoert in de stijl van de code die er al staat.
• Een criticus die het werk tegen het licht houdt en bewijs eist — die scheidt wat is aangetoond van wat is aangenomen.
• Een tester en een security-reviewer die toetsen wat de code echt doet, niet wat die zou moeten doen.
• Een ontwerper voor ritme, typografie en hoe iets aanvoelt.

Zo gaan er meerdere kwaliteitsslagen over hetzelfde werk, elk met een andere vraag: klopt het plan, klopt de uitvoering, klopt het bewijs, is het veilig, voelt het goed. Dat is precies waar het om gaat, want het klassieke risico van AI-code is niet dat die niet werkt — het is een antwoord dat overtuigend klinkt en niet klopt. Eén model dat zijn eigen werk nakijkt, vindt dat niet.

Alles via git, alles via de pipeline

Al ons werk staat in git — ook dat van de AI. Elke wijziging is een eigen tak met een leesbare beschrijving van het waarom, wordt beoordeeld, en gaat pas naar main als de controles groen zijn. Wat er live staat is daardoor altijd te herleiden tot één wijziging, en met één stap terug te draaien.

Uitrollen doet de pipeline, niet een mens met een laptop: de server haalt de nieuwe versie zelf uit git. Niemand kopieert bestanden naar productie, en er kan dus ook niets live staan dat niet in git zit.

Diezelfde pipeline is de plek waar de kwaliteitsbewaking hoort. Bij elke wijziging draait dezelfde reeks controles, en pas als die allemaal groen zijn kan er iets live:

• Een WCAG-regelscan op elke pagina, in zowel het lichte als het donkere thema.
• Een virtuele schermlezer die per pagina de leesvolgorde, de kopstructuur en de labels van formuliervelden naloopt.
• Geautomatiseerde tests van opbouw en gedrag in een echte browser — inclusief de controle dat alles ook zonder JavaScript leesbaar blijft.
• Poorten die de oplevering tegenhouden zodra er een sleutel of een intern adres in de code belandt.

Deze site is er zelf mee gebouwd: dezelfde takken, dezelfde pipeline, dezelfde poorten. Wat u hier leest is dus geen belofte over hoe we het zouden willen doen.

Waar de AI ophoudt

Een automatische toets is geen ervaring. Onze controles vangen veel, maar ze vervangen niet iemand die dagelijks met een schermlezer werkt en binnen tien seconden voelt dat een scherm niet deugt. Die toetsing zoeken we bij mensen op; hebben we die voor iets nog niet, dan zeggen we dat erbij in plaats van het weg te laten.

Hetzelfde geldt voor de keuzes die er echt toe doen: wat u eigenlijk nodig hebt, wat het waard is, en wat we bewust niet bouwen. Daar bestaat geen model voor. Dat is het gesprek.

En ja — het is ook gewoon leuk

Er komen dingen uit die we vooraf niet hadden bedacht, en de drempel om iets te proberen is laag geworden. Daar profiteert u van: een idee toetsen kost geen kwartaal meer. Maar het is ook waarom er naast toegankelijke systeemclients een variant-sudokugenerator, een mindmap-app en twee woordspellen op onze werkpagina staan.

Nieuwsgierigheid is geen bijzaak. Wat we bij het spelen leren, komt terug in het werk waar het serieus moet zijn.

Deze site is zelf werk in uitvoering

Wat u hier ziet is geen opgeleverd eindproduct maar werk in uitvoering: we bouwen er nog aan terwijl u leest, precies zoals hierboven beschreven — in kleine wijzigingen, elk langs dezelfde controles. Er komen pagina's bij, teksten worden scherper, en wat beter kan verandert.

Dat vertellen we liever dan dat we doen alsof alles al af is. Ziet u iets dat niet klopt of beter kan, dan houden we ons aanbevolen.

Benieuwd wat dit voor uw project betekent?

Vertel ons wat u wilt bouwen of laten verbeteren. Dan zeggen we eerlijk wat er wél en niet realistisch is — en wat ervoor nodig is.