Åpner du et repositorium seks måneder etter at en funksjon ble lansert, kan du rekonstruere mye. Du kan følge arkitekturen, inspisere skjemaet, lese testene og se nøyaktig hvilke linjer som ble endret.
Det du vanligvis ikke kan rekonstruere, er samtalen som gjorde disse linjene nødvendige.
Koden vil ikke fortelle deg at en valideringsregel finnes fordi én kunde sender feilformaterte eksporter. Den vil ikke forklare at en merkelig policy for nye forsøk hindrer dupliserte transaksjoner i et nedstrømssystem. Den vil ikke vise at det renere grensesnittet ble avvist etter en tilgjengelighetstest, eller at en tjenestegrense gjenspeiler en kontraktsmessig begrensning snarere enn en ingeniørfaglig preferanse.
Git er fremragende til å bevare kodehistorikk. Det bevarer intensjon bare når et team bevisst skriver den ned og holder den knyttet til implementeringen.
Dette gapet har alltid vært en del av programvareutvikling. AI-verktøy for koding gjør det mer synlig. Et system kan lese hver fil i et repositorium, følge hvert symbol og generere en teknisk overbevisende patch, og likevel løse feil problem.
Problemet er ikke at koden er misvisende. Koden svarer på et snevrere spørsmål.
Fem lag av ingeniørmessig sannhet
De fleste meningsfulle programvareendringer avhenger av fem ulike lag med bevis.
- Intensjon — Hvilket resultat ber brukeren, kunden eller virksomheten om? Dette kan ligge i en spesifikasjon, en sak, en supportsamtale eller et møtereferat.
- Begrensninger — Hva må ikke gå i stykker? Kompatibilitetsløfter, sikkerhetsgrenser, reguleringer, kontrakter, budsjetter og tidsfrister ligger ofte utenfor repositoriet.
- Implementering — Hvordan fungerer systemet i dag? Koden, testene, skjemaene, avhengighetene og distribusjonskonfigurasjonen utgjør dette laget.
- Kjøretidsbevis — Hva skjer i det virkelige systemet? Logger, spor, målinger, produksjonsdata og hendelsesrapporter kan motsi antakelser som ser rimelige ut i koden.
- Beslutningshistorikk — Hvorfor ble den nåværende tilnærmingen valgt? Pull requests, designdiskusjoner, forkastede alternativer og tidligere hendelser rommer svaret.
Repositoriet er sterkest i det tredje laget. Det inneholder deler av de andre, men sjelden nok til å representere dem fullstendig.
Dette er viktig fordi programvarefeil ofte oppstår i grensene mellom lagene. Implementeringen samsvarer med en utdatert spesifikasjon. Løsningen oppfyller saken, men bryter en operasjonell begrensning. Testene består fordi de koder gårsdagens antakelser. Koden er internt konsistent, mens produksjonsdata følger et mønster ingen dokumenterte.
En lokalt korrekt patch kan fortsatt være feil endring.
Hva repositoryet ikke kan svare på alene
Tenk deg en bruker som redigerer et dokument og deretter søker etter den oppdaterte setningen, bare for å få opp den gamle versjonen i resultatene. «Få søket til å oppdatere seg umiddelbart» høres ut som en tydelig forespørsel. Repositoryet viser flere mulige steder å begynne, men kan ikke definere den riktige løsningen på egen hånd.
| Spørsmål | Sannsynlig kilde |
|---|---|
| Hvilken versjon av dokumentet er autoritativ? | Kildedokument og revisjonshistorikk |
| Hvor finnes den gamle teksten fortsatt? | Synkroniseringslogger, ekstraksjonsutdata, søkeindeks eller cache |
| Hva betyr «umiddelbart» for dette produktet? | Produktløfte eller tjenestemål |
| Endret dokumentets tillatelser seg sammen med innholdet? | Kildetillatelser og revisjonshistorikk |
| Er det utdaterte resultatet begrenset til én bruker, kilde eller region? | Forespørselsspor og produksjonsmålinger |
Søkekoden kan forklare hvordan resultater returneres. Den kan ikke fortelle deg om den egentlige feilen er synkroniseringsforsinkelse, utdatert ekstraksjon, cache-invalidering, propagasjon av tillatelser eller en forventning produktet aldri har definert.
Dette skillet blir enda viktigere i modne systemer. Et felt som ser foreldet ut, kan fortsatt støtte en eldre klient. En tjeneste som ser ut til å være duplisert, kan skille data med ulike krav til tillatelser. En kontroll som tilsynelatende er overdreven, kan være det eneste sporet i koden etter en produksjonshendelse det nåværende teamet aldri har sett.
Å fjerne kompleksitet er verdifullt. Å fjerne historikk forkledd som kompleksitet er dyrt.
Mer kontekst kan fortsatt gi feil svar
Den åpenbare løsningen er å gi AI-en mer materiale: hele repositoryet, hver ticket, hvert dokument, hver melding og hver logg.
Det skaper tilgang, ikke forståelse.
Kilder kan være utdaterte, motstridende, spekulative eller skrevet for ulike målgrupper. En idémyldring bør ikke veie tyngre enn en godkjent spesifikasjon. Et krav som er seks måneder gammelt, bør ikke i stillhet overstyre gårsdagens produktbeslutning. En produksjonslogg bør knyttes til releasen, miljøet og kodebanen som produserte den. En kundeforespørsel bør ikke behandles som et universelt krav uten å kontrollere omfanget.
Et seriøst kontekstsystem trenger derfor mer enn bare gjenfinning. Det trenger en måte å resonnere om:
- Autoritet: Hvilken kilde har lov til å definere kravet?
- Aktualitet: Hvilken informasjon er gjeldende, og hva er blitt erstattet?
- Proveniens: Hvor kom hver påstand, begrensning eller konklusjon fra?
- Relasjoner: Hvilken sak, release, kunde, datasett og kodebane hører sammen?
- Tillatelser: Hvilke kilder kan brukes til denne oppgaven og vises til denne personen?
Kontekst er ikke en haug med tokens. Det er en graf med tid, autoritet og grenser.
Mer kontekst bør gi mer evidens, ikke mer selvtillit uten evidens.
Den virkelige arbeidsenheten er endringen
Redigeringsverktøy og kodeverktøy er organisert rundt filer fordi filer er det vi endrer. Ingeniørteam er organisert rundt endringer.
En endring starter med en grunn. Den blir til et krav, berører kode og data, går gjennom review, når produksjon og skaper ny evidens. Hvis disse stadiene forblir frakoblet, begynner hver fremtidige oppgave med enda en runde arkeologi.
Et AI-system som arbeider med ekte programvare, bør følge den livssyklusen.
Før implementering bør det identifisere forespørselen, de relevante begrensningene og eventuelle motstridende kilder. Det bør vite om det retter en feil, endrer forventet atferd eller innfører en ny kontrakt.
Under implementering bør det knytte hvert meningsfulle valg til evidens. Hvorfor denne modulen? Hvorfor denne migreringsstrategien? Hvorfor bevare denne branchen? Forklaringen bør overleve utover chatten som produserte koden.
Etter implementering bør det knytte verifiseringsresultater, gjennomgangsbeslutninger og nyoppdagede begrensninger til endringen. Ellers må neste person – eller neste AI-økt – oppdage dem på nytt.
Dette er forskjellen mellom et verktøy som kan redigere et repository, og et system som kan delta i ingeniørarbeid.
AI bør redusere behovet for rekonstruksjon, ikke fjerne skjønn
Bedre kontekst blir noen ganger fremstilt som en vei til autonom programvareutvikling. Den umiddelbare verdien er mindre dramatisk og mer nyttig: å redusere kostnaden ved å rekonstruere virkeligheten før man gjør en endring.
AI kan hente det opprinnelige kravet frem ved siden av den relevante koden. Det kan løfte frem hendelsen som forklarer en uvanlig sikkerhetsmekanisme. Det kan koble en sviktende metrikk til releasen som endret den. Det kan vise at to autoritative kilder er uenige før implementeringen begynner.
Disse egenskapene fjerner ikke ingeniørfaglig skjønn. De gjør skjønnet bedre informert.
En person må fortsatt avgjøre hvilket kompromiss som er akseptabelt, om et krav er fullstendig, og hvor mye risiko en release kan bære. Systemet bør gjøre evidensen synlig og resonnementet etterprøvbart. Det bør ikke skjule usikkerhet bak en glattpolert patch.
Standarden er ikke «kan det generere kode?»
Standarden er «kan det forklare hvorfor dette er den riktige endringen nå?»
Fra repository-bevisst til arbeidsbevisst
Kodeassistenter ble først nyttige ved å forstå filen foran utvikleren. Repository-bevissthet var neste store steg: å finne relatert kode, følge symboler og gjøre endringer på tvers av et prosjekt.
Neste steg er bevissthet om arbeidet rundt repository-et.
Det betyr å koble kode til spesifikasjonen som ba om den, samtalen som avklarte den, produksjonsevidensen som utfordret den, og beslutningen som bør huskes i etterkant. Det betyr også å utelate kontekst som er irrelevant, utdatert eller utenfor brukerens tillatelser.
Mens vi bygger Dvina, er dette en av ideene vi stadig vender tilbake til. Arbeid skjer ikke inne i én enkelt fil, applikasjon eller samtale. Mening finnes i forbindelsene mellom dem og i hvordan disse forbindelsene endrer seg over tid.
Repository-et er fortsatt avgjørende. Det er den kjørbare sannhetskilden for systemets oppførsel. Det er bare ikke den fullstendige sannhetskilden for produktintensjon, operasjonell virkelighet eller organisatorisk hukommelse.
Hele historien endrer hva som blir bygget
Med bare koden er det naturlige spørsmålet:
Hvilken endring passer dette systemet?
Med den bredere konteksten blir spørsmålet:
Hvilken endring passer dette systemet, dette kravet, denne historikken og dette øyeblikket?
Det andre spørsmålet fanger opp begrensninger før de blir til regresjoner. Det gir dem som gjennomgår endringene, innsikt i begrunnelsen bak implementeringen. Det hjelper nye teammedlemmer med å forstå hvorfor systemet ser ut som det gjør. Det gir AI en forankret rolle: ikke som et orakel inne i editoren, men som en deltaker som kan samle bevis på tvers av arbeidet.
Repoet ditt var aldri hele historien.
Muligheten ligger i å bygge systemer som kan lese resten av den – og vise arbeidet sitt.
