Podnoszenie kompetencji zespołu w inżynierii agentowej

Podnoszenie kompetencji zespołu w inżynierii agentowej to program powiązany z poziomem drabiny autonomii, na którym działa każda pętla, katy zbudowane z własnego repozytorium i oceniane przez testy, sesje review do nauki (review-to-learn) co dwa tygodnie na prawdziwych pull requestach agentów oraz datowany rejestr kompetencji dla każdej osoby. Ten sam rejestr jest dowodem dla obowiązku z art. 4 AI Act.

Wiosną kupiłeś osiem licencji, wrzuciłeś trzy linki na kanał zespołu i zorganizowałeś jedno spotkanie przy lunchu. Teraz dwie osoby puszczają agentów na wiele godzin według specyfikacji, trzy używają ich jak szybszego autouzupełniania, a jedna w ogóle ich nie dotyka. Kolejka review jest pełna pull requestów od agentów, które umieją zweryfikować tylko dwie osoby. A potem w kwestionariuszu bezpieczeństwa klienta pojawia się pytanie, jak spełniasz obowiązek AI literacy z AI Act, i nikt nie potrafi powiedzieć, kto i z czego został przeszkolony. Ta strona jest dla tech leada, który musi rozwiązać pierwszy problem, i dla CTO, który musi odpowiedzieć na drugie pytanie.

Co daje tak zbudowany program rozwoju kompetencji

Tabelę programu: czego ludzie uczą się przy każdym przejściu na drabinie, która kata to potwierdza i kto podpisuje zaliczenie.
90-minutowy moduł bazowy, który każdy posiadacz licencji przechodzi, zanim użyje agentów na kodzie produkcyjnym.
Manifest kat i dwa prompty, które zamieniają historię repozytorium w katy.
Sesję review do nauki dla całego zespołu co dwa tygodnie, z regułą określającą, co musi z niej wyjść.
Rejestr kompetencji w YAML, który obsługuje program i art. 4, z promptem audytowym.
Cztery miary, które pokazują, czy program działa, i typowe sposoby, w jakie się psuje.

Co mówią dowody o uczeniu ludzi pracy z agentami?

Bezpośrednich dowodów na temat programów szkoleniowych do pracy z agentami jest niewiele, więc ta strona opiera się na dwóch ustaleniach, resztę oznacza jako projekt, a sam program mierzy swój efekt w twoim zespole.

To, jak ludzie delegują, decyduje o tym, czego się uczą. W randomizowanym badaniu opublikowanym przez Anthropic 29 stycznia 2026 52 inżynierów, w większości juniorów, uczyło się nowej biblioteki Pythona. Grupa korzystająca z asystenta AI uzyskała w teście kontrolnym średnio 50%, a grupa pisząca kod ręcznie 67%. Uczestnicy, którzy zadawali pytania o koncepcje albo generowali kod, a potem prosili o wyjaśnienia, mieli średnio 65% lub więcej. Próba była mała, test mierzył krótkoterminowe zrozumienie, a wydawcą jest dostawca modelu. Mimo to ćwiczenia trzeba zaprojektować tak, żeby ludzie zachowali zrozumienie, a nie tylko dowozili wynik.

System zespołu decyduje o tym, co agent wzmacnia. Raport DORA 2025 (Google Cloud, 23 września 2025) ujmuje to tak: „AI doesn’t fix a team; it amplifies what’s already there”. Jego AI Capabilities Model wymienia „clear and communicated AI stance” jako pierwszą z siedmiu zdolności. Dla rozwoju kompetencji oznacza to, że uczysz ludzi bramek i reguł zespołu, a nie tylko funkcji narzędzia.

Zbuduj program wokół przejść na drabinie

Drabina autonomii biegnie od poziomu 0 (ręcznie) do poziomu 5 (fabryka, której kodu nie czyta żaden człowiek). Poziom należy do pętli, a nie do osoby: jeden inżynier może prowadzić aktualizacje zależności na poziomie 4, a pracę nad funkcjami na poziomie 2. Dlatego program uczy przejścia, które główna pętla danej osoby robi jako następne, a nie stanowiska. Jedna mapa: drabina, cykl życia i stacje pokazuje, gdzie jest każda pętla.

Przejście	Czego osoba się uczy	Kata, która to potwierdza	Dowód zaliczenia (podpisuje tech lead)
Baza (każdy z licencją)	Uprawnienia i sandbox w swoim narzędziu, prompt injection, sekrety, zmyślone zależności, klasy ryzyka zespołu, czego dowodzi każda bramka CI	Brak; test z pięciu pytań po module	Wpis w rejestrze z datą i zaliczonym testem
L1 → L2: wspomaganie → praca w parze	Delegowanie całego zadania z kryteriami akceptacji; czytanie planu agenta przed edycjami; zatrzymanie i przekierowanie przebiegu	Kata delegowania: dokończ zadanie przez agenta tak, by przeszły ukryte testy, bez edycji plików testowych	Dwie zaliczone katy delegowania; wyjaśnienie jednej zmiany bez otwartego diffa
L2 → L3: praca w parze → review diffów	Review pull requesta agenta względem kryteriów; klasy ryzyka, w których człowiek czyta kod; wspólne reguły w `CLAUDE.md` lub `AGENTS.md`	Kata review: znajdź celowo wprowadzony błąd w zmianie agenta i nazwij test, który by go wyłapał	Trzy zaliczone katy review; jedno prawdziwe znalezisko zamienione w automatyczny test
L3 → L4: review → pisanie specyfikacji	Pisanie wykonywalnych kryteriów akceptacji; siła wyroczni; warunki stopu; czytanie pakietu dowodów zamiast diffa	Kata specyfikacji: napisz kryteria dla dawnego zadania tak, by pierwszy przebieg agenta przeszedł oryginalny, ukryty zestaw testów	Dwie katy specyfikacji zaliczone za pierwszym przebiegiem; jedno prawdziwe zadanie wdrożone z twojej specyfikacji razem z pakietem dowodów
L4 → L5: specyfikacje → prowadzenie pętli	Funkcje przystosowania (fitness functions), bramki, których agent nie może edytować, pisemne uzasadnienie pętli działającej bez nadzoru	Kata harnessu: dodaj bramkę, która wyłapuje klasę błędów zasianą w zestawie kat	Scalona bramka, która wyłapała lub wyłapałaby prawdziwy błąd; uzasadnienie jednej pętli bez nadzoru zrecenzowane przez CTO

Dwie reguły utrzymują tę tabelę w ryzach. Po pierwsze, nikt nie pomija bazy, niezależnie od stażu. W bazie są treści o bezpieczeństwie, a staż nie chroni przed prompt injection. Po drugie, przejście zalicza się na podstawie dowodów z kat i prawdziwej pracy, a nie obecności. Poziom 5 nie jest domyślnym celem; mocny poziom 4 to pełny program dla większości inżynierów.

Przeprowadź moduł bazowy, zanim ktokolwiek użyje agentów na kodzie produkcyjnym

Baza trwa 90 minut, prowadzi ją tech lead albo senior, raz dla każdego nowego posiadacza licencji i ponownie, gdy zespół wprowadza nowego agenta. Najpierw omawia, co może pójść nie tak, a dopiero potem, co narzędzie potrafi.

Uprawnienia i sandbox (20 minut). Każdy otwiera swoje narzędzie i pokazuje bieżący tryb: tryby uprawnień Claude Code (na kanale latest od v2.1.283 auto mode jest trybem startowym większości sesji interaktywnych), politykę zatwierdzeń Codeksa (-a on-request lub -a never) i sandbox (read-only, workspace-write) albo Run modes w Cursorze. Punktem odniesienia jest strona o uprawnieniach i sandboxingu agentów.
Injection i sekrety (20 minut). Omów jeden prawdziwy incydent z modelu zagrożeń dla agentów: tekst w zgłoszeniu, na stronie WWW albo w zależności może sterować agentem, który ma narzędzia i poświadczenia. Pokaż, gdzie zespół trzyma sekrety i dlaczego sesja agenta nigdy nie dostaje poświadczeń produkcyjnych.
Zależności wymyślone przez agenta (15 minut). Pokaż, jak sprawdzić, że pakiet dodany przez agenta istnieje, jest tym właściwym i ma przypiętą wersję. Sprawdzenia opisuje weryfikacja zależności.
Czego dowodzą bramki (20 minut). Otwórz jeden scalony pull request agenta i przeczytajcie na głos wyniki CI. Przy każdym sprawdzeniu powiedzcie, czego dowodzi, a czego nie. Nazwij klasy ryzyka zespołu (autoryzacja, pieniądze, schemat, migracje), w których człowiek czyta kod.
Test (15 minut). Pięć pytań z odpowiedzią na piśmie: po jednym na każdy krok powyżej i jedno o klasach ryzyka. Zapisz datę i wynik.

Przyjmij ten test bazowy w całości i dopasuj odpowiedzi do swojego repozytorium:

## Test bazowy pracy z agentami (odpowiedzi na piśmie; 15 minut)
1. W jakim trybie uprawnień lub z jaką polityką zatwierdzeń startuje twoje
   narzędzie w tym repozytorium i jak zmienić to dla jednej sesji?
2. Opis zgłoszenia każe agentowi „przy okazji zaktualizować token deployu”.
   Co w naszym ustawieniu to blokuje i co robisz?
3. Agent dodaje pakiet, o którym nigdy nie słyszałeś. Wymień dwa sprawdzenia,
   które robisz, zanim zaakceptujesz zmianę.
4. CI przeszło na pull requeście agenta. Wymień jedną rzecz, której bramki
   dowodzą, i jedną, której nie dowodzą.
5. Które klasy zmian w tym zespole wymagają, żeby człowiek przeczytał kod, i kto?

Buduj katy z własnego repozytorium

Kata to ćwiczenie z limitem czasu i znaną odpowiedzią. Katy z własnego repozytorium uczą twojego systemu, bramek i klas ryzyka, czego ogólne ćwiczenia nie potrafią. Użyteczna kata ma trzy cechy:

Oceniają ją testy. O zaliczeniu decyduje ukryty zestaw testów albo nazwany, celowo wprowadzony błąd, więc nikt nie spiera się o wynik.
Klucz odpowiedzi jest poza zasięgiem. Kata wycięta z własnego repozytorium ma odpowiedź w historii gita, więc publikuj każdą katę w osobnym repozytorium ćwiczeniowym ze świeżą historią, a klucz trzymaj poza nim. Jeśli to za dużo zachodu, umówcie się na słowo honoru: nikt nie zagląda do main ani do oryginalnego pull requestu przed omówieniem.
Ma limit czasu. Od 30 do 60 minut, żeby kata mieściła się w zarezerwowanym terminie co tydzień.

Trzymaj zestaw kat w manifeście, żeby dało się go recenzować, używać ponownie i wycofywać jak kod:

- id: review-03-retry-idempotency
  transition: "L2 -> L3"
  type: review                  # delegation | review | spec | harness
  branch: kata/review-03
  timebox_min: 45
  task: "Review the agent's change to the payment retry worker."
  pass: "Names the missing idempotency check and the test that would catch it."
  answer_key: "private: senior's notes, kept outside the practice repository"
  owner: "a.nowak"
  created: 2026-09-26
  retire_when: "the retry worker is rewritten or the seeded defect class gets a gate"

Senior buduje każdą katę razem z agentem, a potem sprawdza wynik sam, zanim ktokolwiek ją zrobi. Dwa prompty poniżej obejmują rodzaje kat, których budowa zajmuje najwięcej czasu.

Build a code-review kata from this repository. Do not show your reasoning in
any file, branch name or commit message.
1. Pick a merged change from the last six months in src/payments/ or
   src/auth/ that has tests and touches error handling or state.
2. Create a branch named kata/review-<short-name> from the commit before that
   change. Re-apply the change, but introduce exactly one realistic defect of
   one of these classes: missing idempotency, wrong error propagation,
   off-by-one in a boundary, or a race on shared state. Keep all existing
   tests passing.
3. Write a pull request description as an agent would: the ticket, the
   acceptance criteria, and a confident summary that does not mention the
   defect.
4. Reply to me only, not in the repository, with: the branch name, the
   defect, the file and line, and the smallest test that would catch it.

Build a specification kata from this repository.
1. Find a merged pull request from the last six months that added a feature
   with at least five new test cases, outside src/auth/ and src/payments/.
2. Create a branch named kata/spec-<short-name> from the commit before that
   pull request. Do not include the implementation or the new tests.
3. Write a one-paragraph ticket in a product manager's voice describing the
   user-visible behaviour, with no hints about edge cases the tests cover.
4. Do not copy or move the original new test files. Tell me their paths and
   the SHA of the merge commit, so I can copy them out myself. They are the
   hidden grader.
5. Reply with the branch name, the ticket, and a list of the behaviours the
   hidden tests check, so I can confirm the kata is fair.

Gałąź katy wciąż ma w historii oryginalną zmianę, więc senior kopiuje ją do świeżego repozytorium ćwiczeniowego: drzewo sprzed zmiany na main, a katę na jej gałęzi:

# Uruchom w katalogu głównym roboczego repozytorium. ../kata-review-03 staje się repozytorium ćwiczeniowym.
base=$(git merge-base main kata/review-03)
git init -b main ../kata-review-03
git archive "$base" | tar -x -C ../kata-review-03
git -C ../kata-review-03 add -A && git -C ../kata-review-03 commit -m "Base"
git -C ../kata-review-03 switch -c kata/review-03
git -C ../kata-review-03 rm -rq . && git archive kata/review-03 | tar -x -C ../kata-review-03
git -C ../kata-review-03 add -A && git -C ../kata-review-03 commit -m "Kata change"

Przy kacie specyfikacji skopiuj wskazane pliki testów (git show <sha>:<ścieżka>) do katalogu z kluczem poza oboma repozytoriami i uruchom je na wyniku inżyniera. Zamień src/payments/ i src/auth/ w promptach na własne katalogi.

Jak przeprowadzić katę w każdym narzędziu?

Kata i jej ocena są takie same w każdym narzędziu: gałąź, limit czasu i ukryte testy. Różni się to, jak osoba izoluje sesję i jak porównuje swoją pracę z agentem do review.

Uruchom katę w osobnym worktree, żeby nie dotknęła innej pracy: claude -w kata-review-03 tworzy nowy worktree gita dla sesji. Przy kacie specyfikacji wejdź w tryb planowania poleceniem /plan, żeby agent napisał plan przed jakąkolwiek edycją, i porównaj plan z kryteriami. Przy kacie w module, którego osoba się uczy, uruchom /output-style learning (polecenie wymaga v2.1.269 lub nowszej). Agent wyjaśnia wtedy swoje wybory, a przy prawdziwej decyzji projektowej zostawia znacznik TODO(human) do uzupełnienia przez osobę. Wybór zapisuje się w .claude/settings.local.json, więc zostaje prywatny i nie zmienia sesji reszty zespołu. Po kacie review uruchom /code-review na tej samej gałęzi i porównaj znaleziska z własnymi.

Uruchom katę poleceniem codex --worktree, które prowadzi sesję w nowym, zarządzanym worktree gita. Przy katach specyfikacji użyj /plan. Nie znaleźliśmy wbudowanego trybu nauki w codex --help ani w codex features list (Codex CLI 0.157.1, sprawdzone 26 września 2026), więc przy kacie do nauki osoba wkleja na początku sesji kontrakt nauki. Po kacie review uruchom z gałęzi katy codex review --base main i porównaj znaleziska z własnymi.

Kontrakt nauki do wklejenia w Codeksie i Cursorze znajdziesz na stronie Twój warsztat i kariera, gdy kod piszą agenci, a prompt do kat debugowania dla juniorów na stronie o rozwoju juniorów.

Prowadź sesje review do nauki dla całego zespołu

Katy uczą na znanych odpowiedziach, a sesje review do nauki uczą na prawdziwej pracy zespołu. Prowadź je co dwa tygodnie przez 45 minut z całym zespołem, rotując prowadzącego.

Prowadzący wybiera jeden scalony pull request agenta z ostatnich dwóch tygodni, który dotknął obsługi błędów, stanu albo przypadku granicznego. Unikaj zmian nazw i aktualizacji zależności.
Przewidywanie (5 minut). Tylko na podstawie zgłoszenia i kryteriów akceptacji każdy zapisuje dwie linijki: czego zmiana musi dotknąć i co może pójść nie tak.
Review (15 minut). Każdy przegląda diff i pakiet dowodów i zapisuje znaleziska, klasyfikując je jako logikę, bezpieczeństwo, wydajność, projekt lub lukę w testach.
Porównanie z agentem do review (10 minut). Pokaż, co na tej samej zmianie znalazł /code-review, codex review albo Bugbot. Wypisz, co znaleźli ludzie, a czego nie znalazł agent, i odwrotnie.
Decyzja o jednym trwałym artefakcie (15 minut). Sesja kończy się jedną zmianą: nowym testem lub bramką, regułą w CLAUDE.md albo AGENTS.md, nową katą albo jawnym „nic”. Wskaż właściciela i datę.

Krok 5 to reguła, która nie pozwala sesji zamienić się w demo. Sesja, która kończy się bez artefaktu i bez jawnego „nic”, się nie odbyła. Strona Dzielenie się wiedzą: wersjonuj dowody, nie triki opisuje, gdzie żyje każdy artefakt i jak się go wycofuje.

In last week's review session we found this defect in an agent pull request,
which CI did not catch:
<paste the finding, the file and the pull request link>
1. Propose the smallest automated check that would have failed on that pull
   request: a unit test, a property test, a lint rule or a fitness function.
   Say which one and why it is the smallest.
2. Write the check on a new branch and show me it failing on the defective
   commit and passing on the fix.
3. Draft a katas.yaml entry for a review kata that seeds the same defect
   class in a different module, with transition "L2 -> L3".
Do not change any existing test to make the new check pass.

Prowadź rejestr kompetencji, który służy też art. 4

AI Act dotyczy firmy, która tylko używa agentów kodujących, głównie przez art. 4 o kompetencjach w zakresie AI. W brzmieniu z 2024 roku art. 4 wymaga od dostawców i podmiotów stosujących działań zapewniających wystarczający poziom kompetencji w zakresie AI personelu korzystającego z systemów AI, z uwzględnieniem doświadczenia, szkoleń i kontekstu użycia. Pakiet Digital Omnibus (rozporządzenie (UE) 2026/1744, w mocy od 27 lipca 2026) złagodził ten obowiązek, ale go nie usunął, według wtórnych omówień kancelarii Gibson Dunn i serwisu aiactblog.nl (2026). Zanim zacytujesz zmienione brzmienie, przeczytaj je w EUR-Lex i potwierdź swoje stanowisko z prawnikiem. Role i harmonogram opisuje strona AI Act dla firm tworzących oprogramowanie z agentami.

Program szkoleń już wytwarza to, czego wymaga art. 4: działania dopasowane do roli i systemów każdej osoby. Ten format rozszerza rejestr ze strony o AI Act o przejście na drabinie i katy, więc jeden plik obsługuje i tech leada, i dział compliance:

- person: "j.kowalski"
  role: developer
  systems: [claude-code, codex]
  autonomy: "local, reversible changes; no production credentials"
  ladder:
    main_loop: "feature work, billing service"
    current_level: L3
    working_towards: L4
  measures:
    - name: "Agent baseline: permissions, injection, secrets, dependencies, gates"
      date: 2026-09-12
      material: "https://wiki.example.com/agents/baseline"
      check: passed
    - name: "Review kata review-03-retry-idempotency"
      date: 2026-09-19
      result: passed
    - name: "Review-to-learn session: billing retry pull request"
      date: 2026-09-24
      material: "https://wiki.example.com/agents/review-to-learn/2026-09-24"
  exits_signed:
    - transition: "L2 -> L3"
      date: 2026-09-24
      evidence: "https://git.example.com/org/billing/pull/412"
      signed_by: "tech-lead-billing"
  next_review: 2027-09-12
  owner: "head-of-engineering"

Zapisuj wyniki kat jako zaliczone lub niezaliczone z datą, a nie jako czasy czy punkty. Rejestr dowodzi, że działania istnieją; to nie jest teczka do oceny pracownika (zobacz sposoby, w jakie program się psuje, niżej).

Compare two files and report gaps. Do not edit either file.
- docs/compliance/ai-literacy-record.yaml: one entry per person.
- seats.csv: an export of everyone with an active Claude Code, Codex or
  Cursor seat, or approval rights on agent pull requests (columns: person,
  tool, role).
Report, as a Markdown table:
1. People in seats.csv with no record entry.
2. People whose most recent measure is older than 12 months.
3. People whose systems list lacks a tool they now have a seat for.
4. People with approval rights on agent pull requests and no signed
   "L2 -> L3" exit.
End with literacy coverage: the share of people in seats.csv with a record
entry that has a measure dated within the last 12 months.

Uruchamiaj audyt co kwartał i za każdym razem, gdy zespół dodaje narzędzie, podnosi poziom autonomii albo zmienia rodzinę modeli. Te same zdarzenia są sygnałem, by powtórzyć moduł bazowy; wyłapuje je strona Jak utrzymać zespół na bieżąco.

Jak sprawdzić, że program działa?

Obecność niczego nie dowodzi. Dowodzą tego cztery miary, a pierwszą czyta dział compliance.

Miara	Definicja	Cel i właściciel
Pokrycie rejestrem kompetencji	Odsetek osób z licencją na agenta albo prawem zatwierdzania pull requestów agentów, których wpis ma działanie z datą z ostatnich 12 miesięcy	100%, raportuje co kwartał szef inżynierii (head of engineering). Luka to problem z dostępem: nie ma wpisu, nie ma licencji
Podpisane przejścia na kwartał	Przejścia na drabinie zaliczone na podstawie dowodów z kat i prawdziwej pracy	Jedno na inżyniera na kwartał to mocne tempo; zero przez dwa kwartały to temat na rozmowę, a nie porażka
Zaliczenia kat za pierwszym podejściem	Odsetek kat zaliczonych za pierwszym razem, dla każdego przejścia, dla całego zespołu	Rośnie w ciągu kwartału; kata, której nikt nie zalicza, jest zepsuta
Znaleziska zamienione w testy	Znaleziska z sesji review do nauki, które mają teraz automatyczne sprawdzenie	Co najmniej jedno na sesję w dwóch sesjach na trzy

Zestawiaj je z miarami dostarczania całego zespołu, a nie jednostek: wskaźnikiem nieudanych zmian (change failure rate) i poprawkami pull requestów agentów, liczonymi od punktu wyjścia ustalonego według strony o frameworkach metryk dla zespołów pracujących z agentami. Jeśli pokrycie rejestrem wynosi 100%, a zmiany agentów psują się na produkcji równie często jak wcześniej, program uczy nie tego, co trzeba: porównaj klasy kat z błędami, które przeciekają.

Jak to odpowiada na pytanie o rozwój kompetencji w scorecardzie tech leada?

Pytanie 18 w scorecardzie tech leada brzmi: jak podnosisz umiejętności AI zespołu. „Wysyłam linki” daje jeden punkt z trzech, a „okazjonalne sesje” dwa. Najwyżej oceniana odpowiedź, „ustrukturyzowana ścieżka + praktyka + review”, odpowiada tej stronie jeden do jednego: tabela programu to ścieżka, katy to praktyka, a sesje review do nauki to review.

Kwartał dla ośmioosobowego zespołu wygląda w kalendarzu tak:

Tygodnie	Co się dzieje	Czas na inżyniera
1–2	Moduł bazowy dla każdego bez wpisu w rejestrze; tech lead umieszcza główną pętlę każdej osoby na drabinie	90 minut jednorazowo
3–12	Jedna kata tygodniowo w zarezerwowanym terminie, dobrana do następnego przejścia danej osoby	30–60 minut tygodniowo
3–12, co drugi tydzień	Sesja review do nauki dla całego zespołu	45 minut co dwa tygodnie
12	Audyt rejestru, podpisanie przejść, przycięcie zestawu kat	30 minut tech leada na inżyniera

Te czasy to założenia tego programu, a nie zmierzony benchmark. Do tego dochodzi czas seniorów na budowę mniej więcej jednej nowej katy tygodniowo.

Co idzie nie tak w programie rozwoju kompetencji

Wyniki kat zamieniają się w ranking. Gdy czasy kat pojawiają się obok nazwisk, ludzie wybierają łatwe katy i przestają przyznawać się do tego, czego nie wiedzą. Użycie systemu AI do oceny pracowników może też przenieść cię do kategorii wysokiego ryzyka związanej z zatrudnieniem w AI Act (załącznik III, od 2 grudnia 2027 po przesunięciu przez Digital Omnibus, według wtórnych omówień; harmonogram opisuje strona o AI Act). Jak to naprawić: zapisuj wyniki kat tylko jako zaliczone lub niezaliczone, trzymaj je poza ocenami okresowymi, a do oceny pracy używaj ścieżek kariery i ocen pracy na czas, gdy output jest tani.

Program uczy funkcji, a nie weryfikacji. Sesje pokazują nowe polecenia, a jakość review się nie zmienia. Jak to naprawić: sprawdź, czy każde przejście w tabeli ma katę ocenianą przez testy, i usuń każdą sesję, z której jedynym wynikiem jest „zobaczyliśmy funkcję”.

Seniorzy pomijają moduł bazowy. Najbardziej doświadczeni inżynierowie się wypisują, a potem zatwierdzają zmiany agentów w trybie uprawnień, którego nigdy nie obejrzeli. Jak to naprawić: uczyń moduł bazowy warunkiem prawa do zatwierdzania pull requestów agentów i poproś seniora, żeby poprowadził następny. Rozmowę opisuje strona o sceptykach i seniorach.

Zestaw kat się starzeje. Katy osadzone w kodzie, którego już nie ma, uczą starego systemu. Jak to naprawić: daj każdej kacie właściciela i warunek retire_when i przycinaj zestaw w 12. tygodniu każdego kwartału.

Rejestr wypełnia się raz, pod audyt. Wpisy pojawiają się w tygodniu przed kwestionariuszem klienta i potem się nie zmieniają. Jak to naprawić: generuj wpisy z dziennika kat i notatek z sesji i uruchamiaj prompt audytowy co kwartał, żeby luki wychodziły, zanim zrobi to kwestionariusz.

Chroniona praktyka znika jako pierwsza. Czas na katy znika w sprincie pod termin i już nie wraca. Jak to naprawić: wpisuj katy do planu sprintu jako zadania z właścicielem i raportuj pominięte terminy na retrospektywie.

Dokąd dalej w temacie rozwoju kompetencji

Jak utrzymać zespół na bieżąco, gdy narzędzia zmieniają się co tydzień Śledzenie wydań, które mówi, kiedy powtórzyć moduł bazowy.

Rozwój juniorów, gdy kod piszą agenci Wersja sesji review do nauki dla juniorów i plan na 90 dni.

AI Act dla firm tworzących oprogramowanie z agentami Role, harmonogram po pakiecie Omnibus i rejestr systemów AI.

Twój warsztat i kariera, gdy kod piszą agenci Indywidualny plan umiejętności, który każdy inżynier prowadzi obok programu.

Jak pomóc zespołowi przestać czytać każdy diff Transfer zaufania, do którego przygotowuje przejście z L3 na L4.

Ścieżka tech leada Ścieżka czytania, do której należy ta strona.

Najczęstsze pytania

Jak podnieść kompetencje zespołu w inżynierii agentowej?

Powiąż program z poziomem drabiny autonomii pętli, w której dana osoba pracuje, ćwicz na katach zbudowanych z własnego repozytorium i ocenianych przez testy, co dwa tygodnie prowadź sesje review do nauki na prawdziwych pull requestach agentów i prowadź datowany rejestr, kto co ukończył. Wysyłanie linków to nie rozwój.

Czym jest kata w inżynierii agentowej?

Ćwiczenie z limitem czasu na gałęzi własnego repozytorium, ze znaną odpowiedzią: znajdź celowo wprowadzony błąd w zmianie agenta, napisz kryteria akceptacji, które oceni ukryty zestaw testów, albo dodaj bramkę wyłapującą całą klasę błędów. O wyniku decydują testy, nie osoba, która prowadzi katę.

Czy rejestr szkoleń pomaga w spełnieniu AI Act?

Tak. Artykuł 4 wymaga od podmiotów stosujących systemy AI działań na rzecz kompetencji w zakresie AI personelu, który z nich korzysta. Pakiet Digital Omnibus złagodził ten obowiązek, ale go nie usunął. Datowany wpis dla każdej osoby, z materiałem i zaliczonymi katami, jest dowodem, że takie działania istnieją. To nie jest porada prawna; potwierdź to z prawnikiem.

Czym rozwój kompetencji różni się od bycia na bieżąco?

Rozwój kompetencji buduje trwałe umiejętności na każdym poziomie drabiny: delegowanie, review, specyfikację i projektowanie harnessu. Bycie na bieżąco to cotygodniowe śledzenie wydań narzędzi i zmian modeli. Wydanie, które zmienia autonomię albo model, jest sygnałem, by powtórzyć część programu.