프런티어 코딩 모델(frontier coding models)들에게는 마치 7월의 크리스마스 같습니다. 최근 AI 비용에 대한 논의가 많지만, 저는 지난 한 달 동안 기능 브랜치(feature branch)당 평균 비용을 줄이면서 코드 생산 속도를 수십 배(orders of magnitude) 높이는 데 성공했습니다. GLM-5.2 및 Kimi-k3와 같은 모델들이 큰 역할을 했지만, 이들은 속도 제한(rate-limited)이 더 심하기 때문에 추가적인 이득은 더 나은 자동화에서 얻었습니다. 이제 저는 에이전트(agent)를 옆에서 지켜보는(babysitting) 대신 코드 생성을 스케줄링합니다. 프롬프트를 계속 확인하거나, 저장소 컨벤션(repo conventions)을 적용하기 위해 에이전트에게 CONTRIBUTING 파일이나 최근 병합된 PR(Pull Request)을 확인하도록 유도하는 일을 더 이상 하지 않습니다. 그런 기능은 이미 내장되어 있습니다. Boris Cherny는 방금 AI 코딩에서 주의력(attention)의 병목 현상을 제거하는 방법에 대해 게시했습니다: https://x.com/bcherny/status/2077929390806073807 만약 그 에이전트가 주도적(proactive)이지 않다면, 그것은 그저 챗봇(chatbot)일 뿐입니다! 저는 오늘 어떤 저장소(repo)를 기반으로 빌드할지 이미 알고 있고, arXiv에서 새로운 내용을 확인하고, 코드와 라이선스를 찾고, 저장소를 스모크 테스트(smoke-test)하고, 해당 방법을 제 애플리케이션에 맞게 조정하며, PR을 다듬기 위해 제 조직의 컨벤션을 적용할 것이라는 점을 알고 있습니다. 저는 동기식 채팅(synchronous chats)에서 같은 말을 반복하며 갇혀 있지 않습니다. 저는 에이전트들을 오케스트레이션(orchestrate)하여 이 과정을 해결합니다. 그래서 저는 도구 및 워크플로 자동화(workflow automations)와 함께 GitHub Actions에서 Claude Code를 스케줄링함으로써 더 높은 처리량(throughput)을 보고 있습니다. 이것이 바로 우리가 Outrider를 구축하고 오픈 소스로 공개한 이유입니다: https://github.com/remyxai/outrider 제 주의력은 어떤 후보를 업스트림 PR(upstream PRs)로 승격시킬지 평가하거나 마지막 마무리를 하는 데 집중됩니다. 이를 '바이브 코딩(vibecoding)의 머니볼(moneyballing)'에 비유할 수 있습니다. AI는 arXiv에 발표되는 방대한 방법론의 홍수(firehose)를 필터링하여, 제 저장소 및 개발 이력과 대조하고, 그것이 제 애플리케이션의 어디에 적합한지 찾아내는 것을 돕습니다. arXiv와 함께하는 AI 채팅을 훨씬 뛰어넘어, 코딩 에이전트는 실제 코드를 기반으로 추천과 구현을 구체화하며, 검증(verification)과 테스트(testing)를 사용하여 어떤 제안을 검토를 위한 PR로 확대할지 결정합니다.

저의 실험들은 Boris가 설명하는 몇몇 신흥 관행(emerging practices)을 반영하고 있지만, 코드 자동화(code automation)의 설계 공간(design space)에 대해서는 배울 점이 많습니다. 어제 100개의 기능 브랜치(feature branch)를 여는 것이 멋지게 들릴 수도 있지만, 이는 우리가 코드에 기대하는 영향력에 대한 하나의 선행 지표(leading indicator)일 뿐입니다. 이 Outrider 기여분은 우리 모두가 사용하는 라이브러리로 업스트림(upstream)되는 중입니다: https://github.com/huggingface/peft/pull/3382 /u/remyxai 님이 제출함 [link] [comments]