Sequoia Ascent 2026 summary

Конспект Sequoia Ascent 2026

30 апреля 2026

Я провёл fireside chat на Sequoia Ascent 2026. Видео на YouTube здесь:

В качестве эксперимента я скормил LLM все свои недавние посты в блоге и твиты, затем дал ей прочитать транскрипт этого видео и попросил подготовить 1) конспект и 2) очищенный транскрипт (с исправлением всех ошибок распознавания, удалением слов-паразитов и т.д.). Я выкладываю и то и другое ниже. Это может быть полезно как людям, которые хотят просто прочитать конспект в текстовом виде, так и LLM — чтобы мой контент был для них читаемым и доступным.

Ниже идёт сгенерированный ИИ контент по этому выступлению. Я использовал топовую модель (в данном случае Codex 5.5), прочитал материал — он читается нормально, без явных ошибок.

Sequoia Ascent 2026: Software 3.0, agentic engineering и «рваный» интеллект

Я недавно присоединился к Stephanie Zhan для fireside chat на Sequoia Ascent 2026, чтобы поговорить с основателями о недавнем сдвиге в AI-агентах, о том, что это значит для софта, и о том, как я думаю о следующей волне AI-native компаний.

Транскрипт мероприятия немного шумный, поэтому я хотел изложить основное интеллектуальное содержание в более чистой форме. Короткая версия: я думаю, что мы перешли новый порог. LLM — это уже не просто чат-боты или автодополнение. Они становятся новым программируемым слоем для цифровой работы.

Это сжатая версия беседы.

1. Декабрь 2025 стал точкой агентного перелома

Я недавно сказал, что никогда не чувствовал себя настолько отставшим как программист.

Причина не в том, что программирование стало сложнее в старом смысле. Дело в том, что изменился рабочий процесс по умолчанию. Большую часть 2025 года такие инструменты, как Claude Code, Codex и агенты в духе Cursor, были полезны, но всё ещё требовали частых правок. Около декабря 2025 я почувствовал ступенчатый скачок: сгенерированные куски стали больше, связнее и надёжнее. Я начал доверять агентам всё больше работы.

Единица программирования изменилась: вместо набора строк кода — делегирование более крупных «макродействий»:

Реализуй эту функцию. Отрефактори эту подсистему. Изучи эту библиотеку. Подними этот сервис. Напиши тесты, прогони их и почини падения. Сравни подходы и предложи план.

Именно поэтому я считаю, что профессия перестраивается. Программист всё больше становится не просто автором кода, а оркестратором агентов.

2. Software 3.0: контекстное окно как новая программа

Я воспринимаю это как следующий шаг последовательности:

Software 1.0: люди пишут явный код. Software 2.0: люди создают датасеты, цели и нейронные сети; программа выучивается в виде весов. Software 3.0: люди программируют LLM через промпты, контекст, инструменты, примеры, память и инструкции.

В Software 3.0 контекстное окно становится главным рычагом. LLM — это интерпретатор над этим контекстом, выполняющий вычисления над цифровой информацией.

Один из примеров — установка. В старом мире установка сложного инструмента в разных окружениях требовала хрупкого shell-скрипта, забитого условиями. В мире Software 3.0 установщик может быть блоком инструкций, который вы вставляете в агент. Агент читает локальное окружение, отлаживает ошибки, адаптируется к машине и завершает установку.

Это программа другого типа. Менее точная, но более адаптивная.

3. MenuGen и момент, когда софт исчезает

Я использовал MenuGen как пример более глубокого сдвига.

MenuGen был традиционным веб-приложением: сфотографировать меню ресторана, распознать названия блюд, сгенерировать изображения блюд и показать результат в UI. Требовался фронтенд-код, API, генерация изображений, деплой, авторизация, платежи, секреты и инфраструктура.

Но позже я увидел версию в духе Software 3.0: сфотографируй меню, отдай мультимодальной модели и попроси отрисовать изображения блюд прямо поверх изображения меню.

В этой версии большая часть приложения исчезает. Нейросеть напрямую преобразует входные медиа в выходные медиа. Старый стек был лесами вокруг преобразования, которое модель теперь может выполнить напрямую.

Это один из важнейших выводов для основателей: AI — это не просто более быстрый способ строить старые приложения. Некоторые приложения должны перестать существовать как приложения.

4. Новая возможность — это не просто более быстрое программирование

Сдвиг шире, чем кодинг. LLM автоматизируют формы обработки информации, которые раньше не поддавались программированию.

Мой паттерн LLM Wiki — самый наглядный пример. Вместо того чтобы каждый раз отвечать на вопросы из сырых документов через RAG, агент инкрементально компилирует сырые источники в постоянную Markdown-вики: саммари, страницы сущностей, страницы концептов, противоречия, перекрёстные ссылки, логи и эволюционирующий синтез.

Ни одна классическая программа не смогла бы устойчиво поддерживать такую базу знаний поверх грязных человеческих документов. А LLM может.

Урок: не спрашивайте только «какой существующий рабочий процесс AI может ускорить?». Спрашивайте также: «какое преобразование информации было невозможно раньше, но теперь стало естественным?»

5. Верифицируемость объясняет, где AI движется быстрее всего

Моя ключевая рамка автоматизации такова:

Традиционный софт автоматизирует то, что можно специфицировать. LLM и reinforcement learning автоматизируют то, что можно верифицировать.

Если у задачи есть автоматическая награда или сигнал успеха, модели могут на ней тренироваться. Именно поэтому математика, кодинг, тесты, бенчмарки, игры и многие инженерные задачи так быстро улучшаются. Они сбрасываемы, повторяемы и вознаграждаемы.

Это также объясняет, почему агенты для кодинга ощущаются драматически лучше, чем многие обычные чат-боты. Кодинг даёт модели обратную связь: тесты проходят или падают, программы запускаются или крашатся, диффы можно осмотреть, бенчмарки можно измерить.

6. «Рваный» интеллект имеет две оси: верифицируемость и внимание при обучении

Интервью добавило важное уточнение к тезису о верифицируемости.

Способности модели зависят не только от того, верифицируема ли задача. Они также зависят от того, делали ли лаборатории акцент на этой задаче во время тренировки, post-training, генерации синтетических данных и reinforcement learning.

Грубая формула:

capability spike ~= verifiability x training attention x data coverage x economic value

Шахматы — хороший пример. Когда GPT-4 улучшилась в шахматах, это не обязательно означало, что общая интеллектуальность плавно выросла повсюду. Возможно, дело было в том, что в обучающую смесь добавили гораздо больше шахматных данных.

Это важно, потому что фронтир-модели не идут с инструкцией. Они — артефакты смеси предобучения, RL-сред, давления бенчмарков, продуктовых приоритетов и экономических стимулов. Они выбиваются вверх в одних местах и ведут себя странно в других.

Поэтому практический вопрос для основателя такой: вы на рельсах модели или нет?

Если ваша задача находится в области, которая верифицируема и плотно натренирована, модель может полететь. Если нет — она может проваливаться на удивление базовым образом. Возможно, вам понадобятся более качественный контекст, инструменты, fine-tuning, собственные evals или собственная среда reinforcement learning.

7. Vibe coding против agentic engineering

Я различаю две связанные, но разные идеи:

Vibe coding поднимает пол. Он позволяет почти любому создавать софт, описывая словами то, что он хочет. Agentic engineering поднимает потолок. Это профессиональная дисциплина координации ошибающихся агентов с сохранением корректности, безопасности, вкуса и поддерживаемости.

Vibe coding годится для прототипов и личных инструментов. Agentic engineering — то, что нужно серьёзным командам.

Agentic-инженер не принимает сгенерированный код вслепую. Он проектирует спеки, контролирует планы, проверяет диффы, пишет тесты, создаёт циклы оценки, управляет правами, изолирует worktree и сохраняет качество.

Мой баг с оплатой в MenuGen — полезный пример. Агент пытался сопоставлять покупки в Stripe с Google-аккаунтами по email-адресам. Это правдоподобный код, но плохой системный дизайн: email в Stripe и email в Google-аккаунте могут отличаться. Человеку нужно достаточно продуктового и инженерного суждения, чтобы настоять на постоянных user ID.

Фронтир-навык — это не запоминание каждой детали API. Агенты могут помнить, использует ли тензорная библиотека dim, axis, keepdim, reshape или permute. Человеку всё ещё нужно понимать основополагающие концепции: хранилище, представления, копирование памяти, инварианты, идентичность, границы безопасности и форму системы.

8. Найм должен измениться

Если agentic engineering — это новый профессиональный навык, найм должен тестировать его напрямую.

Традиционные кодинг-головоломки всё хуже подходят. Лучшее интервью может выглядеть так: построить с агентами серьёзный проект, задеплоить его, сделать его защищённым, а затем дать состязательным агентам попытаться его сломать.

Это тестирует настоящий навык:

Может ли кандидат декомпозировать работу для агентов? Может ли он писать полезные спеки? Может ли он сохранять качество, двигаясь быстро? Может ли он ревьюить сгенерированную работу? Может ли он защитить и закалить систему? Может ли он использовать агентов как рычаг, а не штамповать мусор?

Старая идея «10x-инженера» может стать гораздо более экстремальной. Люди, освоившие agentic-воркфлоу, могут опережать остальных гораздо больше чем в 10 раз.

9. Основателям стоит искать ценные верифицируемые среды

Для основателей одна из важных возможностей — найти домены, которые ценны, верифицируемы и недостаточно натренированы фронтир-лабораториями.

Если вы можете создать доменно-специфичную среду, где модели могут пробовать действия и получать надёжные награды, вы можете улучшить производительность через fine-tuning или reinforcement learning, даже если базовая модель там пока не блестящая.

Самые очевидные домены, такие как кодинг и математика, уже активно охвачены лабораториями. Но многие экономически важные домены могут иметь скрытую верифицируемую структуру, которая пока не освоена.

Это стартап-клин.

10. Agent-native инфраструктура: стройте для агента, а не только для человека

Большая часть софта всё ещё построена под людей, кликающих по экранам.

В документации пишут вещи вроде «зайди по этой ссылке, нажми эту кнопку, открой эту панель настроек». Но всё чаще пользователь — не сам человек напрямую. Пользователь — это агент человека.

Это значит, что продуктам нужны agent-native поверхности:

Markdown-документация. CLI. API. MCP-серверы. Структурированные логи. Машиночитаемые схемы. Готовые к вставке инструкции для агентов. Безопасные права доступа. Аудируемые действия. Безголовые сценарии настройки.

Я думаю об этом в терминах сенсоров и актуаторов. Сенсор превращает какое-то состояние мира в цифровую информацию. Актуатор позволяет агенту что-то изменить. Стек будущего — это агенты, использующие сенсоры и актуаторы от имени людей и организаций.

История с деплоем MenuGen остаётся полезным мерилом. Построить приложение было легко по сравнению с обвязкой Vercel, авторизации, платежей, DNS, секретов и продакшен-настроек. В зрелом agent-native мире я должен иметь возможность сказать «построй MenuGen» — и агент задеплоит всё целиком без ручных кликов.

11. Призраки, а не животные

Моя рамка Animals vs. Ghosts — способ избегать плохих интуиций.

LLM — не животные. У них нет биологических драйвов, телесного давления выживания, любопытства, игры или внутренней мотивации в животном смысле. Это статистические симуляции человеческих артефактов, сформированные предобучением, post-training, RL, продуктовой обратной связью и экономическими стимулами.

Это важно, потому что антропоморфные ожидания вводят нас в заблуждение. Эти системы могут быть гениальными в один момент и нелепо тупыми в следующий. Это не плавные человеческие умы. Это рваные, чужеродные инструменты.

Правильная позиция — ни презрение, ни слепое доверие. Это эмпирическая привычка: узнайте, где они работают, где проваливаются, под что их тренировали и как построить вокруг них ограничители.

12. Образование: мышление можно делегировать, понимание — нет

Мы завершили на теме образования. Есть фраза, к которой я постоянно возвращаюсь:

Мышление можно делегировать, но понимание — нельзя.

Даже если агенты делают больше работы, человеку всё ещё нужно понимание, чтобы их направлять. Нужно знать, что стоит строить, какой вопрос важен, какой результат подозрителен и какой компромисс приемлем.

Именно поэтому мне интересны базы знаний на LLM. Это не просто машины ответов. Это инструменты для превращения информации в понимание.

Это также связано с моим маленьким проектом microGPT: полная реализация обучения и инференса GPT в одном Python-файле без зависимостей. Образовательный артефакт становится достаточно маленьким, чтобы и люди, и агенты могли его осмотреть. Эксперт-человек вкладывает дистиллированный артефакт и стоящий за ним вкус; агент затем может интерактивно объяснять его каждому ученику.

Большая картина

Главный тезис беседы — AI становится новым операционным слоем для цифровой работы.

Дефицитное смещается:

Менее дефицитно: генерация кода, отзыв API, шаблонный код, первые черновики, повторяющаяся настройка, простые преобразования. Более дефицитно: понимание, вкус, проектирование evals, безопасность, границы системы, оркестрация агентов, доменно-специфичные циклы обратной связи и умение замечать, когда модель сошла с рельсов.

Для основателей самые важные вопросы:

Что становится возможным, когда основной пользователь — агент, действующий от имени человека? Какие воркфлоу можно перестроить вокруг сенсоров, актуаторов и верифицируемых циклов? Какой софт должен исчезнуть, превратившись в прямые преобразования модели? Какие домены ценны и верифицируемы, но ещё плотно не натренированы фронтир-лабораториями? Какое человеческое суждение должно оставаться в петле, чтобы сохранить качество?

Моё нынешнее мировоззрение — не в том, что AI просто делает всех быстрее в старой работе. Сама работа реорганизуется вокруг агентов. Софт, исследования, образование, инфраструктура и работа со знаниями — все становятся вариациями одного и того же паттерна:

определи контекст определи инструменты определи цикл обратной связи определи ограничители дай агентам работать сохрани человеческое понимание

Sequoia Ascent 2026: Andrej Karpathy в беседе со Stephanie Zhan

Отредактированный транскрипт. Слегка причёсан для читаемости, очевидные ошибки транскрипции исправлены, слова-паразиты удалены, добавлено несколько уместных ссылок.

Вступление

Konstantine: Тот, кого вы все знаете. В этой AI-революции он стал учителем AI. В каждой революции есть технолог, но есть и учитель — человек, который реально объясняет и направляет это превращение. Andrej стал таким учителем для всего мира.

Он работал над Autopilot в Tesla, был сооснователем OpenAI и оставил всё это, чтобы основать Eureka Labs, где сделал ставку на идею AI как настоящего наставника. Мы рады, что Andrej Karpathy здесь с нашим партнёром Stephanie Zhan.

Stephanie: Привет всем. Мы рады нашему первому особому гостю. Он помог построить современный AI, объяснять современный AI и время от времени переименовывать современный AI.

Он сооснователь OpenAI. Он помог запустить Autopilot в Tesla. И у него редкий дар делать самые сложные технические сдвиги одновременно понятными и неизбежными.

Вы все знаете его как автора термина vibe coding, придуманного в прошлом году. Но всего пару месяцев назад он сказал ещё более поразительную вещь: он никогда не чувствовал себя настолько отставшим как программист. С этого мы и начнём. Спасибо, Andrej, что присоединился.

Andrej: Привет. Рад быть здесь и открывать конференцию.

Агентный перелом декабря 2025

Stephanie: Пару месяцев назад ты сказал, что никогда не чувствовал себя настолько отставшим как программист. От тебя такое слышать поразительно. Можешь распаковать это? Это ощущение было воодушевляющим или тревожным?

Andrej: Точно смесь и того и другого.

Как и многие из вас, я какое-то время — наверное, последний год — пользовался агентными инструментами: Claude Code, Codex и смежными. Они были очень хороши на кусках кода, но иногда промахивались, и приходилось править. В целом — помогали.

А декабрь стал явной точкой. У меня были каникулы, так что было больше времени. Думаю, у многих других было похоже. Я начал замечать, что с последними моделями куски стали выходить нормально. Я просил ещё — и они продолжали выходить нормально. Я не мог вспомнить, когда в последний раз правил их. Я стал доверять системе всё больше и больше.

Я считаю, что это был резкий переход. Многие пережили AI в прошлом году как нечто типа ChatGPT, но к декабрю стоило посмотреть заново, потому что всё изменилось фундаментально, особенно в этом агентном, связном воркфлоу. Оно реально заработало.

Это осознание утащило меня в кроличью нору бесконечных пет-проектов. Моя папка с side-проектами забита всякой всячиной. Я кодил всё время. Это случилось в декабре, и с тех пор я разбираюсь с последствиями.

Software 3.0

Stephanie: Ты говорил о LLM как о новом компьютере. Это не просто лучший софт, это новая вычислительная парадигма. Software 1.0 — это явные правила. Software 2.0 — выученные веса. Software 3.0 — вот это. Если это правда, что команда должна делать иначе в тот день, когда реально в это поверит?

Andrej: Software 1.0 — это писать код. Software 2.0 — это программирование через создание датасетов и обучение нейронных сетей. Программирование становится организацией датасетов, целей и архитектур нейросетей.

Затем произошло вот что: если ты обучаешь GPT-модели или LLM на достаточно большом наборе задач — а интернет, неявно, содержит огромное число задач — эти модели в определённом смысле становятся программируемыми компьютерами.

Software 3.0 — это программирование через промпт. То, что находится в контекстном окне, — это твой рычаг над интерпретатором, а интерпретатор — это LLM. Она интерпретирует твой контекст и выполняет вычисления в пространстве цифровой информации.

Несколько примеров помогли мне это прочувствовать. Когда вышел OpenClaw, для его установки обычно ожидался бы shell-скрипт. Но чтобы покрыть много платформ и разных машин, shell-скрипты обычно раздуваются и становятся крайне сложными. Ты застрял во вселенной Software 1.0 с желанием прописать точный код.

Установка OpenClaw вместо этого была блоком текста, который копируешь и вставляешь в свой агент. Это что-то вроде маленького скилла: копируешь это, отдаёшь агенту — и он установит OpenClaw. Это мощнее, потому что ты работаешь в парадигме Software 3.0. Тебе не надо прописывать каждую деталь. У агента есть интеллект. Он смотрит на твоё окружение, выполняет разумные действия и отлаживает в цикле.

Это другой способ мышления. Какой кусок текста скопировать-вставить в твой агент? Это теперь часть парадигмы программирования.

Другой пример — MenuGen. Ты садишься в ресторане, получаешь меню, и там нет картинок. Я многих этих блюд не знаю. Я хотел сфотографировать меню и получить картинки того, как эти блюда могут примерно выглядеть.

Так я построил приложение. Ты загружаешь фото, оно распознаёт все названия, использует генератор изображений, чтобы получить картинки, и показывает их тебе. Работает на Vercel и перерисовывает меню.

Затем я увидел версию Software 3.0, которая меня поразила. Ты берёшь фото, отдаёшь его Gemini и говоришь: используя Nano Banana, наложи это на меню. Он возвращает изображение того меню, которое я снял, но с пририсованными изображениями блюд.

Весь MenuGen становится излишним. Он работает в старой парадигме. Этого приложения не должно существовать. В парадигме Software 3.0 нейросеть делает бо́льшую часть работы. Твой промпт или контекст — это изображение, выход — тоже изображение. Не нужна вся прокладка приложения между ними.

Людям нужно переосмыслить. Не работай только в существующей парадигме и не думай об AI как об ускорителе существующего. Доступны новые вещи.

И речь не только о том, что программирование стало быстрее. Это более общая обработка информации, которая теперь автоматизируема. Предыдущий код работал над структурированными данными. Ты писал код над структурированными данными.

С моим проектом LLM knowledge bases ты заставляешь LLM создавать вики для твоей организации или лично для тебя. Это не программа в старом смысле. Не было кода, который мог бы создать базу знаний из кучи грязных фактов. Но теперь ты можешь брать документы, перекомпилировать их, переупорядочивать и создавать что-то новое и интересное как переосмысление данных.

Это новые вещи, которые раньше были невозможны. Я постоянно возвращаюсь к этому: не только что мы можем делать быстрее, а что было невозможно раньше? Это интереснее.

Нейронные компьютеры

Stephanie: Мне нравится прогрессия MenuGen. Если экстраполировать дальше, что в 2026 году станет эквивалентом построения веб-сайтов в 90-х, мобильных приложений в 2010-х или SaaS в эпоху облаков? Что задним числом будет казаться очевидным, но сегодня почти не построено?

Andrej: Если идти по примеру MenuGen — большая часть этого кода не должна существовать. Нейросеть должна делать бо́льшую часть работы.

Экстраполяция выглядит очень странно. Можно представить полностью нейронные компьютеры в определённом смысле. Представь устройство, которое подаёт сырое видео или аудио в нейросеть и использует диффузию, чтобы отрендерить UI, уникальный для этого момента.

В ранние дни компьютеров люди были немного запутаны, будут ли компьютеры похожи на калькуляторы или на нейросети. В 1950-х и 1960-х было неочевидно, куда оно пойдёт. Мы пошли по пути калькулятора и построили классические вычисления.

Нейросети сейчас работают виртуализованно на существующих компьютерах. Но можно представить переворот, в котором нейросеть становится хост-процессом, а CPU — сопроцессорами. Вычисления интеллекта и нейросетевые вычисления становятся доминирующей тратой FLOPs.

Можно представить нечто чужеродное, где нейросети делают основную тяжёлую работу и используют инструменты как исторический привесок для детерминированных задач. На самом деле всё это вертят сетевые нейросети.

Это экстраполяция, но, думаю, мы будем приходить туда по частям.

Верифицируемость и «рваный» интеллект

Stephanie: Я бы хотела поговорить о верифицируемости — идее, что AI быстрее и проще автоматизирует те домены, где результат можно верифицировать. Если эта рамка верна, какая работа сейчас движется намного быстрее, чем люди понимают? И какие профессии люди считают безопасными, хотя на самом деле они высоко верифицируемы?

Andrej: Традиционные компьютеры автоматизируют то, что можно специфицировать в коде. Нынешнее поколение LLM может автоматизировать то, что можно верифицировать.

Когда фронтир-лаборатории обучают эти LLM, они тренируют их в гигантских средах reinforcement learning с верифицируемыми наградами. Из-за этого модели прогрессируют и становятся рваными сущностями. Они выбиваются в верифицируемых доменах — математика, код и смежное — и застывают или остаются грубыми по краям там, где эти условия не выполняются.

Я написал о верифицируемости, потому что пытался понять, почему эти штуки настолько рваные. Часть связана с тем, как лаборатории обучают модели. Часть — с тем, на чём лаборатории фокусируются и что попадает в распределение данных. Некоторые вещи значительно ценнее экономически, поэтому лаборатории создают больше сред под них. Код — хороший пример.

Вероятно, есть множество верифицируемых сред, о которых можно подумать, которые не попали в обучающий микс, потому что они менее экономически полезны для развития способностей.

Один из любимых примеров одно время — сколько букв в слове «strawberry». Модели знаменито это ошибались. Сейчас это пропатчено. Новый пример: я хочу поехать на автомойку помыть машину, она в 50 метрах. Ехать или идти пешком? State-of-the-art модель может сказать тебе идти пешком, потому что это близко.

Как такое возможно, что state-of-the-art модель может отрефакторить кодовую базу в 100 000 строк или найти 0-day уязвимости, но при этом говорит мне идти на автомойку пешком? Это рваность. Пока модели остаются рваными, ты обязан быть в петле. Ты обязан относиться к ним как к инструментам и оставаться в курсе того, что они делают.

Моё письмо о верифицируемости — попытка понять эту закономерность. Думаю, это какая-то комбинация «верифицируемо» плюс «лабораториям не всё равно».

Ещё анекдот — шахматы. От GPT-3.5 к GPT-4 люди заметили, что шахматы сильно улучшились. Некоторые думали, что это просто прогресс общих способностей. Но я думаю, что публично известно: в pretraining попал большой объём шахматных данных. Поскольку это было в распределении данных, модель улучшилась гораздо сильнее, чем улучшилась бы по умолчанию.

Кто-то в OpenAI решил добавить эти данные, и теперь — скачок способностей. Поэтому я подчёркиваю это измерение: мы немного во власти того, что делают лаборатории и что они кладут в микс. Тебе приходится исследовать модель, которую тебе дают. У неё нет инструкции. Она работает в одних условиях и не работает в других.

Если ты в схемах, которые были частью reinforcement learning, ты летишь. Если ты вне распределения данных, тебе тяжело. Тебе нужно выяснить, в каких схемах находится твоё приложение. Если нет — придётся смотреть в сторону fine-tuning или собственной работы, потому что это может не выйти из LLM «из коробки».

Стартап-возможности в верифицируемых доменах

Stephanie: Если бы ты был сегодня основателем, решал какую-то посильную, верифицируемую задачу, но оглянулся бы и увидел, что лаборатории начали достигать второй космической в очевидных доменах вроде математики и кодинга, — какой бы у тебя был совет?

Andrej: Верифицируемость делает задачу решаемой в текущей парадигме, потому что ты можешь обрушить на неё огромный объём reinforcement learning.

Это остаётся верным, даже если лаборатории на этом напрямую не сфокусированы. Если ты в верифицируемой постановке, где можешь создавать среды RL или примеры, ты потенциально можешь делать свой fine-tuning и получать выгоду. Технология фундаментально работает. Если у тебя есть разнообразные датасеты или RL-среды, ты можешь использовать фреймворк fine-tuning, дёрнуть за рычаг и получить что-то, что работает довольно хорошо.

Не хочу выдавать конкретные примеры, но есть ценные среды reinforcement learning, о которых можно подумать и которые сейчас не входят в микс фронтир-лабораторий.

Stephanie: С другой стороны, что пока кажется автоматизируемым только издалека? Какие домены или профессии безопаснее других?

Andrej: В конечном счёте почти всё можно сделать верифицируемым в той или иной степени, какие-то вещи легче, какие-то — сложнее. Даже для письма можно представить совет LLM-судей и получить что-то разумное.

Так что вопрос скорее в том, что легко, а что сложно.

Vibe coding против agentic engineering

Stephanie: В прошлом году ты ввёл термин vibe coding. Сегодня мы в мире, который ощущается серьёзнее, более agentic engineering. В чём разница между ними и как бы ты назвал то, в чём мы сейчас находимся?

Andrej: Vibe coding — про то, чтобы поднять пол для всех в плане того, что они могут делать в софте. Кто угодно может vibe-кодить что угодно, и это потрясающе.

Agentic engineering — про то, чтобы сохранить планку качества профессионального софта. Нельзя вносить уязвимости из-за vibe coding. Ты по-прежнему отвечаешь за свой софт, как и раньше. Но можешь ли ты двигаться быстрее? Спойлер: можешь. Вопрос — как делать это правильно.

Я называю это agentic engineering, потому что это инженерная дисциплина. У тебя есть агенты — рваные сущности. Они ошибающиеся и стохастические, но крайне мощные. Как их координировать, чтобы идти быстрее, не жертвуя планкой качества?

Vibe coding поднимает пол. Agentic engineering — про экстраполяцию потолка. Я думаю, что у способности agentic-инженера очень высокий потолок. Раньше говорили про 10x-инженеров. Думаю, тут это многократно усиливается. 10x — не тот ускоритель, который люди получат. Те, кто очень хороши в этом, могут уходить намного выше.

Как выглядит AI-native кодинг

Stephanie: В прошлом году Sam Altman приходил на Ascent и говорил, что разные поколения используют ChatGPT по-разному. Если тебе за 30, ты используешь его как замену Google-поиску. Если ты подросток, ChatGPT — твоя дверь в интернет.

Какая аналогия в кодинге? Если бы мы смотрели на двух кодеров, использующих OpenClaw, Claude Code или Codex — одного посредственного и одного полностью AI-native, — как бы ты описал разницу?

Andrej: Это про то, чтобы вытащить из доступных инструментов максимум, использовать их возможности и инвестировать в свою настройку.

Инженеры всегда так делали с инструментами вроде Vim или VS Code. Теперь инструменты — это Claude Code, Codex и так далее. Ты вкладываешься в свою настройку и используешь то, что есть.

Связанная мысль — найм. Многие хотят нанимать сильных agentic-инженеров, но большинство процессов найма не перестроены под способности agentic-инженера. Если ты раздаёшь маленькие головоломки — это всё та же старая парадигма.

Найм должен выглядеть скорее так: дать человеку большой проект и посмотреть, как он его реализует. Например, написать Twitter-клон для агентов, сделать его хорошим и защищённым, затем заставить агентов симулировать на нём активность. Потом я возьму десять Codex-агентов и попытаюсь сломать сайт, который ты задеплоил, — и они не должны его сломать.

Смотреть на людей в такой постановке — как они строят более крупный проект и пользуются инструментами — ближе к тому, что я бы искал.

Какие человеческие навыки становятся ценнее?

Stephanie: По мере того как агенты делают больше, какой человеческий навык становится ценнее, а не наоборот?

Andrej: Сейчас агенты — как интерны. Ты по-прежнему отвечаешь за эстетику, суждение, вкус и контроль.

Один из моих любимых примеров — из MenuGen. Ты регистрируешься через Google-аккаунт, но покупаешь кредиты через Stripe. У обеих систем есть email. Мой агент пытался начислять купленные кредиты, сопоставляя email из Stripe с email из Google-аккаунта.

Но это могут быть разные email. Пользователь может не получить купленные кредиты. С какой стати использовать email для сопоставления денежных операций? Нужен постоянный user ID. Это типичная ошибка, которую агенты пока делают.

Люди должны отвечать за спеку и план. Мне даже не очень нравится концепция «plan mode» как таковая, хотя она полезна. Есть что-то более общее: ты работаешь с агентом, чтобы спроектировать детальную спеку — это может быть, по сути, документация — и просишь агентов её написать. Ты отвечаешь за контроль и верхнеуровневые категории. Агенты делают много работы снизу.

Ещё пример: тензоры в нейросетях. Там много деталей в PyTorch, NumPy, pandas и так далее: dim против axis, reshape, permute, transpose, keepdim. Я этого больше не помню, потому что мне не нужно. Эти детали обрабатывает интерн, потому что у агентов хорошая память.

Но ты должен понимать фундамент. Ты должен знать, что есть нижележащее тензорное хранилище, что ты можешь манипулировать представлением того же хранилища или создать другое хранилище — что менее эффективно. Тебе нужно достаточно знать, чтобы не копировать память без необходимости.

Так что ты отвечаешь за вкус, инженерию, проектирование и за то, имеет ли система смысл. Ты просишь правильные вещи: например, мы привязываем всё к уникальным user ID. Агенты заполняют пробелы.

Stephanie: Как ты думаешь, вкус и суждение со временем становятся менее значимыми, или потолок просто продолжает расти?

Andrej: Надеюсь, это улучшится. Сейчас оно не улучшается, видимо, потому что это не часть reinforcement learning. Возможно, награды за эстетику нет или она недостаточно хороша.

Когда я смотрю на код, иногда у меня инфаркт. Это не всегда классный код. Он может быть раздутым, копипастным, неудачно абстрагированным, хрупким. Он работает, но мерзкий. Надеюсь, это улучшится в будущих моделях.

Хороший пример — мой проект microGPT, где я попытался максимально упростить обучение LLM. Модели это ненавидят. Они не могут. Я снова и снова просил LLM упрощать ещё и ещё, и она просто не могла. Чувствуешь, что ты вне RL-схем. Как зубы рвать.

Так что люди пока остаются ответственными за это. Но я не думаю, что есть что-то фундаментальное, мешающее улучшениям. Лаборатории просто пока этого не сделали.

Призраки, а не животные

Stephanie: Хочу вернуться к рваным формам интеллекта. Ты написал провокационный текст Animals vs. Ghosts: мы строим не животных, мы вызываем призраков. Это рваные формы интеллекта, сформированные данными и функциями награды, а не внутренней мотивацией, удовольствием, любопытством или эмпауэрментом так, как эволюция формировала животных.

Почему эта рамка важна? Что она меняет в том, как ты строишь, разворачиваешь, оцениваешь или доверяешь им?

Andrej: Я написал об этом, потому что пытаюсь понять, что это вообще такое. Если у тебя есть хорошая модель того, чем они являются и не являются, ты будешь компетентнее их использовать.

Не знаю, есть ли у этой рамки прямая практическая сила. Это слегка философское. Но это о том, чтобы примириться с фактом, что это не животный интеллект. Если ты на них орёшь — они от этого не будут работать ни лучше, ни хуже. Это статистические симуляционные схемы. Субстрат — это предобучение, потом сверху прикручен reinforcement learning.

Это вопрос установки: с чем я взаимодействую, что вероятно сработает, что нет и как мне это модифицировать? У меня нет пяти очевидных рекомендаций, которые сделают твою систему лучше. Скорее это про подозрительность к системе и эмпирическое выяснение со временем.

Agent-native инфраструктура

Stephanie: Ты глубоко работаешь с агентами, которые не просто болтают. У них реальные права, локальный контекст, и они реально совершают действия от твоего имени. Как выглядит мир, когда мы все живём в таком мире?

Andrej: Многим здесь, вероятно, интересно, как выглядит agent-native окружение. Всё нужно переписать. Большинство вещей всё ещё фундаментально написаны для людей.

Когда я пользуюсь фреймворками или библиотеками, документация всё ещё написана для людей. Это моё любимое раздражение. Почему мне всё ещё рассказывают, что делать? Я ничего не хочу делать. Что мне скопировать-вставить в моего агента?

Каждый раз, когда мне говорят «зайди по этому URL» или «кликни здесь», я думаю: нет. Индустрия должна разложить нагрузки на сенсоры и актуаторы над миром. Как сделать вещи agent-native? Как описывать их в первую очередь агентам и строить автоматизацию вокруг структур данных, читаемых для LLM?

Я надеюсь, что появится много agent-first инфраструктуры. С MenuGen сложной частью было не написать код. Проблема была в деплое на Vercel, подключении сервисов, настройках, DNS, авторизации, платежах, секретах и продакшен-конфигурации.

Я бы хотел сказать LLM: построй MenuGen. И дальше я ничего не трогаю — и он развернут в интернете. Это был бы хороший тест на то, становится ли наша инфраструктура agent-native.

В конечном счёте я думаю, что мы идём к миру, где у людей и организаций будет агентское представительство. Мой агент будет говорить с твоим агентом, чтобы согласовать детали встречи и другие задачи. Туда всё примерно и идёт.

Образование и понимание

Stephanie: Мы обязаны закончить на образовании. Ты, наверное, один из лучших в мире в том, чтобы делать сложные технические концепции простыми, и ты глубоко думаешь об образовании. Что остаётся стоящим того, чтобы изучать вглубь, когда интеллект становится дешёвым?

Andrej: Недавно я наткнулся на твит, который меня поразил, и я постоянно о нём думаю:

Мышление можно делегировать, но понимание — нельзя.

Хорошо сказано. Я по-прежнему часть системы. Информация всё ещё должна доходить до моего мозга. Я становлюсь бутылочным горлышком даже в том, чтобы понимать, что мы пытаемся построить, почему это стоит делать и как направлять моих агентов.

Что-то всё равно должно направлять мышление и обработку. И это ограничено пониманием.

Одна из причин, по которой я воодушевлён базами знаний на LLM, — это способ обработать информацию для меня. Каждый раз, когда я вижу другую проекцию на информацию, я ощущаю, что получаю инсайт. Это генерация синтетических данных поверх фиксированных данных.

Когда я читаю статью, моя вики надстраивается из этих статей. Я обожаю задавать ей вопросы. В конечном счёте это инструменты для усиления понимания. Понимание остаётся бутылочным горлышком, потому что нельзя быть хорошим директором, не понимая.

LLM не полностью преуспевают в понимании. Ты по-прежнему уникально за это отвечаешь. Инструменты, усиливающие понимание, невероятно интересны и захватывающи.

Stephanie: Мне не терпится через пару лет вернуться сюда и посмотреть, полностью ли нас автоматизировали из петли и взяли ли они на себя и понимание. Огромное спасибо, Andrej.

Andrej: Спасибо.

Konstantine: Stephanie, Andrej, огромное спасибо.