이러한 프로젝트들이 실패하는 이유는 "바이브 코딩" 때문이 아닙니다. 에이전트가 로컬에서는 올바르지만 전역적으로는 잘못된 수정을 하기 때문입니다. 코드가 왜 존재하는지, 이전에 어떤 시도가 있었는지, 하위 시스템에서 어떤 문제가 발생하는지에 대한 기억이 없습니다. 더 나은 Rails에는 다음이 필요합니다. > 구조화된 메모리: 의존성 그래프, 호출 체인, 사람이 이해할 수 있는 소유권 경계 > 의미 유사성뿐 아니라 파급 효과를 고려한 검색 > 텍스트 신뢰도가 아닌 실행 기반 검증(테스트, 빌드) 에이전트가 전체 코드베이스 상태를 입력하고, 변경 사항을 안전하게 시뮬레이션하고, 실행 가능한 결과물로 정확성을 입증할 수 있게 되면, "코딩 방법을 아는 것"은 더 이상 걸림돌이 되지 않습니다. "무엇을 빌드해야 하는지" - 어떤 제약 조건 하에서, 어떤 절충안을 고려해야 하는지 - 이 문제가 중요해집니다. 관문은 코드 입력에서 판단과 코드 리뷰로 옮겨갑니다. 우리는 반드시 그 지점에 도달할 것입니다. 그것은 '언제'의 문제이지 '도달할지 말지'의 문제가 아닙니다.