Öppna ett repo sex månader efter att en funktion lanserats, så kan du återskapa mycket. Du kan följa arkitekturen, granska schemat, läsa testerna och se exakt vilka rader som ändrades.
Det du vanligtvis inte kan återskapa är samtalet som gjorde de raderna nödvändiga.
Koden kommer inte att tala om för dig att en valideringsregel finns därför att en kund skickar felaktigt formaterade exporter. Den kommer inte att förklara att en märklig återförsökspolicy förhindrar dubbla transaktioner i ett nedströmsystem. Den kommer inte att visa att det renare gränssnittet avvisades efter ett tillgänglighetstest, eller att en tjänstegräns speglar en avtalsmässig begränsning snarare än en teknisk preferens.
Git är utmärkt på att bevara kodhistorik. Det bevarar avsikten bara när ett team medvetet skriver ner den och håller den kopplad till implementationen.
Det glappet har alltid varit en del av mjukvaruutveckling. AI-verktyg för kodning gör det mer synligt. Ett system kan läsa varje fil i ett repo, följa varje symbol och generera en tekniskt övertygande patch och ändå lösa fel problem.
Problemet är inte att koden är vilseledande. Koden besvarar en snävare fråga.
Fem lager av teknisk sanning
De flesta meningsfulla förändringar i mjukvara bygger på fem olika lager av underlag.
- Avsikt — Vilket resultat efterfrågar användaren, kunden eller verksamheten? Det kan finnas i en specifikation, en ticket, en supportkonversation eller en mötesanteckning.
- Begränsningar — Vad får inte gå sönder? Kompatibilitetslöften, säkerhetsgränser, regleringar, avtal, budgetar och deadlines finns ofta utanför repot.
- Implementation — Hur fungerar systemet i dag? Koden, testerna, scheman, beroenden och driftsättningskonfigurationen utgör detta lager.
- Driftunderlag — Vad händer i det verkliga systemet? Loggar, spårningar, mätvärden, produktionsdata och incidentrapporter kan motsäga antaganden som ser rimliga ut i koden.
- Beslutshistorik — Varför valdes den nuvarande lösningen? Pull requests, designdiskussioner, förkastade alternativ och tidigare incidenter rymmer svaret.
Repot är starkast i det tredje lagret. Det innehåller delar av de andra, men sällan tillräckligt för att representera dem fullt ut.
Det här spelar roll eftersom mjukvarufel ofta uppstår i gränserna mellan lagren. Implementationen stämmer med en inaktuell specifikation. Fixen uppfyller ticketen men bryter mot en operativ begränsning. Testerna går igenom eftersom de kodar gårdagens antaganden. Koden är internt konsekvent medan produktionsdata följer ett mönster som ingen dokumenterade.
En lokalt korrekt patch kan fortfarande vara fel ändring.
Vad kodbasen inte kan besvara på egen hand
Tänk dig en användare som redigerar ett dokument och sedan söker efter den uppdaterade meningen, men bara ser den gamla versionen i resultaten. ”Få sökningen att uppdateras omedelbart” låter som en tydlig begäran. Kodbasen visar flera möjliga ställen att börja på, men den kan inte på egen hand avgöra vad den korrekta lösningen är.
| Fråga | Trolig källa |
|---|---|
| Vilken version av dokumentet är den auktoritativa? | Källdokumentet och revisionshistoriken |
| Var finns den gamla texten kvar? | Synkroniseringsloggar, extraktionsutdata, sökindex eller cache |
| Vad betyder ”omedelbart” för den här produkten? | Produktlöfte eller tjänstenivåmål |
| Ändrades dokumentets behörigheter tillsammans med innehållet? | Källbehörigheter och granskningshistorik |
| Är det inaktuella resultatet begränsat till en användare, källa eller region? | Begäranspår och produktionsmått |
Sökkoden kan förklara hur resultat returneras. Den kan inte tala om för dig om det verkliga felet är synkroniseringsfördröjning, inaktuell extraktion, cacheinvalidering, behörighetspropagering eller en förväntning som produkten aldrig definierade.
Den här skillnaden blir ännu viktigare i mogna system. Ett fält som ser föråldrat ut kan fortfarande stödja en äldre klient. En tjänst som ser duplicerad ut kan hålla isär data med olika behörighetskrav. En kontroll som verkar överdriven kan vara det enda spåret i koden av en produktionsincident som det nuvarande teamet aldrig såg.
Att ta bort komplexitet är värdefullt. Att ta bort historia som ser ut som komplexitet är dyrt.
Mer kontext kan fortfarande ge fel svar
Den uppenbara lösningen är att ge AI:n mer material: hela kodbasen, varje ticket, varje dokument, varje meddelande och varje logg.
Det skapar tillgång, inte förståelse.
Källor kan vara inaktuella, motsägelsefulla, spekulativa eller skrivna för olika målgrupper. En brainstorming ska inte väga tyngre än en godkänd specifikation. Ett sex månader gammalt krav ska inte tyst åsidosätta gårdagens produktbeslut. En produktionslogg ska kopplas till den release, miljö och kodväg som skapade den. En kundförfrågan ska inte behandlas som ett universellt krav utan att omfattningen först kontrolleras.
Ett seriöst kontextsystem behöver därför mer än bara hämtning. Det behöver ett sätt att resonera om:
- Auktoritet: Vilken källa får definiera kravet?
- Aktualitet: Vilken information är aktuell, och vad har ersatts?
- Härkomst: Varifrån kommer varje påstående, begränsning eller slutsats?
- Relationer: Vilka ärenden, releaser, kunder, dataset och kodvägar hör ihop?
- Behörigheter: Vilka källor får användas för den här uppgiften och visas för den här personen?
Kontext är inte en hög med token. Det är en graf med tid, auktoritet och gränser.
Mer kontext bör ge mer underlag, inte större säkerhet utan underlag.
Den verkliga arbetsenheten är förändringen
Redigerare och kodverktyg är organiserade kring filer eftersom filer är det vi ändrar. Ingenjörsteam är organiserade kring förändringar.
En förändring börjar med en anledning. Den blir till ett krav, berör kod och data, går igenom granskning, når produktion och skapar nytt underlag. Om de stegen förblir frånkopplade börjar varje framtida uppgift med ännu en omgång arkeologi.
Ett AI-system som arbetar med verklig programvara bör följa den livscykeln.
Före implementation, bör det identifiera begäran, de relevanta begränsningarna och eventuella motstridiga källor. Det bör veta om det rättar ett fel, ändrar förväntat beteende eller inför ett nytt kontrakt.
Under implementationen, bör det koppla varje meningsfullt val till underlag. Varför den här modulen? Varför den här migreringsstrategin? Varför bevara den här grenen? Förklaringen bör leva kvar bortom chatten som producerade koden.
Efter implementeringen bör den koppla verifieringsresultat, granskningsbeslut och nyupptäckta begränsningar till ändringen. Annars måste nästa person – eller nästa AI-session – återupptäcka dem.
Det är skillnaden mellan ett verktyg som kan redigera ett repository och ett system som kan delta i ingenjörsarbetet.
AI bör minska behovet av rekonstruktion, inte ersätta omdöme
Bättre kontext framställs ibland som en väg till autonom mjukvaruutveckling. Det omedelbara värdet är mindre dramatiskt och mer användbart: att minska kostnaden för att återskapa verkligheten innan en ändring görs.
AI kan placera det ursprungliga kravet bredvid den relevanta koden. Den kan lyfta fram incidenten som förklarar en ovanlig skyddsåtgärd. Den kan koppla ett fallerande mätvärde till den release som förändrade det. Den kan visa att två auktoritativa källor är oense innan implementeringen börjar.
De förmågorna tar inte bort ingenjörsmässigt omdöme. De gör omdömet bättre informerat.
En människa måste fortfarande avgöra vilken avvägning som är acceptabel, om ett krav är fullständigt och hur mycket risk en release kan bära. Systemet bör göra underlaget synligt och resonemanget granskningsbart. Det bör inte dölja osäkerhet bakom en välpolerad patch.
Måttstocken är inte ”kan den generera kod?”
Måttstocken är ”kan den förklara varför detta är rätt ändring just nu?”
Från repository-medveten till arbetsmedveten
Kodassistenter blev först användbara genom att förstå filen framför utvecklaren. Repository-medvetenhet var nästa stora steg: att hitta relaterad kod, följa symboler och tillämpa ändringar i ett helt projekt.
Nästa steg är medvetenhet om arbetet runt repositoryt.
Det innebär att koppla koden till specifikationen som efterfrågade den, samtalet som förtydligade den, produktionsunderlaget som ifrågasatte den och beslutet som bör kommas ihåg efteråt. Det innebär också att utesluta kontext som är irrelevant, inaktuell eller utanför användarens behörigheter.
När vi bygger Dvina är detta en av idéerna vi ständigt återkommer till. Arbete sker inte i en enskild fil, applikation eller konversation. Meningen finns i kopplingarna mellan dem och i hur dessa kopplingar förändras över tid.
Repositoryt är fortfarande avgörande. Det är den körbara sanningskällan för systemets beteende. Det är bara inte den fullständiga sanningskällan för produktavsikt, operativ verklighet eller organisatoriskt minne.
Hela berättelsen förändrar vad som byggs
Med bara koden är den naturliga frågan:
Vilken ändring passar det här systemet?
Med den bredare kontexten blir frågan:
Vilken ändring passar det här systemet, det här kravet, den här historiken och det här ögonblicket?
Den där andra frågan fångar upp begränsningar innan de blir regressioner. Den ger granskare resonemanget bakom implementationen. Den hjälper nya teammedlemmar att förstå varför systemet ser ut som det gör. Den ger AI en förankrad roll: inte som ett orakel i editorn, utan som en deltagare som kan sammanställa underlag från hela arbetet.
Ditt repo har aldrig varit hela berättelsen.
Möjligheten är att bygga system som kan läsa resten av den — och visa sitt arbete.
