Harness Engineering is not Enough: Why Software Factories Fail — Dex Horthy, HumanLayer

한 줄 핵심

AI 코딩을 무작정 더 많은 루프와 하네스로 밀어붙이면 단기 생산성은 오르지만, 코드베이스 품질과 유지보수성은 학습·평가 한계 때문에 결국 무너진다.

시간별 요약

1. 0:01
   AI 코딩 도입이 빠르게 확산됐지만, 코드 리뷰 약화·인시던트 증가·버그 증가가 동시에 나타나고 있다. 하네스 엔지니어링만으로는 해결되지 않으며, 문제의 본질은 모델 훈련 방식에 있다.
2. 4:00
   기존 소프트웨어 팩토리는 사람이 만들고 리뷰하던 흐름 위에 에이전트를 얹는 구조였고, 에이전트 팩토리는 그 자리를 agent로 바꾼다. 그러나 빌드 속도는 빨라져도 리뷰·테스트가 병목으로 남아, 더 많은 루프를 넣는다고 근본 문제가 사라지지 않는다.
3. 8:00
   lights-off 방식은 짧게는 작동해도, 3~6개월만 지나면 유지보수성과 코드베이스 품질이 급격히 악화된다. 모델은 단발성 문제 해결에는 강해졌지만, 긴 기간에 걸쳐 복잡한 코드의 일관성과 변경 용이성을 유지하는 데는 여전히 인간의 steering이 필요하다.
4. 11:00
   코딩 모델은 주로 테스트 통과 여부로 보상 학습되기 때문에, 유지보수성이나 아키텍처 품질을 희생해도 정답처럼 보이는 코드를 만들기 쉽다. 좋은 평가 기준이 없으면 try/catch 남용, 임의의 캐스팅 같은 부작용이 생기고, 품질 저하는 수개월 뒤에야 드러난다.
5. 15:00
   속도를 유지하려면 코드 리뷰를 없애기보다, 제품 리뷰·아키텍처·program design·vertical slices를 통해 사전 정렬을 강화해야 한다. 30분의 선행 설계가 수시간의 재작업을 줄이며, 결국 AI는 더 빠르게 만들되 인간은 여전히 코드를 읽고 책임져야 한다.

실무 인사이트

• AI 코딩 도입의 성공 지표를 PR 수나 생성 속도만 보지 말고, 인시던트·재작업률·유지보수성 같은 장기 품질 지표까지 함께 추적해야 한다.
• 에이전트에게 일을 더 시키기 전에 제품 의도, 아키텍처, 호출 구조를 문서로 먼저 고정하면 리뷰 비용과 오류 확률을 동시에 낮출 수 있다.
• 코드 생성 자동화보다 더 중요한 것은 품질을 판별할 verifier와 평가 체계를 만드는 일이며, 특히 장기 유지보수성을 측정하는 벤치마크가 핵심이다.