루프: 의도 → 생성 → 검토 → 개선
이 책의 모든 것은 하나의 사이클로 귀결된다. 이것을 체화하라.
- 의도(Intent). 원하는 것과 중요한 제약을 진술하라 — 입력, 출력, 엣지 케이스, 스택, 스타일. 모호한 의도는 모호한 코드를 낳는다.
- 생성(Generate). 모델이 구현을 작성하게 하라. 문법을 일일이 붙잡지 말고, 동작을 설명하라.
- 검토(Review). 돌아온 결과를 읽어라. 실제로 그 일을 하는가? 빈 리스트, null, 실패한 네트워크 호출을 처리하는가? 작동하는 것 중 가장 단순한 버전인가?
- 개선(Refine). 무엇이 잘못됐는지 가리키고, 구체적인 수정을 제시하고, 다시 생성하라. 기준을 충족할 때까지 반복하라.
대부분의 초보자는 3단계를 건너뛴다. 생성하고, 돌아가고, 넘어간다. 그러다 설명한 적 없는 케이스에서 프로덕션이 깨진다. 검토 단계가 바로 엔지니어링이 일어나는 곳이다.
이 루프에서 좋은 첫 프롬프트는 다음과 같은 모습이다:
Write a TypeScript function `parseDuration(input: string): number`
that converts strings like "1h30m", "45s", "2d" into total seconds.
Requirements:
- Support units: d (days), h (hours), m (minutes), s (seconds).
- Multiple units can combine: "1h30m" = 5400.
- Reject invalid input (empty, unknown units, negative) by throwing
an Error with a clear message.
- No external libraries. Include 5 unit tests covering the edge cases.
Show the function and tests only.
구조에 주목하라: 정확한 시그니처, 명시적인 규칙, 명시된 엣지 케이스, 진술된 제약, 그리고 테스트 요청. 당신은 모델이 알아서 맞추기를 바라는 게 아니다 — 잘못된 추측을 만들어내는 모호함을 제거하는 것이다.
개선 단계도 첫 프롬프트만큼이나 하나의 기술이다. 모호한 피드백은 모호한 수정을 낳는다. 이 두 가지 수정 요청을 비교해보라:
나쁜 예: "this is wrong, fix it"
좋은 예: "parseDuration('1h30m') returns 90 instead of 5400 — you're
summing the numbers but ignoring the unit multipliers. Multiply
each value by its unit's seconds (d=86400, h=3600, m=60, s=1)
before summing. Also add a test for the combined case '2d3h'."
좋은 쪽은 증상, 원인, 그리고 수정 방법을 명시한다. 당신은 동료의 풀 리퀘스트를 검토하듯 검토하고 있는 것이다 — 그리고 더 정밀하게 가리킬수록 더 적은 라운드를 쓴다. 각 루프는 수렴해야 한다. 제자리를 맴돌고 있다는 느낌이 든다면, 그것은 의도가 명세 부족이었다는 신호다. 다시 생성하기를 멈추고 명세를 다시 써라.