W poprzednim tekście napisałem, że software house bez AI zastąpi konkurencja. Podtrzymuję każde słowo. Ale przez ostatnie tygodnie coraz częściej dostaję telefony, które pokazują drugą stronę tej samej monety - i jest ona dużo mniej oczywista.

Dzwonią do mnie właściciele i szefowie techniczni innych firm. Nie moich Klientów - obcych spółek, czasem z zupełnie innej branży. Pytanie jest za każdym razem wariacją tego samego zdania: „Mateusz, jak poradzić sobie z własnym Prezesem, żeby go nie urazić?".

Bo ich Prezes właśnie odkrył AI.

I to nie jest historia o oporze przed technologią. To jest historia odwrotna - o decydencie, który uwierzył w AI za bardzo, za szybko i w niewłaściwym miejscu. O człowieku, który przez całą karierę nie napisał linijki kodu, a teraz wrzuca fragment do modelu, dostaje „gotowe rozwiązanie" i pcha je prosto na serwer produkcyjny. Na projekt, nad którym na GitLabie pracuje pięciu programistów. Każda taka zmiana to u nich kolejny siwy włos.

Jeden z tych telefonów wyglądał tak. Szef techniczny spółki dzwoni w piątek po południu, wyraźnie zmęczony. Ich Prezes wpadł na pomysł, wziął fragment logiki z systemu, przepuścił przez AI, dostał „poprawioną wersję" i sam wypchnął ją na produkcję - pierwszy raz w życiu, w firmie, w której nigdy wcześniej nawet nie logował się do serwera. Zadziałało. Przez kilka godzin wszystko chodziło. A potem, przy pierwszym nietypowym zestawie danych, część systemu przestała odpowiadać - i pięciu programistów spędziło wieczór na odkręcaniu zmiany, której nikt z nich nie widział na oczy, nie znając nawet założeń, z jakimi została zrobiona. Prezes tymczasem był przekonany, że właśnie pokazał zespołowi, jak się pracuje szybko.

To nie jest anegdota o jednej firmie. To jest wzorzec, który powtarza się w niemal identycznej formie w każdej z tych rozmów.

To jest realne ryzyko, o którym nikt nie pisze. Wszyscy ostrzegają zarządy przed ignorowaniem AI. Prawie nikt nie ostrzega zespołów przed zarządem, który AI właśnie pokochał.

Dlaczego to się dzieje teraz - i dlaczego akurat u Prezesa

Przez lata istniała naturalna bariera między decydentem a kodem. Prezes miał pomysł, przekazywał go zespołowi, zespół oceniał, wyceniał, robił albo tłumaczył, dlaczego to zły pomysł. Ta bariera była irytująca, ale pełniła funkcję: filtrowała. Nie każdy pomysł z góry lądował w systemie, bo między pomysłem a systemem stali ludzie, którzy rozumieli konsekwencje.

AI tę barierę zdjęła. Nagle Prezes nie musi nikogo pytać. Wpisuje polecenie, dostaje działający - a przynajmniej wyglądający na działający - kawałek kodu i ma poczucie, że sam zrobił w dziesięć minut to, na co zespół dawał mu dwutygodniowy termin.

I tu jest sedno, które trzeba nazwać wprost: AI nie dała Prezesowi kompetencji. Dała mu pewność siebie.

To są dwie zupełnie różne rzeczy. Kompetencja to wiedza plus świadomość własnych granic - wiesz, co umiesz, i wiesz, czego nie widzisz. Pewność siebie z AI to samo poczucie sprawczości, bez tej drugiej połowy. Prezes widzi wynik. Nie widzi, że wynik nie ma testów, że łamie architekturę, którą zespół budował miesiącami, że zadziała do pierwszej realnej zmiany danych, i że za trzy tygodnie ktoś będzie to odkręcał przez dwa dni.

Model pokazuje mu efekt. Nie pokazuje mu kosztu tego efektu. A Prezes, z natury swojej roli, jest wyczulony właśnie na efekty.

Co widzi zespół po drugiej stronie

Spójrzmy na to z perspektywy tych pięciu programistów, bo to oni są prawdziwymi bohaterami tej historii - i to oni najczęściej cierpią w ciszy.

Pracują nad projektem w uporządkowanym procesie. Mają repozytorium, mają gałęzie, mają review, mają jakiś ustalony sposób, w jaki zmiana wchodzi do systemu. Ten proces nie jest biurokracją dla samej biurokracji. To jest mechanizm, który sprawia, że za pół roku ktokolwiek jeszcze będzie w stanie ten projekt utrzymać.

I nagle w środek tego procesu spada zmiana z góry. Bez zapowiedzi, bez kontekstu, bez omówienia. Prezes „już to zrobił". Kod jest na serwerze. Zespół dowiaduje się po fakcie, że produkcja wygląda inaczej, niż wyglądała rano.

Rozmawiałem o tym z Rafałem Jaseniukiem, CTO The Force Code, bo chciałem to opisać dokładnie tak, jak czuje to strona techniczna, a nie zarząd:

„Problemem nie jest sama zmiana ani to, że pojawia się poza planem - w biznesie takie sytuacje są normalne. Problem zaczyna się wtedy, gdy zmiana omija proces, który daje zespołowi kontrolę nad tym, co trafia na produkcję. Jeśli kod na serwerze przestaje odpowiadać temu, co mamy w repozytorium, review i historii zmian, tracimy jedno źródło prawdy o systemie. A bez tego dużo trudniej oczekiwać od zespołu realnego poczucia odpowiedzialności za system, bo odpowiedzialność wymaga również wiedzy i wpływu na to, za co się odpowiada”

Warto zatrzymać się nad tym, co dzieje się z zespołem nie po jednej takiej zmianie, ale po piątej. Za pierwszym razem programiści są zaskoczeni i naprawiają. Za drugim - zirytowani, ale nadal naprawiają. Za trzecim zaczynają robić coś, co dla firmy jest znacznie groźniejsze niż jakikolwiek zepsuty deployment: przestają planować. Po co budować porządną architekturę, skoro i tak w każdej chwili może w nią wejść zmiana z góry, która ją złamie? Po co pisać testy, skoro Prezes i tak wypycha kod, który przez żadne testy nie przeszedł? Zespół, który przestaje wierzyć w trwałość własnej pracy, przestaje w tę pracę inwestować. I robi dokładnie tyle, żeby dotrwać do końca dnia.

To jest cichy, powolny rozkład, którego nie widać w żadnym raporcie. Prędkość spada, długu technicznego przybywa, najlepsi ludzie zaczynają się rozglądać - a Prezes przez cały ten czas jest przekonany, że to on wniósł do firmy nową energię i tempo.

To ostatnie zdanie jest kluczowe. Bo najgorszą konsekwencją nie jest jeden zepsuty deployment. Najgorszą konsekwencją jest moment, w którym zespół cicho podnosi ręce i mówi sobie: skoro Prezes i tak robi, co chce, to my nie odpowiadamy za to, co się z tym stanie.

W tym momencie firma traci nie kod. Traci właścicielstwo. A software house, w którym nikt nie czuje się właścicielem systemu, jest już tylko kwestią czasu.

Granica, której Prezes nie widzi

Warto w tym miejscu być uczciwym, bo łatwo z tego tekstu zrobić manifest przeciwko Prezesom eksperymentującym z AI. A tak nie jest. Istnieje cała przestrzeń, w której Prezes z AI może działać sam, i to jest wręcz zdrowe.

Prototyp, który ma tylko pokazać ideę i wyląduje w koszu następnego dnia? Świetnie. Wewnętrzny skrypt, który raz w miesiącu przelicza mu jakieś zestawienie, i którego awaria nie dotyka nikogo poza nim? Idealnie. Makieta, na której chce zobaczyć, jak mogłaby wyglądać nowa funkcja, zanim poprosi zespół o wycenę? Bardzo dobrze - to nawet oszczędza wszystkim czasu.

Granica przebiega dokładnie tam, gdzie zaczyna się coś, za co odpowiada ktoś inny niż on. Dopóki Prezes buduje rzeczy, których konsekwencje spadają wyłącznie na niego, jest właścicielem swojego ryzyka. W momencie, w którym dotyka systemu, który utrzymuje pięć innych osób i od którego zależy Klient, przestaje być właścicielem ryzyka - staje się jego źródłem dla innych.

Problem w tym, że AI ukrywa tę granicę. Efekt w piaskownicy i efekt na produkcji wyglądają w oknie modelu identycznie. Ta sama „gotowa" odpowiedź, ta sama pewność, że działa. Prezes nie widzi różnicy między „to działa u mnie na ekranie" a „to jest bezpieczne w systemie, który obsługuje realnych użytkowników" - bo model mu tej różnicy nie pokazuje. I nie pokaże, bo nie zna kontekstu, którego Prezes też nie zna: architektury, zależności, tego, co się stanie z danymi za trzy miesiące.

To jest właśnie ta niewidzialna ściana, o którą rozbija się dobra intencja. I to jest powód, dla którego samo „uważaj" nie wystarczy - bo Prezes szczerze uważa, że uważa.

Dlaczego „nie rób tego" nie zadziała

Naturalnym odruchem CTO jest powiedzieć Prezesowi: „Proszę tego nie robić". I to jest dokładnie ruch, który nie działa - dlatego ci ludzie do mnie dzwonią, zamiast po prostu postawić granicę.

Żeby zrozumieć, dlaczego zakaz nie działa, trzeba zrozumieć, co tak naprawdę napędza Prezesa. A nie napędza go chęć pisania kodu. Napędza go chęć posiadania racji.

Znam to zdanie na pamięć, bo słyszę je w różnych wersjach za każdym razem: „Mówiłem wam, że to jest robota na piętnaście minut. I zobaczcie - ja to zrobiłem w dziesięć".

To nie jest zdanie o kodzie. To jest zdanie o latach frustracji. O każdym terminie, który wydawał się rozdmuchany. O każdym „to się nie da tak szybko", które Prezes odbierał jako wymówkę. AI dała mu pierwszy raz od dawna narzędzie, żeby udowodnić, że miał rację - i on z tego narzędzia korzysta nie po to, żeby programować, tylko po to, żeby wygrać stary spór.

Jeśli powiesz takiemu człowiekowi „nie rób tego", nie usłyszy troski o system. Usłyszy: „znowu próbują mnie zablokować, znowu udowadniają, że się nie znam". I zrobi to następnym razem tym bardziej, tym ciszej, tym bardziej pod stołem.

Z Prezesem, który właśnie poczuł sprawczość, nie wygrywa się czołowo. Tę energię trzeba przekierować, nie zdławić.

Dwa ruchy, które realnie działają

Firmom, które do mnie dzwonią, daję dwie konkretne rzeczy. Obie są zarządcze, nie techniczne - bo problem nie jest techniczny.

Pierwszy ruch: dać Prezesowi piaskownicę.

Nie odbieraj mu zabawki. Daj mu własną. Osobne środowisko, w którym może eksperymentować z AI do woli, budować, testować, sprawdzać swoje pomysły - i które fizycznie nie ma dostępu do produkcji. Klucz jest w tym, żeby nie zaprezentować tego jako klatki, tylko jako przywilej: „To jest Twoja przestrzeń, tu możesz sprawdzić każdy pomysł, zanim ruszymy z nim na poważnie".

Prezes dostaje to, czego naprawdę chce - poczucie sprawczości i możliwość udowodnienia, że pomysł działa. Zespół dostaje to, czego potrzebuje - pewność, że produkcja jest nietykalna. A najlepsze pomysły z piaskownicy i tak trafiają do zespołu, tyle że jako przemyślana propozycja, a nie jako niespodzianka na serwerze.

Drugi ruch: ustawić review jako wsparcie, nie jako blokadę.

Zasada „każda zmiana przechodzi przez review" brzmi dla Prezesa jak biurokracja i kontrola. Więc nie sprzedawaj jej tak. Sprzedaj ją jako ochronę jego pomysłu: „Chcemy, żeby Twój pomysł wszedł do systemu w takim stanie, żeby przetrwał. Review jest po to, żeby czyjś błąd przy okazji nie zabił Twojej dobrej zmiany".

A do tego dochodzi zdanie, które trzeba powiedzieć wprost, spokojnie i bez emocji - bo to jest realna stawka: bez tego procesu zespół techniczny nie weźmie odpowiedzialności za dalsze utrzymanie i naprawy. Nie z złośliwości. Ze strachu. Nie da się odpowiadać za system, w którym w każdej chwili może pojawić się zmiana, której nikt nie widział i nikt nie rozumie.

To nie jest szantaż. To jest uczciwe postawienie sprawy: albo mamy jeden proces, w którym wszyscy - łącznie z Prezesem - działamy, albo zespół przestaje gwarantować cokolwiek. Większość Prezesów, gdy usłyszy to bez agresji, wybiera proces. Bo oni nie chcą chaosu. Oni chcą mieć rację. A proces, w którym ich pomysł zostaje sprawdzony i wdrożony porządnie, daje im rację w sposób, który nie kosztuje firmy dwóch dni odkręcania.

Gdzie ta energia naprawdę powinna iść

Do tej pory pisałem o gaszeniu pożaru. Ale byłbym niekonsekwentny, gdybym zatrzymał się na obronie. Prezes zafascynowany AI to nie jest problem do zneutralizowania. To jest zasób, który akurat płynie w złą stronę.

Bo pomyśl: masz na pokładzie decydenta, który nagle chce testować, sprawdzać, budować, który przestał czekać i zaczął działać. To jest energia, o którą większość firm się modli. Problem polega wyłącznie na tym, że skierował ją na jedyny obszar, w którym robi szkody - na kod produkcyjny, gdzie brakuje mu kompetencji, żeby ocenić konsekwencje.

Przekieruj ją tam, gdzie jego brak technicznej wiedzy nie jest wadą, tylko przewagą.

Prezes z AI jest genialny do definiowania problemu, nie do jego rozwiązywania. Niech AI-uje wymagania, nie deployment. Niech przepytuje pomysły z trzech stron, zanim trafią do zespołu. Niech w dziesięć minut robi wstępny przegląd opcji, których zespół nie miałby czasu przeanalizować, i przynosi go jako materiał do rozmowy, a nie jako gotową decyzję wrzuconą na serwer. Niech używa AI do tego, do czego Prezes jest naprawdę potrzebny - do zadawania lepszych pytań, nie do udawania programisty.

W praktyce robię to jednym prostym przesunięciem języka. Zamiast pozwolić Prezesowi mówić „zrobiłem to", uczę zespół zapraszać go do mówienia „chcę, żeby to działało tak". Pierwsze zdanie kończy rozmowę i zamyka pomysł na serwerze. Drugie ją otwiera - bo „chcę, żeby to działało tak" to jest brief, materiał, z którym zespół może wejść w dialog, doprecyzować, wycenić i wdrożyć porządnie. Prezes nadal przynosi to samo, co przyniósł z AI. Zmienia się tylko to, czy przynosi decyzję, czy propozycję. A to jest różnica między firmą, która się rozjeżdża, a firmą, która przyspiesza.

Ta sama ciekawość, ta sama niecierpliwość, ta sama chęć „sam sprawdzę" - skierowana na warstwę decyzji zamiast na warstwę wykonania - przestaje być zagrożeniem dla zespołu i staje się jego przyspieszeniem.

Prezes, który mówi „zrobiłem to w dziesięć minut", nie chce być programistą. On chce być usłyszany. Chce, żeby po latach ktoś w końcu przyznał mu rację.

Sztuka zarządzania nim nie polega na tym, żeby udowodnić mu, że się myli - bo on w swoim doświadczeniu często się nie mylił, procesy naprawdę bywają za wolne, a terminy naprawdę bywają rozdmuchane. Sztuka polega na tym, żeby dać mu wygrać ten spór w miejscu, gdzie jego wygrana nie kosztuje firmy zespołu.

AI nie zrobiła z Prezesa programisty. Zrobiła z niego kogoś, kto pierwszy raz od lat poczuł, że sam może. To jest ogromna siła. Zadaniem szefa techniki - i zadaniem każdego, kto doradza takim firmom - nie jest tę siłę zgasić. Jest ją skierować tak, żeby pięciu programistów na GitLabie mogło w końcu przestać siwieć.

A jeśli prowadzisz firmę i to Ty jesteś tym Prezesem - potraktuj ten tekst nie jak zarzut, tylko jak zaproszenie. Twoja ciekawość AI jest wartościowa. Pytanie tylko brzmi, czy używasz jej, żeby lepiej decydować, czy żeby udowodnić zespołowi, że się nie znają. Pierwsze zbuduje Ci firmę. Drugie ją po cichu rozłoży.

W świecie złożonych decyzji technologicznych, pomagam układać właściwe puzzle.