Agent 모드 대신 Debug 모드?

..지금까지 이걸 안 해봤다니 내가 바보 같네. 고마워..

Debug 모드 쩔어, 진짜 재밌고 통찰력 있게 쓸 수 있음! 매일 쓰는 건 아니지만, 드라이버 디버깅하거나 런타임에 탄탄한 telemetry를 심어서 진짜 이상한 이슈들을 실시간으로 잡아낼 때 엄청나게 강력한 기능임. 난 진심으로 디버깅 타임이 기다려질 정도임!

근데 모든 개발 스타일이 여기서 이득을 보는 건 아니라는 점을 고려해야 함. 만약 네가 주로 프론트엔드 UI 작업을 한다면(비하하는 건 아님), 런타임 플래그나 임시 로깅, telemetry 같은 게 별로 의미가 없...

맨날 씀. 다른 사람들이 말한 것처럼, Agent mode가 무한 루프에 빠지는 어려운 버그 잡을 때 진짜 최고임.

뭐가 문제일지 가설 세우고, 확인하려고 로깅 추가하고, 재현해달라고 요청한 뒤 자동으로 로그 읽고, 가설이 맞는지 틀린지 검증하고, 끝나면 로깅도 알아서 지워줌.

혁신적인 건 아니지만, 통합이 매끄럽게 잘 되어 있어서 막혔을 때 빠져나오기 좋은 패턴임.

맞아, 차이점은 '버그를 고칠 수 있느냐'보다는 '어떻게 확신을 갖느냐'에서 더 잘 드러나는 것 같아. Agent mode는 버그가 단순하거나 실패 경로가 뻔할 때는 보통 괜찮아. Debug mode는 더 긴밀한 루프가 필요할 때 더 유용하게 느껴져: 로그 추가하고, 재현하고, 가설 세우고, 맞는지 틀린지 증명하고, 마지막으로 계측 코드 제거하는 과정 말이야. 게임 개발할 때는 상태, 타이밍, 라이프사이클, 렌더링, 혹은 이상한 런타임 동작에 문제가 달려있을 때 Debug mode를 쓸 것 같아. 만약 그냥 'th...

이미 베이스 코드가 있다면 구현이나 수정을 할 때는 Plan+Debug 조합이 더 나음. 난 새로운 베이스 코드를 생성해야 할 때만 Plan+Normal 모드를 씀.

오늘 Debug 모드한테 웹 페이지가 왜 서비스를 두 번 호출하는지 물어봤음. 페이지를 살펴본 뒤에 무려 6가지(!) 가능한 이유를 제시하더니, 각각을 증명하거나 부정하기 위해 로깅을 추가하더라. 결국 이유 D가 문제인 걸로 밝혀졌고, 수정 완료한 뒤에 로깅은 제거됐음.

참 세상 좋아졌네. 그냥 각각 써보고 직접 문제를 해결해 보면 안 됨?