훨씬 차분해졌다. 리팩토링 전략과 결과물을 정의하다. GLM-5.2
원문 제목 — So much calmer... Defined strategy and outcomes for refactoring. GLM-5.2
📄 전문 번역
DRY와 모듈화를 내세워 리팩토링을 시작하면 에이전트의 작업을 의심하게 된다는 것이 작성자의 설명이다. 모델이 곁가지로 새어 나가 사이드 퀘스트를 정복하던 과거 경험이 원인이며, Redis 큐와 워크로드 정규화를 고민하다 높은 컨텍스트 한도에 부딪히는 방식이야말로 대부분의 코딩 에이전트가 일하는 방식이라고 지적했다.
이에 전략과 경계를 먼저 정의하는 방식을 도입했고, 자체 하네스 Rehex가 자율이 아닌 완전한 부모 감독 아래 스스로를 개선해 가면서 훨씬 차분한 경험이 되었다고 밝혔다. 도파민 급등도 없고 에이전트가 무엇을 하는지 궁금해할 일도 없다는 것이다.
Claude를 몸소 붙들다 정말 질렸고, Codex는 더 구조적이어서 좋아 보이며 OpenCode의 구조는 모델에 따라 크게 요동친다며, 다른 이용자들이 작업을 어떻게 구조화하는지 하네스를 접고 Linear나 GitHub 이슈를 읽는 쪽으로 갔는지 물었다.
💬 주요 댓글 번역 (2)
🔍 루키 분석
코딩 에이전트의 사이드 퀘스트 현상과 컨텍스트 한도 소진을 문제로 지적하며, 리팩토링 전략과 결과물을 미리 정의하는 방식으로 작업이 훨씬 차분해졌다는 경험이 공유됐다. 댓글에서는 구조화된 진행 표시가 Claude의 불투명한 장기 계획보다 안심된다는 반응이 나왔고, 작성자는 작업 단위 설계 덕분이라고 설명했다.
— 루키 · glm-5.3-flash:cloud
터미널 상태 바가 Working...에 머물면서도 실제 구조화된 진행 상황을 보여주는 것이, Claude가 인증 레이어를 재작성할 12단계 계획을 말없이 꾸미는 걸 지켜보는 것보다 훨씬 안심된다.
감사하다. 바로 그렇게 설계한 이유다. 하네스가 작업 단위 작업을 장려하기 때문에 편집과 쓰기, 실행 같은 도구 기반 작업에서는 항상 그 뷰가 뜬다.