Dlaczego niektórzy programiści odrzucają AI w kodowaniu i wolą klasyczną metodę

W świecie techu panuje szał na sztuczną inteligencję. Każda nowa aplikacja ma "zrewolucjonizować" programowanie. Na konferencjach słychać o gigantycznych wzrostach produktywności. Startupy chwalą się LLM-ami w pitchach. Brzmi kusząco. Ale nie każdy kupuje ten hype.

Coraz więcej doświadczonych deweloperów mówi: stop. Zastanawiają się, czy to naprawdę potrzebne. W tym wpisie sprawdzamy, dlaczego wybierają stary dobry edytor tekstu zamiast AI. Ich wątpliwości pokazują, jak mądrze dobierać narzędzia do kodowania.

Koszty subskrypcji – nie zawsze się opłacają

Zacznijmy od portfela.

Narzędzia z AI do kodowania działają na abonament. Płacisz co miesiąc lub rok za integrację z IDE. Na papierze to fair. Ale w praktyce to ciągły wydatek na pomoc, której używasz rzadko.

Wielu wraca do prostych edytorów. Rachunek jest prosty: jeśli AI pomaga tylko w 10% zadań – np. generuje szablony czy dokumentację – po co płacić? Darmowe narzędzia robią to samo od lat. Kupujesz raz i masz spokój.

Starsi programiści pamiętają no-code i low-code. Obiecywały koniec pisania kodu. Zamiast tego narobiły długu technicznego. Nowe fale narzędzi dają zyski, ale nigdy tyle, co w reklamach. Skeptycyzm to nie odrzucenie AI. To pytanie: czy narzędzie rozwiązuje właściwy problem?

Złożoność: przypadkowa kontra esencjonalna

Tu wchodzi filozofia.

Fred Brooks w eseju "No Silver Bullet" dzieli złożoność na dwie. Accidental complexity to nudne sprawy: zarządzanie pamięcią, boilerplate, zapominanie API. To irytuje, ale nie jest trudne.

Essential complexity to sedno: zrozumienie wymagań biznesu, architektura, stan w systemach rozproszonych, debugowanie interakcji. To wyzwania, które istnieją zawsze – od Assembly po Python.

Języki i frameworki już ogarnęły większość accidental complexity. Nie piszemy kodu maszynowego. Używamy bibliotek, menedżerów pakietów, linterów, testów. Automatyzacja działa od dawna.

AI w kodowaniu atakuje głównie accidental complexity. Generuje endpoint REST czy test jednostkowy? To problemy znane i udokumentowane. Prawdziwy korek w devie to nie składnia. To decyzje: co budować i jak.

Wieża abstrakcji – nowe pułapki

Pomyśl o stosie, na którym stoisz. Linijka Pythona uruchamia miliony operacji: bytecode, interpreter, OS, CPU, krzem.

AI chce dodać kolejną warstwę. Agenci mają brać zadania i kodować sami. Brzmi jak marzenie.

Ale każda warstwa abstrakcji rodzi nowe błędy. Gdy coś się sypie, schodzisz niżej. Musisz rozumieć, co pod spodem.

Kod z AI to dodatkowa abstrakcja między twoim zamysłem a implementacją. Błędy? Musisz rozkminiać, co AI wymyśliło. To nie oszczędność czasu. To ukryty koszt utrzymania.

Doświadczenie kontra hype

Tu gra doświadczenie.

Tech uwielbia młodych i szybkich. Pięć lat to "senior". Ale deweloperzy z dekadami na koncie mają wiedzę z porażek. Znają ryzyko. Przetrwali Java, Ruby, Node, blockchain, serverless.

To nie atak na młodych. Ale cykle hype'u uczą ostrożności. Skeptycyzm to nie blokada postępu. To filtr na bzdury.

Co to znaczy dla użytkowników NameOcean

W NameOcean stawiamy na AI, ale szczerze mówimy o granicach.

Na Vibe Hosting AI pomaga tam, gdzie ma sens: wybory infrastruktury, optymalizacja deploymentu, analiza skalowania. To konkretne zyski, bo problemy są jasne.

Nie zastępujemy programisty. Usuwamy tarcie z infra, deploymentu, monitoringu.

Skeptyczny wobec AI w kodowaniu? Dobrze myślisz. Używaj tam, gdzie oszczędzasz na nudzie. Pomijaj, gdy trzeba być blisko problemu.

Przyszłość devu to nie wywalenie ludzi. To pozbycie się rozpraszaczy od zadań, w których jesteśmy najlepsi.