Open een repository zes maanden nadat een feature is uitgerold en je kunt veel reconstrueren. Je kunt de architectuur volgen, het schema inspecteren, de tests lezen en precies zien welke regels zijn gewijzigd.
Wat je meestal niet kunt reconstrueren, is het gesprek dat die regels noodzakelijk maakte.
De code vertelt je niet dat er een validatieregel bestaat omdat één klant onjuist gevormde exports verstuurt. Ze legt niet uit dat een vreemd retry-beleid dubbele transacties in een downstream-systeem voorkomt. Ze laat niet zien dat de schonere interface is afgewezen na een toegankelijkheidstest, of dat een servicegrens een contractuele beperking weerspiegelt in plaats van een technische voorkeur.
Git is uitstekend in het bewaren van codegeschiedenis. Intentie bewaart het alleen wanneer een team die bewust opschrijft en verbonden houdt met de implementatie.
Dat gat is altijd al onderdeel geweest van software-engineering. AI-codingtools maken het zichtbaarder. Een systeem kan elk bestand in een repository lezen, elk symbool volgen en een technisch overtuigende patch genereren, terwijl het nog steeds het verkeerde probleem oplost.
Het probleem is niet dat de code misleidend is. De code beantwoordt een beperktere vraag.
Vijf lagen van technische waarheid
De meeste betekenisvolle softwarewijzigingen hangen af van vijf verschillende lagen bewijs.
- Intentie — Welk resultaat vraagt de gebruiker, klant of het bedrijf? Dit kan staan in een specificatie, ticket, supportgesprek of vergadernotitie.
- Beperkingen — Wat mag niet kapotgaan? Compatibiliteitsbeloften, beveiligingsgrenzen, regelgeving, contracten, budgetten en deadlines liggen vaak buiten de repository.
- Implementatie — Hoe werkt het systeem vandaag? De code, tests, schema’s, afhankelijkheden en deploymentconfiguratie vormen deze laag.
- Runtime-bewijs — Wat gebeurt er in het echte systeem? Logs, traces, metrics, productiedata en incidentrapporten kunnen aannames tegenspreken die in code redelijk lijken.
- Besluitgeschiedenis — Waarom is voor de huidige aanpak gekozen? Pull requests, ontwerpdiscussies, verworpen alternatieven en eerdere incidenten bevatten het antwoord.
De repository is het sterkst in de derde laag. Ze bevat delen van de andere, maar zelden genoeg om die volledig te vertegenwoordigen.
Dit is belangrijk omdat softwarefouten vaak verschijnen op de grenzen tussen lagen. De implementatie komt overeen met een verouderde specificatie. De oplossing voldoet aan het ticket maar schendt een operationele beperking. De tests slagen omdat ze de aannames van gisteren coderen. De code is intern consistent terwijl productiedata een patroon volgt dat niemand heeft gedocumenteerd.
Een lokaal correcte patch kan nog steeds de verkeerde wijziging zijn.
Wat de repository op zichzelf niet kan beantwoorden
Stel je een gebruiker voor die een document bewerkt en daarna zoekt op de bijgewerkte zin, om vervolgens in de resultaten alleen de oude versie te zien. “Zorg dat zoeken meteen wordt bijgewerkt” klinkt als een duidelijke vraag. De repository laat verschillende mogelijke startpunten zien, maar kan niet op eigen kracht bepalen wat de juiste oplossing is.
| Vraag | Waarschijnlijke bron |
|---|---|
| Welke versie van het document is leidend? | Brondocument en revisiegeschiedenis |
| Waar blijft de oude tekst staan? | Synchronisatielogs, extractie-uitvoer, zoekindex of cache |
| Wat betekent “meteen” voor dit product? | Productbelofte of servicedoelstelling |
| Zijn de rechten van het document tegelijk met de inhoud gewijzigd? | Bronrechten en auditgeschiedenis |
| Is het verouderde resultaat beperkt tot één gebruiker, bron of regio? | Requesttraces en productiemetrics |
De zoekcode kan verklaren hoe resultaten worden teruggegeven. Maar ze kan je niet vertellen of het echte defect synchronisatievertraging, verouderde extractie, cache-invalidatie, propagatie van rechten of een verwachting is die het product nooit heeft gedefinieerd.
Dit onderscheid wordt nog belangrijker in volwassen systemen. Een veld dat verouderd lijkt, kan nog steeds een legacyclient ondersteunen. Een service die op een duplicaat lijkt, kan data scheiden met verschillende rechtenvereisten. Een controle die buitensporig lijkt, kan het enige spoor in de code zijn van een productie-incident dat het huidige team nooit heeft meegemaakt.
Complexiteit verwijderen is waardevol. Geschiedenis verwijderen die zich voordoet als complexiteit, is duur.
Meer context kan nog steeds tot het verkeerde antwoord leiden
De voor de hand liggende oplossing is om de AI meer materiaal te geven: de hele repository, elk ticket, elk document, elk bericht en elke log.
Dat creëert toegang, geen begrip.
Bronnen kunnen verouderd, tegenstrijdig, speculatief of voor verschillende doelgroepen geschreven zijn. Een brainstorm mag niet zwaarder wegen dan een goedgekeurde specificatie. Een vereiste van zes maanden geleden mag de productbeslissing van gisteren niet stilzwijgend overrulen. Een productielog moet gekoppeld zijn aan de release, omgeving en codepad die die log hebben voortgebracht. Een klantverzoek mag niet als universele vereiste worden behandeld zonder eerst de scope te controleren.
Een serieus contextsysteem heeft daarom meer nodig dan alleen retrieval. Het heeft een manier nodig om te redeneren over:
- Autoriteit: Welke bron mag de vereiste bepalen?
- Actualiteit: Welke informatie is actueel, en wat is inmiddels vervangen?
- Herkomst: Waar komt elke claim, beperking of conclusie vandaan?
- Relaties: Welke issue, release, klant, dataset en codepad horen bij elkaar?
- Rechten: Welke bronnen mogen voor deze taak worden gebruikt en aan deze persoon worden getoond?
Context is geen stapel tokens. Het is een graaf met tijd, autoriteit en grenzen.
Meer context zou meer bewijs moeten opleveren, niet meer vertrouwen zonder bewijs.
De echte werkeenheid is de verandering
Editors en codingtools zijn georganiseerd rond bestanden, omdat bestanden zijn wat we aanpassen. Engineeringteams zijn georganiseerd rond veranderingen.
Een verandering begint met een reden. Ze wordt een vereiste, raakt code en data, gaat door review, bereikt productie en creëert nieuw bewijs. Als die fasen los van elkaar blijven staan, begint elke toekomstige taak met weer een nieuwe ronde archeologie.
Een AI-systeem dat aan echte software werkt, zou die levenscyclus moeten volgen.
Vóór de implementatie moet het de aanvraag, de relevante beperkingen en eventuele conflicterende bronnen identificeren. Het moet weten of het een defect oplost, verwacht gedrag wijzigt of een nieuw contract introduceert.
Tijdens de implementatie moet het elke betekenisvolle keuze verbinden aan bewijs. Waarom deze module? Waarom deze migratiestrategie? Waarom deze branch behouden? De uitleg moet blijven bestaan, ook nadat de chat die de code heeft voortgebracht voorbij is.
Na implementatie moet het verificatieresultaten, reviewbeslissingen en nieuw ontdekte beperkingen aan de wijziging koppelen. Anders zal de volgende persoon — of de volgende AI-sessie — die opnieuw moeten ontdekken.
Dat is het verschil tussen een tool die een repository kan bewerken en een systeem dat kan meedraaien in engineeringwerk.
AI moet reconstructie verminderen, niet beoordelingsvermogen vervangen
Betere context wordt soms gepresenteerd als een route naar autonome softwareontwikkeling. De directe waarde is minder spectaculair en nuttiger: de kosten verlagen van het reconstrueren van de werkelijkheid voordat er een wijziging wordt aangebracht.
AI kan de oorspronkelijke vereiste naast de relevante code zetten. Het kan het incident naar voren halen dat een ongebruikelijke beveiliging verklaart. Het kan een falende metric koppelen aan de release die die heeft veranderd. Het kan laten zien dat twee gezaghebbende bronnen elkaar tegenspreken voordat de implementatie begint.
Die mogelijkheden nemen engineeringoordeel niet weg. Ze zorgen ervoor dat dat oordeel beter onderbouwd is.
Iemand moet nog steeds beslissen welke afweging aanvaardbaar is, of een vereiste volledig is en hoeveel risico een release kan dragen. Het systeem moet het bewijs zichtbaar maken en de redenering controleerbaar. Het moet onzekerheid niet verbergen achter een gelikte patch.
De maatstaf is niet: “kan het code genereren?”
De maatstaf is: “kan het uitleggen waarom dit nu de juiste wijziging is?”
Van repository-bewust naar werk-bewust
Coding-assistenten werden voor het eerst nuttig doordat ze het bestand voor de ontwikkelaar begrepen. Repository-bewustzijn was de volgende grote stap: gerelateerde code vinden, symbolen volgen en wijzigingen in een project doorvoeren.
De volgende stap is bewustzijn van het werk rondom de repository.
Dat betekent code verbinden met de specificatie die erom vroeg, het gesprek dat die verduidelijkte, het productiebewijs dat die ter discussie stelde en de beslissing die daarna onthouden moet worden. Het betekent ook context uitsluiten die irrelevant, verouderd of buiten de rechten van de gebruiker valt.
Tijdens het bouwen van Dvina is dit een van de ideeën waar we steeds op terugkomen. Werk vindt niet plaats binnen één enkel bestand, één applicatie of één gesprek. Betekenis leeft in de verbindingen ertussen en in hoe die verbindingen in de loop van de tijd veranderen.
De repository blijft essentieel. Het is de uitvoerbare bron van waarheid voor systeemgedrag. Het is alleen niet de volledige bron van waarheid voor productintentie, operationele realiteit of organisatorisch geheugen.
Het volledige verhaal verandert wat er wordt gebouwd
Met alleen de code is de logische vraag:
Welke wijziging past bij dit systeem?
Met de bredere context wordt de vraag:
Welke wijziging past bij dit systeem, deze vereiste, deze geschiedenis en dit moment?
Die tweede vraag brengt beperkingen aan het licht voordat ze regressies worden. Ze geeft reviewers de onderbouwing achter de implementatie. Ze helpt nieuwe teamleden te begrijpen waarom het systeem eruitziet zoals het eruitziet. Ze geeft AI een gegronde rol: niet als een orakel in de editor, maar als een deelnemer die bewijs uit het hele werk kan samenbrengen.
Je repo was nooit het hele verhaal.
De kans ligt in het bouwen van systemen die ook de rest ervan kunnen lezen — en hun werk kunnen laten zien.
