최악의 AI 코드 변경은 조용한 추측에서 시작됩니다.

작은 리팩토링(refactoring)을 요청합니다. 도구는 패턴을 찾고, 빈틈을 채웁니다. 그리고 잘못된 아이디어 주변으로 깔끔한 코드를 작성합니다.

테스트가 여전히 통과할 수도 있습니다.

해결책은 간단합니다. 도구가 코드를 작성하기 전에 가정 목록을 작성하도록 하세요.

실패는 요청 안에 숨어 있다

예를 들어, 다음과 같이 요청한다고 가정해 봅시다:

실패한 결제 상태 검사에 재시도(retries) 기능을 추가하세요.

도구는 여러 추측을 할 수 있습니다:

• 모든 실패한 요청은 재시도해도 안전하다.
• 타임아웃(timeout)은 아무 작업이 일어나지 않았음을 의미한다.
• 두 번의 요청이 중복 작업을 유발할 수는 없다.

이러한 추측들은 틀릴 수 있습니다.

좌절스러운 부분은 실수가 아닙니다. 그 이후에 코드가 얼마나 합리적으로 보이는가 하는 점입니다.

저는 코드 자체를 검토하는 대신, 그것의 시작 믿음을 검토하는 데 집중했습니다. 이는 잘못된 접근이었습니다.

좋은 변경은 확인된 사실에서 시작됩니다.

위험한 수정 전에 이 프롬프트를 사용하세요

도구가 파일을 변경하기 전에 이것을 붙여넣으세요:

Before editing code, list up to five assumptions you are making.

For each assumption, include:
...

마지막 줄이 중요합니다.

이것이 없으면 많은 도구들이 가정 목록을 작성한 후에도 코딩을 시작할 것입니다. 생각과 변경 사이에 일시 정지가 필요합니다.

유용한 답변의 모습

약한 답변은 다음과 같습니다:

재시도는 이곳에서 흔하기 때문에 안전해야 합니다.

이것은 증거가 아닙니다. 넥타이를 맨 추측일 뿐입니다.

유용한 답변은 다음과 같을 수 있습니다:

클라이언트의 재시도(retries)는 src/client.ts에서 읽기 요청을 수행합니다. 테스트는 상태 코드 429와 503을 다룹니다. 타임아웃 동작은 테스트되지 않았습니다. 서버가 클라이언트가 타임아웃된 후에도 작업을 완료할 수 있는지 확인해야 합니다.

이제 검토할 수 있는 무언가를 갖게 되었습니다.

파일을 열어볼 수 있습니다. 테스트를 읽어볼 수 있습니다. 타임아웃 케이스를 확인할 수 있습니다.

도구는 자신의 확신이 어디서 끝나는지 보여주었습니다.

신뢰도가 아닌 증거를 검토하세요

각 가정에 대해 한 가지 질문을 하세요:

이 프로젝트 내부에서 증거를 제시할 수 있습니까?

좋은 증거에는 다음이 포함됩니다:

좋은 증거에는 다음이 포함됩니다:

• 행동을 명시하는 테스트(A test that names the behavior)
• 해당 행동에 의존하는 호출자(A caller that depends on the behavior)
• 설정 값(A config value)
• 현재 설계 노트(A current design note)
• 이미 동일한 케이스를 처리하는 코드

약한 증거에는 다음과 같은 구절들이 포함됩니다:

• “이것은 보통 안전합니다.”
• “대부분의 시스템은 이런 방식으로 작동합니다.”
• “이름에서 그렇게 암시됩니다.”
• “이것은 위험도가 낮아 보입니다.”

이러한 구절들이 항상 틀린 것은 아닙니다. 단지 확인이 필요할 뿐입니다.

추측 비용이 가장 많이 드는 곳에 사용하세요

이 프롬프트는 다음 사항을 변경할 때 가장 도움이 됩니다:

• 데이터 쓰기(Data writes)
• 로그인 또는 접근 규칙(Login or access rules)
• 두 번 실행될 수 있는 작업(Jobs that may run twice)
• 공개 API 동작(Public API behavior)
• 오류 처리(Error handling)
• 테스트가 적은 오래된 코드

모든 오타에 사용할 필요는 없습니다.

숨겨진 규칙이 깔끔한 코드를 깨진 동작으로 바꿀 수 있을 때 사용하세요.

목표는 완벽한 확실성이 아닙니다

당신은 결코 모든 미지(unknown)를 제거할 수 없을 것입니다.

목표는 미지의 것을 코드화되기 전에 가시적으로 만드는 것입니다.

가정들이 건전해 보이면, 도구에게 계속 진행하라고 지시하세요. 만약 하나라도 증거가 부족하면, 멈추고 먼저 확인하세요.

그 작은 멈춤이 검토를 바꿉니다. 당신은 더 이상 단지 “이 코드가 올바른가?”만 묻는 것이 아닙니다.

당신은 또한 “올바른 사실(fact)에서 시작했는가?”도 묻고 있는 것입니다.

다음 위험한 편집을 하기 전에, 이 프롬프트를 붙여넣고 첫 번째 가정을 검사하세요.

태그: ai, programming, productivity, testing