Agenci AI vs programiści: 5 różnic

Agenci AI w rozwoju oprogramowania: kluczowe różnice w porównaniu do programistów i ich wpływ na proces

Agent oparty na LLM generuje dokumentację architektoniczną dla legacy systemu w Javie z 17 modułami bez dokumentacji. Rezultat: szczegółowe diagramy zależności, opisy interfejsów, adnotacje do komponentów. Dokument imituje specyfikację dojrzałego zespołu. Jednak w miejscach z historycznymi „patyczakami”, takimi jak warstwa proxy zamiast kolejek komunikatów, agent opisał to jako standardową architekturę, wymyślając nieistniejącą logikę bez zastrzeżeń.

Programista zatrzymałby się, by wyjaśnić u autora kodu. Agent operuje tylko widocznym kodem, dopieszczając wyjaśnienia bez wzmianek o założeniach. Im dokładniejszy średni rezultat, tym trudniej wychwycić błędy.

Pięć fundamentalnych różnic agenta od programisty

Brak pamięci projektowej

Agent przetwarza zadanie izolacyjnie, bez nagromadzonego kontekstu. W projekcie ewidencji polowej (raporty offline brygadzistów) synchronizacja konfliktów faworyzuje serwer z powodu przeszłych błędów z duplikatami. Programista przypomina sobie migrację z unikalnym indeksem. Agent wymaga przekazania historii w dokumentach kontekstowych.

Dla narzędzi katastralnych (GKN/EGRN) wspólna analiza formatów zajęła tydzień: różnice w polach, obowiązkowość atrybutów. Bez tego agent generuje sensowny, ale niepraktyczny kod.

Rozwiązanie: prowadź pliki kontekstowe z decyzjami architektonicznymi i dziedziną biznesową.

Dosłowne przestrzeganie specyfikacji

Zadanie: dialog wyboru wersji przy konflikcie synchronizacji. Agent pisze komponent React dla jednego pola. W produkcji psuje się przy konflikcie na kilku polach (data, objętość, komentarz) — reszta zmian ginie.

Programista wyjaśni niejednoznaczności: wspólny dialog czy po polach, scenariusze offline. Agent ignoruje model realnego świata.

// Przykład: kod agenta dla jednego pola
const ConflictDialog = ({ field, localValue, serverValue }) => (
  <Dialog>
    <p>{field}: {localValue} vs {serverValue}</p>
    <button>Lokalny</button>
    <button>Serwer</button>
  </Dialog>
);

Brama jakości w SENAR: cel, kryteria akceptacji, negatywne scenariusze przed startem.

Mnożenie błędów

Przy generowaniu 11 narzędzi katastralnych błąd w formule współrzędnych (kilka cm odchylenia, krytyczne dla pomiarów granicznych) powtórzył się w trzech. Szybkość agenta wzmacnia zarówno sukcesy, jak i porażki.

• Sprawdzaj kilka modułów z zestawu, nie jeden.
• Błąd w patternie kopiuje się do wszystkich podobnych plików.

Ignorowanie długoterminowej architektury

Zadanie: wyszukiwanie po linkach w Sortule. Agent robi bezpośrednie zapytanie z handlera. Optymalne dla skryptu, ale dla rozwijającego się projektu potrzebna warstwa serwisowa do cache'owania, rankingu, testów A/B.

Po dodaniu sekcji architektury do kontekstu agent konsekwentnie używa warstwy.

Brak odpowiedzialności za konsekwencje

Migracja BD: kaskadowe usuwanie brygadiera kasuje raporty i zdjęcia. Testy nie łapią — napisane na schemacie. Agent zapomina zadanie natychmiast.

Programista przewidzi błędy za miesiąc. Odpowiedzialność na liderze: ręczna weryfikacja migracji.

Trzy konsekwencje dla procesu inżynieryjnego

• Podwójna weryfikacja: agent przyspiesza, ale wymaga walidacji w kluczowych punktach — architektura, migracje, negatywne scenariusze.

• Kontekst jako podstawa: przechowuj w repozytorium decyzje architektoniczne, dziedzinę biznesową, historię. SENAR to standaryzuje.

• Filtr ludzki: agent to wykonawca, nie strateg. Inicjatywa i odpowiedzialność po stronie człowieka.

Co najważniejsze

• Agenci przewyższają w statycznej analizie kodu, ale dopieszczają niewidoczne detale logiką bez zastrzeżeń.
• Dosłowne wykonanie wymaga szczegółowych specyfikacji z negatywnymi przypadkami.
• Błędy mnożą się w seriach modułów — selektywna weryfikacja obowiązkowa.
• Decyzje architektoniczne przekazuj do kontekstu z wyprzedzeniem.
• Pełna odpowiedzialność za produkcję spoczywa na programiście-liderze.

— Editorial Team