Gemini 4 Argon 벤치마크, Google을 Claude와 GPT-6 뒤로 밀어
Google이 까다로운 Android 개발 작업에서 자사 모델이 Claude와 GPT-6에 뒤처진다는 Gemini 4 Argon 벤치마크 결과를 공개했다. 10월 26일 업데이트는 불편한 비교를 만들어낸다. Google 자체 평가에서 경쟁 시스템이 최신 모델보다 앞선 것으로 나타났기 때문이다.
이 결과가 중요한 이유는 AI 지원 Android 엔지니어링에 대한 Google의 평가인 Android Bench가 그럴듯한 코드를 제안하는 능력 이상을 시험하기 때문이다. 현재 리더보드는 상당한 규모의 개발 작업을 대상으로 모델과 에이전트 조합을 평가한다. 에이전트는 모델을 사용해 프로젝트를 살펴보고, 파일을 수정하며, 개발 도구를 실행하는 소프트웨어다.
다만 이 헤드라인에는 단서가 필요하다. 이 결과는 동일한 조건에서 개별 모델을 비교한 것이 아니라, 구성된 시스템을 비교한다. 또한 부분적인 진전과 완전히 통과한 솔루션을 구분한다. Google은 경쟁력 차이에 대한 증거를 공개했지만, 이 증거가 뒷받침하는 결론은 Gemini가 모든 Android 코딩에서 보편적으로 패한다는 주장보다 더 제한적이다.
개발자에게 당장의 질문은 위임과 관련된다. 어떤 시스템에 어려운 과제를 맡겨야 하며, 개발자는 얼마나 많은 미완성 작업을 떠안게 될까? Google이 직면한 압박은 더 구체적이다. 자체 점수판이 경쟁사를 우위에 둔다면, 왜 자사의 Android 개발 제품이 그 과제를 받을 가치가 있는지 설명해야 한다.
Gemini 4 Argon 벤치마크는 순위 정정과 함께 뚜렷한 격차를 보여준다
Google이 공개한 결과는 Argon이 경쟁 Claude 및 GPT 시스템 뒤에 있음을 보여주지만, 실시간 리더보드에서는 5위가 아니라 6위에 위치한다.
10월 26일 보도에서 9to5Google은 Argon을 5위로 설명했다. 해당 Android 코딩 보도는 더 넓은 경쟁 구도를 정확히 짚는다. Google의 항목은 Anthropic과 OpenAI의 최신 시스템에 뒤처진다. 다만 현재 표에서 또 다른 Claude 항목이 Argon 바로 위에 있으므로, 정확한 순위는 정정할 필요가 있다.
Google의 Android Bench 리더보드에서는 Claude Sonnet 5.5가 통과율 40%로 1위다. GPT 6.1 Sol은 29.3%를 기록했고, Gemini 4 Argon은 21.3%에 도달했다. 이들의 완료율은 각각 80.9%, 82.8%, 81.8%다.
구성도 서로 다르다. Sonnet은 최대 추론 노력 설정의 Claude Code를 통해 실행되고, GPT는 최대 노력 설정의 Codex를 통해, Argon은 높은 노력 설정의 Antigravity SDK를 통해 실행된다. 추론 노력은 모델의 숙고를 통제하는 구성 설정이다. 어떤 비교에서도 이 라벨은 함께 제시돼야 한다.
이러한 세부 사항은 결과를 보편적인 결론으로 만들지 않으면서도 유용하게 한다. 특정 시스템을 평가하는 팀에는 구체적인 출발점이 생긴다. 반면 모든 코딩 작업에서 브랜드를 비교하는 독자가 포괄적인 판정을 내릴 근거는 훨씬 약하다.
순위 정정이 Google의 문제를 없애지는 않는다. Argon을 5위에서 6위로 옮겨도 서수상 위치만 달라질 뿐, 여러 경쟁 시스템이 더 많은 벤치마크 작업을 성공적으로 마친다는 핵심 관찰은 유지된다.
완료 수치 역시 단순한 해석을 어렵게 한다. Argon의 부분 진전 점수는 언급된 경쟁사들의 점수에 가깝지만, 완전히 통과한 결과에서는 뒤처진다. 이 패턴은 모델이 상당한 양의 코드를 만들어낼 수 있는지와는 다른 질문을 제기한다.
개발자는 대규모 구현물을 받을 수 있지만, 그 결과가 신뢰할 만하다고 보장되지는 않는다. 남은 작업은 미묘한 결함을 찾거나, 누락된 요구사항을 충족하거나, 에이전트가 놓친 동작을 점검하는 일일 수 있다. 점수판만으로는 Argon 실패에서 어느 설명이 가장 큰 비중을 차지하는지 확정할 수 없다.
따라서 가장 타당한 해석은 구체적이다. Google이 시험한 Argon 구성은 완전한 작업 해결에서 선도적인 시험 대상 대안에 뒤처진다. 이는 모든 출력을 똑같이 약하다고 취급할 근거가 아니라, 실패 원인을 조사할 이유가 된다.
이는 경쟁 구도에 대한 대화도 바꾼다. Google에 필요한 것은 Argon이 Android 인터페이스를 생성할 수 있음을 다시 보여주는 일이 아니다. 구성된 시스템이 개발자의 신뢰를 정당화할 만큼 까다로운 과제를 안정적으로 마칠 수 있다는 증거가 필요하다.
Google은 Android 전문성을 완성된 작업으로 전환해야 한다는 압박에 직면해 있다
Google의 Android 지위는 기대를 만들지만, 플랫폼 소유권이 엔지니어링 벤치마크에서 우수한 성능을 입증하지는 않는다.
이 회사는 플랫폼과 개발 관행, 그리고 평가 자체를 정의하는 데 기여했다. 그래서 이 결과는 특히 눈에 띈다. 독자들은 자연스럽게 이러한 이점이 Android 개발자를 위한 강력한 지원으로 이어질 것으로 기대한다.
하지만 그 기대는 측정된 역량이라기보다 Google의 이점에 대한 추론이다. 코딩 시스템은 기존 프로젝트 안에서 지식을 적용하고, 제약을 준수하며, 실수에서 회복해야 한다. 플랫폼에 익숙하다고 해서 이런 조율 문제를 자동으로 해결하는 것은 아니다.
Google은 3월 원래 벤치마크 출시 발표에서 역량 격차를 파악하고 모델 선택을 개선하는 방법으로 이를 제시했다. 이 프레임은 지금 중요하다. 불리한 결과를 공개하는 일은 Google의 제품 서사를 복잡하게 만들더라도 벤치마크의 명시된 목적과 일치한다.
공개 자체를 Gemini에 가치가 부족하다는 인정으로 혼동해서는 안 된다. 평가는 제작자에게 계속 유용하면서도 약점을 드러낼 수 있다. 실제로 항상 발행사에 유리한 벤치마크는 다른 신뢰성 문제를 초래할 것이다.
실질적인 압박은 Argon을 둘러싼 제품 제공에 가해진다. Google이 개발자들에게 어려운 Android 과제를 위임받고자 한다면, 그 증거는 모델 역량을 신뢰할 만한 결과와 연결해야 한다. 통합의 편의성만으로는 성능 비교에 답할 수 없다.
엔지니어링 관리자에게 이는 정당화의 부담에 영향을 준다. 익숙한 공급업체를 선택하면 조달이나 관리가 간소화될 수 있지만, 그런 고려가 해당 코딩 시스템이 팀의 가장 어려운 작업을 처리하는지에 대한 답이 되지는 않는다. 기술적 선택에는 여전히 증거가 필요하다.
반대로 더 높은 순위의 경쟁사가 프로덕션 워크플로에 대한 무제한 접근 권한을 자동으로 얻는 것도 아니다. 팀은 여전히 리포지토리 권한, 검토 기대치, 위임하려는 변경의 종류를 살펴봐야 한다. 벤치마크 선도는 그 결정의 일부에만 답한다.
즉각적인 경쟁 효과는 하나의 가정을 약화시키는 데 있다. Google의 자체 모델이 Google의 모바일 플랫폼에서 당연한 선택일 것이라는 가정이다. Android 개발자들은 이제 플랫폼 특화 관점에서 대안을 시험할 이유를 갖게 됐다.
이는 고객 이탈을 예측하지 않아도 의미 있는 압박이다. उपलब्ध 증거는 도입 변화, 전환율, 사업상 결과를 입증하지 않는다. 다만 구매자가 기본 선택에 의문을 제기할 때 활용할 수 있는 공개 성능 비교를 제시한다.
Google의 가장 강력한 대응은 측정된 약점을 직접 다루는 일이다. 문서화된 변경 사항을 포함한 새로운 결과는 코딩 지능에 대한 일반적인 주장보다 더 많은 정보를 제공할 것이다. 개발자는 무엇이 개선됐는지, 어떤 조건에서 개선됐는지, 어떤 한계가 남았는지를 알아야 한다.
따라서 경쟁 과제는 운영상의 문제다. Google은 자사의 전문성이 설득력 있는 설명이나 상당한 패치에서 멈추지 않고 완성된 애플리케이션까지 이어진다는 점을 보여야 한다. 바로 그 지점에서 플랫폼 신뢰성이 개발자가 무엇을 위임할지 결정하는 데 유용한 증거가 된다.
부분적인 진전만으로는 부족한 영역에서 Claude와 GPT가 앞선다
경쟁상 차이는 시스템이 비슷한 수준의 중간 진전을 만들어내더라도, 완료된 과제와 관련된다.
완료 점수는 과제를 성공으로 선언하지 않으면서도 유용한 작업을 인정할 수 있다. 이 차이는 개발자가 거의 끝난 것처럼 보이는 구현을 넘겨받을 때 중요하다. 눈에 보이는 코드의 양이 남은 문제를 고치는 난이도를 결정하지는 않는다.
가상의 계정 생성 기능을 생각해 보자. 에이전트는 화면을 만들고, 탐색을 연결하며, 사용자 입력을 저장할 수 있다. 하지만 애플리케이션이 실패한 인증 단계를 잘못 처리한다면, 그 기능은 출시 전에 여전히 조사가 필요하다.
누락된 동작은 작은 패치만으로 해결될 수 있다. 그래도 이를 찾으려면 신중한 코드 읽기, 재현, 테스트가 필요할 수 있다. 그러므로 부분 완료와 사람의 노력은 별도로 다뤄야 하며, 어느 한쪽도 다른 쪽으로 기계적으로 환산되지 않는다.
Google의 9월 장기 과제 평가 업데이트는 더 까다로운 과제와 지속적인 채점을 도입한 이유를 설명한다. 장기 과제는 길고 상호 의존적인 단계를 포함하는 개발 작업이다. Google은 앱 생성, 마이그레이션, 기능 추가, 크로스 플랫폼 전환 같은 작업을 설명한다.
이 변화는 선도한다는 의미를 바꾼다. 국소적인 수정에서 뛰어난 시스템은 가치 있는 역량을 입증한 것이지만, 장기 엔지니어링 과제를 관리하는 것과는 다르다. 프로젝트 전반에서 의사결정을 일관되게 유지하는 일은 그 자체로 실패 가능성을 만든다.
Google의 상황이 역전된 지점은 이런 기회를 드러내도록 설계된 벤치마크가 이제 Argon보다 앞선 경쟁사를 부각한다는 데 있다. 이 결과는 지속적인 실행에 초점을 맞춘 시험으로 홈 플랫폼 우위에 대한 기대에 도전한다.
Claude의 선도 구성은 언급된 시스템 중 완전한 해결에서 가장 강력한 공개 결과를 제공한다. GPT의 구성도 또 다른 경쟁 기준점을 제시한다. 이들의 위치는 개발자에게 검토할 대안을 제공할 뿐, 출력을 검토할 필요가 없다고 가정할 근거는 아니다.
중요한 비교는 동등한 작업을 부여받은 시스템 사이에서 이뤄진다. 한 어시스턴트가 어려운 마이그레이션을 처리하고 다른 하나가 분리된 유틸리티 함수만 작성한다면, 겉으로 보이는 생산성은 의미 있는 순위를 뒷받침할 수 없다. 벤치마크는 공통 평가 환경을 정의함으로써 도움을 준다.
그렇다고 이 환경과 회사의 리포지토리 간 차이가 사라지는 것은 아니다. 팀의 의존성, 아키텍처, 승인 기준은 어떤 실패가 가장 중요한지를 바꿀 수 있다. 강력한 일반 결과가 특정 워크로드에 대한 부적합과 공존할 수도 있다.
이 때문에 Claude와 Gemini의 코딩 비교에는 명시적인 작업 범위가 필요하다. 완전한 벤치마크 과제에 대한 주장은 해당 벤치마크에 연결된 상태로 남아야 한다. 이를 설명, 작은 수정, 또는 모든 Android 프로젝트로 확장하려면 추가 증거가 필요하다.
GPT의 위치를 해석할 때도 같은 원칙이 적용된다. 선도자 아래의 순위가 부적합한 제품을 뜻하지는 않는다. 이는 공개된 구성에서 다른 관찰 결과를 나타내며, 팀은 그것이 자기 작업에 얼마나 관련 있는지 평가해야 한다.
Argon의 과제는 상당한 구현과 승인된 완료 사이의 거리를 좁히는 것이다. 이는 어떤 모델이 Android를 가장 잘 이해하는지에 관한 불명확한 논쟁에서 승리하려는 것보다 더 실행 가능한 목표다.
서로 다른 에이전트와 추론 설정이 모델에 대한 판정을 제한한다
Gemini 4 Argon 벤치마크는 배포된 조합을 비교하므로, 근본 모델만이 격차의 유일한 원인이라고 분리해낼 수 없다.
코딩 에이전트는 모델이 프로젝트와 상호작용하는 방식을 통제한다. 이를 둘러싼 소프트웨어는 도구가 어떻게 노출되는지, 어떤 컨텍스트가 계속 제공되는지, 실행이 어떻게 진행되는지를 결정한다. 이러한 구성의 변화는 개발자가 받는 결과에 영향을 줄 수 있다.
그 점은 시스템 비교를 상업적으로도 의미 있게 만든다. 개발자는 도구, 권한, 실행 방식이 포함된 제품을 사용한다. 대체로 그러한 주변 소프트웨어와 분리된 상태로 작동하는 모델을 접하지는 않는다.
그러나 상업적 관련성과 인과적 설명은 서로 다른 문제다. 어떤 구성이 더 나은 성과를 냈는지 안다고 해서, 왜 더 나았는지가 입증되는 것은 아니다. 모델, 에이전트, 추론 설정, 그리고 이들 사이의 상호작용은 여전히 가능한 기여 요인으로 남아 있다.
Google의 10월 벤치마크 변경 로그에는 새로운 Argon, Sonnet 5.5, GPT 6.1 Sol 결과와 함께 추론 노력 수준 레이블이 추가된 사실이 기록되어 있다. 보관된 항목도 기록되어 있다. 따라서 이 업데이트는 이용 가능한 비교 대상과 독자가 각 구성에 대해 받는 정보 모두를 바꾼다.
이 레이블은 투명성을 높이지만, 벤더 간 표준화된 측정을 만들어 주지는 않는다. “high”라는 설정을 다른 제공업체의 “max”와 자동으로 동등하다고 볼 수는 없다. 명칭은 구성을 식별할 뿐, 동일한 계산 조건을 증명하지는 않는다.
또한 다른 설정에서 Argon이 현재의 격차를 해소할 것이라고 가정하기에도 이르다. 이는 현재 순위가 뒷받침하는 설명이 아니라 검증 가능한 가능성이다. 다른 에이전트가 반드시 성과를 개선할 것이라는 주장에도 같은 주의가 적용된다.
더 강력한 인과 비교는 이러한 요소를 의도적으로 바꿔 가며 수행해야 한다. 모델을 고정한 채 에이전트를 변경하면 주변 소프트웨어를 검토하는 데 도움이 된다. 에이전트를 고정한 채 모델을 변경하면 다른 질문을 다루게 된다.
어느 접근법도 모든 비교를 완벽하게 통제된 상태로 만들지는 못한다. 제공업체별 인터페이스와 지원 기능은 다를 수 있다. 그럼에도 명시적인 실험 경계는 독자가 결과가 실제로 무엇을 분리해 측정하는지 이해하는 데 도움이 된다.
Google의 평가 방법론은 추가적인 한계를 제시한다. 비공개 데이터세트, 반복 실행, 자동화된 기능 점검, 모델 보조 시각 평가를 설명한다. 또한 리소스 총량은 조기에 실패하는 시스템에 유리하게 작용할 수 있다고 경고한다.
이러한 공개 내용은 결과를 일축하기보다 신중한 해석을 뒷받침한다. 비공개 작업 모음은 암기된 해법에 대한 노출을 줄일 수 있지만, 외부 재현은 더 어렵게 만든다. 자동화 평가는 규모 있는 평가를 가능하게 하지만, 그 점검이 의도한 작업과 부합하는지는 검토자가 판단해야 한다.
보고된 신뢰 구간도 서로 겹친다. 그렇다고 관찰된 순위가 사라지는 것은 아니지만, 고정된 성능 위계에 대한 확신은 제한된다. 독자는 표시된 결과와 향후 실행에서도 모든 순위가 유지되어야 한다는 주장를 구분해야 한다.
신중한 결론은 여전히 분명하다. Argon은 이 공개 비교에서 뒤처진다. 해결되지 않은 문제는 그 결과 중 얼마나 많은 부분이 모델, 구성, 에이전트 또는 평가의 특정 요구 사항에 기인하는가다.
Android 팀에는 앞으로 인수할 작업에 관한 증거가 필요하다
유용한 구매 결정은 에이전트가 변경 사항을 제출한 뒤 무슨 일이 일어나는지를 묻는다. 리더보드 순위에서 멈추지 않는다.
애플리케이션을 유지보수하는 팀에서 에이전트의 결과물은 다른 누군가의 책임이 된다. 검토자는 변경 사항을 수용하거나, 수정하거나, 거부할 수 있을 만큼 충분히 이해해야 한다. 이 인수 과정이 겉으로 보이는 진전이 활용 가능한 엔지니어링 작업이 되는지를 결정한다.
기존 애플리케이션 전반에 걸친 가상의 마이그레이션을 상상해 보자. 어시스턴트는 대상 코드를 업데이트하고 성공했다고 보고하지만, 검토자는 요청 범위 밖에서 변경된 동작을 발견한다. 이제 팀은 마이그레이션과 의도치 않은 영향 모두를 조사해야 한다.
이 부담은 원래 변경 사항을 수동으로 작성하는 것과 다르다. 완전하고 신뢰할 수 있는 구현을 받는 것과도 다르다. 벤치마크 결과는 후보를 식별하는 데 도움이 될 수 있지만, 인수하는 팀은 여전히 그 인수 과정을 측정해야 한다.
Android 코딩 순위는 더 정확한 질문을 유도할 때 가장 유용하다. 어떤 과제가 실패를 드러내는가? 시스템은 작업을 끝내지 못했을 때 이를 인식하는가? 검토자는 왜 파일을 변경했는지 또는 왜 특정 가정을 채택했는지 추적할 수 있는가?
이 질문들은 자신감 있는 요약이 불확실성을 감출 수 있기 때문에 중요하다. 개발자에게 필요한 것은 세련된 작업 설명이 아니라 무엇을 점검했는지에 대한 증거다. 그 증거의 품질은 독립적인 검증이 얼마나 더 필요한지에 영향을 준다.
관련 비교는 의도한 업무 분담에도 좌우된다. 범위가 제한된 변경에 AI를 사용하는 팀은 확장된 구현을 위임하는 팀과 기대치가 다르다. 후자 범주에서의 실망스러운 결과가 전자에서의 성능을 결론짓는 것은 아니다.
이 구분은 Argon의 벤치마크 열세를 무시하지 않으면서도 계속 유용할 여지를 준다. 팀은 실제로 맡길 작업을 기준으로 이를 평가할 수 있다. 익숙함이나 통합성을 그러한 평가의 대체물로 여겨서는 안 된다.
Claude와 GPT에도 비슷한 의무가 있다. 이들의 더 강한 공개 순위는 주목할 근거가 되지만, 현지 환경의 결과는 더 폭넓은 위임을 여전히 뒷받침해야 한다. 선도적인 벤치마크 항목이 낯선 저장소나 애플리케이션의 명시되지 않은 요구 사항을 보증할 수는 없다.
지식의 연속성도 이 평가의 일부가 된다. 프로젝트 결정, 이전 실패, 제약 조건은 겉보기에 합리적인 변경이 왜 부적절한지를 설명할 수 있다. 검토자가 그러한 맥락을 복원할 수 없다면 에이전트의 선택을 평가하기는 더 어려워진다.
이 문제를 해결하는 팀은 검색 가능한 지식 베이스를 사용해 기술 문서와 개발 결정을 정리할 수 있다. 이는 맥락에 대한 접근을 지원할 뿐, 실행 가능한 점검을 대체하거나 코딩 성능을 입증하지는 않는다.
비즈니스 측면의 함의는 유용성에 대한 더 넓은 정의다. 어시스턴트는 수용된 결과에 도달하는 데 필요한 총 노력을 줄일 때 신뢰를 얻는다. 생성된 코드, 설득력 있는 설명, 중간 진행 상황은 그 결과를 달성하는 데 도움이 되는 범위에서만 중요하다.
Google 비교는 상당한 진전과 완전한 성공을 구분하기 때문에 이 문제를 더욱 선명하게 만든다. 개발자는 이 경계를 면밀히 살펴봐야 한다. 매력적인 시연이 엔지니어링 약속이 되는 지점이며, 인수 팀이 남은 모든 것에 대한 책임을 떠안는 지점이기 때문이다.
Argon의 다음 결과, 구성 변경, 독립 테스트를 지켜보라
다음으로 의미 있는 증거는 Google이 명확히 문서화된 조건에서 완전한 작업 해결 능력을 개선할 수 있는지를 보여 줄 것이다.
첫 번째 신호는 유사한 작업에 대한 또 다른 Argon 평가다. 더 강한 결과는 Google이 측정된 약점을 해결하고 있다는 견해를 뒷받침할 것이다. 작업 모음이 바뀐다면, 누구든 원래 격차가 해소되었다고 주장하기 전에 새로운 비교가 필요하다.
리더보드는 여러 이유로 개선될 수 있으므로 이 구분은 중요하다. 새 모델의 성능이 더 좋을 수도 있고, 에이전트가 바뀔 수도 있으며, 평가가 발전할 수도 있다. 독자는 이러한 변화를 구분할 수 있을 만큼 충분한 문서가 필요하다.
설득력 있는 업데이트는 테스트한 버전을 식별하고 명확한 기준점을 유지해야 한다. 그러한 연속성이 없다면 높은 점수는 고무적일 수 있어도 해석하기는 여전히 어렵다. 핵심 질문은 더 보기 좋은 숫자 하나가 아니라, 비교 가능한 요구 조건에서의 개선이다.
두 번째 신호는 Argon의 에이전트 또는 추론 구성에 대한 문서화된 변경이다. 그러한 변경 후 더 나은 결과가 나온다면 주변 시스템이 격차에 기여했다는 주장이 더 강해질 것이다. 결과가 변하지 않는다면 그 설명의 설득력은 약해진다.
이는 경쟁 대응도 명확히 해 줄 것이다. Google은 여러 구성 요소를 통해 개발자 대상 제품을 개선할 수 있으며, 사용자는 결합된 결과의 혜택을 본다. 그러나 그 개선이 다른 개발 환경에도 이전되는지 판단할 때는 어떤 구성 요소가 개선되었는지를 식별하는 일이 중요하다.
경쟁사에도 같은 수준의 검토가 적용되어야 한다. 업데이트된 Claude 또는 GPT 구성은 관찰된 격차를 넓히거나, 좁히거나, 순위를 바꿀 수 있다. 변화하는 비교에서는 독자가 브랜드 수준의 인상에 의존하기보다 테스트된 시스템을 추적해야 한다.
세 번째 신호는 Google의 작업 모음 밖에 있는 Android 프로젝트에 대한 독립 평가다. 유사한 결과는 공개된 순위가 실무적 관련성을 지닌다는 근거를 강화할 것이다. 다른 결과는 벤치마크가 덜 유용한 지침을 제공하는 작업 부하를 식별하는 데 도움이 된다.
독립적인 증거는 과제와 수용 기준을 모두 설명해야 한다. 명확한 경계가 없는 성공 시연은 실패한 확장 작업과 비교하기 어렵다. 독자가 에이전트가 실제로 무엇을 완료해야 했는지 이해할 수 있을 때 보고서는 더 유용해진다.
특정 결과를 가정해서는 안 된다. 현재 결과는 Google이 격차를 해소할 것, 경쟁사가 위치를 유지할 것, 또는 개발자가 제품을 바꿀 것이라는 점을 입증하지 않는다. 이 결과는 더 잘 통제된 증거로 계속 지켜볼 가치가 있는 비교를 보여 준다.
Gemini 4 Argon 벤치마크는 현재 Google에 답해야 할 구체적인 성능 문제를 제시한다. 자체 평가는 완전한 해결 측면에서 경쟁 시스템에 우위를 부여하는 한편, 구성과 일반화에 관한 중요한 질문은 열어 둔다.
다음 코딩 에이전트 결정을 내리기 전에 위임하려는 과제와 이를 수용하는 데 필요한 증거를 식별하라. 해당 작업으로 후보를 비교하고, 테스트한 구성을 보존하며, 검토자가 제출 후 무엇을 인수하는지 살펴보라. 설득력 있는 시연이 기록을 지배하지 않도록 실패한 시도도 성공한 시도와 함께 보관하라. 중간 진전과 요구 사항을 충족하는 작업을 구분하고, 사람의 개입이 결과를 바꾸는 지점을 기록하라. 이러한 관찰은 향후 Android 코딩 순위를 더 쉽게 해석하게 해 줄 것이다. Google이 다음 Argon 결과를 발표하면, 변경 사항이 여러분의 저장소에서 중요한 실패를 해결하는지 물어보라. 업데이트된 시스템이 팀에 남는 미완료 작업을 줄이는가?
