Piątek, godzina siedemnasta. CEO wchodzi na calla i mówi do deva coś, co słyszę teraz od klientów co drugi tydzień: „This is insane. How did you build this in an afternoon?”. Ma na myśli moduł płatności, który AI wygenerowało w niecały dzień. W poniedziałek pyta, kiedy będzie druga waluta. We wtorek pyta, czy da się dorzucić rabaty grupowe „skoro to już prawie gotowe”.
Trzy miesiące później ten sam dev siedzi na callu i próbuje wytłumaczyć po angielsku, dlaczego dodanie jednego pola do formularza zajmuje teraz trzy dni, skoro cała funkcja powstała w jeden dzień. Nie ma dobrego zdania na to w żadnym języku. Ale po angielsku brakuje mu czegoś więcej niż słownictwa: brakuje mu ramy, w której „to działa” i „to jest zbudowane, żeby przetrwać” nie brzmią jak to samo zdanie.
To jest artykuł o tej ramie. I o tym, jak po angielsku poprosić o czas na coś, czego nikt w budżecie nie zaplanował, bo nikt nie planuje wydatku na coś, co „już działa”.
Liczby, które potwierdzają to, co czujesz w kościach
Zacznijmy od czegoś, czego nie musisz nikomu tłumaczyć na wyczucie, bo ktoś już to policzył. GitClear przeanalizował 211 milionów zmienionych linii kodu z lat 2020–2024, jedną z największych jak dotąd baz danych o tym, co faktycznie dzieje się w repozytoriach, nie w ankietach o satysfakcji z AI. Dwie liczby z tego raportu są warte zapamiętania, bo będziesz ich używał częściej niż jakiejkolwiek analogii z tego tekstu.
Między 2021 a 2024 rokiem udział zmienionych linii sklasyfikowanych przez GitClear jako skopiowane wzrósł z 8,3% do 12,3%. Udział linii przenoszonych — wskaźnika związanego z refaktoryzacją i ponownym użyciem kodu — spadł z 25% do poniżej 10%. Po raz pierwszy w historii tych pomiarów kopiuj-wklej wyprzedził refaktoryzację.
Przeczytaj to jeszcze raz, bo tu leży sedno tego artykułu: to nie jest dowód, że AI pisze zły kod. Sam raport nie dowodzi też, że AI jest przyczyną wszystkich zaobserwowanych zmian. Pokazuje trend w badanych repozytoriach: więcej kopiowania, mniej przenoszenia kodu. Dla zespołu to sygnał, by sprawdzić, czy tempo pisania nie wyprzedza tempa porządkowania. Koszt odkładanego porządkowania ma nazwę: dług techniczny. Sama metafora długu w programowaniu pochodzi z 1992 roku.
Dług, który ktoś już wymyślił, żebyś nie musiał
W 1992 roku Ward Cunningham opisał metaforę długu w tekście na konferencję OOPSLA. Pomagała wyjaśnić, dlaczego zespół potrzebuje czasu na porządkowanie kodu, zamiast wyłącznie dowozić nowe funkcje. To metafora, która przetrwała ponad trzydzieści lat, bo działa dokładnie tak, jak ma działać dobra analogia biznesowa: niesie cenę.
Ujął to mniej więcej tak: wypuszczenie kodu po raz pierwszy jest jak zaciągnięcie długu. Niewielki dług przyspiesza rozwój, dopóki jest szybko spłacany refaktoryzacją. Niebezpieczeństwo zaczyna się, gdy dług nie jest spłacany. Pożyczone pieniądze pozwalają zrobić coś wcześniej, niż byłoby to możliwe, ale dopóki nie oddasz kapitału, płacisz odsetki.
To jest najważniejsze zdanie w całym artykule, więc rozbijmy je na części, bo tu leży błąd, który widzę u połowy inżynierów próbujących sprzedać refaktoring nietechnicznemu odbiorcy: dług sam w sobie nie jest problemem. Problem pojawia się, gdy nikt go nie spłaca, a to jest dokładnie to, co robi vibe coding, jeśli zostawić go bez kontroli. Nie chodzi o to, żeby przekonać kogoś, że AI pisze zły kod. Chodzi o to, żeby przekonać kogoś, że przyspieszenie, które kupił, ma ratę, i że ta rata rośnie z każdym miesiącem, w którym nikt jej nie płaci.
Góra lodowa: to, co widać, i przyczyny ukryte pod wodą
Weźmy przykładową sytuację ilustrującą ten problem: AI wygenerowało logikę naliczania rabatów w module koszyka, ale zrobiło to w trzech różnych miejscach zamiast w jednym, bo o to akurat nikt go nie zapytał. Myślenie systemowe ma gotowy model, który pomaga wyjaśnić, dlaczego ten sam problem wraca, mimo że ktoś go już raz „naprawił”: model góry lodowej. Nad wodą widać pojedyncze zdarzenie. Pod wodą, coraz głębiej, leżą wzorce, struktury i przekonania, które pomagają wyjaśnić, dlaczego się powtarza.
“We refunded a customer 40 euros this morning because checkout applied the wrong discount.”
“It's the third refund for a pricing error this month, not a one-off.”
“The AI wrote the discount rule three times, in three separate files, and they've drifted apart.”
“Nobody scheduled time to check it, because code built in an afternoon looked finished.”
Cztery zdania, jeden problem, każde prawdziwe na swoim poziomie. Jeśli zaczniesz od struktury albo przekonania na spotkaniu z zarządem, usłyszysz „dodaj do backlogu”, bo nie mają punktu zaczepienia dla czegoś, czego jeszcze nie widzieli. Jeśli zaczniesz od zdarzenia, masz ich uwagę od pierwszego zdania, bo to jest dokładnie to, co już zauważyli. Dopiero wtedy schodzisz niżej, żeby pokazać, że to nie przypadek, tylko wzorzec, i że wzorzec ma strukturalną przyczynę, którą przy życiu trzyma jedno konkretne przekonanie.
To przekonanie ma w erze vibe codingu prawie zawsze tę samą treść: skoro AI zbudowało to w jedno popołudnie, to musi być gotowe do wdrożenia. Właśnie to zdanie stoi na dnie większości gór lodowych, które przychodzą do mnie na lekcje.
Trzy zasady pracy z tym modelem: zaczynasz od zdarzenia, które rozmówca zna. Schodzisz niżej, gdy pyta o przyczynę, albo pytasz, czy chce ją poznać: przeskok od razu do struktury brzmi jak wykład, nie jak odpowiedź. Kiedy już rozmawiacie o przyczynach, nazywasz również przekonanie, które utrwala problem. Bez zmiany sposobu planowania pracy nawet dobrze posprzątany kod może za kwartał znów wyglądać tak samo.
Kto siedzi naprzeciwko, kiedy prosisz o czas na sprzątanie
Kwoty i estymacje w poniższych przykładach pokazują sposób formułowania komunikatu. W rozmowie użyj własnych pomiarów i założeń.
Rozmowa o refaktoryzacji kodu z AI ma jedną specyfikę, której nie ma zwykła prośba o refaktoring: po drugiej stronie stołu siedzi ktoś, kto właśnie doświadczył magii. Widział, jak coś powstaje w godzinę. Twoja prośba o dwa tygodnie na „posprzątanie tego, co już działa” brzmi w jego uszach jak cofnięcie się w czasie do świata sprzed AI.
CEO zakochany w prędkości kupił szybkość, nie architekturę, i każda rozmowa o refaktoringu, która nie wspomina o prędkości, przegra.
- "The codebase needs refactoring. There's a lot of duplication."
+ "The speed you loved in week one is gone. Every new feature now touches five files instead of one. Two weeks gets that speed back."CFO kupuje przewidywalność. Kod wygenerowany przez AI, którego nikt dokładnie nie przejrzał, utrudnia jej zapewnienie: zespół nie wie jeszcze, co jest w środku. Tu działa dokładnie ta sama konwersja, co przy każdej estymacji: zamień widełki na scenariusz z ceną czekania.
- "We should probably clean up the code at some point."
+ "A feature that used to take five developer-days now takes six. That's one extra day per feature until we fix the duplicated logic."Sales, który obiecał klientowi „to jest już praktycznie zrobione”, bo widział demo zbudowane w weekend, jest najgroźniejszym rozmówcą w tej całej historii, bo działające demo i gotowy system produkcyjny to dwie różne rzeczy, nawet jeśli wyglądają identycznie na ekranie.
- "Yeah, the AI already built most of it."
+ "The demo works. Getting it ready for production is a separate piece of work: about three weeks. Here's what still needs to be done."Nietechniczny współzałożyciel albo inwestor myśli w kategoriach ryzyka i czasu, na który wystarczy firmie pieniędzy (runway), nie architektury. Jego pytanie brzmi zawsze tak samo, tylko przebrane za coś innego: co się stanie, jeśli tego nie zrobimy.
- "If we don't refactor, the architecture will become a problem."
+ "If we don't fix this now, the next outage during a traffic spike could cost us more than the fix does today."Warstwa językowa: słowa, które sabotują dobrą sprawę
To jest część, której nie znajdziesz w żadnym poradniku o „AI i biznesie”, bo te poradniki piszą ludzie, którzy nie słyszeli setek prób polskiego inżyniera przekonującego klienta po angielsku, że szybkie nie znaczy gotowe.
Rzeczownikowanie. Polski inżynier pod presją ucieka w konstrukcje rzeczownikowe, bo brzmią „poważnie”. W rozmowie o refaktoringu to jest podwójnie kosztowne, bo ukrywa dokładnie to, co chcesz pokazać: konkret i sprawcę.
- "The refactoring of the payment module will result in a reduction of code duplication and an improvement in maintainability."
+ "We'll refactor payments. Right now the same logic lives in three places. After this, it lives in one, and changes take a day, not a week."Fałszywi przyjaciele, którzy akurat tutaj kosztują najwięcej.
Genial nie znaczy „genialny”, tylko „serdeczny, pogodny” — opisuje zwykle człowieka lub jego sposób bycia. Gdy chwalisz rozwiązanie techniczne, dobierz słowo do tego, co naprawdę cenisz: a clever solution to „pomysłowe rozwiązanie”, a well-designed architecture to „dobrze zaprojektowana architektura”. Z kolei genuine znaczy „prawdziwy, autentyczny”: „This is a genuine improvement” to „To rzeczywista poprawa”.
Eventually nie znaczy „ewentualnie”, tylko „w końcu, ostatecznie”. „We'll eventually clean this up” słyszane przez CFO znaczy „nigdy nie ma konkretnej daty”, czyli dokładnie to zdanie, które pogrzebało niejeden refaktoring w tym artykule. Jeśli chodziło Ci o „być może”, użyj possibly albo we might. Jeśli o „w razie potrzeby”, użyj if needed.
Actual i actually nie znaczą „aktualny” i „aktualnie”, tylko „rzeczywisty” i „w rzeczywistości”. „The actual cost of this feature is higher than we expected” mówi coś zupełnie innego niż „the current cost”, i to jest różnica, którą warto umieć nazwać precyzyjnie, kiedy tłumaczysz cenę pośpiechu.
Sympathetic nie znaczy „sympatyczny”, tylko „współczujący, wyrozumiały”. „I hope you can be sympathetic to the constraints we're working under” to prośba o wyrozumiałość, nie stwierdzenie, że ktoś jest miły. Dobre zdanie do zapamiętania, bo dokładnie tego potrzebujesz, prosząc o dodatkowy czas.
Słowa, które detonują rozmowę o kodzie wygenerowanym przez AI. Just w zdaniu „it just needs a bit of cleanup” umniejsza pracę, którą sam za chwilę będziesz wyceniał na dwa tygodnie: jedno słowo podważa cenę, którą wypowiesz zdanie później. Obviously, kiedy tłumaczysz błąd AI, brzmi jak zrzucanie winy na narzędzie zamiast brania odpowiedzialności za to, co zostało wdrożone pod twoim nazwiskiem w code review. Magic i hype są kuszące, bo brzmią świeżo, ale w ustach inżyniera podważają jego własny autorytet: nie chcesz być osobą, która nazywa własne narzędzie pracy magią, kiedy za chwilę prosisz o budżet na jego skutki.
Hedging, którego nikt tu nie oczekuje. Kiedy pytają, ile potrwa refaktoring nieznanego kodu wygenerowanego przez AI, szczerość brzmi jak niekompetencja, jeśli nie jest oznaczona. Rozwiązaniem nie jest usunięcie niepewności, tylko jej etykietowanie.
- "It's hard to say. I haven't really gone through all of it."
+ "Two of the five modules are solid. I've already reviewed them. The other three I haven't traced yet. That's where the estimate could move. I'll have a firm number by Thursday."Analogie, które mają cenę
Dobra analogia o długu technicznym związanym z AI musi nieść koszt, nie tylko obraz.
„It's a subscription, not a purchase. Every sprint we don't refactor, the speed we paid for gets more expensive to keep.” To przekłada dług na coś, co CFO rozumie z pierwszego zdania, bo subskrypcje są jego codziennym słownictwem.
„It's an iceberg. The demo is the ten percent above the water. My two weeks are for the ninety percent you haven't seen yet.” Dobre na pierwszą rozmowę z CEO, który widział tylko demo.
„Think of it as interest on a loan: it doesn't show up on an invoice. It shows up in the extra time every new feature takes.” Ta analogia nawiązuje do metafory długu Cunninghama: przekłada abstrakcyjne odsetki na czas, który zespół traci przy kolejnych zmianach.
Liczby na język pieniędzy
17% duplikacji kodu to abstrakcja. „Three copies of the same pricing logic. Fixing a bug in one copy leaves the other two unchanged” to konkret, który rozmówca zapamięta.
Dane branżowe potraktuj jako punkt wyjścia, nie jako pomiar własnego repozytorium. „GitClear found that copied lines accounted for about 12% of changed lines in its 2024 dataset. That doesn't tell us our own duplication rate. We need to measure that here.” Potem pokaż własny wynik: „We found three copies of the pricing rule. Last month, we fixed one and missed the other two.” Dopiero taki pomiar łączy ogólny trend z konkretną konsekwencją w Twoim kodzie.
„Three days of cleanup” zamień na „about four thousand euros of engineering time, versus the cost of another pricing bug. The last one took us two days to find and fix.” Ułamki, godziny i pieniądze są konkretem. Procenty są ozdobą.
Historie z frontu
Waluta, która nie istniała. CEO zbudował cały onboarding z AI w jeden weekend, zachwycony pokazał go inwestorom. Miesiąc później pojawił się klient z Wielkiej Brytanii, gotowy podpisać kontrakt, pod warunkiem obsługi funtów. EUR było zaszyte na sztywno w sześciu miejscach, bo nikt nie zapytał AI o drugą walutę, więc AI nie miało powodu o niej pomyśleć. Refaktoring, który mógł kosztować dwa dni, gdyby zrobiono go od razu, kosztował trzy tygodnie, bo trzeba było najpierw znaleźć wszystkie sześć miejsc.
„To już prawie gotowe”. Sales obiecał klientowi funkcję, którą widział działającą na demie zbudowanym przez AI w jedno popołudnie. Klient podpisał. Produkcja padła przy pierwszym realnym obciążeniu, bo demo nigdy nie widziało więcej niż pięciu równoczesnych użytkowników. Zespół dowiedział się o obietnicy z maila od klienta, nie od sales.
Refaktoring, który przeszedł za trzecim razem. Inżynier przez dwa sprinty zgłaszał to samo: „The code from the AI sprint has a lot of duplicated logic. We should clean it up”. Dwa razy usłyszał „Let's revisit this next sprint”. Za trzecim razem zaczął od zdarzenia, nie od struktury kodu: „We're refunding about 1,200 euros a month because three copies of the discount logic don't agree with each other. Two weeks of cleanup stops it and unblocks the loyalty program you wanted next quarter.” Dostał zgodę na tym samym spotkaniu. Kod się nie zmienił. Zmieniła się kolejność, w jakiej o nim opowiedział.
Zderzenia, które zdarzają się co tydzień
Mówisz „the code is messy”, słyszą krytykę gustu, nie ryzyka.
- "The code is messy. It needs refactoring."
+ "Every new feature now takes 30% longer because of how this was built. That's the cost we're paying every sprint."Mówisz „we need to refactor before adding this feature”, słyszą blokadę roadmapy.
- "We can't add this until we refactor."
+ "We can add this in one week with a higher risk of regressions, or in two weeks after cleaning up the shared logic. I recommend two weeks."Mówisz „AI wrote this quickly”, słyszą „więc powinno się to równie szybko zmieniać”.
- "The AI wrote this in an afternoon."
+ "The AI wrote the first version in an afternoon. Making it safe to build on takes about a week. The first version didn't include that work."Mówisz „there's technical debt”, nie słyszą nic, bo to słowo jest już wypalone z nadużycia.
- "There's a lot of technical debt in this module."
+ "This module costs us about a day of extra work on every change we make to it. That's the debt, in the currency you use."Co wdrożyć w tym tygodniu
Pierwsze zdanie zawsze nazywa zdarzenie, które już widzieli: refundację, spóźnioną funkcję, tydzień poślizgu, nie strukturę kodu, która je produkuje. Każda prośba o czas na refaktoring zaczyna się od tego, co zauważyli, nie od tego, co jest popsute w środku.
Prośba o budżet ma cztery elementy: krótki kontekst, opcje z kosztem i ryzykiem, rekomendację oraz termin decyzji. „We're losing about 1,200 euros a month to pricing bugs caused by duplicated logic. Three options: fix it properly over two weeks, patch it now and fix it properly later at roughly double the cost, or leave it and keep paying the monthly loss. I'd fix it properly now. It also unblocks the loyalty program. Need a decision by Friday.”
Szablon prośby o refaktoring, do trzymania pod ręką:
What: [funkcja/moduł] costs us about [koszt/tydzień lub miesiąc] because of
[konkretny problem w jednym zdaniu, bez żargonu].
Why now: [co się pogorszy, jeśli poczekamy: kolejna funkcja, kolejny klient,
kolejny błąd].
Cost of the fix: [czas] / [pieniądze].
Cost of waiting: [czas] / [pieniądze], every [sprint/miesiąc] until we do it.
Ask: [konkretna decyzja, konkretny termin].
Test „so what” trzy razy, zanim otworzysz usta: „We have three copies of the pricing logic.” So what? „Fixing one copy leaves the other two wrong.” So what? „Customers still get charged the wrong amount.” So what? „We keep paying refunds and spending time correcting the same error.” Ta ostatnia wersja jest Twoim pierwszym zdaniem.
Odbicie komunikatu na koniec rozmowy o budżecie: „Just so we're aligned: what's your understanding of what we're doing and by when?”. Najtańsze ubezpieczenie w tej całej rozmowie i jedyne, które wyłapuje sytuację, w której ktoś usłyszał „dwa tygodnie na sprzątanie” jako „w wolnej chwili, kiedyś”.
Vibe coding nie jest problemem. Problemem jest to, co rośnie pod wodą, dopóki nikt nie nazwie przekonania, które je tam trzyma. Cunningham dał Ci metaforę długu w 1992 roku. Teraz masz też sposób, by nazwać to, co kryje się pod powierzchnią.
Źródła: