Czy warto poznawać „surowe podstawy” DE w erze AI?

  • Czy warto poznawać „surowe podstawy” DE w erze AI?

    Posted by Marek Czuma on 2026-07-14 at 08:39

    Chciałbym poznać wasze zdanie i jednocześnie powiedzieć o moim.

    Czy dzisiaj warto poznawać takie „surowe”, podstawowe umiejętności, jak Linux, Bash, działanie sieci i serwerów? Albo – choć to trochę „po bandzie” – programowanie?

    Kilka moich spostrzeżeń, po systematycznym, długotrwałym korzystaniu z Codexa, Chata GPT, Cursora oraz z Genie (Databricks Assistant):

    • Asystent AI jest ramieniem, dźwignią. Żeby dobrze działał, musi mieć dobrego rozmówcę. Z tego wynika prosty wniosek: im lepsze skille mam, tym więcej „etapów” i błądzenia mogę ominąć i tym jeszcze lepszy wynik mogę uzyskać z AI.
    • AI potrafi być coraz bardziej kompleksowe. Ale wciąż „nie potrafi” spojrzeć aż tak bardzo z lotu ptaka, jak powinni to robić inżynierowie danych. Często nie dlatego, że nie ma takich „umiejętności”, tylko dlatego, że po prostu, najzwyczajniej w świecie, ciężko go zapiąć „na całym systemie”.
    • Finalnie to tylko narzędzie. Nawet jeśli inne niż reszta. A to prowadzi do prostej konsekwencji: to my odpowiadamy za efekt końcowy. Gdy robię swój prototyp, mogę lecieć na YOLO. Ale gdy robię duży system dla klienta, wypadałoby jednak zweryfikować co tam się w tym kodzie dzieje.
    • Błędy – wciąż się zdarzają. I to częściej niż można by oczekiwać. I nie wychwycimy ich bez tej bazowej wiedzy.
    • Nie zawsze opłaca się korzystać z AI – choć i ja łapię się na tym, że wolę zlecić asystentowi napisanie czegoś banalnego, zamiast poświęcić 20 minut więcej i zrobić to samemu. To trochę odpowiednik wyciągania kalkulatora, żeby policzyć „17 + 38”. Ale… AI kosztuje. I firmy w końcu zaczną coraz mocniej ograniczać wtedy, gdy nie jest to potrzebne. Sądzę, że tak jak dzisiaj specjalizujemy się w optymalizacji jobów sparkowych, tak pojawią się mocne dyskusje jak metodycznie ograniczać koszty zapytań.

    I jeszcze coś: W wielu przypadkach kodowanie się zmieni – i to już się dzieje.
    Klasyczne programowanie jest zastępowane przez wyspecjalizowane zlecanie
    dobrze opisanych zadań. ALE! Nasza robota to potem zrobić code review
    takiego rozwiązania. To może doprowadzić do paradoksu: potrzebni będą ludzie, którzy rozumieją kod i inne techniczne aspekty rozwiązań. Ale nie będzie skąd ich brać, bo będzie coraz mniej kodowania.

    Podsumowując:

    Moim zdaniem na etapie nauki warsztatu należy położyć bardzo mocny nacisk na zrozumienie mechanizmów. Ciągle to jest fundamentem. I będzie jeszcze długo.

    Myślę, że chyba rozwinę te spostrzeżenia w newsletterze najbliższym.

    Ale chętnie poznam wasze zdanie. Szczególnie, jeśli jest inne;-)

    Marek Czuma replied 1 day, 21 hours temu 3 Members · 3 Replies
  • 3 Replies
  • Dominik Szcześniak

    Member
    2026-07-14 at 09:24
    232 Exp

    Hej,

    Ostatnio też się nad tym zastanawiałem. 🙂

    Uważam, że podstawy są dalej istotne i zgadzam się z większością tez, które tutaj postawiłeś.

    Na ten moment AI traktuję jako dźwignię i „przyspieszacz”. Nie jako coś, co mnie totalnie zastępuje. Korzystam w projektach (moja organizacja, pomimo tego, że jest bardzo regulowanym środowiskiem) jest otwarta na użycie narzędzi AI’owych. Prywatnie, czy w projektach dodatkowych również chętnie korzystam np. z Claude Code czy Power BI’owych MCP Serwerów.

    Dużo zależy od modelu który wybierzemy. Nawet na przykładzie Claude’a widzę, jak odpowiedni dobór modelu wpływa na szybkość i jakość rozwiązywania problemów. Co ciekawe, w kwestii np. Power BI widać ogromną różnicę między Sonnetem, a a Opusem (oczywiście na korzyść Opusa), nawet w kwestii realizacji prostych zadań.

    No i tutaj powoli przechodzimy do tego, co wspomniałeś. NIE WYOBRAŻAM sobie, żeby budując dojrzałe, skalowalne rozwiązanie kod nie został przejrzany/ zrozumiany przez DE/ BI Developera.

    Uważam, że zrozumienie podstaw i też doświadczenie, które zdobywaliśmy/ zdobywamy w różnych projektach dają przewagę i pozwalają korzystać z narzędzi jako dźwigni.

    Pytanie, jak to będzie wyglądało za kilka lat. Są też głosy, że obecne modele nadal są bardzo prymitywne i przez najbliższe lata przeskok będzie jeszcze większy. Czy będziemy operatorami i weryfikatorami kodu generowanego przez Agenty?

    Ciekawe też jak to wpłynie w ogóle na specyfikę pracy? Pojawia się też kwestia „cognitive oveload”, tego, że może będą oczekiwania, żeby jeszcze więcej projektów i zadań dowozić w tym samym czasie?

    A może skupimy się jeszcze bardziej na współpracy z biznesem? Na jeszcze lepszym rozumieniu procesów biznesowych/ szukaniu optymalizacji? My, osoby techniczne również.

    Ciekawi mnie też kwestia pricingu, o którym wspominałeś. Wydaje mi się, że niestety idzie to w stronę pay-to-win, czyli ktoś kto ma dużo kasy/ zasobów będzie z przodu wyścigu. Co dalej będzie rozwarstwiało biznesy. Przykład Fable – pokazujemy (teraz do 19.07) wszystkim, a potem jak chcesz to płać (chociaż teraz już są głosy, że nowy model od OpenAI dowozi, więc Fable będzie może ogólnodostępny dalej?). A może wrócimy do on- premów? 🙂 Gdzie każdy będzie trzymał swój model lokalnie, nie martwiąc się też o kwestie związane z bezpieczeństwem danych. (Już teraz w projektach i u Klientów widzę trend (potwierdzają też znajomi Developerzy), że firmy trochę obawiają się uzależnienia od infry zza Oceanu i szukają np. europejskich dostawców chmurowych). To wszystko zależy od potrzeb, wielkości organizacji, zasobów, które może poświęcić np. na zakup sprzętu na lokalne modele (nadal jest to droga impreza 😉 )

    Długie wyszło 😀 Ale temat bardzo ciekawy 🙂 Zachęcam tez innych do wypowiedzi! Miłego dnia!

  • Kasper Bania

    Member
    2026-07-16 at 21:46
    799 Exp

    To właśnie do tego się sprowadza – rola programisty przesuwa się w stronę PM’a, który już nawet nie musi pisać kodu ale musi rozumieć kod generowany przez AI i umieć nim zarządzać w kontekście projektu. Słyszałem też ostatnio zgrabną definicję programisty – to taki ktoś, kto poradzi sobie z kodem jak AI będzie niedostępne 🙂

    Także modele językowe powinniśmy taktować jako asystentów, którzy wspomogą naszą pracę, pomogą gdy utkniemy, przetworzą dla nas trace błędów, bo nam może coś umknąć (kiedyś człowiek potrafił spędzić 3 dni na odkryciu, że jednak tam jest kropka, nie przecinek, dwuliterowy przyjaciel potrafi w ułamku sekundy odkryć ten błąd). Reasumując – uczmy się, rozwijajmy, czujmy temat.

    Dość też powiedzieć, że często AI robi takie babole, że głowa mała.

    Kolejną kwestią jest optymalizacja kosztów… W zeszły weekend mój Dyrektor siadł sobie i stworzył vibekodując POC systemu, który potrzebuje jeden z naszych oddziałów. Spalił na tym tygodniowy limit tokenów i oszacował, że zbudowanie tego rozwiązania pracując tylko z czat-botem wyjdzie 3 razy drożej, niż gdybyśmy kupili na rynku komercyjny program realizujący te same funkcjonalności (chodziło o program do zarządzania warsztatem samochodowym). To zaś co teraz oferowane jest za pół-darmo, za jakiś czas może kosztować konkretne pieniądze, a wiadomo – jak się wplecie to wszystko w procesy firmowe – może być problem.

  • Marek Czuma

    Organizer
    2026-07-17 at 11:18
    5140 Exp

    @dszczesniak „Wydaje mi się, że niestety idzie to w stronę pay-to-win, czyli ktoś kto ma dużo kasy/ zasobów będzie z przodu wyścigu.” – czy to nie jest trochę odwieczne prawo, które działa wszędzie i zawsze? Przynajmniej póki ktoś nie wymyśli czegoś kompletnie innego, co odwraca reguły gry. Wcześniej ogromne korporacje miały gigantyczne zespoły (ciągle mają), na które nie stać małych graczy.

    @kasper zaciekawił mnie case twojego dyrektora. Ale wydaje mi się, że to akurat nie jest najlepsze porównanie – bo nie porównujemy tworzenia oprogramowania do gotowego rozwiązania „z półki” tylko do tworzenia przy pomocy zespołu / samodzielnie. I wtedy sądzę że stworzenie PoCów nigdy nie było tak proste. A to właśnie PoC mogą pokazywać czy „warto

Zaloguj się aby odpowiedzieć