Multiplayer agentic engineering — Arjun Singh, Superconductor

URL: https://www.youtube.com/watch?v=OL7kfezynJM 날짜: 2026-08-10 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

이 강연은 ==“에이전트가 아닌 사람과 에이전트가 어떻게 함께 일하는가”==에 초점을 맞춘다.

• 최근 많은 논의가 에이전트 자체에 집중되지만, 이러한 기술의 궁극적 목표는 사람의 삶과 생산성을 개선하는 것이다.
• Arjun Singh은 Superconductor 팀이 1년간 에이전트를 적극적으로 도입하면서 겪은 마찰과 병목을 해소한 6가지 실전 원칙을 공유한다.
• 팀 전체가 동일한 에이전트 세션을 공유하고, 외부 신호를 코드로 변환하며, 모델과 하네스에 비의존적으로 유지하는 방법을 구체적으로 설명한다.

Superconductor는 인간과 에이전트가 ==노트북·Slack·GitHub·미팅 등 어떤 인터페이스에서도 끊임없이 협업하는 멀티플레이어 에이전틱 엔지니어링==을 지향한다.

---

1. 모델과 하네스(Model/harness)에 대한 비의존성 유지

에이전트 도입의 첫 번째 원칙은 특정 모델이나 하네스에 얽매이지 않는 것이다.

1.1. 최고의 모델과 하네스는 매주 바뀐다

1. 변동성이 높은 최상위 모델

   1. 새 모델 등장: 갑자기 더 좋은 모델이 나와 기존 선택이 뒤바뀔 수 있다.
   2. 기존 모델 철회/제한: 선호하던 모델이 사라지거나 사용이 제한될 수 있다.
   3. 팀 플로우 보호: 모델 변경 하나로 전체 팀의 작업 방식이 뒤흔들려서는 안 된다.

2. 유연한 전환의 필요성

   1. Arjun은 “최고의 모델과 하네스가 주단위로 바뀔 수 있다”고 강조했다.
   2. 워크플로우 전체를 갈아엎지 않고도 모델을 바꿀 수 있는 구조가 필수적이다.

1.2. 오픈 웨이트 모델의 실용성

1. Superconductor의 실제 사용 사례

   1. GLM 5.2: 팀은 GLM 5.2에 매우 만족하며, 비용이 훨씬 저렴하다고 언급했다.
   2. 탐색과 통합의 용이성: 새로운 오픈 웨이트 모델을 쉽게 시험하고 통합할 수 있어야 한다.

2. 비용 대비 효과

   1. 상용 모델에만 의존하면 비용이 급증할 수 있다.
   2. 모델 간 전환이 자유로우면 저렴하고 성능 좋은 모델을 적시에 채택할 수 있다.

1.3. 토큰 판매자와의 인센티브 불일치

1. 공급자와 사용자의 목표 충돌

   1. 공급자의 목표: 토큰 판매자는 더 많은 토큰을 팔려 한다.
   2. 개발자의 목표: 고객의 삶을 개선하고 제품을 발전시키며 고객을 만족시키는 것이다.

2. 비용 통제

   1. 필요한 만큼 토큰을 지불할 수 있지만, 그 이상은 내지 않아야 한다.
   2. 모델을 자유롭게 전환할 수 있어야 공급자의 인센티브와 사용자의 이익 사이에서 균형을 유지할 수 있다.

3. 통제권 회복

   1. 다양한 모델과 하네스 사이에서 전환할 수 있으면, 팀은 에이전트 도구에 대한 통제권을 유지한다.
   2. Arjun은 이것이 Superconductor 제품에서 쉽게 가능하지만, 제품 사용 여부와 무관하게 원칙 자체가 중요하다고 말했다.

---

2. 모든 인간 인터페이스를 에이전트-인간 인터페이스로 전환

코딩 에이전트를 개인 노트북에서만 사용하는 것을 넘어, 팀의 모든 인터페이스에서 에이전트와 협업할 수 있게 해야 한다.

2.1. 노트북에 갇힌 코딩 에이전트의 문제

1. 기존 사용 패턴의 한계

   1. 개발자가 자신의 노트북에서만 에이전트를 사용한다.
   2. 동료는 동일한 에이전트 세션에 접근하거나 대화할 수 없다.
   3. 맥락과 작업 결과가 한 사람의 기기에 갇힌다.

2. 협업 차단

   1. 동료의 작업 상황을 실시간으로 파악하기 어렵다.
   2. 질문이나 피드백을 주고받기 위해 별도의 커뮤니케이션이 필요하다.

2.2. 슬랙봇으로의 확장과 그 한계

1. 슬랙봇의 장점

   1. 보편화된 접근 방식: Claude, Coda, Superconductor 모두 슬랙봇을 제공한다.
   2. 간단한 명령: “Hey, Coda bot, do XYZ”처럼 누구나 에이전트에게 지시할 수 있다.
   3. 공유 가능한 대화: 동료가 같은 봇과 대화할 수 있어 협업이 한결 나아진다.

2. 슬랙봇의 한계

   1. 새로운 울타리: 에이전트가 노트북에서 슬랙이라는 또 다른 단일 공간에 갇힌다.
   2. 업무 범위 제한: 모든 업무가 슬랙에서 일어나지 않으므로, 여전히 맥락 전환이 발생한다.
   3. Slack은 일부에 불과: Slack이 중요하지만, GitHub, 앱, 이메일, 미팅 등 다른 공간에서도 작업이 벌어진다.

2.3. 동일한 에이전트 세션을 모든 인터페이스에서 공유

1. 공유 세션의 원칙

   1. 인터페이스 무관성: Slack, Superconductor 앱, GitHub 등 어떤 인터페이스에서도 같은 세션에 접근할 수 있어야 한다.
   2. 맥락 지속성: 한 곳에서 시작한 작업을 다른 곳에서 이어 할 때 에이전트가 내용을 잊지 않는다.

2. 실제 플로우 예시

   1. Slack에서 시작: 팀이 Slack에서 세션을 시작해 협업한다.
   2. 데스크톱/모바일 앱으로 이어 작업: 더 엔지니어 중심의 환경에서 작업을 계속한다.
   3. GitHub에서 마무리: 동일한 세션의 결과를 GitHub에서 마무리한다.

3. 에이전트 기억의 일관성

   1. Slack에서 이루어진 대화와 변경 사항이 GitHub에서도 동일한 세션으로 이어진다.
   2. 사용자가 “왜 이렇게 했어?”라고 물으면, 에이전트는 이전 맥락을 바탕으로 답할 수 있다.

---

3. 에이전트 작업을 팀 전체에 가시화하고 협업 가능하게 만들기

에이전트의 작업 과정과 결과를 팀원 누구나 볼 수 있게 하면, 신뢰와 협업이 향상된다.

3.1. 세션 참여자와 알림 가시화

1. 누가 참여했는지 파악

   1. 티켓 상단에서 누가 에이전트 세션과 상호작용했는지 확인할 수 있다.
   2. 알림 수신자와 조회자 목록이 명확하게 드러난다.

2. 비기술 직군이 시작한 작업의 추적

   1. 고객지원 담당자가 티켓을 만들어도 엔지니어가 검토했는지 쉽게 확인할 수 있다.
   2. 작업이 엔지니어에 의해 검증되었는지 여부를 한눈에 파악할 수 있다.

3. 검토자의 원활한 개입

   1. 검토자가 스레드에 들어가 “왜 이렇게 구현했어?”라고 질문할 수 있다.
   2. 동일한 에이전트 세션이므로, Sergey의 답변을 기다리지 않고 에이전트에게 바로 질문할 수 있다.
   3. 답은 거의 항상 해당 스레드 안에 있다.

3.2. 아티팩트(artifact)로 작업 가시화

1. 아티팩트의 역할

   1. 작업이 어디서 시작되었든, 어디서 끝나든 에이전트는 스크린샷, 동영상 등의 아티팩트로 결과를 보여준다.
   2. 아티팩트는 인터페이스 간에 공유되므로 어디서나 볼 수 있다.

2. 맥락 전환 제거

   1. “이 이미지를 GitHub에서 봐야 하나, Slack에서 봐야 하나?” 하는 고민이 사라진다.
   2. 작업은 어디서나 보이고, 어디서든 협업할 수 있다.

3. 팀 전체의 상황 인지

   1. 에이전트가 생성한 내용을 팀원 모두가 실시간으로 확인할 수 있다.
   2. 이를 통해 불필요한 질문과 중복 작업을 줄인다.

---

4. 외부 신호를 팀이 빠르게 평가할 수 있는 코드로 전환

Slack 대화, 고객 통화, 이메일, Sentry 알림 등 외부 신호를 자동으로 수집하고 실행 가능한 코드로 바꾸어야 한다.

4.1. 외부 신호의 종류와 현재 문제

1. 다양한 입력 소스

   1. 커뮤니케이션: Slack 대화, 고객 온보딩 통화, 영업 통화, 내부 팀 회의.
   2. 운영 데이터: Sentry, 버그 트래커, 고객 이메일, 기능 요청.

2. MCP 연결만으로는 부족하다

   1. 에이전트가 이메일이나 Notion 등을 확인할 수는 있게 되었다.
   2. 하지만 “어떤 걸 처리할지”는 여전히 인간이 판단해야 한다.
   3. 사람이 수동으로 “이메일 48번”, “티켓 6000번” 등을 지정해야 하는 조정 비용이 남는다.

4.2. 자동 수집·우선순위·실행

1. Superconductor의 접근

   1. 외부 신호를 여러 경로로 자동으로 수집한다.
   2. 우선순위를 매기고, 적절한 행동으로 연결한다.
   3. 사람의 수동 조정을 최소화한다.

2. 신호→코드 파이프라인

   1. 단순히 정보를 모으는 것이 아니라 실행 가능한 티켓, PR, 문서로 변환한다.
   2. 팀은 빠르게 검토하고 출시할 수 있다.

4.3. 미팅 봇 사례

1. Google Meet 봇의 운영 방식

   1. 부스에서의 실증: Superconductor는 엑스포 부스에서 4시간짜리 Google Meet에 미팅 봇을 초대해 하루 종일 작동시켰다.
   2. 다양한 미팅 플랫폼 지원: Zoom, Microsoft Teams 등에서도 동일하게 사용할 수 있다.
   3. 지속적 경청: 봇은 미팅 내용을 듣고, 관련 문서를 생성하거나 기존 작업에 연결한다.

2. 자동 티켓 생성 사례

   1. 아이디어 포착: 참가자가 “코딩 에이전트가 완료를 보고하기 전에 자신의 결과를 평가할 명확한 기준을 갖춰야 한다”는 아이디어를 말했다.
   2. 수동 개입 없이 처리: 봇이 이 아이디어를 포착해 티켓을 생성하고 작업을 시작했다.
   3. 결과 확인: Arjun은 “지금 한 것을 스크린샷으로 찍어줘”라고 요청해, 티켓 양식에 acceptance criteria 필드를 추가한 결과를 확인했다.
   4. 검증: 라이브 프리뷰를 통해 실제로 성능이 개선되는지 검증할 수 있었다.

3. 미팅 봇의 실효성

   1. 온보딩이나 고객 통화 후 수십 개의 아이디어가 프로토타입으로 전환된다.
   2. 최소한의 인간 개입으로 출시 가능한 PR이 여러 개 나온다.
   3. “우리가 이야기하고, 결과를 보고, 출시한다”는 빠른 사이클을 실현한다.

---

5. 코드베이스를 분리된 클라우드 샌드박스에서 운영

에이전트와 코드베이스를 개인 노트북이 아닌 분리된 클라우드 환경에서 실행해야 한다.

5.1. ‘뚜껑 불안(lid anxiety)’ 제거

1. 개인 노트북 의존의 문제

   1. 노트북을 닫으면 작업이 중단될 수 있다.
   2. 사람들이 공항, 사무실 복도, 심지어 차 안에서 노트북을 들고 다니는 현상이 생긴다.
   3. Arjun은 Twitter에서 “운전하며 폰에 노트북을 테더링해 에이전트 작업을 지켜보는 사람”의 글을 본 적 있다고 언급했다.

2. 클라우드 이동의 효과

   1. Arjun이 6개월 된 아이를 두고 있어 노트북에 묶이고 싶지 않았던 것이 큰 동기가 되었다.
   2. 클라우드에서 에이전트가 항상 실행되므로 언제든 노트북을 닫을 수 있다.
   3. ‘뚜껑 불안’이라 불리는 스트레스가 사라진다.

5.2. 최소 권한과 보안 샌드박스

1. 노트북에서 실행하는 리스크

   1. 개발자 노트북에는 민감한 파일, 토큰, 비밀번호 등이 많다.
   2. 승인 플로우나 YOLO 모드가 있어도, 샌드박스 설정 실수로 생산 데이터베이스를 삭제할 수 있다.
   3. Arjun은 “staging인 줄 알고 production DB를 날려버리는” 시나리오를 예로 들었다.

2. 클라우드 샌드박스의 장점

   1. 최소 권한 원칙: 에이전트가 필요한 리소스에만 접근할 수 있다.
   2. 안전한 실험: 누구나 프로토타입과 아이디어를 안전하게 실행할 수 있다.
   3. 심리적 안정: 팀원들이 에이전트를 망설임 없이 사용할 수 있다.

3. 네트워크 샌드박스

   1. 접근 제어: 허용된 도메인과 금지된 도메인을 명확히 설정한다.
   2. 동적 허가: 새로운 벤더 문서가 필요하면, 티켓별 또는 프로젝트별로 일시적 접근을 부여할 수 있다.
   3. 데이터 유출 방지: 코드, 비밀, 콘텐츠가 불법적인 외부 경로로 유출되지 않도록 차단한다.
   4. YOLO 모드 부작용 방지: 자동 승인으로 인한 데이터 누출 가능성을 원천 차단한다.

5.3. 비기술 직군의 실제 작업 트리거

1. 고객지원·성장 담당자의 직접 참여

   1. 비개발자는 개발 환경을 갖추지 않았지만, 분리된 클라우드 샌드박스 덕분에 실제 작업을 트리거할 수 있다.
   2. Slack이나 Rabbit cell에서 “이거 고쳐줘(fix this)”라고 말하면 에이전트가 수정한다.

2. 간소화된 워크플로우

   1. 스크린샷으로 결과를 공유하고, 엔지니어가 검토 후 머지한다.
   2. 기존 Linear → PM 트라이지 → 개발자 할당 과정을 생략할 수 있다.
   3. 비기술 직군이 사용자 피드백과 버그를 직접 제품 개선으로 연결한다.

5.4. 환경 설정의 진화

1. 과거의 어려움

   1. 예전에는 전체 프로젝트를 분리된 샌드박스 환경에 설정하는 것이 매우 고통스러웠다.
   2. 이 때문에 많은 팀이 클라우드 기반 에이전트 환경으로 전환하지 못했다.

2. 현재의 가능성

   1. 에이전트가 환경 설정을 상당 부분 자동화할 수 있게 되었다.
   2. Superconductor는 자체 environment setup assistant를 운영한다.
   3. Cloud Coder나 Codex 등을 활용해도 같은 목표를 달성할 수 있다.

3. 권고

   1. Arjun은 “우리 제품을 쓰지 않더라도, 프로젝트를 이런 식으로 작동하게 만들기를 강력히 권한다”고 말했다.

---

6. 자체 코드베이스로 에이전트 벤치마크

에이전트를 선택할 때 공개 벤치마크가 아닌, 자신의 코드베이스에서 품질·비용·시간을 직접 측정해야 한다.

6.1. 벤치마크 방법

1. 대상 PR 선정

   1. 훌륭한 엔지니어링 작업을 대표하는 PR을 선택한다.
   2. 에이전트가 만든 PR, 인간이 만든 PR, 하이브리드 모두 포함할 수 있다.

2. 비교 지표

   1. 품질 대비 비용(quality vs cost): 같은 품질을 얻는 데 드는 비용.
   2. 품질 대비 시간(quality vs time): 같은 품질을 얻는 데 드는 시간.

3. 에이전트 선택의 유연성

   1. 평가하고 싶은 에이전트를 골라서 독립적으로 테스트한다.
   2. 결과는 팀의 실제 코드베이스와 업무 맥락에서 해석한다.

6.2. 외부 벤치마크의 한계

1. SWE-bench 등 공개 벤치마크

   1. 대부분 Python 기반 문제로 구성되어 있다.
   2. Superconductor는 Ruby on Rails 코드베이스를 사용하므로 직접 적용하기 어렵다.
   3. 전반적인 트렌드는 비교 가능하지만, 실제 결과는 매우 다를 수 있다.

2. 자체 코드베이스의 중요성

   1. 공개 벤치마크가 높은 모델이라도 우리 코드에서는 형편없을 수 있다.
   2. 팀의 언어, 프레임워크, 아키텍처에 맞는 평가가 필요하다.

6.3. Superconductor의 실제 결과

1. 품질-시간 분석

   1. Anthropic 에이전트: 꾸준히 품질이 좋아졌지만, 속도는 크게 빨라지지 않았다.
   2. Codex/Cursor: 상당히 빠르면서도 품질이 우수했다.
   3. 오픈 소스 모델: 시간이 지남에 따라 품질이 점점 좋아졌지만, 여전히 느렸다.

2. 품질-비용 분석

   1. Anthropic: Superconductor 기준으로 훨씬 비쌌다.
   2. Codex: 더 저렴하면서도 충분한 품질을 제공했다.

3. 행동 변화

   1. 데이터를 확인한 후 Superconductor는 기본 모델을 Codex로 전환했다.
   2. Fiable이 출시되었을 때는 잠시 기본 모델로 변경했다가, Fiable이 사라지자 다시 Codex로 돌아왔다.
   3. 모델 비의존성 덕분에 이러한 전환이 큰 업무 중단 없이 이루어졌다.

6.4. 실제 사용량과 비용 데이터

1. 지난 한 달 사용량

   1. 비교적 작은 팀이 한 달에 15억 토큰을 사용했다.
   2. Claude Code: 하루 평균 3,300회 실행, 토큰 비용은 $10,000 상당(플랜 할인 전 기준).
   3. Codex: Claude보다 4배 많은 세션을 사용했으며, 전체 비용은 Claude보다 저렴했다.

2. 현재 워크플로우

   1. 99.9%의 PR이 에이전트에 의해 대폭 생성되었다.
   2. 모든 PR은 인간이 리뷰한다.
   3. 대다수의 머지 작업은 Codex를 통해 이루어진다.
   4. GLM 5.2 사용 증가: 앞으로 GLM 5.2에 더 많이 투자할 계획이다.

3. 자동 라우팅의 전망

   1. 벤치마크 데이터를 바탕으로 작업별 최적 모델을 자동으로 라우팅하는 기능을 준비 중이다.
   2. 서드파티가 아닌 팀 자신이 “어떤 작업에 어떤 모델이 적합한지” 판단할 수 있다.

---

7. 마무리 권고사항 및 실천 포인트

7.1. 세 가지 핵심 권고

1. 코드베이스와 에이전트를 샌드박스에서 실행하라

   1. 분리된 클라우드 환경은 ‘뚜껑 불안’ 해소, 보안, 비기술 직군 참여를 모두 가능하게 한다.
   2. 이 강연에서 다룬 거의 모든 워크플로우의 기반이 된다.

2. 관련 인간 인터페이스에 에이전트를 통합하라

   1. 팀과 에이전트가 맥락 전환 없이 협업할 수 있도록 한다.
   2. Superconductor 외에도 Slack봇, GitHub 통합, 미팅 봇 등 다양한 방식으로 구현할 수 있다.

3. 벤치마크를 만들고 모델 비의존적으로 유지하라

   1. 공개 벤치마크가 아닌 자체 코드베이스에서 품질·비용·속도를 측정한다.
   2. 새로운 모델이 나올 때마다 원활하게 전환하여 비용·속도·품질의 최적 frontier에 머무른다.

7.2. 연락처 및 부스 정보

1. Superconductor 부스

   1. 엑스포 부스를 방문해 데모와 질문을 나눌 것을 권했다.
   2. superagent.com에서 가입할 수 있다.
   3. 이메일 arjun@superagent.com으로 질문할 수 있다.
   4. 강연 후 뒤편에서 추가 질문에 응답할 예정이라고 안내했다.

2. MacBook Neo 경품

   1. 부스에서 MacBook Neo를 경품으로 제공한다.
   2. 가입을 통해 참여한 사람은 밖에서 만나 우승자를 발표한다고 언급했다.

---

주요 발언 모음

"If you go to the talks or go around the expo, you're going to see that a lot of people are talking about putting the agents at the center of everything. But you don't see a lot of people talking about the people." (강연장 곳곳에서 에이전트를 중심에 두는 이야기는 많지만, 그 기술을 사용하는 사람에 대한 이야기는 드물다.)

"The best model and harness can change weekly." (최고의 모델과 하네스는 주단위로 바뀔 수 있다.)

"We've taken it from trapped on somebody's laptop to kind of trapped in Slack." (에이전트를 한 사람의 노트북에 갇힌 상태에서 Slack이라는 새로운 울타리 안에 갇힌 상태로 만든 것에 불과하다.)

"The exact same agent session. So, it's like the agent didn't forget what you did in one place in Slack when you go and talk to it from GitHub." (정확히 동일한 에이전트 세션이므로, Slack에서 한 일을 GitHub에서 이어 대화할 때 에이전트가 잊지 않는다.)

"It's especially important when you have work triggered by non-technical people." (비기술 직군이 작업을 시작할 때 이런 가시성이 특히 중요하다.)

"We talk, stuff comes out, we look at it, we ship it." (우리는 이야기하고, 결과물이 나오고, 검토하고, 출시한다.)

"I don't ever want to think about whether I can step away from a laptop or not." (노트북에서 잠시 떨어질 수 있는지를 고민하고 싶지 않다.)

"You should only give your agents access to only what they need." (에이전트에게는 필요한 것만 접근 권한을 주어야 한다.)

"Essentially 99.9% of our pull requests are heavily agent generated." (거의 99.9%의 PR이 에이전트에 의해 대폭 생성된다.)

"We had 3,300 Claude code runs that cost $10,000 in tokens daily." (Claude Code를 하루 3,300회 실행했는데, 토큰 비용이 하루 $10,000 상당이었다.)

---

핵심 데이터 & 수치

• 팀 이력: Arjun Singh과 공동창업자 Sergey는 UC Berkeley 박사 과정에서 만나, 로봇공학과 컴퓨터 비전을 연구하며 GradeScope를 공동창업했다.
• GradeScope: 전 세계 수천 개 대학, 수백만 학생이 사용하는 채점 도구로 성장했다.
• Superconductor 팀 구성: 현재 Superconductor 팀원 대부분이 GradeScope에서 함께 일한 경험이 있다.
• 모델 비용 비교: Anthropic 에이전트는 Superconductor 코드베이스 기준으로 훨씬 비쌌고, Codex는 더 저렴하면서도 4배 많은 세션을 처리했다.
• 토큰 사용량: 작은 팀이 한 달에 15억 토큰을 사용했다.
• Claude Code 사용량: 하루 3,300회 실행, 토큰 비용은 플랜 할인 전 $10,000 상당.
• Codex 사용량: Claude보다 4배 많은 세션, 전체 비용은 Claude보다 낮음.
• PR 생성 비율: Superconductor의 99.9% PR이 에이전트에 의해 대폭 생성되며, 모든 PR은 인간이 리뷰한다.
• 미팅 봇 운영: 엑스po 부스에서 4시간짜리 Google Meet에 봇을 초대해 하루 종일 작동시켰다.
• 사용 모델 변화: 기본 모델을 Codex로 전환했고, Fiable 출시 시에는 잠시 기본 모델로 변경했다가 철회 후 Codex로 복귀했다.

---

결론 및 시사점

1. 에이전트의 중심은 사람이다: 에이전트 기술 자체가 아니라, 사람과 에이전트가 어떻게 협업하느냐가 핵심이다.
2. 모델 비의존성은 통제와 비용 효율의 기반이다: 모델과 하네스에 얽매이지 않으면 변화하는 생태계에서 자유롭게 이동할 수 있다.
3. 세션과 가시성이 협업을 만든다: 동일한 에이전트 세션을 여러 인터페이스에서 공유하고, 작업 과정과 결과를 팀 전체에 가시화하면 협업이 확장된다.
4. 외부 신호를 코드로 전환하는 자동화가 속도를 만든다: 미팅 봇과 같은 도구는 대화에서 아이디어를 포착해 티켓과 PR로 바로 연결한다.
5. 클라우드 샌드박스는 안전과 참여를 동시에 확보한다: ‘뚜껑 불안’을 없애고, 최소 권한과 네트워크 격리로 보안을 지키며, 비기술 직군도 실제 작업을 트리거할 수 있다.
6. 자체 코드베이스 벤치마크가 모델 선택의 근거가 된다: 공개 벤치마크를 대신해 품질·비용·시간을 직접 측정해야 의사결정의 오류를 줄인다.
7. 에이전트 생성 코드도 인간이 검토해야 한다: Superconductor는 99.9%의 PR이 에이전트가 대폭 생성하지만, 모든 PR은 인간 리뷰를 거친다.