출처 https://www.youtube.com/watch?v=96jN2OCOfLs · 채널 Sequoia Capital (AI Ascent) · 길이 29:49 포맷 Stephanie Zhan(Sequoia)이 진행하는 노변 대담. 게스트는 Andrej Karpathy(OpenAI 공동창업, Tesla 오토파일럿, “vibe coding” 작명). 화면은 무대 위 두 사람과 “AI Ascent” 배경뿐이라 슬라이드는 없다. 원본 자막: 2026-06-20-karpathy-vibe-coding-to-agentic-engineering (raw/transcripts)
한눈에 보는 요약
- “프로그래머로서 이렇게까지 뒤처진 느낌은 처음”의 정체는 12월의 변곡점이다. 1년 가까이 agentic 코딩 도구를 써왔지만, 작년 12월 들어 “청크가 그냥 잘 나오기 시작”하고 교정한 기억이 사라지면서 Karpathy는 시스템을 점점 더 믿게 됐다 — 그게 vibe coding이다. AI를 ChatGPT로만 경험한 사람은 “12월 기준으로 다시 봐야” 한다. agentic coherent workflow가 비로소 실제로 작동하기 시작한 시점이라서다.
- 소프트웨어 1.0→2.0→3.0: 프로그래밍이 프롬프팅으로 바뀐다. 1.0은 코드를 직접 쓰는 것, 2.0은 데이터셋·신경망으로 프로그래밍하는 것, 3.0은 컨텍스트 윈도우가 “LLM 인터프리터를 조종하는 레버”가 되는 것. OpenClaw 설치가 셸 스크립트가 아니라 “에이전트에 복붙할 텍스트”인 것, MenuGen이 Nano Banana 한 줄 프롬프트로 사라지는 것이 그 증거다.
- 검증 가능성 = 자동화 가능성. 전통 컴퓨터가 “코드로 명시 가능한 것”을 자동화했다면, 이번 세대 LLM은 “검증 가능한 것”을 자동화한다. 그래서 모델은 math·code처럼 검증 가능한 영역에서 뾰족하게 peak하고 나머지는 거친(jagged) 모습을 보인다.
- 모델은 “랩의 자비”에 달려 있다. GPT-3.5→4의 체스 실력 향상은 능력 진보가 아니라 누군가 체스 데이터를 pre-training에 넣었기 때문. 매뉴얼 없는 도구를 탐색해 내가 어느 RL 회로(circuit) 안에 있는지 파악하고, 회로 밖이면 직접 fine-tuning해야 한다.
- vibe coding은 바닥을, agentic engineering은 천장을 다룬다. 전자는 누구나 뭐든 만들 수 있게 floor를 올리고, 후자는 기존 전문 소프트웨어의 품질 바를 보존한다. 빠르게 가되 취약점을 들이지 않고 책임진다 — 잘하는 사람의 생산성은 “10x를 한참 넘는다.”
- 사람의 몫은 taste·spec·oversight다. 에이전트는 미학이 RL에 없어 코드가 bloated·brittle·“gross”하다. 우리는 동물이 아니라 유령(ghost)을 소환하는 중이라, 야단쳐도 더 잘 동작하지 않는다 — 의심하며 다루는 마인드셋이 필요하다.
- 마무리는 교육과 “이해.” “사고는 외주 줄 수 있어도 이해는 외주 줄 수 없다.” 무엇을 왜 만드는지 아는 사람이 병목이 되고, Karpathy는 그래서 LLM 지식 베이스(위키) 에 흥분한다 — 정보를 처리하고 이해를 강화하는 도구로서. (이 볼트가 따르는 바로 그 LLM 위키 패턴이다.)
장면별 상세 설명
[00:00] 1. 소개 — “프로그래머로서 이렇게 뒤처진 느낌은 처음”
Stephanie Zhan은 Karpathy를 “현대 AI를 만들고, 설명하고, 가끔 이름까지 바꾼” 사람으로 소개한다 — 바로 이 사무실에서 OpenAI를 공동창업했고, Tesla에서 오토파일럿을 동작시켰으며, 가장 복잡한 기술 전환을 “접근 가능하면서도 필연적으로” 느끼게 만드는 재능이 있다고. 작년에 “vibe coding”이라는 말을 만든 그가, 최근 더 놀라운 말을 했다: 프로그래머로서 이렇게까지 뒤처진 느낌은 처음이라는 것. 대담은 거기서 출발한다.
[00:47] 2. 12월이라는 변곡점 — 그래서 vibe coding
그 감정은 “흥분 반, 불안 반”이다. Karpathy는 1년 가까이 agentic 도구들을 써왔다 — 코드 청크는 잘 뽑아내되 종종 망쳐서 직접 고쳐야 했고, 그럭저럭 도움이 되는 정도였다. 그런데 작년 12월이 명확한 전환점이었다. 마침 휴식기라 시간이 더 있었는데, 최신 모델로 가니 “청크가 그냥 잘 나오기 시작”했다. 더 요청해도 잘 나왔고, 마지막으로 교정한 게 언제인지 기억나지 않는 지점에 이르자 시스템을 점점 더 믿게 됐다 — 그게 vibe coding이었다.
그는 이걸 X(트위터)에서 강조하려 애썼다고 한다. 많은 사람이 AI를 작년 “ChatGPT 비슷한 무언가”로 경험했지만, 12월 기준으로 다시 봐야 한다는 것. 무언가가 근본적으로 바뀌었고, 특히 “agentic coherent workflow”가 비로소 실제로 작동하기 시작했기 때문이다. 그 깨달음이 그를 끝없는 사이드 프로젝트의 토끼굴로 밀어 넣었고, 이후로 그 여파를 관찰하는 중이다.
[02:28] 3. 소프트웨어 1.0 → 2.0 → 3.0 — 프로그래밍이 프롬프팅이 된다
Karpathy가 오래 말해 온 명제 — LLM은 더 나은 소프트웨어가 아니라 새로운 컴퓨터다. 소프트웨어 1.0은 코드를 직접 쓰는 것, 2.0은 데이터셋과 목적함수·아키텍처를 배열해 신경망을 학습시키는 “프로그래밍”이다. 그리고 충분히 큰 과제 집합으로 GPT/LLM을 학습시키면 — 인터넷으로 학습하며 모든 것을 멀티태스킹해야 하므로 — 그 모델은 일종의 프로그래밍 가능한 컴퓨터가 된다. 소프트웨어 3.0에서 프로그래밍은 프롬프팅으로 바뀌고, 컨텍스트 윈도우가 “당신의 컨텍스트를 해석해 디지털 정보 공간에서 연산을 수행하는 인터프리터(=LLM)를 조종하는 레버”가 된다.
구체적인 예가 두 개다. 첫째, OpenClaw 설치. 보통이라면 다양한 플랫폼을 노리느라 비대해진 셸 스크립트일 텐데 — 그건 여전히 “코드를 쓰려는” 소프트웨어 1.0의 우주다 — 실제 설치는 에이전트에 복붙할 텍스트 한 덩이다. 에이전트가 자기 지능으로 환경을 살피고, 지시를 따르고, 루프 안에서 디버깅하며 일을 되게 만든다. 그래서 새 프로그래밍 패러다임의 질문은 “에이전트에 복붙할 텍스트가 무엇인가?” 가 된다.
[04:51] 4. MenuGen과 Nano Banana — “내 앱은 존재하면 안 됐다”
두 번째 예는 더 극단적이다. Karpathy는 MenuGen을 만들었다 — 식당 메뉴판 사진을 올리면 각 메뉴가 어떻게 생겼는지 그림을 보여주는 앱. 그는 이걸 Vercel에서 돌아가는 앱으로 직접 코딩했다(제목 OCR → 이미지 생성기로 그림 → 재렌더링). 그런데 소프트웨어 3.0 버전을 보고 머리가 띵했다: 그냥 사진을 Gemini에 주고 “Nano Banana로 이 그림들을 메뉴 위에 오버레이해”라고 말하면 끝. 모델이 내가 찍은 바로 그 메뉴판 픽셀 위에 각 항목을 그려 돌려준다.
요점은 충격적이다 — “내 MenuGen 전체가 spurious(불필요)다. 옛 패러다임에서 돌아갈 뿐, 그 앱은 존재하면 안 됐다.” 신경망이 일을 점점 더 많이 하고, 프롬프트(=이미지)가 입력, 출력도 이미지이며, 그 사이의 앱은 필요 없다. 그는 사람들이 “기존 패러다임의 속도 향상”으로만 생각하지 말라고 당부한다 — 더 빨라지는 게 아니라 이전엔 불가능했던 새로운 것들이 가능해졌다는 게 더 흥분되는 지점이다. 일례로 그의 LLM 지식 베이스 프로젝트: 문서 더미를 다른 방식으로 “재컴파일”해 위키를 만드는 일은 예전엔 그걸 해줄 코드가 없어서 존재할 수 없었다.
[07:37] 5. 외삽 — 신경망이 host, CPU가 co-processor가 되는 “뉴럴 컴퓨터”
“90년대의 웹사이트, 2010년대의 모바일 앱, 클라우드 시대의 SaaS에 해당하는 2026년판은 무엇이고, 나중에 돌아보면 당연한데 지금은 대부분 안 만들어진 것은?” Karpathy의 외삽은 기묘하다. raw 비디오·오디오를 신경망에 통째로 넣고 diffusion으로 그 순간에 고유한 UI를 렌더하는 “뉴럴 컴퓨터” 를 상상할 수 있다는 것.
그는 컴퓨팅 초창기를 끌어온다. 50·60년대엔 컴퓨터가 계산기를 닮을지 신경망을 닮을지 불분명했고, 결국 계산기(고전 컴퓨팅)의 길로 갔으며 신경망은 지금 그 위에서 가상화돼 돌아간다. 그런데 이게 뒤집혀 신경망이 host process가 되고 CPU가 co-processor가 될 수 있다 — 지능 연산이 신경망으로 옮겨가며 flops 지출의 대부분을 차지하게 되는 그림이다. 도구 사용은 일부 결정론적 작업을 위한 “역사적 부속물”로 남고, 진짜 쇼를 돌리는 건 네트워크로 엮인 신경망들. 다만 한 번에 가는 게 아니라 조각조각(piece by piece) 갈 것이고, 그 경로는 아직 미정이다.
[09:41] 6. 검증 가능성 — LLM은 “검증할 수 있는 것”을 자동화한다
핵심 프레임: 전통 컴퓨터는 “코드로 명시할 수 있는 것”을 쉽게 자동화했고, 이번 세대 LLM은 “검증할 수 있는 것”을 쉽게 자동화한다. 프런티어 랩이 이 모델들을 거대한 강화학습 환경에서 검증 보상으로 학습시키기 때문에, 모델은 math·code처럼 검증 가능한 영역에서 뾰족하게 peak하고 그 바깥에서는 거칠어진다(jagged).
왜 jagged한가에는 두 축이 있다. 하나는 랩이 모델을 어떻게 학습시키느냐, 다른 하나는 랩이 무엇에 신경 써서 데이터 분포에 무엇을 넣느냐다. 코드는 경제적 가치가 커서 환경이 많이 만들어진 좋은 예고, 반대로 검증은 가능하지만 별로 유용하지 않아 믹스에 못 든 영역도 많다. 결국 jaggedness는 “검증 가능성 + 랩이 신경 쓰는지”의 조합이다.
[11:18] 7. Jagged intelligence — 세차장까지 걸어가라는 SOTA 모델
오래된 예가 “strawberry에 r이 몇 개?”였고 모델은 이를 자주 틀렸다(지금은 패치됨). 새 예는 이렇다: “50m 떨어진 세차장에 세차하러 가는데, 운전할까 걸을까?” SOTA 모델은 “가까우니 걸어가라”고 답한다 — 세차하러 가는 맥락을 놓친 채. Opus 4.7이 10만 줄 코드베이스를 리팩터링하고 제로데이 취약점을 찾으면서, 동시에 세차장은 걸어가라고 하는 게 어떻게 가능한가. 이 정신 나간 간극이 jaggedness의 본질이다.
모델이 jagged하게 남아 있는 한 두 가지 신호다: (1) 무언가 살짝 어긋나 있거나, (2) 사람이 루프 안에 어느 정도 머물며 이들을 도구로 다루고 무엇을 하는지 계속 주시해야 한다는 것.
[12:25] 8. 체스 일화 — 우리는 “랩의 자비”에 달려 있다
교훈적인 일화 하나. GPT-3.5에서 GPT-4로 가며 체스 실력이 크게 늘었는데, 많은 사람이 “능력의 자연스러운 진보”로 여겼다. 하지만 실은 누군가 엄청난 양의 체스 데이터를 pre-training에 넣었기 때문이다 — 데이터 분포에 들어왔다는 이유만으로 기본값보다 훨씬 향상된 것.
그래서 우리는 랩이 무엇을 믹스에 넣느냐에 다소 좌우된다. 매뉴얼 없는 도구를 받아 직접 탐색해야 하고, 어떤 설정에선 되고 어떤 설정에선 안 된다. RL의 일부였던 회로(circuit) 안에 있으면 날아오르고, 데이터 분포 밖 회로에 있으면 고전한다. 내 응용이 어느 회로에 있는지 파악하고, 회로 밖이라면 fine-tuning과 자체 작업을 진지하게 봐야 한다 — 그건 LLM에서 그냥 튀어나오지 않는다.
[13:36] 9. 창업자에게 — 검증 가능하면 레버를 당길 수 있다, “결국 모든 게 자동화 가능”
“랩이 math·code 같은 명백한 영역에서 escape velocity에 도달한 지금, 창업자라면?” Karpathy의 답: 검증 가능성은 현 패러다임에서 무언가를 tractable하게 만든다 — RL을 대량으로 쏟아부을 수 있기 때문이다. 그리고 이건 랩이 직접 그 영역에 집중하지 않아도 참이다. 검증 가능한 설정에서 다양한 RL 환경·예시를 직접 만들 수 있다면, 자체 fine-tuning으로 레버를 당겨 꽤 잘 작동하는 결과를 얻을 수 있다. “그건 그냥 작동하는 기술”이다.
그는 “매우 유망한 도메인이 하나 있다”면서도 “무대에서 vague하게 던지긴 싫다”며 답을 아낀다. 반대로 “멀리서만 자동화 가능해 보이는 것”은? — 글쓰기 같은 것도 LLM 판사들의 council을 두면 어느 정도 합리적인 결과를 끌어낼 수 있으니, 결국 쉬우냐 어려우냐의 문제일 뿐이다. 결론은 한 단어다: “모든 게 자동화 가능하다(Everything is automatable).”
[15:45] 10. vibe coding vs agentic engineering — 바닥과 천장
둘은 다르다. vibe coding은 모두의 바닥(floor)을 올린다 — 누구나 무엇이든 vibe code할 수 있고, 그건 놀랍다. agentic engineering은 기존 전문 소프트웨어의 품질 바(ceiling 쪽)를 보존한다. vibe coding을 한다고 취약점을 들여선 안 되고, 소프트웨어에 대한 책임은 예전과 똑같이 진다 — 다만 더 빠르게 갈 수 있다(스포일러: 갈 수 있다). 문제는 “어떻게 제대로 하느냐”다.
그가 이걸 “엔지니어링 분과”라 부르는 이유: 에이전트는 뾰족하고(spiky) 약간 stochastic하며 다소 fallible하지만 극도로 강력한 엔티티다. 품질 바를 희생하지 않으면서 이들을 조율해 더 빠르게 가는 것 — 그걸 제대로 해내는 게 agentic engineering의 영역이다. 그리고 그 천장은 매우 높다. 예전의 “10x 엔지니어”보다 훨씬 증폭돼, 잘하는 사람은 10x를 한참 넘어선다는 게 그의 현재 체감이다.
[17:20] 11. AI 네이티브 코더와 채용 — 퍼즐 대신 “큰 프로젝트를 줘라”
Sam Altman이 작년 AI Ascent에서 했던 말 — 세대마다 ChatGPT를 다르게 쓴다(30대는 구글 검색 대체, 10대는 인터넷의 관문) — 의 코딩판은? mediocre한 사람과 완전한 AI 네이티브의 차이는 결국 가용한 도구를 최대한 끌어내고, 모든 기능을 쓰고, 자기 셋업에 투자하는 것이다. 예전에 Vim이나 VS Code를 길들였듯 이제 Claude Code·Codex를 길들이는 것.
이어 채용 이야기. 사람들은 강한 agentic 엔지니어를 뽑고 싶어 하면서도 채용 프로세스를 리팩터링하지 않았다. 퍼즐을 풀게 한다면 옛 패러다임이다. 그가 보는 채용은 이렇다 — “큰 프로젝트를 주고 구현하는 걸 지켜봐라.” 예컨대 “에이전트용 Twitter 클론”을 쓰게 하고, 정말 좋고 안전하게 만들게 한 뒤, 에이전트들로 활동을 시뮬레이션한다. 그다음 codex 5.4 xhigh 10개를 풀어 그 사이트를 깨보게 하고, 깨지지 않아야 통과다. 더 큰 프로젝트를 짓고 도구를 활용하는 모습을 보는 것이 그가 주목할 지점이다.
[19:29] 12. 사람의 몫 — taste·spec·oversight, 그리고 MenuGen의 이메일 버그
“에이전트가 더 많이 할수록 더 가치 있어지는 인간 능력은?” 지금의 답은 미학·판단·취향·약간의 감독이다. 그가 드는 에이전트의 기묘함: MenuGen에선 Google 계정으로 가입하고 Stripe로 크레딧을 사는데, 둘 다 이메일이 있다. 에이전트는 영속적인 user ID 없이 Stripe 이메일을 Google 이메일에 매칭하려 했다 — 둘이 다른 이메일이면 자금이 연결되지 않는다. “왜 임의로 바뀔 수 있는 이메일로 자금을 교차 대조하지?” 이런 실수를 아직 한다.
그래서 사람은 spec과 plan을 책임져야 한다. 그는 plan mode를 딱히 좋아하진 않지만(물론 유용하다), 더 일반적으로 에이전트와 함께 매우 상세한 spec(=문서)을 설계하고 에이전트가 그걸 채우게 하는 방식을 가리킨다. 본인은 top-level 카테고리와 감독을 맡고, 세부는 에이전트가 처리한다. 텐서 API의 잗다란 디테일(keep_dims vs keepdim, dim vs axis, reshape/permute/transpose)은 그도 이제 기억하지 않는다 — recall이 좋은 “인턴”이 처리하니까. 다만 텐서의 view와 storage 같은 펀더멘털은 이해해야 메모리를 불필요하게 복사하지 않는다. taste·engineering·design은 사람이, 빈칸 채우기는 에이전트가.
[22:13] 13. taste는 덜 중요해질까 — 모델은 micro GPT를 단순화하지 못한다
“이 taste·판단이 시간이 갈수록 덜 중요해질까, 아니면 천장이 계속 오를까?” Karpathy는 개선되길 바란다. 지금 안 되는 건 미학이 RL에 들어 있지 않아서 — 미학에 대한 비용·보상이 없거나 충분치 않다. 실제로 코드를 들여다보면 가끔 심장마비가 온다: 굉장히 bloated하고, copy-paste가 많고, 깨지기 쉬운 어색한 추상화가 있고, “작동하긴 하는데 그냥 정말 gross하다.”
좋은 예가 그의 micro GPT 프로젝트다 — LLM 학습을 최대한 단순하게 만들려는 시도인데, 모델이 이걸 싫어한다. “더 단순화해, 더 단순화해” 아무리 프롬프트해도 못 한다. RL 회로 밖이라 광속이 아니라 “이를 뽑는(pulling teeth)” 느낌이다. 결론은 비슷하다 — 사람이 여전히 이 영역을 책임지지만, 이를 막는 근본적 장벽은 없다. 랩이 아직 안 했을 뿐이다.
[23:31] 14. Animals vs ghosts — 우리는 동물이 아니라 유령을 소환한다
Karpathy의 또 다른 글의 프레임: 우리는 동물을 만드는 게 아니라 유령을 소환한다. 이들은 데이터와 보상 함수로 빚어진 jagged한 지능이지, 진화가 준 내재 동기·재미·호기심·empowerment로 빚어진 존재가 아니다.
왜 이 프레임이 중요한가? 이것들이 무엇이고 무엇이 아닌지 좋은 모델을 가지면 더 유능하게 쓸 수 있기 때문이다. 그는 이게 “실질적 힘(real power)“이 있는지는 모르겠고 약간의 철학이라고 솔직히 인정한다. 다만 핵심은 이들이 동물 지능이 아님을 받아들이는 것이다 — 야단친다고 더 잘 동작하거나 더 못 동작하지 않는다. 전부 통계적 시뮬레이션 회로일 뿐이고, 기질은 pre-training(=통계)이며 그 위에 RL이 볼트온된다. 그래서 그가 갖는 태도는 거창한 5가지 처방이 아니라, 의심하며(suspicious) 시간을 두고 파악해 가는 마인드셋이다.
[24:16] 15. 권한을 가진 에이전트 — agent-native 인프라와 sensors/actuators
이제 에이전트는 채팅만 하지 않고 실제 권한과 로컬 컨텍스트를 갖고 우리 대신 행동한다. 모두가 이 agentic-native 환경에 흥분하지만, 모든 게 여전히 인간을 위해 쓰여 있어 다시 쓰여야 한다. 그의 가장 큰 pet peeve: 프레임워크·라이브러리 문서가 인간용이라는 것 — “왜 사람들이 아직도 나한테 뭘 하라고 하지? 난 아무것도 하기 싫다. 에이전트에 복붙할 게 뭐냐?” “이 URL로 가세요” 같은 안내를 볼 때마다 답답하다.
방향은 워크로드를 세계에 대한 sensor와 actuator로 분해하고, agent-native하게(에이전트에 먼저 설명) 만들며, LLM에 legible한 데이터 구조를 자동화하는 것이다. MenuGen 일화가 좋은 테스트다 — 정작 고생은 코드가 아니라 Vercel 배포(여러 서비스 설정, DNS 구성)였다. 프롬프트 하나로 “MenuGen을 빌드해”라고 하면 아무것도 손대지 않고 인터넷에 배포되는 날 — 그게 인프라가 agent-native해졌다는 신호다. 궁극적으로는 사람과 조직에 에이전트 대리(representation) 가 생겨서, “내 에이전트가 네 에이전트와 얘기해 미팅 디테일을 정하는” 세계로 간다.
[27:42] 16. 교육 — “사고는 외주 가능해도 이해는 불가능”
마지막 질문은 교육이다 — 지능이 싸지는 다음 시대에, 깊이 배울 가치가 남는 것은? Karpathy는 최근 머리를 떠나지 않는 트윗을 인용한다: “사고는 외주 줄 수 있어도, 이해는 외주 줄 수 없다(You can outsource your thinking, but you can’t outsource your understanding).”
그는 여전히 시스템의 일부이고, 정보는 어떻게든 그의 뇌로 들어와야 한다. 무엇을 만들려는지, 왜 할 가치가 있는지, 에이전트를 어떻게 지휘할지를 아는 데서 자신이 병목이 되고 있다고 느낀다. 그가 LLM 지식 베이스에 흥분한 이유도 여기 있다 — 정보를 처리하는 한 방식이고, 정보에 다른 projection을 비출 때마다 통찰을 얻기 때문이다. 기사를 읽으면 그 기사들로 위키가 쌓이고, 거기에 질문을 던진다. 이것들은 이해를 강화하는 도구다. LLM은 이해에 능하지 않으므로, 그건 여전히 사람이 유일하게 책임지는 몫이다. 그는 “몇 년 뒤 다시 와서, 우리가 루프에서 완전히 빠지고 이해까지 자동화됐는지 보고 싶다”며 마친다.
부록 — 실전 체크리스트
- “에이전트에 복붙할 텍스트가 무엇인가?”를 먼저 물어라. 설치·설정·온보딩을 셸 스크립트가 아니라 에이전트용 텍스트(스킬)로 설계한다.
- 새로 만들기 전에 “이 코드가 존재해야 하는가?”를 의심하라. MenuGen처럼 신경망이 통째로 대체할 수 있는 앱은 짓지 않는다.
- 검증 가능한 영역을 노려라. 검증 가능하면 RL을 쏟아부을 수 있고, 랩이 안 해주면 직접 RL 환경·데이터셋을 만들어 fine-tuning으로 레버를 당긴다.
- 내가 어느 RL 회로 안/밖에 있는지 탐색하라. 회로 안이면 날아오르고, 밖이면 직접 fine-tuning을 각오한다.
- 품질 바를 양보하지 마라. vibe coding으로 취약점을 들이지 않는다 — 소프트웨어 책임은 예전과 같다.
- 상세한 spec(=docs)을 에이전트와 함께 설계하고, 빈칸은 에이전트가 채우게 하라. top-level 카테고리와 oversight는 사람이 쥔다.
- 펀더멘털은 이해하고, API 디테일은 위임하라. (예: 텐서 view/storage는 알되
keepdim/axis같은 건 인턴에게.) - 채용은 퍼즐이 아니라 큰 프로젝트로. 만들게 하고, 에이전트로 부수려 시도해 견디는지 본다.
- 읽은 것을 LLM 지식 베이스(위키)로 쌓아 “이해”에 투자하라. 사고는 위임해도 이해는 위임할 수 없다.
원문 인용 모음
- [01:36] “And then I was vibe coding.”
- [01:53] “Things have changed fundamentally… especially on this agentic coherent workflow that really started to actually work.”
- [03:22] “Your programming now turns to prompting, and what’s in the context window is your lever over the interpreter that is the LLM.”
- [04:46] “What is the piece of text to copy-paste to your agent? That’s the programming paradigm now.”
- [06:02] “All of my MenuGen is spurious. It’s working in the old paradigm — that app shouldn’t exist.”
- [09:00] “The neural net becomes kind of like the host process, and the CPUs become kind of like the co-processor.”
- [10:07] “Traditional computers can easily automate what you can specify in code… this latest round of LLMs can easily automate what you can verify.”
- [11:41] “How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000-line code base or find zero-day vulnerabilities, and yet tells me to walk to this car wash? This is insane.”
- [13:01] “We are slightly at the mercy of whatever the labs are doing, whatever they happen to put into the mix.”
- [15:09] “Everything is automatable.”
- [15:57] “Vibe coding is about raising the floor for everyone… agentic engineering is about preserving the quality bar of what existed before in professional software.”
- [16:55] “People who are very good at this peak a lot more than 10x.”
- [18:47] “Hiring has to look like: give me a really big project and see someone implement that big project.”
- [22:42] “Sometimes I get a little bit of a heart attack… it’s very bloated and there’s a lot of copy-paste and awkward abstractions that are brittle. It works, but it’s just really gross.”
- [24:39] “If you yell at them, they’re not going to work better or worse — it doesn’t have any impact.”
- [25:53] “Why are people still telling me what to do? I don’t want to do anything. What is the thing I should copy-paste to my agent?”
- [27:16] “I’ll have my agent talk to your agent to figure out some of the details of our meetings.”
- [28:11] “You can outsource your thinking, but you can’t outsource your understanding.”
관련 노트
- 원본 자막: 2026-06-20-karpathy-vibe-coding-to-agentic-engineering
- 같은 “루프를 짜는 엔지니어링” 명제: 2026-06-14-boris-cherny-claude-code-future
- agentic engineering 전환: 2026-05-16-ai-coding-agentic-engineering-shift
- Karpathy가 흥분한 바로 그 패턴: moc-llm-wiki
- 주제 MOC: moc-ai-coding