Elke review op een pull request stelt dezelfde smalle vraag: is deze wijziging in orde? De bredere vraag stelt niemand, tot de week voor de lancering, als iemand senior de repository krijgt met de vraag "kan dit live?". Die review is meestal gehaast, hangt af van wie er tijd heeft, en eindigt in een document met zorgen dat niemand omzet in werk.
We hebben een go-live check in CodeLynq gebouwd zodat je die vraag met één knop kunt stellen, op elk project, zo vaak als je wilt. Dit is wat hij controleert, hoe hij tot een oordeel komt, en wat hij je niet kan vertellen.
Drie dingen die een go-live check moet dekken
Een bruikbare go-live review is geen lijst van honderd punten. Hij beantwoordt drie vragen, en elke bevinding hoort bij een ervan:
- Code en architectuur. Houdt de code stand in productie, en niet alleen op de laptop van een developer? Hard-coded localhost, debugvlaggen die nog aan staan, standaard-secrets, ontbrekende migraties, geen foutafhandeling op de calls die gaan falen, N+1-queries en onbegrensde loads.
- Beveiliging en data. Authenticatie en autorisatie op elk endpoint, injectie, secrets in de repository, CORS en CSRF, persoonsgegevens in logs, data die nooit wordt verwijderd, een database die een redeploy niet overleeft.
- Flows. Werkt waar het product voor bestaat van begin tot eind? Registreren, inloggen, de kernacties, betalingen als die er zijn: ingang, handler, opslag, antwoord. Een flow die half af is, onbereikbaar is, of breekt op lege invoer of een dubbele submit, is een probleem voor de lancering.
Hoe de check werkt
Een go-live check kloont elke repository in het project en doet drie dingen na elkaar. Eerst draaien de scanners die op de checkout van toepassing zijn: gitleaks en semgrep als ze geïnstalleerd zijn, pip-audit bij een requirements-bestand, npm audit bij een package.json, of je eigen scancommando als je dat instelde. Dan draait het testcommando van het project, hetzelfde dat runs gebruiken om hun werk te controleren. Daarna beoordeelt een AI-agent de hele checkout, met de uitvoer van scanners en tests erbij.
Die agent kan alleen lezen. Hij kan bestanden lezen, oplijsten en doorzoeken, maar niet wijzigen en geen commando's uitvoeren. Een check die de code kan veranderen die hij beoordeelt, is geen check. Hij krijgt ook de context van het project: de architectuurprincipes, randvoorwaarden en domeinkennis die je team vastlegde, zodat "dit breekt een regel die wij hanteren" een bevinding kan zijn, en niet alleen algemene best practice.
Bevindingen, geen essay
De agent moet eindigen met een gestructureerde lijst: per bevinding een categorie, een ernst van kritiek tot info, een korte regel-id, een omschrijving, een aanbeveling en een locatie in de code. Kritiek betekent nu misbruikbaar of dataverlies; hoog moet voor de lancering opgelost zijn; gemiddeld moet binnenkort.
Twee keuzes kwamen voort uit nadenken over hoe dit misgaat. Staat er geen leesbare lijst in het antwoord, dan vragen we het één keer opnieuw, en lukt het dan nog niet, dan mislukt de check met die reden. Het alternatief, "geen bevindingen" vastleggen, zou je vertellen dat je project schoon is terwijl niemand het echt controleerde. En het oordeel is niet aan de agent. We leiden het af uit de bevindingen: een kritieke of hoge bevinding betekent niet klaar, alleen gemiddelde betekent klaar met waarschuwingen, anders klaar. Een antwoord dat "ziet er goed uit" zegt boven een kritieke bevinding, is niet klaar.
Serieuze bevindingen worden taken
Een rapport is de plek waar bevindingen vergeten worden. Daarom worden kritieke, hoge en gemiddelde bevindingen uit een go-live check taken op de backlog van het project, als concept, met het probleem, de locatie en de aanbeveling er al in, en de bugvelden ingevuld zodat een run begint met reproduceren. Lagere bevindingen blijven op het rapport. Eén check maakt hooguit vijftien taken aan, wat de agent ook teruggeeft.
De check nog eens draaien moet je backlog niet verdubbelen. Elke bevinding krijgt een vingerafdruk uit categorie, regel en bestand, bewust zonder regelnummer, dat verschuift bij elke andere wijziging, en zonder titel, die het model per run anders formuleert. Een bevinding die bij een open taak hoort, wordt aan die taak gekoppeld in plaats van opnieuw aangemaakt. De agent ziet ook wat er al openstaat, met de vraag dezelfde regel en locatie te gebruiken als hij hetzelfde probleem weer ziet, want de vingerafdruk is maar zo stabiel als de woorden die het model kiest.
Wat hij niet doet
- Hij klikt niet door je app. "Werken de flows" wordt beoordeeld vanuit de code en je testsuite. Er wordt niets gedeployd en geen browser maakt een testaccount aan. Heeft het project geen testcommando, dan draaien er geen tests; de agent weet dat en wordt gevraagd ontbrekende tests op kritieke flows als bevinding te melden. Je testsuite doet hier veel van het werk.
- Het is geen pentest. Hij leest code; hij valt geen draaiend systeem aan. Bij een lancering onder regelgeving is het de review voor de pentest, niet in plaats ervan.
- Hij kost modelgebruik. Een check leest het hele project, dus het gaat van je tegoed af, net als een run.
- Hij draait op onze workers. Voorlopig draaien checks op het platform, ook voor organisaties die een self-hosted runner voor hun runs gebruiken.
Waar hij past
De controles bij elke run, die we beschreven in vier checks voor een AI-run, kijken naar één wijziging. De go-live check kijkt naar alles waar niemand aan werkt, en dat is in de meeste projecten het grootste deel van de code. Draai hem een paar weken voor de lancering in plaats van de dag ervoor, zodat de taken die hij aanmaakt tijd hebben om pull requests te worden, en draai hem opnieuw als die gemerged zijn. Dat tweede oordeel is het oordeel dat je laat zien aan wie moet tekenen.