"AI code is slop" has a problem: test262, html5lib-tests and Microsoft's own shader compiler disagree
Alera, 오픈소스 라이브러리 개발서 사람 개입 메시지 112건에서 11건으로 줄여
Alera의 에이전트 공장은 네 차례의 오픈소스 라이브러리 개발에서 사람의 개입 메시지를 112건에서 11건으로 줄였다고 보고합니다. 외부 테스트와 퍼징, 기존 구현과의 성능 비교도 함께 공개했지만, 수치 일부는 에이전트 측 측정이며 네 프로젝트만으로 일반적인 AI 코드 품질을 단정할 수는 없습니다.
- 주제
에디터 노트
외부 테스트와 비교 결과를 공개하고 패배한 항목까지 적은 점은 단순한 데모보다 검증 가능한 근거를 제공합니다. 다만 이 보고서가 직접 다루는 결과는 네 라이브러리이며, 일부 수치는 에이전트 측 기록입니다. 메시지 감소도 사람의 총 작업 시간이 같은 비율로 줄었다는 뜻은 아닙니다. Reddit 상단 댓글은 test262와 DXC 등 이 글의 네 사례에 없는 추가 프로젝트 수치를 내놓습니다. 이를 보고서의 측정 결과와 합쳐 읽으면 안 됩니다. 반대로 공개 테스트가 구현의 악의적 조작이나 내부 구조의 품질까지 증명하지 못한다는 반론도 타당한 한계 지적입니다. 댓글의 코드 검토 주장은 독립 감사 결과가 아니므로, 현재 자료가 뒷받침하는 결론은 정해진 외부 검증에서 성과를 보인 구현이 있다는 데까지입니다.
AI 요약
Alera의 라이브러리 공장은 기존에 알려진 종류의 라이브러리를 지정된 언어로 새로 구현해 GitHub에 공개하는 에이전트 시스템입니다. 기획자, 프로젝트 관리자, 빌드 오케스트레이터, 엔지니어와 독립 리뷰어를 두고, 기본 라이브러리 외 의존성을 금지하며 외부 테스트와 기존 구현 비교, 퍼징으로 결과를 검증합니다. 보고서는 2026년 9월 26일부터 10월 23일까지 진행한 oneyaml-rust, oneyaml-go와 oneyaml-csharp, oneimage-csharp, onepdf-csharp 네 차례를 다룹니다.
사람의 개입과 개발 주기
각 프로젝트의 첫 메시지부터 1.0 공개까지 작성자가 보낸 메시지는 각각 112건, 108건, 14건, 11건으로 줄었습니다. 마지막 두 프로젝트는 각각 22시간 56분, 17시간 27분 만에 1.0 태그에 도달했습니다. 다만 메시지 수는 작업량 전체가 아닙니다. 한 글자 답변과 긴 리뷰가 모두 한 건으로 계산되고, 에이전트가 작성한 내용을 읽는 시간도 포함하지 않습니다. 작성자는 대화 기록에서 다른 에이전트 메시지와 플랫폼 알림 등을 제외해 본인 메시지를 추정했으며, 플랫폼이 발신자를 직접 기록하지 않는다고 설명합니다.
초기에는 작성자가 직접 상태를 확인하고 에이전트의 설계 질문에 답했습니다. 이후 에이전트가 인계와 컨텍스트 한도 관리를 맡도록 절차를 손봤고, oneimage-csharp부터는 프로젝트 관리자 에이전트가 기획자의 설계 질문에 대신 답했습니다. 그 인터뷰의 결정 기록에는 누가 답했는지도 표시했습니다. 한 차례 개발이 끝날 때마다 에이전트 실행을 검토해 절차와 프롬프트를 고쳤습니다. 첫 YAML 구현 뒤에는 테스트 실행을 기다리는 시간이 많다는 분석에 따라 테스트와 승인 절차를 조정했습니다. 작성자는 에이전트에게 지시를 많이 추가할수록 유연한 에이전트가 잘못하는 일도 늘어난다는 원칙을 세웠습니다.
외부 검증과 한계
oneyaml-rust는 공식 yaml-test-suite 402개를 모두 통과했고, oneyaml-go는 681개 중 680개, oneyaml-csharp는 681개 중 680개를 통과했습니다. oneimage-csharp는 JPEG 디코딩 결과를 libjpeg-turbo와 비트 단위로 대조했고, ImageSharp보다 29개 작업 중 27개에서 빨랐다고 보고했습니다. onepdf-csharp는 공개 문서 코퍼스 세 종류에서 충돌이나 멈춤이 없었고, PdfPig보다 17개 성능 비교 항목에서 빨랐다는 결과를 제시했습니다. 각 프로젝트는 퍼징 결과와 성능상 열세 항목도 공개했습니다.
다만 프로젝트별 검증 수준과 자료 출처는 같지 않습니다. onepdf-csharp 수치는 보고서 작성자가 다시 실행한 결과가 아니라 저장소의 README와 결정 기록에 실린 에이전트 측 측정입니다. YAML 구현에도 테스트 통과만으로 드러나지 않는 차이가 남았습니다. 예를 들어 oneyaml-go의 일반 값 형식은 태그를 버리고, oneyaml-csharp는 1.0에서 기존 구현보다 느린 항목이 34개였습니다. 보고서도 서로 다른 종류의 라이브러리를 직접 비교하지 않으며, 네 번의 실행만으로 공장 방식의 성과를 일반화하지 않습니다.
Reddit 반응
- @ai-tacocat-ia — 자바스크립트 인터프리터, HTML 파서, HLSL 셰이더 컴파일러 등 C# 라이브러리 11개를 만들었다고 주장합니다. test262 99.55%, html5lib-tests 100%, DXC와 GPU 테스트 330개 결과 일치 등 외부 검증 수치를 들며, 코드 작성은 AI가 했지만 평가는 자체 테스트가 아니라고 말합니다.
- @sane_finale — 테스트가 학습 데이터에 들어 있었을 가능성을 제기해도 html5lib-tests와 DXC 비교 결과는 의미가 있다고 봅니다. 특히 셰이더 컴파일러의 속도 비교를 언급합니다.
- @Fit_Advisor8847 — 작은 모델에서도 반복 작업을 하고 사람이 결정을 먼저 내리면 결과가 좋아졌다고 말합니다. 모델에 많은 결정을 맡기면 도구 호출 실패와 반복 루프, 조잡한 결과가 나타났다는 경험을 덧붙입니다.
- @Isogash — 공개 테스트 통과만으로 구현의 견고함을 입증하기 어렵고, 테스트를 통과하도록 결과를 꾸미는 구현 사례도 있다고 반박합니다. 구성 요소별 검증과 구조가 필요하다고 주장하며, 저장소 코드를 살펴본 뒤 구조가 좋지 않다고 평가합니다.
- @Comprehensive-Pin667 — 기존 구현을 바탕으로 만든 결과라면 처음부터 새로 만든 것이라는 표현에 의문을 제기합니다. 다른 댓글에서는 OnePDF의 폰트 코드가 FreeType 계열 구현에 영향을 받았다는 분석을 제시하면서도, 저장소 전체를 복제했다고 단정할 증거는 없다고 구분합니다.
- @ai-tacocat-ia — 특정 라이브러리를 다른 언어로 번역한 것이 아니라, PDF 라이브러리처럼 이미 알려진 종류의 소프트웨어를 정하고 요구사항을 논의해 구현했다고 답합니다. 개별 구현뿐 아니라 에이전트 운영 절차와 테스트 하네스가 개발의 큰 부분이라고 설명합니다.
원문: Recursive AI / 번역·요약: Trawling