W zamierzchłych czasach gdy komunikację z procesorem zastępował C, a później języki obiektowe, też można byłoby powiedzieć, że programiści specjalizujący się tylko w wysokopoziomowych językach nie do końca rozumieją co robią. Ale czy musieli rozumieć? Czy odbierało im to możliwość dostarczania wartości biznesowej? Co do zasady - wątpię.

Tak jak i wtedy, tak i dziś są pewne kwestie, które wymagają myślenia, szerokiej wiedzy i doświadczeń. Projektowanie architektury, optymalizacje czy podejmowanie kluczowych długoterminowych decyzji to są właśnie te rzeczy... ale takie kompetencje przecież nie przynależą juniorowi. Junior musi mieć generalne spojrzenie na to co robi i dowozić konkretne efekty w postaci wytworzonego oprogramowania. Korzystając z narzędzi AI nie degraduje swojego umysłu czy doświadczenia, on zdobywa tylko to doświadczenie, które jest mu realnie potrzebne. Stosując analogię - on dzisiaj by wykopać dół nie potrzebuje już łopaty, ma całą koparkę. Nie rozwinie nią mięśni, ale z jej użyciem tych mięśni już rozwijać nie potrzebuje.

Taka "koparka" nie wykopie idealnego dołu o perfekcyjnych wymiarach, ale mniej więcej osiągnie pożądany cel. Przy tworzeniu oprogramowania jest wg mnie podobnie - precyzyjność jest mniej istotna od optymalności. Brak wiedzy co się dzieje pod spodem naszych działań nie jest szkodliwa, jest powszechna i potrzebna. I wielkim paradoksem jest, że starsi programiści krytykują dzisiejszych juniorów za brak dogłębnej wiedzy o pisanym kodzie (czemu winne są rzekomo rozwiązania AI), gdy oni sami przecież nie czytają całego kodu źródłowego bibliotek czy frameworków, z których korzystają na co dzień. Każdy działa na ślepo i ja nie uważam, że jest w tym cokolwiek złego.

Szkodliwym jest za to "dziadkowanie", że oj ci młodzi to nic nie rozumieją. Ich myślenie o tworzeniu oprogramowania jest zupełnie inne - liczy się przede wszystkim osiąganie celu, a nie precyzja techniczna, dzisiaj na jeszcze wyższym poziomie niż kiedykolwiek wcześniej. I ja uważam, że to bardzo dobrze, to jest właśnie prawdziwe myślenie o programowaniu jak o narzędziu, a nie celu samym w sobie.