Pod koniec pierwszego kwartału tego roku w mojej sieci na LinkedIn przewijał się jeden zrzut ekranu za drugim. Wszystkie dotyczyły tej samej liczby. Forbes, powołując się na wewnętrzną analizę Cursora, napisał, że abonament Claude Code Max za 200 dolarów miesięcznie potrafi „zjeść" nawet 5000 dolarów mocy obliczeniowej w przeliczeniu na jednego użytkownika. Niektórzy analitycy podbijali ten sufit jeszcze wyżej - do 25 tysięcy dolarów dla najbardziej wygłodniałych power userów. Płacisz 200. Obsłużenie cię kosztuje wielokrotność tej kwoty. Różnicę dokłada dostawca modelu.
Zaraz potem pojawiła się riposta. Część analityków rozłożyła te liczby na czynniki pierwsze i pokazała, że mylą one cenę detaliczną API z realnym kosztem serwowania modelu - a to dwie zupełnie różne rzeczy. Według danych samego dostawcy przeciętny programista zużywa około 6 dolarów dziennie w przeliczeniu na API, a 90 procent użytkowników mieści się poniżej 12 dolarów. Jeśli faktyczny koszt to jakieś 10 procent ceny API, mówimy o kilkunastu dolarach miesięcznie, nie o tysiącach. Nawet użytkownik, który przy cenniku API wykręciłby rachunek na 8000 dolarów, w rzeczywistości kosztuje dostawcę ułamek tej kwoty.
I tu jest sedno, które przegapiła większość komentujących. Dla mnie - jako właściciela software house'u, który co miesiąc podpisuje faktury za te narzędzia - nie ma większego znaczenia, czy prawda to 5000 dolarów, czy 50. Znaczenie ma jedno: zdolność, za którą przy stawkach API zapłaciłbym tysiące, kupuję dziś za 200 dolarów. Ktoś mi dopłaca do tej transakcji. I nie robi tego z sympatii.
Rozpisałem tę historię tak szczegółowo, bo ona jest kluczem do zrozumienia, co naprawdę dzieje się z rynkiem wytwarzania oprogramowania. Nie chodzi o to, czy AI zabierze pracę programistom. To pytanie źle postawione. Chodzi o to, że narzędzia radykalnie zmieniające ekonomię naszej branży są dziś sprzedawane poniżej kosztu - i to jest okno, które kiedyś się zamknie. Kto wykorzysta je świadomie, zbuduje przewagę. Kto potraktuje AI jako gadżet albo zagrożenie, ten obudzi się w momencie, gdy subsydium zniknie, a konkurencja już dawno wbudowała je w swój model działania.
Fałszywa debata: „AI zastąpi programistów"
Od dwóch lat słyszę tę samą tezę w dwóch skrajnych wariantach. Pierwszy: AI zastąpi programistów, software house'y znikną, wystarczy prompt. Drugi, obronny: AI generuje śmieciowy kod, prawdziwy inżynier jest niezastąpiony, nic się nie zmieni. Oba są wygodne, bo oba zwalniają z myślenia. I oba są fałszywe.
Prawda jest mniej efektowna. AI nie zastępuje software house'u, bo nie zastępuje tego, za co Klient naprawdę płaci. Klient nie kupuje linijek kodu. Kupuje pewność, że system zadziała pod obciążeniem, że dane nie wyciekną, że gdy w piątek o 23:00 padnie płatność, ktoś odbierze telefon i weźmie za to odpowiedzialność. Kupuje przełożenie mętnego pomysłu biznesowego na architekturę, która przetrwa trzy lata rozwoju. Tego model językowy nie robi - i długo nie będzie robił, bo to nie jest problem generowania tekstu, tylko odpowiedzialności i osądu.
Co się natomiast zmienia - i to fundamentalnie - to koszt wytworzenia samego kodu. Ta warstwa, która jeszcze niedawno pochłaniała większość godzin projektu, tanieje na naszych oczach. A kiedy tanieje najdroższy dotąd składnik usługi, zmienia się wszystko: rentowność, struktura zespołu i sposób, w jaki wyceniasz projekt. Software house, który tego nie przeprojektuje, nie zniknie z dnia na dzień. On po prostu zacznie przegrywać wyceny z kimś, kto policzył to inaczej.
Co naprawdę zmienia się w software house
Zacznę od rentowności, bo to najtwardszy argument. Kiedy zaczynaliśmy w The Force Code świadomie wpuszczać AI do produkcji kodu - nie jako ciekawostkę dla programistów, tylko jako element procesu - najszybciej zobaczyliśmy efekt tam, gdzie praca była powtarzalna i przewidywalna. Migracje, testy jednostkowe, pierwsze wersje endpointów, dokumentacja techniczna. To są zadania, które kiedyś zjadały godziny seniorów albo, co gorsza, były delegowane do juniorów i wracały do poprawek. Dziś powstają szybciej, a inżynier wchodzi na etapie, na którym jego osąd faktycznie coś wnosi: przegląd, architektura, wychwycenie tego, czego model nie widzi.
To brzmi jak oczywista wygrana, ale ma drugą stronę, o której mówi się rzadziej. Jeśli obniżasz koszt wytworzenia, a wyceniasz projekt po staremu - roboczogodzinami - to sam sobie tniesz przychód. Bo klient prędzej czy później zapyta, dlaczego to samo, co rok temu kosztowało 200 godzin, dziś zajmuje 120. I będzie miał rację. Model rozliczania „za czas" był sensowny, gdy czas był wąskim gardłem. Kiedy przestaje nim być, rozliczanie za czas staje się karą za własną efektywność.
Stąd druga zmiana: model wyceny. Coraz mocniej przesuwam myślenie z „ile godzin to zajmie" na „jaką wartość to dostarcza". To nie jest kosmetyka. To zmiana filozofii sprzedaży usługi IT. Jeśli integracja, którą wykonuję o połowę szybciej niż konkurencja, oszczędza klientowi dwadzieścia godzin pracy jego zespołu miesięcznie, to jej cena nie powinna wynikać z mojego kosztu, tylko z jego korzyści. AI, obniżając mój koszt, paradoksalnie zmusza mnie do dojrzalszej rozmowy o cenie - takiej, jaką od dawna prowadzą dobre firmy doradcze, a jaką branża software'owa przez lata omijała, chowając się za stawką godzinową.
Trzecia zmiana dotyczy struktury zespołu i jest najbardziej niewygodna. Rola juniora, jaką znaliśmy - ktoś, kto pisze prosty, powtarzalny kod pod okiem seniora i tak uczy się rzemiosła - kurczy się, bo tę pracę coraz częściej wykonuje model. To rodzi realny problem, którego nie wolno przemilczeć: jeśli maszyna robi zadania, na których dawniej dojrzewali juniorzy, to skąd za pięć lat wezmą się seniorzy? Nie mam na to gotowej odpowiedzi i nie ufam nikomu, kto twierdzi, że ma. Wiem natomiast, że software house, który dziś traktuje AI wyłącznie jako sposób na zwolnienie juniorów i cięcie kosztów, kupuje sobie krótkoterminową marżę kosztem długoterminowej zdolności do dostarczania. To jest dokładnie ta pułapka, o której pisałem wcześniej przy okazji „AI washingu" - technologia jako wygodne alibi dla decyzji, które i tak chciało się podjąć.
Moja odpowiedź na razie brzmi: zmieniamy to, czego junior się uczy. Mniej klepania kodu, więcej czytania cudzego, przeglądania, kwestionowania tego, co wypluł model, rozumienia architektury od pierwszego dnia. Junior, który potrafi ocenić, czy wygenerowane rozwiązanie jest dobre, jest dziś cenniejszy niż junior, który potrafi je tylko napisać.
Jest wreszcie czwarta zmiana, najbardziej podstępna, bo nie widać jej w kwartalnym raporcie - dług techniczny. Kod generowany przez model powstaje szybko i zwykle wygląda poprawnie. „Wygląda poprawnie" to jednak nie to samo co „jest poprawny". Model potrafi napisać funkcję, która przechodzi testy, a mimo to niesie subtelny błąd bezpieczeństwa, nieoptymalne zapytanie do bazy albo założenie, które wywróci się przy dziesięciokrotnie większym ruchu. Te problemy nie eksplodują w dniu wdrożenia. Eksplodują pół roku później, gdy system rośnie, a nikt już nie pamięta, dlaczego dana linijka wygląda tak, a nie inaczej. Software house, który mierzy swoją nową efektywność wyłącznie tempem powstawania kodu, hoduje sobie dług, który spłaci z nawiązką przy pierwszej poważnej awarii u klienta. Dlatego u nas zasada jest twarda: przyspieszenie, które AI daje na wejściu, w części reinwestujemy z powrotem w przegląd, testy i bezpieczeństwo. To nie spowalnia procesu - to jedyny sposób, żeby oszczędność czasu była realna, a nie pożyczona od przyszłości. I to jest kolejna rzecz, której klient wprost nie kupuje, ale za której brak zapłaci najwięcej.
Dokładnie ten mechanizm opisuje Rafał Jaseniuk, CTO The Force Code:
„Dobrym przykładem są testy. Model często nie pisze ich po to, żeby znaleźć błędy w rozwiązaniu, ale żeby potwierdzić, że aktualny kod przechodzi testy. Potrafi więc nieświadomie dopasować test do istniejącej implementacji, nawet jeśli sama implementacja zawiera błędne założenia lub lukę bezpieczeństwa. W efekcie wszystko świeci się na zielono, ale system wcale nie jest bardziej poprawny ani bezpieczny. Dlatego AI powinno wspierać proces weryfikacji, a nie być jego jedynym uczestnikiem."
Ten sam temat - gdzie AI realnie pomaga, a gdzie usypia czujność zespołu - to jeden z obszarów, którymi Rafał zajmuje się na co dzień i z których szkoli inne firmy.
Okno subsydiów, które kiedyś się zamknie
Wróćmy do tych 200 dolarów. To, co dziś wygląda jak niewiarygodna okazja, jest w istocie klasycznym mechanizmem pozyskiwania klienta i danych. Dostawcy modeli sprzedają topową moc AI poniżej ceny, którą sami sobie wystawiają w cenniku API, bo w zamian dostają coś bezcennego: nas, wpiętych na stałe w ich narzędzia, generujących realne dane o tym, jak wygląda praca z kodem w produkcji, i budujących liczby wzrostu, na których opierają kolejne rundy finansowania. To nie jest działalność charytatywna. To najtańszy marketing i najlepsze badania rynku, jakie można kupić.
Z tego wynika prosta konsekwencja, którą powtarzam każdemu, kto chce słuchać: ciesz się subsydium, ale nie buduj na nim fundamentu firmy. Klasyczne zasady wyprzedaży. Wyprzedaż jest prawdziwa, hojność nie. W momencie, w którym strategia dostawcy przestanie się spinać - a spinać się kiedyś musi - cena wzrośnie, limity się zacisną, model rozliczeń zmieni kształt. Widzieliśmy już zapowiedzi tego: użytkownicy planów Max, którzy nagle wypalali cały miesięczny budżet w kilkadziesiąt minut po zmianie sposobu liczenia. To nie jest teoria. To jest przypomnienie, kto trzyma rękę na kurku.
Co to oznacza w praktyce dla właściciela software house'u? Że okno jest teraz. Dziś kupuję zdolność, która za dwa czy trzy lata będzie kosztować wielokrotnie więcej - i za te pieniądze mam czas, żeby zbudować pod nią proces, kompetencje i przewagę, których nie da się kupić razem z abonamentem. Kluczowe słowo to „proces". Bo firmę, która nauczyła się dobrze wpinać AI w wytwarzanie oprogramowania - z przeglądem, kontrolą jakości, standardem bezpieczeństwa, świadomym modelem wyceny - podwyżka cen narzędzi zaboli, ale nie wywróci. Firmę, która całą swoją nagłą efektywność oparła wyłącznie na tanim dostępie do modelu i nic pod tym nie zbudowała, ta sama podwyżka rozłoży na łopatki. Bo jej przewaga nigdy nie była jej - była wypożyczona.
Co konkretnie warto budować pod tym subsydium, dopóki jest tanie? Po pierwsze, własny standard pracy z modelem - nie „każdy programista używa, jak chce", tylko spisane zasady: gdzie AI wolno wejść, gdzie nie, jak wygląda obowiązkowy przegląd wygenerowanego kodu, jak testujemy, jak pilnujemy bezpieczeństwa i zgodności z RODO, gdy w grę wchodzą dane klienta. Po drugie, przemyślany model wyceny oparty na wartości, przećwiczony na tyle projektów, żeby stał się nawykiem, a nie eksperymentem przy jednej ofercie. Po trzecie, wiedza organizacyjna - to, czego zespół nauczył się o tym, co model robi dobrze, a gdzie regularnie się myli, spisane i przekazywane dalej, a nie zamknięte w głowie jednego seniora. To wszystko są aktywa, które zostają w firmie niezależnie od tego, ile jutro będzie kosztować abonament. Narzędzie można w każdej chwili podmienić na tańsze albo droższe. Procesu, dyscypliny i wiedzy podmienić się nie da - trzeba je wypracować. I właśnie dlatego czas, który mam teraz, jest wart więcej niż same 200 dolarów oszczędności miesięcznie.
Dlaczego zastąpi cię konkurencja, nie AI
I tu dochodzimy do drugiej połowy tytułu, która jest ważniejsza od pierwszej. Zagrożeniem dla software house'u nie jest sztuczna inteligencja. Zagrożeniem jest inny software house, który wbuduje ją w swój model szybciej i mądrzej niż ty.
Wyobraź sobie dwie firmy stające do tego samego przetargu. Pierwsza wycenia projekt tak, jak robiła to trzy lata temu: liczy godziny, dokłada bufor, podaje kwotę. Druga ma proces, w którym warstwa powtarzalnego kodu powstaje szybciej, inżynierowie skupiają się na architekturze i integracjach, a wycena odzwierciedla wartość dla klienta, nie liczbę przepracowanych godzin. Druga firma może zaproponować krótszy termin, niższą cenę albo wyższą marżę przy tej samej cenie - do wyboru, w zależności od sytuacji. Za każdym razem wygrywa. I nie dlatego, że ma lepszych programistów. Dlatego, że policzyła ekonomię swojej usługi na nowo, a konkurent liczy ją po staremu.
To jest cała gra. Klient prawie nigdy nie wie, że stoi między firmą, która zintegrowała AI, a taką, która tego nie zrobiła. On widzi tylko dwie oferty: jedną szybszą i tańszą, drugą wolniejszą i droższą. Nie musi rozumieć technologii, żeby wybrać. I właśnie dlatego ten wyścig jest tak niebezpieczny dla tych, którzy go nie zauważają - przegrywasz kolejne przetargi, nie wiedząc, że przegrywasz je z powodu, którego nie widać w ofercie.
Warto przy tym zrozumieć, na czym naprawdę polega przewaga, bo łatwo ją pomylić z dostępem do narzędzia. Dostęp do modelu ma dziś każdy - to nie jest przewaga, to punkt wyjścia. Przewagą jest tempo, w jakim firma przekłada ten dostęp na zmieniony sposób pracy: jak szybko przebudowuje procesy, jak szybko uczy zespół nowego podziału ról, jak szybko dostosowuje wyceny. Ta różnica nie kumuluje się liniowo. Firma, która wystartowała rok wcześniej, nie jest o rok do przodu - ona ma za sobą rok błędów, których konkurent dopiero się nauczy, rok kalibracji procesu i rok referencji od zadowolonych klientów. W momencie, gdy narzędzia się zrównają cenowo i możliwościami, właśnie ten skumulowany rok doświadczenia będzie jedyną rzeczą, której nie da się nadrobić abonamentem. Dlatego zwlekanie nie jest neutralne. Każdy miesiąc zwłoki to nie „poczekam, aż się wyklaruje" - to miesiąc przewagi oddany komuś, kto nie czekał.
AI jako warstwa zarządcza, nie funkcja techniczna
Piszę to wszystko z perspektywy, która przewija się przez większość moich tekstów: AI jest dla mnie warstwą zarządzania firmą, a nie technologiczną ciekawostką. W software house to widać wyjątkowo ostro, bo tu AI wchodzi jednocześnie do dwóch miejsc - do samego produktu, czyli kodu, i do sposobu, w jaki tym produktem zarządzam. To drugie jest ważniejsze i trudniejsze.
Bo decyzja, gdzie wpuścić model, a gdzie zostawić człowieka, gdzie zaakceptować szybkość kosztem kontroli, a gdzie odwrotnie - to nie jest decyzja techniczna. To decyzja zarządcza, którą podejmuje osoba odpowiedzialna za rentowność i za relację z klientem. I tu wracam do wątku, który poruszałem niedawno przy okazji własnych nawyków decyzyjnych: AI jest genialnym narzędziem do walidacji, pod warunkiem że nie zamienia się w narzędzie do racjonalizacji. W kontekście software house'u brzmi to tak - łatwo dać się skusić i uznać, że skoro model coś wygenerował, to jest dobre, bo potwierdza to, co chcieliśmy usłyszeć: że będzie szybciej i taniej. Prawdziwa dyscyplina polega na tym, żeby wciąż pytać, czego ten kod nie widzi, gdzie się złamie, kto za niego odpowie. To pytanie zadaje człowiek, nie maszyna. I dopóki tak jest, software house ma się czym różnić.
Nie napisałem tego tekstu, żeby cię uspokoić, i nie napisałem go, żeby cię przestraszyć. Napisałem go, bo widzę, jak wielu właścicieli firm IT tkwi w jednej z dwóch wygodnych narracji - „AI nas zastąpi" albo „AI to zabawka" - podczas gdy prawdziwa zmiana dzieje się w miejscu, na które żadna z nich nie patrzy. W ekonomii usługi. W modelu wyceny. W strukturze zespołu. I w tym cichym subsydium, dzięki któremu dziś kupujemy za 200 dolarów coś, co jutro będzie kosztować krotność tej kwoty.
Okno jest otwarte teraz. Po to, żeby zbudować firmę, której nie wywróci ani podwyżka cen narzędzi, ani konkurent, który obudził się wcześniej. Bo za dwa lata pytanie nie będzie brzmiało, czy używasz AI. Będzie brzmiało, czy zdążyłeś zbudować pod nią coś swojego - zanim przestała być tania.
W świecie złożonych decyzji technologicznych, pomagam układać właściwe puzzle.
