Siadam na fotelu CEO.

Gotowy serwis dostarczający bazę, github i serwis, który bierze kod i od razu wdraża go na produkcję. Wszystko to będą narzędzia, których mój agent będzie mógł użyć. Do testowania również użyję agenta. Full AI, żadnego człowieka po drodze, poza tym, który będzie pisał prompty. Piszę prompt, opisuję dokładnie, czego chcę, i już po chwili widzę wynik. Jest imponujący. Jeszcze nie dokładnie taki, jaki ma być, więc piszę następny prompt z poprawkami. Kiedy jestem zadowolony, piszę następne prompty z funkcjonalnościami. Wdrożenia robią się automatycznie. Po tygodniu mam działającą aplikację. Gotowe. Działa. Zarabiamy.

Czy jest idealnie? Nieważne, nie musi być. Nie robi mi różnicy, czy zaufam AI, czy człowiekowi. W końcu czym różni się pisanie promptów od dostarczania wymagań developerowi.

Gdybyśmy tu postawili kropkę w tej historii, byłoby pięknie. Jednak historia trwa dalej. Pojawia się pierwszy użytkownik, któremu coś nie działa. Nie ma problemu, AI to poprawi. Może nawet zautomatyzujemy i ten proces. Użytkownicy będą dawali feedback do AI, który będzie priorytetyzował defekty i na bieżąco poprawiał. Za chwilę okazuje się, że aplikacja działa powoli, czasami nawet wyrzuca dziwne błędy. AI szuka przyczyny i poprawia.

W tym momencie może pojawić się wiele rzeczy, a szansa na to, że aplikacja będzie działać bezbłędnie, kurczy się. Co zrobisz, jeśli okaże się, że użytkownicy widzą wrażliwe dane innych użytkowników? Co zrobisz, jeśli AI nagle stwierdzi, że przyczyną spowolnienia jest zbyt duża baza, i postanowi ją wyczyścić? Co zrobisz, jeśli AI w pewnym momencie stwierdzi, że najlepiej zacząć od nowa, i usunie wszystko?

W pewnym momencie potrzebujesz więcej zasobów. Providerzy nie wystarczają. Musisz przenieść swoją aplikację na inną infrastrukturę. Wtedy dopiero okazuje się, że AI ma wszystko zahardkodowane pod obecny setup, bo nikt mu nie powiedział inaczej.

Siadam teraz na fotelu programisty.

Pierwsza różnica - podchodzę do pisania kodu, jakby to był mój własny. Ostatecznie to ja będę musiał się pod nim podpisać. Druga różnica - wieloletnie doświadczenie nauczyło mnie, że kod się częściej czyta, niż pisze. W tej kwestii AI zmieniło tylko jedno - kodu się nie pisze. To znaczy, że jego czytelność jest jeszcze ważniejsza. Z drugiej strony, czy w ogóle jest ważna, skoro działa? Nie podłączam jeszcze żadnych connectorów - praca z jirą, gitem jest w mojej pamięci mięśniowej, zwyczajnie tego nie potrzebuję. Najpierw chcę zobaczyć, czy to działa.

Piszę pierwszy prompt i zanim jeszcze uruchomię aplikację, czytam kod. Najbardziej interesuje mnie model danych i tabele, które utworzą się w bazie podczas migracji.

Dlaczego? Model danych to coś, co najtrudniej zmienić po wypuszczeniu na produkcję. Jest to świat przedstawiony naszego systemu. Nierozważna zmiana może doprowadzić do utraty danych lub spójności bazy. Przed pierwszym releasem bazę można po prostu wyczyścić i zapełnić od nowa. Na produkcji wiąże się to z utratą danych użytkowników lub, co gorsza, złym przypisaniem danych.

To jest ten moment, w którym AI zmienia coś - testuje - nie działa - poprawia - testuje - działa. A na koniec okazuje się, że po drodze baza popada w ruinę. Ja to zrobię oczywiście na środowisku testowym i sprawdzę migracje, czy destruktywne działanie nie zostanie zreprodukowane na produkcji.

Potem patrzę na interfejs. Po interfejsie poznam, czy AI zrozumiało moje przypadki użycia. Przeglądam nazwy handlerów oraz ich inputy i outputy. Następnie sprawdzam, jak działają te, które robią coś więcej niż zapisz/wczytaj/usuń.

Wtedy okazuje się, że AI co prawda daje oczekiwany wynik, ale wewnątrz nie robi tego, co powinien. Tłumaczę mu wtedy, jak to powinno wyglądać, a on to poprawia.

Zostaje mi jeszcze jedna rzecz. Jeśli teraz nie czytam kodu bardzo dokładnie, to znaczy, że musi być on na tyle czytelny, żebym w razie czego mógł go zrozumieć. Dodaję AI - w moim przypadku jest to Claude - odpowiednie wytyczne, jak ma pisać kod. Nie jest to kwestia estetyki, a szybkiego odnalezienia się w cudzym kodzie podczas inwestygacji problemu.

Ostatecznie jestem nie tylko zadowolony, ale i pod wrażeniem. Claude pomyślał o edge-case’ach, o których ja nie pomyślałem. Napisał tysiące linii kodu w zawrotnym czasie. Czy wszystko działa jak należy? To trzeba sprawdzić. Zaczynam testowanie i szybko okazuje się, że jednak bym coś poprawił, albo zwyczajnie mam defekt. Opowiadam o tym Claude’owi, a ten z zapałem bierze się do poprawy.

Nie, nie - nie możesz tego tak zrobić, bo zepsujesz coś innego - tłumaczę mu po raz kolejny, a on przyznaje mi rację. Osobiście już piętnaście minut temu znalazłem przyczynę buga, ale wciąż daję mu szansę. Ostatecznie poprawiam sam. Inwestygacja zmusiła mnie do zaglądnięcia głębiej w kod i widzę znacznie więcej miejsc do poprawy. To po prostu tylko udaje, że działa. Piszę fragment kodu, żeby pokazać Claude’owi, jak to się robi, i tłumaczę - zastosuj to w reszcie miejsc. Claude to robi, a efekt jest znacznie lepszy, niż gdyby pisał to sam.

Ostatecznie dochodzę do swojego sposobu pracy z Claude’em. Najważniejszy jest oczywiście model danych, potem zakres odpowiedzialności serwisów i ich interfejsy. Claude świetnie dopisze kod asystujący mojemu modelowi. Zrobi to wręcz lepiej ode mnie. Jemu nie pomylą się operatory, nie popełni błędu w klauzulach logicznych, będzie pamiętał o wyjątkach i najbardziej żmudną pracę wykona z zapałem.

Nagle Claude głupieje. Zwyczajna sprawa. Skończył się kontekst. Nie pamięta tego, co robił. Nasz kod, który pisaliśmy razem, staje się dla niego obcy. - Muszę przeglądnąć strukturę kodu - odpowiada, kiedy daję mu kolejne zadanie. Cóż, na szczęście wiem, jak mu to wytłumaczyć i go ukierunkować, ale chwilę to trwa, nie mówiąc o zużytych tokenach. To znaczy, że trzeba na bieżąco zapisywać, co robimy, i opisywać funkcjonalności. To nawet lepiej. Będzie czyściej i porządniej, a zapisywaniem i tak zajmie się AI.

Mam MVP. Do tej pory nie musiałem myśleć o wdrożeniu. Wiem, że podzieliłem aplikację na dockerowalne serwisy i wszystko i tak trafi do klastra k8s, a gdzie on będzie - zdecyduję za chwilę. Kazałem Claude’owi zrobić osobny schemat dla każdego serwisu, więc wszystko jest łatwo przenaszalne. Claude dopisuje konfigi dla k8s - w końcu nic szczególnie nie wykracza poza standardowe elementy. Jeśli chodzi o bazę i deployment - nie potrzebuję korzystać z gotowych providerów, robiłem to tysiące razy. Od dawna mam już bazę produkcyjną dla małych projektów i klaster, gdzie mogę dodać kolejny namespace. Będę potrzebował czegoś więcej? Zmigruję bazę, poprawię konfigi i zdeployuję na inny klaster.

Kiedy przychodzi do mnie pierwszy klient z problemem, wiem, gdzie mam logi, i mogę w nie zaglądnąć. Podrzucam je Claude’owi, bo czemu mam to analizować sam. Ten znajduje problem i poprawia. Czekaj! - mówię. Tak nie możesz tego poprawić, bo stracimy dane użytkowników. „Masz rację! - odpowiada Claude - zrobię to tak, żeby nie dotykać bazy“. Po chwili mamy gotowy fix. Sprawdzam go lokalnie, żeby wiedzieć, czy działa. Robię smoke testy na reszcie funkcjonalności, żeby sprawdzić, czy niczego nie popsuliśmy, ale nie powinniśmy - w końcu rozumiem zmianę w kodzie.

Dochodzę do wniosku, że mam do czynienia z juniorem na sterydach. AI napisze kod znacznie szybciej niż ja, dokładniej niż ja, ale i nabałagani znacznie szybciej i bardziej niż ja.

Wracając do początku - czy potrafię zrobić sam w dwa tygodnie to, co zajęłoby zespołowi miesiąc? Tak. Problem nie leży w pierwszych dwóch tygodniach, tylko w następnych latach funkcjonowania aplikacji. Ulegamy iluzji świeżego projektu, w którym przyspieszenie jest największe, a błędy logiczne jeszcze nieodkryte.

Ostatecznie pojawia się pytanie. Gdybym miał dwie aplikacje robiące to samo i wiedział o nich tylko tyle, że jedną napisał CEO z AI, a drugą programista z AI - od której oczekiwałbym lepszego działania, bezpieczeństwa i długowieczności? Moja propozycja: niech CEO korzystają z programistów, a programiści z AI.