Inżynieria agentowa w pięciu warstwach: od specyfikacji i agentów równoległych po reguły i nadzór
Karpathy nazwał ten proces kodowaniem w stylu „vibe coding”. Przyjrzyj się pięciu warstwom inżynierii agentowej: specyfikacjom, orkiestracji, zapisanym regułom, ludzkiej ocenie i możliwościom obserwacji, a także planowi tygodniowemu.
Kodowanie w stylu „vibe” cieszyło się dużym powodzeniem. Andrej Karpathy, osoba, która wprowadziła ten termin, ogłosił już koniec tej ery; nie tylko określił problem, ale także naszkicował to, co ma go zastąpić: inżynierię agentową, w której agenci sztucznej inteligencji planują, piszą, testują i wdrażają kod, podczas gdy człowiek sprawuje uporządkowany nadzór. Człowiek określa cel, agenci go realizują, a człowiek sprawdza wynik. To profesjonalna metoda budowania z wykorzystaniem sztucznej inteligencji, a nie tylko obok niej, i jest to daleko od przypadkowego zadawania poleceń w nadziei na pozytywny rezultat.
Ranniejsze dążenia do rozwoju opartego na specyfikacjach, polegające na zapisaniu tego, co system musi robić, zanim jakikolwiek agent cokolwiek stworzy, okazały się obejmować jedynie jeden warstwę tej dyscypliny. Zespoły w środowisku produkcyjnym uzupełniły później jeszcze cztery warstwy. Poniżej przedstawiono wszystkie pięć warstw, pokazano, jak wyglądają one w praktyce, oraz zamknięto tekst planem ćwiczeń trwających tydzień, który pomoże rozpocząć pracę.
Dlaczego nazwa ma znaczenie
To określenie to coś więcej niż tylko branding. Wyznacza granicę pomiędzy dwoma zupełnie różnymi sposobami pracy, a Karpathy nakreślił tę granicę za pomocą dwóch pytań. Kodowanie w stylu Vibe pyta, czy coś da się sprawić, by funkcjonowało. Inżynieria agentowa pyta natomiast, czy da się sprawić, by funkcjonowało niezawodnie, na dużą skalę i bez wprowadzania luk bezpieczeństwa.
Pierwsze pytanie usuwa ograniczenia. Każdy może teraz tworzyć prototypy: osoba pracująca w wolnym czasie opisuje to, czego chce, przyjmuje otrzymane wyniki i w rezultacie ma gotową działającą demonstrację. To naprawdę przydatne do eksploracji. Drugie pytanie natomiast ustala górne granice. Oprogramowanie, które przetwarza płatności, obsługuje dane zdrowotne lub zarządza infrastrukturą, wciąż wymaga profesjonalnej dyscypliny. Agent może napisać kod, ale to człowiek musi zaprojektować system, określić jego granice i sprawdzić wyniki.
Sam Karpathy sformułował to dosadnie: inżynieria agentów to dyscyplina inżynieryjna, a agenci są niestabilni, stochastyczni i niezwykle potężni, więc prawdziwym problemem jest skoordynowanie ich tak, by działały szybciej, nie obniżając przy tym standardu jakości. Ten problem – szybkość bez poświęceń jakości – jest obecnie kluczowym pytaniem w tej dziedzinie. To nie tylko jego opinia. IBM, Forrester i Anthropic opublikowały w tym samym kwartale formalne ramy dla odrębnej, nowej dyscypliny, dochodząc do tego niezależnie. Gdy organizacje, które rzadko się zgadzają, dochodzą do tego samego wniosku w tym samym czasie, idea ta ma uzasadnienie.
Termin ten utrwalił się, ponieważ inżynierowie potrzebowali nazwy dla pracy, którą już wykonywali: bardziej ustrukturyzowanej niż proste polecenia, bardziej zdyscyplinowanej niż kodowanie oparte na nastroju, a jednocześnie różniącej się od tradycyjnego rozwoju oprogramowania. Dyscyplina, którą opisuje, składa się z pięciu warstw, przy czym każda z nich opiera się na tej poniżej. Jeśli pominąć jedną z nich, cała struktura staje się niewiarygodna.
Warstwa 1: specyfikacja
Napisz specyfikację przed tym, jak jakikolwiek agent wygeneruje jakikolwiek kod. Określ, co system musi zawsze robić, czego nigdy nie może robić, jak sprawdzić, czy funkcjonuje, oraz jak stwierdzić, że przestał pracować. Umieść to wszystko w jednym dokumencie, utrzymuj ten dokument aktualny i oceniaj wszystko, co tworzy agent, w oparciu o niego.
Różne środowiska w inżynierii sztucznej inteligencji nazywają to planowaniem strategicznym, definiowaniem intencji lub po prostu specyfikacją. Nazwa może się różnić, ale praktyka pozostaje ta sama: trzeba wiedzieć, czego się chce, zanim poprosi się agenta o jego stworzenie.
Jest jeden punkt, który łatwo przeoczyć. Specyfikacja nie jest dokumentem powstałym w dniu uruchomienia – to żywy dokument. Ilekroć implementacja ujawnia coś, czego specyfikacja nie przewidziała (a zawsze tak się dzieje), specyfikacja jest aktualizowana. Zespoły, których pracownicy stopniowo odbiegają od pierwotnego zamysłu, to niemal zawsze te zespoły, które napisały specyfikację od samego początku i nigdy więcej jej nie otworzyły.
Minimalny szablon zaczyna się od nagłówka, który określa ten dokument jako źródło prawdy:
# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth
Następnie znajdują się listy kontrolne zachowań, sekcja z wymaganymi zachowaniami oraz sekcja z surowymi ograniczeniami, takimi jak zakaz przetwarzania zwrotu pieniędzy w wysokości powyżej 500 dolarów bez zatwierdzenia przez człowieka:
## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A
Trzymaj to na jednej stronie. Jeśli specyfikacja jest dłuższa, funkcja jest zbyt rozbudowana i należy ją podzielić, aż każda jej część zmieści się na tej stronie.
Nawet doskonała specyfikacja przekazana jednemu agentowi napotyka ograniczenia wydajności, dlatego istnieje druga warstwa.
Warstwa 2: orkiestracja
Rozważmy funkcję, która dotyczy schematu bazy danych, API, interfejsu użytkownika oraz zestawu testów. Tradycyjnie jeden inżynier pracuje kolejno nad poszczególnymi elementami lub zespół koordynuje prace w ramach sprintu. W inżynierii opartej na agentach czterech agentów zajmuje się jednocześnie wszystkimi czterema elementami: jeden pisze kod migracji, drugi punkty końcowe, trzeci komponenty interfejsu użytkownika, a czwarty pisze testy i sprawdza pozostałe elementy pod kątem problemów bezpieczeństwa. Każdy z nich ma swój własny kontekst i ograniczenia, a ich wyniki są łączone w jedną spójną zmianę.
To nie jest hipoteza. Stripe stosuje ten model w środowisku produkcyjnym, wykorzystując wewnętrzny system agentów, który co tydzień generuje ponad 1000 połączonych żądań pull request, z których każde jest tworzone przez agenta, sprawdzane przez człowieka, przechodzi testy CI i jest wdrażane. Korzyść jest wielokrotnie większa, a nie dwukrotna.
Rytm pracy składa się z pętli powtarzającej się dla każdej funkcji: planowanie, realizacja, weryfikacja. Niektóre zespoły nazywają to pętlą PEV.
- Planowanie. Człowiek tworzy specyfikację na podstawie informacji z poziomu 1 i dzieli pracę na niezależne, możliwe do delegowania jednostki. Ważną decyzją jest określenie, które zadania mogą być wykonywane równolegle, ponieważ nie zależą od wyników innych zadań, a które muszą być wykonywane kolejno.
To, co kiedyś zajmowało dwa tygodnie, teraz obejmuje zaledwie kilka godzin lub jeden dzień intensywnej pracy. Większość wysiłku ludzkiego skupia się na planowaniu i weryfikacji, podczas gdy agenci wykonują większość pracy pomiędzy nimi.
Nuansę tę trzeba czasu, by ją pojąć: celem jest użyteczny paralelizm, a nie maksymalny. Trzy agenty działające na ściśle powiązanych modułach powodują konflikty, których rozwiązanie kosztuje więcej niż oszczędności uzyskane dzięki równoczesnemu działaniu. Dwa agenty na niezależnych modułach, z trzecim, który sprawdza oba, dają spójny wynik. Umiejętność polega na dekompozycji zadania, tak by można je było delegować bez późniejszych problemów z integracją.
Skelet orkiestratora może opisać ten cykl w swoim docstringu:
class AgenticOrchestrator:
"""Plan → Execute (parallel) → Verify"""
i wdrożyć krok planowania, który dzieli funkcjonalność na zadania nadające się do delegacji:
def plan(self, feature_spec: dict) -> dict:
"""Decompose feature into independently delegatable tasks."""
tasks = []
for component in feature_spec["decomposition"]:
tasks.append({
"id": component["id"],
"spec": component["scope"],
"constraints": feature_spec["must_never"] + component.get("local_rules", []),
"depends_on": component.get("depends_on", []),
"verification": component.get("success_criteria", []),
})
independent = [t for t in tasks if not t["depends_on"]]
sequential = [t for t in tasks if t["depends_on"]]
return {"parallel": independent, "sequential": sequential} async def execute(self, plan: dict):
"""Run independent tasks in parallel, sequential tasks in order."""
parallel_results = await asyncio.gather(*[
self.delegate_to_agent(task) for task in plan["parallel"]
])
for task in plan["sequential"]:
result = await self.delegate_to_agent(task, prior=parallel_results)
parallel_results.append(result)
return parallel_results def verify(self, results: list, spec: dict) -> dict:
"""Check all outputs against the spec — structural, not line-by-line."""
issues = []
for result in results:
if not self.satisfies_spec(result, spec):
issues.append(f"{result['id']}: does not satisfy spec")
if self.conflicts_with(result, results):
issues.append(f"{result['id']}: conflicts with another module")
return {"passed": len(issues) == 0, "issues": issues}
Zasadą przewodnią jest ścisłe określanie zakresu kontekstu. Każdy agent powinien otrzymywać jedynie swoją sekcję specyfikacji, pliki kodu oraz zasady. Wrzucanie całego repozytorium kodu do każdego okna kontekstowego marnuje tokeny, zwiększa koszty i osłabia zdolność modelu do skupienia uwagi.
Orkiestracja zapewnia wydajność, a wydajność bez spójności prowadzi do chaosu. Każdy agent musi znać konwencje zespołu, ograniczenia architektoniczne i polityki bezpieczeństwa, a także specyfikację swojego zadania. Następna warstwa dostarcza te informacje.
Warstwa 3: skodyfikowane zasady
Większość narzędzi już posiada coś w tym rodzaju. Claude Code ładuje plik CLAUDE.md na początku każdej sesji, Cursor czyta plik .cursorrules, a Codex – AGENTS.md. Koncepcja jest podobna: plik w korzeniu projektu, który określa, jak ma się zachowywać agent.
W 2026 roku zespoły posunęły się jeszcze dalej i zakodowały całą swoją kulturę rozwoju jako ograniczenia zrozumiałe dla agentów, wykraczając poza sam zestaw technologiczny. Praktycy tacy jak Paul Duvall dokumentują wzorce pochodzące z zespołów produkcyjnych, a InfoQ śledzi ich poziom dojrzałości. Cztery wzorce pojawiają się wszędzie tam, gdzie stosowana jest inżynieria oparta na agentach:
- Rozwój kierowany specyfikacją, w którym to specyfikacja określa zakres pracy (Warstwa 1).
- Kodowane zasady i ograniczenia architektoniczne: konwencje, polityki bezpieczeństwa, wzorce obsługi błędów, standardy nazywania oraz procedury wdrażania – wszystko to znajduje się w plikach, które agenty ładują przed rozpoczęciem pracy.
- Aтомowa dekompozycja z użyciem agentów równoległych: funkcjonalności dzielone na najmniejsze możliwe elementy, które mogą być przekazywane samodzielnie (Warstwa 2).
Największym problemem jest skalowanie. Jeden plik CLAUDE.md sprawdza się dobrze przy prototypie składającym się z 1 000 linii kodu. Baza kodu licząca 100 000 linii nie może być opisana w jednym pliku, a nawet gdyby to było możliwe, zasady zajęłyby całe okno kontekstowe, zanim agent dotrze do rzeczywistego zadania.
Zespoły, które rozwiązują ten problem, budują hierarchiczne systemy zasad, podobnie jak konfiguracje ESLint dziedziczą ustawienia organizacyjne i mogą być modyfikowane dla poszczególnych projektów. Struktura folderów wygląda następująco:
your-company/
├── .ai-rules/
│ └── org-rules.md ← Company-wide: security, compliance, style
│
├── team-payments/
│ ├── .ai-rules/
│ │ └── team-rules.md ← Team-level: error handling, testing, deploys
│ │
│ ├── service-checkout/
│ │ ├── CLAUDE.md ← Repo-level: architecture, tech stack, builds
│ │ ├── src/
│ │ │ ├── auth/
│ │ │ │ └── .ai-rules.md ← Module: auth-specific constraints
│ │ │ └── payments/
│ │ │ └── .ai-rules.md ← Module: PCI compliance rules
Na górze znajduje się plik organizacyjny, załadowany dla każdego agenta w każdym repozytorium. Obejmuje kwestie takie jak nigdy nie przechowywanie sekretów, wymaganie autoryzacji w publicznych API oraz unikanie udostępniania śladów wykonywania w odpowiedziach na błędy:
# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context
Poniżej znajduje się plik zespołu, który dziedziczy te zasady i dodaje własne, takie jak wzorzec Result zamiast rzucanych wyjątków, cały dostęp do bazy danych przez warstwę repository oraz testy obejmujące prawidłowy przebieg działania oraz co najmniej dwa scenariusze awarii:
# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data
Agent ładowuje zasady organizacji, zasady zespołu, plik CLAUDE.md repozytorium oraz zasady dotyczące modułu, którym się zajmuje. Dzięki temu kontekst pozostaje skoncentrowany i uporządkowany. Agent pracujący w module płatności otrzymuje zasady zgodności z PCI, natomiast agent w interfejsie użytkownika ich nie otrzymuje, ponieważ te zasady marnowałyby zasoby kontekstu bez żadnego efektu.
Zasady określają, jak należy pracować, ale wynik nadal wymaga ludzkiej oceny. Kod może przestrzegać wszystkich konwencji i mimo to być błędny pod względem architektonicznym, rozwiązując postawiony problem w sposób, który powoduje większy problem gdzie indziej. Dlatego kolejna warstwa nie jest opcjonalna.
Warstwa 4: nadzór ludzki
Trzy słowa opisują model działania, który się ukształtował: delegowanie, sprawdzanie, przejmowanie odpowiedzialności.
Delegowanie. Przekaż agencie dobrze określone zadanie z jasnymi ograniczeniami i pozwól mu pracować. Nie kontroluj każdego kroku realizacji ani nie obserwuj, jak pisze. Specyfikacja i zasady istnieją po to, by można było polegać na agencie, że będzie je przestrzegał.
Przeglądanie. Traktuj zwrócony wynik jak prośbę o zmianę od kompetentnego, lecz młodszego inżyniera: szybkiego, sprawnego, ale skłonnego do subtelnych błędów, które zauważy tylko ktoś, kto rozumie cały system. Sprawdź dopasowanie architektoniczne oraz przypadki krawędziowe. Upewnij się, że spełniono specyfikację, co oznacza, że osiągnięto zamierzony cel, a nie tylko to, że testy przeszły.
Odpowiedzialność. Człowiek odpowiada o ostateczną jakość. Agent wykonał pracę, osoba ją zatwierdziła, a awaria w produkcji jest jej odpowiedzialnością. Ta odpowiedzialność odróżnia inżynierię opartą na agencie od kodowania „na chybił trafił”, gdzie nikt nie bierze odpowiedzialności za wynik.
Problem rzeczywiście istnieje. Agenci tworzą kod szybciej, niż ludzie są w stanie go przejrzeć, więc pojawia się pokusa złagodzenia wymogów, by nadążyć za tempem. To właśnie ta pokusa doprowadziła do powstania podejścia vibe coding: programiści akceptowali wyniki, ponieważ wyglądały one poprawnie, przechodziły testy, a zbliżał się termin. Inżynieria oparta na agentach ma na celu zapobieganie powtarzaniu się tego wzorca.
Raport Anthropic na temat trendów w kodowaniu z użyciem agentów opisuje, jak doświadczeni inżynierowie sobie z tym radzą. Przekazują zadania, których poprawność można łatwo sprawdzić jednym spojrzeniem lub które nie wiążą się z dużymi konsekwencjami. Im bardziej zadanie jest trudne pod względem koncepcyjnym lub zależy od specyfiki projektu, tym częściej decydują się je wykonać sami lub wspólnie z agentem. Umiejętność określenia, co przekazać, a co zachować, jest nową kluczową umiejętnością. Rozwija się poprzez praktykę, nie istnieją dla niej żadne skróty dzięki frameworkom czy narzędziom, i odróżnia inżyniera, który efektywnie wykorzystuje agenty, od tego, który tworzy imponujące wyniki, które jednak zawodzą podczas dokładnej analizy.
Lista kontrolna pomaga przed wdrożeniem czegokolwiek stworzonego przez agenta do produkcji. Jej nagłówek brzmi:
## Agent Output Review Checklist
a jego treść, podzielona na sekcje zaczynające się od sprawdzenia zgodności specyfikacji (czy wdrożone zostały wszystkie wymagane zachowania, czy przestrzegane są ograniczenia, czy spełnione zostały kryteria sukcesu), a następnie przechodzące do architektury i sensu biznesowego:
### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)
Warto to wydrukować i przymocować obok monitora. Narzędzia do analizy kodu oraz proces CI mogą częściowo zautomatyzować pierwsze trzy sekcje. Ostatnia, dotycząca rozsądku biznesowego, jest powodem, dla którego człowiek musi być zaangażowany w cały proces.
Przeglądanie kodu pozwala wykryć problemy przed wypuszczeniem produktu. Powolna degradacja jakości, subtelne regresje oraz wzrost kosztów, których nikt nie zauważa aż do przybycia rachunku, pojawiają się dopiero później i wymagają interwencji najwyższego szczebla.
Szczegół 5: rozwój obserwowalny
Nadzór systemu i rozwój obserwowalny brzmią podobnie, ale pełnią różne funkcje. Nadzór informuje o tym, że system działa, ma normalną opóźnioność reakcji, niewiele błędów oraz zielony panel sterowania. Rozwój obserwowalny pokazuje, co dokonał system: który agent obsłużył jakie zadanie, na podstawie której specyfikacji, przy użyciu jakich narzędzi, tworząc jaki kod, oraz czy wynik odpowiadał zamierzeniom.
Różnica staje się widoczna o 2 w nocy. Przy samym monitorowaniu można stwierdzić, że coś jest nie tak, ale przyczyna pozostaje nieznana, więc noc upływa na analizowaniu różnic i domyślaniu się problemu w poszczególnych modułach. W przypadku rozwoju opartego na obserwacjach ślad z procesu wdrożenia pokazuje, że agent numer 3 zmienił procedurę autoryzacji zgodnie ze specyfikacją, która ignorowała jednoczesne odnowienia tokenów. To oznacza dwanaście minut skupionej diagnostyki zamiast dwóch godzin spekulacji.
W praktyce chodzi o trzy nawyki:
- Każde zadanie agenta tworzy ustrukturyzowany ślad: otrzymaną specyfikację, użyte narzędzia, zmienione pliki, wersję modelu, zużyte tokeny oraz wynik weryfikacji. Gdy trzy dni później pojawi się błąd, ślad pokazuje, co się stało, więc nikt nie musi o tym pamiętać.
Minimalna konfiguracja zaczyna się od importów niezbędnych do tworzenia krótkiego zapisu śledzenia:
from dataclasses import dataclass, field
from datetime import datetime
a klasa danych typu trace zastosowana do każdego zadania delegowanego:
@dataclass
class AgentTrace:
"""Minimum trace for every agent-delegated task."""
task_id: str
agent_id: str
spec_given: str # What was the agent told to do?
tools_used: list[str] # Which tools did it invoke?
files_modified: list[str] # What did it change?
model_version: str # Which model, which version?
tokens_consumed: int # What did it cost?
started_at: datetime = field(default_factory=datetime.utcnow)
completed_at: datetime | None = None
verification_result: str = "" # pass / fail / needs_review
human_reviewer: str = "" # Who signed off?
issues_found: list[str] = field(default_factory=list)
Dodaj cotygodniową ocenę trwającą piętnaście minut. Jej nagłówek:
## Weekly Observable Development Review (15 minutes)
i związane z tym pytania: ile zadań zostało przekazanych, ile z nich przeszło weryfikację przy pierwszej próbie (cel powyżej 80%), która kategoria miała najwięcej problemów oraz jakie były trzy najważniejsze problemy:
1. How many agent tasks were delegated this week? ___
2. How many passed verification on first attempt? ___ (target: >80%)
3. Which task category had the most issues? ___
4. Top 3 issues found during review:
- ___
- ___
- ___
5. Which issues should become codified rules (Layer 3)? ___→ Update CLAUDE.md with any new rules from this week's observations.
Piętnaście minut tygodniowo wystarcza, by zamknąć ten cykl. Obserwacje stają się zasadami, zasady poprawiają organizację procesów, lepsza organizacja przynosi lepsze wyniki, a te z kolei dają nowe obserwacje.
Dowody skuteczności
Wyróżniają się dwa liczby. Ponad 1000 połączonych żądań pull request tygodniowo w Stripe jest tworzonych przez algorytmy, sprawdzanych przez ludzi, przechodzących testy CI i używanych w produkcji – to nie jest eksperyment w środowisku testowym. Taka wydajność nie była możliwa rok wcześniej. Inna grupa odbiorców podaje inne dane: badanie McKinsey wskazuje na redukcję kosztów operacyjnych o 20 do 40 procent, co sprawia, że sztuczna inteligencja przechodzi z kategorii inicjatyw innowacyjnych do infrastruktury operacyjnej – czego domaga się nie tylko dyrektor technologiczny, ale także finansowy.
Co to oznacza dla kariery inżynierskiej
Rola ta się zmienia, ale nie znika. Inżynierowie w 2026 roku piszą mniej kodu podstawowego i poświęcają więcej czasu na koordynację agentów, projektowanie architektury, określanie celów i zasad oraz weryfikację wyników. Kluczowa umiejętność przesuwa się od składni ku myśleniu systemowemu, od pytania o to, jak napisać funkcję, do pytania o to, jak zaprojektować system, w którym agenci będą ją poprawnie pisać.
Karpathy rozszerzył to na proces rekrutacji: pomijaj pytania typu zagadka i postaw znaczący projekt, na przykład stworzenie bezpiecznego klonu Twittera, a następnie sprawdź, jak kandydaci radzą sobie z narzędziami, specyfikacjami i nadzorem podczas prób jego złamania. To sprawdza dyscyplinę, a nie szybkość pisania.
W rozmowach z liderami ds. inżynierii wielokrotnie pojawiają się trzy kompetencje:
- Biegłość w tworzeniu specyfikacji. Napisanie specyfikacji na tyle precyzyjnej, aby agent mógł ją wykonać bez niejasności, jest trudniejsze niż pisanie kodu. Kod ma kompilator, który wykrywa błędy, natomiast specyfikacja polega wyłącznie na interpretacji agenta. Jeśli specyfikacja jest niejasna, agent wybierze pewną interpretację, będzie na niej budować i przedstawi wynik dokładnie takiego, jak został poproszony.
- Sądzenie w zakresie orkiestracji. Umiejętność decydowania, co delegować, a co zachować, kiedy pomocne są równoległe wykonywania, a kiedy połączenia są zbyt ścisłe, oraz kiedy wynik wymaga dokładnej analizy zamiast tylko sprawdzenia struktury. Rozwija się to poprzez setki decyzji o delegowaniu, z których każda pokazuje, co działa, a co powoduje problemy integracyjne.
Gergely Orosz dobrze to ujął: istnieje coś znacznie ważniejszego od programowania, co czyni inżynierów wyjątkowymi, i zasługuje na rozwijanie. To, co wyróżnia inżynierów w 2026 roku, to systemy, które projektują, specyfikacje, które piszą, ich umiejętność podejmowania decyzji dotyczących delegacji oraz standard jakości, których nie chcą obniżać. Te umiejętności są teraz cenniejsze właśnie dlatego, że mechaniczna realizacja zadań została zautomatyzowana.
Pięciodniowy plan rozpoczęcia pracy
Pięć ćwiczeń w ciągu tygodnia, z których każde buduje na poprzednim:
- Poniedziałek: kodowanie wiedzy zespołu. Napisz plik CLAUDE.md lub .cursorrules dla bieżącego projektu. Pomiń listę technologii i zapisz zasady pracy: jak radzić sobie z błędami, jak strukturyzować testy, jak nazywać elementy oraz niepisane zasady, których każdy nowy pracownik powinien się nauczyć już pierwszego dnia.
- Wtorek: określenie zadań i ich delegowanie. Wybierz jedną funkcjonalność z listy zadań do realizacji i napisz jej specyfikację na podstawie szablonu: co musi robić, czego nie może robić, kryteria sukcesu oraz sygnały niepowodzenia. Całkowicie przekaż tę pracę agentowi i wyznacz czas zarówno na określenie zadań, jak i na ich sprawdzenie. Ten stosunek pokazuje, gdzie faktycznie idą wysiłki.
Jeden tydzień nie uczyni z nikogo inżyniera agentów. Pokazuje jednak, jak wygląda ta dyscyplina i czy przechodzenie od pisania kodu do koordynowania agentów daje energię czy ją zużywa. Obie odpowiedzi są uzasadnione, ale pomocne jest wiedzenie, która jest prawdziwa.
Gdzie pogląd oparty wyłącznie na specyfikacji zawodzi
Traktowanie specyfikacji jako jedynego źródła odpowiedzi – poprzez jej pisanie, przestrzeganie i weryfikację według niej – jest konieczne, ale niewystarczające. Specyfikacja stanowi dane wejściowe dla systemu orkiestracji, a nie samodzielną praktykę. Doskonała specyfikacja przekazana jednemu agentowi zapewnia dobre wyniki. Ta sama specyfikacja, rozdzielona między pięć równoległych agentów, z których każdy jest związany skodyfikowanymi regułami, poddawana jest kontrolom w ramach ustrukturyzowanego nadzoru oraz śledzona podczas procesu rozwoju, przynosi mniej więcej dziesięciokrotnie większe rezultaty przy tej samej jakości.
Kwarter warstwy 4 również łatwo jest niedoceniać. Specyfikacja określa intencję, a człowiek decyduje, czy ta intencja została spełniona. Specyfikacja sama w sobie nie narzuca się, a etap jej weryfikacji wymaga takiej samej dyscypliny jak sam proces pisania. To właśnie weryfikacja, a nie model, framework czy narzędzia, jest tym elementem, w którym większość zespołów szuka oszczędności, gdy zbliżają się terminy.
Co następuje
Widoczne są dwa kierunki rozwoju: jeden prawie pewny, a drugi spekulatywny.
Pierwszy, prawie pewny, zakłada, że inżynieria oparta na agentach stanie się standardową metodą w profesjonalnym rozwoju oprogramowania w ciągu około 18 miesięcy – nie dlatego, że wszyscy o tym czytają, ale ze względu na nieodparte korzyści ekonomiczne. Trzech inżynierów stosujących tę metodę, przy silnych specyfikacjach, równoległej orkiestracji i zdyscyplinowanej kontroli, osiąga efekty równoznaczne z tymi, które uzyskują dwunastu pracowników stosujących tradycyjne podejście. Gdy rachunki są tak jasne, debata się kończy.
Kierunek spekulatywny to zastępy agentów: sieci agentów koordynujących się między sobą i zarządzających całymi procesami pracy lub funkcjami biznesowymi przy minimalnym udziale człowieka. Niektóre zespoły już przeprowadzają eksperymenty. Czy to rozwiązanie sprawdzi się w skali przedsiębiorstw z wymaganą niezawodnością, pozostaje nieznane, dlatego do zainteresowania należy podchodzić z ostrożnością i sceptycyzmem.
To, co nie jest spekulacją, to fakt, że rola inżyniera już się zmieniła. Kluczowym pytaniem jest to, czy kompetencje nowej roli – specyfikacja, orkiestracja i weryfikacja – są już rozwijane, czy też praca nadal odbywa się tak, jakby pisanie kodu było głównym zadaniem. Kiedyś pracą było wpisywanie kodu. Teraz pracą jest projektowanie systemu, który go tworzy, oraz potwierdzanie, że to, co zostało stworzone, jest poprawne.