Anthropic과 Simon Willison의 논쟁: 코드가 많다고 더 나은 소프트웨어는 아니다

Simon Willison이 오랫동안 금기시돼 온 생산성 지표를 다시 꺼내 들었다. 수십 년간의 회의론에도 불구하고, 코딩 에이전트가 코드 줄 수를 다시 의미 있는 지표로 만들 수 있다는 주장이다. 그의 8월 19일 에세이는 AI 지원 개발을 다룬 팟캐스트 대화에서 비롯됐다. anthropic simon이라는 검색어는 이 논쟁을 이끄는 두 축, 즉 Willison의 주장과 Anthropic의 점점 더 강력해지는 코딩 도구를 포착한다.

Willison은 더 긴 프로그램이 자동으로 더 낫다고 주장하는 것이 아니다. 그의 주장은 더 좁다. 과거 소프트웨어 생산에는 인간의 처리량이라는 엄격한 한계가 있었다. 개발자는 생산적인 하루에 수백 줄 정도의 프로덕션 준비 코드를 완성할 수 있었다. 이제 에이전트는 같은 시간 안에 훨씬 더 많은 코드를 생성하고, 테스트하고, 수정할 수 있다.

이 변화는 다른 한계를 드러낸다. Fred Brooks는 이를 개념적 일관성(conceptual integrity)이라고 불렀다. 시스템은 하나의 일관된 설계 아이디어를 반영해야 한다는 뜻이다. 코딩 에이전트는 구현 역량을 높일 수 있지만, 커져 가는 코드베이스 전반에서 그 일관성을 자동으로 지켜주지는 않는다.

따라서 진짜 경쟁 구도는 인간 프로그래머와 Anthropic 또는 다른 모델 제공업체 간의 대결이 아니다. 구현 처리량과 아키텍처 이해의 대결이다. 이제 팀은 자신 있게 설명하고, 검토하고, 유지보수할 수 있는 속도보다 더 빠르게 코드를 생산할 수 있다.

Simon Willison이 코드 줄 수 논쟁에서 실제로 바꾼 것

Willison은 코드량을 개별 프로그래머를 평가하는 점수가 아니라, 사라진 생산 제약의 증거로 본다.

그의 8월 19일 에세이에서 Willison은 소프트웨어 팀이 타당한 이유로 거부해 온 관점을 다시 살핀다. 코드 줄 수를 세면 부풀린 구현을 부추기고, 재사용에는 불이익을 주며, 결과 시스템이 의도한 문제를 해결하는지는 무시하게 된다.

관리자가 직원들을 비교할 때는 이러한 반론이 여전히 유효하다. 취약한 하위 시스템을 제거하는 개발자는 수천 줄을 추가하는 개발자보다 더 큰 가치를 만들 수 있다. 간결한 구현은 테스트, 이해, 운영도 더 쉬울 수 있다.

Willison의 논의는 다른 지점에서 출발한다. 코딩 에이전트 이전에는 숙련된 엔지니어가 직접 만들어낼 수 있는 작동하는 코드의 양이 실질적인 상한선을 만들었다. 타이핑은 그 한계의 일부일 뿐이었다. 개발자는 저장소를 탐색하고, 문서를 참고하고, 테스트를 실행하고, 실패를 디버깅하고, 최종 변경 사항을 검토해야 했다.

에이전트는 이러한 활동 중 여러 가지를 하나의 상호작용 루프로 압축한다. 개발자는 변경 사항을 설명하고, 에이전트가 관련 파일을 살피게 한 뒤 결과를 구현하고 테스트하도록 요청할 수 있다. 이후 사람은 패치를 검토하고, 방향을 바로잡거나, 다시 한 번 반복 작업을 진행한다.

여기서 코드 줄 수가 흥미로워지는 이유는 상한선이 이동했기 때문이다. 한 명의 엔지니어가 하루 동안 여러 개의 상당한 규모의 구현을 감독할 수 있다면, 코드량은 생산 역량의 실제 변화를 기록한다. 그렇다고 생성된 모든 줄이 유용하다는 뜻은 아니다.

이 구분은 공장 처리량과 닮았다. 생산 라인에서 나오는 단위 수를 세면 생산 능력에 관한 중요한 정보를 얻을 수 있다. 하지만 고객이 그 단위를 필요로 하는지, 사양을 충족하는지, 현장에서 고장 나지 않을지는 알 수 없다.

이처럼 더 좁은 주장이 중요한 이유는 AI 생산성 논의가 흔히 극단으로 치닫기 때문이다. 한쪽은 생성된 모든 줄을 새로운 경제적 산출로 본다. 다른 한쪽은 코드량을 지나치게 완전히 무시해, 구현 처리량의 명백한 증가조차 설명하지 못한다.

Willison은 더 유용한 중간 입장을 제시한다. 에이전트가 개발자가 시도할 수 있는 구현의 양을 늘렸는지 물을 때는 코드를 세라. 유지보수성, 사용자 가치, 정확성, 엔지니어링 판단을 평가할 때는 세는 일을 멈춰라.

이 해석은 Simon Willison의 AI 실험이 개발자들의 관심을 끄는 이유도 설명한다. 그는 작동하는 프로토타입과 도구, 그리고 그 제작 과정에 관한 상세한 기록을 자주 공개한다. 이러한 결과물은 에이전트가 한 사람이 더 많은 아이디어를 탐색하도록 도울 수 있음을 보여준다. 그 결과물이 곧 성숙한 제품과 같다는 뜻은 아니다.

따라서 변화는 측정할 수 있지만, 측정에는 경계가 있다. 더 많은 작동하는 코드는 더 큰 생산 역량을 시사할 수 있다. 그러나 팀이 그 역량을 현명하게 사용했는지는 판단할 수 없다.

Anthropic Simon 검색이 Claude Code 생산성으로 이어지는 이유

anthropic simon의 연결점은 워크플로의 변화다. 개발자들은 모든 줄을 직접 작성하는 대신 점점 더 구현 작업을 감독하고 있다.

Anthropic은 Claude Code를 에이전트형 코딩 도구로 설명한다. 즉, 프로젝트를 살피고, 파일을 수정하고, 명령을 실행하며, 요청한 결과에 도달할 때까지 반복 작업을 할 수 있다. 이 워크플로는 커서 주변의 짧은 다음 내용을 예측하는 기본 자동완성과 다르다.

이 차이는 작업 단위를 바꾼다. 자동완성에서는 개발자가 여전히 구현을 단계별로 구성한다. 에이전트를 사용하면 개발자는 엔드포인트 추가, 마이그레이션 작성, 실패한 테스트 조사처럼 범위가 정해진 결과를 위임할 수 있다.

Anthropic의 코딩 가이드는 저장소 탐색, 문서화된 지침, 테스트, 검증을 강조한다. 이러한 관행은 중요한 현실을 보여준다. 코드 생성만으로 올바른 변경이 보장되지는 않기에 에이전트에는 맥락과 피드백이 필요하다.

현실적인 세션은 흔히 사전 탐색으로 시작한다. 에이전트는 프로젝트 지침을 읽고, 관련 인터페이스를 검색하며, 기존 규칙을 파악한다. 이후 저장소의 테스트를 실행하기 전에 패치를 제안하거나 생성한다.

목표에 대한 책임은 여전히 사람에게 있다. 작업이 충분히 명세됐는지, 선택한 추상화가 시스템에 맞는지, 결과 동작이 받아들일 만한지를 결정한다. 생성 코드의 양이 늘수록 이러한 결정은 더욱 중요해진다.

따라서 Claude Code 생산성에는 두 가지 요소가 있다. 눈에 보이는 요소는 구현 속도다. 덜 눈에 띄는 요소는 개발자가 제약 조건을 제공하고, 방향 이탈을 감지하며, 그럴듯하지만 부적합한 작업을 거부하는 능력이다.

Anthropic의 광범위한 경제 연구는 사람들이 직업별 작업 전반에서 AI를 어떻게 사용하는지 반복적으로 살펴왔다. 코딩이 두드러지는 이유는 소프트웨어 작업이 실행, 테스트, 비교, 수정할 수 있는 결과물을 만들어내기 때문이다.

이 피드백 루프는 프로그래밍을 에이전트에 특히 잘 맞는 분야로 만든다. 모델은 변경을 생성하고, 컴파일러 오류를 관찰한 뒤, 사람이 모든 실패를 설명해주기를 기다리지 않고 다시 시도할 수 있다. 자동화된 테스트는 또 다른 즉각적 수정의 원천을 제공한다.

하지만 실행 가능한 피드백은 저장소가 검사할 수 있는 범위만 다룬다. 테스트 스위트가 통과했다고 해서 새 추상화가 아키텍처에 속한다는 사실이 증명되지는 않는다. 모든 보안 문제, 운영 비용, 혼란스러운 유지보수 경로를 드러내지도 않는다.

바로 이 지점에서 Willison의 주장은 단순히 코딩이 빨라졌다는 주장보다 더 중요한 의미를 갖는다. 에이전트는 이제 병목을 하류로 옮길 만큼 충분한 그럴듯한 소프트웨어를 생산할 수 있다. 검토, 아키텍처, 검증은 새로 늘어난 물량을 감당해야 한다.

압박을 받는 팀은 AI 도구를 거부하는 팀만이 아니다. 더 강한 통제 장치 없이 에이전트를 도입하는 조직도 자체적인 불리함에 직면한다. 확신을 쌓는 속도보다 더 빠르게 구현을 축적할 수 있기 때문이다.

이것이 Claude Code 생산성의 핵심 과제다. 이 도구는 한 개발자가 시도할 수 있는 범위를 넓힐 수 있지만, 그 산출물 중 얼마나 많은 부분이 오래가는 소프트웨어가 되는지는 주변의 엔지니어링 시스템이 결정한다.

개념적 일관성은 코드 생성으로 제거할 수 없는 제약이다

개념적 일관성이란 많은 기여자가 함께 구축하더라도 시스템의 각 부분이 하나의 일관된 설계를 따른다는 뜻이다.

Fred Brooks는 대규모 소프트웨어 프로젝트가 왜 어려워지는지 살피며 이 개념을 발전시켰다. 그의 고전적인 소프트웨어 엔지니어링 에세이에서 Brooks는 본질적 복잡성은 하나의 새로운 표기법, 언어, 도구만으로 제거할 수 없다고 주장했다.

코딩 에이전트는 프로그래밍의 우발적인 부분을 많이 개선한다. 보일러플레이트를 작성하고, API 간 변환을 수행하며, 정의를 찾고, 테스트를 생성하고, 반복적인 마이그레이션을 실행할 수 있다. 이러한 작업은 늘 새로운 아키텍처 아이디어를 요구하지 않으면서도 시간을 소모한다.

본질적 복잡성은 남는다. 누군가는 시스템이 무엇을 해야 하는지, 어떤 개념을 드러내야 하는지, 각 부분이 어떻게 관계를 맺어야 하는지를 결정해야 한다. 이러한 결정은 개발자와 사용자가 함께 지녀야 할 정신적 모델을 규정한다.

에이전트는 그 모델을 약화시키면서도 국소적으로는 타당해 보이는 코드를 만들 수 있다. 기존 개념에 두 번째 추상화를 만들거나, 두 모듈에서 같은 오류를 서로 다르게 처리하거나, 앞선 설계 선택과 충돌하는 의존성을 도입할 수 있다.

각 패치는 테스트를 통과할 수 있다. 그럼에도 시스템은 더 이해하기 어려워질 수 있다.

이 실패 방식은 에이전트의 속도가 빨라질수록 커진다. 불일치가 누적되기 때문이다. 중복 헬퍼 하나는 무해해 보인다. 하지만 여러 병렬 도메인 모델, 구성 경로, 재시도 메커니즘은 결국 모든 변경을 더 비싸게 만든다.

이 문제는 AI에만 국한되지 않는다. 대규모 인간 팀은 언제나 아키텍처 표류와 싸워왔다. 코딩 에이전트는 고위 검토자가 살피기 전에 저장소에 들어올 수 있는 구현 결정의 수를 늘린다.

이 때문에 개념적 일관성은 희소한 자원이 된다. 이는 명확한 소유권, 문서화된 불변 조건, 일관된 인터페이스, 그리고 과거의 선택이 왜 이뤄졌는지 이해하는 사람들에게 달려 있다. 토큰 출력이 늘어난다고 해서 이러한 자원이 자동으로 늘어나지는 않는다.

유용한 코드베이스는 에이전트가 같은 문제를 해결하는 유효한 방법의 수를 줄여준다. 확립된 패턴, 실행 가능한 테스트, 간결한 저장소 지침을 갖춘다. 모듈 경계는 단지 파일을 정리하는 데 그치지 않고 의도를 전달한다.

혼란스러운 코드베이스는 반대의 효과를 만든다. 에이전트는 여러 선례를 보고 프롬프트에 가장 가까워 보이는 것을 선택할 수 있다. 그 선택은 팀이 이미 제거하려 했던 우발적 패턴을 강화할 수 있다.

이런 역학은 숙련된 엔지니어에게 다른 종류의 영향력을 부여한다. 그들의 가치는 시스템을 정의하고, 모호성을 줄이며, 중요한 결정을 검토하는 쪽으로 옮겨간다. 이들은 에이전트가 작동하는 환경의 품질을 책임지게 된다.

같은 교훈은 프로젝트 지식에도 적용된다. 아키텍처 결정은 이슈 트래커, 설계 문서, 회의 메모, 코드 리뷰 토론에 흩어져 있는 경우가 많다. 검색 가능한 엔지니어링 지식 기반은 또 다른 구현 경로가 자리 잡기 전에 팀이 그 맥락을 되찾도록 도울 수 있다.

에이전트에는 여전히 정확한 지침이 필요하다. 지식 검색이 기술적 판단을 대체할 수는 없다. 하지만 새 패치가 저장소 밖에 숨겨진 결정을 무시할 가능성은 줄일 수 있다.

개념적 일관성은 Willison의 생산성 주장을 경영의 질문으로 바꾼다. 코드 생성 비용이 낮아진 뒤, 팀은 코드를 이해 가능하게 만드는 공유 모델을 어떻게 보존할 것인가?

진짜 상대는 이해 없는 처리량이다

더 큰 구현 역량은 인간의 이해, 자동화된 검사, 운영 피드백이 그 속도를 따라갈 때에만 가치를 만든다.

이것이 anthropic simon 논쟁의 핵심 충돌이다. 코딩 에이전트는 더 많은 변경을 생성할 수 있지만, 조직이 그 변경들을 하나의 일관된 시스템으로 평가할 수 있는 역량은 여전히 제한적이다.

리뷰는 명백한 병목 중 하나다. 큰 풀 리퀘스트는 누가 작성했든 이해하는 데 시간이 든다. 리뷰어가 테스트 통과만으로 충분한 근거가 된다고 가정하면 생성된 코드는 문제를 더 악화시킬 수 있다.

테스트는 필요하지만, 그 커버리지는 이전의 기대를 반영한다. 테스트는 이미 알려진 실패 모드를 탐지하는 데 가장 강하다. 패치가 잘못된 요구사항, 부적절한 의존성 또는 향후 변경을 어렵게 만드는 설계를 도입할 때는 취약하다.

보안 리뷰도 같은 비대칭성에 직면한다. 에이전트는 인증 로직, 데이터 처리, 네트워크 호출을 빠르게 추가할 수 있다. 반면 리뷰어는 이러한 요소들이 애플리케이션의 나머지 부분 및 위협 모델과 어떻게 상호작용하는지 검토해야 한다.

운영 환경은 또 다른 지연된 시험을 제공한다. 로컬 조건에서는 올바르게 동작하는 코드가 프로덕션 부하, 불완전한 데이터 또는 비정상적인 사용자 행동에서는 실패할 수 있다. 더 많은 릴리스는 학습을 가속할 수 있지만, 팀이 결과를 관찰하고 해석할 수 있을 때에만 그렇다.

따라서 에이전트의 가장 강력한 활용 사례는 피드백이 빠른, 범위가 제한된 작업에서 나타난다. 예로는 충분히 테스트된 API 클라이언트 업데이트, 반복적인 구성 변환, 이미 확립된 인터페이스 주변의 테스트 케이스 추가, 일회용 프로토타입 제작 등이 있다.

가장 취약한 사례는 문서화되지 않은 제품 판단이나 새로운 아키텍처 경계가 필요한 작업에서 나타난다. 에이전트는 여전히 답을 생성할 수 있다. 하지만 그 유창함은 그 답이 실제보다 더 확정된 것처럼 보이게 만들 수 있다.

연구 역시 자기 보고된 속도를 충분한 근거로 취급하지 말라고 경고한다. 2025년 무작위 연구인 developer productivity trial에서는 숙련된 오픈소스 개발자들이 속도 향상을 예상했음에도 AI 도구를 사용했을 때 선정된 작업을 더 느리게 완료한 것으로 나타났다.

이 결과가 Willison의 관찰을 무효화하는 것은 아니다. 이 연구는 특정 집단, 특정 저장소, 특정 세대의 도구, 특정 작업 선정 방식을 측정했다. 다만 생성된 산출물, 체감 속도, 완료된 작업이 서로 어긋날 수 있음을 보여 준다.

숙련된 메인테이너는 자신의 프로젝트에 대한 상세한 정신적 모델을 지니고 있다. 에이전트 산출물을 읽고 수정하는 비용이 익숙한 변경을 직접 작성하는 비용보다 더 클 수 있다. 덜 익숙한 작업에서는 저장소 탐색이 업무에서 차지하는 비중이 커지므로 다른 결과가 나올 수 있다.

따라서 팀은 최소한 네 가지 측정 항목을 분리해야 한다.

구현 처리량

완료된 패치, 변경된 줄 수 또는 전달된 작업 단위를 집계한다. 이 수치는 에이전트가 생산 역량을 확장했는지 보여 준다.

검증 부담

리뷰 시간, 테스트 실패, 보안 발견 사항, 수정 반복 횟수를 측정한다. 이 수치는 산출물을 신뢰하는 데 드는 비용을 보여 준다.

시스템 품질

인시던트, 유출된 결함, 롤백 비율, 유지보수 작업을 추적한다. 이러한 결과는 더 빠른 구현이 제품을 약화했는지 드러낸다.

사용자 가치

도입률, 작업 완료율, 유지율 또는 기타 제품별 결과를 측정한다. 이러한 신호는 추가된 소프트웨어가 실제로 의미가 있었는지 보여 준다.

코드 줄 수는 첫 번째 범주에 속한다. 조직이 이 측정치를 보편적인 생산성 점수로 격상할 때 문제가 시작된다.

이 구분은 관리자가 개인의 산출물을 해석하는 방식도 바꾼다. 대규모 에이전트 생성 패치를 감독한 엔지니어는 직접 작성한 코드가 거의 없어도 가치 있는 아키텍처 기여를 했을 수 있다. 반대로 다른 엔지니어는 훨씬 많은 코드를 작성하면서 수개월의 정리 작업을 만들 수 있다.

줄 수를 세면 공장의 변화를 드러낼 수 있다. 그러나 최고의 공장 관리자를 식별할 수는 없다.

숫자만으로는 여전히 증명할 수 없는 것

가장 강력한 회의론적 주장은 더 많은 코드량이 이전된 노동을 측정하면서 이전된 위험은 숨길 수 있다는 것이다.

에이전트는 타이핑, 저장소 검색, 초기 디버깅을 처리한다. 개발자는 결과를 이해할 책임을 물려받는다. 조직이 생성만 집계한다면 절감된 노동은 기록하지만, 추가된 검증 의무는 무시하게 된다.

이 문제는 코드가 그것을 만든 맥락보다 오래 살아남을 때 심각해진다. 원래 프롬프트가 남아 있지 않을 수 있다. 남아 있더라도 프롬프트에는 생성과 리뷰 과정에서 발견된 모든 절충안이 좀처럼 담기지 않는다.

그 후의 메인테이너는 일반적인 소스 코드를 마주한다. 그들은 코드의 가정을 추론하고, 의도적인 패턴과 모델의 습관을 구분하며, 안전하게 수정해야 한다. 이 비용은 생산성 대시보드가 최초의 병합을 축하한 지 수개월 뒤에 나타난다.

생성된 테스트도 비슷한 주의가 필요하다. 테스트는 커버리지를 개선하고 놓친 사례를 드러낼 수 있다. 그러나 구현의 가정을 재현해 잘못된 동작에 설득력 있는 자동화된 확인층을 제공할 수도 있다.

문서화도 같은 방식으로 실패할 수 있다. 에이전트는 코드가 현재 무엇을 하는지 설명하는 명확한 문서를 만들 수 있다. 하지만 그 설명이 동작이 원래 제품 요구사항과 일치한다는 사실을 입증하지는 않는다.

이 문제는 단순히 기술적인 문제가 아니라 인식론적인 문제다. 팀은 왜 변경이 올바르다고 믿는지 알아야 한다. 테스트가 같은 해석에서 생성되었다면 “에이전트가 생성했고 테스트가 통과했다”는 것은 처음 보이는 것보다 약한 근거다.

독립적인 검증이 도움이 된다. 사람은 구현 전에 인수 기준을 작성할 수 있다. 별도의 리뷰어는 스타일이 아니라 동작을 검토할 수 있다. 팀은 적대적 테스트를 위해 서로 다른 도구나 프롬프트를 사용할 수도 있지만, 두 번째 모델이 독립적인 권위는 아니라는 점을 기억해야 한다.

저장소 규모는 또 다른 불확실성을 더한다. 에이전트는 관련 맥락을 식별할 수 있을 때 인상적인 성과를 낸다. 필수 제약이 많은 서비스, 비공개 운영 지식 또는 충돌하는 역사적 관례에 걸쳐 있을 때 성능은 예측하기 어려워진다.

더 긴 컨텍스트 윈도우는 검색 마찰을 줄이지만, 어떤 정보가 우선되어야 하는지는 결정하지 않는다. 모델은 여러 설계 문서를 읽고도 어떤 결정이 여전히 권위를 갖는지 인식하지 못할 수 있다.

2025년 AI-assisted development report는 AI 도입을 더 큰 딜리버리 시스템 안에서 다룬다. 이것이 올바른 분석 수준이다. 도구 사용은 문서화 품질, 리뷰 관행, 플랫폼 엔지니어링, 조직의 신뢰와 상호작용한다.

성숙한 팀은 더 큰 구현 역량을 더 빠른 실험과 더 짧은 대기열로 전환할 수 있다. 미성숙한 팀은 같은 역량을 더 큰 풀 리퀘스트, 더 시끄러운 저장소, 지연된 실패로 전환할 수 있다.

이 때문에 AI 생산성에 관한 광범위한 주장은 검증하기 어렵다. 결과는 작업 유형, 개발자의 친숙도, 모델의 동작, 저장소의 건전성, 피드백 루프의 품질에 따라 달라진다.

Willison의 제안은 코드 줄 수에 모든 것을 증명하라고 요구하지 않기 때문에 이러한 비판을 견딘다. 이 지표에 한 가지 역사적 제약이 바뀌었음을 기록하라고 요청할 뿐이다.

위험은 고용주가 이 관찰을 해석하는 방식에 있다. 미묘한 엔지니어링 신호는 빠르게 할당량이 될 수 있다. 그렇게 되면 팀은 복잡성을 줄이는 대신 눈에 보이는 양을 생성할 유인을 받는다.

올바른 회의론적 결론은 코드량에 정보가 전혀 없다는 것이 아니다. 이 수치가 리뷰 비용, 시스템 결과, 개념적 완결성과 분리될 때 위험해진다는 것이다.

Anthropic Simon 논쟁 이후 주목할 점

다음 단계는 점점 더 극적인 코딩 시연이 아니라 저장소의 결과로 결정될 것이다.

첫 번째 신호는 독립적인 작업 단위 측정이다. 더 많은 통제 연구가 익숙한 저장소와 익숙하지 않은 저장소, 서로 다른 경험 수준, 여러 에이전트 워크플로를 비교해야 한다. 결과에는 작업 완료뿐 아니라 리뷰 시간과 결함도 포함되어야 한다.

그 연구들이 검증 비용 이후에도 지속적인 이득을 보여 준다면 Willison의 처리량 주장은 더 강해진다. 유지보수와 리뷰를 계산에 넣었을 때 이득이 사라진다면, 코드량은 이전된 작업에 더 가까워 보일 것이다.

두 번째 신호는 변경 규모와 아키텍처 집중도다. 팀은 에이전트 지원 개발이 작고 집중된 패치를 만드는지, 아니면 여러 하위 시스템에 걸친 광범위한 변경을 만드는지 살펴봐야 한다.

더 작은 패치는 개발자들이 명확한 경계 안에서 에이전트를 사용하고 있음을 시사한다. 더 큰 패치는 생성 역량이 조직의 일관된 설계 유지 능력을 앞지르고 있음을 나타낼 수 있다.

세 번째 신호는 장기적인 저장소 건전성이다. 유용한 지표에는 롤백 빈도, 중복된 추상화, 의존성 증가, 인시던트 비율, 이후 수정에 필요한 시간이 포함된다.

이 지표 전반의 개선은 더 많은 생성 코드가 개념적 완결성과 공존할 수 있음을 보여 줄 것이다. 악화는 에이전트가 팀이 진정으로 흡수할 수 있는 속도보다 더 빠르게 소프트웨어를 만들고 있다는 우려를 뒷받침할 것이다.

이러한 신호는 벤치마크 점수만으로는 알 수 없는 중요한 의미를 지닌다. 모델은 고립된 프로그래밍 문제 해결 능력은 향상될 수 있지만, 한 회사의 진화하는 아키텍처를 이해하는 능력까지 향상되는 것은 아니다.

개발자는 에이전트 산출물을 구현 제안으로 다뤄야 한다. 도구에 범위가 제한된 작업, 명시적인 제약, 신뢰할 수 있는 테스트를 제공해야 한다. 생성된 코드를 다듬기 전에 설계 결정을 검토해야 한다.

엔지니어링 리더는 단순한 산출량 할당량에 저항해야 한다. 변경된 줄 수를 새로운 역량의 한 지표로 측정할 수는 있지만, 검증 노력, 프로덕션 결과, 사용자 가치와 함께 봐야 한다.

엔지니어링 외의 지식 노동자도 관심을 가져야 한다. 소프트웨어는 내부 운영, 분석, 고객 경험을 점점 더 매개하고 있다. 더 저렴한 코드는 팀이 자동화할 수 있는 범위를 넓히는 동시에, 그들이 이해해야 할 시스템도 확대할 수 있다.

anthropic simon 논의는 결국 어느 한쪽의 증거도 부정하지 않으면서 AI 코딩을 새롭게 조명한다. 에이전트는 개인이 이전에 직접 타이핑하고, 테스트하고, 디버깅할 수 있었던 것보다 훨씬 많은 구현을 생성할 수 있다. 이는 실제 생산성의 변화다.

해결되지 않은 문제는 조직이 그 역량을 일관된 소프트웨어로 전환할 수 있는지다. 코드가 생성된 뒤에 무슨 일이 일어나는지 지켜봐야 한다. 누가 이를 리뷰하는지, 어떤 가정이 살아남는지, 그리고 다음 개발자도 여전히 시스템을 설명할 수 있는지 말이다.