Kiedy „wystarczy, że działa" to za mało

Porozmawiajmy o tym, co wydarzyło się w Godot. Dla tych, którzy missed (heh) ostatnie newsy — ta popularna otwartoźródłowa silnik gier ogłosiła, że nie będzie przyjmować wkładów wygenerowanych przez AI. Ich argument? Maintainerzy po prostu nie mogą zaufać contributorom, którzy nie rozumieją w głębi kodu, jaki przysyłają.

To nie jest zazdrość ani technologiczny snobizm. To realny problem jakościowy, z którym prędzej czy później zmierzy się każdy poważny projekt deweloperski.

Pułapka „vibe coding"

„Vibe coding" — taki modny termin pojawił się dla opisania pisania kodu przez AI, podczas gdy ty skupiasz się na „vibe'u" projektu. I rozumiem — narzędzia jak Claude, Copilot czy ChatGPT są naprawdę przydatne. Pomogły wielu programistom szybciej dostarczać projekty i uczyć się nowych frameworków.

Ale tworzy się tutaj niebezpieczna iluzja: przekonanie, że dostarczenie działającego kodu oznacza jego zrozumienie.

Kiedy wysyłasz pull request do projektu open-source, nie dostarczasz tylko funkcjonalności. Obiecujesz, że będziesz opiekunem tego kodu przez lata. Będziesz naprawiać bugi, obsługiwać edge cases'y, tłumaczyć swoje decyzje innym maintainerom. Jak możesz to robić, jeśli tak naprawdę nie rozumiesz tego, co napisałeś?

Co tak naprawdę mówią maintainerzy Godota

Zespół Godota opisał napływ AI-generowanych PR-ów jako „demoralizujący". Czytaj między wierszami: nie chodzi tylko o irytację. Chodzi o dług techniczny kumulujący się w ich bazie kodu — kod, który działa, ale którego nikt w zespole nie jest w stanie utrzymywać czy debugować.

To ukryty koszt vibe codingu na skalę. Narzędzia AI optymalizują pod kątem szybkiego tworzenia działającego kodu. Nie optymalizują pod kątem długoterminowej utrzymywalności, klarownych komentarzy ani kodu, który naturalnie pasuje do istniejącej architektury projektu.

Złoty środek

Oto rzecz — to nie znaczy, że narzędzia AI są złe. Nie są. Ale jest ogromna różnica między:

• Używaniem AI do nauki nowej koncepcji, a potem pisaniem własnej implementacji
• Używaniem AI do szablonowego kodu, który w pełni rozumiesz
• Używaniem AI do generowania kodu, którego nie potrafisz wyjaśnić, zdebugować ani zmodyfikować

Pierwsze dwa? Całkowicie OK. Trzeci? Tutaj robi się ciężko, szczególnie w projektach colaboracyjnych.

Co to oznacza dla Twoich projektów

Niezależnie czy budujesz startupowy MVP czy utrzymujesz bibliotekę open-source, potraktuj to jako sygnał do przejrzenia własnych praktyk:

1. Czy potrafisz wyjaśnić każdą linię, którą wysyłasz? Jeśli nie, to jest to ryzyko.
2. Czy używasz AI jako nauczyciela czy jako kuli?" Oba podejścia mają sens, ale wiedz, po którą sięgasz.
3. Kto odpowiada, gdy kod wygenerowany przez AI psuje się w produkcji? Podpowiedź: wciąż Ty.

Podsumowanie

Decyzja Godota może wydawać się surowa, ale w gruncie rzeczy chodzi o ochronę integralności collaborative tworzenia oprogramowania. Maintainerzy tego silnika wyznaczają granicę, którą wiele projektów będzie musiało rozważyć, gdy narzędzia AI staną się coraz bardziej wyrafinowane.

Prawdziwe pytanie nie brzmi „czy AI ma miejsce w dewelopmencie" — brzmi „czy jesteśmy szczerzy wobec siebie, jeśli chodzi o to, co tak naprawdę wnosimy, gdy pozwalamy AI robić ciężką pracę".

A Ty co o tym myślisz? To rozsądne stanowisko, czy społeczność open-source zbyt dużo gatekeepuje? Daj znać w komentarzach.