Niklaus Harness Leaderboard, 브랜드 순위를 넘어 Kimi Code, Hermes, Pi, Claude Code, Codex를 테스트하다

Joël Niklaus는 28,849회의 시험에서 9개 코딩 에이전트 하니스를 비교하며, 모델 선택만으로 성능 문제가 해결된다는 생각에 이의를 제기했다. Niklaus harness leaderboard는 기반 모델과 추론 설정을 통제한 상태에서 모델의 작업을 지휘하는 소프트웨어를 평가한다. 초기 결과에서는 여러 잘 알려진 도구가 비슷한 정확도 범위에 위치했으며, 효율성과 반복 가능성의 차이로 인해 어느 하나를 승자로 단정하기 어려웠다.

비교 대상에는 Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code, OpenClaw가 포함된다. 하니스는 AI 모델의 지침, 도구, 실행 루프를 관리하는 소프트웨어다. 여기서는 그 주변 소프트웨어 자체가 검토 대상 변수가 된다.

핵심적인 긴장은 제품의 평판과 특정 테스트 구성에서 나타나는 동작 사이에 있다. 이 결과가 Claude Code나 Codex가 기본 모델과 함께 항상 더 우수하게 작동한다는 것을 입증하지는 않는다. 서로 다른 하니스가 통제된 조건에서 선택된 오픈 모델을 구동할 때 어떤 일이 벌어지는지를 살펴보며, 이는 더 좁은 질문이지만 개발자에게 실질적인 영향을 준다.

Niklaus Harness Leaderboard가 실제로 비교하는 것

이 실험은 모든 코딩 제품을 분리할 수 없는 하나의 패키지로 취급하는 대신, 이를 둘러싼 에이전트 소프트웨어를 분리해 평가한다.

Niklaus는 공개 설명에서 하니스만 바꾸고 모델, 제공업체, 추론 강도는 고정한다고 밝혔다. 각 작업에는 세 번의 시도가 주어진다. 초기 평가는 Terminal-Bench 2.1과 DeepSWE를 사용해 GLM-5.3-Flash, DeepSeek-V4.1-Flash, Flint를 대상으로 진행됐다.

이 설계는 일반적인 제품 비교가 여러 변수를 동시에 바꾸는 경우가 많기 때문에 중요하다. 개발자가 코딩 어시스턴트를 바꾸면 모델, 지침, 사용 가능한 도구, 권한, 실행 동작이 함께 달라질 수 있다. 그러면 성능 차이의 원인을 특정하기 어려워진다.

공개 설명에 따르면 mini-swe-agent는 세 모델 전반에서 평균 51.4%의 해결률을 기록했으며, OpenClaw는 27.3%였다. Niklaus는 다른 네 개 하니스도 선두 결과와 통계적으로 동률이라고 밝혔다. 이 수치는 영구적인 순위가 아니라 초기 공개 결과를 나타낸다.

모델별 결과는 이 전체 평균을 더 복잡하게 만든다. Niklaus에 따르면 GLM-5.3-Flash에서는 mini-swe-agent가, DeepSeek-V4.1-Flash에서는 Hermes Agent가, Flint에서는 Kimi Code가 선두를 차지했다. 따라서 순위는 개발자가 어떤 모델을 실행하려는지에 따라 달라진다.

즉각적인 시사점은 제한적이지만 중요하다. 한 모델에서 잘 작동하는 하니스가 다른 모델에서도 자동으로 같은 상대적 성능을 끌어내는 것은 아니다. 전체 점수는 후보를 찾는 데 도움이 될 수 있지만, 실제 배포에서 중요한 조합을 가릴 수도 있다.

Terminal-Bench는 소프트웨어가 명령을 실행하고 파일과 상호작용하는 터미널 환경에서 에이전트가 작업을 수행하도록 평가한다. DeepSWE는 별도의 소프트웨어 엔지니어링 평가를 제공한다. 두 가지를 함께 사용하면 비교 범위는 넓어지지만, 결과를 결합한다고 해서 작업 모음이 모든 개발 워크플로를 대표하게 되는 것은 아니다.

이 실험의 결론에는 날짜도 함께 붙여야 한다. 이 글을 위해 확인했을 때 라이브 애플리케이션에는 v0.1.2가 표시됐다. 현재 설명은 초기 공개 당시의 고정 제공업체 표현을 단순 반복하는 대신, 동등한 제공업체를 확인한다고 언급한다.

이 구분은 벤치마크가 최초 발표 이후 변할 수 있기 때문에 주목할 가치가 있다. 새로운 하니스 버전, 추가 시험, 수정된 통제 조건은 스크린샷의 의미를 바꿀 수 있다. 현재 보드가 다른 순서를 보여주더라도, 출시 수치는 출시 당시 구성에 대한 근거로 남는다.

원래 Reddit 토론을 접한 독자에게 가장 중요한 정정은 범위에 관한 것이다. 이것은 선택된 하니스와 모델 조합의 비교다. 나열된 제품명과 관련된 모든 기능, 구독 경험, 기본 구성을 포괄적으로 시험한 것은 아니다.

코딩 에이전트 공급업체, 전체 구성 설명 압박에 직면

이 결과는 에이전트 성능을 기반 모델에만 전적으로 귀속하는 주장에 압박을 가한다.

하니스 개발자에게 이 비교는 구현 선택을 더 분명하게 드러낸다. 지침, 도구 인터페이스, 재시도 동작, 종료 결정은 모두 모델이 수행하는 작업을 좌우한다. 강력한 모델도 이를 지휘하는 소프트웨어 때문에 마찰을 겪을 수 있다.

모델 제공업체에는 같은 실험이 귀속 문제를 제기한다. 특정 에이전트 안에서 나온 실망스러운 결과가 모델만이 유일한 원인임을 뜻하지는 않는다. 반대로 강한 결과 역시 해당 가중치를 사용하는 모든 애플리케이션이 이를 재현한다는 증거는 아니다.

엔터프라이즈 구매자에게 이는 의미 있는 평가가 무엇을 설명해야 하는지를 바꾼다. 구성 선택이 결과에 영향을 미칠 때 모델과 어시스턴트의 이름만으로는 충분하지 않다. 구매자는 테스트된 조합을 이해하고 자신의 작업과 관련된 동작을 재현할 수 있을 만큼의 정보가 필요하다.

가상의 유지보수 작업을 생각하면 이 구분이 구체적으로 드러난다. 에이전트는 저장소를 검사하고, 실패한 테스트를 식별하며, 함수를 수정하고, 변경 사항을 검증해야 할 수 있다. 각 단계는 하니스가 정보를 노출하고 작업 순서를 관리하는 방식에 좌우된다.

에이전트가 수정 후 관련 테스트를 실행하지 않고 멈춘다면, 그럴듯한 패치는 검증되지 않은 채 남는다. 비생산적인 명령을 계속 실행하면 완료는 더 느려지고 자원 집약도도 커진다. 기반 모델이 변하지 않아도 이는 운영상의 차이다.

그렇다고 특정 리더보드 결과를 어떤 구현이 초래했는지 입증되는 것은 아니다. 이를 확인하려면 실행 기록을 살펴보고 개입을 테스트해야 한다. 다만 통제된 비교가 모델 순위만으로 답할 수 없는 유용한 질문을 던지는 이유는 설명한다.

출시 결과는 익숙한 Claude Code vs Codex 논쟁에도 경계를 설정한다. 이 제품명은 흔히 특정 모델 계열을 중심으로 구축된 완전한 경험을 뜻한다. 선택된 오픈 모델로 이들의 하니스를 시험하는 것은 그러한 완전한 경험을 비교하는 것과는 다른 질문이다.

이 실험에서 낮은 순위가 제품의 기본 서비스가 부진하다는 뜻은 아니다. 높은 순위 역시 코드 검토, 대화형 협업, 조직별 워크플로에서의 우위를 입증하지 않는다. 그러한 주장은 해당 활동을 직접 측정하는 평가가 필요하다.

Kimi Code 벤치마크 결과에도 같은 한계가 적용된다. Flint에서 보고된 선두는 테스트된 조건에서 그 조합을 추가로 조사할 근거가 된다. 관련 없는 모델이나 저장소 전반에서 일반적인 우위를 확립하는 것은 아니다.

공급업체의 건설적인 대응은 구성을 공개하고 결과에 영향을 주는 변경 사항을 설명하는 것이다. 그러면 구매자는 모델 업그레이드와 하니스 개선을 구분할 수 있다. 성능 주장은 평가하기 쉬워지고 실패 원인은 조사하기 쉬워진다.

이 압박은 특히 교체 가능한 에이전트 소프트웨어를 통해 오픈 모델을 운영하는 팀에 중요하다. 이들의 구매 결정에는 실행 계층이 포함된다. 인지도 높은 제품명에만 의존하는 대신, 그 계층이 무엇을 기여하는지에 관한 근거가 필요하다.

비슷한 정확도는 서로 다른 운영 동작을 가릴 수 있다

근접한 정확도 결과에도 자원 사용량, 지연 시간, 일관성에서는 의미 있는 차이가 있을 수 있다.

현재 보드는 정확도를 완전한 답으로 제시하는 대신 여러 측정치를 구분한다. 평가 방법은 모델 사용량을 외부에서 측정하고, 모델 처리 시간과 에이전트 실행 시간을 구별한다고 설명한다. 이러한 구분은 비슷한 해결률이 왜 서로 다른 운영 경험으로 이어질 수 있는지 설명하는 데 도움이 된다.

보드는 정확도와 비용을 함께 표시하고, 표시된 두 측정치 모두에서 경쟁자에게 뒤지지 않는 선택지의 집합인 파레토 프런티어를 식별한다. 이를 통해 독자는 가장 높은 정확도가 항상 더 바람직하다고 가정하지 않고도 경쟁하는 장점을 살펴볼 수 있다.

이러한 관점은 조직에 고정된 작업량과 제한된 자원이 있을 때 중요하다. 최소한의 감독이 필요한 어려운 작업에서는 작은 정확도 우위도 가치가 있을 수 있다. 그러나 일상적인 유지보수 작업 전반에서 훨씬 더 많은 실행 시간을 요구한다면, 같은 우위의 매력은 낮아질 수 있다.

효율성 결과 역시 해석이 필요하다. 지출이 적다고 해서 에이전트가 반드시 더 효과적으로 추론한다는 뜻은 아니다. 더 적은 시도, 더 이른 종료, 더 짧은 출력, 또는 다른 도구 사용 패턴을 반영할 수 있다. 실행 기록은 생산적인 절제와 성급한 실패를 구분하는 데 도움이 된다.

마찬가지로 실행 시간이 길다고 해서 낭비가 입증되는 것은 아니다. 에이전트는 패치를 추가로 확인하거나 실패한 접근법에서 회복하기 위해 더 많은 노력을 들일 수 있다. 중요한 질문은 그 추가 작업이 팀이 실제로 가치 있게 여기는 결과를 개선하는지다.

그래서 시도당 자원 사용량과 성공 결과당 자원 사용량을 보고하는 것은 서로 다른 질문에 답한다. 저렴하지만 실패한 시도는 여전히 실패다. 사람이 복구하는 비용이 그렇지 않았다면 워크플로를 지배했을 상황에서는, 더 많은 자원을 요구하는 성공한 시도가 더 나은 선택일 수 있다.

이는 보드의 모든 하니스에 대해 확립된 설명이 아니라 평가 시 고려할 사항이다. 차트는 조사할 가치가 있는 패턴을 드러낼 수 있다. 그러나 그 패턴을 일으킨 지침이나 도구 동작을 차트만으로 식별할 수는 없다.

원리는 간단하다. 에이전트는 정보를 받고, 행동을 선택하며, 결과를 관찰하고, 다음에 무엇을 할지 결정한다. 하니스는 어떤 도구를 사용할 수 있는지, 그 응답이 어떻게 모델에 전달되는지를 포함해 이 루프의 중요한 부분을 통제한다.

환경 문제로 인해 빌드가 실패하는 가상의 저장소를 생각해 보자. 애플리케이션 코드를 반복해서 수정하는 에이전트는 원인을 해결하지 못한 채 자원을 소모할 수 있다. 다른 구성은 환경 문제를 인식하고 조사의 방향을 전환할 수 있다.

이 차이는 순수한 모델 지식이 아니라 작업 실행에 관한 것이다. 그러한 설명을 확립하려면 관찰된 동작과 결과를 연결해야 한다. 그 검토 없이 특정 하니스가 “더 똑똑하다”고 말하는 것은 근거를 넘어선다.

따라서 Niklaus harness leaderboard는 단일 승자라는 표현이 시사하는 것보다 더 구체적인 비교를 지원한다. 개발자는 자신의 작업량이 감당할 수 있는 방식으로 자원을 사용하면서 허용 가능한 정확도를 달성하는 조합이 무엇인지 물을 수 있다. 답은 대화형 개발과 무인 운영 사이에서 달라질 수 있다.

이는 Kimi Code 벤치마크 헤드라인을 읽는 방식도 바꾼다. 모델별 선두는 추가 평가를 위한 유용한 신호다. 실패한 시도, 실행 시간, 점수를 만들어 낸 동작에 관한 정보 없이는 여전히 불완전하다.

같은 이유로 Claude Code vs Codex 비교도 테스트된 맥락을 보존해야 한다. 이름은 방향을 제시하지만, 결과가 실제로 무엇을 설명하는지는 구성에 따라 결정된다.

반복 가능한 성공은 간헐적인 성공과 다른 결과다

간헐적으로 작업을 해결하는 에이전트는 일관되게 해결하는 에이전트와는 다른 배포 가능성을 제시한다.

Niklaus는 이후 반복 시도 전반의 신뢰성을 강조했다. 그의 신뢰성 분석에 따르면 mini-swe-agent는 시도당 평균 51.4%의 작업을 해결했다. 세 번의 시도에서 최소 한 번은 68.6%를 해결했지만, 모든 시도에서 해결한 비율은 33.0%였다.

이 수치는 서로 다른 운영상의 질문을 설명한다. 평균은 여러 시도에 걸친 성능을 포착한다. 최소 한 번의 성공은 반복 기회가 주어질 때 결국 해결책이 나오는지를 보여 준다. 매번 성공은 측정된 시도 내에서의 일관성을 나타낸다.

누군가 에이전트의 작업 과정을 지켜볼 때 이 구분은 중요해진다. 개발자는 실패한 시도를 검토하고, 지시를 변경하거나, 다시 실행할 가치가 있는지 판단할 수 있다. 사람의 감독은 간헐적인 성공도 유용하게 만들 수 있지만, 감독에 드는 시간 역시 워크플로의 일부로 남는다.

무인 프로세스는 다른 제약에 직면한다. 주변 시스템이 실제로 대안을 실행하고 그 품질을 판별하지 않는 한, 성공한 대체 시도가 존재한다고 가정할 수 없다. 반복 시도에는 선택 방법, 실행 예산, 그리고 해결되지 않은 실패를 처리하는 방식이 필요하다.

따라서 가끔 성공하는 점수는 일관성 측정을 대체하기에 부적절하다. 이는 특정 구성이 어떤 조건에서는 해결책에 도달할 수 있음을 보여 줄 수 있다. 그러나 해당 구성이 필요할 때마다 그 해결책을 신뢰성 있게 제공한다는 점까지 입증하지는 않는다.

Niklaus는 인용된 비교에서 다섯 개 하네스가 모든 시도에서 32.0%~33.3%의 작업을 해결했다고 보고했다. 그는 이 결과들이 우열을 가리기에는 지나치게 근소하다고 설명한다. 이는 선두 그룹 내에서 정밀한 승자 주장을 자제해야 한다는 근거가 된다.

신뢰성 수치에도 한계는 함께 명시되어야 한다. 세 번의 시도는 해당 실험 안에서의 반복 가능성에 관한 근거를 제공한다. 변화하는 리포지토리, 의존성, 권한, 사용자 지시 전반의 프로덕션 실패율을 확립하지는 않는다.

벤치마크에서의 실패가 곧바로 해로운 프로덕션 작업으로 이어지는 것도 아니다. 평가기는 작업이 성공 기준을 충족하는지 측정한다. 운영상 결과는 에이전트가 무엇에 접근할 수 있는지, 그리고 작업 주변에 어떤 승인 또는 검증 절차가 있는지에 달려 있다.

엔지니어링 관리자에게 시사하는 바는 역량과 신뢰할 수 있는 제공을 분리해야 한다는 것이다. 어떤 구성은 때때로 올바른 패치를 만들 만큼의 역량은 갖췄지만, 무인 워크플로에는 여전히 부적합할 수 있다. 이 간극에는 더 강한 마케팅 문구가 아니라 추가 검증이 필요하다.

가상의 의존성 업데이트는 이 차이를 잘 보여 준다. 에이전트는 한 번의 실행에서는 패키지를 성공적으로 업데이트하고 테스트를 통과시킬 수 있지만, 다른 실행에서는 관련 구성 변경을 놓칠 수 있다. 간헐적 성공은 헤드라인 수치가 암시하는 것보다 무인 운영 준비 상태를 훨씬 적게 입증한다.

그 워크플로를 평가하는 팀은 재현 가능한 완료와 명확한 실패 처리에 관심을 둘 것이다. 또한 결과 변경 사항을 검토자가 이해할 수 있는지도 중요하게 볼 것이다. 이러한 차원은 벤치마크 검증기가 최종 상태를 승인하는지 여부와는 별개다.

리더보드의 반복 시도 관점은 이 구분을 공개 비교로 끌어낸다. 독자들이 한 번의 성공 궤적을 제품의 완전한 설명으로 여기는 대신, 에이전트가 다시 작업해야 할 때 무엇이 일어나는지 묻게 한다.

벤치마크 버전과 공개 기록은 승자 주장에 한계를 둔다

공개된 결과는 검토 가능한 근거이지만, 벤치마크 버전과 구성, 그리고 검증의 완전성에 의해 제한된다.

Terminal-Bench 자체는 버전 레이블이 중요한 이유를 분명히 보여 주는 사례다. 2.1 개정판은 이전 판의 89개 작업 중 28개에서 문제를 수정했다. 유지관리자들은 이러한 수정 이후 대표적인 에이전트-모델 점수에 변화가 있었다고 보고했다.

이 이력은 벤치마크 버전이 주장 자체의 일부임을 의미한다. Terminal-Bench 2.0의 점수를 2.1의 점수와 단순히 상호 교환 가능한 것으로 취급할 수는 없다. 표시되는 지표의 이름이 같더라도 작업과 평가 조건은 달라졌다.

같은 원칙은 하네스에도 적용된다. 결과는 테스트된 소프트웨어 버전과 설정에 속한다. 업데이트가 지시, 도구 실행 또는 종료 동작을 바꾼다면, 이전 점수는 이전 구현을 설명한다.

이는 빠르게 변화하는 공개 논의에 과제를 만든다. 보드가 바뀐 뒤에도 차트는 계속 유통될 수 있고, 댓글은 그 차트를 현재 정보처럼 다룰 수 있다. 독자는 그 이미지가 여전히 무엇을 입증하는지 판단하기 위해 원래 구성과 측정 날짜를 알아야 한다.

프로젝트의 공개 실행 기록은 이러한 세부 사항을 확인할 경로를 제공한다. 기록의 공개는 투명성 측면의 장점이다. 그렇다고 모든 결과가 이미 독립적인 재현이나 완전한 수동 검토를 거쳤다는 뜻은 아니다.

독립 재현을 위해서는 명시된 구성을 실행하고 관련 패턴이 지속되는지 확인해야 한다. 기록을 읽는 일은 보고된 계산이나 개별 동작의 감사를 뒷받침할 수 있다. 이 활동들은 서로 다른 종류의 근거를 제공한다.

인과적 질문은 특히 까다롭다. 점수 차이는 통제된 조건에서 구성과 결과 사이의 연관성을 식별할 수 있다. 차이를 설명하려면 실패를 검토하고, 제안된 변경이 이를 바꾸는지 시험해야 한다.

예를 들어 타임아웃 문제가 의심된다면, 다른 관련 조건을 유지하면서 타임아웃을 바꿔 시험해야 한다. 정보 손실 문제가 의심된다면 어떤 정보가 사라졌는지 검토하고, 이를 보존하는 것이 결과를 개선하는지 확인해야 한다. 어느 설명도 낮은 순위만으로 자동으로 따라오지는 않는다.

벤치마크 친숙성은 부정행위를 가정하지 않고도 조사할 가치가 있는 또 다른 우려를 제기한다. 공개 작업에 맞춰 최적화된 시스템은 다른 곳에서 동일하게 개선되지 않아도 그 작업 분포에서는 성능을 높일 수 있다. 낯선 작업의 근거는 그 향상이 얼마나 폭넓게 이전되는지 확립하는 데 도움이 될 것이다.

작업 범위는 별도의 한계를 제시한다. 리포지토리 유지보수에는 고정된 벤치마크가 완전히 포착할 수 없는 조직 관례, 모호한 요청, 사람의 검토 기대치가 포함된다. 벤치마크는 이러한 배포 관련 질문을 미해결 상태로 남기면서도 여전히 유용할 수 있다.

실질적인 대응은 근거를 의사결정에 비례하게 유지하는 것이다. 공개 결과는 후보군 선정이나 표적화된 시험을 정당화할 수 있다. 팀의 개발 워크플로를 대체하려면 해당 팀의 실제 책임과 유사한 작업에서 나온 추가 근거가 필요하다.

구성, 실패 사례, 검토 결정을 함께 보관하면 이러한 비교를 더 쉽게 다시 검토할 수 있다. 검색 가능한 지식 베이스는 테스트 중 사용된 기술 문서와 함께 그러한 평가 이력을 보존하는 데 도움이 될 수 있다.

검증 격차가 실험의 가치를 없애는 것은 아니다. 이는 결과가 현재 뒷받침하는 내용과 이를 강화하기 위해 필요한 추가 작업을 규정한다. 이는 모든 순위를 문자 그대로 받아들이거나 비교 전체를 완전히 기각하는 것보다 더 유용한 해석이다.

다음 테스트는 업데이트, 재현, 무인 작업을 추적해야 한다

가장 강력한 후속 근거는 버전 변경을 초기 비교를 넘어선 작업에서 재현 가능한 개선과 연결할 것이다.

가장 먼저 지켜볼 신호는 명확한 버전 이력을 갖춘 업데이트된 하네스 성능이다. 개발자가 실행 소프트웨어를 변경할 때, 비교 가능한 재실행은 정확도, 효율성 또는 일관성이 변했는지를 보여 줄 수 있다. 이전 구성을 보존해야 이 비교가 의미를 갖는다.

반복 측정 전반의 개선은 하네스 엔지니어링이 결과에 실질적으로 영향을 미친다는 주장을 강화할 것이다. 비교 가능한 재실행에서 사라지는 결과는 주장된 향상에 대한 신뢰를 약화시킬 것이다. 어느 쪽 결과든 업데이트된 승자 배지보다 더 많은 정보를 제공한다.

이는 공급업체에도 건설적인 대응 방식을 제공한다. 이들은 실패 패턴을 식별하고, 관련 구현 변경을 설명하며, 결과에 관한 근거를 공개할 수 있다. 그러면 독자는 제품의 평판에서 품질을 추론하는 대신 구체적인 엔지니어링 주장을 평가할 수 있다.

두 번째 신호는 일치하는 통제를 갖춘 독립 재현이다. 별도의 평가자는 모델, 제공업체 조건, 추론 설정, 작업 버전, 하네스 버전을 문서화해야 한다. 차이는 겉보기에는 동일한 점수 안에 흡수되지 않고 계속 드러나야 한다.

독립 결과가 대략적인 순서나 모델별 패턴을 유지한다면 비교에 대한 신뢰는 높아진다. 결과가 갈린다면, 이는 더 면밀한 검토가 필요한 조건을 가리킨다. 제공업체 동작, 실행 설정, 측정 세부 사항은 편리한 설명이 아니라 연구 질문이 된다.

재현은 모든 수치가 정확히 일치할 것을 요구하지 않는다. 관련된 문제는 합리적인 반복 측정에서도 결론이 유지되는지다. 추가 근거가 이를 구별할 수 있음을 뒷받침하지 않는 한, 근소한 결과는 근소한 상태로 남아야 한다.

세 번째 신호는 명시적인 무인 성공 기준을 갖춘 낯선 작업에서의 성능이다. 이는 에이전트가 요청된 작업을 완료하고, 결과를 검증하며, 실패를 적절하게 처리하는지 확인하는 것을 뜻한다. 사람의 개입은 “자율적 완료”의 의미를 바꾸므로 기록되어야 한다.

그러한 작업에서의 일관된 개선은 리더보드 결과의 실질적 중요성을 강화할 것이다. 친숙한 벤치마크 작업에 국한된 향상은 그 관련성을 좁힐 것이다. 이 구분은 전체 평균의 또 다른 작은 움직임보다 배포에 더 중요하다.

지금 소프트웨어를 선택하는 팀에게 이 근거는 실제 조합 수준에서의 비교를 뒷받침한다. Kimi Code, Hermes Agent, Pi, Claude Code, Codex, mini-swe-agent는 팀이 사용하려는 구성에서 평가할 가치가 있다. 이름만으로 결과를 결정할 수는 없다.

Niklaus 하네스 리더보드는 출시 결과, 반복 시도, 접근 가능한 기록을 통해 이러한 평가의 공개 출발점을 제공한다. 그 지속적인 기여는 이 측정들이 에이전트 동작을 설명하고 개선하는 데 도움이 되는지에 달려 있다.

코딩 워크플로를 바꾸기 전에, 대표적인 유지보수 작업을 사용해 후보 조합을 이미 신뢰하는 설정과 비교하라. 정확한 구성, 완료 근거, 검토자 노력, 개입이 필요한 실패를 기록하라. 성공적인 검증 단계 없이는 그럴듯한 패치로 충분하지 않은 작업도 포함하라. 의미 있는 하네스 업데이트 후에는 이전 결과를 보존하면서 비교를 다시 수행해 변경 사항을 이해할 수 있도록 하라. 공개 보드를 그 의사결정을 위한 근거로 활용하되, 최종 판단은 자체 워크플로에 맡겨라. 답해야 할 질문은 구체적이다. 실제로 제공할 수 있는 감독 수준 안에서, 어떤 테스트된 조합이 팀이 검증하고 반복하며 수용할 수 있는 작업을 제공하는가?