Don't waste 2 years learning to code. The man who built Claude Code tells you what to learn instead. 82 minutes

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

Однако, как только я начал работать в Cursor, я осознал, чего именно мне не хватало — миссии. Собственно, именно это изначально и привело меня в Anthropic. До прихода в Anthropic я работал в Big Tech, но в какой-то момент захотел перейти в лабораторию, чтобы иметь возможность внести свой вклад в формирование будущего той «безумной штуки», которую мы сейчас строим.

То, что привлекло меня в Anthropic — это именно их миссия, которая полностью сосредоточена на безопасности (safety). Если вы встретите любого сотрудника в коридорах офиса и спросите, почему он здесь работает, ответом всегда будет «безопасность».

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

С момента запуска Cloud Code прошел год, что дает повод для осмысления достигнутого проектом влияния. Согласно недавнему отчету Semi Analysis, в настоящее время 4% всех коммитов на GitHub создаются с помощью Cloud Code. Более того, по прогнозам, к концу текущего года этот показатель достигнет одной пятой (20%) от всех коммитов кода на GitHub. В отчете это явление описали фразой: «Пока мы моргали, искусственный интеллект поглотил всю разработку программного обеспечения».

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

Рассуждая о пройденном пути, следует отметить, что статистика, говорящая о 4% всех мировых коммитов, кажется невероятной и значительно превышает первоначальные ожидания. Тем не менее, это ощущение сохраняется как некая отправная точка. Важно также учитывать, что приведенные цифры касаются только публичных коммитов (public commits). Если проанализировать частные репозитории (private repositories), то фактическое влияние проекта оказывается значительно выше. Для создателей проекта самым поразительным является не текущее число, а темп, с которым происходит рост. Если рассматривать темпы роста Cloud Code по любым метрикам, заметно, что они продолжают ускоряться: проект не просто растет, он растет всё быстрее и быстрее.

Когда работа над QuadCode только начиналась, изначально задумывалось, что это будет лишь небольшой хакерский проект. В компании Anthropic давно понимали, что хотят выпустить какой-то продукт для написания кода. На протяжении долгого времени в Anthropic строили модели, следуя определенной ментальной модели создания безопасного ИИ (HEI): сначала модель обучается хорошо писать код, затем — эффективно использовать внешние инструменты, и на финальном этапе — хорошо взаимодействовать с компьютером (то есть управлять интерфейсами). Это примерная траектория развития, над которой в компании работали долгое время.

Команда, которая изначально начала этот проект, называлась Anthropic Labs team. Позже Майк Кригер (Mike Krieger) и Бен Манн (Ben Mann) перезапустили работу этой команды, что стало своего рода вторым этапом разработки. Эта группа создала несколько значимых вещей: QuadCode, протокол MCP (Model Context Protocol) и настольное приложение. Все эти наработки отражают ключевую идею развития: «код — инструменты — работа с компьютером».

Причины такой структуры важны для Anthropic в контексте безопасности систем. ИИ становится все более мощным и способным. В последний год произошел важный сдвиг: для инженеров ИИ перестал быть просто текстовым интерфейсом или собеседником для диалога — он теперь не просто пишет код, а использует инструменты и совершает реальные действия в цифровом мире.

С появлением продукта, который в транскрипте упоминается как cowork (вероятно, имеется в виду Claude Desktop/Computer Use), этот переход к активным действиям становится доступен и для пользователей без технических навыков. Для многих людей, привыкших к диалоговым ИИ, это может быть первым опытом взаимодействия с системой, которая действительно выполняет действия за них: она может пользоваться Gmail, отправлять сообщения в Slack и совершать другие задачи. Это работает достаточно хорошо сейчас, и в дальнейшем возможности будут только улучшаться.

Для Anthropic долгое время присутствовало ощущение необходимости что-то создать, однако долгое время было не до конца очевидно, что именно.

Когда я присоединился к компании Ant, я потратил месяц на то, что можно назвать хакингом: создавал массу странных прототипов. Большинство из них так и не были запущены и даже не были близки к запуску — это был просто способ понять границы того, на что способна модель. Затем я потратил месяц на этап post-training, чтобы разобраться в исследовательской стороне процесса. Честно говоря, как инженер, я считаю, что для хорошей работы необходимо понимать слой, который лежит под тем уровнем, на котором вы работаете.

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

У меня сохранилась видеозапись самой первой версии — я записал демо летом и опубликовал его. Проект назывался Quad CLI, и тогда я просто показывал, как он использует несколько инструментов. Самым шокирующим для меня было то, что я дал модели bash-инструмент, и она смогла использовать его для написания кода. Я задал вопрос: «Какую музыку я сейчас слушаю?». И это было самое безумное, потому что я не давал модели инструкцию «используй этот инструмент для того-то» или «сделай то-то». Модели предоставили инструмент, и она сама поняла, как его использовать, чтобы ответить на вопрос, в ответе на который я даже не был уверен: «Какую музыку я слушаю?».

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

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

В итоге идея прижилась и после выпуска довольно быстро стала хитом в Anthropic. Количество DAU (daily active users — ежедневные активные пользователи) просто устремилось вертикально вверх.

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

Одной из причин успеха Cloud Code стала скрытая потребность (latent demand) — идея заключалась в том, чтобы внедрить инструмент туда, где уже находятся люди, и сделать их текущие рабочие процессы немного проще. Однако тот факт, что инструмент работал в терминале, был неожиданным и казался своего рода чем-то чужеродным, поэтому пользователям приходилось проявлять открытость и учиться работать с ним.

Сейчас Cloud Code доступен повсеместно: в мобильных приложениях для iOS и Android, в десктопных приложениях, на веб-сайте, а также в качестве расширений для IDE, Slack и GitHub — во всех тех местах, которые более привычны инженерам. Но это не было отправной точкой.

По мере роста команды и развития продукта он стал приносить всё больше пользы людям по всему миру — от небольших стартапов до крупнейших компаний (так называемых FANG). Они начали получать обратную связь, и для авторов это стало невероятным опытом, который заставляет сохранять смирение, поскольку они продолжают постоянно учиться у своих пользователей.

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

Раньше существовали прогнозы вроде: «ИИ будет писать 100% кода», и все отвечали: «Нет, это безумие, о чем вы вообще говорите?». А теперь все говорят: «Конечно, всё происходит именно так, как они предсказывали». Это отражает только то, насколько быстро всё движется и меняется в современном мире.

Во время сессии вопросов и ответов на конференции в мае 2025 года лектор сделал прогноз, что к концу года программистам, возможно, больше не потребуется использовать IDE (интегрированную среду разработки) для написания кода. Инженеры начнут отходить от привычного процесса работы в них. Лектор вспоминает, что аудитория в зале отреагировала на это утверждение коллективным вздохом, так как прогноз показался крайне необычным и даже безумным.

Тем не менее, в компании Anthropic принято мыслить категориями экспонент (экспоненциального роста), и это глубоко заложено в ДНК организации. Лектор поясняет, что трое из сооснователей компании были в числе первых трех авторов статьи о scaling laws (законах масштабирования), поэтому в компании действительно привыкли мыслить экспоненциально. Если проанализировать экспоненту процента кода, написанного с помощью ИИ (названного в транскрипте Quad), и просто проследить эту линию, становится очевидно, что показатель преодолеет отметку в 100% к концу года, даже если это совершенно не соответствует интуитивным ожиданиям. Лектор отмечает, что он просто «проследил эту линию», и в ноябре лично для него это стало реальностью, которая сохраняется с тех пор. Сейчас эту же тенденцию компания начинает наблюдать у множества других своих клиентов.

Развивая тему инноваций, лектор комментирует идею, что важной частью пути является экспериментирование — просто играть с технологиями и смотреть, что из этого получится. Это часто происходит в Anthropic, когда сотрудники, в частности Питер, просто пробовали что-то новое, и результаты случались сами собой. По мнению лектора, это ощущение является центральным ингредиентом многих крупнейших инноваций в сфере ИИ: люди просто сидят, пробуют различные подходы и пытаются «проталкивать» возможности моделей дальше, чем большинство других людей.

Инновации не имеют заранее заданной дорожной карты, их невозможно форсировать. Для успеха необходимо предоставлять людям пространство и создавать условия так называемой психологической безопасности, в рамках которой важно осознавать, что совершать ошибки — это нормально, и что даже если 80% идей окажутся неудачными, это допустимый путь. При этом требуется сохранять определенный уровень ответственности: если идея не срабатывает, необходимо вовремя признать убытки, прекратить инвестиции и перейти к следующей задаче.

На ранних этапах работы над Claude Code не было очевидно, окажется ли инструмент полезным в принципе. В феврале он писал около 20% кода, к маю показатель вырос до 30%, и большую часть работы автору приходилось выполнять самостоятельно. Отметка в 100% генерации кода была достигнута только в ноябре. Несмотря на долгий путь, с самых первых дней возникало ощущение, что удалось нащупать нечто значимое, что требовало постоянной работы по вечерам и выходным.

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

На текущий момент 100% кода автора пишутся с помощью Claude Code. Автор характеризует себя как достаточно продуктивного программиста (пролифичного кодера): такой статус сохранялся за ним еще во времена работы в Instagram, где он входил в число наиболее эффективных инженеров, и сохраняется сейчас в компании Anthropic, даже несмотря на руководящую должность. Ежедневно автор создает от 10 до 30 пулл-реквестов, при этом с ноября прошлого года он не редактировал ни одной строки кода вручную.

Тем не менее, это не означает, что можно полностью устраниться от процесса. Автор просматривает код, поскольку в разработке, где задействовано множество участников, необходимо обеспечивать проверку корректности и безопасности программ. В Anthropic также внедрен процесс автоматического ревью кода с помощью Claude для всех запросов: Claude проводит ревью 100% всех пулл-реквестов. Несмотря на это, остается слой ручной проверки человеком. Существование подобных контрольных точек необходимо до тех пор, пока код не является исключительно прототипом, который не будет запускаться в реальной среде и не требует дальнейшего исполнения.

At this point, 100% of being code is written by AI. This is where everyone in software engineering is going. While this felt like a crazy milestone previously, it is now simply the reality of our world. The question arises: what is the next big shift in how software is written that either a team is already operating in or that a team will head towards?

Something happening right now is that the AI is starting to come up with its own ideas. It looks through feedback, reports, bug reports, and telemetry. Based on this, it starts generating ideas for bug fixes and things to ship. It is starting to get a little bit more like a coworker.

A second significant development is that we are starting to branch out of coding. At this point, it is safe to say that coding is largely solved, at least for the kinds of programming the speaker does, because the AI can do it. As we look at what is beyond this, there are many things adjacent to coding that are coming, but also general tasks. The speaker uses an AI assistant every day for all sorts of things that are simply not related to coding at all. For example, the speaker had to pay a parking ticket the other day and just had the AI do it. Furthermore, the AI handles all project management for the team, which involves syncing information between spreadsheets, messaging people on Slack, sending emails, and managing all other related tasks.

The true frontier is something like this, rather than just coding, because coding is effectively solved. Over the next few months, across the industry and for every kind of code tech base and stack that engineers work on, coding will become increasingly solved. The idea of the AI actually helping a user determine what to work on is extremely interesting. Many people listening are product managers, and they are likely sweating. The question becomes: how do you use the AI for this? Do you just talk to it? Is there anything clever to come up with to help use it to determine what to build?

Если возник вопрос, как придумать, что именно нужно создавать, самый простой способ — открыть Cursor (в транскрипте — Quad Code, очевидная ошибка распознавания, речь идет о редакторе кода с ИИ) и направить его в Slack-канал с проектом. В нашей команде есть специальный канал, куда стекается вся внутренняя обратная связь по продукту с момента его первого релиза, и даже в 2024 году это непрерывный поток данных.

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

Сейчас я делаю то же самое, но большую часть работы берет на себя ИИ. Я подключаю его к каналу с фидбеком, и он сам предлагает варианты действий: «Вот несколько вещей, которые я могу сделать, я уже подготовил пару PR (pull requests), посмотришь?».

Мы наблюдаем, как технологии значительно улучшаются в этом направлении. Сейчас это своего рода «Святой Грааль»: мы решили проблему написания кода, но следующим «узким местом» стало проведение ревью кода. Возникает вопрос: кто будет проверять все эти PR? Следующий большой открытый вопрос заключается в том, что люди остаются необходимыми для принятия решений о том, что именно нужно строить и как приоритизировать задачи. Сейчас Cursor (ИИ-инструмент) начинает помогать в этом вопросе.

Растёт ли продуктивность разработки? Да, траектория положительная, и она значительно улучшилась. Частично это происходит благодаря обучению, специфичному для программирования. Очевидно, что мы обладаем лучшими моделями для кодинга в мире, и они становятся всё лучше и лучше (версия 3.5 просто невероятна). Однако, помимо этого, очень хорошо переносится и обучение, которое мы проводим вне контекста программирования. Существует своего рода эффект transfer (переноса): когда вы учите модель выполнять задачу X, она естественным образом улучшается и в выполнении задачи Y.

Прирост продуктивности был просто невероятным. В Anthropic за последний год, с момента внедрения Claude Code, мы, вероятно, увеличили инженерную команду в четыре раза, но продуктивность в пересчете на одного инженера при этом выросла на 200% в количественном выражении (по Pull Requests). Эта цифра кажется сумасшедшей для любого, кто работает в этой сфере и занимается вопросами продуктивности разработчиков.

Мой предыдущий опыт работы в Meta был связан именно с этим. Одной из моих обязанностей там было обеспечение code quality (качества кода) во всей компании — это касалось всех наших кодовых баз, включая Facebook, Instagram, WhatsApp и прочие ресурсы. Большая часть работы тогда сводилась к продуктивности, потому что логика проста: если вы повышаете качество кода, инженеры становятся более продуктивными. В то время мы видели показатели, при которых за год работы сотен инженеров над задачей можно было добиться роста продуктивности лишь на несколько процентных пунктов. Поэтому сегодня наблюдать прирост в сотни процентных пунктов — это нечто совершенно безумное.

Что также поражает, так это то, насколько нормализовались подобные показатели. Мы слышим эти цифры и реагируем буднично: мол, «конечно, ИИ делает это с нами». Однако количество изменений, происходящих сейчас в разработке программного обеспечения, в создании продуктов и в целом в технологическом мире, просто беспрецедентно. К этому очень легко привыкнуть, но важно осознавать, что текущая ситуация — это что-то из ряда вон выходящее. Это факт, о котором мне самому приходится напоминать себе время от времени.

Существует определенный недостаток в том, что модели искусственного интеллекта меняются очень часто. На личном уровне это вызывает сложности: модели развиваются настолько быстро, что я порой застреваю в устаревшем способе мышления о них. Более того, я замечаю, что новые сотрудники или недавние выпускники, приходящие в команду, подходят к задачам гораздо более «AGI-forward» (ориентированно на широкие возможности ИИ), чем я.

Рассмотрим пример, с которым я столкнулся пару месяцев назад: это был случай с утечкой памяти (memory leak). Это типичная ситуация, когда программный код работает, потребление памяти постоянно растет, и в какой-то момент приложение «падает». Это стандартная инженерная проблема, которую каждый разработчик решал тысячи раз. Традиционно способ решения выглядит так: вы делаете heap snapshot (снимок кучи), загружаете его в специальный отладчик, пытаетесь разобраться, что именно происходит, и используете специализированные инструменты для анализа ситуации. Я проделывал именно это: просматривал трассировки и пытался определить, в чем заключается проблема.

В то же время инженер, который работает в команде сравнительно недавно, просто попросил Claude (в исходном тексте «Quad Code», что является ошибкой распознавания при упоминании модели) решить эту задачу. Он спросил: «Эй, Claude, кажется, здесь утечка. Можешь разобраться?» И модель выполнила в точности те же действия, что и я: сделала heap snapshot, самостоятельно написала небольшой инструмент для его анализа, провела своего рода just-in-time программирование, нашла проблему и отправила pull request (запрос на слияние) быстрее, чем я.

Для тех из нас, кто использует подобные модели давно, по-прежнему необходимо ментально «транспортировать» себя в текущий момент и не застревать в старых моделях работы. Мы больше не говорим о временах «Sonnet 3.5» — новые модели стали совершенно иными. Эта смена парадигмы мышления очень существенна.

Для формирования культуры высокой скорости разработки необходима фундаментальная смена мышления. В командах, ориентированных на этот подход, существуют кодифицированные принципы, которые проговариваются с каждым новым сотрудником. Один из таких принципов звучит так: «Что может быть лучше, чем сделать что-то самому? Попросить Claude сделать это». Это именно то, что произошло в примере с memory leak (утечкой памяти): разработчик в какой-то момент забыл о принципе использования ИИ для решения проблемы, хотя это был самый очевидный путь.

Существует интересное явление: когда вы намеренно создаете ситуацию underfunding (недофинансирования) в проекте, это заставляет команду «клаудифицировать» (cloudify) процессы. Мы наблюдаем это, когда на проект выделяется всего один инженер. Такой специалист стремится завершить задачу максимально быстро, и это желание — intrinsic motivation (внутренняя мотивация). Человек просто хочет качественно выполнить работу; если у него есть хорошая идея, он хочет реализовать ее как можно скорее, и ему не нужно, чтобы кто-то его заставлял — инициатива исходит изнутри. Если у инженера есть доступ к инструментам вроде Claude, он может использовать их для автоматизации значительной части работы.

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

Идея недофинансирования интересна тем, что в общем сознании существует убеждение: ИИ позволит компаниям нанимать меньше сотрудников, меньше инженеров. Однако речь идет не просто о повышении продуктивности. Суть в том, что вы фактически добьетесь лучших результатов, если будете недофинансировать проект. Вы получите больше пользы от ИИ-инструментов, если над задачей работает меньше людей. Если нанимать классных инженеров и дать им возможность действовать, они разберутся, как решить задачу.

Мой совет CTO и руководителям всех уровней: не пытайтесь оптимизировать расходы или срезать бюджеты на начальном этапе. Начните с того, чтобы просто дать инженерам как можно больше токенов. Мы начинаем видеть, что в некоторых компаниях «неограниченные токены» становятся привлекательным бонусом при найме. Я всячески поощряю такой подход, потому что он дает людям свободу пробовать идеи, которые могли бы показаться слишком безумными. И если такая идея срабатывает, вы уже сможете понять, как ее масштабировать. Это именно тот момент, когда стоит начать оптимизировать расходы и сокращать затраты. Например, вы можете перейти с модели Claude Opus на работу с Haiku или Sonnet, когда задача уже понятна. Но поначалу стоит просто «забрасывать» задачу токенами, чтобы посмотреть, будет ли идея работать, и предоставить инженерам свободу действий. Рекомендация здесь проста: будьте щедры с использованием токенов при работе с моделями.

Может возникнуть мнение, что я говорю это только потому, что работаю в Anthropic и хочу, чтобы люди тратили как можно больше токенов. Но суть в другом: самые интересные и инновационные идеи рождаются, когда кто-то идет до конца и проверяет границы возможного. Реальность такова, что на малых масштабах затраты на токены в любом случае относительно невелики по сравнению с зарплатой инженера или другими операционными расходами бизнеса. Это не является огромной статьей затрат. Однако когда проект масштабируется и начинает потреблять огромное количество токенов, стоимость становится существенной. Именно тогда наступает момент для оптимизации. Мы в Anthropic начинаем видеть инженеров, которые тратят сотни тысяч долларов в месяц на токены, и мы наблюдаем такие же тенденции в других компаниях.

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

Несмотря на это, отношение к программированию как к способу создания чего-то полезного сохранилось у меня с самого начала. Однако в какой-то момент я лично попал в «кроличью нору» эстетики программирования. Я даже написал книгу про TypeScript (в то время это был самый крупный проект по TypeScript), просто потому что влюбился в сам язык. Я глубоко погрузился в принципы functional programming и тому подобные области. Мне кажется, многие программисты отвлекаются на это.

С моей точки зрения, в программировании действительно существует некая эстетика, особенно в functional programming и type systems. Это особое ощущение — «шум» в голове, который возникает, когда удаётся решить сложную математическую задачу. Похожее чувство ты испытываешь, когда балансируешь типы, и понимаешь, что программа получается по-настоящему красивой. Но всё же это не главное. Для меня кодинг — это в первую очередь инструмент, способ реализации задач.

При этом важно понимать, что не все подходят к этому одинаково. Например, у нас в команде есть инженер Лена, которая по выходным вручную пишет код на C++ просто потому, что ей это действительно приносит удовольствие. Все люди разные. Я считаю, что даже несмотря на то, как меняется наша профессиональная область и как всё вокруг трансформируется, всегда найдётся пространство для того, чтобы наслаждаться искусством программирования и заниматься созданием вещей «вручную», если у вас есть такое желание.

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

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

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

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

Для понимания происходящих сейчас перемен наиболее подходящей исторической аналогией является появление печатного станка. Если рассматривать Европу середины XV века, то уровень грамотности в то время был очень низким — менее 1% населения. В основном чтением и письмом занимались только писцы. Они работали на лордов и королей, которые зачастую сами не были грамотными. Задача этих немногочисленных специалистов заключалась в том, чтобы выполнять всю работу по переписыванию текстов, так как это была работа, требующая узкоспециализированных навыков.

Когда появился Иоганн Гутенберг и его печатный станок, произошел колоссальный сдвиг. Существует примечательный факт: за 50 лет после изобретения печатного станка было создано больше печатных материалов, чем за предыдущую тысячу лет. Объем печатной продукции резко возрос, а стоимость её производства значительно снизилась — примерно в 100 раз за последующие 50 лет.

Что касается уровня грамотности населения, то здесь изменения происходили медленнее, так как обучение чтению и письму — сложный процесс, требующий развитой образовательной системы и наличия свободного времени (когда человеку не нужно весь день работать на ферме). Однако в течение последующих 200 лет уровень грамотности в мире вырос до 70%.

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

Для инженеров сегодня это служит точным параллельным примером. Многих разработчиков уже не привлекает рутинная часть кодинга, которая всегда была сопряжена с деталями: настройкой Git, использованием различных инструментов и прочими техническими сложностями. Это не та часть, которую можно назвать веселой. Настоящее удовольствие приносит процесс создания чего-то нового, общение с пользователями, обдумывание масштабных систем, планирование будущего и сотрудничество с командой. Именно этим разработчики получают возможность заниматься чаще.

Современные инструменты позволяют заниматься этим всем — даже тем, у кого нет технического опыта. Люди без профильной подготовки могут реализовать то, что описывалось выше. В процессе создания небольших проектов при возникновении трудностей можно просто обратиться к инструменту с запросом «помоги мне разобраться», и проблема, которая раньше требовала долгих часов поиска на Stack Overflow и возни с библиотеками и зависимостями, решается пошагово: раз, два, три, четыре — и всё готово.

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

Влияние ИИ будет распространено на широкий спектр профессий, особенно тех, что примыкают к инженерному делу: продакт-менеджмент, дизайн, анализ данных. В будущем сфера применения ИИ расширится практически на любую деятельность, выполняемую за компьютером, поскольку модели становятся всё совершеннее. Агенты представляют собой следующий этап развития ИИ после простых языковых моделей, и именно через них люди, ранее не использовавшие технологии подобного рода, начинают осваивать их возможности. Если год назад никто толком не понимал, что такое «агент», и никто их не использовал, то сегодня это стало стандартом в работе.

В контексте индустрии термин «агент» (agent) зачастую используется неверно и теряет смысл, однако он имеет очень конкретное техническое определение. Агент — это ИИ, или языковая модель (LLM), способная использовать инструменты. Это значит, что такой ИИ не просто общается с пользователем, а может совершать активные действия и взаимодействовать с компьютерными системами: работать в Google Docs, отправлять электронную почту или запускать команды на компьютере.

Любая работа, подразумевающая использование компьютерных инструментов, будет затронута этими изменениями в ближайшее время. Это комплексная проблема, которую обществу и индустрии предстоит решить сообща. Именно поэтому в компании Anthropic вопросам влияния ИИ на рынок труда уделяют столь пристальное внимание, привлекая к исследованиям экономистов, экспертов по политике и социальных аналитиков.

Что касается дискуссий о потере рабочих мест: существует концепция парадокса Джевонса (Jevons paradox), согласно которой по мере роста нашей продуктивности мы склонны нанимать больше людей, а не меньше. По мнению лектора, ситуация с рынком труда не выглядит столь пугающей. Личный опыт лектора и наблюдения в компании показывают, что внедрение ИИ не ведет к сокращению штата — команда продолжает активно нанимать сотрудников. Кроме того, для самих инженеров использование ИИ-инструментов (таких как Claude) сделало процесс программирования гораздо более приятным, избавив от рутины. Подобные отзывы приходят и от многих клиентов.

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

Представим мир через несколько лет, где каждый человек способен программировать. Что это откроет? Любой сможет создавать программное обеспечение в любой момент по своему желанию. Мы не можем предсказать последствия так же, как люди в XV веке не могли предвидеть влияние печатного станка на современный мир. При этом в краткосрочной перспективе эти трансформации будут болезненными и разрушительными для многих. Это тот диалог и те вызовы, которые обществу предстоит осознать и преодолеть вместе.

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

Второй важный совет — стремиться быть generalist (универсальным специалистом) в большей степени, чем это было принято в прошлом. Традиционно, получая образование в области Computer Science (CS), многие учатся только писать код и не осваивают ничего другого, возможно, получая минимальные знания по системной архитектуре. Однако наиболее эффективные инженеры и менеджеры по продукту, с которыми приходится работать ежедневно, — это люди, которые выходят за рамки одной дисциплины.

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

• Гибридные специалисты — product and infrastructure engineers (продуктовые инженеры, разбирающиеся в инфраструктуре).
• Продуктовые инженеры с отличным чувством дизайна, способные самостоятельно выполнять дизайнерские задачи.
• Инженеры с хорошим пониманием бизнеса, которые используют эти знания, чтобы определять, что делать дальше.
• Инженеры, которые любят общаться с пользователями и могут на основе этого общения определять дальнейшие шаги по развитию продукта.

В ближайшие несколько лет наиболее востребованными специалистами станут не только те, кто является «AI-native» и отлично владеет инструментами, но и те, кто проявляет любопытство, является универсалом, пересекает границы нескольких дисциплин и способен мыслить шире, охватывая проблемы в целом, а не только их техническую часть.

Что касается разделения ролей (инженерия, дизайн, продакт-менеджмент), в краткосрочной перспективе они сохранятся. Однако уже сейчас наблюдается около 50% пересечения в этих ролях, когда разные специалисты по факту занимаются одной и той же деятельностью, сохраняя при этом свои специализации. Например, кто-то пишет код чуть больше, а кто-то фокусируется на координации, планировании, прогнозировании или stakeholder alignment (согласовании интересов стейкхолдеров).

К концу года границы между этими ролями станут еще более размытыми. В некоторых организациях название должности «software engineer» может начать исчезать, заменяясь на более широкое понятие — «builder» (строитель), или же может прийти к тому, что все станут продакт-менеджерами, которые при этом еще и пишут код.

Было проведено неформальное исследование в Twitter о том, как внедрение инструментов ИИ влияет на удовлетворенность работой среди различных специалистов. Опрос был разделен на три категории: инженеры, продакт-менеджеры (PM) и дизайнеры. Согласно результатам, 70% инженеров и PM сообщили, что стали получать больше удовольствия от работы после начала использования ИИ-инструментов, и лишь около 10% отметили, что стали наслаждаться работой меньше. У дизайнеров показатели оказались иными: только 55% ответили, что стали получать больше удовлетворения, а 20% — что меньше.

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

Важным аспектом является то, как именно люди используют инструменты. Например, дизайнеры в Anthropic чаще используют настольное приложение Claude для написания кода. В нем есть вкладка «Code», расположенная рядом с основной функцией чата, работающая на той же базе, что и Claude Code. Это позволяет программировать без необходимости открывать множество терминалов, сохраняя при этом мощность основного инструмента. Одной из ключевых возможностей является параллельный запуск сессий — так называемый multi-coding. Это более понятный и нативный способ работы для специалистов, которые не являются инженерами.

Такая практика отражает принцип «принесения продукта туда, где находятся люди». Суть заключается в том, чтобы не заставлять пользователей менять рабочий процесс или прилагать дополнительные усилия для освоения нового инструмента. Если удается облегчить выполнение того, что пользователи делают ежедневно, продукт становится лучше, и люди получают от него больше удовольствия.

Этот подход связан с принципом скрытого спроса (latent demand), который лектор называет одной из важнейших доктрин в разработке продуктов.

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

Как пример скрытого спроса (latent demand), можно рассмотреть Facebook Marketplace. Фиона, которая была первым менеджером команды Marketplace, часто говорит об этом. Продукт был запущен на основе наблюдения, сделанного примерно в 2016 году: 40% всех сообщений в Facebook Groups (группах Facebook) были связаны с куплей-продажей товаров.

Это была любопытная ситуация, своего рода «злоупотребление» функционалом продукта Facebook Groups. Разумеется, это не было злоупотреблением в сфере безопасности, но означало, что пользователи использовали продукт не по назначению, так как никто изначально не проектировал его для торговли. Пользователи сами приспособили группы для этих целей, потому что это оказалось крайне полезным. Стало очевидно: если создать специализированный продукт для купли-продажи, пользователям это понравится. Таким образом, успех Marketplace был предсказуем. Первым шагом в реализации этого решения стали отдельные «группы для купли-продажи» — специальные целевые группы для совершения сделок, а затем последовал запуск самого продукта Marketplace.

Facebook Dating начался со схожих наблюдений. В данном случае анализировались просмотры профилей пользователей на Facebook. Было замечено, что 60% всех просмотров страниц совершались людьми, которые не были друзьями друг с другом и при этом были противоположного пола. Это выглядело как некое подобие традиционного сценария знакомств: люди заходили на профили друг друга, по сути, «шпионя» (creeping) друг за другом. Возникла гипотеза: если построить продукт специально для этой цели, он может стать успешным.

Идея скрытого спроса (latent demand) является крайне мощным инструментом. Именно на ее основе возникло решение CoWord. Около полугода мы наблюдали, что многие люди использовали Quad Code вовсе не для написания кода. Были примеры совершенно неожиданного применения: кто-то в Twitter использовал его для выращивания помидоров, другой человек анализировал с его помощью геном, третий восстанавливал фотографии с поврежденного жесткого диска — кажется, это были свадебные снимки. Кто-то, по моим ощущениям, использовал его даже для анализа МРТ.

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

Мы заметили эту тенденцию довольно рано, где-то в мае прошлого года. Помню, как я пришел в офис и увидел, что наш data scientist по имени Брендан использует Quad Code на своем компьютере: у него был открыт терминал. Я был шокирован. Я спросил: «Брендан, что ты делаешь? Ты разобрался, как открыть терминал?». Это ведь очень инженерный инструмент — даже многие инженеры не хотят работать с терминалом, так как это самый низкоуровневый способ взаимодействия с компьютером, своего рода «погружение в дебри» системы.

В итоге, Брендан самостоятельно разобрался, как пользоваться терминалом, скачал Node.js, установил Quad Code и выполнял SQL-анализ прямо в терминале. Это было невероятно. А уже на следующей неделе все наши data scientists начали делать то же самое.

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

Традиционно существует некое интересное второе измерение понятия latent demand (латентный спрос). Стандартная концепция заключается в том, чтобы наблюдать за тем, что делают люди, делать их задачи немного проще и расширять их возможности. Однако современный подход, который начал формироваться в последние полгода, несколько отличается: теперь необходимо смотреть на то, что пытается делать сама модель, и упрощать именно этот процесс.

Когда мы начинали разработку Quad Code, мы заметили, что многие люди, проектирующие системы с использованием LLM, работают по модели «помещения модели в коробку». Она выглядит следующим образом: есть некое приложение, которое разработчик хочет создать, и есть определенная задача, которую должна выполнять модель. Разработчик жестко задает этот компонент, определяет, как модель будет взаимодействовать с инструментами, API и прочими интерфейсами.

В случае с Quad Code мы решили инвертировать этот подход. Мы исходили из того, что продуктом является сама модель. Мы стремились «обнажить» её, создать вокруг минимально возможные «строительные леса» (scaffolding) и просто дать модели необходимый набор инструментов. Это позволяет самой модели принимать решения: какие инструменты запустить, в какой последовательности их использовать и так далее. На мой взгляд, большая часть этой стратегии была основана на latent demand, то есть на том, что сама модель «хотела» делать. В исследовательских кругах это называется being on distribution (нахождение в рамках распределения). Вы буквально пытаетесь увидеть, что модель сама по себе пытается сделать. В контексте продукта latent demand — это ровно та же самая концепция, просто примененная к модели, а не к пользователю.

Разработка CoWord заняла у команды всего 10 дней, причем проект был полностью создан с использованием Quad Code (исправлено с Cloud Code по контексту работы с кодом). Успех продукта во многом объясняется невероятно сильной командой (Феликс, Сэм, Дженни и другие).

Возникновение CoWord стало ответом на латентный спрос: команда заметила, что пользователи применяют Quad Code для нетехнических задач, и пыталась выяснить, что с этим делать. В течение нескольких месяцев сотрудники пробовали разные варианты развития событий, пока в конечном итоге не возникла идея просто взять Quad Code и внедрить его в Desktop-приложение. Именно этот подход сработал.

Использование Quad Code позволило построить очень сложную и защищенную систему. Были выстроены guardrails (предохранители), которые гарантируют, что модель выполняет нужные действия и не выходит за рамки заданных параметров. Например, вместе с приложением поставляется целая виртуальная машина — весь код для этого был написан с помощью Quad Code. Команде оставалось лишь продумать, как сделать систему безопаснее и доступнее для пользователей, которые не являются инженерами.

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

В отличие от Quad Code, который после релиза не сразу стал хитом (потребовалось время, чтобы люди поняли, зачем он нужен и как его использовать, а сама модель поначалу была недостаточно хороша), CoWord стал популярным сразу после выпуска.

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

Первый, самый базовый уровень — это Alignment (выравнивание) и mechanistic interpretability (механистическая интерпретируемость). Это этап обучения модели, на котором мы стремимся обеспечить её безопасность. На сегодняшний день существуют достаточно сложные технологии, позволяющие нам понимать, что именно происходит внутри нейронов, и отслеживать эти процессы. Например, если в модели появляется нейрон, связанный с обманом, мы начинаем доходить до того уровня развития технологий, когда можем мониторить такую активность и понимать, что этот процесс начал работать.

Второй уровень — это evals (оценки). По сути, это лабораторные условия: модель помещается в «чашку Петри» для всестороннего исследования. Мы создаем синтетические ситуации и ставим перед моделью задачу, чтобы проверить её реакцию: «Хорошо, модель, что ты будешь делать? Поступаешь ли ты правильно? Остаешься ли ты в рамках выравнивания (aligned) и безопасна ли ты?».

Третий уровень — это наблюдение за тем, как модель ведет себя «в дикой природе» (in the wild), то есть в реальных условиях эксплуатации. По мере того как модели становятся всё более сложными, этот уровень приобретает критическое значение, потому что нейросеть может отлично проявлять себя на первых двух этапах — показывать хорошие результаты в лабораторных тестах и при механистической интерпретации, но при этом работать не лучшим образом в реальной среде.

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

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

Именно по этой причине мы выпускаем продукты на ранней стадии и называем это «research preview». Модель постоянно совершенствуется, и, по сути, это единственный способ обеспечить долгосрочную уверенность в том, что нейросеть останется выровненной и будет совершать правильные действия.

В данной сфере AI, где темпы конкуренции крайне высоки, существует постоянный страх, что модель может выйти из-под контроля и нанести ущерб, поэтому поиск баланса между развитием технологий и безопасностью является сложной задачей. Работа в этом направлении выстраивается вокруг трех уровней. Первый уровень — это наблюдение за тем, как модель думает и функционирует. Второй уровень включает систему тестов и оценок, которые выявляют, когда модель совершает нежелательные действия. Третий уровень подразумевает ранний выпуск моделей для обеспечения контроля. Первый уровень, или наблюдаемость (observability), позволяет заглянуть внутрь «мозга» модели и увидеть, как она мыслит и в каком направлении движется.

Этот инструментарий тесно связан с областью, называемой mechanistic interpretability (механистическая интерпретируемость), автором которой является Крис Ола (Chris Olah), эксперт в этой области. Суть данного подхода заключается в следующем: если рассматривать мозг человека или животного как совокупность соединенных нейронов, то его можно изучать на механистическом уровне, чтобы понять, что делают эти нейроны. Выяснилось, что это удивительным образом переносится и на нейронные сети: хотя нейроны моделей не идентичны биологическим, они во многом ведут себя схожим образом. Это позволило исследователям узнать очень многое о том, как функционируют подобные нейроны, как конкретный слой или нейрон соотносится с тем или иным концептом, как кодируются специфические понятия, и даже как модель осуществляет планирование и «думает наперед». В прошлом существовали сомнения, действительно ли модель делает что-то глубокое или просто предсказывает следующий токен, но сейчас накоплено достаточно много доказательств того, что процессы в моделях более глубокие.

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

Для команды Anthropic создание безопасных и полезных для мира технологий является главной миссией и причиной существования компании. Именно поэтому значительная часть исследований публикуется в открытом доступе. Компания делится наработками, чтобы вдохновить другие лаборатории, работающие над аналогичными темами, делать это безопасным способом.

Внутри компании этот принцип называют «гонкой к вершине» (race to the top). Примером реализации такого подхода служит Claude Code, для которого был выпущен открытый программный «песочница» (sandbox). Это среда, в которой может работать агент, при этом она гарантирует соблюдение определенных границ, таких как невозможность получить доступ ко всему содержимому системы пользователя. Этот проект был сделан с открытым исходным кодом и совместим с любыми агентами, а не только с Claude Code, что сделано для того, чтобы другие разработчики могли легко внедрять аналогичные меры безопасности. Это рычаг, который компания использует для того, чтобы убедиться, что развитие технологий движется в правильном и безопасном направлении.

Среди инженеров и продакт-менеджеров, работающих в связке с ИИ-агентами, наблюдается специфический тип тревоги, возникающий в ситуациях, когда агенты перестают корректно функционировать. Это состояние характеризуется чувством, что процесс «заблокирован» или агент находится в неопределенном статусе (вопрос/ответ), что влечет за собой страх потери продуктивности, заставляя человека стремиться немедленно «разбудить» агента и возобновить его работу. Это проблема, которую сообществу следует отслеживать и осмысливать.

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

Изменился и сам процесс разработки: на текущий момент лектор распределяет работу примерно поровну: одна треть времени проходит в терминале, одна треть — в десктопном приложении и одна треть — в iOS-приложении. Это неожиданный результат, так как еще недавно казалось, что такой сценарий кодинга в 2026 году будет невозможен.

Под «кодингом» сейчас подразумевается не написание программного кода как такового, а описание того, что именно пользователь хочет получить, фактически делегируя исполнение облачным системам.

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

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

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

При создании продуктов на базе искусственного интеллекта важно не пытаться «поместить модель в коробку», ограничивая ее поведение чрезмерно строгими рамками. Часто инстинкты разработчиков подталкивают их к созданию сложной системы, где модель является лишь одним из компонентов, а поверх нее накладываются жесткие рабочие процессы (например, требование обязательно выполнять шаг один, затем шаг два, потом шаг три с использованием сложных оркестраторов). На практике почти всегда можно добиться лучших результатов, если просто дать модели инструменты, поставить перед ней цель и позволить ей самостоятельно найти путь к решению. Если год назад для работы требовалось много вспомогательных конструкций (scaffolding), то сегодня в них практически нет необходимости. Принципиальная установка здесь заключается в следующем: не стоит спрашивать, «что модель может сделать для тебя» в узком смысле, лучше подумать о том, как предоставить модели инструменты для выполнения задач. Не пытайтесь чрезмерно курировать модель или предоставлять ей огромный объем контекста заранее, — лучше дайте ей инструмент, с помощью которого она сама сможет получить нужный контекст.

Еще один важный принцип, который является более общей версией описанного подхода, — это «горький урок» (the bitter lesson). Этот термин восходит к одноименной заметке Рича Саттона, опубликованной около десяти лет назад. Суть этой идеи предельно проста: более общая модель всегда будет превосходить более узкую, специализированную модель. Хотя Саттон в свое время приводил примеры из области беспилотных автомобилей и других доменов, у «горького урока» существует множество следствий. Для разработчика главный вывод следующий: всегда стоит делать ставку на более общую модель. Не нужно пытаться использовать крошечные (tiny) модели для специфических задач, не стоит прибегать к избыточному дообучению (fine-tuning) без веских на то причин. Используйте более общую модель, если у вас есть такая гибкость выбора.

В контексте этого принципа «рабочие процессы», о которых говорилось ранее, — это способ отойти от использования общей модели, пытаясь окружить ее подпорками (scaffolding). Как правило, такая обвязка может улучшить производительность на 10–20%, но часто эти достижения нивелируются с выходом следующей версии модели. Поэтому почти во всех случаях лучше просто дождаться следующего обновления модели.

Исходя из этого, можно сформулировать еще один принцип: всегда планируйте создание продукта с расчетом на модель, которая появится через полгода, а не на ту, что существует сегодня. В первые версии продукта Quadcode код писался минимально, потому что в тот момент модели еще не очень хорошо справлялись с программированием. Они «двигались» в нужном направлении, но это была ранняя стадия. Модель выполняла лишь базовые задачи (например, использовала Git), но не брала на себя существенную долю написания кода. Ставка была сделана на то, что в какой-то момент модель станет достаточно хорошей, чтобы самостоятельно писать большую часть программного кода. Инфлексия произошла с появлением моделей класса Opus 4 и Sonnet 4, когда пользователи начали массово использовать Quadcode, что привело к экспоненциальному росту. Это полезный совет для тех, кто строит стартапы: первые шесть месяцев соответствие продукта рынку (product-market fit) может быть не идеальным, и это вызывает дискомфорт. Однако, если строить систему с расчетом на возможности будущих моделей, то в момент их выхода ваш продукт мгновенно обретет эффективность, «включится» и начнет работать.

Основываясь на трендах развития технологий, можно сделать ставку на то, что модели будут становиться все лучше в двух ключевых направлениях. Во-первых, это использование инструментов и работа с компьютерами. Во-вторых, способность моделей эффективно функционировать в течение длительных периодов времени. Если проследить траекторию развития, например, Sonnet 3.5 — год назад модель могла эффективно работать около 15–30 секунд, прежде чем начинала «сходить с рельс», и требовала постоянного контроля («держать за руку») при выполнении сложных задач. Сегодня же, с моделями уровня Opus 4.6, среднее время работы без присмотра человека составляет от 10 до 30 минут. Есть примеры, когда модели работали автономно часами, днями и даже неделями. Со временем это станет нормой: модели будут выполнять задачи очень долгое время, и необходимость «нянчиться» с ними (babysit) отпадет.

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

Первый совет — всегда используйте наиболее мощную, способную модель. На данный момент актуальной моделью является Opus 4.6, и в настройках у меня всегда включен режим максимальной производительности (maximum effort). Часто возникает заблуждение, что для экономии средств стоит использовать менее производительные модели, такие как Sonnet или аналоги. Однако это не так: из-за меньшего уровня «интеллекта» такой модели в конечном итоге тратится больше токенов для выполнения той же задачи, а также требуется гораздо больше коррекций и «ручного управления» (hand-holding) со стороны человека. В результате использование менее дорогой модели может оказаться дороже и менее эффективно по количеству используемых токенов. Самая способная модель справляется с задачей значительно быстрее, требует меньше исправлений, и, следовательно, оказывается экономичнее.

Второй совет — используйте Plan Mode. Я начинаю почти все свои задачи, примерно в 80% случаев, именно в этом режиме. Суть Plan Mode предельно проста: в промпт модели внедряется одно предложение с инструкцией не писать код до тех пор, пока план не будет окончательно утвержден. В этом нет ничего сложного. Для тех, кто работает в терминале, переход в Plan Mode осуществляется двойным нажатием клавиш Shift-Tab. В десктопном приложении, веб-интерфейсе и мобильной версии для активации режима предусмотрены специальные кнопки, также эта функция была добавлена в интеграцию со Slack. В этом режиме модель ведет диалог с пользователем, и, только когда план выглядит удовлетворительно, вы разрешаете выполнение задачи. После утверждения плана я использую автоматическое принятие правок (auto accept), так как при использовании модели Opus 4.6 задача почти всегда выполняется верно с первого раза.

Третий совет — экспериментируйте с различными интерфейсами. Многие пользователи при упоминании Claude Code представляют исключительно работу в терминале. Разумеется, он поддерживается на всех платформах — Mac, Windows и любых других терминалах, но существует множество других форм-факторов для работы с инструментом. Мы предлагаем приложения для iOS и Android, десктопное приложение, интеграцию со Slack и другие возможности. Каждый инженер уникален, поэтому важно найти именно тот способ взаимодействия, который ощущается комфортным для вас. Нет необходимости ограничиваться только терминалом, ведь везде запускается один и тот же агент.

Ben Mann, сооснователь компании Anthropic, задал вопрос о том, какие существуют планы на период после создания AGI и на что будет похожа жизнь, когда мы достигнем этого состояния. Прежде чем присоединиться к Anthropic, я жил в сельской местности в Японии, и это был совершенно иной образ жизни. Я был единственным инженером в городе и единственным англоговорящим человеком, что создавало совершенно иную атмосферу. Пару раз в неделю я ездил на велосипеде на фермерский рынок мимо рисовых полей. Это была совершенно другая скорость жизни, полная противоположность Сан-Франциско. Одной из вещей, которая мне действительно нравилась, был способ, которым мы знакомились с соседями и выстраивали дружеские отношения — через обмен продуктами, например, соленьями. В том городе, где мы жили, все готовили мисо и делали соленья. Я стал довольно хорошо разбираться в приготовлении мисо и сделал несколько партий. Это то, чем я занимаюсь до сих пор.

Мисо — это интересная вещь, которая учит вас мыслить в категориях длительных временных отрезков, что сильно отличается от инженерии. Партия белого мисо готовится как минимум три месяца, а красное мисо требует от двух до четырех лет. Вы должны быть очень терпеливы: вы смешиваете ингредиенты, а затем просто оставляете это настаиваться. Именно это мышление в рамках длительных временных интервалов мне и нравится. Если бы я не был в Anthropic или мы оказались в мире после AGI, я бы, вероятно, занимался приготовлением мисо.

Философия Anthropic изначально строилась на последовательном подходе: разработка начиналась с написания кода, затем переходила к использованию инструментов (tool use), а в конечном итоге — к использованию компьютера (computer use). В компании придерживаются именно такой стратегии развития моделей, поскольку она позволяет наиболее эффективно изучать вопросы безопасности, проводить исследования и совершенствовать технологии.

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

При этом сейчас кажется, что мы находимся лишь в самом начале пути: большая часть мира еще не использует Claude Code и искусственный интеллект в принципе. Ощущение такое, что работа выполнена всего на 1%, и предстоит сделать еще очень многое. Это подтверждают и показатели: несмотря на огромные инвестиции и большие доходы, которые генерирует Claude Code и компания в целом, масштабы потенциального рынка все еще кажутся колоссальными.

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

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

Борис начинает с рекомендации технической книги, которую считает лучшей из прочитанных им: Functional Programming in Scala. Несмотря на то, что использование самого языка Scala в будущем может оказаться неактуальным, книга обладает уникальной элегантностью в подходе к функциональному программированию, мышлению и типам, что фундаментально изменило то, как Борис пишет код и размышляет о программировании. Ее можно воспринимать как своего рода исторический артефакт или как инструмент для личного профессионального роста.

Вторым бестселлером в жанре научной фантастики Борис называет Accelerando Чарльза Стросса. Это невероятно динамичная книга, в которой темп повествования постоянно возрастает, что, по мнению лектора, лучше всего передает суть текущего исторического момента. Сюжет охватывает период от начала технологического сингулярности до финала с участием коллективного сознания лобстеров, вращающегося вокруг Юпитера, — всё это происходит в течение нескольких десятилетий.

Третьей рекомендацией становится сборник рассказов The Wandering Earth (в русском переводе «Блуждающая Земля») Лю Цысиня. Борис отмечает, что хотя многим Лю Цысинь известен по «Задаче трёх тел», его рассказы нравятся ему даже больше. Помимо высокого литературного мастерства, эта литература интересна тем, что предлагает отличный от западного взгляд на научную фантастику, что само по себе заслуживает внимания.

Научная фантастика, по словам Бориса, играет важную роль в формировании мышления: она создает модели развития мира и помогает подготовиться к тому, куда движутся технологии.

Ведущий отмечает, что хотел бы в будущем сделать отдельный подкаст о жизни Бориса в Японии и его пути к работе в Anthropic. Затем собеседники обмениваются рекомендациями в жанре SF и обсуждают книгу Вернора Винджа A Fire Upon the Deep («Пламя над бездной»). Борис подтверждает, что это великолепное произведение, особенно интересное с точки зрения концепций ИИ (искусственного интеллекта) и AGI (сильного искусственного интеллекта). Также они упоминают приквел «Глубина в небе» (A Deepness in the Sky), отмечая, что это произведение довольно объемное и сложное для погружения, но очень качественное.

В рамках блиц-опроса я спросил о любимом недавнем сериале или фильме. Мой собеседник отметил, что на самом деле почти не смотрит телевизор или кино из-за нехватки времени, но сделал исключение для сериала «Задача трех тел» (3 Body Problem) на Netflix. Он посчитал, что это отличная экранизация книжной серии.

Отвечая на вопрос о продукте, который он недавно открыл для себя и который действительно полюбил, спикер порекомендовал Co-Work. По его словам, это инструмент, который кардинально изменил его повседневную жизнь, поскольку он запущен постоянно, а его интеграция с Chrome особенно эффективна. Инструмент помог оплатить штраф за парковку и отменил несколько подписок, избавив от большого количества рутинной работы.

Также он порекомендовал подкаст Acquired, который ведут Бен и Дэвид. Ему очень нравится то, как они погружаются в историю бизнеса и оживляют её. Тем, кто еще не слушал, он советует начать с эпизода про Nintendo.

Говоря о Co-Work, суть заключается в следующем: вы пишете, что хотите сделать, а система может запустить Chrome и выполнить действия за вас. Спикер привел пример одного сотрудника из Anthropic, который использовал его для заполнения надоедливых медицинских PDF-форм: программа просто загружает браузер, авторизуется и заполняет их. Эксперименты с этой технологией проводились еще год назад, но тогда модель была не готова. Сейчас же она работает по-настоящему эффективно. Спикер отметил, что многим людям сложно понять, что это такое, потому что они никогда раньше не пользовались агентами. Ему это напоминает ранние этапы Claude Code, но развитие идет гораздо быстрее, и технология начинает прорываться в массы.

Существует также расширение для Chrome, которое можно использовать отдельно: боковая панель в браузере, где вы можете общаться с Claude, который «видит» экран вашего браузера. Вы можете попросить его сделать что-то, узнать его мнение о том, на что вы смотрите, или попросить кратко пересказать содержание страницы.

Для тех, кто только начинает использовать Co-Work, рекомендуется следующий подход:

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

Во-вторых, настраивайте связки инструментов. Например, можно дать команду: «Посмотри мои самые важные письма, а затем отправь сообщения в Slack или занеси информацию в таблицу». Спикер, к примеру, использует это для проектного менеджмента: у них есть общая таблица для всей команды, где каждый инженер каждую неделю заполняет статус-отчет. Каждый понедельник Co-Work проверяет таблицу, находит тех, кто еще не заполнил отчет, и присылает им напоминание в Slack. Это избавляет его от необходимости делать ручную работу, и достаточно одного промпта, чтобы автоматизировать это действие.

В-третьих, можно запускать несколько задач параллельно. В Co-Work можно держать запущенными столько задач, сколько нужно. Спикер просто запускает проектный менеджмент, затем дает другие поручения, отдает их в работу и идет пить кофе, пока всё выполняется.

Существует пост, в котором собрано множество способов использования того, что раньше называлось Claude Code, а теперь доступно через Co-Work. Увидев эти примеры, многие люди задаются вопросом: «Ого, я и не думал, что это можно использовать таким образом».

Говоря о жизненном кредо, которое помогает в профессиональной деятельности, важно руководствоваться здравым смыслом (common sense). Многие неудачи, которые я наблюдаю, особенно в рабочей среде, происходят из-за того, что люди просто не пользуются здравым смыслом. Они следуют процессам, не задумываясь о них, или просто выполняют задачу, не осмысливая её суть. Также часто бывает, что люди работают над продуктом или идеей, которая изначально не является хорошей, но продолжают следовать набранному темпу, не подвергая это критической оценке.

Лучшие результаты, которые я вижу, достигаются, когда люди думают исходя из первых принципов (first principles) и развивают собственный здравый смысл. Если что-то кажется подозрительным («пахнет странно»), значит, скорее всего, это плохая идея. Это тот самый совет, который я даю коллегам чаще всего. Думаю, можно было бы посвятить отдельный подкаст обсуждению того, что такое здравый смысл и как его развивать, но сейчас мы оставим это без подробностей.

Что касается активности в Twitter (X), я начал пользоваться этой платформой по воле случая. Долгое время я использовал исключительно Threads, потому что когда-то помогал их разрабатывать, мне нравится их дизайн, это очень лаконичный продукт.

Началось всё с того, что мне стало скучно — я оказался в Европе, у меня было несколько свободных часов, и я исчерпал идеи, над которыми работал. Я открыл Twitter, увидел, что люди обсуждают QuadCode, и начал отвечать. Затем я решил, что было бы полезно специально поискать баги, о которых пишут люди, или посмотреть, какие отзывы они оставляют. Я представился, и люди стали массово писать о проблемах и давать фидбек.

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

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