Dit repo var aldrig hele historien

Åbn et repository seks måneder efter, at en feature blev lanceret, og du kan rekonstruere meget. Du kan spore arkitekturen, inspicere skemaet, læse testene og se præcis, hvilke linjer der blev ændret.

Det, du som regel ikke kan rekonstruere, er den samtale, der gjorde de linjer nødvendige.

Koden fortæller dig ikke, at en valideringsregel findes, fordi én kunde sender fejlformaterede eksporter. Den forklarer ikke, at en mærkelig retry-politik forhindrer dublerede transaktioner i et downstream-system. Den viser ikke, at den renere grænseflade blev afvist efter en tilgængelighedstest, eller at en servicegrænse afspejler en kontraktmæssig begrænsning snarere end en teknisk præference.

Git er fremragende til at bevare kodehistorik. Det bevarer kun intentionen, når et team bevidst skriver den ned og holder den knyttet til implementeringen.

Det hul har altid været en del af software engineering. AI-kodeværktøjer gør det mere synligt. Et system kan læse hver eneste fil i et repository, følge hvert symbol og generere en teknisk overbevisende patch, mens det stadig løser det forkerte problem.

Problemet er ikke, at koden er misvisende. Koden besvarer et snævrere spørgsmål.

Fem lag af teknisk sandhed

De fleste meningsfulde softwareændringer afhænger af fem forskellige lag af evidens.

1. Intention — Hvilket resultat efterspørger brugeren, kunden eller virksomheden? Det kan stå i en specifikation, en ticket, en supportsamtale eller et mødenotat.
2. Begrænsninger — Hvad må ikke gå i stykker? Kompatibilitetsløfter, sikkerhedsgrænser, regulering, kontrakter, budgetter og deadlines ligger ofte uden for repositoriet.
3. Implementering — Hvordan fungerer systemet i dag? Koden, testene, skemaerne, afhængighederne og deploymentskonfigurationen udgør dette lag.
4. Driftsevidens — Hvad sker der i det virkelige system? Logs, traces, metrics, produktionsdata og hændelsesrapporter kan modsige antagelser, som ser rimelige ud i koden.
5. Beslutningshistorik — Hvorfor blev den nuværende tilgang valgt? Pull requests, designdiskussioner, forkastede alternativer og tidligere hændelser rummer svaret.

Repositoriet står stærkest i det tredje lag. Det indeholder dele af de andre, men sjældent nok til at repræsentere dem fuldstændigt.

Det er vigtigt, fordi softwarefejl ofte opstår i grænsefladerne mellem lagene. Implementeringen matcher en forældet specifikation. Løsningen opfylder ticketen, men bryder en driftsmæssig begrænsning. Testene består, fordi de indkoder gårsdagens antagelser. Koden er internt konsistent, mens produktionsdata følger et mønster, som ingen har dokumenteret.

En lokalt korrekt patch kan stadig være den forkerte ændring.

Hvad repositoryet ikke kan besvare af sig selv

Forestil dig en bruger, der redigerer et dokument og derefter søger efter den opdaterede sætning, men kun ser den gamle version i resultaterne. “Få søgningen til at opdatere med det samme” lyder som en klar anmodning. Repositoryet viser flere mulige steder at begynde, men det kan ikke i sig selv afgøre, hvad den rigtige løsning er.

Søgekoden kan måske forklare, hvordan resultater returneres. Den kan ikke fortælle dig, om den egentlige fejl er synkroniseringsforsinkelse, forældet ekstraktion, cache-invalidering, propagering af tilladelser eller en forventning, som produktet aldrig har defineret.

Denne skelnen bliver endnu vigtigere i modne systemer. Et felt, der ser forældet ud, kan stadig understøtte en legacy-klient. En tjeneste, der ligner en dublet, kan være adskilt for at håndtere data med forskellige tilladelseskrav. Et tilsyneladende overflødigt tjek kan være det eneste spor i koden efter en produktionshændelse, som det nuværende team aldrig har set.

Det er værdifuldt at fjerne kompleksitet. Det er dyrt at fjerne historik, der er forklædt som kompleksitet.

Mere kontekst kan stadig give det forkerte svar

Den oplagte løsning er at give AI'en mere materiale: hele repositoryet, alle tickets, alle dokumenter, alle beskeder og alle logge.

Det skaber adgang, ikke forståelse.

Kilder kan være forældede, modstridende, spekulative eller skrevet til forskellige målgrupper. En brainstorm bør ikke vægte højere end en godkendt specifikation. Et seks måneder gammelt krav bør ikke stiltiende tilsidesætte gårsdagens produktbeslutning. En produktionslog bør knyttes til den release, det miljø og den kodevej, der skabte den. En kundeanmodning bør ikke behandles som et universelt krav uden først at afklare omfanget.

Et seriøst kontekstsystem har derfor brug for mere end retrieval. Det har brug for en måde at ræsonnere om:

• Autoritet: Hvilken kilde må definere kravet?
• Aktualitet: Hvilken information er gældende nu, og hvad er blevet afløst?
• Proveniens: Hvor kommer hver påstand, begrænsning eller konklusion fra?
• Relationer: Hvilke issue, release, kunde, datasæt og kodevej hører sammen?
• Tilladelser: Hvilke kilder må bruges til denne opgave og vises til denne person?

Kontekst er ikke en bunke tokens. Det er en graf med tid, autoritet og grænser.

Mere kontekst bør give mere evidens, ikke mere sikkerhed uden evidens.

Den egentlige arbejdsenhed er ændringen

Editorer og kodeværktøjer er organiseret omkring filer, fordi filer er det, vi ændrer. Engineering-teams er organiseret omkring ændringer.

En ændring begynder med en årsag. Den bliver til et krav, berører kode og data, går gennem review, når produktion og skaber ny evidens. Hvis de stadier forbliver adskilte, begynder enhver fremtidig opgave med endnu en omgang arkæologi.

Et AI-system, der arbejder på rigtig software, bør følge den livscyklus.

Før implementering bør det identificere anmodningen, de relevante begrænsninger og eventuelle modstridende kilder. Det bør vide, om det retter en fejl, ændrer forventet adfærd eller indfører en ny kontrakt.

Under implementering bør det knytte hvert meningsfuldt valg til evidens. Hvorfor dette modul? Hvorfor denne migrationsstrategi? Hvorfor bevare denne gren? Forklaringen bør leve videre ud over den chat, der producerede koden.

Efter implementeringen bør den knytte verificeringsresultater, reviewbeslutninger og nyopdagede begrænsninger til ændringen. Ellers må den næste person — eller den næste AI-session — genopdage dem.

Det er forskellen mellem et værktøj, der kan redigere et repository, og et system, der kan deltage i ingeniørarbejde.

AI bør reducere rekonstruktion, ikke fjerne dømmekraft

Bedre kontekst bliver nogle gange fremstillet som en vej til autonom softwareudvikling. Den umiddelbare værdi er mindre dramatisk og mere nyttig: at reducere omkostningerne ved at rekonstruere virkeligheden, før man foretager en ændring.

AI kan bringe det oprindelige krav tættere på den relevante kode. Det kan fremhæve den hændelse, der forklarer en usædvanlig sikkerhedsforanstaltning. Det kan forbinde en fejlslagen metrik med den release, der ændrede den. Det kan vise, at to autoritative kilder er uenige, før implementeringen begynder.

De evner fjerner ikke ingeniørmæssig dømmekraft. De gør dømmekraften bedre informeret.

Et menneske skal stadig afgøre, hvilket tradeoff der er acceptabelt, om et krav er fuldstændigt, og hvor meget risiko en release kan bære. Systemet bør gøre evidensen synlig og ræsonnementet efterprøveligt. Det bør ikke skjule usikkerhed bag en poleret patch.

Standarden er ikke “kan det generere kode?”

Standarden er “kan det forklare, hvorfor dette er den rigtige ændring nu?”

Fra repository-bevidst til arbejdsbevidst

Kodningsassistenter blev først nyttige ved at forstå filen foran udvikleren. Repository-bevidsthed var det næste store skridt: at finde relateret kode, følge symboler og anvende ændringer på tværs af et projekt.

Det næste skridt er bevidsthed om arbejdet omkring repositoryet.

Det betyder at forbinde kode med den specifikation, der anmodede om den, den samtale, der præciserede den, den produktionsevidens, der udfordrede den, og den beslutning, der bør huskes bagefter. Det betyder også at udelukke kontekst, der er irrelevant, forældet eller uden for brugerens tilladelser.

Mens vi bygger Dvina, er dette en af de idéer, vi bliver ved med at vende tilbage til. Arbejde foregår ikke i én enkelt fil, applikation eller samtale. Mening lever i forbindelserne mellem dem og i, hvordan de forbindelser ændrer sig over tid.

Repositoryet er fortsat essentielt. Det er den eksekverbare kilde til sandhed for systemets adfærd. Det er bare ikke den fuldstændige kilde til sandhed for produktintention, operationel virkelighed eller organisatorisk hukommelse.

Hele historien ændrer, hvad der bliver bygget

Med kun koden er det naturlige spørgsmål:

Hvilken ændring passer til dette system?

Med den bredere kontekst bliver spørgsmålet:

Hvilken ændring passer til dette system, dette krav, denne historik og dette øjeblik?

Det andet spørgsmål opfanger begrænsninger, før de udvikler sig til regressioner. Det giver reviewere indsigt i tankerne bag implementeringen. Det hjælper nye teammedlemmer med at forstå, hvorfor systemet ser ud, som det gør. Det giver AI en forankret rolle: ikke som et orakel inde i editoren, men som en deltager, der kan samle evidens på tværs af arbejdet.

Dit repo var aldrig hele historien.

Muligheden er at bygge systemer, der kan læse resten af den – og vise deres arbejde.