Nieraz w dyskusjach w jednej z poprzednich firm, gdy rozmawiałem z PMami miałem argument, że w końcu to developerzy są niezbędni do zbudowania produktu. PM, PO, EM nawet QA są po to by ten proces był szybszy i lepszy, ale sami bez developerów nic nie zbudują, a developerzy bez nich i owszem ;-)
Ale teraz vibecoding sugeruje, że jednak PM/PO o odpowiednim poziomie ogaru wystarczy.
Z jednej strony się zgadzam, z drugiej mam pewne wątpliwości.
Wątpliwości związane z nazwijmy to ilością informacji, która jest w stanie przetworzyć człowiek.
Wiemy z nauki o tym jak się ludzie uczą i zapamiętują, że nasz mózg jest w stanie w danym momencie trzymać w "pamięci podręcznej" 4 do 7 rzeczy, ale dla większości populacji to jest bliżej 4. To są rzeczy o których możemy myśleć tak, że bez dodatkowych narzędzi jak jakieś wizualizacje umiemy śledzić interakcję i wpływanie na siebie tych rzeczy.
Mamy tutaj 2 sposoby ataku, jeden to narzędzia zewnętrzne, np. wizualizacja czy to na kartce, czy przez postawienie rzeczy na stole... ale to działa tylko dla pewnych rzeczy, czasem to o czym myślimy ma więcej niż 2 czy nawet 3 wymiary, czasem relacji nie da się "uprzestrzennić", no i nie wszyscy tak myślą.
Drugą metodą jest chunkowanie, albo bardziej abstrakcje. Możemy zbiór pewnych rzeczy złożyć w grupę i myśleć o niej jako o jednej rzeczy, ukrywając co jest w środku.
Vibecoding to takie narzędzie łączące dwie te techniki. Z jednej strony ukrywa złożoność problemu, z drugiej daje nam prosty interfejs do sugerowania zmian. Zakładając, że to działa (jest teraz powiedzmy znośnie) daje to możliwość ukrycia złożoności i przez to jeden człowiek jest to w stanie ogarnąć.
Systemy agentowe sugerują, że to można budować tak warstwami, tam gdzie był jeden człowiek jest agent, tam gdzie był jeden nadzorca, jest agent i warstwa po warstwie... ale i to jest "wydaje mi się", "gut feeling" i tym podobne.
Jest jakaś granica. Każda warstwa dodaje niepewność w interpretacji, ukrywa to przed nami i w pewnym momencie troubleshooting jest niemożliwy... bo root cause problemu jest bardzo głęboko, albo jeszcze zabawniej jest wynikiem interakcji wielu ukrytych głęboko problemów.
To jest tak jak dziś z LLMami... albo z ulubionymi przez Stephena Wolframa emergentnymi właściwościami. Gdzieś w końcu się pojawia coś czego abstrakcja nie umie ukryć bez zgubienia zrozumienia.
Nie do końca wiem jaki z tego wniosek wypływa ;-) poza tym, że mam wrażenie, że vibecoding nie wyeliminuje programistów. Może nas zmienić, może zmniejszyć ilość, może (acz tu mam wątpliwości) obniżyć próg wejścia (czyli tu jestem w pozycji, jeśli PM/PO są w stanie używając vibecodingu zbudować coś, to najpewniej są intelektualnie zdolni do nauczenia się programowania).
Tak, to jest gut feelign, bo może, kiedyś agenty nie będą miały ograniczenia jak my 4 rzeczy naraz w głowie, ale będą w stanie operować na 1000 albo milionie? Tylko, że wtedy agent będzie nie tylko bystrzejszy od nas, my będziemy jak mrówka w stosunku do człowieka.... (a i tu nie wiemy, czy nie ma jakiejś granicy inteligencji i jak daleko od niej jesteśmy ;-))
Jeszcze inna sprawa, vibecoding pokazuje, że trudność w projekcie jest w tym by zdecydować co chcemy zbudować, ale chodzi o taki opis gdzie nie macha się rękami, a podaje konkretne rozwiązania ;-)
Podobne postybetaNie lenistwo, a strach. Prawdziwe źródło długu technicznegoSerce czy rozum?Nie lejmy betonu na kod.... Bez człowieka ani rusz ;-)Taki tam rant po Gradle i Dockerze ;-)
