Nyiss meg egy repót hat hónappal azután, hogy egy funkció élesbe került, és rengeteg mindent vissza tudsz fejteni. Végigkövetheted az architektúrát, átvizsgálhatod a sémát, elolvashatod a teszteket, és pontosan láthatod, mely sorok változtak.
Amit viszont általában nem tudsz rekonstruálni, az a beszélgetés, amely szükségessé tette ezeket a sorokat.
A kód nem fogja elmondani, hogy egy validációs szabály azért létezik, mert egy ügyfél hibás exportokat küld. Nem magyarázza el, hogy egy furcsa újrapróbálkozási szabály miért akadályozza meg a duplikált tranzakciókat egy downstream rendszerben. Nem mutatja meg, hogy a letisztultabb felületet egy akadálymentességi teszt után vetették el, vagy hogy egy szolgáltatáshatár inkább szerződéses korlátozást tükröz, mint mérnöki preferenciát.
A Git kiválóan őrzi meg a kód történetét. A szándékot viszont csak akkor őrzi meg, ha a csapat tudatosan leírja azt, és kapcsolatban tartja a megvalósítással.
Ez a rés mindig is a szoftvermérnökség része volt. Az AI-alapú kódolási eszközök csak láthatóbbá teszik. Egy rendszer elolvashat minden fájlt egy repóban, követhet minden szimbólumot, és készíthet technikailag meggyőző patchet úgy is, hogy közben mégis a rossz problémát oldja meg.
A probléma nem az, hogy a kód félrevezető. A kód egy szűkebb kérdésre válaszol.
A mérnöki igazság öt rétege
A legtöbb érdemi szoftveres változtatás öt különböző bizonyítékrétegtől függ.
- Szándék — Milyen eredményt kér a felhasználó, az ügyfél vagy az üzlet? Ez lehet egy specifikációban, ticketben, supportbeszélgetésben vagy megbeszélési jegyzetben.
- Korlátok — Mi az, aminek nem szabad sérülnie? A kompatibilitási ígéretek, biztonsági határok, szabályozások, szerződések, költségkeretek és határidők gyakran a repón kívül találhatók.
- Megvalósítás — Hogyan működik ma a rendszer? Ezt a réteget a kód, a tesztek, a sémák, a függőségek és a telepítési konfiguráció adják.
- Futásidejű bizonyítékok — Mi történik a valódi rendszerben? A logok, trace-ek, metrikák, éles adatok és incidensjelentések ellentmondhatnak azoknak a feltételezéseknek, amelyek a kódban ésszerűnek tűnnek.
- Döntéstörténet — Miért a jelenlegi megközelítést választották? A pull requestek, a tervezési viták, az elvetett alternatívák és a korábbi incidensek adják meg a választ.
A repó a harmadik rétegben a legerősebb. Tartalmaz részeket a többiből is, de ritkán eleget ahhoz, hogy teljes egészében képviselje őket.
Ez azért fontos, mert a szoftverhibák gyakran a rétegek közötti határokon jelennek meg. A megvalósítás egy elavult specifikációnak felel meg. A javítás teljesíti a ticketet, de megsért egy működési korlátot. A tesztek azért mennek át, mert a tegnapi feltételezéseket kódolják. A kód belsőleg következetes, miközben az éles adatok egy olyan mintát követnek, amelyet senki sem dokumentált.
Egy lokálisan helyes patch még mindig lehet rossz változtatás.
Amire a repository önmagában nem tud választ adni
Képzeljünk el egy felhasználót, aki szerkeszt egy dokumentumot, majd rákeres a frissített mondatra, de a találatok között továbbra is a régi verzió jelenik meg. Az, hogy „a keresés azonnal frissüljön”, egyértelmű kérésnek hangzik. A repository több lehetséges kiindulópontot is feltár, de önmagában nem tudja meghatározni, mi a helyes javítás.
| Kérdés | Valószínű forrás |
|---|---|
| A dokumentum melyik verziója tekinthető hitelesnek? | Forrásdokumentum és verziótörténet |
| Hol marad meg a régi szöveg? | Szinkronizációs naplók, kinyerési kimenet, keresőindex vagy gyorsítótár |
| Mit jelent az, hogy „azonnal” ennél a terméknél? | Termékígéret vagy szolgáltatási célkitűzés |
| Változtak-e a dokumentum jogosultságai a tartalommal együtt? | Forrásjogosultságok és auditnapló |
| Az elavult találat egyetlen felhasználóra, forrásra vagy régióra korlátozódik? | Kérésnyomok és éles üzemi metrikák |
A keresési kód megmagyarázhatja, hogyan érkeznek vissza a találatok. Azt viszont nem tudja megmondani, hogy a valódi hiba szinkronizációs késés, elavult kinyerés, gyorsítótár-inaktiválás, jogosultságterjedés vagy egy olyan elvárás-e, amelyet a termék soha nem definiált.
Ez a különbségtétel kiforrott rendszerekben még fontosabbá válik. Egy mező, amely elavultnak tűnik, lehet, hogy még mindig egy örökölt klienst szolgál ki. Egy látszólag duplikált szolgáltatás elkülöníthet eltérő jogosultsági követelményekkel rendelkező adatokat. Egy túlzónak tűnő ellenőrzés pedig lehet, hogy az egyetlen kódszintű nyoma egy olyan éles üzemi incidensnek, amellyel a jelenlegi csapat soha nem találkozott.
Az összetettség leépítése értékes. A történelemnek álcázott összetettség törlése drága.
Több kontextus is vezethet rossz válaszhoz
A kézenfekvő megoldás az, hogy több anyagot adunk az AI-nak: a teljes repositoryt, minden ticketet, minden dokumentumot, minden üzenetet és minden naplót.
Ez hozzáférést teremt, nem megértést.
A források lehetnek elavultak, ellentmondásosak, spekulatívak, vagy eltérő közönségnek íródtak. Egy ötletelés nem írhatja felül egy jóváhagyott specifikációt. Egy hat hónapos követelmény nem írhatja felül csendben a tegnapi termékdöntést. Egy éles üzemi naplót ahhoz a kiadáshoz, környezethez és kódúthoz kell kötni, amely létrehozta. Egy ügyfélkérést nem szabad általános követelményként kezelni anélkül, hogy ellenőriznénk a hatókörét.
Egy komoly kontextusrendszernek ezért többre van szüksége, mint visszakeresésre. Szüksége van arra, hogy a következőkről tudjon következtetni:
- Autoritás: Melyik forrás jogosult meghatározni a követelményt?
- Időszerűség: Melyik információ aktuális, és mit váltottak már fel?
- Eredet: Honnan származik az egyes állítás, megkötés vagy következtetés?
- Kapcsolatok: Mely issue, kiadás, ügyfél, adatkészlet és kódút tartozik össze?
- Jogosultságok: Mely források használhatók ehhez a feladathoz, és melyek mutathatók meg ennek a személynek?
A kontextus nem tokenek halmaza. Hanem egy gráf idővel, autoritással és határokkal.
A több kontextusnak több bizonyítékot kell eredményeznie, nem több bizonyíték nélküli magabiztosságot.
A munka valódi egysége a változás
A szerkesztők és a kódolási eszközök fájlok köré szerveződnek, mert a fájlok azok, amelyeket módosítunk. A mérnöki csapatok változások köré szerveződnek.
Egy változás egy okkal kezdődik. Követelménnyé válik, érinti a kódot és az adatokat, átmegy a review-n, eljut élesbe, és új bizonyítékokat hoz létre. Ha ezek a szakaszok elszakadnak egymástól, minden jövőbeli feladat egy újabb régészeti körrel indul.
Egy valós szoftveren dolgozó AI-rendszernek ezt az életciklust kell követnie.
A megvalósítás előtt azonosítania kell a kérést, a releváns megkötéseket és az esetleges egymásnak ellentmondó forrásokat. Tudnia kell, hogy hibát javít, az elvárt viselkedést módosítja, vagy új szerződéses vállalást vezet be.
A megvalósítás során minden érdemi döntést bizonyítékhoz kell kapcsolnia. Miért ez a modul? Miért ez a migrációs stratégia? Miért kell megtartani ezt az ágat? A magyarázatnak túl kell élnie azt a chatet, amely a kódot létrehozta.
A megvalósítás után csatolnia kell a módosításhoz az ellenőrzési eredményeket, a felülvizsgálati döntéseket és az újonnan feltárt korlátokat. Ellenkező esetben a következő embernek — vagy a következő AI-munkamenetnek — újra fel kell tárnia ezeket.
Ez a különbség egy olyan eszköz között, amely képes szerkeszteni egy repót, és egy olyan rendszer között, amely részt tud venni a mérnöki munkában.
Az AI-nak az újraépítés terhét kell csökkentenie, nem az ítélőképességet kiváltania
A jobb kontextust néha az autonóm szoftverfejlesztéshez vezető útként mutatják be. A közvetlen értéke ennél kevésbé látványos, viszont hasznosabb: csökkenti a valóság újraépítésének költségét, mielőtt változtatás történne.
Az AI képes az eredeti követelményt a releváns kód mellé helyezni. Fel tudja hozni azt az incidenst, amely megmagyaráz egy szokatlan védelmi mechanizmust. Össze tud kapcsolni egy hibás metrikát azzal a kiadással, amely megváltoztatta. Meg tudja mutatni, hogy két hiteles forrás nem ért egyet még a megvalósítás megkezdése előtt.
Ezek a képességek nem váltják ki a mérnöki ítélőképességet. Inkább megalapozottabbá teszik azt.
Továbbra is embernek kell eldöntenie, melyik kompromisszum elfogadható, hogy egy követelmény teljes-e, és mekkora kockázatot hordozhat egy kiadás. A rendszernek láthatóvá kell tennie a bizonyítékokat, és ellenőrizhetővé kell tennie az érvelést. Nem szabad egy csiszolt patch mögé rejtenie a bizonytalanságot.
A mérce nem az, hogy „képes-e kódot generálni?”
A mérce az, hogy „meg tudja-e magyarázni, miért ez a helyes változtatás most?”
A repótudatostól a munkatudatosig
A kódolási asszisztensek először azzal váltak hasznossá, hogy megértették a fejlesztő előtt megnyitott fájlt. A repószintű tudatosság volt a következő nagy lépés: kapcsolódó kód megtalálása, szimbólumok követése és módosítások alkalmazása egy teljes projekten át.
A következő lépés a repó körüli munkára való rálátás.
Ez azt jelenti, hogy a kódot összekapcsoljuk azzal a specifikációval, amely kérte, azzal a beszélgetéssel, amely pontosította, azzal az éles üzemi bizonyítékkal, amely megkérdőjelezte, és azzal a döntéssel, amelyre később is emlékezni kell. Azt is jelenti, hogy kizárjuk azt a kontextust, amely irreleváns, elavult vagy kívül esik a felhasználó jogosultságain.
Dvina építése közben ez az egyik olyan gondolat, amelyhez újra és újra visszatérünk. A munka nem egyetlen fájlon, alkalmazáson vagy beszélgetésen belül történik. A jelentés a köztük lévő kapcsolatokban él, és abban, ahogyan ezek a kapcsolatok idővel változnak.
A repó továbbra is alapvető fontosságú. Ez a rendszer viselkedésének végrehajtható, elsődleges igazságforrása. Egyszerűen nem teljes igazságforrás a termékszándék, az operatív valóság vagy a szervezeti emlékezet szempontjából.
A teljes történet megváltoztatja, mi épül meg
Ha csak a kód áll rendelkezésre, a természetes kérdés ez:
Milyen változtatás illik ehhez a rendszerhez?
Tágabb kontextussal a kérdés ez lesz:
Milyen változtatás illik ehhez a rendszerhez, ehhez a követelményhez, ehhez az előzményhez és ehhez a pillanathoz?
Ez a második kérdés még azelőtt felszínre hozza a korlátokat, hogy regresszióvá válnának. Megadja az ellenőrzést végzőknek a megvalósítás mögötti érvelést. Segít az új csapattagoknak megérteni, miért úgy néz ki a rendszer, ahogy. Az AI-nak is megalapozott szerepet ad: nem mindentudóként a szerkesztőben, hanem olyan résztvevőként, amely a munka egészéből tud bizonyítékokat összerakni.
A repód sosem volt a teljes történet.
A lehetőség abban rejlik, hogy olyan rendszereket építsünk, amelyek a többit is el tudják olvasni — és meg is tudják mutatni, hogyan jutottak a következtetéseikre.
