Granska intentionen, låt maskinerna sköta resten

Agent-pull requests kommer i större antal, de ser säkra ut, och du kan inte fråga författaren "vad tänkte du?" efteråt. Tidig forskning börjar visa vad det betyder i praktiken.

En studie av 7 156 agent-PR:ar fann att typen av uppgift betyder mer än vilken agent som skrev den: "documentation tasks achieve 82.1% acceptance compared to 66.1% for new features." Ingen agent vann varje kategori. [2] En andra studie tittade på 654 avvisade agent-PR:ar och identifierade sju avvisningsmönster som bara förekommer i agent-PR:ar — och att "a large proportion of rejected PRs (67.9%) lack explicit reviewer feedback." [1] Med andra ord: för det mesta säger ingen agenten varför.

Båda studierna använder samma publika dataset av agent-PR:ar (AIDev), och båda publicerades i februari 2026; agenterna har förändrats sedan dess — läs siffrorna som riktning, inte som en topplista.

Allt en maskin kan kontrollera ska aldrig nå en människa: formatering, typer, lint, komplexitet, tester. Vart och ett av dem hör hemma tidigare i kedjan — vid agentens redigering, vid commit, i CI. Vi går igenom hur du sätter upp det i vår guide om direkt feedback för kodande agenter.

Googles guide för kodgranskning gäller fortfarande för agenter: granskaren tittar på design, funktionalitet, komplexitet, tester, namngivning och kommentarer — det som gör en kodbas friskare över tid. [3] Skillnaden med agenter är att den mekaniska delen av den listan nästan helt kan automatiseras.

"Klart, alla tester går igenom" är ett påstående. Be om bevis istället. Lägg till en överlämningsrad i varje story som ber agenten "summarize changed files, checks run, failures encountered, and any remaining risk." [8] Cursors Cloud Agents kan också bifoga skärmdumpar, videor och loggreferenser till pull requesten, så att du kan se att ändringen fungerar utan att checka ut grenen. [7]

## What changed
- auth/login-form.tsx — locked-account message + reset link
- auth/login-form.test.tsx — new test for the locked case

## Checks run
- npm run typecheck ✔
- npm test -- auth ✔ (14 passed)

## Failures hit
- First run broke the signup error style; fixed by reusing ErrorBanner.

## Remaining risk
- Copy not reviewed by product. Lockout threshold unchanged (non-goal).

Låt inte agenten betygsätta sitt eget arbete. En automatisk granskare i en färsk kontext fångar saker som skaparen är blind för. Claude Codes dokumentation beskriver ett skrivare/granskare-mönster: "A fresh context improves code review since Claude won't be biased toward code it just wrote." [4] Cursor Bugbot "analyzes PR diffs and leaves comments with explanations and fix suggestions" [5], och GitHub Copilot code review gör samma sak på GitHub. [6] Claude Code på webben kan gå ett steg längre och automatiskt fixa pull requests: den bevakar en PR och svarar på CI-misslyckanden och granskningskommentarer — ett bra exempel på att skicka fynden tillbaka till agenten. [9]

Det finns en baksida, och samma dokumentation är ärlig om den:

"A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering." [4]

Agera därför bara på fynd som påverkar korrekthet eller de angivna kraven. Allt annat är valfritt.

Kom ihåg de 67,9 %: de flesta avvisade agent-PR:ar saknar en uttalad anledning. [1] När du avvisar en PR eller ber om ändringar, säg varför — i PR:n eller i storyn. "Fel" lär ingenting. "Den här bör återanvända befintliga ErrorBanner, se signup-form.tsx" fixar den här körningen och nästa. Om samma feedback dyker upp gång på gång hör den hemma i era delade konventioner, inte i ännu en kommentar.

Den här guidens poäng är att granskningen bör vara lagerdelad: maskiner först, en oberoende granskare sedan, du sist — mätt mot storyn. Aerunit täcker mittlagret och måttstocken. När en agent öppnar en pull request granskar Aerunit den automatiskt och kan skicka fynden tillbaka till samma agentsession för att fixas, så att PR:n du öppnar redan har gått igenom en runda.

Måttstocken är själva storyn: Aerunits story writer föreslår Linear-ärenden med omfattning, acceptanskriterier och icke-mål, så att du granskar mot ett namngivet mål. Och teamkonventioner du annars skulle upprepa i granskningskommentarer lever en gång i delad kontext och skills, och matas in i varje story och körning.