Code

Code is waar je Status200 AI vraagt om in je repository's te werken, zoals je een codeeragent zou vragen: een bug oplossen, tests schrijven, de code uitleggen, een wijziging maken. Code opent op het vak waarin je vraagt, met de repository en de branch daarin gekozen en alle taken eronder; de pagina van een taak is een gesprek waarin je kunt antwoorden. Status200 start ook zelf taken, vanuit uitzonderingen, traces en onderzoeken. Een Runner kloont de repository, schrijft de wijziging op een nieuwe branch, bouwt en test die, en opent een pull request. Een mens beoordeelt en merget elke pull request: de Runner kan branches pushen en pull requests openen, meer niet.

AI vragen in een repository#

1. Open Code#

   Open Producten → Code. Code opent op Wat moet AI doen?: het vak waarin je vraagt, met alle taken eronder, de nieuwste eerst. Is er nog geen repository, dan biedt Code in plaats daarvan GitHub verbinden aan (zie Voordat je begint). Repository's, in het zijmenu, toont de repository's waarin AI kan werken, en bundelt onder Niet verbonden de repository's die de GitHub App niet meer bereikt. De pagina van elke repository heeft hetzelfde vak voor die repository.

2. Kies de repository en de branch#

   Het vak begint bij de repository die je het laatst koos. Kies een andere in de onderste rij ervan en, ernaast, de branch waarvan de taak uitgaat: de hoofdbranch van de repository, gemarkeerd als Standaard, totdat je een andere kiest. AI maakt zijn branch vanaf de branch die je kiest en opent zijn pull request daarnaartoe.

3. Zeg wat je wilt#

   Schrijf de wijziging, de bug of de vraag in je eigen woorden. Zolang er nog niets gevraagd is, stelt Code er onder Probeer te vragen een paar voor.

4. Voeg context toe#

   Klik op Context toevoegen om AI te geven wat het nodig heeft: een bestand of map van de repository, een notitie, een koppeling of een record van het project. Status200 leest elk record wanneer je het verzoek verstuurt, met jouw rechten, en bewaart wat AI kreeg.

5. Start de taak#

   Klik op Taak starten of druk op Enter. De pagina van de taak opent, en het werk van AI verschijnt daar terwijl het gebeurt.

Een verzoek bevat hooguit 10 stukken context. Tokens, sleutels, wachtwoorden en e-mailadressen in wat Status200 leest, worden afgeschermd voordat AI ze ziet, zoals overal waar Status200 AI je gegevens leest.

Het gesprek van een taak#

De pagina van een taak is een gesprek: wat er gevraagd is en de toegevoegde context, dan de beurt van AI – de stappen die het zet terwijl het ze zet (de bestanden die het las en bewerkte, waarnaar het zocht, de opdrachten die het uitvoerde), zijn antwoord, de bestanden die het wijzigde met hun diff, en de pull request. Bovenaan de pagina staat waar de taak werkt (de repository en de branch waarvan die uitging), hoeveel regels die wijzigde, met een knop naar de pull request, en hoe de taak ervoor staat:

Om verder te gaan, schrijf je in het vak onderaan, dat in beeld blijft terwijl het gesprek scrolt: antwoord AI, voeg context toe of vraag om wijzigingen. Elk antwoord is de volgende beurt van dezelfde taak: die werkt op dezelfde branch en pusht naar dezelfde pull request zolang die open is. Een taak doet één beurt tegelijk, dus het vak wacht terwijl AI werkt. Het Logboek van elke beurt is het letterlijke verslag van wat die deed.

Wie een repository kan lezen, leest zijn taken. AI iets vragen, antwoorden en een taak stoppen vereisen het recht om de repository te bewerken, en dat geldt ook voor de diff van een wijziging bekijken: alle anderen zien welke bestanden er veranderd zijn. De taken die Status200 zelf start (hieronder) staan ook in hun repository, als gesprekken waarin je kunt antwoorden.

Hoe een herstelrun verloopt#

1. Je klikt op Taak starten in Code, of op Oplossen met AI bij een onopgeloste uitzondering, of een andere knop of trigger start een taak (zie Waar hersteltaken starten).
2. De taak komt in de wachtrij van zijn repository, en de Runner die de repository kiest pakt hem op: een van je Runners, of een globale Runner als hij er geen kiest (zie De Runner van de repository kiezen).
3. De Runner haalt de context van de taak op. Bij een verzoek zijn dat de woorden, de toegevoegde context en het gesprek tot dan toe; bij een uitzondering het type, het bericht en de stack trace.
4. Hij kloont de repository naar een eigen werkruimte en maakt een branch. Een herstel van een uitzondering heet oneuptime-fix-exception- gevolgd door de eerste tekens van de id van de run. Een vraag gaat uit van de branch die gekozen was toen die gesteld werd, en de pull request opent daarnaartoe. Een antwoord werkt in plaats daarvan op de branch van de open pull request van de taak.
5. Een code-agent, aangedreven door de LLM-provider van je project, leest de code en schrijft de wijziging. De Status200-server doet de LLM-aanroepen, zodat de Runner nooit de API-sleutel van je provider heeft, en elke aanroep wordt gemeten en staat in de AI-logs. Een herstel van een uitzondering, een trage trace of een incident leest tijdens het werk ook uit productie: de uitzonderingen, traces, logs en metrieken van de services van de repository (zie Productietelemetrie in een herstel).
6. Op een eigen Runner bouwt en test de code-agent zijn wijziging zoals de AGENTS.md van de repository zegt, voordat er iets wordt gecommit, en herstelt hij wat faalt (zie Controle vóór de pull request).
7. De Runner commit, pusht de branch, opent de pull request (bij een verzoek alleen als er code is gewijzigd) en verwijdert de werkruimte.

De pagina waarop de taak is gestart, toont live de status. Elke taak staat in zijn repository onder Producten → Code: zijn pagina is zijn gesprek, en het Logboek van elke beurt heeft een regel voor elk bestand dat de Runner las of schreef en elke opdracht die hij uitvoerde.

Elke run is gebonden aan budgetten die de server afdwingt: hoogstens 40 LLM-aanroepen en 100.000 uitvoertokens. De query's op productietelemetrie van een run tellen mee voor dezelfde 40 aanroepen. Een run die er een bereikt, stopt met een samenvatting van het werk tot dan toe in plaats van in een lus te blijven draaien. Herstelruns tellen ook mee voor de dagelijkse AI-limieten van het project, als het project die instelt.

Waar hersteltaken starten#

Deze knoppen verschijnen alleen waar ze een taak kunnen starten. Staat AI voor het project uit, dan verschijnt er geen en heeft het zijmenu van een uitzondering geen AI Assistance. Logging verbeteren en Tracing verbeteren verschijnen zodra er een repository is gekoppeld, en Versnellen met AI alleen bij een trace die het verhelpen waard is (zie Traceverkenner). Oplossen met AI bij een functie verschijnt alleen bij de eigen code van de applicatie die minstens 5% van de tijd of het geheugen van het profiel inneemt, of waarvan het aandeel met 3 punten of meer is gegroeid sinds het venster waarmee het wordt vergeleken (zie Continue profilering).

Om de pagina AI Assistance van een uitzondering te openen, open je de uitzondering onder Producten → Observability → Uitzonderingen en kies je AI Assistance in het zijmenu. Een opgeloste of gearchiveerde uitzondering moet eerst als onopgelost worden gemarkeerd.

Status200 AI start hersteltaken ook zelf: vanuit een onderzoek dat een codewijziging vindt, vanuit een onderzoek dat zonder conclusie eindigt omdat er telemetrie ontbrak, en vanuit AI Insights over uitzonderingen en trage traces. Elk heeft een eigen schakelaar; zie Automatische codeherstellingen.

Productietelemetrie in een herstel#

Status200 weet wat je code in productie doet, dus een herstel hoeft niet alleen van een stack trace uit te gaan. Terwijl de code-agent werkt, kan hij de productietelemetrie opvragen van de services die bij de repository horen:

De beschrijving van de pull request vermeldt wat de agent opvroeg en wat dat liet zien. Andere taken, zoals regressietests en verbeteringen aan logging of tracing, raadplegen productie niet.

Wat de agent kan lezen, bepaalt de Status200-server op basis van de taak zelf:

• Alleen lezen. De query's draaien op de Status200-server, nooit op de Runner, die geen inloggegevens heeft waarmee telemetrie te lezen is. Niets wat ze doen, kan je project veranderen.
• Dit project, en alleen de services die bij deze repository horen. Je koppelt ze niet zelf: het zijn de services waarvoor Status200 deze repository vindt, zoals het ook de repository van een herstel vindt - de stack traces van hun uitzonderingen lopen door de bestanden ervan, ze heten zoals de repository, of het is de enige repository van het project. De telemetrie van een andere service kan niet worden gelezen.
• Geen privé-incidenten, en tokens, sleutels, wachtwoorden en e-mailadressen worden afgeschermd voordat de agent een resultaat ziet, zoals overal waar Status200 AI je gegevens leest.
• Begrensd. Hoogstens 12 query's per run, die elk meetellen voor de 40 aanroepen van de run.

Als er geen service bij de repository hoort, draait de taak zonder productietelemetrie, zoals voorheen.

Productiebeoordeling van pull requests#

Status200 weet wat je code in productie doet, dus kan het een pull request beoordelen met wat niemand ziet die de diff leest. Zet Pull requests beoordelen aan de hand van productie aan onder Meer instellingen op de pagina Instellingen van een repository in Code, en elke pull request die iemand met schrijfrechten opent of bijwerkt, krijgt één opmerking die zegt wat productie laat zien van de code die hij wijzigt. De opmerking wordt bij elke push ter plekke bijgewerkt, en de pagina Productiebeoordelingen van de repository in Code bewaart elke beoordeling, met Opnieuw beoordelen.

Als productie iets laat zien, leest Status200 AI het naast de diff en voegt Aandachtspunten toe: een paar korte punten, elk gebaseerd op de feiten. Dit draait alleen zolang AI voor het project aan staat, hooguit 10 keer per dag voor een pull request en 100 keer voor een repository, en wordt gemeten zoals elke AI-aanroep; de feiten worden elke keer zonder AI gelezen. Als productie niets over de wijziging laat zien, plaatst Status200 niets.

• Alleen totalen. De opmerking bevat aantallen, duren en namen van code: nooit het bericht van een uitzondering, een logregel, de titel van een incident of persoonsgegevens.
• Openbare repository's krijgen een link. Iedereen kan de pull requests van een openbare repository lezen, dus daar linkt de opmerking alleen naar de beoordeling in Status200, die alleen leden van het project kunnen openen. Opmerking bij productiebeoordeling, onder Meer instellingen op de pagina Instellingen van de repository, kan overal Alleen een link naar de beoordeling plaatsen, of De beoordeling, ook in een openbare repository.
• Externe bijdragers kunnen er geen starten. Een pull request wordt alleen vanzelf beoordeeld als de auteur, en wie er ook naar pushte, naar de repository mag schrijven. Een van iemand anders - een externe bijdrager, een fork, een bot - wordt beoordeeld als iemand met schrijfrechten er @oneuptime production review op reageert, of in Code op Opnieuw beoordelen klikt.
• Alleen lezen. Een beoordeling kloont niets en voert niets van de pull request uit. De diff en de titel zijn gegevens voor Status200 AI, nooit instructies: de AI heeft geen tools, en wat hij schrijft, wordt als tekst in de opmerking gezet.

De schakelaar staat aan voor de repository's die de GitHub App vanaf nu verbindt. Een repository die werd verbonden voordat hij bestond, houdt hem uit tot je hem aanzet.

Controle vóór de pull request#

Een repository zegt in een AGENTS.md in de hoofdmap, het bestand dat codeeragents lezen, hoe hij wordt gebouwd en getest. Voordat de code-agent iets wijzigt, leest hij de AGENTS.md van de repository (of zijn CLAUDE.md, als hij geen AGENTS.md heeft) uit de branch waar de taak van uitgaat, en werkt hij zoals die zegt. Zonder een van beide haalt hij het uit de CONTRIBUTING.md van de repository, de README, de pakketscripts, de Makefile of de CI-workflows. Er is niets in te stellen in Status200.

Niets uit een pull request die uit een fork komt, wordt ooit gelezen als de instructies van de repository: een herziening weigert zo'n pull request, en een review leest de basisbranch.

Opdrachten die op een repository zijn ingesteld#

Code vraagt niet meer om setup-, build- en testopdrachten, maar een repository die ze heeft, eerder ingesteld of via de API of Terraform, houdt ze. Ze staan alleen-lezen op de kaart Build- en testopdrachten, onder Meer instellingen op de pagina Instellingen van de repository, en Opdrachten verwijderen verwijdert alle drie. Zolang er een is ingesteld, controleert elke herstelrun op een eigen Runner zijn wijziging er ook mee voordat de pull request opent:

1. Als de code-agent klaar is, draaien de opdrachten op volgorde in de root van de repository, op de Runner, in de gekloonde werkruimte. Elke opdracht krijgt tot 15 minuten en draait met CI=true, zodat niets op invoer wacht; de eerste fout stopt de ronde.
2. Bij een fout gaat het einde van de uitvoer van de mislukte opdracht terug naar dezelfde code-agent als hersteltaak, met de instructie zijn eigen wijziging te verbeteren in plaats van tests af te zwakken of over te slaan, en de opdrachten draaien opnieuw. Hij doet hoogstens 2 herstelpogingen. Die delen het LLM-budget van de run, en hun wijzigingen komen in dezelfde commit als het herstel.
3. De uitkomst, geslaagd, mislukt of overgeslagen (geen opdrachten ingesteld, of een globale Runner), staat in een Verification-sectie van de beschrijving van de pull request en wordt vastgelegd bij de pull request van de taak.

Een wijziging die de controle nog steeds niet doorstaat, wordt niet weggegooid: de pull request opent toch, met een duidelijk gemarkeerde sectie "Verification failed" die de mislukte opdracht noemt en eindigt met de uitvoer ervan. Het werk blijft bewaard, en wie beoordeelt, beslist. Een repository zonder ingestelde opdrachten wordt als overgeslagen gemeld, in plaats van een groene build te suggereren.

De opdrachten zijn repository-instellingen die je team schrijft en die op je eigen Runner draaien: hetzelfde vertrouwensmodel als de Bash-stappen van een runbook. De AI schrijft of wijzigt ze nooit. Een globale Runner, die Status200 voor elk project draait, voert ze nooit uit: op een globale Runner wordt het herstel geschreven en ter beoordeling geopend, wordt de controle als overgeslagen gemeld, en controleert de eigen CI van je repository de wijziging. Draai een eigen Runner om het herstel te laten bouwen en testen voordat de pull request opent.

Na het mergen van een fix#

Een fix mergen lost niets op totdat hij draait. Zodra een pull request met een fix gemerged is, wacht Status200 op een vastgelegde deploy die hem bevat (zie Deploys en wijzigingen) en houdt in die deploy in de gaten waarvoor de fix bedoeld was. De pull request van de taak in Code zegt hoe het ging, net als de pagina AI Assistance van de uitzondering, de AI-logboeken van het incident en de AI-insight waar de fix uit voortkwam:

Totdat een deploy hem uitlevert, staat bij de fix Gemerged, wacht op een deploy, daarna Gedeployed, wordt in productie gevolgd zolang hij gevolgd wordt. Een fix die binnen 14 dagen in geen enkele vastgelegde deploy zit, of waarover productie niets kan zeggen, staat op Niet geverifieerd in productie. Automatische codefixes beschrijft de regels. Een regressietest, betere foutafhandeling, een review en een verzoek in Code worden niet gevolgd: productie kan niet laten zien wat ze veranderen.

Voordat je begint#

Een taak heeft drie dingen nodig. Het vraagvak van Code en de pagina AI Assistance van de uitzondering controleren alle drie voordat ze aanbieden te starten, en zeggen wat er ontbreekt.

Op een zelf gehoste instantie is de globale provider één blok in config.env (Docker Compose) of in je Helm-waarden. Voor een zelf gehoste Ollama:

GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.

Elke ondersteunde provider werkt: zie LLM-providers voor alle providers en elke omgevingsvariabele.

Je koppelt repositories niet aan services. Als een taak start, vindt Status200 de repository door de bestandspaden uit de stack trace van de uitzondering te vergelijken met je gekoppelde repositories. Als niets overeenkomt, valt hij terug op een repository met dezelfde naam als de service, en dan op de enige repository van het project als er maar één is. De pagina AI Assistance toont welke repository hij vond.

De Runner van de repository kiezen#

Elke repository kiest de Runner waarop AI erin werkt: open op zijn pagina Instellingen in Code Meer instellingen, klik op Bewerken op de kaart Runner en kies er een. Een repository die de GitHub App importeert, begint op de standaard-Runner van het project, als het er een heeft. Een repository die er geen kiest, werkt op Globale Runner, die Status200 voor elk project draait.

Alleen de Runner die een repository kiest, krijgt zijn taken en een token ervoor. In een project dat Globale Runners gebruiken uitzet onder Runbooks → Runbook-agenten, heeft elke repository een van de eigen Runners van het project nodig. De pagina van een Runner toont de repositories die hem kiezen.

Een eigen Runner draaien#

Om een Runner ergens anders te draaien, bijvoorbeeld op een machine dicht bij je repositories:

1. Maak de Runner aan#

   Maak een Runner aan onder Runbooks → Runbook-agenten en klik op Installatie-instructies weergeven in zijn rij. De opdracht bevat de geheime sleutel van de Runner, die alleen een Project Owner, Project Admin of Runbook Admin kan lezen. Hij ziet er zo uit:

   Bash

   docker run --name status200-runner --restart unless-stopped \
     -e STATUS200_RUNNER_ID=<runner-id> \
     -e STATUS200_RUNNER_KEY=<runner-key> \
     -e STATUS200_URL=<your-status200-url> \
     -d status200/runner:release

2. Kies hem voor de repository#

   Open op de pagina Instellingen van de repository in Code Meer instellingen, klik op Bewerken op de kaart Runner en kies de Runner. De Runner neemt de wijziging over bij zijn volgende heartbeat, binnen ongeveer een minuut; er hoeft niets opnieuw te starten.

3. Controleer of hij verbinding maakt#

   De Runner verschijnt binnen een minuut of twee als verbonden op de pagina Runbooks → Runbook-agenten. Zo niet, lees dan de log van de container (docker logs status200-runner) op een fout met inloggegevens of het netwerk.

Elke manier om de container te draaien werkt (Docker Compose, Kubernetes enzovoort), zolang hij deze variabelen heeft en je Status200-instantie via HTTPS kan bereiken:

Automatische codeherstellingen uit onderzoeken#

Als een AI-onderzoek een analyse van de hoofdoorzaak plaatst bij een incident of een waarschuwing, en de zorgvuldige classificatie ervan een wijziging in de code aanbeveelt, biedt de onderzoekskaart Open Fix PR from this analysis aan: een hersteltaak waarvan de hele context de geplaatste analyse is. De knop is verborgen als de oplossing operationeel is, alleen de infrastructuur betreft, extern is, een verwachte weigering, een gebruikersfout of zonder conclusie. Geschikte herstellingen gebeuren zonder de klik zolang Nieuwe incidenten automatisch herstellen aan staat op Incidenten → AI → Instellingen (en Nieuwe waarschuwingen automatisch herstellen op Waarschuwingen → AI → Instellingen). Herstellen begint uit, ook voor nieuwe projecten. Zonder AI-regel wordt elke geschikte fix geopend; met regels alleen een voor wat een regel matcht, wanneer de regel Pull requests met oplossing aan heeft staan (een nieuwe regel heeft dat), in de code-repository's die hij noemt.

Zolang herstellen aan staat, zet een onderzoek dat eindigt met een zekere, onderbouwde hoofdoorzaak die een codewijziging kan herstellen, dezelfde hersteltaak in de wachtrij die de knop aanmaakt. De beslissing is een begrensde classificatie die de server controleert, nooit een patroon dat op de tekst van de analyse wordt toegepast: alleen een positief oordeel voor een codeherstel opent een pull request. Ontbrekend bewijs, een oplossing buiten de code en een mislukte classificatie eindigen allemaal in niets doen.

Al het andere is gelijk aan de knop:

• De pull request opent klaar voor review, geschreven vanuit de geplaatste analyse, en heeft een repository nodig die via de GitHub App is gekoppeld, een die de matchende regels noemen als ze er noemen, en een Runner die online is om erin te werken: die de repository kiest, of een globale Runner.
• Hij telt mee voor de dagelijkse limiet voor hersteltaken van dat signaal (Daily Incident AI Fix Task Limit of Daily Alert AI Fix Task Limit, onder Meer instellingen op de AI-instellingenpagina ervan) en voor het maximum aan open pull requests van de repository, als een van beide is ingesteld. Niet ingesteld beperkt geen van beide iets.
• Elke trigger zoekt eerst naar een hersteltaak die al in de wachtrij staat of draait voor hetzelfde incident of dezelfde waarschuwing, zodat een automatische trigger en een klik normaal één taak worden, niet twee pull requests. De controle is een lezing vóór het schrijven, geen vergrendeling, dus twee triggers op precies hetzelfde moment kunnen er nog allebei door komen.
• De run wordt door het systeem geschreven, aan niemand toegeschreven, en niets wordt vanzelf gemerged.

Als een herstel mislukt#

Privacy#

De kloon van je repository staat in een werkruimte in de container van de Runner en wordt verwijderd als de run eindigt, geslaagd of niet. De Runner heeft nooit de API-sleutel van je LLM-provider: de Status200-server doet de LLM-aanroepen voor hem, en voert ook de query's op productietelemetrie uit. Status200 bewaart je repository niet en traint niet op je code. Het log van de taak bewaart de eerste 300 tekens van de uitvoer van elke stap, zodat je kunt nagaan wat de Runner deed, en daar kunnen stukjes code in staan. Draai een zelf gehoste Runner met je eigen LLM-provider (lokale Ollama inbegrepen), en je code verlaat nooit je infrastructuur.

Op de roadmap#

Gepland, en vandaag nog niet beschikbaar:

• Ondersteuning voor GitLab. Repositories worden alleen via de GitHub App gekoppeld.

Volgende stappen#