Dirac에서 흥미로웠던 건 이런 부분들임 Hash-Anchored edits의 최적화 버전으로 파일을 편집하고, 언어의 AST를 써서 어떤 코드를 컨텍스트에 넣을지 결정하니 큰 코드 파일 전체를 읽지 않게 됨
작업은 전부 배치로 묶어서 대량의 읽기/수정을 동시에 처리하고, 모델이 필요하면 bash/python/perl 스크립트를 직접 실행해 즉석 분석도 하게 함
또 컨텍스트를 꽤 세심하게 관리해서, 다음에 모델이 거의 확실히 요청할 정보는 미리 넣어두는 식으로 업데이트함
왜 AST가 코드 편집이나 변경 범위 추론에 더 널리 쓰이지 않는지 늘 궁금했음
예전에 어떤 글에서는 grep도 비슷하게 효과적이라고 했고, 그 맥락에서는 그 말도 어느 정도 납득되긴 했음
앵커 기반 편집은 새 앵커를 컨텍스트에 주입해야 하고 Dirac도 diff로 그렇게 처리하던데, 그러면 토큰 기준으로 search and replace보다 정말 더 효율적인지 잘 모르겠음
해시가 토큰 하나여도 그렇고, 코드는 쓰기보다 읽기가 더 많아서 누적 비용도 커짐
예전에 더 긴 stable anchors로 실험했을 때도 오히려 퇴보처럼 느껴졌고, Dirac의 효율은 기본적으로 파일 스켈레톤만 보여주는 데서 더 많이 오는 듯함
Batches all operations가 뭔지 몰라서 소스를 봤는데, 모델이 병렬 툴 호출을 잘 해주길 기대하는 대신 tool API 자체가 여러 대상을 리스트로 받게 설계돼 있다는 뜻으로 보였음
내 경험상도 모델은 대량의 병렬 호출을 한꺼번에 잘 안 하려 하고, 특히 약한 모델일수록 그 경향이 더 강함
SOTA 모델에 토큰을 태우기보다 파일 편집 전용의 매우 싼 특화 모델을 쓰는 쪽이 낫지 않나 싶음
상위 모델은 더 저렴한 편집 모델을 만들어 호출만 하게 하는 방식도 가능해 보임
언어의 AST로 가져올 컨텍스트를 정한다면, 결국 파서가 있는 언어에서만 동작하는 구조인지 궁금함
AI harness가 성능에 얼마나 큰 영향을 주는지 정말 흥미로움
Google 공식 결과의 48%에서 65%로 올라간 건 엄청 큰 차이인데, 모델 비교는 많이 봐도 같은 모델로 harness만 비교한 결과는 거의 못 봄
같은 모델 기준으로 harness 성능을 비교하는 리더보드가 있는지 궁금함
아마 model+harness의 데카르트 곱 전체를 비교해야 할 듯함
가장 많이 인용되는 건 terminal bench 2.0인데, 여기도 cheating 의혹과 benchmaxxing 문제를 피하진 못함
꽤 놀랍게도 Opus 4.6에서 Claude Code가 꼴찌인데, 이게 Claude Code의 한계일 수도 있고 벤치마크 자체가 말해주는 바일 수도 있음
미래는 인간형의 중앙집중 지능이 아니라, 문어형 분산 지능에 더 가까울 수도 있겠다는 생각도 듦
그러면 핵심은 모델보다 harness 자체를 더 똑똑하게 만드는 쪽이 됨
그게 결국 terminal-bench가 하는 일 아닌가 싶기도 함
지난 몇 달간 같은 로컬 모델로 직접 테스트해보니, 내 환경에서는 Claude Code가 OpenCode보다 확실히 낫고 OpenCode가 Codex보다 나았음
벤치마크라면 최소한 다른 계열 모델 하나는 더 넣어봐야 일반화되는지 알 수 있음
비용을 생각하면 Minimax 2.7이 괜찮아 보이고, 그 전까지는 Gemini 3 Flash에 과적합된 결과인지 판단하기 어려움
랜딩 페이지에도 현재 숫자가 전부 Gemini 3 Flash 기반이라는 걸 분명히 적어야 하고, 더 저렴한 게 같은 모델 기준으로 더 빠른 뜻이라면 완료 시간도 벤치마크에 넣는 편이 좋겠음
아울러 skills, 중첩 AGENTS.md, MCP 지원 여부도 이주를 검토하는 사람에겐 중요함
Minimax 2.7로 직접 돌려봤는데 편집 툴을 꽤 싫어했고, 금방 sed로 파일을 수정하는 쪽으로 무너졌음
모델이 임의의 도구에 완벽히 일반화되지 않고, 특히 파일 편집처럼 흔한 작업은 학습 데이터에 있던 도구 편향을 타는 게 자연스러워 보임
그런 면에서 Gemini 계열은 에이전트 작업에서 대체로 덜 강해서, 오히려 특정 도구 편향이 덜할 수도 있겠음
아직 직접 써보진 않았지만, 굳이 새 harness를 통째로 만들지 말고 pi에 확장으로 얹는 쪽은 왜 선택하지 않았는지 궁금함
내가 본 pi의 extension API는 꽤 넓고, Hash anchored edits 같은 것도 충분히 구현 가능해 보였음
프로젝트를 공개해줘서 고맙고 나중에 직접 살펴볼 생각임
몇 달 전 어느 오후에 Cline이 너무 느려서 답답했고, 내부를 들여다보다가 몇 군데 고치기 시작했음
그러다 점점 빨려 들어가서 변경 7만 줄, 삭제 4만 줄쯤 쌓인 뒤 두 달 지나 지금 상태가 됨
요즘 local LLM과 새 harness들을 보고 있는데, Pi가 OpenCode보다 실제로 얼마나 나은지 궁금함
최대로 활용하려면 어떤 모델과 커스터마이징 조합이 좋은지도 알고 싶음
코드를 보다가 telemetry가 https://dirac.run/v1/event로 전송되는 걸 발견했음
노골적으로 민감한 정보를 보내는 것 같진 않고 악의적으로 보이진 않지만, API 에러도 보내고 있어서 경우에 따라 민감한 내용이 새어 나갈 여지는 있음
게다가 1인 개발자가 운영하는 엔드포인트로 opt-out 방식인 건 꽤 무섭게 느껴져서, 개인적으로는 이 지점 때문에 못 쓰겠음
확인한 telemetry는 이 정도였음 dirac.run/v1/event로 machine ID, 토큰 사용량, 모델 정보, 이벤트, 에러 앞 500자, 플랫폼 정보를 보냄 dirac.run/v1/event/decide에서 기능 플래그를 60분마다 machine ID와 함께 조회하고, 이건 telemetry opt-out과 무관하게 항상 켜져 있으며 코드 수정 없이는 끌 수 없음
웹 검색/웹 fetch 도구는 api.dirac.run을 경유해서 요청 내용과 시스템 헤더를 보냄
모델 목록도 Anthropic provider를 쓰더라도 OpenRouter, HuggingFace, Groq 등에 조회를 날림
고마움
이건 Cline 포크라 telemetry 메커니즘을 그대로 물려받은 부분이고, 디버깅에 도움이 될까 해서 남겨둔 것뿐임
악의적인 목적은 전혀 없고 PII를 생성하거나 저장하지도 않음
harness가 얼마나 중요한지가 핵심 포인트고, 이건 오래 남을 해석이라고 봄
모델은 빌려 쓸 수 있고 프롬프트도 비슷하게 복제 가능하지만, 벤치 숫자의 상당 부분은 그 주변의 harness가 결정함
같은 harness 아래서 Gemini를 Sonnet으로 바꾸는 변화보다, 같은 모델에서 harness를 바꾸는 변화가 더 클 수 있음
네가 링크한 cheating-agents 글도 결국 같은 얘기고, 실제로 측정되는 건 harness이며 모델은 그 바탕 재료에 가까움
다만 context management는 보편적 성질이라기보다 현재 세대 모델의 약점을 메우는 성격이 강해서, 몇 세대 지나면 도구가 질문 임베딩 기반 RAG를 밀어낸 것처럼 사라질 수도 있음
그래서 ARC-AGI-3는 harness 사용을 허용하지 않음
모델이 직접 harness를 만들어야 하게 해둠
축하함, 정말 잘 만든 듯함
지난 몇 주 동안 내 쪽에서도 harness를 만드는 일이 가장 재밌는 사이드 프로젝트였고, 늘 마무리는 못 하지만 특히 두 가지 경험이 궁금함 컨텍스트 관리에서는 오래된 tool call 응답 가지치기, 출력 잘라내기, 자동 compaction이 꽤 잘 먹혔고, 모든 걸 기억하는 이득보다 컨텍스트를 줄이는 이득이 더 컸음
대신 짧은 요약은 항상 남겨둠
또 subagents 쪽은 메인 에이전트에 도구를 거의 노출하지 않고 run_agent 하나만 주며, 하위 에이전트가 search/execute/fetch를 쓰게 하는 식으로 실험 중임
하위 에이전트가 간결한 요약만 돌려주면 상위 컨텍스트가 오래 깨끗하게 유지될 거라 보는데, 아직 프롬프트 설계는 더 실험 중임
고마움 API 캐싱을 지원한다면 pruning은 웬만하면 건드리지 않는 편이 낫고, prune 한 번 할 때마다 캐시가 깨져서 90% 할인 캐싱 이점을 날리게 됨 subagent는 Cline 기능을 개선한 걸 Dirac도 이어받았지만, 모델마다 위임 학습이 잘 안 돼서 편차가 큼
특히 하위 에이전트가 루프에 빠지거나 반환하지 않을 때를 대비해, 메인 에이전트가 통제할 메커니즘은 꼭 필요함
이건 정말 흥미롭고, 내가 harness를 만들며 겪은 경험과도 잘 맞아떨어짐
같은 모델로도 아직 상당한 상방이 남아 있다고 봄
작년에는 Anthropic이 새 모델이 나올수록 harness가 도구를 두른 단순한 while loop에 가까워진다는 서사를 밀었는데, 지금은 오히려 반대로 가는 느낌임
harness 쪽에서 탐색할 게 너무 많고, 내 작업에서는 rolling context window가 compaction보다 훨씬 강력했음
여기에 지속적인 상위 요약과 자세한 자동 피드백 파이프라인까지 붙이면 더 좋아지는데, 물론 이건 에이전트 목표가 명확하고 일관될수록 구현이 쉬워짐
Kimi 2.6과 Dirac으로 Rust 코드베이스를 리팩터링하고 있음 Clean Architecture를 더 강화하는 방향이고, 작업 범위는 Beads epic과 하위 이슈로 정리해뒀음
계획은 gpt5.5로 세웠고 완료 검증도 gpt5.5가 맡고 있음
대규모 코드베이스 리팩터링에서는 Dirac이 OpenCode보다 생산적이었고, OpenCode는 .rs 파일을 망가뜨려서 되돌려야 했음
Hacker News 의견들
Dirac에서 흥미로웠던 건 이런 부분들임
Hash-Anchored edits의 최적화 버전으로 파일을 편집하고, 언어의 AST를 써서 어떤 코드를 컨텍스트에 넣을지 결정하니 큰 코드 파일 전체를 읽지 않게 됨
작업은 전부 배치로 묶어서 대량의 읽기/수정을 동시에 처리하고, 모델이 필요하면 bash/python/perl 스크립트를 직접 실행해 즉석 분석도 하게 함
또 컨텍스트를 꽤 세심하게 관리해서, 다음에 모델이 거의 확실히 요청할 정보는 미리 넣어두는 식으로 업데이트함
예전에 어떤 글에서는
grep도 비슷하게 효과적이라고 했고, 그 맥락에서는 그 말도 어느 정도 납득되긴 했음해시가 토큰 하나여도 그렇고, 코드는 쓰기보다 읽기가 더 많아서 누적 비용도 커짐
예전에 더 긴 stable anchors로 실험했을 때도 오히려 퇴보처럼 느껴졌고, Dirac의 효율은 기본적으로 파일 스켈레톤만 보여주는 데서 더 많이 오는 듯함
Batches all operations가 뭔지 몰라서 소스를 봤는데, 모델이 병렬 툴 호출을 잘 해주길 기대하는 대신 tool API 자체가 여러 대상을 리스트로 받게 설계돼 있다는 뜻으로 보였음내 경험상도 모델은 대량의 병렬 호출을 한꺼번에 잘 안 하려 하고, 특히 약한 모델일수록 그 경향이 더 강함
상위 모델은 더 저렴한 편집 모델을 만들어 호출만 하게 하는 방식도 가능해 보임
AI harness가 성능에 얼마나 큰 영향을 주는지 정말 흥미로움
Google 공식 결과의 48%에서 65%로 올라간 건 엄청 큰 차이인데, 모델 비교는 많이 봐도 같은 모델로 harness만 비교한 결과는 거의 못 봄
같은 모델 기준으로 harness 성능을 비교하는 리더보드가 있는지 궁금함
꽤 놀랍게도 Opus 4.6에서 Claude Code가 꼴찌인데, 이게 Claude Code의 한계일 수도 있고 벤치마크 자체가 말해주는 바일 수도 있음
그러면 핵심은 모델보다 harness 자체를 더 똑똑하게 만드는 쪽이 됨
벤치마크라면 최소한 다른 계열 모델 하나는 더 넣어봐야 일반화되는지 알 수 있음
비용을 생각하면 Minimax 2.7이 괜찮아 보이고, 그 전까지는 Gemini 3 Flash에 과적합된 결과인지 판단하기 어려움
랜딩 페이지에도 현재 숫자가 전부 Gemini 3 Flash 기반이라는 걸 분명히 적어야 하고, 더 저렴한 게 같은 모델 기준으로 더 빠른 뜻이라면 완료 시간도 벤치마크에 넣는 편이 좋겠음
아울러 skills, 중첩 AGENTS.md, MCP 지원 여부도 이주를 검토하는 사람에겐 중요함
sed로 파일을 수정하는 쪽으로 무너졌음모델이 임의의 도구에 완벽히 일반화되지 않고, 특히 파일 편집처럼 흔한 작업은 학습 데이터에 있던 도구 편향을 타는 게 자연스러워 보임
그런 면에서 Gemini 계열은 에이전트 작업에서 대체로 덜 강해서, 오히려 특정 도구 편향이 덜할 수도 있겠음
open-weights 모델 벤치마크도 시도했지만 추론이 느려서 계속 timeout에 걸렸고, terminal bench는 타임아웃을 수정할 수 없었음
관련 불만은 여기에도 적어둠 https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
Gemini 표기는 GitHub README에 반영했고, 평균 완료 시간은 더 짧았지만 출력 속도가 랜덤하게 느려질 때가 있어 엄밀한 벤치마크로 넣진 않았음
skills / AGENTS.md / MCP 정보도 추가해둠
아직 직접 써보진 않았지만, 굳이 새 harness를 통째로 만들지 말고 pi에 확장으로 얹는 쪽은 왜 선택하지 않았는지 궁금함
내가 본 pi의 extension API는 꽤 넓고, Hash anchored edits 같은 것도 충분히 구현 가능해 보였음
프로젝트를 공개해줘서 고맙고 나중에 직접 살펴볼 생각임
그러다 점점 빨려 들어가서 변경 7만 줄, 삭제 4만 줄쯤 쌓인 뒤 두 달 지나 지금 상태가 됨
최대로 활용하려면 어떤 모델과 커스터마이징 조합이 좋은지도 알고 싶음
코드를 보다가 telemetry가 https://dirac.run/v1/event로 전송되는 걸 발견했음
노골적으로 민감한 정보를 보내는 것 같진 않고 악의적으로 보이진 않지만, API 에러도 보내고 있어서 경우에 따라 민감한 내용이 새어 나갈 여지는 있음
게다가 1인 개발자가 운영하는 엔드포인트로 opt-out 방식인 건 꽤 무섭게 느껴져서, 개인적으로는 이 지점 때문에 못 쓰겠음
dirac.run/v1/event로 machine ID, 토큰 사용량, 모델 정보, 이벤트, 에러 앞 500자, 플랫폼 정보를 보냄dirac.run/v1/event/decide에서 기능 플래그를 60분마다 machine ID와 함께 조회하고, 이건 telemetry opt-out과 무관하게 항상 켜져 있으며 코드 수정 없이는 끌 수 없음웹 검색/웹 fetch 도구는 api.dirac.run을 경유해서 요청 내용과 시스템 헤더를 보냄
모델 목록도 Anthropic provider를 쓰더라도 OpenRouter, HuggingFace, Groq 등에 조회를 날림
이건 Cline 포크라 telemetry 메커니즘을 그대로 물려받은 부분이고, 디버깅에 도움이 될까 해서 남겨둔 것뿐임
악의적인 목적은 전혀 없고 PII를 생성하거나 저장하지도 않음
harness가 얼마나 중요한지가 핵심 포인트고, 이건 오래 남을 해석이라고 봄
모델은 빌려 쓸 수 있고 프롬프트도 비슷하게 복제 가능하지만, 벤치 숫자의 상당 부분은 그 주변의 harness가 결정함
같은 harness 아래서 Gemini를 Sonnet으로 바꾸는 변화보다, 같은 모델에서 harness를 바꾸는 변화가 더 클 수 있음
네가 링크한 cheating-agents 글도 결국 같은 얘기고, 실제로 측정되는 건 harness이며 모델은 그 바탕 재료에 가까움
다만 context management는 보편적 성질이라기보다 현재 세대 모델의 약점을 메우는 성격이 강해서, 몇 세대 지나면 도구가 질문 임베딩 기반 RAG를 밀어낸 것처럼 사라질 수도 있음
모델이 직접 harness를 만들어야 하게 해둠
축하함, 정말 잘 만든 듯함
지난 몇 주 동안 내 쪽에서도 harness를 만드는 일이 가장 재밌는 사이드 프로젝트였고, 늘 마무리는 못 하지만 특히 두 가지 경험이 궁금함
컨텍스트 관리에서는 오래된 tool call 응답 가지치기, 출력 잘라내기, 자동 compaction이 꽤 잘 먹혔고, 모든 걸 기억하는 이득보다 컨텍스트를 줄이는 이득이 더 컸음
대신 짧은 요약은 항상 남겨둠
또 subagents 쪽은 메인 에이전트에 도구를 거의 노출하지 않고
run_agent하나만 주며, 하위 에이전트가 search/execute/fetch를 쓰게 하는 식으로 실험 중임하위 에이전트가 간결한 요약만 돌려주면 상위 컨텍스트가 오래 깨끗하게 유지될 거라 보는데, 아직 프롬프트 설계는 더 실험 중임
API 캐싱을 지원한다면 pruning은 웬만하면 건드리지 않는 편이 낫고, prune 한 번 할 때마다 캐시가 깨져서 90% 할인 캐싱 이점을 날리게 됨
subagent는 Cline 기능을 개선한 걸 Dirac도 이어받았지만, 모델마다 위임 학습이 잘 안 돼서 편차가 큼
특히 하위 에이전트가 루프에 빠지거나 반환하지 않을 때를 대비해, 메인 에이전트가 통제할 메커니즘은 꼭 필요함
이건 정말 흥미롭고, 내가 harness를 만들며 겪은 경험과도 잘 맞아떨어짐
같은 모델로도 아직 상당한 상방이 남아 있다고 봄
작년에는 Anthropic이 새 모델이 나올수록 harness가 도구를 두른 단순한 while loop에 가까워진다는 서사를 밀었는데, 지금은 오히려 반대로 가는 느낌임
harness 쪽에서 탐색할 게 너무 많고, 내 작업에서는 rolling context window가 compaction보다 훨씬 강력했음
여기에 지속적인 상위 요약과 자세한 자동 피드백 파이프라인까지 붙이면 더 좋아지는데, 물론 이건 에이전트 목표가 명확하고 일관될수록 구현이 쉬워짐
특히 harness 포인트가 흥미로웠음
크레딧이 거의 바닥날 때 더 작은 모델로 내리고 프롬프트를 더 구조화하면, 종종 gpt-5.4-mini가 감에 맡긴 gpt-5.4보다 더 잘할 때도 있었음
그래서 좋은 에이전트 워크플로 아이디어를 작고 검사 가능하며 설치 가능한 skills로 옮기는
skill distillery를 시작했음 https://github.com/ouatu-ro/skill-distillery첫 번째는 Dirac의 구조적 코드 워크플로를 바탕으로 한
dirac-workflow인데, Dirac 복제본은 아니고 런타임이나 영속 AST 인덱스, hash-anchor 편집 엔진, 벤치 harness는 없음대신 작은 AST 헬퍼와 워크플로 규율만 이식 가능한 skill로 담았고, Dirac 저장소 자체에 적용해본 짧은 보고서도 넣어둠
원저자 입장에서 프롬프트와 도구가 대표성이 있는지 피드백을 받고 싶음
https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py
Kimi 2.6과 Dirac으로 Rust 코드베이스를 리팩터링하고 있음
Clean Architecture를 더 강화하는 방향이고, 작업 범위는 Beads epic과 하위 이슈로 정리해뒀음
계획은 gpt5.5로 세웠고 완료 검증도 gpt5.5가 맡고 있음
대규모 코드베이스 리팩터링에서는 Dirac이 OpenCode보다 생산적이었고, OpenCode는
.rs파일을 망가뜨려서 되돌려야 했음