AI nie kończy projektów. Kończy je decyzja, że są skończone

Tydzień temu pisałem o tym, jak zacząć z AI, nie będąc programistą (link zostawiam na końcu, gdybyś przegapił/a). Obiecałem wtedy, że dziś zajmiemy się czymś trudniejszym. Bo zacząć to jedno. A nie zakopać się po drodze to zupełnie inna historia.

To akurat nie moje słowa. To zdanie z ankiety, którą wypełniacie po zapisie na mailing:

„Wykorzystuję AI, jednakże nie potrafię kończyć projektów z jego pomocą. Zakopuję się po drodze i błądzę.”

I to nie był jeden głos. Pod tym podpisałoby się pół listy.

Więc powiem Ci coś, co na pierwszy rzut oka brzmi jak truizm, a okazuje się sednem całej sprawy.

AI nie kończy projektów.

Projekty kończy decyzja, że są skończone. Człowiek ją podejmuje, nie model. A z AI ta decyzja jest trudniejsza, nie łatwiejsza. Bo narzędzie, które obniża koszt dorzucenia „jeszcze jednej rzeczy” prawie do zera, obniża go też wtedy, kiedy NIE powinno.

Najpierw zła wiadomość: to już jest nawyk

Wiesz, jak wyrabia się nawyk. Pijesz rano szklankę wody przez trzy tygodnie i przestajesz o tym myśleć, po prostu sięgasz.

Tylko że dokładnie tak samo wyrabia się nawyk negatywny. Nie skończyłeś pierwszego projektu. Drugiego. Trzeciego. I z każdym kolejnym porzucenie przychodzi odrobinę łatwiej. Aż „odpuszczę i zacznę coś nowego” staje się odruchem, którego nawet nie zauważasz.

To dlatego „zakopuję się po drodze” boli bardziej, niż wynikałoby z samej straty czasu. Bo to nie jest pojedyncza porażka. To ścieżka, która sama się utwardza.

Dobra wiadomość jest taka, że ten sam mechanizm działa w drugą stronę. Ale o tym na końcu.

Dlaczego z AI zakopujesz się szybciej

Zbuduj coś bez AI, a każdy nowy pomysł kosztuje. Trzy wieczory, frustrację, naukę kolejnej rzeczy. Ten koszt jest Twoim hamulcem. Sam z siebie pilnuje, żebyś nie rozdmuchał projektu, bo zwyczajnie nie masz na to siły.

A teraz to samo z modelem. Masz pomysł, wpisujesz zdanie, dostajesz kod. „Skoro idzie tak gładko, to dorzućmy jeszcze logowanie. I powiadomienia. I może panel statystyk.” Każda z tych rzeczy w pojedynkę wygląda na pięciominutową.

Ian Khor opisał to lepiej, niż ja bym potrafił. Zakres projektu rozrasta się wtedy nie przez jedną świadomą decyzję, tylko przez „stały sączek nocnych promptów, z których każdy w danej chwili wydaje się oczywisty”. Dorzucasz funkcję za funkcją, każda drobna, aż projekt urósł dwa razy ponad plan, choć ani razu nie powiedziałeś sobie „rozszerzam”. W jego przykładzie po trzech tygodniach lista do zrobienia spuchła trzykrotnie. Nic z tego nie było zaplanowane. Nic nie było na pierwotnej liście.

→ Ian Khor: jak ogarnąć scope creep przy pracy z AI

Brzmi znajomo? To jest dokładnie to „błądzę po drodze” z ankiety. Tyle że teraz wiesz, skąd się bierze. Nie z Twojej słabej woli. Z tego, że zniknął naturalny hamulec.

Druga pułapka: ściana na 70%

Jest jeszcze coś, co dopada zwłaszcza osoby bez technicznego tła.

Addy Osmani, inżynier z Google, nazwał to „problemem 70%”. Pisze wprost o nieprogramistach budujących z AI: „dochodzą do 70% zaskakująco szybko, ale te ostatnie 30% zamieniają się w ćwiczenie z malejących zysków”.

→ Addy Osmani: trudna prawda o kodowaniu z AI

Pierwsze 70% to demo. Wygląda, działa, cieszysz się. A potem zaczyna się reszta: przypadki brzegowe, sytuacje, których nie przewidziałeś, rzeczy, które wysypują się dopiero u prawdziwego użytkownika. I ta reszta potrafi zająć tyle samo czasu, co całe pierwsze 70%.

Tu ludzie się łamią. Bo czują, że są „prawie gotowi” od dwóch tygodni. Każda poprawka rozwala dwie inne. Przepisują to samo w kółko, bo każda wersja jest „prawie”.

To nie jest dowód, że się nie nadajesz. To najnormalniejszy etap KAŻDEGO projektu. Tyle że nikt Cię o nim nie uprzedził.

Trzy sygnały, że właśnie się zakopujesz

Po sobie i po uczniach nauczyłem się rozpoznawać moment, w którym projekt zaczyna tonąć. Trzy rzeczy:

1. Co wieczór dorzucasz „jeszcze tylko jedną rzecz” i lista rośnie zamiast maleć.
2. Nie umiesz powiedzieć, co właściwie znaczy „skończone” przy tym projekcie. Bo nigdy tego nie zapisałeś.
3. Wracasz do tego samego fragmentu po raz piąty, a model za każdym razem mówi „teraz będzie dobrze”.

Jeśli łapiesz u siebie choć jedno, projekt nie jest do wyrzucenia. Brakuje mu ram.

Przestań budować pałac

W głowie masz pałac. Wiem, bo sam go mam za każdym razem. Wizja produktu, który robi wszystko, wygląda genialnie i obok którego stoi jeszcze pięćdziesiąt pomysłów czekających w kolejce. Problem w tym, że pałacu nie da się zbudować na raz. Rozsypie się gdzieś po drodze i zostajesz z niczym.

Więc zamiast pałacu zbuduj jeden pokój. Brzydki, bez ozdób, ale taki, w którym da się mieszkać.

W praktyce to trzy rzeczy. Żadna nie jest techniczna.

Pierwsza. Zanim wpiszesz pierwszy prompt, wypisz od pięciu do dziesięciu rzeczy, które aplikacja MUSI robić. Nie więcej. To jest Twoja wersja 1.0 i ani jeden punkt poza tą listą do niej nie wchodzi. Gdy w środę o 23:00 przyjdzie genialny pomysł (a przyjdzie), nie bierzesz się za niego. Zapisujesz go w jednym miejscu, w narzędziu do zadań albo w pliku „następna wersja”, i wracasz do listy. Pomysł nie ucieka. Po prostu czeka na swoją kolej.

Pokażę Ci, jak to wygląda w praktyce.

A co, jeśli za pół roku okaże się, że konta jednak są potrzebne? To się okaże na produkcji, kiedy realni ludzie zaczną gubić kody. Wtedy je dorobisz, bo będziesz wiedział, że są naprawdę potrzebne, a nie tylko że „wypadałoby je mieć”.

Druga. Wypuść tę brzydką wersję do ludzi tak szybko, jak się da. To jest najważniejsze zdanie w całym tekście. Bo Ty teraz zgadujesz, czego użytkownik potrzebuje, a w jakichś dziewięciu przypadkach na dziesięć zgadujesz źle. Dopiero kiedy ktoś realnie tego użyje, dowiadujesz się, co dorobić. Inaczej dokładasz funkcje, o które nikt nigdy nie poprosił, i każda z nich to kolejny worek roboty i kolejny powód, żeby nie skończyć.

Trzecia, najtrudniejsza. W którymś momencie mówisz „skończone, wydaję”. Wbrew pokusie, że jeszcze tu i tam. Model nigdy tego za Ciebie nie powie. Jemu zawsze można coś poprawić. Tę granicę stawiasz Ty.

Jak to wygląda, gdy się uda

Bartek, jeden z uczniów ATD, miał konkretny problem: grafiki dyżurów przychodziły w Excelu i trzeba było ręcznie pilnować zmian, żeby żadnej nie przegapić. Zbudował Dzwonek i było po sprawie.

Ale zwróć uwagę na to, czego NIE zrobił. Nie zbudował „platformy do zarządzania dyżurami” z kontami, rolami i panelem admina. Wziął jeden problem, domknął go w działające narzędzie i na tym poprzestał. Excel wchodzi, przypomnienie wychodzi. Skończone.

---

Pamiętasz tę dobrą wiadomość, którą zostawiłem na koniec?

Nawyk działa w obie strony. Gdy pierwszy raz dowieziesz wersję 1.0, w głowie zapala się lampka: „potrafię to skończyć”. Wtedy wersja 1.1 jest już łatwiejsza. A 1.2 jeszcze łatwiejsza. Z każdym wydaniem domykanie wchodzi w krew tak samo, jak wcześniej wchodziło odpuszczanie. Tylko teraz pracuje dla Ciebie, nie przeciwko.

Nagrałem zresztą o tym kiedyś osobny film, jeśli wolisz wideo:

→ Nie potrafisz skończyć projektu? (YouTube)

A i obiecany na początku link do zeszłotygodniowego tekstu, jeśli go przegapiłeś(aś):

→ Granica nieprogramista - programista nie jest tam, gdzie myślisz

A za tydzień schodzimy głębiej, w stronę, której pewnie się nie spodziewasz: co się dzieje, kiedy projekt naprawdę rośnie i model zaczyna wymykać się spod kontroli mimo dokumentacji, planów i wszystkiego, co robisz dobrze. Inna liga problemów.

Napisz mi, który z trzech sygnałów łapiesz u siebie najczęściej. Obstawiam, że pierwszy :)

Miłego dnia.