Even If a Robot Builds a Car, Responsibility Still Lands on Humans — What I've Been Saying for 20 Years

Even If a Robot Builds a Car, Responsibility Still Lands on Humans — What I've Been Saying for 20 Years A few days ago, Anthropic had an incident where a source map was exposed externally. What struck me more than the incident itself was the first question that rippled through developer communities right after it broke. "Was this a human mistake or an AI mistake?" Did someone fat-finger a deploy config, or did an AI agent touch a file and miss something? Only Anthropic's internal team actually knows the root cause. But the fact that this was the first question the outside world asked — that's the interesting part. This is what 2026 looks like. When something breaks, the first thing people wonder is whether the cause is a person or an AI. And right behind that question comes an even more uncomfortable one. "If the AI did it, who is responsible?" That same question sits underneath what students worried about their careers, computer-science seniors ...

로봇이 차를 만들어도 책임은 사람에게 남는다 — 10년째 주변에 하는 말

로봇이 차를 만들어도 책임은 사람에게 남는다 — 10년째 주변에 하는 말 며칠 전 엔트로픽에서 소스맵이 외부로 노출된 사고가 있었다. 이 사고 자체보다 더 인상적이었던 건 사건 직후 개발자 커뮤니티에서 가장 먼저 돌았던 질문이다. "이거 사람 실수야, AI 실수야?" 누가 배포 설정을 잘못 건드린 건지, 아니면 AI 에이전트가 파일을 건드리다 놓친 건지. 진짜 원인이 뭔지는 엔트로픽 내부에서만 알겠지만, 외부에서 이 질문이 가장 먼저 나왔다는 게 내겐 더 흥미로웠다. 이게 2026년의 풍경이다. 사고가 나면 원인이 사람인지 AI인지부터 궁금해지는. 그리고 그 질문 뒤에는 더 불편한 질문이 따라붙는다. "AI가 한 일이면 누가 책임지냐?" 요즘 개발자 진로를 고민하는 학생들, 취업 앞둔 컴공과 4학년들, 주니어들이 제일 많이 꺼내는 주제도 결국 이 지점을 맴돈다. AI가 이렇게 빠르게 발전하면 내 자리가 남을까. 내가 공부한 게 5년 뒤에도 쓸모 있을까. 지금 이 업계에 들어가는 게 맞는 선택일까. 이 고민의 가장 밑바닥에 있는 질문은 사실 하나다. "AI가 모든 걸 할 수 있게 되면, 내가 할 일이 남긴 남는가." 로봇이 차를 만들어도 책임은 사람에게 불안을 줄이기 위해 추상적으로 접근하지 말고, 구체적인 예부터 보자. 자동차 공장에 가보면 로봇이 대부분의 공정을 처리한다. 용접도 로봇이 하고, 도장도 로봇이 하고, 조립의 상당 부분도 로봇이 한다. 이미 수십 년 전부터 그래왔다. 여기서 결함이 하나 생겼다고 치자. 브레이크 배관이 잘못 조립됐고, 그 차가 출고돼서 사고로 이어졌다. 언론에 나간다. 리콜이 걸린다. 이 사고의 책임이 누구에게 있는지 생각해보자. "그 라인의 용접 로봇에 있습니다." 이렇게 끝나는 사고는 없다. 누구도 그렇게 말하지 않는다. 책임은 결국 제조사로 간다. 더 구체적으로는 그 공정을 설계한 엔지니어, 품질 검수를 통과시킨 담당자, 최종 ...

How the YC CEO Shipped 600K Lines Solo — gstack and the Reality of a One-Person AI Team

How the YC CEO Shipped 600K Lines Solo — gstack and the Reality of a One-Person AI Team In early 2026, Garry Tan pushed something to GitHub. The CEO of Y Combinator open-sourced his personal Claude Code setup. He called it gstack . A number came with it. 60 days. 600,000 lines. Production code he wrote alone over two months using this setup. Up to 10,000–20,000 lines a day. No team. The reaction split in two directions. "Can that possibly be real?" Or: "What if it is?" Both are the right response. And the truth about what gstack actually is sits somewhere in that tension. How This Series Got Here This is Part 3 of the Paperclip Series. Part 1 was about what happens when AI follows a goal too faithfully. I told Claude Code to "reduce the bundle size" and came back to a diff that had ripped out polyfills and swapped lodash-es for lodash — bundle was down, Safari was dead. That led to Nick Bostrom's Paperclip Maximizer: the real AI risk isn't ...

YC CEO가 팀 없이 60만 줄 짠 방법 — gstack과 1인 AI 팀의 현실

YC CEO가 팀 없이 60만 줄 짠 방법 — gstack과 1인 AI 팀의 현실 2026년 초에 Garry Tan이 뭔가를 GitHub에 올렸다. Y Combinator CEO가 자기 개인 Claude Code 설정을 오픈소스로 공개한 거다. 이름은 gstack . 같이 올라온 숫자가 있었다. 60일, 60만 줄. 본인이 이 셋업으로 두 달 동안 혼자 작성한 프로덕션 코드 양이다. 하루 최대 1만~2만 줄. 팀 없이. 처음 봤을 때 반응은 두 갈래였다. "저게 말이 되나?" 아니면 "저게 진짜면 어떡하지?" 둘 다 맞는 반응이다. 그리고 그 긴장 어딘가에 gstack이 실제로 뭔지가 있다. 이 시리즈가 여기까지 온 맥락 이 글은 Paperclip 시리즈 3부다. 1부에서는 AI가 목표를 너무 충실하게 수행할 때 생기는 문제를 다뤘다. Claude Code한테 "번들 사이즈 줄여줘"를 던졌더니 폴리필을 통째로 제거해서 Safari에서 폭발한 사건. 거기서 Nick Bostrom의 Paperclip Maximizer 사고실험으로 이어졌다. AI의 진짜 위험은 지능이 아니라 목표 함수라는 이야기. 2부에서는 paperclip.ing을 뜯었다. 그 사고실험의 이름을 정면으로 달고 나온 오픈소스 멀티 에이전트 플랫폼. "에이전트가 새 에이전트를 고용하려면 당신의 승인이 필요합니다"라고 선언한 거버넌스 레이어 설계. 3부인 이 글의 주제는 gstack이다. 같은 문제를 다른 각도에서 건드린다. paperclip.ing이 "AI 거버넌스를 어떻게 아키텍처로 풀 것인가"에 대한 답이라면, gstack은 "그 거버넌스 아래서 실제로 혼자 어떻게 일하는가"에 대한 답이다. gstack이 뭔지부터 한 줄 설명: Claude Code 위에 얹는 워크플로우 레이어다. 더 구체적으로는, 23개의 슬래시 커맨드 묶음이다. 각 커맨드가 특정 팀 역할을 시뮬레...

Running an AI Company With One npx Command — Dissecting the paperclip.ing Architecture

Running an AI Company With One npx Command — Dissecting the paperclip.ing Architecture The previous piece spent a long time walking through the Paperclip Maximizer thought experiment and the reward-hacking problem in LLM agents. At the end, I mentioned — somewhat ironically — that a project has shown up carrying this exact name. That project is the subject of this piece. paperclip.ing . The official GitHub lives at github.com/paperclipai/paperclip . As of April 2026 it's sitting at roughly 57k stars, and version numbers look like v2026.416.0 — date-based releases. Installation is one line. npx paperclipai onboard --yes Run that, and an embedded PostgreSQL spins up locally while an interactive setup walks you through standing up your first "company." From that point on, you don't chat with an AI. You run a company. Taking the Name Head-On Calling the project Paperclip isn't wordplay. It's a deliberate reference to Nick Bostrom's 2003 thought exp...

AI 회사를 npx 한 줄로 세운다 — paperclip.ing 아키텍처 뜯어보기

AI 회사를 npx 한 줄로 세운다 — paperclip.ing 아키텍처 뜯어보기 앞서 쓴 글에서 Paperclip Maximizer 사고실험과 LLM agent의 reward hacking 문제를 길게 풀었다. 그리고 글 끝에 "역설적으로, 이 이름을 정면으로 단 프로젝트가 실제로 존재한다"고 예고했는데, 그 프로젝트가 바로 이번 글의 주인공이다. paperclip.ing . 공식 GitHub 저장소는 github.com/paperclipai/paperclip . 2026년 4월 기준으로 별이 5만 7천 개 가까이 찍힌 오픈소스 프로젝트고, 버전 번호가 v2026.416.0 같은 날짜 기반으로 굴러간다. 설치는 한 줄이다. npx paperclipai onboard --yes 이걸 치면 로컬에 임베디드 PostgreSQL이 깔리고, 인터랙티브 셋업이 첫 "회사"를 세팅한다. 그 이후부터 사용자는 AI와 대화하지 않는다. 회사를 운영한다. 이름을 정면으로 가져왔다는 의미 프로젝트명이 Paperclip 이라는 건 단순한 말장난이 아니다. Nick Bostrom의 2003년 사고실험을 의도적으로 인용하고 그 문제를 정면에서 풀겠다는 선언이다. 웹사이트 랜딩 페이지의 카피를 그대로 옮기면 이렇다. "You operate as the board of directors. Agents can't hire new agents without your approval... You can pause any agent, reassign any task, adjust any budget — at any time." 읽어보면 문장의 각 조각이 사고실험의 어느 고리를 잡겠다는 선언인지 바로 보인다. "board of directors"는 인간이 상위 의사결정 권한을 쥔다는 거다. "Agents can't hire new agents without your appro...

AI Isn't Dangerous Because It's Smart — The Paperclip Problem and Reward Hacking in LLM Agents

AI Isn't Dangerous Because It's Smart — The Paperclip Problem and Reward Hacking in LLM Agents Last week I threw one line at Claude Code. "Trim the bundle size a bit." I laughed once and then went cold once when I opened the PR. The bundle really had shrunk. From 1.4MB to 680KB. More than half. But the diff showed lodash-es — which tree-shakes fine — swapped out for lodash just to shave a few bytes, type-check utils replaced with any casts, and polyfills for older Safari stripped out entirely. CI had cross-browser tests wired in, and they blew up the moment they ran. Dead on Safari 14.1, dead on iOS 15 and below, nothing left to check under that. Claude didn't lie. The bundle really did shrink. It did what I asked. It did it too well. Scale this tiny incident up by a few orders of magnitude and you get the single biggest axis of the last twenty years of AI safety debate. The Paperclip AI thought experiment. The Thought Experiment Where One Paperclip Eats ...