코딩 에이전트를 사용하는 거의 모든 사람이 빠지는 패턴이 하나 있는데, 이는 에이전트를 사용하는 목적 자체를 조용히 무너뜨립니다. 에이전트가 변경 사항을 만들어내면 당신은 당연한 질문을 던집니다. "이거 작동하나요?" 에이전트는 그렇다고 답합니다. 당신은 그것을 믿습니다. 확신에 차 있고 보통은 맞기 때문입니다. 그리고 가끔씩 에이전트는 확신에 차서 완전히 틀리게 되고—당신은 그것을 프로덕션에서야 알게 됩니다.
문제는 에이전트가 거짓말을 한다는 것이 아닙니다. 문제는 질문 그 자체입니다.
왜 "작동하나요?"는 잘못된 질문인가
에이전트에게 자신의 변경 사항이 작동하는지 물을 때, 당신은 그 결과물을 만들어낸 것과 똑같은 추론으로 그 결과물을 평가하라고 요청하는 것입니다. 같은 펜으로 자기 답안지를 채점하는 셈입니다. 코드를 작성하면서 어떤 엣지 케이스를 놓쳤다면, 그것을 판단할 때도 똑같은 엣지 케이스를 놓칠 것입니다. 새로운 것이 하나도 개입하지 않았기 때문입니다—같은 모델, 같은 맥락, 같은 사각지대입니다.
더 나쁜 것은, 언어 모델은 동의하는 쪽으로 기우는 경향이 있다는 점입니다. "이건 null 이메일을 제대로 처리하죠, 그렇죠?"라는 식으로 질문을 던지면, 당신은 평가를 요청한 것이 아니라 결론을 제시하고 에이전트에게 그것을 확인해 달라고 초대한 것입니다. 에이전트는 보통 그렇게 합니다. 당신이 돌려받는 것은 검증이 아닙니다. 그것은 당신 자신의 바람을 매우 유창하게 되울린 메아리일 뿐입니다.
대신 증거를 요구하세요
해결책은 작지만 모든 것을 바꿉니다. 에이전트에게 변경 사항이 작동한다고 주장하게 하는 것을 멈추고, 대신 보여 달라고 요청하는 것입니다. 증거란 에이전트의 의견이 아니라 시스템 자체가 만들어낸, 당신이 직접 확인할 수 있는 산출물입니다. 모든 증거가 동등한 것은 아니며, 대략적인 위계가 있습니다.
- 실행 증거가 가장 강력합니다. 에이전트가 실제로 코드를 실행하고 진짜 출력을 보여줍니다—통과한 테스트, 기대한 대로 반환된 명령어.
- 전후 비교 증거는 그에 못지않게 좋습니다. 관찰 가능한 상태의 구체적인 변화입니다. 쿼리 수가 47에서 2로 줄었다, 실패하던 요청이 이제 200을 반환한다.
- 에이전트가 작성한 테스트는 더 약합니다. 버그를 놓친 것과 같은 사각지대가 테스트에서도 그 버그를 놓칠 수 있기 때문입니다—하지만 당신이 읽고 실행할 수 있는 테스트는 여전히 단순한 주장보다는 훨씬 낫습니다.
- 말로 하는 설명이 가장 약합니다. 때로는 그것이 얻을 수 있는 전부이지만, "제 추론은 이렇습니다"는 증거가 아닙니다. 그것은 증거가 원래 검증해야 할 대상 그 자체입니다.
모든 경우에서 해야 할 일은 같습니다. 예/아니오 질문을 관찰 가능한 무언가에 대한 요청으로 바꾸는 것입니다.
실제로는 이런 모습입니다
"이 마이그레이션이 null 이메일을 처리할까요?"라고 묻는 대신, null 이메일을 가진 행을 시드하고 마이그레이션을 실행한 뒤 그 출력을 보여 달라고 요청하세요. "이게 N+1 쿼리 문제를 고쳤나요?"라고 묻는 대신, 쿼리 로깅을 추가하고 엔드포인트를 호출한 뒤 전후 카운트를 보여 달라고 요청하세요. "레이트 리미터가 리셋되나요?"라고 묻는 대신, 한도에 도달하고 기다렸다가 다시 시도해서 요청이 성공하는 모습을 보여 달라고 요청하세요. 각각의 경우에서, 당신은 믿어야만 했던 주장을 읽을 수 있는 결과로 대체한 것입니다.
이것이 우리 에이전트가 샌드박스 안에서 동작하는 이유입니다
증거는 에이전트가 실제로 무언가를 실행할 수 있을 때만 성립하며, 이것은 나중에 덧붙인 생각이 아니라 설계상의 결정입니다. 모든 TaskGoblin 실행은 저장소가 클론되고 툴체인을 사용할 수 있는 샌드박스 안에서 이루어지므로, 에이전트는 코드가 무엇을 할지 추론만 하는 것이 아니라 테스트를 실행하고, 명령어를 실행하고, 실제 결과를 관찰할 수 있습니다. 머지 리퀘스트를 검토할 때 그 발견 사항은 구체적인 동작을 가리키며, 당신이 @taskgoblin fix라고 답할 때 그 변경 사항은 단순히 주장되는 것이 아니라 에이전트가 직접 검증할 수 있는 것입니다.
이것이 또한 훌륭한 개발 환경이 그 어느 때보다 큰 보상을 주는 이유이기도 합니다. 당신의 서비스를 띄우고, 시드 데이터를 로드하고, 테스트 스위트를 실행할 수 있는 에이전트는 진짜 증거를 만들어낼 수 있습니다. 코드만 읽을 수 있는 에이전트는 의견만 줄 수 있습니다. 당신의 프로젝트가 실행 가능할수록, 당신은 믿는 대신 검증할 수 있는 에이전트의 결과물을 더 많이 얻게 됩니다.
한 문장으로 요약하면
에이전트에게 그 작업이 맞는지 묻지 마세요. 그것을 보여 달라고 요청하세요—그리고 당신이 직접 확인할 수 있는 종류의 보여주기를 우선하세요. 코드를 실행하고 그 출력을 당신에게 건네주는 에이전트는, 코드를 그저 보증하기만 하는 에이전트가 결코 할 수 없는 단 한 가지를 해내고 있습니다. 그것은 바로 자기 자신의 확신 말고, 당신이 믿을 수 있는 무언가를 주는 것입니다.
