코드 검토를 안 하게 되니 무섭네요

바로 이거죠. 저는 한술 더 떠서 OpenRouter를 통해 수많은 에이전트가 리뷰하게 합니다. Opus가 각 모델의 결과물을 검토하고 점수를 매기는 스코어카드 문서를 계속 업데이트하고 있어요(혹시 모를 숨은 보석을 찾기 위해 무작위 모델도 하나 추가하라고 지시했죠). 또한 각 모델의 강점과 약점을 기록해두어 다음 세션에서 어떤 모델을 쓸지 결정할 때 참고합니다.

너무 비싸요, 하지 마세요.

코드와 멀어지면서 생기는 자연스러운 결과입니다.

편리함을 즐기세요, 앞으로 더 심해질 겁니다.

저는 다시 돌아가서 왜 xyz를 변경했는지 묻곤 합니다

즉, 어떻게 구현하고 싶은지 명시하지 않고 계신 거네요. 계획이 부족한 겁니다. 원하는 것을 너무 일반화해서 말하고 있어요. 당장은 그렇게 넘길 수 있겠죠. 편리하니까요. 하지만 장기적으로는, 앱이 무엇을 해야 하는지 일반화만 하고 어떻게 구현할지 명시하지 않는다면 유지보수하기 힘든 엉망진창인 코드가 나올 겁니다.

만약 이게 직접 만들고 유지보수해야 하는 프로덕션 앱이라면, 이제 게으름 피우는 건 그만둬야 합니다. 처음부터 충분히 명시한다면 코드베이스는 여전히 당신의 창작물로 남을 수 있어요. Claude가 당신이 시작한 방향과 다르게 밀어붙인다면, 특히 반박하기 어려워 보인다면, 그건 배움의 기회로 삼으세요.

1년 뒤 누군가 당신에게 앱에 대한 기술적인 질문을 했을 때, 대답도 못 하고 Claude한테 물어봐야 하는 바보가 되고 싶으신가요? 코드를 직접 짜지 않더라도, 이해하는 대가로 돈을 받는다는 사실을 잊지 마세요.

물론 이게 그냥 개인 취미 프로젝트라면 이야기는 다르죠. 전 예전엔 사이드 프로젝트를 절대 안 했는데, 요즘은 그냥 즐기는 분위기예요. Claude가 알아볼 수 없는 어셈블리어를 뱉어내든 말든 상관없죠.

이게 미래인가요?

그건 당신에게 달렸습니다. 에디터에 코드를 직접 치지 않더라도 여전히 뇌를 쓰고 엔지니어로 남을 수 있어요.

제출하세요. 받아들이세요.

코드베이스에 /simplify를 실행해보세요. 데스크톱 앱을 쓰고 있다면, 코드베이스를 단순화 에이전트로서 검토해달라고 요청해보세요.

검토하는 습관이 문제가 아니라, 50개 파일이 바뀌는 게 문제예요. 그 정도 크기의 diff를 제대로 검토하는 사람은 아무도 없으니, 한 번의 변경을 빠르게 훑어볼 수 있을 정도로 작게 유지하는 게 목표가 되어야 합니다.

코드를 작성하기 전에, 건드릴 파일 목록과 그 이유를 나열하게 하세요. 목록이 기능에 비해 너무 길다면, 비용이 들지 않는 지금 단계에서 거절하세요.

그래도 diff가 크게 나온다면, '왜 xyz를 변경했냐'고 묻지 마세요. 항상 이유를 찾아낼 테니까요. '이 변경 사항 중 기능에 필요 없는 게 뭐냐'고 묻고, 그 부분만 되돌리게 하세요. git diff --stat을 먼저 실행하면 변경 범위를 몇 줄로 요약해서 볼 수 있습니다.

sparkhound가 말한 두 번째 에이전트 리뷰도 그 위에서 잘 작동합니다. 단, 똑같은 질문을 던져야 하죠. '기능을 깨뜨리지 않고 뺄 수 있는 게 뭐냐'고요.

저는 2005년쯤부터 컴파일러가 뱉어내는 어셈블리 코드를 확인하는 걸 그만뒀습니다.

저는 한 번 제출했고, 제 판단과는 반대였지만 이제 돌아갈 수 없게 됐습니다. 너무 편리하거든요.

저는 QA 팀이랑 일할 때 항상 그랬는데요.

이걸 어떻게 해야 할까요? 아니면 이게 미래인가요?

자동 테스트를 구축하세요. 하네스를 변경할 때마다 평가(evals)를 구축해서 워크플로우의 효율성을 측정할 수 있게 하세요. 평가는 결과가 항상 동일(사양)하다는 전제하에 토큰 사용량과 속도를 측정합니다. 오픈 사양을 채택하고, jev를 채택해서 반복적인 작업은 결정론적 알고리즘에 맡겨 비용을 절감하세요. 더 할 수 있는 게 많습니다. 모델들은 아직 게으르고 단순해서, 틀 밖을 보지 못하고 당신의 워크플로우를 개선해주지는 않을 겁니다.