Naar de inhoud
SwankyForge
SwankyForge
Alle inzichten
Artikel9 min lezen

Met een AI-pair in elke repository automatiseren we de checks en laten we vijf beslissingen bij mensen

Hoe het engineeringteam met AI-codeerassistenten werkt: wat bij elke wijziging automatisch draait, wat een mens altijd beslist, en wat we nog niet hebben gemeten.

Het meeste engineeringwerk in onze repositories begint nu met een eerste versie van een AI-codeerassistent. Niets daarvan gaat live op het woord van de assistent. Deze notitie beschrijft de opzet zoals die bestaat in de repository achter deze website, omdat dat de enige is die we openbaar kunnen laten zien. Ze zet ook de beslissingen op een rij die we bij mensen houden, en het getal dat we je nog niet kunnen geven.

De korte versie, als je inkoopt

We zijn een klein lab van twee engineers, met specialisten die per project worden toegevoegd. Een AI-assistent werkt naast ons beiden. Hij schrijft eerste versies van code, tests, documentatie en routineverslagen. Bij elke wijziging draaien geautomatiseerde checks die wijzigingen blokkeren die een regel overtreden. Een mens leest elke wijziging voordat die wordt gemerged. Niets bereikt productie of het publiek zonder een expliciet ja.

Wat je hieraan hebt: dezelfde twee engineers dekken meer van het routinewerk dat kleine teams vaak overslaan, zoals tests, documentatie en releasechecks. Daardoor blijft er meer budget over voor de delen die oordeelsvermogen vragen: de metric kiezen, beslissen of een model het bouwen waard is, en het in je proces inpassen.

Wat we niet claimen: een versnellingscijfer. We hebben er geen gemeten, en het externe bewijs zegt dat zelfgerapporteerde versnelling onbetrouwbaar is. De laatste secties beschrijven wat we zouden meten en wat dit voor een klant betekent.

Wat het onderzoek zegt: de tool is niet de winst

Vier studies uit 2025 bepaalden hoe we dit hebben opgezet.

  • Het DORA-programma van Google ondervroeg voor het rapport van 2025 bijna 5.000 technologieprofessionals. 90% gebruikt AI op het werk, en meer dan 80% denkt dat het hen productiever heeft gemaakt. Toch meldt 30% weinig of geen vertrouwen in de code die het genereert. De samenvatting van het rapport is dat AI "amplifies what's already there": sterke teams worden beter, worstelende teams zien hun problemen toenemen.
  • Het Technology Report 2025 van Bain vond dat teams die AI-codeerassistenten gebruiken een productiviteitswinst van 10–15% zien. Sommige bedrijven melden 25–30%, maar alleen als AI samengaat met een herontwerp van het hele proces. Eén reden dat het eerste getal klein is: het schrijven en testen van code is ongeveer 25–35% van de tijd van idee tot lancering.
  • De Stack Overflow Developer Survey van 2025 vond dat 84% van de respondenten AI-tools gebruikt of dat van plan is, en dat 46% de nauwkeurigheid van de output wantrouwt. De meest voorkomende frustratie was output die bijna goed is, maar net niet.
  • METR voerde een gerandomiseerde studie uit met 16 ervaren open-source developers op 246 echte taken. Met AI-tools toegestaan duurden taken 19% langer. De developers hadden 24% versnelling verwacht, en dachten achteraf nog steeds dat ze 20% sneller waren geweest. De auteurs waarschuwen dat het resultaat specifiek is voor hun situatie: grote, volwassen open-sourceprojecten en developers met beperkte ervaring met de gebruikte tool.

Samen gelezen zeggen de studies drie dingen. Een assistent invoeren is makkelijk. De winst hangt af van het proces eromheen. En niemands indruk van de eigen snelheid is bewijs. Daarom stoppen we de moeite in het proces (instructies, checks en goedkeuringsmomenten) en niet in de keuze van de tool.

Wat de assistent in onze repository doet

We gebruiken Claude Code. Vijf onderdelen maken het werk ervan voorspelbaar.

Projectinstructies. Een bestand in de root van de repository vertelt de assistent wat waar staat, welke regels hard zijn en welke commando's hij moet draaien. Het wordt geversioneerd zoals code, dus een wijziging van de regels verschijnt in de review zoals elke andere wijziging. Iedereen met toegang tot de repository kan precies lezen wat de assistent is verteld.

Skills voor terugkerende taken. Een skill is een korte uitgeschreven procedure die de assistent volgt voor één soort taak. We hebben er acht: een case study uitschrijven met het bijbehorende bewijsrecord, een engineeringnotitie opstellen, een post voor de bedrijfspagina opstellen, een profiel voor een extern platform genereren, tekst controleren op vertrouwelijke namen en persoonsgegevens, een read-only audit van de vertrouwenssignalen van de site, een wekelijks statusrapport, en triage van binnenkomende aanvragen. Elke skill zegt waar hij stopt. Geen ervan eindigt met het publiceren van iets.

Hooks. De acties van de assistent lopen via scripts die we zelf hebben geschreven. Nadat hij een bestand heeft bewerkt, wordt dat bestand gescand op vertrouwelijke namen en persoonsgegevens, en een vondst stuurt de assistent terug om het te herstellen. Voordat hij een git commit of push kan uitvoeren, draait een guard de vertrouwelijkheidsscan en de claims-lint op wat op het punt staat de working tree te verlaten. Elke vondst blokkeert het commando. Een gewone git pre-commit-hook past dezelfde checks toe op commits die met de hand worden gemaakt.

CI bij elke push en pull request. De pipeline draait lint, typechecks en een build, en daarna drie guards:

  • de vertrouwelijkheidsscan, over broncode, content en de gerenderde HTML. Als de configuratie ontbreekt, faalt hij in plaats van stilletjes te slagen;
  • de claims-lint, die een lijst superlatieven en zinnen met geleend gezag afwijst;
  • de contentvalidator, die een case study zonder bewijsrecord weigert, net als een referentieontwerp dat gemeten getallen claimt en een getal op de homepage dat niet linkt naar de case waar het vandaan komt.

Deze regels zijn bewust mechanisch. Een assistent produceert snel plausibele tekst, en plausibel maar fout is precies het falen dat de enquêtes beschrijven. Een regel die bij elke commit draait, hangt er niet van af dat iemand, mens of model, eraan denkt zorgvuldig te zijn.

De contentpipeline. Alles wat voor het publiek bedoeld is, gaat door drie mappen: drafts, approved, published. Een skill kan in drafts schrijven en nergens verder. Alleen de eigenaar voert de goedkeuringsstap uit, die beide scans opnieuw draait voordat het bestand wordt verplaatst. Publiceren gebeurt met de hand: een goedgekeurde post wordt als kant-en-klare tekst naar de eigenaar gestuurd, en een goedgekeurde notitie gaat pas live met de volgende goedgekeurde push naar main. Deze notitie heeft die weg afgelegd. Een assistent stelde haar op uit de eigen bestanden van de repository, de scans draaiden erop, en ze bereikte deze pagina nadat een mens haar had goedgekeurd.

Wat we nooit delegeren

Vijf beslissingen blijven bij mensen, wat de tools ook kunnen.

  1. De metric afspreken met de klant. Welk getal succes definieert, hoe het wordt gemeten en welke drempel als klaar telt. We zetten het in het contract voordat de training begint. Een assistent kan kandidaat-metrics opsommen. Hij kan niet weten op welke je business gaat handelen.
  2. Beoordelen of ML de moeite waard is. Soms is het eerlijke antwoord een regel, een rapport of een procesaanpassing. "Begin nog niet aan ML" is een aanbeveling die we doen, en het is een oordeel over jouw situatie, geen taak voor tekstgeneratie.
  3. Releases goedkeuren. Een merge naar main deployt. Niets wordt naar main gepusht zonder een expliciet ja van de eigenaar, en de rechten van de assistent sluiten force-pushen uit.
  4. Met de klant praten. Gesprekken, schriftelijke antwoorden, slecht nieuws. Een skill kan een antwoord op een aanvraag opstellen; een mens leest het, past het aan en verstuurt het. Geen enkel script neemt contact op met een lead.
  5. Beslissen wat openbaar wordt. Posts, notities, profielen, case studies en coderreleases. De pipeline maakt van publiceren een bewuste stap in plaats van een standaard.

De rode draad is verantwoordelijkheid. Elk van deze beslissingen heeft gevolgen waar iemand op aangesproken moet kunnen worden, en die iemand moet een mens zijn. Op een project is dat de ene benoemde engineer die van begin tot eind bij het werk blijft.

Wat we niet hebben gemeten

We hebben geen voor-en-nacijfer voor onze eigen productiviteit, en we zullen er ook geen noemen. Het resultaat van METR is de reden: developers die 19% trager waren, dachten dat ze 20% sneller waren. Een indruk, ook de onze, is geen meting.

Als we een getal publiceren, krijgt het hetzelfde bewijslabel als onze case studies (gemeten, geschat of illustratief), en komt het uit registraties zoals deze, verzameld over een genoemd venster:

  • tijd van het openen van een issue tot een gereviewde, gemergede wijziging, voor vergelijkbare soorten taken;
  • het aandeel gemergede wijzigingen dat binnen 14 dagen werd teruggedraaid of gerepareerd;
  • problemen die vóór de merge door hooks en CI werden gevangen, tegenover defecten die daarna werden gevonden;
  • reviewtijd per wijziging, omdat review de plek is waar de output van een assistent mensen tijd kost;
  • uren per mijlpaal tegenover de schatting uit onze calculator.

Tot die tijd is de eerlijke claim smaller. De checks draaien bij elke wijziging, en de vijf beslissingen hierboven worden door mensen genomen.

Wat dit voor jou betekent

Meer van het routinewerk wordt gedaan. Bij een vast budget zijn tests, documentatie, monitoring en releasechecks het eerste waarop kleine teams bezuinigen. Een assistent maakt ze goedkoper om te schrijven, en de checks maken ze moeilijk over te slaan.

De prijs gaat naar oordeelsvermogen. Onze tarieven en de uren achter elke rol staan op de prijspagina, en de calculator laat de rekensom zien. De uren die het zwaarst wegen, zijn die aan de metric, de evaluatie en de integratie met je proces: de delen die geen assistent voor ons doet. Als je niet zeker weet of ML het juiste antwoord is, geeft de gratis teardown een eerste oordeel in zes vragen, en een korte betaalde discovery beslist het voordat er een model wordt getraind.

Je kunt de opzet inspecteren. De repository staat vanaf dag één in jouw organisatie. Als er een assistent in werkt, staan de instructies en checks daarvan ook in die repository, naast de geschiedenis van elke wijziging, waar je ze kunt lezen.

Stel elke leverancier dezelfde vragen. Welke AI-tools krijgen je code en data te zien, en onder welke voorwaarden? Welke checks draaien bij elke wijziging, en blokkeren ze of waarschuwen ze alleen? Wie keurt een release goed? Heeft de leverancier de eigen versnelling gemeten, en hoe? De antwoorden vertellen je of AI in hun proces discipline versterkt, of het gebrek eraan.

Bronnen

Een proces dat te veel kost?

Vertel ons erover. Het eerste gesprek is gratis, en als AI niet het antwoord is, zeggen we dat.

Bespreek je vraagstuk