에이전트가 먼저 동의한다면, 리뷰는 폐기하라
첫 번째 통과(first-pass)에서의 동의는 실패한 에이전트 리뷰다.
자신이 제시한 전제를 그대로 되돌려 듣는 것과 같다.
스코어링된 반대 의견 로그(scored dissent log)가 존재할 때까지 병합을 차단하라.
내가 주장하고 싶은 내용
코딩 에이전트는 동의하기 쉽기 때문에 종종 동의한다.
칭찬 몇 마디와 사소한 지적 하나로는 리뷰가 될 수 없다.
그러한 패턴은 diff를 축복하는 것이 아니라, 멈추게 해야 한다.
이 글은 의도적으로 강경한 입장을 취한다.
첫 번째 통과에서의 동의는 설계가 올바르다는 증거가 아니다.
오직 반증(falsify)할 수 있는 반대 의견만이 패치를 움직일 수 있다.
당신은 이 diff에 대한 기록된 리뷰어이다.
에이전트는 의심을 할 수 있는 쿼터(quota)를 가진 초안 비평가일 뿐이다.
만약 그것이 의심하지 않는다면, 당신은 그 실행을 폐기해야 한다.
값싼 실행은 게으른 리뷰를 부른다
무료 모델 접근성은 또 다른 채팅을 자유롭게 느끼게 만든다.
무료 서버 옵션은 또 다른 실행을 자유롭게 느끼게 만든다.
값싼 실행이야말로 게으른 리뷰가 숨어있는 곳이다.
공개: 이 글은 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었다.
MonkeyCode는 여기서 단지 그 두 가지 옵션에 대한 호스트 역할만 할 뿐이다.
무료 모델 접근성을 박수갈채가 아닌, 반대 의견 패스에 사용하라.
무료 서버 옵션을 고정된(pinned), 일회용 리뷰 상자로 사용하라.
단순히 이용 가능하다는 것 자체가 여기서는 품질 주장이 아니다.
이 글은 토큰 쿼터, 모델 이름 또는 하드웨어 사양을 발명하지 않았다.
운영자가 실제로 켠 호스트와 모델을 고정하라.
그러한 사실들은 변하며, 이 게이트(gate)는 그것들을 필요로 하지 않는다.
대시보드가 숫자를 보여준다면, 그 숫자를 스스로 기록하라.
오늘 읽지 않은 수치는 인용하지 마라.
지난달의 스크린샷은 현재의 사실이 아니다.
실시간 약관을 읽고, 본인이 본 것만 적어라.
- 설계 전제를 다시 설명하는 문장 하나를 작성하세요.
- 여전히 실패할 수 있는 반론을 최소 세 가지 모으세요.
- 각 반론에 대해 허위화(falsifier) 명령이나 주장을 첨부하세요.
- 에이전트가 당신에게만 동의할 때 실행을 중단하세요.
에이전트가 설계를 공격할 수 없다면, 스레드를 멈추세요.
지금 같은 채팅에서 더 열심히 하라고 애원하지 마세요.
동일한 고정 계약(frozen contract)으로 깨끗한 실행을 여세요.
토큰을 쓰기 전에 계약을 고정하라 (Freeze the contract before you spend a token)
당신이 계약을 작성하고, 에이전트는 그것을 수정하지 않습니다.
그 계약을 diff와 함께 버전 관리 하에 저장하세요.
답변 키가 아닌 diff와 계약을 붙여넣으세요.
# dissent-contract.yaml
# 실행할 수 있는 제안입니다. 측정된 벤치마크는 아닙니다.
review_id: "REV-014"
...
금지 목록(forbidden list)이 이 연습의 핵심입니다.
당신은 친근한 요약본이 아니라 마찰에 비용을 지불하고 있는 것입니다.
당신의 아이디어를 위반할 수 없는 리뷰는 리뷰가 아닙니다.
산문(prose)을 신뢰하기 전에 로그를 게이트하라 (Gate the log before you trust the prose)
이 스크립트는 모델을 전혀 호출하지 않습니다.
오직 표준 입력(stdin)에서 반론 로그(dissent log)를 수락하거나 거부할 뿐입니다.
어떤 반론에 대해 논의하기 전에 로컬에서 게이트를 실행하세요.
#!/usr/bin/env python3
"""로컬 반론 게이트. 실행하기 전까지의 제안입니다."""
import json
...
게이트에 JSON 로그를 공급하고 종료 코드를 읽으세요.
python3 dissent_gate.py < dissent-log.json
echo "gate_exit=$?"
종료 코드 0은 로그가 필요한 형태를 갖추었음을 의미합니다.
그 종료 코드가 어떤 반론이 사실이라는 것을 의미하지는 않습니다.
여전히 각 명명된 파일을 열고 허위화를 시도해야 합니다.
게이트 옆에 실패하는 고정값(fixture)을 유지하라 (Keep a failing fixture next to the gate)
게이트를 신뢰하기 전에, 그것이 거울(mirror)을 거부한다는 것을 증명해야 합니다.
전제를 단순히 반복하는 나쁜 로그를 저장하세요.
비-0 종료 코드(non-zero exit)를 예상하고, 통과하면 설정을 실패시키세요.
{
"premise": "동기 파일 읽기를 경계가 있는 비동기 풀로 대체합니다.",
"objections": [
...
그 고정값은 카운트(count)와 거울에 반영된 주장 모두에서 죽어야 합니다.
좋은 로그는 각각 실제 검증을 가진 세 가지 구별되는 공격이 필요합니다.
친근한 로그가 빠져나갈 수 있도록 게이트를 약화시키지 마세요.
각 행을 직접 점수화하세요
게이트가 로그를 수락한 후 이 표를 사용하세요.
마지막 열은 당신이 채우고, 에이전트는 채우지 않습니다.
파일 없이 유창한 문장도 여전히 실패입니다.
| 항목 | 통과 예시 | 실패 예시 |
|---|
| 파일 존재 여부 | diff에 경로가 있음 | 경로를 지어냄 |
| ... | | |
| A low severity with a real falsifier can still block you. A high severity with no file cannot block anyone. Severity is only a hint you may override in writing. | | |
가짜 메트릭 없이 하나의 diff를 검토하기
로컬 파일 읽기 주변의 작은 변경을 고려해 보세요.
패치는 동기(sync) 읽기를 제한된 비동기 풀(bounded async pool) 안에 감쌉니다.
약한 리뷰는 풀이 더 깨끗해 보인다고 말하고 멈춥니다.
그 리뷰를 폐기하세요. 왜냐하면 그 리뷰가 전제에 동의했기 때문입니다.
사용 가능한 반론은 풀이 호출자들에게 백프레셔(backpressure)를 숨긴다고 말합니다.
반증자는 슬롯보다 더 많은 대기자가 있는 테스트입니다.
두 번째 반론은 취소(cancellation)가 열린 핸들(open handle)을 누수시킨다고 말합니다.
반증자는 파일을 닫아야 하는 타임아웃입니다.
만약 당신이 그 검사를 구축할 수 없다면, 반론은 열려 있게 됩니다.
세 번째 반론은 재시도(retry)가 부분 파일(partial file)을 두 번 읽는다고 말합니다.
반증자는 읽기와 체크섬 사이에 발생한 충돌입니다.
만약 diff에 체크섬이 없다면, 반론은 여전히 유효합니다.
이 줄들은 측정된 실험실 결과가 아니라 형태를 보여줍니다.
이 기사는 그것들을 타이밍하거나 라이브 모델을 점수화하지 않았습니다.
당신의 저장소는 실제 파일 경로를 제공해야 합니다.
결과를 게시하는 방법
풀 리퀘스트에 에이전트의 칭찬을 붙여넣지 마세요.
세 가지 반론, 반증자들, 그리고 당신 자신의 점수를 게시하세요.
팀원은 모델의 기분이 아니라 당신의 판결을 봐야 합니다.
짧은 댓글 형식(short comment shape)을 사용하고 지루하게 유지하세요.
- 상단에 한 문장으로 전제(premise)를 진술합니다.
- 열었던 파일 옆에 각 반론 ID를 나열합니다.
- 각 반증자를 재현됨(reproduced), 차단됨(blocked), 또는 폐기됨(dropped)으로 표시합니다.
- 병합(merge), 수정(revise), 또는 폐기(discard)로 끝내고, 추가 형용사는 생략합니다.
모든 행(row)을 삭제하더라도 실제 증명은 부족합니다.
빈 비평가(critic)만 있을 뿐, 조용한 승인(quiet approval)이 아닙니다.
모델의 침묵은 '조용한 예'가 아닙니다.
검토를 격리 구역에 두기 (Put the run in quarantine)
무료 서버 옵션에서 이견 통과(dissent pass)를 실행하세요.
이미 확인한 다이제스트(digest)에 해당 호스트를 고정(pin) 상태로 유지하세요.
이름을 지정할 수 없는 호스트에서는 코드를 검토하지 마세요.
해당 서버를 검토 기록의 격리 구역으로 취급하세요.
그 호스트가 여러분의 트리에 패치를 적용하도록 두지 마세요.
이견 로그(dissent log)를 복사한 다음, 검토 실행을 종료하세요.
만약 호스트 다이제스트가 누락되었다면, 토큰을 사용하지 마세요.
고정되지 않은 호스트는 소프트 검토와는 별개의 실패입니다.
먼저 고정을 수정하고, 모델에게 이견을 요청하세요.
이 게이트를 사용해서는 안 되는 경우 (Who should not use this gate)
이미 사람이 검토권을 가지고 있다면 이 워크플로우를 건너뛰세요.
두 번째 사람은 강제된 반대 목록보다 낫습니다.
에이전트는 오직 사람의 대기열(queue)이 병목 현상일 때만 사용하세요.
또한 다음 네 가지 경우에도 게이트를 건너뛰세요.
- 공식 보안 감사가 필요하며, 이 게이트는 그것이 아닙니다.
- 변경 사항이 주석만 있는 오타(typo)라면, 이견 제기는 낭비입니다.
- 명시된 파일을 읽을 수 없다면, 점수를 매길 수 없습니다.
- diff가 비밀 정보(secrets)를 요구한다면, 그 비밀 정보를 붙여넣지 마세요.
정책상 소스 코드를 호스팅 모델로 보내는 것이 금지되어 있다면 게이트를 건너뛰세요.
무료 서버 옵션이 여러분의 데이터 규칙을 지우지는 않습니다.
첫 토큰이 노트북을 떠나기 전에 현재 약관을 읽으세요.
README에 유지해야 할 제한 사항 (Limits you should keep in the README)
로컬 게이트는 주장의 진실성이 아니라 구조를 확인합니다.
모델은 여전히 세 가지 유창하고 거짓된 이의 제기를 생성할 수 있습니다.
여러분의 점수표(scoring table)만이 유일한 진실 단계이며, 이는 수동적입니다.
무료 접근은 어떤 약속 없이 변경되거나 사라질 수 있습니다.
릴리스를 영구적인 무료 등급에 의존하게 만들지 마세요.
어떤 경우든 계약과 게이트는 git에 보관하세요.
길이 확인(length check)은 얇은 텍스트의 거친 대리 지표입니다.
짧고 날카로운 주장은 여전히 유효한 이의 제기가 될 수 있습니다.
서면 재정의(written override)를 허용하고, 누가 그 재정의를 승인했는지 기록하세요.
이 문서는 실제 제품 벤치마크를 보고하는 것이 아닙니다.
YAML과 Python 코드는 실행해 볼 제안으로 간주하십시오.
게이트(gate)를 가르치기 전에 자체적인 종료 코드(exit code)를 저장하세요.
선을 지키세요 (Hold the line)
코딩 에이전트가 첫 번째 통과 합의만으로 병합하지 마십시오.
파일, 주장(claims), 그리고 반박자(falsifiers)가 포함된 이견 기록(dissent log)을 요구하십시오.
그 기록을 직접 점수 매긴 다음, diff를 열어놓고 결정하세요.
이러한 이견 검증 과정(dissent pass)을 위한 일회용 호스트가 필요하다면 MonkeyCode를 사용해 보세요.
무료 모델 접근과 무료 서버 옵션이 이러한 격리된 용도에 적합합니다.
게이트는 여러분의 레포지토리(repo)에, 그리고 판결은 여러분의 손에 두세요.