AI 소프트웨어 팩토리, 에이전트가 PR을 열고 리뷰하고 머지하는 시스템
How to Build an AI Software Factory: Agents That Open, Review, and Merge PRs
AI 소프트웨어 팩토리는 코딩 에이전트를 둘러싼 시스템으로, 다섯 단계와 각 단계의 게이트로 구성된다. Sentry의 Seer는 이슈의 실행 가능성을 점수화하고, Stripe는 약 10초 만에 devbox를 부팅하며, Spotify의 LLM 판사는 에이전트 세션의 약 25%를 거부한다. Faire는 에이전트가 작성한 PR에 두 명의 인간 리뷰를 요구한다. 생성은 비용에 비례해 확장되지만 리뷰는 그렇지 않다는 비대칭이 핵심 설계 문제다.
AI는 코드 생산의 경제성을 바꾼다. 좋은 판단력과 휴대폰을 가진 한 사람이 팀이 리뷰할 수 있는 것보다 더 빠르게 PR을 생성할 수 있다.
HN 토론
10- Incipient
나는 fable과 opus를 각각 약 25%, 75% 비율로 사용하고 있다. 3단계 프로세스를 쓰는데 - 주제를 논의하고 리뷰를 작성한 뒤, 리뷰를 태스크 파일로 변환하고 디자인 문서를 업데이트하고, 마지막으로 태스크 파일을 코드로 구현한다. 보통 변경당 300~1000 LOC 정도를 구현하고, 새 UI 페이지 같은 경우에는 더 많다.
솔직히 말해서 믿을 수 없을 정도로 훌륭하다.
- 50%의 경우에는 내가 전부 그대로 받아들이는 코드를 생성한다.
- 25%: 내가 좋아하지 않는 선택을 하거나, 구현 방식이 내가 원했던 접근법이 아니라서 내가 수정한다.
- 10%: 불필요하게 반쯤 중복되는 함수 로직을 만들어서 코드가 훨씬 많아지고 실행 경로를 머릿속으로 그리기 어려워진다.
- 10%: 그래서는 안 되는 비즈니스 로직을 그대로 반영하고, 그것을 미묘하게 바꿔버린다. 이걸 고치려면 엄청난 개입이 필요하다.
- 5%: 완전히 궤도를 이탈한다. 예를 들어 비즈니스/애플리케이션 로직이 데이터베이스에 있어야 한다고 결정해버린다.
프롬프트를 잘 쓰고 검토하는 이 방식은 솔직히 아주 잘 작동한다(다만 아직 유료 고객이 한 줌 이상인 상태에서의 테스트는 기다리고 있다!) 하지만 완전히 자동화된 에이전트 파이프라인? 나는 확신이 안 든다. 마지막 15%의 사례가 코드베이스를 순식간에 퇴화시킬 것이다.
또한 CC 구독 없이 토큰당 지불한다면, 내 접근 방식에는 끔찍하게 비쌀 것이다.
- notatoad
여기 관련된 개념들에 대한 유용한 정리글처럼 보이긴 하는데, 나는 Claude의 글쓰기 스타일을 읽는 게 너무 싫다.
이건 콘텐츠 마케팅이니까, 최소한 발행 버튼을 누르기 전에 한 번 검토는 하라… 만약 당신의 마케팅이 다듬어지지 않은 AI 쓰레기라면, 당신의 제품도 그럴 거라고밖에 생각할 수 없다.
- joshheitzman
우리는 수십 년 동안 소프트웨어 팩토리를 가지고 있었다. 그것들은 보통 컴파일러, 링커, 툴체인 등이라고 불린다.