00:00:00(ритмичная музыка)
00:00:02— Привет всем, как дела?
00:00:23Это очень круто, я Декс.
00:00:25Как и было сказано в том отличном представлении,
00:00:27я уже довольно давно занимаюсь ИИ-агентами.
00:00:29Наш доклад «12 факторов агентов» на конференции AI Engineer в июне
00:00:32стал одним из самых популярных за всё время.
00:00:34Кажется, он вошел в топ-8 или около того,
00:00:35один из лучших докладов июньской конференции.
00:00:38Там я, возможно, упоминал кое-что о контекстной инженерии.
00:00:41Почему я здесь сегодня и о чем хочу рассказать?
00:00:44Я хочу обсудить одно из моих любимых выступлений
00:00:46на AI Engineer в июне.
00:00:47Я знаю, что вчера мы получили свежие новости от Игоря,
00:00:49но мне не разрешили менять слайды,
00:00:50так что речь пойдет о том, о чем Игорь говорил в июне.
00:00:54Вкратце: они опросили 100 000 разработчиков
00:00:56из компаний самых разных размеров
00:00:58и выяснили, что в большинстве случаев,
00:01:00когда вы используете ИИ для разработки ПО,
00:01:01вам приходится делать много переделок и правок.
00:01:04ИИ не очень хорошо справляется со сложными задачами
00:01:07в уже существующих, «устоявшихся» кодовых базах.
00:01:08На графике видно, что,
00:01:10по сути, вы выпускаете гораздо больше кода,
00:01:11но огромная его часть — это просто переделка того мусора,
00:01:14который вы выпустили на прошлой неделе.
00:01:15С другой стороны,
00:01:18если вы пишете проект с нуля, какой-нибудь простой дашборд,
00:01:21тогда всё работает отлично.
00:01:25Но если зайти в 10-летнюю кодовую базу на Java,
00:01:28результат будет уже не тот.
00:01:29И это совпало с моим личным опытом.
00:01:30Общаясь со многими фаундерами и крутыми инженерами, я слышал:
00:01:32слишком много «шлака», это фабрики техдолга,
00:01:35в нашем коде это работать не будет.
00:01:37Может быть, когда-нибудь, когда модели станут лучше.
00:01:40Но именно в этом и суть контекстной инженерии.
00:01:42Как выжать максимум из сегодняшних моделей?
00:01:44Как грамотно управлять окном контекста?
00:01:46Мы говорили об этом в августе.
00:01:48Должен признаться в одной вещи.
00:01:49Когда я впервые попробовал Claude Code, я не был впечатлен.
00:01:53Ну, окей, подумал я, это чуть лучше, мне нравится интерфейс.
00:01:54Понятно.
00:01:56Но с тех пор наша команда кое-что нащупала,
00:01:59благодаря чему мы смогли
00:02:01увеличить производительность в 2-3 раза.
00:02:02Мы выпускали столько кода, что у нас не было выбора,
00:02:06кроме как изменить сам способ взаимодействия.
00:02:07Мы полностью перестроили процесс создания ПО.
00:02:11Нас было трое, это заняло 8 недель, и это было чертовски сложно.
00:02:12Но теперь, когда мы решили эту проблему, мы никогда не вернемся назад.
00:02:14Это как раз про отсутствие «шлака» в коде.
00:02:16Кажется, мы чего-то добились.
00:02:18В сентябре это стало суперпопулярным на Hacker News.
00:02:20Тысячи людей зашли на GitHub
00:02:23и взяли нашу систему промптов «исследование-план-реализация».
00:02:25Цели, к которым мы в итоге пришли:
00:02:28нам нужен ИИ, который хорошо работает в старом коде,
00:02:31который может решать сложные задачи.
00:02:35Никакого «шлака», понимаете? Больше никакого мусора.
00:02:38И нам нужно было сохранять ментальную синхронизацию.
00:02:40Через минуту я расскажу подробнее,
00:02:42что именно это значит.
00:02:43И, конечно, мы хотим тратить,
00:02:44как и во всём остальном, как можно больше токенов.
00:02:46То, что мы можем эффективно делегировать ИИ,
00:02:47действительно очень важно.
00:02:50Это дает колоссальное преимущество.
00:02:52Итак, это продвинутая контекстная инженерия для кодинг-агентов.
00:02:53Начну с небольшого вступления.
00:02:56Самый примитивный способ использовать кодинг-агента —
00:02:58это попросить его о чем-то, потом сказать, в чем он ошибся,
00:03:01попытаться его перенаправить и просить снова, и снова, и снова,
00:03:03пока у вас не закончится контекст, вы не сдадитесь или не расплачетесь.
00:03:05Но мы можем подойти к этому умнее.
00:03:09Большинство людей довольно быстро понимают
00:03:11в ходе своих экспериментов с ИИ, что иногда лучше,
00:03:13если диалог зашел не туда,
00:03:17просто начать в новом окне контекста.
00:03:21Вы говорите: «Окей, тот путь был тупиковым».
00:03:24«Давай начнем сначала».
00:03:25Тот же промпт, та же задача.
00:03:26Но на этот раз пойдем вот этим путем.
00:03:27И не ходи туда, потому что это не работает.
00:03:29Как понять, что пора начинать заново?
00:03:31Если вы видите вот это,
00:03:34(смех в зале)
00:03:37значит, точно пора начинать сначала, верно?
00:03:39Это то, что говорит Claude, когда вы указываете ему на косяки.
00:03:41Но мы можем быть еще хитрее.
00:03:45Мы можем использовать то, что я называю «намеренным сжатием».
00:03:47Суть в том, что независимо от того, на правильном вы пути или нет,
00:03:50вы можете взять текущее окно контекста
00:03:53 и попросить агента сжать его в один Markdown-файл.
00:03:56Вы можете его проверить, разметить тегами.
00:03:59И когда запустится новый агент,
00:04:00он сразу приступит к работе вместо того, чтобы
00:04:02заново искать файлы, вникать в структуру кода
00:04:04и пытаться войти в курс дела.
00:04:05Что именно входит в это «сжатие»?
00:04:07Вопрос в том, что именно занимает место
00:04:09в вашем окне контекста?
00:04:11Это поиск файлов, понимание логики работы кода,
00:04:13редактирование файлов, результаты тестов и сборки.
00:04:17И если у вас подключен MCP, который вываливает кучу JSON-данных
00:04:20и UUID-идентификаторов в ваш контекст,
00:04:22то да поможет вам бог.
00:04:25Так что же нам нужно сжимать?
00:04:26Я еще вернусь к деталям,
00:04:28но вот пример хорошего сжатия.
00:04:30Это именно то, над чем мы работаем:
00:04:31конкретные файлы и номера строк,
00:04:33имеющие значение для решаемой задачи.
00:04:34Почему мы так помешаны на контексте?
00:04:37Потому что за это утверждение LLM уже критиковали на YouTube.
00:04:39Они не являются «чистыми функциями», так как они недетерминированы,
00:04:42но они не сохраняют состояние (stateless).
00:04:45И единственный способ добиться лучшего результата от LLM —
00:04:46это подать на вход лучшие токены,
00:04:49чтобы получить лучшие токены на выходе.
00:04:51На каждом шаге цикла,
00:04:52когда Claude или любой другой агент выбирает следующий инструмент...
00:04:53Могут быть сотни правильных следующих шагов
00:04:55и сотни неправильных.
00:04:56Но единственное, что влияет на то, что будет выдано далее,” —
00:04:58это содержание текущего диалога.
00:05:00Поэтому мы будем оптимизировать это окно контекста
00:05:03по точности, полноте, размеру
00:05:05и немного по «траектории».
00:05:07Траектория — это интересно,
00:05:10потому что многие говорят:
00:05:11«Я сказал агенту сделать что-то,
00:05:12а он сделал это неправильно».
00:05:13«Я его исправил, накричал на него,
00:05:16но он снова всё испортил».
00:05:17«И я опять на него наорал».
00:05:18И вот LLM смотрит на этот диалог и думает:
00:05:20«Окей, ясно: я накосячил, человек наорал,
00:05:21я опять накосячил, он опять наорал».
00:05:23«Значит, самый вероятный следующий токен в этой беседе —
00:05:24мне нужно снова облажаться,
00:05:25чтобы человек мог еще раз на меня прикрикнуть».
00:05:26Так что следите за своей траекторией.
00:05:29Если расставить приоритеты от обратного,
00:05:31то хуже всего — неверная информация,
00:05:33затем — нехватка информации, и только потом — лишний шум.
00:05:35Если любите формулы, вот вам простенькое уравнение,
00:05:36если вам так проще думать об этом.
00:05:39Джефф Хантли провел много исследований кодинг-агентов.
00:05:42Он очень точно подметил:
00:05:44чем больше вы забиваете окно контекста,
00:05:47тем хуже будут результаты.
00:05:51Это подводит нас к концепции,
00:05:51очень «научной» концепции под названием «зона тупости».
00:05:53Итак, у вас есть окно контекста.
00:05:55Примерно 168 000 токенов.
00:05:56Часть зарезервирована под вывод и сжатие.
00:05:59Это зависит от модели,
00:06:01но возьмем для примера Claude Code.
00:06:03Отметка в 40% — это то место, где вы начнете
00:06:05замечать снижение эффективности в зависимости от задачи.
00:06:07Если у ваших кодинг-агентов слишком много MCP-подключений,
00:06:09вы делаете всю работу в «зоне тупости»
00:06:10 и никогда не получите хороших результатов.
00:06:14Люди об этом уже говорили.
00:06:17Не буду на этом останавливаться.
00:06:18Результаты могут отличаться.
00:06:2140% — это примерный ориентир, всё зависит от сложности задачи.
00:06:21Вернемся к сжатию, или, как я буду называть это впредь,
00:06:22«умному избеганию зоны тупости».
00:06:23Мы можем использовать субагентов.
00:06:26Если у вас есть субагент для фронтенда, субагент для бэкенда,
00:06:28субагент для QA и субагент-дата-сайентист — пожалуйста, остановитесь.
00:06:31Субагенты нужны не для антропоморфизации ролей.
00:06:33Они нужны для контроля контекста.
00:06:37Вы можете сделать следующее: если вам нужно найти,
00:06:39как что-то устроено в огромной кодовой базе,
00:06:44вы можете направить агента сделать это,
00:06:47если он поддерживает субагентов,
00:06:49или собрать свою систему субагентов.
00:06:51Вы просто говорите: «Эй, выясни, как это работает».
00:06:53И он может выделить это в новое окно контекста,
00:06:55в котором будет происходить всё это чтение, поиск,
00:06:56просмотр целых файлов
00:06:58и анализ всей кодовой базы.
00:07:00А затем он просто вернет очень краткое сообщение
00:07:03обратно родительскому агенту, что-то вроде:
00:07:05«Нужный тебе файл находится здесь».
00:07:07Родительский агент прочитает этот один файл и сразу примется за дело.
00:07:09Это очень мощный инструмент.
00:07:13Если владеть им правильно,
00:07:14можно получать отличные результаты
00:07:17и очень эффективно управлять контекстом.
00:07:20Но что работает даже лучше субагентов
00:07:22или как надстройка над ними,
00:07:23так это рабочий процесс, который я называю «частым намеренным сжатием».
00:07:25Мы обсудим схему «исследование-план-реализация» через минуту,
00:07:29но суть в том, что вы постоянно
00:07:30или даже надстройка над ними,
00:07:32— это рабочий процесс, который я называю «частое намеренное уплотнение».
00:07:35Мы обсудим схему «исследование-план-реализация» через минуту,
00:07:37но суть в том, что вы постоянно
00:07:39держите окно контекста маленьким.
00:07:41Вы строите весь процесс вокруг управления контекстом,
00:07:45и он состоит из трех фаз: исследование, план и реализация,
00:07:48и мы стараемся все время оставаться в «умной зоне».
00:07:51Исследование нужно для понимания того,
00:07:53как работает система, поиска нужного файла
00:07:55и сохранения объективности.
00:07:56Вот промпт, который можно использовать для исследования.
00:07:58А вот результат работы такого промпта.
00:08:00Все это — открытый код.
00:08:01Вы можете взять их и потестировать сами.
00:08:04При планировании вы намечаете точные шаги.
00:08:06Вы указываете имена файлов и фрагменты строк.
00:08:08Вы должны четко прописать, как мы будем все проверять
00:08:10после каждого изменения.
00:08:11Вот пример хорошего промпта для планирования.
00:08:12А вот один из наших планов.
00:08:13В нем есть реальные фрагменты кода.
00:08:16Затем мы переходим к реализации.
00:08:17И если вы прочитаете такой план,
00:08:17то легко поймете, почему даже самая «глупая» модель в мире
00:08:20вряд ли здесь накосячит.
00:08:23Так что мы просто идем по пунктам, выполняем план
00:08:24и держим контекст на низком уровне.
00:08:26Промпт для планирования, как я уже сказал,
00:08:27это самая скучная часть процесса.
00:08:30Я хотел проверить это на практике.
00:08:31В рамках нашей работы я веду подкаст со своим другом Вайбхавом,
00:08:34который является CEO компании Boundary ML.
00:08:37И я сказал: «Слушай, я попробую с одной попытки пофиксить баг
00:08:39в вашей кодовой базе на Rust объемом 300 000 строк,
00:08:41написанной для языка программирования».
00:08:42Весь этот эпизод записан.
00:08:45Он длится около полутора часов.
00:08:46Я не буду сейчас пересказывать всё,
00:08:47но мы провели кучу исследований,
00:08:48а потом выкинули их, потому что они были плохими.
00:08:49Затем мы составили план без исследования и с ним,
00:08:51и сравнили все результаты.
00:08:53Было весело.
00:08:54Это было в понедельник вечером.
00:08:55А к утру вторника мы уже были на шоу,
00:08:57и их CTO уже увидел PR (пулл-реквест),
00:08:59не осознавая, что я сделал это просто ради прикола в подкасте.
00:09:03И он такой: «Да, выглядит отлично.
00:09:04Добавим это в следующий релиз».
00:09:05Он был немного в замешательстве.
00:09:08Вот этот план.
00:09:09Но в любом случае, да, подтверждено.
00:09:12Это работает в старых кодовых базах без лишнего мусора.
00:09:14Но мне хотелось проверить, можем ли мы решать сложные задачи.
00:09:17Вайбхав все еще был настроен скептически.
00:09:19Мы просидели около семи часов в субботу
00:09:21и отправили 35 000 строк кода в BAML.
00:09:24Один из PR был принят через неделю.
00:09:26Скажу честно, часть этого — генерация кода.
00:09:28Вы обновляете поведение,
00:09:29и все эталонные файлы обновляются автоматически.
00:09:31Но в тот день мы отгрузили действительно много кода.
00:09:33По его оценкам, мы сделали объем работы 1–2 недель за 7 часов.
00:09:36Так что, круто, мы можем решать сложные задачи.
00:09:40Но у этого есть пределы.
00:09:41Я сел со своим приятелем Блейком.
00:09:42Мы пытались удалить зависимости Hadoop из Parquet Java.
00:09:46Если вы знаете, что такое Parquet Java,
00:09:47мне жаль, что в вашей карьере
00:09:50произошло нечто, приведшее вас к этому.
00:09:53Все прошло не очень.
00:09:55Вот планы, вот исследования.
00:09:57В какой-то момент мы все выкинули
00:09:58и фактически вернулись к маркерной доске.
00:10:00Нам пришлось — как только мы поняли,
00:10:01где зарыты все грабли,
00:10:03вернуться к вопросу:
00:10:05«Ладно, как это вообще должно стыковаться?»
00:10:06И это подводит меня к очень интересному моменту,
00:10:09о котором Джейк расскажет позже.
00:10:11Не отдавайте процесс мышления на аутсорс.
00:10:13ИИ не может заменить мышление.
00:10:14Он может только усилить ваши мыслительные способности
00:10:17или их отсутствие.
00:10:19Меня спрашивают: «Декс,
00:10:21это же разработка на основе спецификаций (Spec-driven development), верно?»
00:10:23Нет, разработка на основе спецификаций изжила себя.
00:10:27Не сама идея, а само словосочетание.
00:10:30Оно стало размытым.
00:10:33Это Бриджетта из ThoughtWorks.
00:10:35Многие говорят «спецификация»,
00:10:37имея в виду просто более детальный промпт.
00:10:39Кто-нибудь помнит эту картинку?
00:10:41Кто-нибудь знает, откуда она?
00:10:43Ладно, это слишком тонко.
00:10:44Никогда не наступит «год агентов»
00:10:46из-за семантической диффузии.
00:10:47Мартин Фаулер сказал это еще в 2006 году.
00:10:49Мы придумываем хороший термин с четким определением,
00:10:52потом все воодушевляются,
00:10:53и каждый начинает вкладывать в него свой смысл,
00:10:56пока он не станет абсолютно бесполезным.
00:10:59У нас агент — это и человек, и микросервис,
00:11:02и чат-бот, и рабочий процесс.
00:11:05И спасибо, Саймон.
00:11:06Мы вернулись к началу.
00:11:07Агент — это просто инструменты, работающие в цикле.
00:11:09То же самое происходит с Spec-driven dev.
00:11:11Раньше у меня в начале доклада был слайд Шона,
00:11:15но из-за него многие люди
00:11:15фокусировались не на том.
00:11:17Его мысль о том, что «забудьте про код, теперь это как ассемблер»,
00:11:19и нужно сосредоточиться только на Markdown.
00:11:21Идея крутая, но люди говорят, что Spec-driven dev —
00:11:24это написание лучшего промпта или документа с требованиями (PRD).
00:11:26Иногда это использование проверяемых циклов обратной связи
00:11:28и обратного давления.
00:11:30Возможно, это отношение к коду как к ассемблеру,
00:11:32как учил нас Шон.
00:11:34Но для многих это просто куча Markdown-файлов,
00:11:36которые используются во время кодинга.
00:11:37Или мой любимый вариант, на который я наткнулся на прошлой неделе:
00:11:39«Спецификация — это документация для open-source библиотеки».
00:11:43Так что всё.
00:11:44Понятие Spec-driven dev перехайплено и бесполезно.
00:11:48Оно семантически размыто.
00:11:49Поэтому я хотел поговорить о четырех вещах,
00:11:52которые реально работают сегодня — тактических и практических шагах,
00:11:55которые мы проверили внутри компании и с нашими пользователями.
00:11:59Мы проводим исследование, выясняем, как работает система.
00:12:02Помните фильм «Помни» (Memento)?
00:12:03Это лучший фильм о контекстном инжиниринге,
00:12:05как говорит Питер.
00:12:07Этот парень просыпается, у него нет памяти,
00:12:09ему приходится читать собственные татуировки, чтобы понять, кто он
00:12:11и чем он занимается.
00:12:12Если вы не введете своих агентов в курс дела, они начнут галлюцинировать.
00:12:17И это ваша команда — схема очень упрощена
00:12:19для большинства из вас.
00:12:19У большинства организации гораздо крупнее.
00:12:21Но допустим, вы хотите сделать работу вот в этой части.
00:12:23Вы могли бы добавить инструкции по онбордингу
00:12:26в каждый репозиторий.
00:12:27Вы даете кучу контекста.
00:12:28Вот репо, вот как он работает.
00:12:29Это сжатая информация обо всем контексте кодовой базы,
00:12:32которую агент может изучить заранее,
00:12:34прежде чем приступить к работе.
00:12:36Это сложно, потому что иногда описание становится слишком длинным.
00:12:39По мере роста вашей кодовой базы,
00:12:41вам придется либо удлинять этот текст,
00:12:43либо упускать какую-то информацию.
00:12:45И вот, пока вы читаете всё это,
00:12:48вы изучаете контекст
00:12:49огромного монорепозитория на пять миллионов строк,
00:12:52и вы потратите всю «умную зону»
00:12:53только на то, чтобы понять, как это работает, и не сможете
00:12:55эффективно вызывать инструменты в «глупой зоне».
00:12:57Так что вы можете дробить это по уровням.
00:13:02Речь идет о прогрессивном раскрытии информации.
00:13:04Вы могли бы разделить это, верно?
00:13:05Можно просто положить файл в корень каждого репозитория,
00:13:08и затем на каждом уровне иметь дополнительный контекст,
00:13:11основанный на том, в каком месте вы работаете,
00:13:13только то, что вам нужно знать.
00:13:15Мы не описываем сами файлы,
00:13:17потому что они и есть первоисточник истины.
00:13:18Но по мере работы агента,
00:13:19вы подтягиваете корневой контекст,
00:13:21а затем — контекст подпапки.
00:13:22Не будем говорить о конкретных инструментах,
00:13:23для этого можно использовать CloudMD,
00:13:24можно использовать Hoax или что угодно еще.
00:13:26Но тогда у вас остается много места в «умной зоне»,
00:13:28потому что вы загружаете только то, что необходимо.
00:13:31Проблема в том, что эти данные устаревают.
00:13:33И каждый раз, когда вы выпускаете новую фичу,
00:13:35вам нужно инвалидировать кэш,
00:13:38и пересобирать большие части этой внутренней документации.
00:13:42Вы могли бы активно использовать ИИ
00:13:43и сделать обновление этой документации частью процесса.
00:13:46Позвольте задать вопрос.
00:13:48Если взять сам код, названия функций,
00:13:50комментарии и документацию,
00:13:51кто-нибудь угадает, что находится на оси Y этого графика?
00:13:57— Мусор. — Мусор.
00:13:58На самом деле, это количество лжи,
00:14:01которую можно найти в любой части вашей кодовой базы.
00:14:03Вы могли бы сделать обновление документации частью процесса,
00:14:06но, скорее всего, не стоит, потому что вы этого не сделаете.
00:14:08Мы предпочитаем сжатый контекст по требованию.
00:14:11Допустим, я создаю фичу, связанную с SCM-провайдерами,
00:14:14JIRA и Linear.
00:14:15Я бы просто задал направление.
00:14:17Я бы сказал: «Так, мы работаем
00:14:18вот в этой части кодовой базы»,
00:14:21и хороший исследовательский промпт или слэш-команда
00:14:24может использовать ваши навыки,
00:14:27запустить субагентов для анализа вертикальных срезов кодовой базы
00:14:30через кодовую базу, а затем составят исследовательский документ,
00:14:33который будет просто снимком актуального состояния,
00:14:35основанным на самом коде, тех его частей, которые важны.
00:14:39Мы сжимаем истину.
00:14:41Планирование — это рычаг.
00:14:43Планирование — это компрессия намерений.
00:14:45И в плане мы наметим конкретные шаги.
00:14:48Давайте возьмем наше исследование, PRD, баг-тикет
00:14:50или что бы то ни было.
00:14:52Мы создаем план и файл плана.
00:14:54То есть мы снова все уплотняем.
00:14:55И здесь я хочу сделать паузу и поговорить о ментальной синхронизации.
00:14:58Кто-нибудь знает, для чего нужно код-ревью?
00:15:00Для ментальной синхронизации, именно для нее.
00:15:05Конечно, это и проверка корректности, и прочее.
00:15:08Но самое важное — как нам удерживать
00:15:10всех членов команды в едином контексте
00:15:11относительно того, как и почему меняется кодовая база?
00:15:14Я могу просматривать по тысяче строк на Go каждую неделю.
00:15:17Простите, на самом деле не могу.
00:15:18Это тяжело, хоть и возможно.
00:15:19Но я не хочу этого делать.
00:15:20По мере роста команды весь код проходит через ревью.
00:15:23Мы не оставляем код непрочитанным.
00:15:24Но я, как технический лидер команды,
00:15:27могу читать планы и оставаться в курсе событий.
00:15:29И этого достаточно.
00:15:30Так я могу вовремя заметить проблемы
00:15:32и понимать, как развивается система.
00:15:35У Митчелла был отличный пост
00:15:36о том, как он прикрепляет свои треды из AMP
00:15:38к пул-реквестам, чтобы вы видели не просто
00:15:41стену зеленого текста в GitHub,
00:15:43а конкретные шаги, промпты,
00:15:44и результат сборки в конце, которая прошла успешно.
00:15:46Это ведет ревьюера по всему пути автора,
00:15:49чего обычный PR на GitHub дать не может.
00:15:51И когда вы начинаете выпускать
00:15:52в два-три раза больше кода,
00:15:54ваша прямая обязанность — найти способы
00:15:57синхронизировать команду и показать: «вот что я сделал»
00:16:00и «вот как мы это протестировали вручную».
00:16:01Ваша цель — рычаг, поэтому нужна высокая уверенность,
00:16:04что модель действительно сделает все правильно.
00:16:06Я не могу просто прочесть план и сразу понять,
00:16:08что именно произойдет и какие правки внесутся в код.
00:16:11Поэтому со временем мы пришли к тому, что наши планы
00:16:14содержат фрагменты кода, которые будут изменены.
00:16:17Итак, ваша цель — рычаг.
00:16:18Вам нужна компрессия намерений
00:16:19и надежное исполнение.
00:16:22У меня физическое образование.
00:16:23Мы любим проводить линии через центры пиков и кривых.
00:16:28Чем длиннее ваши планы, тем выше надежность,
00:16:30но ниже читаемость.
00:16:31Для вас, вашей команды и вашего кода
00:16:33существует золотая середина — постарайтесь ее найти.
00:16:35Потому что когда мы проверяем исследования и планы,
00:16:37если они хороши, мы достигаем ментальной синхронизации.
00:16:40Не перекладывайте мышление на других.
00:16:42Я уже говорил: это не магия.
00:16:44Идеального промпта не существует.
00:16:46Ничего не выйдет, если вы сами не будете читать план.
00:16:50Весь наш процесс построен на том, что вы, как создатель,
00:16:53находите в постоянном диалоге с агентом,
00:16:55изучая планы по мере их появления.
00:16:56И если вам нужно мнение коллеги,
00:16:58вы можете отправить ему план и спросить:
00:16:58«Слушай, план нормальный?»
00:17:00«Подход верный?»
00:17:00«Порядок действий правильный?»
00:17:03Джейк тоже написал отличный пост о том,
00:17:05что ценность цепочки «исследование-план-реализация»
00:17:07заключается в человеке, который контролирует корректность.
00:17:11Если вы и должны что-то вынести из этого доклада,
00:17:14так это то, что плохая строка кода — это просто плохая строка.
00:17:17Но плохой пункт в плане — это уже сотня плохих строк.
00:17:22А плохая строчка в исследовании — например, непонимание
00:17:25того, как работает система и где что находится —
00:17:27погубит всю вашу затею.
00:17:29Вы просто отправите модель в совершенно неверном направлении.
00:17:31Работая внутри компании и с нашими пользователями,
00:17:34мы постоянно стараемся направить усилия человека
00:17:36на самые важные этапы этого процесса.
00:17:39Не делегируйте мышление.
00:17:41Остерегайтесь инструментов, которые просто выплевывают
00:17:43кучу Markdown-файлов ради видимости работы.
00:17:45Не буду называть конкретные имена.
00:17:47Иногда такой подход избыточен.
00:17:49Я думаю об этом так:
00:17:51вам не всегда нужен полный цикл RPI.
00:17:54Иногда нужно больше действий, иногда меньше.
00:17:56Если вам нужно просто изменить цвет кнопки,
00:17:57просто скажите об этом агенту.
00:18:00Для простых задач и небольших фич хватит легкого плана.
00:18:04Для средних фич, затрагивающих несколько репозиториев,
00:18:07проведите исследование, а затем составьте план.
00:18:09Суть в том, что сложность задач, которые вы можете решить,
00:18:10растет вместе с тем, сколько усилий вы готовы вложить
00:18:13в контекстную инженерию и компрессию.
00:18:15Так что, если вы замахнулись на что-то серьезное,
00:18:18вам придется потрудиться над контекстом.
00:18:19Меня часто спрашивают: как понять,
00:18:21сколько контекстной инженерии нужно?
00:18:23Нужна практика.
00:18:24Вы будете ошибаться, и это нормально —
00:18:26ошибаться снова и снова.
00:18:27Иногда вы переусложните, иногда сделаете слишком поверхностно.
00:18:29Выберите один инструмент и набейте на нем руку.
00:18:32Я не советую пытаться объять необъятное,
00:18:35переключаясь между всеми возможными тулзами.
00:18:36Я не большой любитель аббревиатур.
00:18:40Мы говорили, что разработка через спецификации изжила себя.
00:18:42Не думаю, что «исследование-план-реализация» станет догмой.
00:18:44Важнее всего — компрессия, контекстная инженерия
00:18:47и умение оставаться в «умной зоне».
00:18:48Но люди уже начали называть это RPI,
00:18:50и я ничего не могу с этим поделать.
00:18:52Просто будьте осторожны: идеального промпта
00:18:55и серебряной пули не существует.
00:18:56Если вам нужно модное словечко,
00:18:58назовите это «инженерией оснастки» (harness engineering),
00:19:00что является частью контекстной инженерии.
00:19:01Это то, как вы встраиваетесь в точки интеграции
00:19:03в Codex, Cursor или где-то еще,
00:19:05как вы адаптируете их под свою кодовую базу.
00:19:07Что дальше?
00:19:11Думаю, тема с кодинг-агентами скоро
00:19:12станет чем-то обыденным.
00:19:13Люди научатся ими пользоваться и станут в этом профи.
00:19:15Самое сложное — это адаптировать команду
00:19:17и ваши рабочие процессы в SDLC к миру,
00:19:21где 99% кода пишется искусственным интеллектом.
00:19:24Если вы не разберетесь с этим, вы проиграли.
00:19:26Потому что сейчас намечается раскол:
00:19:27стафф-инженеры не спешат внедрять ИИ,
00:19:29потому что он не дает им большого прироста в скорости,
00:19:31а джуны и мидлы используют его вовсю,
00:19:33потому что он восполняет нехватку навыков.
00:19:35Но при этом он выдает немало «шлака»,
00:19:36и с каждой неделей сеньоры ненавидят это всё больше,
00:19:38потому что им приходится разгребать мусор,
00:19:40написанный в Cursor на прошлой неделе.
00:19:42Это не вина ИИ
00:19:44и не вина мидл-разработчика.
00:19:46Культурные изменения — это всегда тяжело,
00:19:48и они должны идти сверху, чтобы сработать.
00:19:50Так что, если вы технический лидер,
00:19:52выберите один инструмент и начните практиковаться.
00:19:54Если хотите помочь нам — мы расширяем команду.
00:19:56Мы строим агентную IDE, чтобы помочь командам
00:19:59максимально быстро перейти к 99% кода, генерируемого ИИ.
00:20:03Будем рады пообщаться, если хотите работать с нами.
00:20:06Заходите на сайт, пишите на почту
00:20:08или просто подходите ко мне в кулуарах.
00:20:09Спасибо большое за ваше внимание и энергию.
00:20:11(аплодисменты)
00:20:13(ритмичная электронная музыка)