Ścieżki kariery i oceny pracy, gdy output jest tani

Ścieżki kariery dla inżynierów pracujących z agentami kodującymi nagradzają efekty, specyfikację, weryfikację i wkład w harness zamiast ilości kodu. Liczba pull requestów, zmienionych linii i wydanych tokenów staje się celem w rozumieniu prawa Goodharta, gdy tylko trafi do formularza oceny, więc zostaje na dashboardach zespołu. Dowodem przy awansie jest teczka podlinkowanych artefaktów, za które inżynier odpowiadał.

Trwa tydzień kalibracji. Jedna osoba zmergowała w tym półroczu 212 pull requestów i prowadzi w rankingu użycia dostawcy. Druga zmergowała 19, ale napisała testy akceptacyjne i scenariusze holdout, dzięki którym zespół płatności przestał czytać każdy diff. Twoja ścieżka kariery wciąż mówi „dostarcza dużo kodu dobrej jakości”, a manager wkleił eksport rankingu do wniosku awansowego.

Ta strona jest dla CTO lub VP Engineering, który odpowiada za ścieżkę kariery, oraz dla tech leada albo managera, który pisze oceny. Dostajesz macierz kompetencji, metryki, które nie trafiają do ocen, teczkę dowodów, kartę telemetrii z ustawieniami, które ją egzekwują, i plan wdrożenia na jeden cykl. Profile ról na etapie rekrutacji opisuje strona rekrutacja i rozmowy kwalifikacyjne w inżynierii agentowej.

Dlaczego ścieżki kariery przestają działać, gdy kod piszą agenci?

Większość ścieżek kariery powstała, gdy output był drogi, więc „dostarcza dużo kodu wysokiej jakości” było rozsądnym przybliżeniem wpływu. Agenci usunęli koszt pierwszej połowy tego zdania, a drugą połowę zrobili trudniejszą do zobaczenia. Dane wskazują w tę samą stronę:

Output rośnie szybciej niż dostarczanie. Raport Faros AI AI Engineering Report 2026 (kwiecień 2026, telemetria 22 000 developerów) pokazuje wzrost liczby mergowanych pull requestów na developera o 16,2%, a przy tym wzrost mediany czasu w code review o 441,5%, incydentów na pull request o 242,7% i churnu kodu o 861%. Nagradzanie pierwszej liczby nagradza przyczynę pozostałych trzech.
Praca przesunęła się do code review. W badaniu Anthropic wśród własnych inżynierów (2025-12-02, deklaracje samego dostawcy: 132 ankiety i 53 wywiady) część osób opisuje przesunięcie pracy w „70%+ to being a code reviewer/reviser rather than a net-new code writer” („w ponad 70% w stronę recenzowania i poprawiania kodu zamiast pisania nowego”). Liczba commitów tej pracy nie widzi.
Udział AI opisuje branżę, a nie osobę. DX podaje średnio 51,9% kodu napisanego przez AI w ponad 400 firmach w II kwartale 2026 roku (Justin Reock, 2026-06-17, dane deklaratywne). Udział konkretnej osoby pokazuje nawyki narzędziowe, a nie osąd.
Samoocena przyspieszenia dzięki AI jest zawodna. W randomizowanym badaniu METR z 2025 roku (2025-07-10, narzędzia z początku 2025) doświadczeni developerzy open source pracowali z AI o 19% dłużej, a mimo to uważali, że AI przyspieszyło ich o 20%. „Z agentami dowiozłem dużo więcej” to hipoteza, a nie dowód.

Rozwiązaniem nie jest nowa metryka, tylko ścieżka kariery, która nazywa pracę odróżniającą dziś inżynierów, i ocena, która prosi o jej dowody. Niektóre stare sygnały trzeba zastąpić, a nie tylko usunąć: „pisze czysty kod” zamienia się w projektowanie kontroli, które utrzymują kod w czystości bez czytania go (funkcje dopasowania, bramki lintera i typów), a głębia widoczna w trudnym kodzie – w głębię widoczną w specyfikacjach, projekcie wyroczni i diagnozie incydentów. Ilość kodu, szybkość i liczbę code review obsługuje tabela Goodharta niżej.

Macierz kompetencji dla inżynierii agentowej

Użyj macierzy zamiast technicznych wierszy obecnej ścieżki kariery. „Inżynier” odpowiada poziomowi mid, „Senior” seniorowi, a „Staff i wyżej” poziomom staff, principal i ich odpowiednikom. Oczekiwania wobec poziomów wejściowych opisuje strona rozwój juniorów, gdy kod piszą agenci.

Wymiar	Inżynier	Senior	Staff i wyżej
Efekty	Dowozi zmiany o określonym zakresie, spełniające kryteria akceptacji, i wskazuje efekt, któremu każda służyła	Odpowiada za metrykę efektu funkcji lub serwisu (lead time, poziom błędów, adopcja) i ją przesuwa	Decyduje, do jakich efektów dąży grupa, i zatrzymuje pracę agentów, która ich nie przesuwa
Specyfikacja	Pisze kryteria akceptacji przed uruchomieniem agenta; agenci rzadko je źle odczytują	Pisze specyfikacje i krótkie ADR-y, które wdrażają agenci innych inżynierów; poprawki z winy specyfikacji są rzadkie i śledzone	Ustala standard specyfikacji i ADR-ów dla grupy i rozstrzyga niejasności między zespołami, zanim trafią do agenta
Weryfikacja	Każdą zmianę dowodzi testami i pakietem dowodów; potrafi wyjaśnić zmianę bez otwartego diffu	Projektuje wyrocznie (testy akceptacyjne, testy właściwości, scenariusze holdout) i podnosi siłę wyroczni dla modułu; wyłapuje defekty w code review przed merge’em	Decyduje, które pętle mogą przejść na code review oparte wyłącznie na dowodach, odpowiada za strategię weryfikacji i cofa zaufanie, gdy bramka coś przepuści
Harness i dźwignia	Zgłasza i naprawia tarcia w harnessie: niestabilną kontrolę, mylącą regułę, brakujące polecenie	Dostarcza skille, hooki, kontrole lub pliki kontekstu, które przyjmują inni inżynierowie i które mierzalnie zmniejszają liczbę poprawek	Buduje produkty harnessu używane przez wiele zespołów (ewaluacje, polityki, środowiska) i wycofuje to, co nie pomaga
Utrzymanie i odpowiedzialność	W razie potrzeby debuguje własne zmiany na produkcji bez agenta	Prowadzi incydenty dotyczące kodu napisanego przez agentów i pisze analizy, które zmieniają bramkę, a nie tylko linijkę	Odpowiada za niezawodność systemu i za poziom autonomii, na jakim pracują jego agenci
Ludzie i warsztat	Utrzymuje umiejętności bez asystenta (debugowanie, czytanie nieznanego kodu) i prosi o wspólne code review szkoleniowe	Prowadzi dla juniorów wspólne code review szkoleniowe i przeglądy specyfikacji; rekrutuje w procesie, w którym agent jest dozwolony	Rozwija seniorów, kształtuje proces rekrutacji i samą ścieżkę kariery

Macierz dzieli słownik z rubryką rozmów w rekrutacji do inżynierii agentowej, więc ludzie są zatrudniani i awansowani na podstawie tych samych dowodów.

Dwie zasady utrzymują macierz w uczciwości:

Odpowiedzialność nie przechodzi na agenta. Inżynier odpowiada za to, co dowieźli jego agenci, łącznie z częściami, których nikt nie przeczytał. Kto nie umie wyjaśnić ani wycofać zmiany swojego agenta, nie spełnia wiersza Weryfikacja na żadnym poziomie.
Dźwignia liczy się tylko wtedy, gdy korzystają z niej inni. Skill, hook albo kontrola daje punkty, gdy przyjmie je inny zespół i spadnie liczba poprawek, w które celują.

Jakie dowody liczą się w każdym wymiarze?

Każde twierdzenie w ocenie potrzebuje artefaktu, który komisja kalibracyjna może otworzyć; liczby z następnej sekcji nigdy się nie kwalifikują.

Wymiar	Dowody, które się liczą
Efekty	Metryka efektu zespołu przed i po, ze zmianami, które ją przesunęły
Specyfikacja	Specyfikacje, kryteria akceptacji i ADR-y oraz dopytania, których wymagały po przekazaniu
Weryfikacja	Dodane wyrocznie z wynikiem testów mutacyjnych lub scenariuszy holdout przed i po; defekty wyłapane przed merge’em; defekty, które uciekły, prześledzone do kontroli tego inżyniera
Harness i dźwignia	Artefakt, kto go przyjął i ile poprawek lub czasu code review usunął
Utrzymanie i odpowiedzialność	Poprowadzone analizy incydentów, wykonane wycofania zmian, bramki dodane po incydencie
Ludzie i warsztat	Postępy juniorów względem ich planu, notatki ze wspólnego code review szkoleniowego, jakość opinii z rozmów rekrutacyjnych

Które metryki stają się celami w rozumieniu prawa Goodharta?

Prawo Goodharta w sformułowaniu Marilyn Strathern: „When a measure becomes a target, it ceases to be a good measure” („gdy miara staje się celem, przestaje być dobrą miarą”; Marilyn Strathern, „Improving ratings: audit in the British University system”, European Review 5(3), 1997). Agenci skracają drogę od celu do obchodzenia metryki, bo podbicie liczby kosztuje teraz jeden prompt.

Metryka	Jak agenci ułatwiają jej podbicie	Do czego nadal się nadaje	W indywidualnej ocenie?
Zmergowane pull requesty, commity	Podział pracy na wiele małych pull requestów od agenta	Przepustowość zespołu, czytana obok change fail rate	Nigdy
Dodane lub zmienione linie, zaakceptowane linie	Więcej linii często znaczy gorzej	Sama w sobie do niczego	Nigdy
Tokeny, wydatki, koszt na osobę	Cel nagradza pętle zostawione na chodzie; limit karze kosztowną weryfikację	Koszt zespołu na zaakceptowaną zmianę; zarządzanie budżetem	Nigdy
„% kodu napisanego przez AI”, sesje, czas aktywności	Przepychanie każdego zadania przez agenta	Wykorzystanie i tarcia na poziomie zespołu	Nigdy
Pozycja w rankingu dostawcy	Łączy powyższe liczby	Znajdowanie osób, które mogą podzielić się przepływami pracy	Nigdy
Liczba testów, pokrycie linii	Testy, które niewiele sprawdzają albo odwzorowują implementację	Minimum w CI	Tylko jako podlinkowana wyrocznia z wynikiem testów mutacyjnych
Liczba code review, akceptacje	Akceptuj szybciej, czytaj mniej	Równoważenie obciążenia recenzentów	Nigdy; liczą się defekty wyłapane przed merge’em

Ranking dostawcy nie jest hipotetyczny. Panel analityczny Claude Code dla planów Team i Enterprise szereguje 10 użytkowników według pull requestów albo linii kodu i oferuje eksport CSV Export all users (dokumentacja analityki Claude Code, sprawdzona 2026-09-26). Anthropic przedstawia go jako sposób na znalezienie zaawansowanych użytkowników, którzy pomogą innym; używaj go dokładnie do tego, nigdy we wniosku awansowym.

Definicje zespołowe (odsetek zaakceptowanych zmian, koszt na zaakceptowaną zmianę, obciążenie code review) są na stronie DORA, SPACE, DX Core 4 i pomiar AI, która ma tę samą zasadę: żadnej metryki nie raportuje się per inżynier.

Co trafia do oceny zamiast liczb: teczka dowodów

Poproś każdego inżyniera o jedną teczkę dowodów na cykl ocen. To inny artefakt niż pakiet dowodów, który dowodzi pojedynczej zmiany w PR: teczka zbiera pracę jednej osoby z całego cyklu i zastępuje listę „co zbudowałem” z samooceny. Pisze ją inżynier, a manager sprawdza każdy link.

# Teczka dowodów: <imię i nazwisko>, <cykl, np. 2026-H2>

## Efekty (1–3)
- Efekt: <metryka śledzona przez zespół, np. p95 opóźnienia checkoutu>
  Przed → po: <wartości, daty, link do dashboardu źródłowego>
  Mój udział: <linki do specyfikacji / wyroczni / zmian>

## Specyfikacja
- <link do specyfikacji, kryteriów akceptacji lub ADR-u> — wdrożył(a): <kto lub która pętla agenta>
  Dopytania po przekazaniu: <liczba, linki>

## Weryfikacja
- Dodana lub wzmocniona wyrocznia: <link> — wynik testów mutacyjnych lub scenariuszy holdout przed → po
- Defekty wyłapane przed merge'em: <linki do komentarzy w PR>
- Defekty, które uciekły z kodu, który weryfikowałem: <linki do incydentów lub błędów, z tym, czego nie złapała bramka>

## Harness i dźwignia
- <link do skilla / hooka / kontroli / pliku kontekstu> — przyjęli: <zespoły lub osoby>
  Efekt: <poprawki, czas code review lub odsetek porażek przed → po, ze źródłem>

## Utrzymanie i odpowiedzialność
- Poprowadzone incydenty lub wycofania zmian: <linki>; bramka zmieniona potem: <link>

## Ludzie i warsztat
- Wspólne code review szkoleniowe lub przeglądy specyfikacji: <linki lub notatki>; kto się rozwinął i jak
- Praktyka bez asystenta w tym cyklu: <co i czego się nauczyłem>

## Co zrobiłbym inaczej
- <jedno lub dwa zdania, z linkiem, jeśli istnieje>

Teczka ma się zmieścić na dwóch stronach; na poziomie staff to głównie efekty, strategia weryfikacji i dźwignia.

Help me draft my evidence packet for the 2026-H2 review cycle. Use only read-only commands.

1. Run `git log --author="$(git config user.email)" --since=2026-07-01 --name-only` in this repository and group my changes by what they touched: product code, tests and fixtures, specs and ADRs (docs/, specs/, *.md with acceptance criteria), CI workflows, and agent harness files (CLAUDE.md, AGENTS.md, .claude/, .codex/, .cursor/, .agents/ — whichever exist).
2. If the GitHub CLI is available, run `gh pr list --author @me --state merged --search "merged:>=2026-07-01" --json number,title,url,body --limit 200` and find pull requests whose description links a spec, an incident, or an evidence bundle.
3. Draft the packet with these sections: Outcomes, Specification, Verification, Harness and leverage, Operation and ownership, People and craft, What I would do differently.
4. Every line must carry a link to a commit, PR, spec, dashboard or incident. Where you cannot find evidence for a section, write "No evidence found — ask me" instead of filling it.
5. Do not include counts of PRs, commits, lines or tokens anywhere in the packet. If a section only has counts, leave it for me to fill.

Show me the draft and the list of artifacts you could not classify.

Jak nie dopuścić, żeby telemetria stała się inwigilacją?

Telemetria agentów jest potrzebna do kontroli kosztów, tarć w harnessie i metryk zespołowych. Pocięta na osoby staje się systemem monitoringu, a inżynierowie, którzy podejrzewają, że zasila ich ocenę, przestają zgłaszać nieudane uruchomienia.

Jest też strona prawna. Model, który ocenia, szereguje albo przydziela pracę inżynierom na podstawie telemetrii agentów, to zastosowanie z pkt 4 lit. b załącznika III do AI Act (monitorowanie i ocena wydajności oraz zachowania pracowników), wysokiego ryzyka od 2 grudnia 2027 roku na mocy odroczenia z pakietu omnibus z 2026 roku (źródło wtórne; potwierdź w EUR-Lex); zob. AI Act dla firm tworzących oprogramowanie z agentami. Monitorowanie pracowników już dziś rodzi pytania na gruncie RODO, a w Niemczech rady zakładowe współdecydują o systemach technicznych nadających się do monitorowania wydajności pracowników (BetrVG §87 ust. 1 pkt 6). Omów to z prawnikiem; to nie jest porada prawna. Przyjmij i opublikuj poniższą kartę, zanim włączysz telemetrię.

# Karta telemetrii agentów — <firma>, obowiązuje od <data>

1. Cel. Zbieramy telemetrię agentów kodujących, aby zarządzać kosztami, znajdować
   tarcia w harnessie i mierzyć dostarczanie na poziomie zespołu. Nie zbieramy jej
   do oceniania osób.
2. Agregacja. Każdy dashboard i raport pokazuje zespoły liczące co najmniej pięć osób.
   Grupę mniejszą niż pięć osób łączymy z grupą nadrzędną.
3. Tożsamość. Identyfikatory osobowe (e-mail, identyfikatory kont, użytkownika i sesji)
   są usuwane w kolektorze przed zapisem, z wyjątkiem magazynu administracji licencji (pkt 5).
4. Treść. Nie zbieramy treści promptów, odpowiedzi asystenta, argumentów narzędzi
   ani wyników narzędzi.
5. Dostęp do danych indywidualnych. Inżynier widzi własne użycie. Administratorzy
   licencji widzą użycie per stanowisko wyłącznie w celu zarządzania licencjami
   i limitami wydatków.
6. Oceny. Żadna telemetria, ranking dostawcy ani eksport z panelu analitycznego
   nie trafia do oceny okresowej, teczki dowodów, wniosku awansowego, kalibracji
   ani planu naprawczego.
7. Bez automatycznego oceniania. Żaden model ani reguła nie ocenia, nie szereguje
   i nie przydziela pracy poszczególnym inżynierom na podstawie tych danych.
8. Retencja. Surowe zdarzenia przechowujemy 90 dni; agregaty zespołowe 24 miesiące.
9. Zmiany. Każdą zmianę karty ogłaszamy z 30-dniowym wyprzedzeniem i uzgadniamy
   z <przedstawicielami pracowników / radą zakładową, jeśli istnieje>.
10. Audyt. <Rola> co kwartał sprawdza punkty 2–7 i publikuje wynik wewnętrznie.

Liczby w karcie to wartości domyślne, a nie progi prawne; ustal je z prawnikiem.

Egzekwuj kartę w każdym narzędziu

Karta działa tylko wtedy, gdy konfiguracja jest z nią zgodna.

Co wysyła. Dla zalogowanego użytkownika Claude Code dołącza user.email, user.account_uuid, user.account_id i organization.id do każdej metryki i zdarzenia eksportowanego do twojego endpointu OpenTelemetry. Każde zdarzenie niesie też user.id i session.id; w sesji przez Claude apps gateway user.id to identyfikator podmiotu z IdP, a user.groups zawiera grupy tej osoby w IdP. Treść promptów, odpowiedzi asystenta, argumenty narzędzi, wyniki narzędzi i pełne treści żądań API są domyślnie wyłączone, a włączają je OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT i OTEL_LOG_RAW_API_BODIES (dokumentacja monitoringu Claude Code, sprawdzona 2026-09-26 dla v2.1.283). Pkt 4 karty wymaga, żeby wszystkie pięć pozostało nieustawione w ustawieniach zarządzanych. Nieustawione OTEL_LOG_ASSISTANT_RESPONSES dziedziczy wartość OTEL_LOG_USER_PROMPTS, więc zostaw obie nieustawione (albo jawnie ustaw obie na 0).

Konfiguruj centralnie. Claude Code ignoruje zmienne eksportera w pliku .claude/settings.json repozytorium, więc ustaw je w managed settings, z oznaczeniem zespołu i bez identyfikatorów kont w metrykach:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_RESOURCE_ATTRIBUTES": "team.id=payments,cost_center=eng-123",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_SESSION_ID": "false"
  }
}

Rozprowadź inny team.id dla każdego zespołu. user.email i user.id nadal są dołączane, a zdarzenia nadal niosą session.id, więc usuń je w kolektorze (niżej).

Panel analityczny. Ranking i eksport CSV Export all users widzi każdy Admin i Owner. Trzymaj listy tych ról krótkie, a eksport i raport wydatków per użytkownik z dala od narzędzi do ocen.

Co wysyła. W kodzie openai/codex z tagu rust-v0.157.1 (sprawdzone 2026-10-02 na CLI 0.157.1) eksportery logów i śladów są domyślnie wyłączone, a log_user_prompt ma wartość false, ale metrics_exporter domyślnie ma wartość statsig, czyli własny kanał metryk OpenAI (codex-rs/config/src/types.rs). Każda metryka niesie tagi sesji auth_mode, session_source, originator, service_name, model i app.version (codex-rs/otel/src/metrics/tags.rs), a poszczególne metryki dokładają własne: codex.turn.cost_microusd niesie conversation.id, czyli klucz konkretnej sesji, oraz turn.id, a codex.tool.call i codex.tool.call.duration_ms niosą nazwę narzędzia w tagu tool (codex-rs/otel/src/events/session_telemetry.rs). codex-rs/otel/src/metrics/config.rs wyłącza te metryki ze Statsig właśnie po to, żeby własne eksportery OTLP nadal je dostawały. Eksporter samych metryk wysyła więc do kolektora klucz sesji i klucz tury, a kolektor opisany niżej usuwa oba. Logi niosą jeszcze więcej. Każde zdarzenie niesie user.email, user.account_id i conversation.id (codex-rs/otel/src/events/shared.rs), a zdarzenie codex.tool_result zapisuje pełne arguments narzędzia i do [otel.tool_result] max_bytes jego wyniku, domyślnie 2048 bajtów (codex-rs/otel/src/tool_result.rs). Żadna flaga nie wyłącza tego zdarzenia, a max_bytes nie skraca argumentów, więc eksporter logów Codex łamie pkt 4 karty. Wysyłaj wyłącznie metryki:

[otel]
environment = "prod"
log_user_prompt = false
# No `exporter` (logs) and no `trace_exporter`: Codex log events carry tool
# arguments, tool output and user.email. Metrics still carry conversation.id
# and turn.id; the collector deletes both.
metrics_exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/metrics", protocol = "binary" } }

Oznacz zespół. Zasób (resource) metryk Codex ustawia tylko service.name, service.version, env, os i os_version (codex-rs/otel/src/metrics/client.rs), a config.toml nie ma klucza, który dodałby do metryk atrybut zasobu. Codex buduje ten zasób przez Resource::builder() z opentelemetry_sdk 0.31, który czyta też OTEL_RESOURCE_ATTRIBUTES: w teście z 2026-10-02 CLI 0.157.1 uruchomione z OTEL_RESOURCE_ATTRIBUTES=team.id=payments wysłało team.id=payments w zasobie każdej paczki metryk. Ustaw tę zmienną osobno dla każdego zespołu w środowisku powłoki lub uruchamiania, którym steruje zarządzanie urządzeniami, bo config.toml jej nie przeniesie. Sesja uruchomiona bez niej przychodzi bez team.id: przypisz ją do zespołu w procesie pseudonimizacji albo ją odrzuć.

Gałąź main dodaje log_agent_responses i log_guardian_assessments (oba domyślnie wyłączone); CLI 0.157.1 je ignoruje. Mimo to przepuść pierwszą sesję Codex przez kontrolę kolektora opisaną niżej: późniejsza wersja może dodać tagi. Plik ograniczeń administracyjnych requirements.toml nie ma klucza dla tabeli [otel] (config_requirements.rs, sprawdzone 2026-09-26), więc rozprowadzaj config.toml przez zarządzanie urządzeniami i opieraj się na tej kontroli; zob. jedna polityka dla wszystkich agentów kodujących.

Niezależnie od narzędzi usuwaj tożsamość w OpenTelemetry Collectorze, zanim dane trafią do magazynu. Procesor attributes usuwa klucze z metryk, logów i śladów. Jest częścią dystrybucji contrib OpenTelemetry Collectora, a nie podstawowej kompilacji otelcol, więc uruchamiaj tę konfigurację w otelcol-contrib albo w dystrybucji, która zawiera ten procesor. Nie rusza też atrybutów zasobu: jeśli narzędzie umieszcza tożsamość w bloku resource, dodaj procesor resource z tymi samymi akcjami delete. To kompletna konfiguracja kolektora; zamień endpoint otlphttp na swój magazyn:

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}

processors:
  attributes/drop-identity:
    actions:
      - key: user.email
        action: delete
      - key: user.account_uuid
        action: delete
      - key: user.account_id
        action: delete
      - key: user.id
        action: delete
      - key: user.groups
        action: delete
      - key: session.id
        action: delete
      - key: conversation.id
        action: delete
      - key: turn.id
        action: delete
  batch: {}

exporters:
  otlphttp:
    endpoint: https://storage.example.com
  debug: {}

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [attributes/drop-identity, batch]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [attributes/drop-identity, batch]
      exporters: [otlphttp]

Usuwaj user.id, choć nie zawiera e-maila: jest stały dla instalacji, a w sesji przez gateway to identyfikator podmiotu z IdP, więc działa jak pseudonim konkretnej osoby i pozwala odtworzyć ranking. conversation.id z Codex to taki sam klucz sesji, a jego turn.id jest jeszcze drobniejszy (jedna wartość na turę w sesji jednej osoby), więc znikają oba: pkt 3 karty usuwa identyfikatory sesji, a identyfikator tury to identyfikator sesji z licznikiem. Jeśli potrzebujesz liczby sesji per zespół, użyj dla session.id akcji hash zamiast delete.

Żeby to sprawdzić, dopisz debug do listy exporters w obu potokach, przepuść jedną sesję i potwierdź, że nie przetrwał żaden atrybut user.*, session.id, conversation.id, turn.id ani atrybut konta, a team.id tak. Powtarzaj kontrolę po każdej aktualizacji agenta: nowe wersje dodają atrybuty.

Wdróż nową ścieżkę kariery w jednym cyklu ocen

Najpierw usuń złą zachętę, potem daj ludziom nowy format dowodów, a na końcu kalibruj według niego.

Ogłoś, co przestaje obowiązywać od teraz. Zanim otworzysz kolejny cykl, zapisz, że liczby pull requestów, linii, tokenów, udział AI i pozycje w rankingach nie pojawią się w żadnej ocenie, teczce ani na kalibracji.
Opublikuj i wyegzekwuj kartę telemetrii. Uzgodnij ją z przedstawicielami pracowników, jeśli ich masz, i wdróż zmiany w kolektorze i managed settings.
Przepisz techniczne wiersze ścieżki kariery. Zastąp je macierzą dopasowaną do twoich poziomów; prompt audytu ścieżki poniżej wskazuje każde sformułowanie oparte na ilości.
Przetestuj teczkę dowodów na dwóch zespołach: jednym, który intensywnie korzysta z agentów, i jednym, który korzysta mało. To, czego inżynierom trudno było udowodnić, pokazuje, gdzie proces ukrywa pracę.
Kalibruj według checklisty poniżej. Przewodniczący kalibracji czyta teczki przed spotkaniem i przerywa każdą dyskusję, która wraca do liczb.
Zrób audyt cyklu. Przeprowadź kontrole z następnej sekcji, opublikuj zagregowane wyniki i popraw każdy wymiar, który nie dał dowodów.

Checklista kalibracji

Przewodniczący odczytuje tę listę na początku każdego spotkania kalibracyjnego.

Każda ocena powołuje się na co najmniej jeden podlinkowany artefakt dla każdego omawianego wymiaru.
Nikt nie przytacza liczby pull requestów, commitów, linii, tokenów, sesji ani pozycji w rankingu.
Przy każdej ocenie „powyżej oczekiwań” komisja nazywa efekt i wskazuje, kto jeszcze na nim skorzystał.
Praca nad code review i weryfikacją jest omawiana u każdego seniora i każdej osoby na poziomie staff.
Defekty, które uciekły na produkcję, omawia się najpierw jako porażki bramek: „która kontrola powinna była to złapać?”.
Wkład w harness powołuje się na przyjęcie przez kogoś innego.
Osoby korzystające z agentów mało i intensywnie są oceniane w tych samych wymiarach i na podstawie tych samych dowodów.

Attached is our engineering career ladder (all levels, all rows). Audit it for agentic engineering.

1. Quote every phrase that rewards volume or speed of producing code (for example "delivers a high volume", "writes a lot of", "fast implementation", "number of PRs"). For each, explain in one sentence how an engineer could satisfy it with a coding agent without improving outcomes or quality.
2. Map each existing row to one of these dimensions: Outcomes, Specification, Verification, Harness and leverage, Operation and ownership, People and craft. List rows that map to none, and dimensions that no row covers.
3. For each level, propose replacement wording for the rows you flagged. Each proposed criterion must name an artifact a calibration committee can open (spec, oracle with mutation score, incident review, adopted skill or check, outcome metric) and must not use a count of PRs, commits, lines, tokens or sessions.
4. Keep accountability explicit: every level must state that the engineer owns and can explain changes their agents made.

Output a table: current wording | problem | dimension | proposed wording. Then list the three changes with the biggest effect on who gets promoted.

Here is a draft performance review I wrote for one engineer: [paste the review].

Check it against our rules:
1. Flag every sentence that uses a count of pull requests, commits, lines, tokens, sessions, AI share or a leaderboard position as evidence. Suggest what artifact should replace it.
2. Flag every claim with no link to an artifact (spec, PR, oracle, dashboard, incident review, adopted skill or check).
3. Check that verification and review work is discussed, not only feature delivery.
4. Flag wording that attributes agent-written work to the engineer without saying how they verified it, and wording that penalizes low agent usage by itself.
5. Flag anything that looks like it came from per-person telemetry or a vendor analytics export.

Do not rewrite the review. Return a list of findings with the quoted sentence and the fix.

Skąd wiesz, że nowa ścieżka kariery nagradza właściwą pracę?

Wynik ścieżki kariery to to, kto awansuje. Sprawdzaj go w każdym cyklu, zamiast ufać samym sformułowaniom.

Kontrola	Jak	Zdrowy wynik	Właściciel
Pokrycie dowodami	Weź próbę 10 teczek i policz twierdzenia bez działającego linku	Mniej niż jedno twierdzenie bez linku na teczkę	Przewodniczący kalibracji
Czy ilość nadal jest nagradzana	Zespół people analytics koreluje oceny z liczbą zmergowanych pull requestów na danych spseudonimizowanych i raportuje wyłącznie współczynnik	Słaba albo żadna korelacja; silna dodatnia oznacza, że tak	Szef people analytics
Równowaga wymiarów	Policz, na które wymiary powoływał się każdy wniosek awansowy	Weryfikacja i harness pojawiają się w awansach na seniora i staff, nie tylko efekty	VP Engineering
Efekty zespołów	Change fail rate, czas w code review i odsetek zaakceptowanych zmian z panelu metryk	Stabilne albo lepsze	Tech leadzi
Zaufanie	Anonimowe pytanie w ankiecie: „Mogę zgłosić nieudane uruchomienie agenta albo wycofaną zmianę bez szkody dla mojej oceny” (skala pięciostopniowa)	Większość odpowiedzi 4 lub 5, bez spadku	Engineering managerowie
Zgodność z kartą	Kontrola kolektora pod kątem atrybutów tożsamości; przegląd dostępów do paneli	Brak identyfikatorów osobowych poza administracją licencji	Zespół platformowy lub bezpieczeństwa

VP Engineering zatwierdza ścieżkę kariery i audyt cyklu; HR business partner i przedstawicielstwo pracowników, jeśli istnieje, współpodpisują kartę.

Co idzie nie tak, gdy przepisujesz ścieżkę kariery pod agentów?

Ranking i tak trafia na kalibrację. Manager przynosi eksport od dostawcy „dla kontekstu”. Naprawa: przewodniczący przerywa dyskusję, eksport znika z teczki, a pkt 6 karty trafia do zaproszenia na kolejną kalibrację.

Pozorna praca nad harnessem zastępuje ilość kodu. Pojawiają się skille, których nikt nie instaluje; zaliczaj harness tylko z adopcją i zmierzonym efektem.

Liczba testów staje się nową liczbą linii. Naprawa: przyjmuj wyłącznie siłę wyroczni (wynik testów mutacyjnych, odsetek zaliczonych scenariuszy holdout) albo wyłapane defekty i chroń wyrocznię przed edycjami agenta.

Seniorzy robiący code review dostają niższe oceny za „mały output”. Naprawa: wpisz do teczki defekty wyłapane przed merge’em i pokaż obciążenie recenzentów według strony kolejka code review, gdy pull requesty otwierają agenci.

Inżynierowie wyłączają telemetrię albo ją omijają. Naprawa: opublikuj kartę, konfigurację kolektora i wynik audytu. Jedno naruszenie karty ją przekreśla.

Specyfikacje robią się dłuższe, a nie lepsze. Oceniaj je po tym, co stało się po przekazaniu, nigdy po długości.

Juniorzy nie mają jak pokazać dowodów na swoim poziomie. Naprawa: daj poziomom wejściowym mniejszą teczkę, zbudowaną wokół ich planu rozwoju ze strony rozwój juniorów.

Oceny zaczyna pisać model. Manager prosi asystenta o ranking zespołu na podstawie telemetrii. Naprawa: zakaż tego w polityce korzystania z AI; to automatyczna ocena pracowników, którą AI Act klasyfikuje jako wysokie ryzyko. Prompt sprawdzający szkic oceny powyżej tylko ją sprawdza; nigdy nie wystawia punktów.

Dokąd dalej ze ścieżkami kariery

Następnie zmień proces rekrutacji, żeby nowe osoby były wybierane według tych samych wymiarów, według których będą awansować.

Rekrutacja i rozmowy kwalifikacyjne w inżynierii agentowej Zadania próbne z dozwolonym agentem, które sprawdzają pisanie specyfikacji, projektowanie weryfikacji i ocenę w code review.

Twój warsztat i kariera, gdy kod piszą agenci Strona inżyniera w tej samej sprawie: umiejętności, które procentują, te, które zanikają, i plan portfolio.

Frameworki metryk dla kodu pisanego przez agentów Definicje zespołowe, które ta strona trzyma z dala od indywidualnych ocen.

Podnoszenie kompetencji zespołu w inżynierii agentowej Program nauki na każdy poziom, który daje dowody wymagane przez macierz.

Najczęstsze pytania

Czy liczba pull requestów albo zużycie tokenów powinny trafiać do ocen okresowych inżynierów?

Nie. Gdy kod piszą agenci, obie liczby da się podbić bez dowiezienia czegokolwiek: więcej mniejszych pull requestów od agenta albo pętle agenta zostawione na chodzie. Trzymaj je na poziomie zespołu, obok metryki stabilności, a osoby oceniaj na podstawie podlinkowanych dowodów efektów, specyfikacji, weryfikacji i pracy nad harnessem.

Co powinna nagradzać ścieżka kariery, gdy większość kodu piszą agenci?

Efekty, za które inżynier odpowiadał, specyfikacje, które agenci innych osób wdrażają bez błędnego odczytania, weryfikację, dzięki której pętla działa na dowodach zamiast czytania linijka po linijce, wkład w harness przyjęty przez innych inżynierów oraz odpowiedzialność za incydenty i wycofania zmian.

Jak korzystać z telemetrii agentów, żeby nie stała się inwigilacją?

Zanim cokolwiek zbierzesz, spisz kartę telemetrii: tylko agregaty zespołowe, minimalny rozmiar grupy, wyłączona treść promptów, dane indywidualne widoczne tylko dla samego inżyniera i administracji licencji oraz pisemna zasada, że żadna telemetria nie trafia do oceny, awansu ani planu naprawczego.