Koľko v ére AI skutočne stojí migrácia legacy kódu
Vendor lock-in v skutočnosti nikdy nebol o samotnom dodávateľovi. Bol o nákladoch na presun kódu. Tieto náklady práve skolabovali.
Vráťme sa do roku 2024, predtým, než AI zmenila spôsob, akým vyvíjame softvér.
Vtedy, keď nás klient požiadal o prevzatie softvéru, ktorý vyvinulo iné štúdio, nikdy sme ho priamo neodmietli. Boli sme však úprimní: bude to bolieť a bude to stáť viac, než dúfate. To nebola prehnaná opatrnosť, ale férové zhodnotenie reality. Prevziať cudzí codebase bolo naozaj náročné a drahé, a my sme s tým rátali hneď od začiatku. Pochopiť ho, refaktorovať a spätne vytvoriť dokumentáciu priamo z kódu mohlo zabrať celé týždne predtým, než sme vôbec nasadili niečo nové. Túto realitu sme premietli do ceny a nejeden klient sa rozhodol, že mu to za to nestojí. A presne tieto náklady vás držali v pasci u dodávateľa, ktorého ste už dávno prerástli.
Pasca, ktorá vás drží u nesprávneho dodávateľa
Pozrite sa na ten istý moment z pohľadu klienta. Nejaké štúdio pre vás vyvinulo systém kritický pre vaše podnikanie a váš vzťah začal škrípať. Možno ich projekt prerástol. Možno to robil jeden freelancer, ktorý na vás už nemá čas. Alebo zvýšili ceny, pretože vedeli, že od nich len tak ľahko neodídete.
Rozhodnete sa teda odísť. Obvoláte iné štúdiá. A zistíte, že to vôbec nie je také jednoduché. Skoro nikomu sa do prevzatia existujúceho kódu nechce, a to z jedného alebo viacerých z týchto dôvodov:
- Chýbajú im doménové znalosti, ktoré si pôvodný tím budoval roky.
- Kód je nekvalitný, pretože bol jednoducho tak napísaný.
- Kód je nekvalitný, pretože bol transpilovaný alebo obfuskavaný, čiže zámerne upravený tak, aby s ním nikto iný nedokázal pracovať.
- Neexistuje k nemu žiadna dokumentácia.
Každý z týchto dôvodov je reálny. Pochopiť, refaktorovať a zdokumentovať neznámy codebase by si vyžadovalo týždne práce ešte predtým, než vôbec nasadíte prvú novú funkciu. Takže si vypočujete úprimný verdikt: potrebuje to prepis a bude to stáť veľa peňazí. A tak sa potichu vrátite k pôvodnému dodávateľovi, stále rovnako zaseknutí.
„Skutočný vendor-lock nie je zmluva. Sú to v skutočnosti náklady na presun vášho kódu. Dnes už nie.“
Čo sa zmenilo
A tu prichádza zásadný posun. Vo vývoji poháňanom AI je dokumentácia všetkým — a tá už viac nemusí byť niečím, čo musel človek osobne sadnúť a napísať.
AI dokáže čítať kód, a to vrátane legacy kódu, ktorý nikdy predtým nevidela, a premeniť ho na vysvetlenie zrozumiteľné pre ľudí. Táto jediná schopnosť odomyká všetko ostatné. Teraz dokážeme:
- Vygenerovať doménovú dokumentáciu z logiky ukrytej hlboko v legacy codebase.
- Refaktorovať nekvalitný kód, bez ohľadu na to, či bol zle napísaný, alebo takýmto spôsobom transpilovaný.
- Preniesť kód na iný stack.
- Vygenerovať technickú dokumentáciu pre samotný kód.
Praktický výsledok: náklady na prevzatie codebase klesli na zlomok pôvodnej sumy. To, čo bolo predtým kvôli vysokým nákladom neekonomické refaktorovať, je dnes plne realizovateľné.
Pre mňa osobne bolo najväčším odomknutím možností to, že nás prestal obmedzovať stack. Systém napísaný v technológii, v ktorej sme doteraz nič nenasadili, už pre nás neznamená automatické „nie“, pretože ho dokážeme prepísať do stabilnejšieho a známejšieho stacku, o ktorý sa dokážeme starať celé roky.
Prečo tomu môžete veriť
„AI uľahčuje prevzatie legacy kódu“ je presne tá veta, ktorú čoskoro začne hovoriť každá druhá agentúra. Ukážeme vám preto, čo v skutočnosti robíme my — proces sa totiž predstiera oveľa ťažšie ako samotné sľuby.
Predtým, než na čokoľvek siahneme, zdokumentujeme doménu. Človek na našej strane musí pochopiť, čo systém robí a prečo, aby sme vedeli urobiť kľúčové rozhodnutia tam, kde AI narazí na svoje limity. Nad legacy codebase spustíme dedikovaný Claude skill, ktorý zdokumentuje každý modul a jeho logiku. Výstupom je de facto doménová príručka: princípy celého systému, rekonštruované priamo z kódu, ktorý ich vykonáva.
Prácu rozdelíme a potom ju posielame do cyklu špecializovaných agentov. Refaktorovanie alebo prechod na novú platformu prebieha ako štruktúrovaný proces:
- Zanalyzujeme codebase a rozdelíme ho na moduly, teda funkčné skupiny kódu. V CRM sú takýmto modulom napríklad „Kontakty“.
- Každý modul rozdelíme na konkrétne úlohy: prepísanie controllerov pre kontakty, modelov a frontendu. Samotné toto rozdelenie je už súčasťou tvorby dokumentácie.
- Človek skontroluje, či tieto úlohy dávajú zmysel a či celková architektúra drží pohromade.
Potom každá úloha prechádza cyklom, kde má každú prácu na starosti samostatný agent:
- jeden úlohu naimplementuje,
- ďalší napíše backendové testy,
- ďalší napíše end-to-end testy,
- ďalší zrecenzuje výsledok,
- ďalší spustí kontrolu zhody (parity check): AI vizuálne porovná refaktorovanú obrazovku s pôvodnou a vypočíta odchýlku.
Akýkoľvek agent v tomto cykle môže vrátiť úlohu späť implementátorovi na opravu toho, čo našiel. Povolenú odchýlku nastavujeme zámerne, napríklad okolo 5 %, pretože snaha o dosiahnutie pixel-perfect presnosti pri marginoch a paddingoch je zaručený spôsob, ako sa nekonečne zacykliť bez reálneho úžitku.
Celý cyklus uzatvára človek. Na konci skontrolujeme celú migráciu, prejdeme si všetko, čo agenti označili, a na základe našich zistení často vytvoríme ešte niekoľko ďalších úloh predtým, než spustíme ďalšie kolo.
Všimnite si celú tú štruktúru: AI robí masívny objem práce, kým ľudia majú pod kontrolou vyhodnocovanie na oboch koncoch. To je hlavný dôvod, prečo na konci dostanete udržateľný systém, a nie len kopu zdanlivo správneho kódu.
Nedávny príklad, pri ktorom budem kvôli dohode o mlčanlivosti (NDA) hovoriť len vo všeobecnosti: neznámy codebase s približne 10 modulmi a zhruba 50 obrazovkami sme preniesli na úplne iný stack. Päť dní. Starým spôsobom by len snaha o jeho pochopenie, migrácia a ručné otestovanie každej obrazovky zabrali niekoľko mesiacov práce. V tomto rozdiele spočíva celý zmysel.
Kde sa stále skrýva háčik
Úprimné obmedzenie, a to veľmi reálne: tento postup si dobre poradí s nekvalitným kódom. Nedokáže však automaticky vyriešiť nesprávny kód.
Ak legacy systém nie je len chaotický, ale priamo logicky chybný (napríklad nejaký výpočet v ňom funguje potichu nesprávne už roky), AI nemá ako vedieť, či ide o bug, alebo o vaše zámerné, hoci netradičné, biznis pravidlo. Ak to necháme tak, bez váhania prenesie túto chybu aj do nového systému. Pred samotnou refaktorizáciou preto najprv vyhľadávame tieto slabé miesta: chybné výpočty a logiku, ktorá nedáva zmysel. Tieto opravy zapracujeme priamo do zadaní, takže výsledný kód bude správny, a nebude len krajšou kópiou tej istej chyby.
Čo si z toho odniesť
Ak zostávate u dodávateľa, ktorého ste už prerástli, len preto, že presun sa vám zdá príliš drahý, vaše prepočty sú už zastarané.
To, čo bývalo drahou prekážkou a mimoriadne účinnou formou vendor lock-inu, je dnes zvládnuteľný, prevažne jednorazový náklad. Zastaraný stack, neudržateľný kód alebo tím, ktorý stratil záujem: nič z toho už nemusí byť trvalým stavom.
Ak máte presne takýto codebase, spravíme vám bezplatný audit, povieme vám na rovinu, v akom je stave, a navrhneme cenu za prevzatie spolu s ďalším postupom. Žiadny reflex v štýle „prepíšme to od nuly“. Iba férové zhodnotenie toho, čo je potrebné urobiť, aby ste sa pohli z miesta. Dajte nám vedieť!