나는 에이전트에게 큰 코드 블록 생성을 기대하지 않음
대신 로그를 훑거나 여러 소스 파일을 분석해 테스트 실패 원인을 설명하는 데 훨씬 유용함
이런 능력을 평가하는 디버깅 벤치마크가 필요하다고 생각함. 빌드 시스템이나 CLI 숙련도를 측정하는 테스트가 있으면 좋겠음
나도 동의함. 코드베이스 전체에 일관된 소규모 변경을 적용할 때 특히 유용함
예를 들어 앱 전체를 hard delete에서 soft delete로 리팩터링했는데, 삭제 로직과 쿼리 모두 수정해야 했음
수동으로 하면 지루하고 실수하기 쉬운데, 에이전트가 빠르게 처리해줘서 정말 고마웠음
이런 장기적 작업에는 SWE Bench Pro나 Terminal Bench 2가 적합함
SWE Bench Pro는 아직 과도하게 최적화되지 않아 신뢰할 만함
반면 일반 SWE나 LCB는 이미 수치 부풀리기 경쟁으로 실효성이 떨어짐
빌드 시스템 관련 테스트는 CompileBench(Quesma의 벤치마크)에서 다룸
참고로 나는 Quesma의 창립자임
나는 하루 종일 대규모 코드 생성만 함
이제는 회사든 사이드 프로젝트든 직접 코드를 거의 쓰지 않음
주로 Rust와 TypeScript로 개발자 도구를 만드는 일을 함
나도 환경 구성을 에이전트에게 맡김 kubectl / helm으로 배포하고 문제 발생 시 에이전트가 직접 디버깅함
몇 시간 걸리던 일이 순식간에 끝나서 놀라울 정도임
개발자들에게 MiniMax, Kimi 같은 모델을 실제 업무에 써보라고 권하고 싶음
하지만 단점도 빠르게 드러남 — 추론 토큰 사용량 증가, 느린 출력, 품질 저하 등
그래도 모델 라우팅과 reasoning budget을 잘 관리하면 비용을 크게 절약할 수 있음
앱과 프롬프트를 최적화해 출력 토큰을 줄이는 것도 중요함
나도 Kimi로 괜찮은 결과를 얻고 있음
하지만 어려운 작업에서는 단순한 토큰 단가보다 효율이 더 중요함
링크에 나온 접근법은 Sonnet과 Opus에도 효과가 있음
다만 MiniMax나 Qwen은 아직 그 수준에 미치지 못함
결국 어떤 작업에 어떤 모델이 비용 효율적인지 구분하는 하네스 설계가 핵심임
나는 SOTA 이하 모델은 쓰지 않음
Opus 4.6 medium을 써봤다가 바로 후회했음. 품질 차이가 너무 큼
나는 MiniMax를 매일 코딩용으로 사용함
토큰 사용량은 신경 안 씀, 월 10유로 요금제에서 5시간마다 1500회 요청 가능함
실제로는 Opus나 Sonnet보다 느리지 않음
벤치마크에서는 Anthropic 모델이 더 좋아 보이지만, 현실 작업에서는 차이가 거의 없음
MiniMax가 막히면 Opus로 전환하고, 다시 MiniMax로 돌아오면 됨
Opus는 예산을 빨리 소모하지만 MiniMax는 사실상 무제한임
Kimi는 최근 내 디버깅용 주력 모델임
Claude나 GPT보다 문제를 더 빨리 찾아냄
하지만 문맥 일관성 문제가 심각함 — 코드 재작성 시 작은 오차가 생겨 전체를 망칠 수 있음
지금은 가격 경쟁의 끝없는 레이스임
DeepSeek이 단일 실행 기준으로 모든 모델을 이기고, 비용도 로컬 전력의 절반 수준임
DeepSeek에도 이 접근법을 적용할 수 있음
여러 해답을 생성하고, 작은 모델로 유망한 후보를 선택해 테스트 후 피드백을 반복하는 방식임
일종의 유전 알고리즘처럼 점진적으로 수렴함
“전기요금보다 싸다”는 게 무슨 뜻인지 설명해줄 수 있음?
작은 모델들은 테스트에 맞춰 과도하게 미세조정되어 실제 환경에서는 성능이 형편없음
나는 항상 회의적임
벤치마크는 통과하지만 실제로는 범용성이 떨어지는 경우가 많음
그래도 모델을 슬림화하려는 시도 자체는 흥미로움
언어와 분야에 따라 차이가 큼
시스템 프로그래밍(C++, Rust)에서는 여전히 Sonnet 4.5 수준과 큰 격차가 있음
오픈모델들은 구문 오류 해결에 너무 많은 시간을 쓰고, 논리적 일관성을 잃는 경우가 많음
로컬 GPU를 충분히 갖고 있지만, 클라우드 모델의 라이선스 문제도 걱정됨
ATLAS의 접근법은 꽤 영리함
여러 솔루션을 생성하고, 각 코드의 임베딩 지문(fingerprint) 을 계산해 정확도를 예측함
작은 신경망인 Cost Field가 이를 점수화해 가장 가능성 높은 코드를 선택함
덕분에 테스트 시간을 줄이면서도 88% 정확도로 올바른 해답을 고름
모델을 줄이면 각 뉴런이 여러 역할을 맡게 되어 일반화 능력이 떨어짐
오히려 큰 모델이 구조적으로 단순할 수 있음
읽는 사이에 GPU 가격이 $1000이 되어버렸음
이 AI가 작성한 프로젝트는 LiveCodeBench와 완전히 다른 방식으로 자체 벤치마크를 돌림
README에는 ATLAS 점수가 599개 LCB 작업을 기반으로 한 V3 파이프라인(best-of-3 + Lens + iterative repair) 결과라고 명시되어 있음
반면 경쟁 모델 점수는 단일 실행(pass@1) 기준이라 비교가 불공정함
Sonnet이나 GPT5.4도 같은 방식으로 테스트하면 더 높은 점수를 낼 수 있음
README에는 실제로 사용되지 않는 구조들이 많아 AI 자동 생성 코드의 허술함이 드러남
이런 벤치마크가 문제 전용 최적화에만 효과적인지 궁금함
결국 우리는 일반성을 압축할 수 없는 한계를 배우게 될 것임
“Geometric Lens routing”이란 표현이 너무 이상함
그냥 GPT가 만들어낸 용어처럼 들림
회의적이긴 하지만 이런 오픈모델 실험은 정말 반가움
중상급 PC에서도 로컬로 모델을 돌릴 수 있다면 큰 진전임
Hacker News 의견들
나는 에이전트에게 큰 코드 블록 생성을 기대하지 않음
대신 로그를 훑거나 여러 소스 파일을 분석해 테스트 실패 원인을 설명하는 데 훨씬 유용함
이런 능력을 평가하는 디버깅 벤치마크가 필요하다고 생각함. 빌드 시스템이나 CLI 숙련도를 측정하는 테스트가 있으면 좋겠음
예를 들어 앱 전체를 hard delete에서 soft delete로 리팩터링했는데, 삭제 로직과 쿼리 모두 수정해야 했음
수동으로 하면 지루하고 실수하기 쉬운데, 에이전트가 빠르게 처리해줘서 정말 고마웠음
SWE Bench Pro는 아직 과도하게 최적화되지 않아 신뢰할 만함
반면 일반 SWE나 LCB는 이미 수치 부풀리기 경쟁으로 실효성이 떨어짐
참고로 나는 Quesma의 창립자임
이제는 회사든 사이드 프로젝트든 직접 코드를 거의 쓰지 않음
주로 Rust와 TypeScript로 개발자 도구를 만드는 일을 함
kubectl / helm으로 배포하고 문제 발생 시 에이전트가 직접 디버깅함
몇 시간 걸리던 일이 순식간에 끝나서 놀라울 정도임
개발자들에게 MiniMax, Kimi 같은 모델을 실제 업무에 써보라고 권하고 싶음
하지만 단점도 빠르게 드러남 — 추론 토큰 사용량 증가, 느린 출력, 품질 저하 등
그래도 모델 라우팅과 reasoning budget을 잘 관리하면 비용을 크게 절약할 수 있음
앱과 프롬프트를 최적화해 출력 토큰을 줄이는 것도 중요함
하지만 어려운 작업에서는 단순한 토큰 단가보다 효율이 더 중요함
링크에 나온 접근법은 Sonnet과 Opus에도 효과가 있음
다만 MiniMax나 Qwen은 아직 그 수준에 미치지 못함
결국 어떤 작업에 어떤 모델이 비용 효율적인지 구분하는 하네스 설계가 핵심임
Opus 4.6 medium을 써봤다가 바로 후회했음. 품질 차이가 너무 큼
aibenchy 비교 결과
토큰 사용량은 신경 안 씀, 월 10유로 요금제에서 5시간마다 1500회 요청 가능함
실제로는 Opus나 Sonnet보다 느리지 않음
벤치마크에서는 Anthropic 모델이 더 좋아 보이지만, 현실 작업에서는 차이가 거의 없음
MiniMax가 막히면 Opus로 전환하고, 다시 MiniMax로 돌아오면 됨
Opus는 예산을 빨리 소모하지만 MiniMax는 사실상 무제한임
Claude나 GPT보다 문제를 더 빨리 찾아냄
하지만 문맥 일관성 문제가 심각함 — 코드 재작성 시 작은 오차가 생겨 전체를 망칠 수 있음
지금은 가격 경쟁의 끝없는 레이스임
DeepSeek이 단일 실행 기준으로 모든 모델을 이기고, 비용도 로컬 전력의 절반 수준임
여러 해답을 생성하고, 작은 모델로 유망한 후보를 선택해 테스트 후 피드백을 반복하는 방식임
일종의 유전 알고리즘처럼 점진적으로 수렴함
작은 모델들은 테스트에 맞춰 과도하게 미세조정되어 실제 환경에서는 성능이 형편없음
나는 항상 회의적임
벤치마크는 통과하지만 실제로는 범용성이 떨어지는 경우가 많음
그래도 모델을 슬림화하려는 시도 자체는 흥미로움
시스템 프로그래밍(C++, Rust)에서는 여전히 Sonnet 4.5 수준과 큰 격차가 있음
오픈모델들은 구문 오류 해결에 너무 많은 시간을 쓰고, 논리적 일관성을 잃는 경우가 많음
로컬 GPU를 충분히 갖고 있지만, 클라우드 모델의 라이선스 문제도 걱정됨
여러 솔루션을 생성하고, 각 코드의 임베딩 지문(fingerprint) 을 계산해 정확도를 예측함
작은 신경망인 Cost Field가 이를 점수화해 가장 가능성 높은 코드를 선택함
덕분에 테스트 시간을 줄이면서도 88% 정확도로 올바른 해답을 고름
오히려 큰 모델이 구조적으로 단순할 수 있음
읽는 사이에 GPU 가격이 $1000이 되어버렸음
이 AI가 작성한 프로젝트는 LiveCodeBench와 완전히 다른 방식으로 자체 벤치마크를 돌림
README에는 ATLAS 점수가 599개 LCB 작업을 기반으로 한 V3 파이프라인(best-of-3 + Lens + iterative repair) 결과라고 명시되어 있음
반면 경쟁 모델 점수는 단일 실행(pass@1) 기준이라 비교가 불공정함
Sonnet이나 GPT5.4도 같은 방식으로 테스트하면 더 높은 점수를 낼 수 있음
README에는 실제로 사용되지 않는 구조들이 많아 AI 자동 생성 코드의 허술함이 드러남
이런 벤치마크가 문제 전용 최적화에만 효과적인지 궁금함
결국 우리는 일반성을 압축할 수 없는 한계를 배우게 될 것임
“Geometric Lens routing”이란 표현이 너무 이상함
그냥 GPT가 만들어낸 용어처럼 들림
회의적이긴 하지만 이런 오픈모델 실험은 정말 반가움
중상급 PC에서도 로컬로 모델을 돌릴 수 있다면 큰 진전임