다들 AI로 어떻게 코딩하시나요?

1번 방식이 압도적임. 기획 이후에 필요하다면 노력을 좀 줄여도 됨. 솔직히 지능형 모델 비용이 점점 싸지고 있어서, 그냥 Opus를 적당한 노력으로 모든 작업에 쓰는 게 큰 문제는 아님.

Haiku로 기획하고, Opus가 아무리 반대해도 그 기획을 무조건 따르게 강제함.

변태 같네.

개발할 때 Opus 5.5를 정말 많이 씀. Codex 20달러 티어가 감사나 리뷰에는 아주 잘 먹힘.
하지만 Opus를 써서 오류가 없다고 나왔는데도, 프롬프트를 바꿔보면 심각한 결함이 발견되기도 함.

같은 소프트웨어와 모델이라도 시니어 개발자들은 뭘 물어봐야 할지 알기 때문에 나보다 더 좋은 결과를 얻을 거라고 확신함.

내가 시작한 방법 중 하나는 감사(audit)만 전담하는 Claude 프로젝트를 만드는 거임. Opus 5.5에서 그걸 쓰고, fable을 시도한 다음, codex 감사 기능을 추가해서 더 학습시키면 다음 프로젝트부터는 감사가 훨씬 쉬워짐.
새로운 버전의 Opus나 다른 모델이 나올 때마다 감사 도구를 다시 돌림. 내 프로젝트들은 p0, p1, p2 리스트로 나뉘어 있고, 감사 도구는 각 프로젝트 폴더에 감사 도구를 업데이트하라는 지침과 함께 핸드오프를 남김. 그러면 감사 도구가 어떤 사이트가 완료됐고 뭐가 남았는지 알려주고 라이브 버전이 최신 상태인지 확인해 줌.

1번 방식인데 한 가지 변경점이 있음: 리뷰어 모델을 작성 모델과 다르게 설정하는 거임. Opus가 작성하면 Codex가 리뷰하게 하거나 그 반대로 함. 절대 같은 모델이 자기 작업물을 리뷰하게 두지 않음. 리뷰어는 diff를 완전히 새로운 시각에서 읽기 때문에, 작성 모델이 자기 논리에 빠져서 그냥 지나친 부분을 잡아낼 수 있음.

내 경험상 2번 방식은 저렴한 코더 모델이 여러 번 수정 과정을 거쳐야 해서 토큰을 다 태워버림. 수정할 때마다 컨텍스트를 다시 로드해야 하니까. 질문자가 느린 이유도 바로 그거임. 모델 등급을 낮추는 게 효과적인 건 이름 바꾸기, 테스트 스캐폴딩, 문서화 같은 지루한 작업들임. 그런 건 테스트를 통과해야 하는 저렴한 모델한테 맡기고, 디자인과 관련된 건 강력한 모델한테 맡기셈.