이 글은 최근 시리즈의 부록/사이드 퀘스트 같은 느낌입니다. 메인 포스트에 깔끔하게 들어맞지 않아서 독립적으로 게시합니다. 소프트웨어 팩토리가 실패하는 이유 2부: 다시 불을 켜다 에서 잠깐 언급됩니다.
레버리지 찾기
AI 이전에도, 기능을 출시하는 데 걸리는 시간의 25-50%만이 실제 코드를 작성하는 데 사용되었습니다. 나머지는 정렬/계획, 코드 리뷰/재작업, 솔루션 테스트/검증에 사용되었습니다.
만약 AI를 코드 작성에만 사용한다면, 코딩 시간 2-4시간을 10-20분으로 줄일 수 있지만, 다른 부분은 전혀 가속화되지 않습니다.
하지만 계획 수립과 정렬에 AI를 사용한다면, 실제로 2-3배 더 빨라질 수 있습니다.
AI 코딩 레버리지의 80/20 법칙
여러분이 AI 공장에 두 문장짜리 프롬프트를 무작정 던져 넣었을 때, 완전히 병합 가능한 결과를 얻을 확률은 약 50%이고, 재작업해야 할 확률은 50%라고 가정해 봅시다.
이제 여러분이 10년 경력의 수석 엔지니어라고 가정해 보겠습니다. 여러분의 머릿속에는 100개 레포지토리에 걸친 전체 코드베이스가 다운로드되어 있습니다. 그래서 직접 완벽하게 상세한 명세서를 작성하는 데 오후 내내 시간을 보냅니다. 그러면 확률이 더 좋아지겠지만, 여전히 무언가 중요한 것을 다시 해야 할 확률이 약 10%는 남아 있습니다.
그리고 극단적인 경우: 모든 줄을 직접 작성합니다. 에이전트가 실수할 일이 없으므로 재작업 확률은 0이 됩니다.
\\참고\\ 이 예시에서는
"무언가를 변경해야 할 확률"에 "변경의 고통스러운 정도"를 가중치로 적용한 값
을 단일 백분율 숫자로 모호하게 처리하겠지만, 분명히 이것은 두 개의 별도 변수입니다. 모델이 버튼 스타일을 50% 확률로 잘못 지정할 수 있지만, 수정이 저렴한 프롬프트 하나라면, 결합된 "예상 고통"은 낮습니다.
예상 고통 = 변경해야 할 확률 × 변경의 고통스러운 정도
이것을 도식화하면, 사전에 투자한 노력과 예상 고통 사이에는 반비례 관계가 있습니다.
여러분이 원하지 않는 것은 예상 고통의 80%를 처음 10분 안에 제거할 수 있었던 작업을 계획하는 데 6시간을 소비하는 것입니다.
한 단계 아래로 내려가지 않고는 답할 수 없는 질문에 지나치게 집중하지 않고 이 작업을 수행해야 합니다. 예를 들어, "제품" 수준에서 일부 작업을 수행했지만 아직 모든 미해결 질문에 답하지 못한 경우, 현재 위치에서 멈추고 기술적 세부 사항 수준으로 확대/축소하여 무엇이 실현 가능한지 이해해야 할 필요가 있습니다. 이에 대한 완벽한 프로세스는 없습니다.
이것이 우리가 레버리지라고 부르는 것입니다. 그리고 이것은 실용적이어야 함을 요구합니다. 50,000피트 관점에서 10,000피트 관점까지 여러 단계의 계획을 수행하는 경우, 각 단계에서 약간의 방향 전환을 통해 가능한 한 많은 예상 고통을 제거하고 있는지 확인해야 합니다.
행운을 빕니다.
