코딩 에이전트가 작업을 더 오래 자율적으로 수행할 수 있어도 개발 생산성이 항상 높아지는 것은 아니라는 단순 시뮬레이션 모델이 제시됐다. 모델은 잘못된 설계가 뒤늦게 발견되면 그 위에 쌓인 코드를 되돌려야 하며, 프롬프트에 담기지 않은 제약을 파악하고 결과를 검토하는 엔지니어의 역량이 병목이 될 수 있다고 설명한다.

모델의 출발점은 작업 완료 시간 지표와 실제 개발 생산성은 다를 수 있다는 문제의식이다. METR의 작업 완료 시간 지표는 사람이 X시간 걸리는 과제를 모델이 얼마나 오래 걸려 수행하는지, 그리고 성공률이 얼마인지를 측정한다. 반면 범위가 반복해서 바뀌는 과제에서 코드 복잡도와 불필요한 코드 등을 함께 보는 SlopCodeBench에서는 최신 모델의 최고 통과율이 GPT-6 Astra XHigh의 16.3%였고, 이는 5월 GPT-5.5 Sol의 14.8%와 비교해 큰 차이가 아니다. 원문은 두 수치의 차이가 잡음일 가능성도 있다고 덧붙인다.

이 글은 과제 크기, 모델의 속도와 작업 성공률, 잘못된 추상화로 흐를 가능성, 프롬프트 작성과 검토에 드는 시간 등을 변수로 둔 단일 에이전트 모델을 구성했다. 엔지니어가 문제의 제약을 얼마나 알고 프롬프트에 전달하는지, 검토 과정에서 문제를 얼마나 잘 발견하는지도 반영했다. 이는 실제 개발을 측정한 실험 결과가 아니라 단순화된 가정에 따른 시뮬레이션이다.

시뮬레이션에서는 한 번에 맡기는 작업이 길어질수록 잘못된 추상화가 쌓이고, 나중에 발견했을 때 되돌릴 작업도 늘어 생산성이 떨어질 수 있었다. 작업 완료 시간 지표의 H₅₀가 네 배로 늘어도 기본 설정에서 역량이 높은 엔지니어의 생산성 증가는 약 3.0배에서 3.3배로 제한됐다. 모델의 잘못된 설계 위험을 낮추면 역량이 낮은 엔지니어의 생산성은 크게 개선될 수 있지만, 회사 내부의 사적 제약처럼 모델이 추론할 수 없는 정보는 사람이 프롬프트와 검토로 보완해야 한다.

모델의 기본 설정에서 역량이 높은 엔지니어는 에이전트 두 개를 함께 쓸 때 가장 높은 처리량을 얻었다. 엔지니어가 프롬프트 작성과 검토에 이미 시간을 쓰고 있어, 에이전트가 더 늘면 대기하는 에이전트가 생기고 작업 간 전환 비용이 커진다는 설명이다. 다만 모델 속도와 작업 시간 지평, 잘못된 추상화 위험 등의 조건이 달라지면 적정 에이전트 수 역시 달라질 수 있다. 역량이 낮은 엔지니어는 두 개를 쓰는 것이 반드시 더 생산적이지 않았으며, 글은 한 에이전트를 쓰면서 프롬프트와 검토에 집중하는 방식을 제안한다.

AI가 서로의 코드를 검토하는 에이전트 스웜은 검토를 사람이 맡는 소규모 에이전트 운영보다 더 많은 잠재적 기술 부채를 남길 수 있었다. 시뮬레이션에서는 높은 생산성으로 보이는 결과가 프로젝트 종료 뒤 되돌려야 할 코드의 비용을 제외했을 때 나타나기도 했다. 따라서 이 모델이 제시하는 실무적 시사점은 작업을 가능한 한 길게 맡기거나 에이전트를 무작정 늘리기보다, 사람이 알고 있는 제약을 프롬프트에 담고 결과를 자주 검토해 잘못된 방향을 일찍 바로잡는 것이다.