규모에 맞춰 출력 검토하기

여기 정직한 문제가 있다: 에이전트들이 여러 과업에 걸쳐 수백 줄을 작성할 때, 당신은 열 줄짜리 디프를 검토하듯 모든 줄을 읽을 수 없다. 읽을 수 있는 척하면 고무도장 찍기(보지도 않고 승인)나 마비(아무것도 신뢰하지 않음) 중 하나로 이어진다. 둘 다 출시하지 못한다.

뚫고 나가는 길은 전부 읽는 대신 몇 개의 층에서 게이트를 거는 것이다:

• 테스트는 바닥선이다. 관련 테스트가 초록색이고 타입 체커가 깨끗하지 않으면 어떤 에이전트 출력도 병합되지 않는다. 이건 타협 불가이며 자동이다 — 이 부분은 기계가 한다.
• 위험한 부분을 스폿 리뷰하라. 전부 읽을 수는 없으니, 폭발 반경이 큰 부분을 읽어라: 인증, 돈, 데이터 삭제, 외부 호출을 건드리는 것 무엇이든. 나머지는 기능 만들기 장의 위험 신호를 훑어라 — 건드리지 말았어야 할 파일, 조용히 삭제된 것, 작은 요청이 만들어낸 거대한 디프.
• 코드베이스가 아니라 디프를 읽어라. git diff --stat은 무엇이 얼마나 바뀌었는지 몇 초 만에 알려준다. 한 모듈로 범위를 정한 과업이 여섯 모듈에서 변경을 보인다면, 한 줄을 읽기 전에 더 자세히 들여다보라는 신호다.
• 실행하라. 초록색 테스트 스위트가 동작하는 앱은 아니다. 그것을 클릭하라. 마지막 확인은 언제나 다른 모든 장과 같은 것이다: 당신 눈앞에서 요청한 대로 실제로 동작하는가?

여기서 범위 정하기는 두 번 보답한다. 빡빡하게 범위를 정한 과업은 실제로 검토할 수 있는 디프를 만든다. 풀어놓은 과업은 그럴 수 없는 디프를 만든다. 검토 문제는 대부분 상류에서, 브리프에서 해결된다.