K3가 언제든 출시될 수 있다는 소식에, 우리는 K3가 목표로 한다고 소문난 분야인 '장기적 관점의 에이전트 기반 코딩 (long horizon agentic coding)'에서 K2 라인업이 실제로 얼마나 개선되었는지 궁금해졌습니다. 하나의 프롬프트, 4개의 모델: K2 Thinking, K2.5, K2.6, K2.7 Code. 작업은 버그가 심어진 3개의 파일로 구성된 Python 미니 저장소(repo)입니다. 하나는 테스트가 잡아낼 수 있는 가변 기본 인자 (mutable default arg) 버그이고, 다른 하나는 어떤 테스트도 잡아내지 못하는 조용한 과도 삭제 (silent over-removal) 버그이며, 우리가 요청한 '실행 취소 (undo)' 기능은 모델이 가격 로그가 저장되지 않았음을 깨닫지 못하면 올바르게 구현하는 것이 불가능한 버그입니다. 모델들은 엄격한 STEP/TOOL/RESULT 프로토콜을 따라야 하며, pytest 출력을 정직하게 시뮬레이션해야 합니다. 정답(Ground truth): 원본 코드에서는 5개의 테스트 중 정확히 1개만 실패합니다. 우리는 이후 실제 인터프리터에서 모든 모델의 최종 코드를 검증했습니다. temp 1, top_p 0.95, 각 모델당 1회 실행, 재시도 없음. 네, n=5인 temp 0이 더 나았을 것이라는 점은 알고 있습니다.

K2 Thinking의 실행 결과는 솔직히 좀 가슴 아픕니다. 다른 어떤 모델도 잡지 못한 조용한 버그를 포함하여 세 가지 버그를 모두 찾아냈습니다. 그러고 나서 자신의 시뮬레이션된 테스트 실행에서 KeyError를 환각해냈고, 존재하지 않는 실패를 디버깅하느라 약 21k개의 추론(reasoning) 토큰을 낭비했습니다. 트레이스(trace)의 실제 인용구: "아이디어가 고갈되었습니다... 패배를 받아들여야 합니다". 최종 보고서에는 근본 원인을 알 수 없는 5개의 테스트가 FAIL로 나열되었습니다. 최고의 탐정이자 최악의 엔지니어입니다. K2.5는 실패하는 테스트를 만들어냈고(결과값이 9.0을 반환하는데 checkout이 8.0을 반환한다고 주장함), 세 번의 수정을 시도한 뒤, /100을 /100.0으로 바꾸는 아무런 효과 없는(no-op) 편집을 하고 나서 승리를 선언했으며, 보고서에 그 가상의 버그를 "수정됨"으로 나열했습니다. 결국 코드는 멀쩡했기에 상황이 더 우스꽝스럽게 느껴질 정도입니다.

K2.6은 우리가 요청하지 않았지만 존중할 만한 일을 해냈습니다. 삭제된 SKU (Stock Keeping Unit) 실행 취소 테스트를 가장 먼저 작성했고, 시뮬레이션에서 올바른 이유로 테스트가 실패하는 것을 지켜본 뒤, 설계를 수정했습니다. 우연한 TDD (Test-Driven Development)였습니다. K2.7의 코드는 그저 깔끔했습니다. 초기 테스트 상태를 정확하게 호출한 (실패 1회, 통과 4회) 유일한 모델이었습니다. 4번의 시뮬레이션 실행 동안 가짜 결과(fake results)가 0건이었습니다. 또한 undo_last를 작성하기 전에 로그 가격 문제를 수정했으며, 그 후 inventory.Add를 한 번 호출하는 방식으로 실행 취소를 구현하여 삭제된 SKU 케이스를 별도 처리 없이 해결했습니다. 63초가 걸렸습니다. 함정은 이것입니다: K2.7의 추론 과정을 보면 조용한 과다 삭제 버그 ("...대신 전체 항목을 삭제함... 아마 커버되지 않은 버그일 수도 있음")를 인지했음에도 불구하고... 그냥 보고하지 않았습니다. 테스트가 이를 커버하지 않았기에 신경 쓰지 않은 것입니다. 구형 사고 방식의 모델만이 테스트되지 않은 버그를 수정할 가치가 있는 것으로 취급한 유일한 모델이었습니다. 따라서 지난 12개월 동안: 유령 테스트 결과(phantom test results)는 급격히 감소하여 -> 2 -> 1 -> 0으로 이어졌으며, 이는 6배 더 빠르고 3.5배 더 저렴하며, 버그에 대한 호기심은 "눈에 보이는 모든 것을 수정하라"에서 "테스트를 만족시키고 나머지는 무시하라"로 좁혀졌습니다. 만약 K3에 대한 루머가 맞다면 (새로운 아키텍처, 긴 호흡의 에이전트), 이것이 바로 모델이 밀고 나가야 할 축입니다. 우리가 출시 첫날 실제로 알고 싶은 것은, K3가 K2.7의 '제로 팬텀(zero-phantom)' 규율을 유지하면서도, 테스트가 놓치는 버그를 표시하던 K2 Thinking의 습관을 되찾을 수 있느냐 하는 것입니다. 그 조합이 기본적으로 시니어 엔지니어의 모습입니다. K3가 공개되는 날 동일한 프롬프트를 실행하고 그 차이점(delta)을 게시하겠습니다. 프롬프트와 상세 결과는 첫 번째 댓글에 있으며, 내용은 길며 /u/qubridInc에 의해 제출되었습니다. [link] [comments]