드리프트
드리프트는 왜 죽지 않는가
드리프트는 고쳐도 다시 돌아온다. 비즈니스 로직을 SSOT로 닫았더니, 그 SSOT를 만드는 생성기에서 똑같은 드리프트가 한 층 위로 올라왔다. 왜 이건 죽지 않는가를 엔트로피에서부터 다시 쌓는다.
당신의 에이전트 루프는 왜 발산하는가
Loop Engineering이 보편화될수록 사람들은 같은 벽에 부딪힌다 — 루프가 수렴하지 못하고 발산한다. 무한 회전·드리프트·리워드 해킹, 세 얼굴의 뿌리는 하나다. 루프의 판정 슬롯에 생성자 자신을 다시 꽂은 것. 그런데 발산은 차라리 운이 좋다. 보이니까. 진짜 무서운 건 조용히 거짓 수렴한 루프다. 처방은 하나 — 완료를 잠그는 권한을 LLM이 아니라 결정론적 게이트에만 둔다.
왜 당신의 에이전트는 멈추지 않는가
에이전트를 24시간 돌린다는 자랑 앞에서 드는 감각은 감탄이 아니라 의문이다 — 왜 아직 안 끝났지? 코드는 탐색 문제가 아니라 제약 충족 문제다. 멈출 수 있는 시스템이 건강한 시스템이다.
Supabase는 바이브 코딩의 함정이다
AI가 Supabase를 추천하는 이유는 기술적 우월성이 아니라 훈련 데이터에 튜토리얼이 많아서다. 비즈니스 로직이 블랙박스에 들어가면 에이전트가 추적하지 못한다. 들어가는 건 30초, 나오는 건 3개월.
제 2강. AI를 못 믿는 법 — 바이브 코딩의 한계와 원인
AI가 새 기능을 추가하면서 기존 기능을 조용히 바꿔버리는 드리프트, 58%의 아첨 편향, 97%가 5번 곱해지면 86%가 되는 수학. 왜 5개 기능에서 무너지는가.
Reins Engineering — 고삐 있는 AI
하네스 엔지니어링은 울타리다. 에이전트가 밖으로 못 나가게 할 뿐, 목적지에 도달하게 하지 않는다. Reins Engineering은 고삐다 — 결정론적 계약으로 방향을 잡고, 래칫으로 잠그고, 결정과 구현을 분리한다.
Hurl이 바이브 코딩의 드리프트를 막는다
바이브 코딩은 3개월 만에 로직 드리프트로 무너진다. CMU, METR, DORA, Amazon 사례가 이를 증명한다. Hurl로 API 계약을 plain text로 선언하고 래칫으로 잠그면, AI의 자유를 제한하지 않으면서 드리프트를 구조적으로 억제한다.