The post has been translated automatically. Original language: Russian
Analysis of Andrey Karpaty's conversation with Stephanie Jean at Sequoia AI Ascent 2026 — through the prism of vibe coding and the AIstack course
A year ago, Karpaty coined the term "vibe coding". This year, on the Sequoia Ascent stage, he said something that sounds strange coming from the co-founder of OpenAI and the man who raised Autopilot at Tesla: he had never felt so laggy as a programmer.
I understand this feeling well. That's why I want to analyze the half-hour conversation not as another piece of news about AI, but as a map. It describes exactly what I've been doing with my hands for the last few months — and exactly what I'm building AIstack around.
The turning point happened in December
Karpaty names a specific point — December 2025. Before that, tools like Claude Code and Codex were useful, but they required constant editing: the model produced pieces of code, and they had to be cleaned. In November, he said, he wrote about 80% of the code with his hands. By December, the proportion had turned around: now the agents were doing about 80%, and he couldn't remember the last time he'd fixed something manually.
It was not a smooth upgrade, but a threshold passed. It looked the same for me: the folder with pet projects began to swell, because the cost of "trying an idea" dropped to almost zero. The unit of work is no longer a line of code. Now this is a macro action: implement the feature, refactor the subsystem, study the library, pick up the service, write tests and fix what fell.
Karpaty's main conclusion is that the profession is being rewritten. The programmer is less and less the author of the code and more and more the orchestrator of agents. If you haven't opened these tools since the fall of 2025, you're working on outdated assumptions about what's even possible.
The floor and ceiling are not a play on words
The most important part for me is the distinction between the two concepts.
Vibe coding raises the floor. It makes it possible for almost anyone to build a working application: you describe what you want, the model does it, and you don't proofread every line. It's great, and it's really changed the entry barrier.
Agentic engineering raises the ceiling. It's an engineering discipline.: how to coordinate agents — powerful entities, but erratic and stochastic — without lowering the quality bar. You're still responsible for your product. You still can't sneak in a vulnerability just because it's "so convenient." The question is how to move faster without losing control.
Karpaty puts it harshly: the old "10x engineer" is no longer about acceleration by a factor of 10. Those who have really mastered the orchestration of agents rise noticeably higher.
This is where my thesis takes place, which I have been repeating to clients and students for many months now: vibe coding is a passing wave. Not because it's bad, but because it's about gender. The next area is agents and engineering work with them. It's nice when one of the most respected people in the industry independently names the same thing and gives it a name.
Software 3.0: Context as a program
Karpaty completes his old frame. Software 1.0 — a person writes code. Software 2.0 — a person collects datasets and trains a neural network, the program is "hardwired" into weights. Software 3.0 — a person programs LLM itself: with promptness, context, tools, examples, and memory.
In this picture, the context window is the main lever, and the LLM is an interpreter that performs calculations on information.
His example with the OpenClaw installation was accurate. In the old world, an installer is a shell script that swells depending on the conditions for each OS and architecture. In Software 3.0, an installer is a block of text that you paste into an agent: he looks at your environment, performs actions, and makes mistakes along the way. Less accurate, but adaptive.
This is not a theory for me. I am building an MCP-first infrastructure and keeping several agents with shared roles. "Which piece of text should the agent insert" is now a part of programming. And separately, Karpaty reminds us: it's not just that coding has become faster. There are things that didn't exist before in principle. His example with LLM, a wiki system that incrementally reassembles a bunch of disparate documents into a live knowledge base, is not "speeding up old code." Previously, such a program simply did not exist.
I consider the question he suggests to be the most valuable for the founder: not "which existing process will accelerate AI," but "which information transformation was impossible — and became natural."
Jagged intelligence and why you can't leave the circuit
Next is the verification framework. Classical computers automate what can be specified by code. Current LLMs automate what can be verified. If the task has a success signal — tests, a reward, a measurable result — the model can be trained on it. That's why code, mathematics, and benchmarks are growing so fast.
Hence jagged intelligence. The model can refactor the code base for 100,000 lines or find a zero-day vulnerability — and in the same dialogue advise you to drive to the car wash, which is 50 meters away on foot. This is not a bug in the usual sense, it is a form of this intelligence: peaks where laboratories have invested in verifiable learning, and dips outside this zone.
The practical conclusion for those who build a product on this is that you need to understand which "rails" your task is in. If inside the trained distribution, the model flies. If someone stumbles on the outside, they need their own context, tools, additional training, or their own quality assessments. Karpaty highlights this separately as a startup opportunity: to find a valuable, verifiable, and at the same time understaffed domain and build your own RL environment there.
A skill that is not automated
His favorite example is from MenuGen. The user logs in via Google, and buys credits via Stripe. Both have email addresses. The agent wrote a "plausible" code: to match the payment with the account at the email address. But this is a bad system design — the emails may not match, and the person will not receive what they bought. We need a stable user ID. Agents still make such mistakes.
Therefore, the person remains the main one in terms of specification, design and taste. Karpaty doesn't remember by heart what the parameter is called — dim, axis, keepdim — and doesn't have to: the agent has an excellent recall for such details. But a person must understand the essence — that the tensor has storage, that the view divides memory, that unnecessary copying affects performance. You are responsible for making the system make sense. The agent fills in the blanks.
He honestly adds: when you look at the generated code, sometimes you grab your heart — it's bloated, copied, fragilely abstracted. It works, but it's ugly. Maybe future models will fix it. So far, this is a person's area of responsibility.
The bottleneck is understanding
We graduated from education, and here's a phrase worth watching the whole conversation for.:
You can delegate thinking, but you can't delegate understanding.
Even when agents do most of the work, they should be guided by someone who understands: what is worth building in general, why is it important, what kind of result is suspicious, what kind of compromise is acceptable. Understanding becomes a bottleneck, because a bad director won't pull off a good system.
That's why I don't believe in the logic of "tools are free, so there's nothing to learn." Exactly the opposite. When code generation, drafts, and routine become cheaper, the price increases for things that cannot be given to the agent: understanding, taste, evaluation design, system boundaries, and orchestration. This is the content of AIstack. The course is not about "how to code an MVP" (this is the floor, it is mastered over the weekend). It's about the ceiling: how to assemble and lead a team of three AI employees so as not to lose quality. In fact, it's about the very discipline that Karpaty called agentic engineering, translated into the language of the founder and product.
Karpaty gave this territory a name and authority. Next is a matter of practice. I'm launching the stream in September; who wants to deal with this systematically, and not randomly — aistackca.com .
Video of the conversation: youtube.com/watch?v=96jN2OCOfLs
Разбор разговора Андрея Карпатого со Стефани Жан на Sequoia AI Ascent 2026 — через призму vibe coding и курса AIstack
Год назад Карпатый придумал термин «vibe coding». В этом году на сцене Sequoia Ascent он сказал вещь, которая звучит странно из уст сооснователя OpenAI и человека, поднявшего Autopilot в Tesla: он никогда не чувствовал себя настолько отстающим как программист.
Я хорошо понимаю это ощущение. Поэтому хочу разобрать получасовой разговор не как очередную новость про ИИ, а как карту. В ней описано ровно то, что я последние месяцы делаю руками — и ровно то, вокруг чего я собираю AIstack.
Перелом случился в декабре
Карпатый называет конкретную точку — декабрь 2025-го. До этого инструменты вроде Claude Code и Codex были полезными, но требовали постоянной правки: модель выдавала куски кода, и их приходилось дочищать. В ноябре он, по его словам, писал руками около 80% кода. К декабрю пропорция перевернулась: теперь агенты делают порядка 80%, а он не может вспомнить, когда в последний раз что-то исправлял вручную.
Это был не плавный апгрейд, а пройденный порог. У меня он выглядел так же: папка с пет-проектами начала пухнуть, потому что стоимость «попробовать идею» упала почти до нуля. Единица работы перестала быть строкой кода. Теперь это макро-действие: реализуй фичу, отрефактори подсистему, изучи библиотеку, подними сервис, напиши тесты и почини то, что упало.
Главный вывод Карпатого: профессия переписывается. Программист всё меньше автор кода и всё больше — оркестратор агентов. Если вы не открывали эти инструменты с осени 2025-го, вы работаете на устаревших предпосылках о том, что вообще возможно.
Пол и потолок — это не игра слов
Самая важная для меня часть — разграничение двух понятий.
Vibe coding поднимает пол. Он даёт возможность собрать рабочее приложение почти кому угодно: ты описываешь, чего хочешь, модель это делает, и ты не вычитываешь каждую строку. Это прекрасно, и это реально изменило входной барьер.
Agentic engineering поднимает потолок. Это инженерная дисциплина: как координировать агентов — сущности мощные, но ошибающиеся и стохастические — и при этом не уронить планку качества. Ты по-прежнему отвечаешь за свой продукт. Тебе по-прежнему нельзя протащить уязвимость только потому, что «так навайбкодилось». Вопрос в том, как двигаться быстрее, не теряя контроль.
Карпатый формулирует жёстко: старый «10x-инженер» — это уже не про ускорение в 10 раз. Те, кто действительно освоил оркестрацию агентов, поднимаются заметно выше.
Именно здесь проходит мой тезис, который я повторяю клиентам и студентам уже много месяцев: vibe coding — это уходящая волна. Не потому что он плохой, а потому что он про пол. Следующая территория — агенты и инженерная работа с ними. Приятно, когда один из самых уважаемых людей в индустрии независимо называет ту же вещь и даёт ей имя.
Software 3.0: контекст как программа
Карпатый достраивает свою старую рамку. Software 1.0 — человек пишет код. Software 2.0 — человек собирает датасеты и обучает нейросеть, программа «зашита» в веса. Software 3.0 — человек программирует саму LLM: промптом, контекстом, инструментами, примерами, памятью.
В этой картине контекстное окно — главный рычаг, а LLM — интерпретатор, который выполняет вычисление над информацией.
Его пример с установкой OpenClaw попал точно. В старом мире инсталлятор — это shell-скрипт, который распухает от условий под каждую ОС и архитектуру. В Software 3.0 инсталлятор — это блок текста, который ты вставляешь агенту: он сам смотрит на твоё окружение, выполняет действия и чинит ошибки по ходу. Менее точно — но адаптивно.
Для меня это не теория. Я строю инфраструктуру MCP-first и держу несколько агентов с разделением ролей. «Какой кусок текста вставить агенту» — это и есть теперь часть программирования. И отдельно Карпатый напоминает: дело не только в том, что кодить стало быстрее. Появились вещи, которых раньше не было в принципе. Его пример с LLM-вики — система, которая инкрементально пересобирает кучу разрозненных документов в живую базу знаний, — это не «ускорение старого кода». Раньше такой программы просто не существовало.
Вопрос, который он предлагает задавать, я считаю самым ценным для основателя: не «какой существующий процесс ускорит ИИ», а «какое преобразование информации было невозможно — и стало естественным».
«Зубчатый» интеллект и почему нельзя выходить из контура
Дальше — рамка верифицируемости. Классические компьютеры автоматизируют то, что можно специфицировать кодом. Нынешние LLM автоматизируют то, что можно проверить. Если у задачи есть сигнал успеха — тесты, награда, измеримый результат, — модель можно на ней тренировать. Поэтому код, математика, бенчмарки растут так быстро.
Отсюда «зубчатый» (jagged) интеллект. Модель может отрефакторить кодовую базу на 100 тысяч строк или найти zero-day уязвимость — и в том же диалоге посоветовать ехать на машине на мойку, до которой 50 метров пешком. Это не баг в привычном смысле, это форма этого интеллекта: пики там, где лаборатории вложились в верифицируемое обучение, и провалы за пределами этой зоны.
Практический вывод для тех, кто строит на этом продукт: вы должны понимать, в каких «рельсах» находится ваша задача. Если внутри обученного распределения — модель летит. Если снаружи — спотыкается на элементарном, и тогда нужны свой контекст, инструменты, дообучение или собственные оценки качества. Карпатый отдельно подсвечивает это как стартап-возможность: найти ценный, верифицируемый и при этом недообученный лабораториями домен — и построить там свою RL-среду.
Навык, который не автоматизируется
Любимый его пример — из MenuGen. Пользователь логинится через Google, а кредиты покупает через Stripe. У обоих есть email. Агент написал «правдоподобный» код: сопоставлять оплату с аккаунтом по адресу почты. Но это плохой системный дизайн — почты могут не совпасть, и человек не получит то, что купил. Нужен устойчивый user ID. Такие ошибки агенты всё ещё делают.
Поэтому человек остаётся главным по спецификации, дизайну и вкусу. Карпатый не помнит наизусть, как называется параметр — dim, axis, keepdim, — и не обязан: у агента отличный recall на такие детали. Но человек обязан понимать суть — что у тензора есть хранилище, что view делит память, что лишнее копирование бьёт по производительности. Вы отвечаете за то, чтобы система имела смысл. Агент заполняет пробелы.
Он честно добавляет: когда смотришь на сгенерированный код, иногда хватаешься за сердце — он раздут, скопирован, хрупко абстрагирован. Работает, но некрасиво. Возможно, это починят будущие модели. Пока — это зона ответственности человека.
Узкое место — это понимание
Закончили на образовании, и здесь — фраза, ради которой стоило смотреть весь разговор:
Можно делегировать мышление, но нельзя делегировать понимание.
Даже когда агенты делают большую часть работы, направлять их должен тот, кто понимает: что вообще стоит строить, почему это важно, какой результат подозрителен, какой компромисс допустим. Понимание становится бутылочным горлышком — потому что плохой директор не вытянет хорошую систему.
Вот почему я не верю в логику «инструменты бесплатны, значит учиться нечему». Ровно наоборот. Когда генерация кода, черновики и рутина дешевеют, в цене растёт то, что не отдать агенту: понимание, вкус, проектирование оценок, границы системы, оркестрация.
По сути — про ту самую дисциплину, которую Карпатый назвал agentic engineering, переложенную на язык основателя и продакта.
Карпатый дал этой территории имя и авторитет. Дальше — вопрос практики.
Видео разговора: youtube.com/watch?v=96jN2OCOfLs
Share
