코딩 에이전트가 diff 크기를 최소화하도록 학습시킬 수 있을까요?

그 목록에 예상 라인 수를 추가하는 것도 도움 됨. 컴포넌트를 나열했는데도 ~2,000 라인이라고 하면, 파일이 수정되기 전에 계획을 거부해버리면 됨.

좋은 추가 의견임. 숫자가 있으면 계획을 거부하기가 훨씬 쉬워짐.

리뷰어가 어디를 검색했는지 나열하게 하는 건 좋은 요령임. 한 번에 완벽한 결과를 기대하는 것보다 여러 단계를 거치는 게 낫다는 데 동의함. 삭제 단계도 그중 하나로 아주 잘 쓰고 있음.

정말 흥미롭네. 혹시 설정한 거 오픈소스임?

맞는 말임. 다만 내 문제는 모델에 상관없이 발생하는 거라.

이런 것들이 봇들이 일상적으로 하는 짓인데, 비전문가들은 그냥 작동하니까 괜찮다고 생각함. 아무도 신경 안 쓸 거라고 생각하겠지!!

틀렸음... 그 코드베이스는 유지보수되어야 하고, 대중적인 믿음과는 반대로 그 책임은 절대 사람에게서 벗어날 수 없음. 책임 소재가 있어야 하니까.

이건 아마 걔들이 시도하는 것 중 가장 덜 심각한 문제일걸... DB나 API를 쿼리하게 하거나, 더 최악인... 쓰기 작업을 시키려고 하지 마.

언제 잘 작동하는지 앎? 숙련된 엔지니어가 모든 걸 어떻게 수행할지 말 그대로 지시할 때임. 코드를 어떻게 구조화할지, 스크립트 인클루드에 뭐가 들어가고 뭐가 안 들어갈지, 어떤 로직이 반복 가능하고 호출 가능해야 하는지, 플랫폼 일관성, 속도 제한, 확장성까지. 확실히 구체적으로 지시하면 괜찮은 코드를 줄 수도 있음. 그렇게 안 하면? 뭐... 말했듯이, 잘 모르는 사람들에겐 불행하게도 그게 좋은 코드처럼 보이겠지. 그렇다고 그게 좋은 코드가 되는 건 아님.

참고로, 모델의 노력 수준(effort level)을 낮추면 작업 속도도 빨라지고 diff 수도 줄어듦. '바이브 코딩(vibecoding)'을 너무 심하게 하는 게 아니라면 실패율도 거의 안 올라감.

이런 것들은 에이전트 리뷰 단계의 일부가 되어야 함. PR을 완료하기 전에 여러 에이전트를 돌려서 이런 문제를 잡아내야 함. 자동화할 수 있는 부분임. 100%는 아니지만 꽤 많이 잡아냄.

혹시 공유해줄 만한 괜찮은 AI 코드 리뷰 파이프라인 있음?