AI 코딩에서 가장 짜증 나는 점은 나쁜 코드가 아니라, 요청하지도 않은 코드임

난 모든 설정을 다 해둠. 먼저 모든 가이드라인을 세우고, 그다음 SAST, DAST, 커버리지까지 설정함. 그러고 나서 변경 사항을 만들기 전에 먼저 계약(contracts)부터 확인함. 이제는 내가 접근 방식이 마음에 안 들 때를 제외하면 거의 확인할 게 없음.

아니면 그렇게 하지 말라고 시키거나, 이미 그렇게 했다면 지우라고 하면 되는 거 아님?

엄격하게 가야 함. 변경된 모든 줄은 내가 요청한 내용으로 추적 가능해야 함. 그 외에 AI가 발견한 다른 것들은 diff가 아니라 보고서에 담아야 함.

그럴 거면 그냥 손으로 직접 짜는 게 낫겠네. 이 방식은 네 문구가 쉼표 하나 틀리거나, 오타가 있거나, 의도가 다르게 해석될 수 있는 경우에 오히려 문제를 일으킬걸.

.md 파일에 이런 내용을 추가해봐.

코드 변경

• 코드 변경 사항을 리뷰하기 쉽게 만들 것.

• 작업에 필요한 내용만 변경할 것. 내가 요청하지 않은 수정, 리팩토링, 이름 변경, 서식 변경은 하지 말 것.

• 관련 없는 문제를 발견하면 나에게 알릴 것. 내가 요청하지 않는 한 수정하지 말 것.

• diff를 작고 집중된 상태로 유지할 것. 변경할 필요가 없는 코드를 옮기거나 서식을 바꾸지 말 것.

• 기존 코드의 스타일과 패턴을 따를 것.

매번 엄격하게 해야 함. 추가적인 변경 사항은 제안만 하게 하고, 직접 적용하게 두지 마. 보안 측면에서 보면, 요청하지 않은 변경 사항 때문에 로깅 조정이 조용히 개인 정보를 저장하기 시작하거나 인증 체크가 슬그머니 사라지는 일이 생김. 직접 읽을 수 있는 작은 diff가 수정해야 할 똑똑한 에이전트보다 훨씬 나음.

아니, 명시하지 않으면 나쁜 코드도 짬. 예를 들어 전체 프로세싱을 다 해놓고 나중에 유효성 검사를 한다든지 하는 식임. 빈 폴더에서 시작하면 요청이나 응답, 혹은 그 형태에 대한 간단한 필드 유효성 검사조차 놓치기도 함. 그래서 가이드라인 없이는 나쁜 코드를 만드는 게 맞음.

high thinking/yolo 모델 쓰지 마.. low thinking 에이전트는 질문이 생기면 그냥 구현해버리는 대신 매번 물어봄.