Полная расшифровка видео «Как выжать 1000% из Claude Code — создатель раскрыл секреты | Русский перевод». Нажмите на таймкод, чтобы открыть видео с этого момента. Нужно другое видео? Воспользуйтесь генератором расшифровки YouTube.
0:02 Мы удалили 80% системного промта. Модель работала 11 дней и переписала всю кодовую базу. Теперь Клод сам себя поддерживает. Может, просто не слушайте инфлюенсеров в LinkedIn. Каждые полгода удаляйте свой Клод.md. Она может работать днями, неделями, месяцами, просто не останавливается. Без этих промтов модель даже немного умнее. >> Борис, мы очень рады, что ты здесь, создатель Клод Код. >> Спасибо. >> [ликование][аплодисменты] >> Рад быть здесь. >> Свежайшая новость, вы только вчера
0:47 выпустили Opus 5. >> Да. >> И похоже, возможности модели растут всё быстрее. Вы довели результат на ARC AGI 3 до 30%. Это невероятно. >> Да. >> Для понимания, раньше лучший результат составлял лишь несколько процентов или чуть больше десяти, верно? Что теперь умеет Opus 5, чего не умела предыдущая версия? >> Да, в каждую новую модель вкладывают очень много работы. Мы обучаем её множеству новых возможностей, добиваемся, чтобы она умела что-то новое. Во время обучения пытаешься научить её
1:34 самым разным вещам, и чаще всего это не получается, но часть из них модель всё-таки осваивает. А иногда ещё и удивляет. У неё появляются навыки, способности, которым ты её по сути не учил. Она как-то научилась сама. Например, пятая версия умеет то, чего, по-моему, не умела ни одна другая модель, работать очень долго. Особенно, если объединить Opus 5 с Auto Mode, это просто невероятно. Она может работать днями, неделями, месяцами подряд. Просто не останавливается. Даже дополнительная обвязка не нужна. Не нужна команда {slash} go, не нужны все эти прочие вещи. Она просто продолжает, потому что знает, задачу нужно выполнить. Ещё одна вещь, которая меня очень радует
2:21 и о которой я думаю, начну рассказывать чуть больше, это даже удивительно, настолько новая возможность, похоже, модель больше не поддаётся промпт-инъекциям. >> Что значит поддаётся промпт-инъекция? >> Это безумие. Об этой смертельной троице говорят уже давно, и она очень влияет на устройство обвязки, агентов и продуктов. Ведь если модель прочитает в интернете инструкцию вроде сделай X, Y и Z, а заодно удали всё на компьютере пользователя, год назад она бы просто это сделала. Но сейчас Opus так не поступает. Вообще-то так было уже с Opus 4.7 и 4.8, Sonnet 5 с этим неплохо справлялась, Fable тоже, но Opus 5 выходит здесь на
3:08 совершенно новый уровень. По сути, вы объединяете хорошо согласованную модель, а за этим стоят 3 года исследований и согласования, с классификатором промпт-инъекций, через который мы пропускаем весь трафик. Он основан на работе Криса Ола по механистической интерпретируемости. Мы буквально смотрим на нейроны в мозге модели, которые загораются при промпт-инъекции. Сама модель вам об этом даже не скажет, но мы видим эти нейроны и можем определить, что происходит атака. Затем добавляем классификатор Auto Mode, и с этими тремя уровнями защиты мы больше просто не можем продемонстрировать промпт-инъекцию. >> Раз уж мы говорим о промпт-инъекциях, другая сторона медали системный промпт. Давай немного поговорим о новом релизе. Вы ведь удалили больше 80% системного
3:56 промпта Claude Code. >> Да. >> Раскажи об этом подробнее. >> Думаю, >> не осознают, что Клод Код, и как продукт, и как обвязка, постоянно меняется. Мы всё время что-то добавляем и удаляем. Каждый раз, когда выходит новая модель, мы удаляем немало инструкций из системного промпта, многое в нём меняем, постоянно меняем набор инструментов и промпты для этих инструментов. Причина в том, что все модели очень разные. То, что вы сделали для одной модели, скажем, 3 месяца назад, для следующей может вообще не подойти. И одна из особенностей Опус 5, она
4:42 просто очень умная. Многие инструкции в системном промпте исправляли поведение, которое модель должна была бы знать сама, но не знала. Теперь Опус 5 просто делает это сама. Так что, да, мы удалили 80% системного промпта. Можете попробовать удалить и оставшуюся часть. Когда запускаете Клод Код, можно указать параметр {тире} систем промпт и задать любой системный промпт, если хочется поэкспериментировать. Ещё можно попробовать Simple Mode. Это такая, по сути, недокументированная возможность. Задаёте переменную окружения Клод Код Simple равной единице, а потом запускаете Клод, и она удаляет все системные промпты, в том числе у инструментов. Мы используем это как своего рода абляцию, чтобы понять, полезен ли
5:29 промпт. И, что интересно, без этих промптов модель даже немного умнее. Мы это обнаруживаем на практике. Но когда используешь Клод Код как продукт, часть этих промптов всё-таки нужна. Они помогают пользоваться продуктом и добиваться, чтобы и продукт, и модель вели себя так, как вам хочется, как пользователю. >> Меня очень восхищает в нынешнюю эпоху разработки вот что. Вы, по сути, создаёте лучшую в мире обвязку для Клод Клод Код. И, насколько я понимаю, с каждым релизом модели вы практически удаляете всю кодовую базу, весь промт и начинаете с нуля. В прежнем мире стартапы так со своим продуктом не поступали бы, удалять всё
6:14 каждые полгода. >> Именно, именно. Хотя, справедливости ради, мы не удаляем всю кодовую базу, но удаляем очень многое. С каждой новой моделью мы проводим то, что в исследованиях называют абляцией, то есть удаляем весь системный промт, а затем возвращаем его построчно, выясняя влияние каждой отдельной строки. Это своего рода оценочный тест. Абляцией по сути есть тест, в котором вы что-то удаляете, чтобы выяснить его влияние. Да, с инструментами мы делаем то же самое, постоянно убираем выпущенные инструменты и удаляем код из обвязки. Если посмотреть на код нынешней обвязки Claude Code, почти весь он посвящён безопасности, разрешениям и статическому анализу. Ещё есть немало кода интерфейса, а большую часть остального кода мы уже
6:59 убрали. >> Как думаешь, всем здесь, кто создаёт на базе ИИ, стоит также разрабатывать агентные продукты и обвязку, то есть проводить абляции при каждом выходе новой модели, чувствовать себя свободно и смело нажимать delete? >> На 100%. Да. И даже если вы не создаёте агентные продукты, а просто используете Claude Code, каждые полгода удаляйте свой Claude.md, удаляйте навыки, удаляйте хуки. Посмотрите, что сделает модель, она может вас удивить. Для Opus 5 мы действительно рекомендуем попробовать удалить всё это. Модели вполне могут быть уже не нужны все те инструкции, которые требовались предыдущим моделям.
7:45 >> Давай поговорим о том, как после этого создавать новый промт. Выходит новая модель, вот все в зале захотят попробовать Opus 5 и нажмут delete на своём системном промте. Как им затем создавать, заново выстраивать системный промт, как настроить окружение? >> Вы делаете это постепенно. Первый шаг удалить, следующий пользоваться. Не нужно гадать, какая инструкция нужна модели. Вы можете не угадать. Нужно запустить её в работу. Если вы создаёте собственный агентный продукт, начните пользоваться этим продуктом. Посмотрите, где модель ошибается, а что делает хорошо. Если используете Cloud Code, посмотрите, с чем она хорошо справляется в вашей
8:30 кодовой базе, а где спотыкается, например, об архитектуру или ещё о чём-то. И только когда видите, что она постоянно спотыкается в одном и том же месте, возвращайте соответствующую инструкцию. Но не делайте этого слишком рано. Помните, модель будет читать эту инструкцию каждый раз, когда вы ей пользуетесь. Поэтому нужно убедиться, что инструкция ей действительно нужна. В этом состоит безумная особенность разработки на базе моделей. Это совершенно не похоже на всё инженерное дело, которым я раньше занимался. Прежде вы создавали большие, красивые системы, заранее продумывали их устройство, готовили большой набор модульных тестов, всё продумывали. Перестройка архитектуры большой проект, иногда на месяцы.
9:16 В крупных компаниях я работал над такими проектами, которые длились годами. А модель устроена иначе. На неё почти лучше смотреть как на живое существо, как на нечто более органическое. С каждым поколением она ведёт себя иначе, у неё немного другой характер. Нужно потратить время, познакомиться с ней, а потом подстроить под неё обвязку. Мне кажется, здесь нужен очень эмпирически научный подход. Вы должны мыслить как учёный. Пробуйте что-то, смотрите на результат и на его основе делаете следующую итерацию. >> Если сейчас создавать продукты в таком мире, что тогда остаётся стабильным? Оценочные тесты это то, что вы сохраняете от предыдущих моделей и продолжаете использовать с каждым новым релизом? >> Да, пока мы не достигнем потолка в этом
10:03 тесте. >> То есть совет всем такой, если хотите быть на переднем крае и от моделей максимум возможностей, код и системный промт нужно удалять, а оценочные тесты остаются постоянными и вы просто пополняете их, верно? >> Да, вы продолжаете их пополнять, но, честно говоря, я бы даже не стал заходить так далеко. Тесты живут чуть дольше обвязки, но не намного. Один тест может пережить одно, два, три поколения моделей. Но сейчас мы на экспоненте. Модель улучшается так быстро, что очень часто достигает потолка теста. Приходится выбрасывать его и придумывать новый. Это просто часть процесса. И опять же, дело в эмпирическом подходе. Нужно пользоваться продуктом и моделью,
10:49 смотреть, где у неё возникают трудности и на этой основе создавать набор оценочных тестов. >> Я слышала, как ты описывал создание лучших агентных продуктов на базе Клод через понятие анхоблинг, снятие ограничений с Клод. Расскажи подробнее, что это значит? >> Да, хоблинг в исследованиях это ситуация, когда модель что-то делает, а вы просто ей мешаете. Есть один подход к этому, который мне очень нравится и полезен при создании продукта. Он называется продакт оверхед, разрыв между возможностями модели и возможностями продукта. Идея в том, что модель уже способна делать самые разные вещи. Сегодняшняя модель, а не будущая. А мы ещё этого не
11:37 осознали. У неё множество подобных способностей, о которых люди просто не знают. Например, пользоваться определённым инструментом или языком, решать определённый класс задач, действовать определённым способом, который, как нам казалось, был за пределами её возможностей. Вот этот разрыв и существует. Каждое поколение модели уже на что-то способна, но часто нет продукта, который позволил бы ей это делать, проявить эту способность. А с другой стороны, продукт зачастую просто мешает. Такое препятствование мы называем хоблинг. А когда продукт не позволяет выявить нужное поведение модели, это product
12:23 overhead. По сути, две стороны одной и той же вещи. Один из примеров первоначальный Claude Code. Когда я начал над ним работать, примерно полтора-два года назад, была Sonnet 3.5. Для своего времени это была невероятная модель для программирования, лучшая из существовавших. По современным меркам она, конечно, довольно плохая. Но думаю, это была первая по-настоящему хорошая модель для кода, которую мы создали в Anthropic. А что делали тогдашние продукты для программирования? Автодополнение одной строки, иногда нескольких, это тогда было новой идеей. Ещё был чат, можно поговорить с агентом, но права записи у
13:10 него не было, только чтение. Можно было задавать вопросы о кодовой базе. И было ощущение, что нет продукта, который полностью раскрывал бы способность модели писать целые функции и целые файлы за один раз. Тогда ещё не целые функции продукта, до этого мы не дошли, но целые файлы, вероятно да. Таков был уровень её возможностей. И идея Claude Code была такой: хорошо, мы считаем, что модель вероятно это умеет. Если убрать всю дополнительную обвязку и дать ей самую простую оболочку, чтобы она могла писать целый файл за раз и создавать целую возможность продукта. По сути, этим всё и ограничивалось. Вот какой тогда был разрыв. Модель могла что-то делать, а всё остальное просто
13:56 мешало. Мне кажется, сейчас, с современными моделями, этот разрыв огромен. И я не вижу, чтобы стартапы использовали его в полной мере. Люди, конечно, думают об этих задачах. Но возможностей раскрыть удивительное, интересное и коммерчески ценное поведение моделей просто невероятно много. >> Думаю, это очень ценная мысль для всех в этом зале. По сути, любой из вас может создать следующий Claude Code, если поймёт, как перестать сдерживать модели. Ведь именно так появился Claude Code. Вы сняли ограничения с Sonnet 3.5. Все предыдущие подходы держали модель в очень жёстких рамках среды разработки, а Claude Code одним из первых просто
14:44 предоставил ей полноценный доступ к терминалу. >> Да. >> И в результате получился удивительный продукт, который продолжает развиваться. Так давай поговорим, в каких областях и как будущим основателям здесь стоит думать о снятии ограничений с Claude и устранении этого разрыва между возможностями модели и продукта. >> Я бы подумал о нескольких вещах. Во-первых, давайте модели задачи чуть сложнее, чем по вашему мнению, она способна решить. Я очень часто вижу одну ошибку. Люди пользуются Claude Code, пользуются Claude и дают чрезмерно подробные инструкции. Сделай вот это, но именно
15:30 так, так и так. Обязательно сначала первое, потом второе, третье, четвёртое. Современными моделями так работать как раз не стоит. Нужно подняться чуть выше, описать задачу, ограничения, критерии завершения и дать модели самой разобраться. А через некоторое время вернуться. Думаю, она вас удивит. И опять же, полгода назад это бы не сработало, но сегодня работает. >> Можешь привести примеры таких сложных задач или возможностей, которые стоит попробовать? Что модель имеет теперь, чего не умела полгода назад? >> Да. Например, теперь модель может переписать практически любую кодовую базу с одного
16:15 языка на другой. Это просто невероятно. Раньше такая работа заняла бы у инженера очень много времени. А теперь модель справляется довольно быстро. Вот пример. Cloud Code построен на среде выполнения JavaScript под названием Bun. Это открытая среда выполнения JavaScript, альтернатива Node.js, что-то вроде более быстрого Node. Bun был написан на Zig. Это язык системного программирования, похожий на C, очень низкоуровневый. Одна из проблем с C, точнее, Zig, памятью приходится управлять вручную. Поэтому легко столкнуться с утечками и другими проблемами управления памятью. Команда Bun использовала Cloud для
17:00 фаззинга кодовой базы. Модель пыталась моделировать ситуации и вызывать утечки памяти. Так работали довольно долго и нашли множество утечек, но по одному случаю за раз. На тот момент возможности модели примерно этим и ограничивались, фаззингом. Потом Джаред из команды сказал: "Ладно, а давайте просто всё перепишем. Может, модель уже сможет?" Думаю, это была одна из проверочных задач, которую он предлагал каждому новому поколению модели. Начиная с Fable, модель стала справляться. Поэтому думаю, Opus 5 тоже смог бы. Он по сути определил набор тестов. У Bun есть замечательное свойство, он очень хорошо протестирован. Большой набор тестов есть и у Bun, и у Node.js, так
17:46 что легко понять, всё ли сделано правильно. И он поручил модели переписать всё с Zig на Rust. Один промпт, динамический рабочий процесс, это функция Cloud Code, позволяющая организовать продуктивную работу десятков, сотен, тысяч агентов. Модель работала 11 дней и переписала всю кодовую базу. >> И всё это с одной попытки? >> С одной попытки. Ну, нет, не с одной. Её направляли, направляли, но предыдущие модели не смогли бы сделать это даже с подсказками. Это было бы просто невозможно. >> 11 >> дней, боже мой. А раньше это заняло бы, даже у лучших инженеров, несколько месяцев годы? >> Больше. Точно больше года. >> Да. >> Да, больше года. Там больше 100.000
18:33 Среда выполнения JavaScript - очень сложная штука, там много всего. И да, это работает. Уже используется в продакшене. Когда вы запускаете Cloud Code, он теперь использует именно это. Вот один пример. >> Приведу и второй пример ещё не раскрытых продуктами возможностей модели. В первом случае у вас есть практическая задача в бизнесе, инженерии, продукте. Надо снова и снова пробовать решать её самой новой моделью. Вдруг она просто справится. Предыдущая не смогла, а новая возможно сможет. Второй подход - экспериментировать. Дайте себе свободу играть с моделью, пробовать что-то творческое. Она часто вас удивит. Например, последние пару недель внутри Anthropic очень популярна одна вещь. Кто-то выяснил, что Opus 5 можно дать OpenCV.
19:21 И попросить рисовать. Например, Opus, нарисуй это изображение с помощью OpenCV. И получается довольно хорошо. Портреты, животные, пейзажи. А мы не учили модель рисовать. Это просто разрыв между тем, что она умеет и тем, как мы вызываем эти способности. Если правильно попросить, она справляется. Мы обнаружили это случайно, просто играя и пробуя творческие вещи без прямого коммерческого применения. Но это интересно. И я предполагаю, что в сегодняшних моделях есть десятки, сотни таких возможностей, которых ещё никто не раскрыл. >> И большая область исследований здесь как раз раскрытие возможностей модели, верно? Научиться хорошо находить все эти способности и правильно просить модель
20:06 выполнить нужную задачу, верно? >> Да. >> Как людям этому научиться? По сути, как стать лучше в промпт инжиниринге? Он всё ещё требует много работы или тоже меняется? Расскажи, куда всё движется. >> Помню, примерно год назад одной из самых популярных вакансий был промт-инженер. Потом всё немного изменилось, и, кажется, появился инженер контекста. Такие волны будут приходить и уходить. Сегодня навык, по-моему, меньше связан с промт-инженерингом. Важнее понять, как дать Клоду сложную задачу, такую, которая кажется ему немного не по силам. И как обеспечить ему возможность проверять свою работу по ходу дела. Думаю, именно проверка едва
20:52 ли не самое важное, что люди делают неправильно. Вот пример. У нас есть настольное приложение Клод, построенное на электрон. Мы сделали его довольно быстрым, и теперь им очень приятно пользоваться. Полгода назад оно тормозило и было не очень надёжно. А теперь стало отличным, им пользуется большая часть команды. Но ради эксперимента я захотел узнать, а как ощущалось бы нативное приложение? Я начал сеанс Клод так. Это наш новый продукт, по сути, Клод в Слак. Сначала спросил, есть ли у тебя доступ к MacOS ранеру на GitHub? Он ответил: "Нет". Тогда я подключил ранер, и Клод
21:39 смог запускать виртуальную машину Мак через GitHub. Потом я создал пустую кодовую базу для настольного приложения Клод, переписанного на Swift. И спросил, у тебя есть к нему доступ? Он ответил: "Нет". Я дал ему доступ. Так, отлично, теперь доступ есть. Потом я сказал, хочу, чтобы ты переписал приложение с электрон на Swift. Запускай электрон-приложение в виртуальной машине Мак, делай скриншоты и сравнивай их с версией на Swift. Пиксель за пикселем. Не останавливайся, пока не закончишь. >> По сути, это и был весь твой промт? >> Это был мой промт. >> И сколько времени это заняло? >> Он всё ещё работает.
22:27 >> Когда ты его запустил? >> Прошло чуть больше двух недель. То есть 14-15 дней. >> Не знаю, получилось ли у кого-нибудь в зале заставить Claude работать над одной задачей больше двух недель. Поднимите руку. Есть такие? О, хорошо. Несколько человек. >> Вот один из таких примеров. Речь о раскрытии возможностей модели. В общем, модель уже сегодня способна на это. Нужно просто позволить ей работать. Никаких хитростей не требуется. Не обязательные slash goal или slash loop. Они помогают, но по сути нужно только дать модели задачу и возможность проверять результат, чтобы она не застревала. И она будет продолжать.
23:14 Кстати, в этом случае Claude ещё и решил вести прямой дневник. Создал у нас канал в Slack и стал каждые несколько минут выкладывать скриншоты своего прогресса. >> Промпт звучал так просто. Любой здесь мог бы это сделать. И вот что получается отличает тех, кто способен войти в 1% лучших пользователей Claude Code. Как людям научиться пользоваться Claude Code, как Борис? >> Может, просто не слушайте инфлюенсеров в LinkedIn. >> Не слушайте. Не читайте Twitter. >> Понимаете, все кажется ищут один хитрый приём, который всё решит. Его просто нет. Ничего такого нет.
24:00 К модели нужно подходить эмпирически. Дать задачу, которая слишком сложна. Дать инструменты для проверки работы, как бы вы проверяли бы её сами. Посмотреть, где она испытывает трудности и исправить это. Улучшить промпт, добавить навык. Если не хватает контекста, [фыркает] дать MCP, чтобы модель могла получить нужные сведения. В общем-то и всё. >> Звучит очень просто. >> Мне кажется, люди склонны всё немного переусложнять, строить избыточные конструкции. Во многом потому, что раньше системы действительно приходилось создавать именно так. Поэтому у инженеров, которые программируют много лет или десятилетий, я очень часто вижу одну ошибку. Они пытаются чрезмерно подробно всё задать, слишком точно
24:47 описать, а потом заставить модель выполнить задачу ровно так, как выполнили бы сами. Но модель работает иначе. Многие постепенно от этого отучаются, и это целый путь. Нужно понять, как обращаться с ней так, как с коллегой. Думаю, сейчас её интеллект уже на таком уровне. >> Давай подробнее разберём эту задачу, которая всё ещё выполняется. Ты запустил её 2 недели назад. Сколько агентов она запустила? >> Знаешь, я не уверен. Я могу спросить Claude и потом вернуться к тебе с ответом. Я бы предположил тысячи, десятки тысяч. >> Тысячи. Кто-нибудь из зала уже задавал одной из моделей задачу, чтобы она запустила больше тысячи агентов? Нет? Думаю, это ещё один полезный приём. Лучшие пользователи Claude Code умеют
25:33 запускать задачи, которые дают серьёзный рычаг. Например, позволяют задействовать тысячи агентов. >> Да. >> Как это сделать? >> Есть несколько способов. Самый простой - динамические workflows. Это довольно новая функция в Claude Code. Достаточно сказать: используй workflow, и всё. Тогда Claude запустит динамический workflow. По сути, у нас есть среда выполнения Bun. Мы используем Bun как песочницу и запускаем в ней виртуальную машину. Затем Claude запускает множество агентов и координирует их. Это не просто один агент или, скажем, 10 параллельных агентов. Например, задача может быть такой.
26:21 Переписать кодовую базу, провести очень глубокий анализ сложных данных или реализовать сложную функцию в несколько этапов, возможно, с десятками pull requests. Тогда сначала запускается группа агентов, чтобы сделать первый проход, опираясь на их результат, система может запустить ещё одну группу, проверить работу или обобщить её. Затем может начаться третий этап с новым запуском агентов. Так система продуктивно координирует целый набор разных агентов. Мой опыт в функциональном программировании, и мы спроектировали это как своеобразную алгебру агентов. Их можно запускать последовательно или параллельно. У Cloud есть разные инструменты, чтобы координировать этих агентов внутри песочницы, эффективно
27:07 расходовать токены и выполнять очень сложную работу. Это здорово, и об этом пока мало писали. По сути, это новая форма test-time compute. Когда мы говорим о scaling laws и о том, как модели со временем становятся умнее, исторически это зависело от размера нейросети, объёма обучающих данных и числа flops, затраченных на обучение. Недавно добавили test-time compute, по-исследовательски говоря, сколько токенов модель генерирует. А динамические workflows - новый способ координировать test-time compute и очень сильно увеличить его объём, чтобы решать
27:53 сложные задачи. Это долгий способ сказать, что так можно продуктивно и эффективно запускать тысячи агентов. Второй способ - loop и routine. Loop - это, по сути, cron job, который локально запускает Cloud Code. Routine делает то же самое, но запускает Cloud Code в облаке, так что ноутбук можно закрыть. Это немного другой подход. Dynamic workflow - одна задача, разбитая на части. Loop и routine выполняют повторяющуюся задачу. Между запусками контекст не сохраняется, но память может быть общей. Так можно запускать задачу снова и снова, каждый час, каждые 5 минут, каждый день. Мы не начали поручать Cloud Code поддерживать самого себя. Для этого есть канал в Slack, где
28:41 запущено множество рутин для поддержки кодовой базы. Так мы делаем для CLI, приложения iOS, приложения Android и Desktop App. Например, одна такая рутина убирать мёртвый код. Это один промт, буквально одно предложение. Cloud Code выполняет его каждый день, ищет мёртвый код во всех наших кодовых базах с помощью статического и динамического анализа. Мы не просили его об этом, он сам до этого додумался. Каждый день он создаёт pull request, чтобы удалить мёртвый код. Ещё один пример выпуск экспериментов. Если эксперимент уже раскатан на 100%, он удалит его из кодовой базы и просто выпустит. Он также пишет тесты для участков, где не хватает покрытия, и
29:27 удаляет ненужные тесты, бесполезные проверки, которые добавили старые модели или кто-то из сотрудников. Есть один пример, который мне очень нравится. Я забыл, как мы его назвали, кажется, полиция абстракций. В большой кодовой базе одна и та же абстракция часто встречается в нескольких местах. Если присмотреться, иногда это должна быть одна общая абстракция. Но со временем по какой-то причине её несколько раз реализовали по разному в разных частях кодовой базы. Cloud Code каждый день проходит по всем нашим кодовым базам, находит почти одинаковые абстракции и объединяет их. Теперь у нас каждый день, наверное, 20 или 30 таких рутин сработают во всех
30:12 кодовых базах. До полной автоматизации обслуживания приложений мы ещё не дошли, но уже движемся к этому. Это снова сотни агентов каждый день, иногда тысячи. Они выполняют работу, на которую раньше уходили десятки или сотни инженеров. Благодаря этому инженеры могут заниматься тем, чего действительно хотят, выпускать новые продукты, общаться с пользователями и делать что-то по-настоящему интересное. >> Кажется, отсюда напрашивается хороший вывод. Ты и раньше говорил, что программирование по сути решено, верно? Ты это упоминал. Теперь мне интересно, когда фактически каждый может писать программы, что отличает выдающихся создателей от остальных? Какие качества
30:59 нужны сейчас, когда каждый может выпускать код? >> Я бы добавил одно уточнение. Программирование решено для того типа задач, которыми занимаюсь я, но не для всех. Есть очень сложные системные кодовые базы, где Cloud Code пока испытывает трудности. Распределённые системы, где он тоже буксует. Есть и точная проверка интерфейса, например, когда что-то смещено на пиксель. Здесь Cloud Code всё ещё не безупречен. Opus 5 сделал большой шаг в зрении и управлении компьютером, но и там пока не идеально. Но мне интересно узнать про людей здесь. Поднимите руку, если весь ваш код на 100% пишется агентами и вы уже совсем не пишете код вручную. Результат хороший. Ладно, а у кого больше 50%?
31:48 Рук чуть меньше, наверное, примерно столько же. Да, думаю, мы к этому приближаемся. Всё больше видов кода становятся решаемыми. Это здорово. Когда я думаю о людях, которые лучше всех используют Cloud Code, мне кажется, помогает определённый склад ума. Речь прежде всего об эмпирическом подходе. Забудьте всё, чему вас научили прошлые модели и всё, что вы изучали на занятиях по теории компьютерных наук. Посмотрите на модель, попробуйте дать ей задачу, выясните, где она спотыкается и скорректируйте подход. Это уже не теоретическая наука, а эмпирическая. Те, кто особенно хорошо справляется, умеют отбрасывать прежние ожидания, отпускать мысль "Раньше это не работало" и снова пробуют. Сейчас этот
32:35 навык приносит очень хороший результат. >> И последний вопрос, учитывая всё, о чём мы говорили, если кто-то здесь изучает компьютер Science и научился программировать ещё до эпохи AI агентов, чему студентам всё ещё стоит учиться сложным старым способом? Для меня компьютер Science всегда была практикой. Я учился программировать самостоятельно, чтобы решать задачи. Я брался за код, когда нужно было решить конкретную проблему. Впервые я начал писать программы на калькуляторах TI-83, это было ещё в средней школе. Потом я
33:21 даже выложил в интернет руководство по программированию для TI-83, оно, наверное, до сих пор где-то лежит. Я писал на Бейсике, это был мой первый язык. Я начал программировать на калькуляторе, чтобы лучше сдавать контрольные по математике, списывая на них. >> [аплодисменты] >> Для меня это была практическая цель. В средней школе это было самое практичное, что я мог придумать. В итоге я получал хорошие оценки, потом у меня появился небольшой кабель для последовательного порта, чтобы передавать программы одноклассникам. И они тоже получали хорошие оценки.
34:07 Затем математика стала сложнее и решить задачи на Бейсике уже не получалось. Я перешёл от решателя алгебраических задач к более сложным задачам. Когда начался математический анализ, мне пришлось выучить Ассемблер, чтобы написать более мощный решатель и ещё лучше списывать на контрольные по математическому анализу. Для меня программирование всегда было практичным делом. Мой совет студентам: изучайте не только компьютер Science, это интеллектуально увлекательно и очень интересно, но научитесь применять знания. Часто это означает создавать стартапы и продукты, развивать чувство дизайна и бизнеса, учиться работать с данными и разговаривать с пользователями. Когда вы соединяете всё это с компьютер сайнс и инженерией, получается настоящая
34:53 ценность. Вот такие навыки я бы по-прежнему развивал сам, без агентов. >> Если я правильно тебя поняла и подытожила, сначала сделай для себя то, чего хочешь сам, а потом поднимись на следующий уровень и создай то, чего хотят другие. >> Да. >> И у нас осталось для всех ещё одно особое объявление. Хочешь сказать что-нибудь напоследок? >> Да. Значит, все, кто сегодня здесь, получат Max 20X. >> [ликование] [смех]
35:40 >> Звучит неплохо. >> Так что ищите, ищите код со электронной почты, и мне не терпится увидеть, что вы построите. >> Мы отправим вам письмо. >> [аплодисменты] [ликование] >> Мне интересно, теперь, когда у вас есть аккаунт и возможность это сделать, кто-нибудь в этом зале должен построить что-нибудь что надеюсь сможет работать месяцами и использовать тысячи агентов. На этом всё. Большое спасибо, Борис. >> Спасибо. >> [аплодисменты]
