Taka obserwacja z pracy z vibe codingiem...
Pracuję w czymś, co de facto jest startupem wewnątrz firmy. Raz widać to bardziej, raz mniej. Ostatnio bardziej. Cała koncepcja nagle się zmieniła i coś, co zbudowałem w ramach zabawy z vibe codingiem jako prototyp (najpierw tworząc historyjki i wstępne szkice), powoli staje się głównym silnikiem docelowego rozwiązania.
Teraz próbuję przenieść część kodu z tego prototypu do lambd. W przyszłości chcę mieć pełną funkcjonalność prototypu, czyli modyfikowanie plików językiem naturalnym, ale na razie potrzebuję prostego, deterministycznego API zmieniającego te pliki według parametrów. Bo to zostało obiecane klientowi.
I tu pojawia się problem z vibe codingiem: ten kod pisał obcy.
Co innego mieć kod w prototypie, co innego wrzucać go do aplikacji obsługującej klientów. Trzeba ten kod przejrzeć, a jest tego od groma. Trzeba dopisać lepsze testy. Claude oczywiście napisał własne testy, ale przed robieniem demka w ramach executive summary chciałem pokazać animację z jedną drogą, zmienić ją toolem i pokazać wynik... Droga złośliwie się nie zmieniała. Choć testy przechodziły, to testowały to, co Claude'owi wydawało się właściwe, a nie to, co faktycznie trzeba było zrobić ;-)
I taka praca męczy, bo więcej czasu spędzam na próbach zrozumienia, co Claude miał na myśli, niż na kodowaniu.
Mam zresztą szerszą obserwację z pola walki i z otoczenia. Claude i podobne narzędzia są świetne do dobrze zdefiniowanej roboty na istniejącym kodzie. Mieliśmy na przykład problem z mapą: były na niej wszystkie klasy dróg, ale system generujący z nich 3D domyślnie operuje na 2-3 najwyższych klasach, a na pozostałych tylko wtedy, gdy się go do tego zmusi (magiczny przełącznik Urban Roads). W efekcie klient widział na mapie drogi, których w 3D nie było. Z Claude'em byłem w stanie to szybko ogarnąć: poczytał o API map, porównał z zapytaniem do serwera i teraz na mapie widać dokładnie te drogi, które trafiają do 3D. Prosto opisane zadanie i zrobione super.
To samo sprawdza się, gdy robi się coś zupełnie nowego od zera. W kilkanaście minut ma się prototyp, który samemu pisałoby się 2-4 tygodnie, i to od razu z ładnym UI.
Problemy zaczynają się, gdy chcesz to ulepszyć, dodać złożone warunki i specyficzną logikę biznesową. Słuchając "Security Now!" i innych podcastów z sieci TWiT, widzę, że to powszechne. Leo Laporte próbuje z Claude'em przepisać swój stary system do faktur i mam wrażenie, że od dwóch miesięcy "prawie skończył". Ma wszystko w ładnym UI, tylko system wciąż nie do końca działa tak, jak powinien ;-)
Podobne postybeta
Zdolny Junior z rozmachem ;-) zwany też jako Claude Code
O wyższości debuggera
Złej (albo leniwej) baletnicy przeszkadza i rąbek u spódnicy
Jak VHDL obalił komunizm
Zauroczył mnie Cladue Code ;-)
Brak komentarzy:
Prześlij komentarz