Osąd inżynierski staje się najrzadszym zasobem

Implementacja staje się tańsza. To sprawia, że osąd staje się drogi.

Osąd to nie intuicja ani opinia. To zdolność podejmowania decyzji w warunkach niepewności. AI sprawia, że ta umiejętność jest bardziej widoczna niż kiedykolwiek.

Dwóch inżynierów może otrzymać to samo zadanie: zbudować API do uzgadniania faktur. AI może napisać kod dla obu. Składnia i frameworki będą wyglądać tak samo.

Końcowe systemy będą się różnić. Jeden inżynier może zbudować niechlujny serwis, który trudno utrzymać. Inny może oddzielić reguły biznesowe i logikę do niezależnych komponentów.

AI nie dokonało tego wyboru. Dokonał go inżynier.

Architektura wciąż ma znaczenie, ponieważ implementacja nie jest już czynnikiem różnicującym. Tym czynnikiem są decyzje stojące za kodem.

Złożoność nie znika wraz z AI. Ona się przesuwa.

W przeszłości inżynierowie poświęcali czas na tłumaczenie pomysłów na kod. Teraz to AI dokonuje tego tłumaczenia. Najtrudniejsza praca odbywa się, zanim napiszesz choćby jedną linię.

Musisz odpowiedzieć na pytania takie jak:

  • Jaki problem rozwiązujemy?
  • Które dane są źródłem prawdy?
  • Gdzie powinny znajdować się reguły biznesowe?
  • Jak mierzymy sukces?

Autouzupełnianie nie potrafi na nie odpowiedzieć. Wymagają one kontekstu.

Tworzenie oprogramowania przypomina teraz inżynierię informacji. Wąskim gardłem nie jest kod. Wąskim gardłem jest informacja.

Zmagasz się z:

  • Brakującymi wymaganiami.
  • Niekompletną dokumentacją.
  • Sprzecznymi regułami biznesowymi.
  • Nieokreśloną odpowiedzialnością.

Inżynier, który organizuje informacje, tworzy większą wartość niż ten, który szybko pisze kod.

Przepływ pracy uległ zmianie. Kiedyś wyglądał tak: Wymagania -> Projektowanie -> Kod -> Debugowanie -> Wdrożenie.

Teraz wygląda on tak: Problem biznesowy -> Kontekst -> Architektura -> Implementacja AI -> Weryfikacja przez człowieka -> Bezpieczeństwo -> Ewaluacja -> Produkcja.

Kodowanie jest teraz małą częścią procesu. Priorytetem są działania towarzyszące.

Decyzje o dużym znaczeniu zapadają poza edytorem kodu. Zapadają one, gdy pytasz:

  • Czy to powinno być oddzielny serwis?
  • Czy możemy poddać tę decyzję audytowi?
  • Co się stanie, jeśli AI się pomyli?
  • Czy ta architektura może ewoluować?

Inżynieria AI to coś więcej niż prompty czy wybór modelu. To tylko jedna warstwa.

Prawdziwe wyzwania mają charakter architektoniczny:

  • Jak modelować wiedzę biznesową?
  • Jak rozwiązywać niejednoznaczność?
  • Jak utrzymać zaufanie?

Modele zmieniają się co kilka miesięcy. Architektury trwają latami. Zła architektura bardzo szybko staje się kosztowna.

Najlepsze zespoły budują systemy, które przetrwają wiele generacji modeli. Optymalizują je pod kątem adaptacyjności.

AI to tylko kolejna warstwa abstrakcji. Wyższa abstrakcja wymaga silniejszego rozumowania, a nie słabszego.

Najsilniejsi inżynierowie to nie najszybsi programiści. To ci, którzy wprowadzają klarowność. Definiują architektury, standaryzują dane i redukują niejednoznaczność.

Dobry system pomaga ludziom i agentom AI współpracować. Zły system sprawia jedynie, że błędy występują szybciej.

Inżynier, który wprowadza klarowność, tworzy dźwignię.

Source: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l

Optional learning community: https://t.me/GyaanSetuAi