AI 에이전트에게 기능을 맡기면 결과물은 쉽게 커집니다. 날짜 하나를 고르는 UI에도 외부 라이브러리, 래퍼 컴포넌트, 전용 스타일, 시간대 논의가 차례로 붙을 수 있습니다. DietrichGebert/ponytail은 이 과잉 구현을 “더 짧게 작성하라”는 구호로 누르지 않습니다. 대신 브라우저와 기존 코드가 이미 가진 해법을 먼저 확인하도록 판단 순서를 바꿉니다.
Ponytail의 ladder는 일곱 단계로 구성됩니다. 기능이 정말 필요한지 묻고, 코드베이스에 이미 있는 구현을 찾고, 표준 라이브러리와 브라우저의 네이티브 기능을 차례로 살핍니다. 설치된 의존성으로 해결되는지도 본 뒤 한 줄짜리 해법을 검토하고, 마지막에만 최소 구현으로 내려갑니다. 날짜 선택기라면 복잡한 컴포넌트 대신 `<input type="date">`가 먼저 후보가 됩니다. 브라우저의 기능 경계가 불필요한 코드 생성을 막는 중단선이 되는 셈입니다.
여기서 “최소”는 안전장치를 버린다는 뜻이 아닙니다. README는 에이전트가 변경 대상 코드를 읽고 실제 흐름을 추적한 다음 ladder를 적용한다고 설명합니다. 신뢰 경계의 검증, 보안, 오류 처리, 데이터 손실 방지, 접근성은 줄이지 않는 항목으로 남습니다. 그래서 ponytail의 목표는 토큰 수를 무작정 깎는 것이 아니라, 필요한 코드와 습관적인 코드를 구별하는 데 있습니다.
공개된 에이전트 벤치마크는 이 주장을 실제 작업으로 시험했습니다. FastAPI와 React로 구성된 오픈소스 저장소에서 12개 기능 티켓을 동일 에이전트의 skill 유무로 비교했고, 평균 코드량은 54%, 토큰은 22%, 비용은 20%, 소요 시간은 27% 감소했습니다. 안전성은 100%였습니다. 특히 날짜 선택기와 색상 선택기처럼 네이티브 입력으로 대체할 여지가 큰 작업에서 감소폭이 컸고, 이미 간결한 코드에서는 효과가 거의 없었습니다.
반대 조건도 README에 함께 적혀 있습니다. GPT-5.5처럼 사다리의 단계를 오래 숙고하는 추론 모델에서는 비용과 시간이 오히려 늘 수 있습니다. 그러므로 ponytail을 모든 에이전트에 통하는 만능 압축기로 해석하면 곤란합니다. 브라우저 기능과 기존 저장소를 잘 활용하지 못하고, 작업마다 새 추상화를 만드는 에이전트에 더 적합한 규칙입니다.
AI 코딩의 생산성을 “얼마나 많이 생성했는가”로만 측정하면 저장소에 남은 불필요한 구조를 놓치기 쉽습니다. Ponytail이 던지는 질문은 단순합니다. 이 코드는 정말 필요한가? 브라우저가 이미 답을 갖고 있지는 않은가? 좋은 에이전트의 다음 단계는 더 빠른 타이핑이 아니라, 답이 있는 자리에서 정확히 멈추는 능력일 수 있습니다.