AI에게 계획서를 주지 말고, 함께 짜며 전문성을 쌓아라
I Use Development-Driven Specs, Not Spec-Driven Development
Bill Cox의 실행형 저서 《The Art of Building AI Coding Agents》는 '스펙 주도 개발' 대신 '개발 주도 스펙'을 내세운다. 설계를 논의한 뒤 다음 챕터의 TL;DR과 연습문제만 초안으로 잡고, AI와 페어 프로그래밍하며 실시간으로 방향을 잡고 실수를 고치고 결정의 이유를 기록한다. 구현이 평가를 통과하면 그 메모로 챕터 본문을 쓴 뒤, 새 학생 에이전트에게 챕터와 채점기를 주어 재구현이 가능한지 시험한다. 결과물은 기능 목록이 아니라 판단력을 전수하는 실행 가능한 스펙이다. Ensemble V2가 이 책을 실행해 V3를 만들었고, 저자는 Cadence와 함께 V3 안에서 에이전트와 교재를 함께 개선했다.
코드를 그냥 문서화하지 말고, 왜 그렇게 만드는지를 가르쳐라. 그 모든 것을 미리 배울 수는 없다.
HN 토론
26- dromologist
제 일상 업무는 아주 레거시한 프레임워크를 다루는 일인데, 최상의 결과를 얻으려면 결국 에이전트에 수많은 스킬과 추가 도구 등을 잔뜩 붙여주게 되더군요. 이제 와서 보면 이건 이 프로젝트만을 위해 특별히 설계된 하네스나 다름없습니다.
필요에 의해 어쩔 수 없이 그렇게 된 측면도 있지만, 하네스를 자신의 특정 개발 경험에 맞추는 게 정말 큰 도움이 된다고 생각합니다. 마치 원하는 특정 플러그인으로 가득 찬 IDE처럼요. 다만 IDE는 아니죠. IDE는 이제 끝났으니까요.
- WaywardGeek
이렇게 하면 실행 가능한 명세서가 만들어집니다. Ensemble 같은 AI 코딩 에이전트에게 주면 명세서를 자율적으로 실행해서 새로운 버전의 코드를 만들어냅니다. 제가 "The Art of Building AI Coding Agents"를 실행해서 Ensemble의 새 버전을 만들 때 이 방식이 완벽하게 작동합니다. 이보다 더 성공적인 명세서는 본 적이 없습니다.
명세서는 코드를 작성하면서 함께 만들어야 합니다. 이 두 과정은 분리될 수 없습니다. 저는 평소처럼 AI와 사전 설계 대화를 나눈 뒤, 다음 챕터의 TL;DR과 연습 문제 섹션만 작성해 달라고 요청합니다. 그다음 AI와 페어 프로그래밍을 하면서 TL;DR을 따라 구현하고, 진행하면서 불분명한 점을 명확히 하기 위해 메모를 남기고, 실시간으로 AI를 제 설계 쪽으로 이끌어 갑니다.
새 코드가 모든 연습 문제 채점기를 통과한 뒤에야 비로소 AI에게 메모와 voice.md 파일을 읽고 챕터 본문을 작성하라고 요청합니다. 그다음 학생 역할을 하는 에이전트를 실행해서, 챕터와 채점기만으로 순수하게 코드를 작성할 수 있는지 확인합니다.
이 과정이 끝나면 저는 전문가가 되어 있고, 코드를 검토할 필요조차 없습니다.
코드는 그저 올바른 명세서를 실행한 결과일 뿐입니다. 컴파일러가 만들어내는 또 하나의 산출물인 셈이죠.
바이브 코딩은 그만두세요. 코드를 작성하면서 AI와 페어 프로그래밍을 통해 전문가가 되고, 그다음 코드를 작성하기 위해 했던 일들로부터 명세서를 만드세요. 코드를 만들기 위해 문서를 작성하지 마세요. 과정과 배운 점, 그리고 왜 이렇게 만들었는지를 문서화하세요. 그건 미리 할 수 없습니다.
페어 프로그래밍을 할 줄 모른다면 […]
- ozlikethewizard
"AI 코딩 에이전트를 만드는 책. 다음 판을 만드는 에이전트."
진짜요?