에이전트가 쓴 코드를 읽지 않고, 제약으로 둘러싼다는 Uncle Bob

Who Should Read

코딩 에이전트가 쓴 코드를 일일이 리뷰하다 지쳐, 리뷰 대신 자동 검증 체계를 고민하는 백엔드 개발자

Core Mechanics

• 코드를 읽지 않는 게 전략이다
  • Uncle Bob은 60년대 후반부터 코딩했다고 밝힌다.
  • 에이전트가 쓴 코드를 읽지 않는 것이 생산성을 취하는 유일한 방법이라고 말한다.
• 읽는 대신 제약으로 둘러싼다
  • 에이전트 주변에 극단적인 제약을 건다고 한다.
  • 단위 테스트, gherkin 테스트, QA 절차, 품질 지표, 뮤테이션 테스트, 테스트 커버리지 등을 쓴다.
• 제약 목록은 이게 끝이 아니다
  • 원문은 이 외에도 "수많은 다른 것들"이 있다고 쓴다.
  • 구체적인 설정이나 도구 이름은 나오지 않는다.
• 신뢰의 근거는 관문 통과다
  • 에이전트 코드가 모든 제약과 테스트라는 관문(gauntlet)을 통과해야 한다.
  • 그래서 결과물에 매우 높은 확신이 있다고 말한다.
• 트윗이 나온 맥락
  • 한 사용자가 Claude에게 파일 편집을 맡기기 불편하고, 책임지는 코드는 이해해야 한다고 썼다.
  • Uncle Bob이 이에 답하는 형태다.

Community Reactions

• 테스트도 에이전트가 쓰면 소용없다는 경험
  • 에이전트가 기능을 완전히 거꾸로 구현하고, 그 구현이 맞다는 테스트를 잔뜩 써서 전부 통과한 적이 있다는 경험이 나왔다.
  • 형식 검증을 써도 거꾸로 된 기능의 증명만 나왔을 거라는 의견이다.
• 그는 테스트와 제약은 읽느냐는 반론
  • 그 정도 확신엔 테스트가 아주 많이 필요하다는 의견이다.
  • SQLite는 코드 한 줄당 500줄 이상의 테스트가 있다는 예가 나왔고, 그럴 바엔 코드를 읽는 게 낫다는 주장이다.
• 리뷰해 보니 95%는 고칠 게 없었다는 경험
  • 에이전트 코드를 직접 리뷰하면 약 95% 확률로 바꿀 게 없다는 경험이 공유됐다.
  • 아키텍처 결정과 에이전트의 "주의사항" 확인은 사람이 해야 한다는 의견이다.
• 진짜 비싼 버그는 스펙 빈틈이라는 의견
  • 비용이 큰 버그는 대개 스펙 자체의 구멍이라는 의견이 있었다.
  • 사람의 노력이 스펙·설계·테스트 시나리오로 옮겨 가야 한다는 의견도 있었다.

How to Apply

• 에이전트 PR에 뮤테이션 테스트 돌리기
  • 오늘 가장 최근 에이전트가 쓴 모듈 하나를 골라라.
  • 언어에 맞는 뮤테이션 테스트 도구를 돌려 살아남은 변이를 확인해라.
  • 살아남은 변이가 있으면 테스트가 약하다는 신호로 보고 테스트를 보강해라.
• 테스트는 구현과 분리해 먼저 쓰기
  • 스펙을 사람이 확인한 뒤 gherkin 시나리오부터 작성해라.
  • 그 뒤에 에이전트에게 구현을 맡겨라.
  • 테스트와 구현을 같은 에이전트가 동시에 쓰지 않게 나눠라.
• 에이전트 완료 조건에 관문 목록 박기
  • 에이전트 지침 파일에 테스트, 커버리지, 품질 지표 통과를 완료 조건으로 명시해라.
  • 하나라도 실패하면 완료로 보고하지 못하게 해라.
• 스펙 리뷰에 사람 시간 쓰기
  • 코드 리뷰 시간을 줄이고 스펙과 시나리오 점검에 써라.
  • 거꾸로 구현된 기능을 막으려면 요구사항 자체를 사람이 확인해라.

Try It

# Claude Code 또는 ChatGPT에 붙여넣기 (원문 아이디어의 간이 버전: 제약으로 코드 검증)

당신은 코드를 구현하는 에이전트입니다. 아래 기능을 구현하기 전에 먼저 제약을 세우세요.

기능 설명: {{기능 설명}}
언어/프레임워크: {{언어}}

순서:
1. 기능 설명을 gherkin(Given/When/Then) 시나리오로 먼저 써서 보여주세요. 정상·경계·실패 케이스를 포함하세요.
2. 시나리오마다 단위 테스트를 작성하세요. 구현 코드는 아직 쓰지 마세요.
3. 테스트가 통과하도록 구현하세요.
4. 구현 후 뮤테이션 테스트를 돌린다고 가정하고, 살아남을 만한 변이를 5개 예상해 그걸 잡는 테스트를 추가하세요.
5. 마지막에 "스펙에서 내가 해석한 부분"과 "스펙과 달라질 수 있는 부분"을 목록으로 적으세요.

이어서 해 볼 것: 5번의 목록을 사람이 읽고 스펙이 맞는지 확인한 뒤, 실제 뮤테이션 테스트 도구를 돌려 보세요.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://twitter.com/unclebobmartin/status/2080257779395154409?s=20
• https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html