인간은 같은 문제를 두 번 다루어서는 안 됩니다.
요약: 모든 인간의 코드 리뷰 발견 사항을 harness 규칙으로 만들어, 다음 리뷰가 이전에 끝난 곳에서 시작되도록 하세요.
흔한 실수 ❌
당신은 AI의 풀 리퀘스트를 검토하고 문제를 발견합니다.
그것을 수정하고, 댓글을 남기고, 병합합니다.
이 댓글은 닫힌 풀 리퀘스트에 존재했고, harness는 그것을 알지 못했습니다.
당신은 이번 주 세 개의 풀 리퀘스트에서 같은 명명 규칙을 설명했습니다.
네 번째 것이 지금 열려 있습니다.
당신의 harness가 가진 유일한 기억은 바로 당신입니다.
그리고 당신이 가장 비싼 부분입니다.
해결하는 문제점 😔
-
가장 비용이 많이 드는 리뷰어가 linter 또는 hook가 잡아낼 수 있는 발견 사항에 주의를 기울입니다.
-
두 명의 리뷰어가 머릿속에 서로 다른 규칙 세트를 가지고 있어, 표준이 없는 같은 코드에서 서로 다른 것을 발견합니다.
-
AI가 당신이 읽는 것보다 빠르게 작성하므로, 모든 라인을 검토하는 것이 전체 파이프라인의 병목 현상이 됩니다.
-
큰 풀 리퀘스트가 인간의 도움이 필요했던 하나의 결정을 묻어버립니다.
-
harness는 첫날에 추측한 규칙에 고정되어 있고, 코드베이스의 실제 실수는 기록되지 않은 채로 남겨집니다.
-
리뷰에서 결정된 설계 결정은 문서화되지되며, 다음 리뷰어는 그것들을 재발견해야 합니다.
-
누구도 리뷰가 무엇을 발견하는지 세지 않기 때문에, 팀이 개선되고 있는지 알 수 없습니다.
-
리뷰가 단순히 코드만 수정하는 경우, 데밍이 설명한 사이클을 시작하지 못하기 때문에 같은 발견 사항이 계속해서 돌아옵니다.
이렇게 하는 방법 🛠️
-
모든 사람의 리뷰 코멘트를 코드상의 결함뿐만 아니라 하우징(harness) 내의 결함으로 간주하세요.
-
발견 사항을 누가 포착할 수 있었는지에 따라 분류하세요: 린터(linter)나 후크(hook), 판단 능력(judge skill), 작성된 결정, 또는 오직 인간만이 할 수 있는 것.
-
명명이나 형식 같은 기계적인 발견 사항은 후크(hook)나 린트 규칙(lint rule)으로 만드세요.
-
의미론적(semantic) 발견 사항은 AI가 매 세션마다 새롭게 읽도록 하는 검증기 능력(validator skill) 내부의 규칙으로 만드세요.
-
설계상의 발견 사항은 작성된 결정으로 만들고, 그 옆에 이유를 적어 내려가세요.
-
거부된 코드를 문제점 파일(pitfalls file)에 실패하는 예시로 추가하세요.
-
하우징(harness)에서 규칙 세트를 시작하고, 모든 인간의 발견 사항을 먼저 실패하는 테스트 케이스로 작성하세요: 거부된 코드가 입력이고, 아직 아무것도 감지하지 못하기 때문에 테스트가 실패합니다.
-
그 테스트를 통과시키는 규칙을 작성한 다음, 기준 확인(criteria check)과 함께 거부된 diff에 대해 하우징(harness)를 실행하고, 그 규칙이 해당 diff를 차단할 때만 유지하세요.
-
{
테스트와 규칙을 수정 사항과 같은 풀 리퀘스트(pull request)에 함께 전송하여 lesson가 변경 사항과 함께 병합되도록 하세요.
-
다음 diff를 먼저 pipeline에 보내서, 살아남는 것만 확인하세요.
-
모든 발견 사항을 니트(nit), 결함(defect), 디자인(design), 또는 비즈니스 규칙(business rule)으로 태그하고, 리뷰당 개수를 세세요.
-
몇 주마다 contradiction audit를 실행하세요. 모든 새로운 규칙이 오래된 규칙과 불일치할 수 있으므로, 모델이 성장하여 더 이상 사용하지 않는 hoarded rules는 버리세요.
-
harness가 결정할 수 없는 결정(디자인 트레이드오프, 비즈니스 규칙, 위험 등)에 주의를 기울이세요.
이점 🎯
-
가장 희소한 자원을 보호하세요: 당신은 harness가 판단할 수 없는 것, 그 외에는 아무것도 읽습니다.
-
두 번 돈을 내지 마세요: 규칙이 된 발견 사항은 다시는 작성하지 않는 발견 사항입니다.
-
실제 고통에서 성장하세요: harness는 당신이 1일차에 상상했던 실수 대신, 실제 코드베이스가 생성하는 실수를 수집합니다.
-
매번 같은 방식으로 검토하세요: 어떤 리뷰어가 열더라도 모든 diff는 동일한 규칙을 따릅니다.
-
더 빠르게 병합하세요: 발견 사항이 적게 당신에게 도달하므로, 작은 pull request에 대한 검토가 더 빨리 끝납니다.
-
당신의 성숙도를 읽으세요: 발견 사항의 조합은 설문조사 없이도 팀이 얼마나 성숙한지 알려줍니다.
-
사람과 에이전트를 온보딩하세요: 새로운 팀원이나 새로운 에이전트는 인간이 내렸던 모든 결정을 상속받습니다. 이는 회사 두뇌(company brain)와 같습니다.
Context 🧠
당신은 누구보다 빠르게 코드를 생성하지만, 검토자로서 확장되지 않습니다.
Mäntylä and Lassenius는 리뷰 결함의 60%에서 75%가 진화 가능성(evolvability), 즉 명명 규칙, 구조, 문서화에 관한 것임을 발견했습니다.
pull request 내의 댓글은 잘못된 장소에 존재하는 규칙입니다.
올바른 장소는 harness입니다: 린터(linter), 훅(hook), 기술(skill), 또는 문서화된 결정입니다.
Fool me once, shame on you; fool me twice, shame on me.
전통 속담, 1651년 Anthony Weldon에 처음 인쇄됨
Standards gates는 기계적인 발견 사항을 차단하므로, 설계 트레이드오프(design trade-offs)와 위험 쪽으로 올라가야 합니다.
이것이 바로 loop engineering의 순환 과정입니다: 평가(evaluation)는 당신이 그 안에 넣는 모든 발견 사항을 확인하며, 사람이 필요하지 않습니다.
harness가 성장하고 규칙들이 서로 불일치하기 시작하므로, 몇 주마다 모순점(contradictions)을 감사해야 합니다.
프롬프트 참고 📝
나쁜 프롬프트 🚫
Review this pull request.
Fix every problem you find.
Tell me when it's ready to merge.
좋은 프롬프트 👉
You're reviewing this pull request as the harness, not as a person.
Read AGENTS.md, the standards, and the design decisions first.
...
고려 사항 ⚠️
모든 발견 사항이 규칙이 될 필요는 없습니다.
이상한 엣지 케이스(edge case)에 대한 일회성 판단은 주석(comment)으로 남겨둡니다.
주석 하나를 기반으로 작성된 규칙은 틀릴 수 있습니다.
저는 단 하나의 주석만으로는 규칙을 자동화하지 않을 것입니다.
두 번째 주석이 나올 때까지 기다립니다.
규칙은 코드와 같으므로, 다른 모든 변경 사항처럼 검토(review)가 필요합니다.
당신은 검토를 남기지 않습니다.
중요한 결정 사항으로 넘어갑니다. 그리고 그것은 작아진 일이 아니라, 다른 종류의 일입니다.
건강한 팀이 리뷰당 몇 개의 발견 사항을 봐야 하는지는 아직 모르겠습니다.
'0'이라는 것은 아무도 보고 있지 않다는 것을 의미할 것입니다.
유형 📝
[X] 반자동(Semi-Automatic)
제한 사항 ⚠️
첫 몇 주는 규칙 위에 수정사항을 작성해야 하므로 시간이 더 많이 소요됩니다.
A judge skill은 모든 diff마다 토큰 비용이 발생하므로, 저렴한 검사는 린터(linters)에 남겨두어야 합니다.
context가 필요한 발견 사항이 기록되지 않았다면, 그 컨텍스트를 작성하기 전까지는 규칙이 될 수 없습니다.
태그 🏷️
- 지식 관리 (Knowledge Management)
레벨 🔋
[X] 중급 (Intermediate)
관련 팁 🔗
AI 코딩 팁 040 - AI에게 당신 자신의 모순점을 감사하게 하라
mcsee profile
Maxi Contieri
Maxi Contieri
Maxi Contieri
팔로우
Oct 12
#ai #webdev #programming #tutorial
댓글 추가
9분 읽기
AI 코딩 팁 016 - PR 교훈을 AI의 두뇌에 공급하라
mcsee profile
Maxi Contieri
Maxi Contieri
Maxi Contieri
팔로우
Apr 21
#ai #programming
4 반응댓글 추가
6분 읽기
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
[AI 코딩 팁 041 - 모든 코드 리뷰 발견 사항을 규칙으로 만드세요]
AI Coding Tip 027 - Force Code Standards
mcsee profile
Maxi Contieri
Maxi Contieri
Maxi Contieri
팔로우
7월 14일