DHH mówi "stop" tradycyjnemu podejściu

W świecie Ruby on Rails głos Davida Heinemeier Hanssona zawsze był głośny i wyraźny. Dlatego gdy twórca Rails i współwłaściciel 37signals ogłosił, że zmienił zdanie na temat narzędzi AI do kodowania, społeczność programistów – nie tylko ta związana z Ruby – zamarła w oczekiwaniu.

Na jednym z odcinków podcastu z Robbym Russellem DHH nie ograniczył się do grzecznego kiwnięcia głową w stronę AI. Stwierdził wprost, że traktowanie AI poważnie to "obowiązek zawodowy". Dla kogoś, kto zbudował Rails na fundamencie rzemiosła programistycznego i starannie pisanego kodu, to naprawdę duże słowa.

Czym jest vibe coding?

Termin "vibe coding" pewnie już gdzieś Ci się obił o uszy. To potoczne określenie na współpracę z asystentami AI przy generowaniu kodu. Ale podejście DHH wykracza daleko poza bezmyślne kopiowanie odpowiedzi ChatGPT.

W 37signals vibe coding stał się wewnętrznym eksperymentem. Designerzy i product managerowie pracują teraz bezpośrednio w kodzie, ramię w ramię z programistami. Tradycyjny, uznawany za świętość sześciotygodniowy cykl Shape Up? Też "do rozważenia". Chodzi o coś więcej niż zastępowanie developerów – chodzi o demokratyzację tworzenia oprogramowania i szybsze iteracje.

Główna zasada? "Git reset and try again." Eksperymentowanie jest tanie, więc kod wygenerowany przez AI, który nie trafia w sedno, nie jest porażką – to po prostu paliwo do następnej próby.

Basecamp 5: teoria w praktyce

Ta filozofia nie jest oderwana od rzeczywistości. Jest wdrażana. Niedawno wystartowało Basecamp 5, które można uznać za pierwszy poważny produkt, gdzie te praktyki zostały w pełni zintegrowane z workflow 37signals.

Rezultaty mówią same za siebie: szybsze iteracje, zespoły cross-funkcjonalne łamiące tradycyjne silosy, gotowość do oddania AI żmudnej pracy – żeby ludzie mogli skupić się na tym, co naprawdę interesujące.

Rails: spokój w erze zmian

Co ciekawe, sam Rails nie musiał się dramatycznie zmienić, by to wszystko działało. Backend frameworka pozostaje tak stabilny, że plik modelu napisany w 2026 roku wygląda naturalnie obok tego z 2013 roku. Ta stabilność to ogromna zaleta w erze AI – konwencje są tak ugruntowane, że narzędzia AI mogą generować kod Rails z wysokim prawdopodobieństwem sukcesu.

W roadmapie Rails znajdziemy kilka interesujących nowości:

• Lexi – edytor oparty na Lexical, który trafi do ActionText
• Native passkeys – nowoczesne uwierzytelnianie bez haseł
• Magic links – płynne i bezpieczne logowanie jednym kliknięciem

Te funkcje pokazują, że Rails nie tylko dostosowuje się do AI, ale nadal ewoluuje jako framework stawiający na doświadczenie dewelopera i rozsądne ustawienia domyślne.

Co z tego wynika dla Ciebie?

Niezależnie od tego, czy prowadzisz startup, zarządzasz zespołem programistów, czy dopiero zaczynasz przygodę z web developmentem, pivot DHH niesie jasny przekaz: narzędzia są mniej ważne niż efekty. Ręczne pisanie każdej linijki kodu nigdy nie było celem samym w sobie – chodziło o budowanie świetnego oprogramowania, które rozwiązuje realne problemy.

Narzędzia AI nie umniejszają rzemiosła w tworzeniu oprogramowania. Zmieniają jedynie miejsce, gdzie to rzemiosło się przejawia. Programiści i zespoły, które będą się rozwijać, to te, które adaptują swoje workflow, eksperymentują odważnie i pamiętają, że kod to środek do celu, nie cel sam w sobie.

W NameOcean obserwujemy tę ewolucję na co dzień. Nasi klienci coraz częściej budują projekty wykorzystujące workflow wspomagane AI, a wybór platformy ma znaczenie. Stabilność Rails połączona z otwartością na nowe paradygmaty dewelopmentu czyni z niego świetny wybór dla zespołów gotowych na vibe coding bez porzucania dobrych praktyk.

Przyszłość Rails to nie wybór między rzemiosłem a szybkością. To posiadanie obu naraz – i szczerze mówiąc, to podejście, do którego warto się dostosować.