Scorecard dewelopera: klucz odpowiedzi

Klucz odpowiedzi do scorecardu dewelopera przypisuje każde z 25 pytań scorecardu dewelopera do strony, która poprawia tę odpowiedź, i nazywa dowód w repozytorium, jakiego wymaga odpowiedź za 3 punkty. Jest napisany dla dewelopera, który ma już wynik i chce wiedzieć, które trzy luki zamknąć najpierw i jak udowodnić każdą poprawkę.

Twój wynik to Poziom 2 · W parze, 31 punktów na 75. Codziennie pracujesz z Claude Code albo Codexem, a mimo to etapy 4 i 6 są blisko zera, a 25 linków na stronie wyników nie mówi, od czego zacząć. Ten klucz wybiera trzy pierwsze pytania, kieruje każde na jego stronę kanoniczną i mówi, jaki plik, job albo przebieg uprawnia do wyższej odpowiedzi.

Jak liczy się wynik scorecardu dewelopera

25 pytań, od 0 do 3 punktów każde, razem 75 punktów, około 8 minut. Pytanie 10 jest wielokrotnego wyboru: punkt za każdy serwer MCP, którego używasz w typowym tygodniu, maksymalnie 3. Sześć sekcji odpowiada sześciu etapom cyklu życia i ma kolejno 12, 9, 18, 12, 12 i 12 punktów. Strona wyników wypisuje każdą odpowiedź poniżej 3 punktów w karcie Popraw te odpowiedzi.

Co oznacza każdy z przedziałów poziomów 1–4 dla dewelopera?

Przedziały zapożyczają nazwy z drabiny autonomii, ale mierzą coś węższego: harness wokół twojej własnej pracy, tak jak go deklarujesz. Drabina opisuje, jak pętla naprawdę dostarcza zmergowane zmiany. Porównaj swój przedział ze stroną odpowiedniego poziomu drabiny i odpowiadaj za repozytorium, w którym pracujesz najczęściej, a nie za najlepszy projekt poboczny.

Przedział	Punkty	Co opisuje	Pierwszy ruch
Poziom 1 · Z asystą	0–18	AI to szybsza wyszukiwarka: wklejane snippety, agent, który nigdy nie widzi repozytorium.	Etap 1: wybierz jeden agentowy harness, scommituj plik instrukcji i daj mu jedno polecenie weryfikacji. Zobacz poziomy 1–2.
Poziom 2 · W parze	19–37	Jeden agent, jedno zadanie, a ty patrzysz na każdy krok. Są pliki instrukcji i kilka serwerów MCP.	Etap 4: niech sesja udowodni swoją pracę, zanim na nią spojrzysz.
Poziom 3 · Menedżer code review	38–56	Agenci piszą, ty przeglądasz diffy. Działają zautomatyzowane PR-y i rozszerzenia.	Etapy 2 i 5: przenieś swój osąd do specyfikacji i do kontraktu review. Zobacz poziom 3.
Poziom 4 · Menedżer specyfikacji	57–75	Piszesz spec i testy, potem sprawdzasz, co przeszło.	Zamknij pętlę etapu 6 i naucz tego setupu swój zespół. Scorecard nie ma przedziału dla poziomu 5; prowadzenie fabryki oprogramowania to decyzja dla konkretnej pętli.

Jak wybrać trzy pierwsze pytania do poprawy?

1. Podziel punkty każdej sekcji przez jej maksimum. 7 na 18 w etapie 3 (39%) to większa luka niż 5 na 9 w etapie 2 (56%), choć etap 3 ma więcej punktów.
2. Weź dwie sekcje z najniższym odsetkiem. W każdej wybierz pytanie, w którym twoja odpowiedź jest najdalej od 3 punktów.
3. Jeśli etap 4 jest poniżej połowy i nie jest już jedną z tych dwóch sekcji, dodaj jego najsłabsze pytanie. W przeciwnym razie weź najsłabsze pytanie z trzeciej od końca sekcji. Worktree (pytanie 13) i pętle PR (pytanie 19) mnożą pracę, którą trzeba sprawdzić; bez pętli informacji zwrotnej z etapu 4 ta praca spada na ciebie jako diffy do czytania.
4. Dla każdego pytania zapisz w pliku planu poniżej docelową odpowiedź i artefakt, który ją potwierdzi.
5. Wypełnij scorecard ponownie po 30 dniach i porównuj odsetki sekcji, nie przedział. Jedno pytanie, które skacze z 1 na 3 punkty, rzadko zmienia przedział, ale widać je w sekcji.

Scommituj plan obok kodu, który opisuje, żeby agent mógł go przeczytać, a zespół przejrzeć:

# docs/scorecard-plan.yaml — one entry per question you are working on
- question: 14         # How does the agent verify its own work before human review?
  current_points: 1
  target_points: 3
  target_answer: "Quantifiable targets, an automated fix loop, and a verifier subagent in fresh context"
  evidence: "scripts/verify.sh named in AGENTS.md; three merged PRs whose description links a green verify run"
  check_on: 2026-10-26

Która strona odpowiada na każde pytanie scorecardu dewelopera?

Każda tabela podaje pytanie, stronę do przeczytania najpierw i drugą, oraz dowód, jakiego wymaga odpowiedź za 3 punkty. Pytania 4, 5, 8, 10, 14, 15 i 23 linkują bezpośrednio stronę tematu, bo ich strony z omówieniem pytania są do niej włączane.

Etap 1 — Plan: intencja i fundamenty (pytania 1–4, 12 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
1	Jak twój główny setup AI obsługuje pracę w repozytorium?	Wybór głównego harnessu · Mapa narzędzi	Wersjonowane instrukcje, bramki planu i artefaktów, ograniczone uprawnienia narzędzi i powtarzalne polecenie weryfikacji, wszystko w repozytorium
2	Który plan najlepiej pasuje do twojego rzeczywistego obciążenia?	Dobór planu AI · Ceny planów i rozliczanie	Kwartalny przegląd na reprezentatywnych zadaniach: współbieżność, przerwy i koszt ukończonego zadania
3	Jak dobierasz model i środowisko wykonawcze do każdego zadania?	Routing modeli na dowodach · Hub modeli	Wersjonowane ewaluacje dla każdej klasy zadań, zapisujące jakość, opóźnienie, błędy i koszt ukończonej pracy
4	Jak utrwalasz problem, zanim powstanie kod lub plan (intent.md)?	Plan: zapisz intent.md · Łańcuch artefaktów	Scommitowany szablon intent.md, a intent.md każdej funkcji przejrzany przez właściciela produktu przed startem designu

Etap 2 — Design: specyfikacja i polityki (pytania 5–7, 9 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
5	Jak przekształcasz intencję w specyfikację (spec.md)?	Design: napisz spec.md · Spec-driven development	spec.md powstały w jednej sesji pod kontrolą skilli polityk, z każdą zgłoszoną wątpliwością rozwiązaną przed buildem
6	Jak kodyfikujesz i egzekwujesz polityki (brand, bezpieczeństwo, compliance, UX)?	Skille agenta jako polityka · Własne skille	Wersjonowane katalogi skilli w repozytorium, każdy z imiennym właścicielem i fixture’ami testowymi
7	Jak prototypujesz i walidujesz UI przed pisaniem kodu?	Akceptacja wizualna · MCP dla narzędzi projektowych	Makieta z zatwierdzonego narzędzia projektowego, którą da się obejrzeć, iterowana i zaakceptowana przed generowaniem kodu

Etap 3 — Build: plany, reguły i paralelizm (pytania 8–13, 18 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
8	Jak często zaczynasz w trybie planu i commitujesz plan.md?	Build: plan.md, potem implementacja · Łańcuch artefaktów	plan.md scommitowany przed implementacją przy każdej nietrywialnej zmianie i aktualizowany, gdy praca od niego odchodzi
9	Jak skonfigurowana jest wiedza o kodzie (CLAUDE.md, AGENTS.md, reguły)?	AGENTS.md i CLAUDE.md · Przycinanie plików instrukcji	Krótki plik główny plus reguły per ścieżka oraz ślad, że błąd powtórzony dwa razy stał się regułą
10	Których serwerów MCP używasz w typowym tygodniu?	Startowy zestaw MCP · Bezpieczeństwo MCP	Trzy serwery używane co tydzień, każdy powiązany z powtarzalnym zadaniem i ograniczony do minimalnych uprawnień
11	Jak używasz subagentów z ograniczonymi narzędziami?	Subagenci o wąskim zakresie · Harness	Definicje verifiera, simplifiera i explorera z jawnymi ograniczeniami narzędzi i własnym kontekstem
12	Jak używasz hooków jako deterministycznych zabezpieczeń (guardrails)?	Hooki jako zabezpieczenia (guardrails) · Hooki Claude Code	Hooki, które blokują chronione ścieżki i wycieki sekretów oraz uruchamiają formatowanie i kontrolę polityk, każdy z testem
13	Jak uruchamiasz równoległe sesje bez kolizji plików?	Równolegli agenci w worktree · Narzędzia do pracy równoległej	Skrypt obsługujący 2–4 worktree z jawną rewizją bazową, portami, stanem lokalnym, weryfikacją i sprzątaniem

Etap 4 — Test: pętle weryfikacji i ciągłe ewaluacje (pytania 14–17, 12 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
14	Jak agent weryfikuje własną pracę, zanim pokaże ją człowiekowi?	Test: daj sesji pętlę informacji zwrotnej · Jak silna jest twoja wyrocznia?	Jedno polecenie weryfikacji z mierzalnymi celami, uruchamiane w pętli, plus subagent weryfikujący w świeżym kontekście
15	Jak naprawiasz błędy z agentami?	TDD z pomocą AI · Ochrona wyroczni	Czerwony test scommitowany przed poprawką i hook, który blokuje edycję plików testów w trakcie naprawy
16	Jak weryfikujesz interfejs i zachowanie end-to-end w przeglądarce?	Weryfikacja w przeglądarce przez agenta · Automatyzacja testów E2E	Przebieg w przeglądarce według kryteriów akceptacji z zachowanymi artefaktami, a krytyczne ścieżki przeniesione do testów w CI
17	Jak testujesz regresyjnie konfigurację agentów?	Ciągłe ewaluacje · Ewaluacje agentów kodujących	Job ewaluacji w CI uruchamiany przy każdym PR zmieniającym instrukcje, skille lub hooki, z incydentami produkcyjnymi dodawanymi jako przypadki

Etap 5 — Deploy: pętle review i bramki produkcji (pytania 18–21, 12 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
18	Jak recenzowane są pull requesty przed merge’em (REVIEW.md)?	Warstwowe review PR · Review PR od agenta	REVIEW.md z osobnymi przejściami na błędy, bezpieczeństwo i zgodność ze specyfikacją, uwagami ocenionymi według wagi i akceptacją człowieka
19	Jak rozwiązywane są uwagi z review i nieudane checki CI?	Ograniczona pętla review i poprawek · Pakiet dowodów	Pętla z limitem prób, która naprawia potwierdzone przyczyny, ponawia wymagane checki i zatrzymuje się przed imienną akceptacją
20	Co powstrzymuje agenta przed wdrożeniem niesprawdzonych zmian na produkcję?	Bramka akceptacji produkcji · Uprawnienia i sandboksy	Brak poświadczeń produkcyjnych w środowisku agenta, zablokowany bezpośredni push i jawna zgoda człowieka na wydanie
21	Jak zarządzasz rollbackiem po regresji?	Przećwiczony rollback · Progressive delivery	Job rollbacku uruchamiany jednym poleceniem, z datowanym zapisem ćwiczenia i deterministycznym sprawdzeniem odzyskania

Etap 6 — Maintain: zamknięcie pętli i reakcja na incydenty (pytania 22–25, 12 punktów)

#	Pytanie	Czytaj	Dowód na 3 punkty
22	Jak monitorujesz produkcję i wykrywasz anomalie wymagające działania?	Wykrywanie anomalii i diagnoza · Monitoring i obserwowalność	Wersjonowane progi, diagnoza w trybie tylko do odczytu, zachowane dowody i routing według poziomu akceptacji
23	Co się dzieje, gdy na produkcji odpala się alert?	Maintain: zamknij pętlę · Taksonomia awarii	Alert uruchamia agenta w trybie headless, który składa intent.md z dowodami do kolejki triage’u
24	Jak skanujesz kod pod kątem głębokich podatności i dryfu architektury?	Planowane skany bezpieczeństwa · Skanowanie bezpieczeństwa	Planowane przebiegi skanera i agenta, które zachowują dowody, kierują poprawki przez bramki PR i dodają ewaluacje regresyjne
25	Jak AI uczestniczy w reakcji na incydenty i dyżurach on-call?	Triage incydentów z ograniczonym agentem · Reakcja na incydenty	Agent o wąskim zakresie zbiera dowody i szkicuje oś czasu; imiennie wskazany człowiek zatwierdza działania, odzyskanie i post-mortem

Jak udowodnić wyższą odpowiedź bez czytania każdego diffa?

Każda odpowiedź za 3 punkty powyżej nazywa artefakt, a nie nawyk: scommitowany plik, job w CI, hook z testem, zachowany przebieg w przeglądarce, zapis ćwiczenia. Deklaruj wyższą odpowiedź tylko wtedy, gdy możesz podlinkować ten artefakt. Przy pytaniach o build i testy najmocniejszym dowodem jest check, który pada, gdy kod jest błędny. Czytanie dowodów zamiast kodu wyjaśnia, dlaczego to zastępuje review linijka po linijce, a kolega z zespołu albo tech lead potwierdza link, zanim ponownie wypełnisz scorecard.

Dowody może zebrać za ciebie agent. Uruchom go w trybie, który każde narzędzie przewiduje do pracy tylko do odczytu, z repozytorium, które oceniasz, zamiast ufać, że sam prompt utrzyma go w tym trybie.

Claude Code

Uruchom sesję w trybie planu, który eksploruje bez edycji plików: claude --permission-mode plan (sprawdzone w claude --help, v2.1.285). Wklej prompt poniżej.

Codex

Uruchom prompt nieinteraktywnie w sandboksie tylko do odczytu: codex exec --sandbox read-only - < scorecard-evidence.txt (sprawdzone w codex exec --help, v0.157.1). Prompt ma kilka linii i zawiera cudzysłowy, więc zapisz go najpierw do pliku scorecard-evidence.txt: wklejony w cudzysłowie jako argument zepsułby polecenie powłoki. Myślnik - każe Codexowi czytać instrukcje ze stdin.

Cursor

Przełącz agenta w Plan Mode, który tworzy plan przed napisaniem jakiegokolwiek kodu, i wklej prompt poniżej.

Treść promptu jest taka sama we wszystkich trzech narzędziach.

Prompt do skopiowania: zbierz dowody dla etapów 3 i 4

Read-only task. Do not edit files, run commands that write, or call any network API.
I am answering Developer Scorecard questions 8, 9, 11, 12, 13, 14 and 15 for this repository.
For each question, list the evidence that exists today:
- plan.md or spec.md files, and whether commits add them before the implementation
- AGENTS.md, CLAUDE.md and path-scoped rule files, with their line counts
- subagent definitions and the tools each one is allowed to use
- hook configuration, what each hook blocks, and any test for it
- worktree or parallel-session scripts
- the single command that verifies a change, and where the instructions name it
- bug-fix commits whose failing test landed before the fix
Cite each item as path:line or commit hash. Then state, per question, which answer on a 0-3 scale
the evidence supports and what is missing for 3. Write "not found" instead of guessing.

Polecenie weryfikacji, które nigdy nie pada, niczego nie dowodzi. Zanim zadeklarujesz 3 punkty w pytaniu 14 lub 15, sprawdź wyrocznię w jednorazowym worktree. W terminalu uruchom git worktree add ../scorecard-probe HEAD, uruchom agenta w ../scorecard-probe ze zwykłymi uprawnieniami do edycji i wklej drugi prompt. Świeży worktree nie ma nieśledzonych plików, takich jak node_modules czy .env, więc prompt najpierw instaluje zależności poleceniem instalacji z repozytorium; bez tego krok 1 może paść z powodów niezwiązanych z wyrocznią. Po wszystkim usuń worktree poleceniem git worktree remove --force ../scorecard-probe.

Prompt do skopiowania: sprawdź, czy polecenie weryfikacji łapie prawdziwy błąd

This is a disposable git worktree. Nothing here will be committed.
1. Find the command AGENTS.md or CLAUDE.md names for verifying a change. Install dependencies with the
   repository's install command, then run it and confirm it passes.
2. Pick one function that has tests. Introduce a single realistic bug: an off-by-one, an inverted
   condition, or a dropped error branch. Do not touch any test file.
3. Run the same verify command again. Report whether it failed, which test caught the bug,
   and the exact failure message.
4. Repeat with two more bugs in different modules.
Finish with a table: bug, file:line, caught (yes/no), catching test. For every bug that was not
caught, name the missing test. Do not fix the tests.

Każdy niezłapany błąd to luka w wyroczni, a jej naprawa należy do strony jak silna jest twoja wyrocznia?, a nie do twojego wyniku.

Kiedy wynik scorecardu dewelopera wprowadza w błąd?

• Oceniłeś nawyki, nie artefakty. „Zwykle najpierw planuję” dostaje tę samą odpowiedź co scommitowany plan.md, jeśli na to pozwolisz. Wyjście: obniż o punkt każdą odpowiedź, której nie potwierdzasz linkiem do pliku, joba albo przebiegu. Ten niższy wynik to twój prawdziwy punkt startu.
• Twój setup żyje na twoim laptopie. Skille, hooki i serwery MCP w katalogu domowym pomagają tobie, ale świeży klon repozytorium nie dostaje żadnego z nich. Wyjście: odpowiadaj za to, co dostaje klon kolegi z zespołu, i przenieś do repozytorium to, na czym polegasz.
• Pytanie 10 zmieniło się w liczenie serwerów. Trzy podłączone serwery MCP, których rzadko używasz, nadal dają 3 punkty, a każdy ładuje definicje swoich narzędzi do kontekstu. Wyjście: licz tylko serwery wywołane w tym tygodniu przy powtarzalnym zadaniu, a resztę usuń, tak jak pokazuje ograniczanie kosztu tokenów MCP.
• Paralelizm z etapu 3 wzrósł przed etapem 4. Cztery worktree bez pętli informacji zwrotnej to cztery razy więcej diffów do czytania. Wyjście: ogranicz się do jednej sesji naraz, dopóki pytania 14 i 15 nie osiągną 3 punktów.
• Przedział stał się celem. Skok z poziomu 2 na poziom 3 w jeden miesiąc zwykle oznacza, że odpowiedzi ruszyły szybciej niż artefakty. Wyjście: sprawdź każdą zmienioną odpowiedź z jej dowodem, zanim komukolwiek powiesz o nowym przedziale.

Dokąd dalej z wynikiem scorecardu dewelopera

Wypełnij scorecard dewelopera 25 pytań, około 8 minut, bez zakładania konta: przedział poziomu 1–4 od razu, a pełny plan 30/60/90 po podaniu e-maila.

Ścieżka dewelopera Uporządkowana ścieżka lektury: od agenta w parze do specyfikacji i dowodów.

Cykl życia AI-native Sześć etapów, za którymi idą sekcje scorecardu, i artefakt, który każdy etap przekazuje dalej.

Scorecard CTO: klucz odpowiedzi Standaryzujesz ten sam harness w wielu zespołach? Pytania CTO przypisane w ten sam sposób.