AI 에이전트는 길을 잃지 않는다 — 그래서 리팩토링은 영원히 미뤄진다
AI Agents and the Refactoring That Never Happens
AI 에이전트와 함께 일하는 개발자들이 시스템의 가장 복잡한 부분을 재구성하는 것을 점점 더 꺼리게 되는 현상에 대한 분석. 인간은 작업 기억의 한계 때문에 코드를 모듈화하고 캡슐화해 왔지만, 에이전트는 그런 한계가 없어 '이 코드는 이제 감당할 수 없다'는 신호를 느끼지 못한다. 그 결과 리팩토링을 위한 자연스러운 체크포인트가 사라지고, 팀은 코드를 이해하지 못한 채 에이전트를 신뢰하게 된다. 저자는 모듈화가 인간에게만 좋은 것이 아니라 에이전트의 정확성과 토큰 비용에도 이득임을 지적하며, 에이전트가 스스로 묻지 않을 질문을 인간이 의도적으로 던져야 한다고 주장한다.
길을 잃지 않는 에이전트의 편리함은 분명하지만, '에이전트가 여전히 이해할 수 있다'는 것은 '시스템이 건강하다'는 것과 같지 않다.
HN 토론
64- bunderbunder
나는 "AI 에이전트는 길을 잃지 않는다"는 주장에 동의하지 않는다. 내가 관찰한 바에 따르면, 그들은 길을 잃는 느낌을 경험하지 않을 뿐이다. 이는 꽤 다른 것이다.
올여름 나는 깊고 복잡한 데이터 처리 파이프라인을 풀어내는 데 도움을 주기 위해 코딩 에이전트를 꽤 오랫동안 사용했다. 그 파이프라인은 에이전트들에 의해 매우 짧은 시간에 구축된 것이었다. 그러나 그것이 오류로 가득 차 있고 많은 잘못된 데이터를 생성하고 있다는 것도 분명해졌다.
내가 곧 발견한 것은 내 질문의 절반 이상이 매우 자신 있게 틀린 답변을 받는다는 것이었다. 그리고 마침내 현재 작업 중인 문제를 진단한 후에도 에이전트에게 버그 수정을 맡기는 것이 어려웠다. 데이터 흐름을 추적하는 데 나보다 더 어려움을 겪고 있었기 때문에(더 빠른 것이 반드시 더 나은 것은 아니라는 점을 참고로 제출한다), 그것은 원숭이의 발과 같았다. 물론 내가 요청한 정확한 버그를 고치겠지만, 일반적으로 그 과정에서 새로운 결함을 도입했다. 그리고 그렇다, 나는 최신 최고의 모델들과도 이 어려움을 겪고 있었다.
결국 나는 이 코드베이스에서 에이전트가 정말로 깊고 절망적으로 길을 잃었다고 결론지었다. (편집: 그리고 아마도 이 코드가 처음부터 그렇게 나빠진 이유는 그것을 만드는 데 사용된 에이전트들이 한동안 길을 잃었지만, 이 문제를 인식하고 운영자의 주의를 환기시킬 수 없었기 때문일 것이다.)
- joshstrange
그 사이 나는 여기서 수년(또는 수십 년) 동안 인간이 작성한 코드를 가능한 한 많이 리팩토링하고 있다. 내가 물려받았거나, 만드는 데 기여했거나, 그 위에 구축한 엉망진창을 깨끗하고 말끔한 것으로 바꾸는 것이 내가 가장 좋아하는 LLM 사용처일지도 모른다. 개인 프로젝트나, 시간이 있을 때 진화해온 코드베이스도 마찬가지인데, 내가 원했던 만큼 "깨끗하게" 유지되지 않았던 것들이 마침내 정리되고 있다.
나는 항상 내 코드가 깨끗하고 따라가기 쉽기를 _원했지만_, 삶, 마감, 우선순위 변경 등이 그 길을 막아섰다. 이제 나는 마침내 개인적인 열반을 실현할 수 있다.
그렇긴 하지만, 나는 모델이 과도한 추상화나 비슷한 것에 치우치지 않도록 조종해야 했다. 왜냐하면 그것이 코드를 너무 따라가기 어렵게 만들었기 때문이다.
- simonw
나는 코딩 에이전트에 접근할 수 있게 되면서 리팩토링할 수 있는 나쁜 코드 패턴에 훨씬 덜 관대해지는 데 도움이 되었다는 것을 발견했다.
리팩토링은 예전에는 실제 비용이 있었다. 즉, 새로운 기능을 개발하는 데서 떼어내야 하는 상당한 시간이었다.
이제 나는 잠재적인 리팩토링을 발견하면 비동기 코딩 에이전트(또는 워크트리 등)에서 프롬프트를 실행하고, 20분 후에 돌아와서 그것을 수락하거나, 약간 손보거나, 포기할 수 있다. 비용은 거의 들지 않는다.
- joshka
이것의 많은 부분은 다양한 벤치마크를 충족하는 코드를 생성하도록 에이전트를 훈련시키는 것과 이전에 부적응적이었던 것들에 대한 반응의 조합에서 비롯된 것처럼 느껴진다. 즉, 사후 훈련에서 모델에서 명시적으로 훈련된 것들이다. 나는 모델이 기본적으로 코드를 작성하는 방식에 포함되지 않는 장기 소프트웨어 엔지니어링 원칙이 많이 누락되어 있다고 생각한다.
나는 모델 사후 훈련을 하는 사람들이 대규모 복잡한 소프트웨어 시스템에서 작업하지 않은 젊은 연구자들인 경향이 있어서, 이와 관련하여 무엇이 중요한지에 대한 그들의 취향이 그다지 발달하지 않았을 수 있다는 추측이 있다.
그러나 이것은 적절한 초기 지시로 조종될 수 있는 영역이다("구현의 트레이드오프를 선택할 때, 문제를 해결하는 데 필요한 정확한 코드만 구현하는 것보다 장기적인 유지보수성과 코드의 이해 가능성을 위해 구축하라. 등. 사고 사슬은 종종 미래 에이전트 세션에서 반복되어야 할 정보를 포함하므로, 미래 세션과 사용자 이해가 존중되도록 그것을 코드나 외부 문서에 영속화하라.")
또한 변경 후 단계로도 비슷한 효과를 얻을 수 있다. 그리고 에이전트를 사용하여 생성된 코드의 범죄를 처리하는 일반적인 작업 방식에 이 계층을 구축할 수 있다. 그러나 모든 AI 연구소가 해야 할 일 중 하나는 실제 프로젝트의 AGENTS.md를 실제 프로젝트의 실패 모드가 무엇인지에 대한 하드 표현으로 보는 것이다 […]
- moezd
AI 에이전트는 항상 길을 잃는다. 특히 코드베이스가 이미 통제 불능으로 번져나가고 있다면 더욱 그렇다.
당신의 규율은 이미 코드를 이해하고 있거나 기능 개발 광란에 뛰어들기 전에 표준에 대한 명확한 기준선을 확립한 경우에만 효과가 있다. 그리고 그것은 매 턴마다 강제되어야 한다. 그렇지 않으면 코드 생성의 소방호스가 정문을 쉽게 무너뜨린다.