Otevřete repozitář šest měsíců po nasazení funkce a dokážete zrekonstruovat mnohé. Můžete vysledovat architekturu, prozkoumat schéma, přečíst si testy a přesně vidět, které řádky se změnily.
Co obvykle zrekonstruovat nedokážete, je konverzace, kvůli níž byly tyto řádky potřeba.
Kód vám neřekne, že validační pravidlo existuje proto, že jeden zákazník posílá chybně formátované exporty. Nevysvětlí, že zvláštní politika opakování požadavků brání duplicitním transakcím v navazujícím systému. Neukáže, že čistší rozhraní bylo zamítnuto po testu přístupnosti, ani že hranice služby odráží smluvní omezení, nikoli technickou preferenci.
Git je skvělý v uchovávání historie kódu. Záměr uchovává jen tehdy, když ho tým záměrně zapíše a udržuje propojený s implementací.
Tato mezera byla vždy součástí softwarového inženýrství. AI nástroje pro psaní kódu ji jen zviditelňují. Systém může přečíst každý soubor v repozitáři, sledovat každý symbol a vygenerovat technicky přesvědčivý patch, a přesto stále řešit špatný problém.
Problém není v tom, že by kód byl zavádějící. Kód jen odpovídá na užší otázku.
Pět vrstev technické pravdy
Většina smysluplných změn v softwaru závisí na pěti různých vrstvách důkazů.
- Záměr — O jaký výsledek uživatel, zákazník nebo firma žádá? To může být ve specifikaci, ticketu, konverzaci se supportem nebo poznámce ze schůzky.
- Omezení — Co se nesmí rozbít? Přísliby kompatibility, bezpečnostní hranice, regulace, smlouvy, rozpočty a termíny často leží mimo repozitář.
- Implementace — Jak systém funguje dnes? Tuto vrstvu tvoří kód, testy, schémata, závislosti a konfigurace nasazení.
- Důkazy z provozu — Co se děje ve skutečném systému? Logy, traces, metriky, produkční data a incident reporty mohou odporovat předpokladům, které v kódu vypadají rozumně.
- Historie rozhodnutí — Proč byl zvolen současný přístup? Odpověď nesou pull requesty, diskuse o návrhu, zamítnuté alternativy a předchozí incidenty.
Repozitář je nejsilnější ve třetí vrstvě. Obsahuje části těch ostatních, ale jen zřídka natolik, aby je reprezentoval úplně.
Na tom záleží, protože selhání softwaru se často objevují na hranicích mezi vrstvami. Implementace odpovídá zastaralé specifikaci. Oprava splní ticket, ale poruší provozní omezení. Testy procházejí, protože kódují včerejší předpoklady. Kód je vnitřně konzistentní, zatímco produkční data sledují vzorec, který nikdo nezdokumentoval.
Lokálně správný patch může být stále špatnou změnou.
Na co samotný repozitář nedokáže odpovědět
Představte si uživatele, který upraví dokument a pak vyhledá aktualizovanou větu, jen aby ve výsledcích viděl starou verzi. „Zařiďte, aby se vyhledávání aktualizovalo okamžitě“ zní jako jasný požadavek. Repozitář odhalí několik možných míst, kde začít, ale sám o sobě nedokáže určit správnou opravu.
| Otázka | Pravděpodobný zdroj |
|---|---|
| Která verze dokumentu je směrodatná? | Zdrojový dokument a historie revizí |
| Kde starý text zůstává? | Synchronizační logy, výstup extrakce, vyhledávací index nebo cache |
| Co v tomto produktu znamená „okamžitě“? | Produktový příslib nebo servisní cíl |
| Změnila se spolu s obsahem dokumentu i jeho oprávnění? | Zdrojová oprávnění a historie auditu |
| Je zastaralý výsledek omezený na jednoho uživatele, zdroj nebo region? | Trasování požadavků a produkční metriky |
Kód vyhledávání může vysvětlit, jak se vracejí výsledky. Nedokáže vám ale říct, zda je skutečnou chybou zpoždění synchronizace, zastaralá extrakce, invalidace cache, propagace oprávnění nebo očekávání, které produkt nikdy nedefinoval.
Toto rozlišení je v zavedených systémech ještě důležitější. Pole, které vypadá zastarale, může stále podporovat staršího klienta. Služba, která působí jako duplicitní, může oddělovat data s odlišnými požadavky na oprávnění. Kontrola, která se zdá přehnaná, může být jedinou stopou v kódu po produkčním incidentu, který současný tým nikdy nezažil.
Odstraňovat složitost je cenné. Odstraňovat historii převlečenou za složitost je drahé.
I více kontextu může vést ke špatné odpovědi
Zjevné řešení je dát AI více materiálu: celý repozitář, každý ticket, každý dokument, každou zprávu a každý log.
To vytváří přístup, ne porozumění.
Zdroje mohou být zastaralé, rozporné, spekulativní nebo psané pro různé publikum. Brainstorming by neměl mít větší váhu než schválená specifikace. Požadavek starý šest měsíců by neměl tiše přebít včerejší produktové rozhodnutí. Produkční log by měl být svázán s releasem, prostředím a cestou v kódu, které ho vytvořily. Požadavek zákazníka by neměl být bez ověření rozsahu považován za univerzální požadavek.
Seriózní systém práce s kontextem proto potřebuje víc než jen vyhledávání. Potřebuje způsob, jak uvažovat o:
- Autoritě: Který zdroj smí definovat požadavek?
- Aktuálnosti: Které informace jsou platné nyní a které už byly nahrazeny?
- Původu: Odkud se vzalo každé tvrzení, omezení nebo závěr?
- Vztazích: Který problém, release, zákazník, dataset a cesta v kódu k sobě patří?
- Oprávněních: Které zdroje lze pro tento úkol použít a ukázat této osobě?
Kontext není hromada tokenů. Je to graf s časem, autoritou a hranicemi.
Více kontextu by mělo přinášet více důkazů, ne větší jistotu bez důkazů.
Skutečnou jednotkou práce je změna
Editory a nástroje pro psaní kódu jsou uspořádané kolem souborů, protože soubory jsou to, co upravujeme. Inženýrské týmy jsou uspořádané kolem změn.
Změna začíná důvodem. Stává se z ní požadavek, zasáhne kód i data, projde review, dostane se do produkce a vytvoří nové důkazy. Pokud tyto fáze zůstanou odpojené, každý budoucí úkol začne dalším kolem archeologie.
Systém AI pracující na skutečném softwaru by měl tento životní cyklus sledovat.
Před implementací by měl identifikovat požadavek, relevantní omezení a případné konfliktní zdroje. Měl by vědět, zda opravuje chybu, mění očekávané chování, nebo zavádí nový kontrakt.
Během implementace by měl každé smysluplné rozhodnutí propojit s důkazy. Proč tento modul? Proč tato migrační strategie? Proč zachovat tuto větev? Vysvětlení by mělo přetrvat i po skončení chatu, ve kterém kód vznikl.
Po implementaci by měl ke změně připojit výsledky ověření, rozhodnutí z revize a nově objevená omezení. Jinak je bude muset další člověk — nebo další AI relace — znovu objevit.
To je rozdíl mezi nástrojem, který umí upravovat repozitář, a systémem, který se dokáže podílet na inženýrské práci.
AI by měla omezovat rekonstruování, ne nahrazovat úsudek
Lepší kontext se někdy prezentuje jako cesta k autonomnímu vývoji softwaru. Jeho bezprostřední přínos je méně dramatický a užitečnější: snižuje náklady na rekonstrukci reality před provedením změny.
AI může přinést původní požadavek přímo k relevantnímu kódu. Může vytáhnout incident, který vysvětluje neobvyklou pojistku. Může propojit selhávající metriku s releasem, který ji změnil. Může ukázat, že se dva autoritativní zdroje rozcházejí ještě před začátkem implementace.
Tyto schopnosti nenahrazují inženýrský úsudek. Umožňují, aby byl lépe informovaný.
Člověk stále musí rozhodnout, který kompromis je přijatelný, zda je požadavek úplný a jaké riziko může release nést. Systém by měl zpřístupnit důkazy a umožnit kontrolu uvažování. Neměl by skrývat nejistotu za uhlazeným patchem.
Měřítkem není „umí generovat kód?“
Měřítkem je „dokáže vysvětlit, proč je tohle právě teď správná změna?“
Od povědomí o repozitáři k povědomí o práci
Asistenti pro psaní kódu se poprvé stali užitečnými ve chvíli, kdy začali rozumět souboru, který má vývojář právě před sebou. Povědomí o repozitáři bylo dalším velkým krokem: vyhledávání souvisejícího kódu, sledování symbolů a aplikace změn napříč projektem.
Dalším krokem je povědomí o práci, která se kolem repozitáře odehrává.
To znamená propojit kód se specifikací, která si ho vyžádala, s konverzací, která ji upřesnila, s produkčními důkazy, které ji zpochybnily, a s rozhodnutím, na které by se mělo pamatovat i později. Zároveň to znamená vyloučit kontext, který je nerelevantní, zastaralý nebo mimo oprávnění uživatele.
Při budování Dvina se k této myšlence neustále vracíme. Práce se neodehrává uvnitř jediného souboru, aplikace ani konverzace. Smysl vzniká ve vazbách mezi nimi a v tom, jak se tyto vazby v čase proměňují.
Repozitář zůstává zásadní. Je to spustitelný zdroj pravdy o chování systému. Jen zkrátka není úplným zdrojem pravdy o záměru produktu, provozní realitě ani organizační paměti.
Celý příběh mění to, co se nakonec vytvoří
Když máte jen kód, přirozená otázka zní:
Jaká změna se do tohoto systému hodí?
Se širším kontextem se otázka mění na:
Jaká změna se hodí do tohoto systému, k tomuto požadavku, k této historii a k tomuto okamžiku?
Právě tahle druhá otázka zachytí omezení dřív, než se z nich stanou regrese. Dává reviewerům vysvětlení, proč je implementace navržená právě takto. Pomáhá novým členům týmu pochopit, proč systém vypadá tak, jak vypadá. A dává AI ukotvenou roli: ne jako věštci uvnitř editoru, ale jako účastníkovi, který dokáže napříč prací shromažďovat důkazy.
Váš repozitář nikdy neobsahoval celý příběh.
Příležitost spočívá v budování systémů, které dokážou přečíst i zbytek — a ukázat, z čeho vycházejí.
