[0:00]Если ты кодишь с AI агентом и в каждом промте пишешь: без ошибок, будь внимателен, ничего не сломай. У меня для тебя новости - это не работает. Это как писать тех заданий: сделай хорошо и чтобы работало быстро. Если тебе приходится это писать, проблема не в модели, проблема в процессе. А если ты уже материшься на агентов в терминале, знай, мы все через это прошли, но это тоже сигнал. И вот что интересно, об этом почти никто не говорит вслух. Все используют курсор, Copilot, Clode Code, но мало кто делится тем, как именно, какой у них реальный процесс. Где факапят, что работает? В командах каждый сам себе изобретает велосипед и набивает одни и те же шишки. Кто-то молчит, потому что кажется, все вокруг уже разобрались, а ты один тупишь. А кто-то, потому что до сих пор стыдно признаться, что пишешь код с AI. Как будто сам не можешь, как будто не настоящий разработчик. Но индустрия уже сдвинулась, и это видно по данным. Сначала давайте мы с вами посмотрим на цифры, что реально происходит с качеством AI-кода, и почему компании, которые делают лучшие модели в мире, нанимают инженеров сотнями. Потом сам процесс, как выстроить работу с агентом так, чтобы не терять контроль, и в конце всё это посмотрим на живом примере. Посмотрим, как же это всё работает. Начнём с цифр. Ноябрь двадцать пятого. Carnegie Mellon публикует исследование, где 800 репозиториев на GitHub перешли на Cursor. Данные до августа двадцать пятого, включая период, когда уже работали агентные фичи и самые сильные модели. Какой же результат? Первый месяц строк кода стало в пять раз больше, коммиты выросли на 55%. Но к третьему месяцу оба показателя вернулись к норме. Буст скорости был временным. А вот что не вернулось к норме - предупреждения статического анализатора кода выросли примерно на 30%, а сложность кода - на 40%. И оба показателя остались высокими. И что самое неприятное, эта накопленная сложность потом замедляет разработку. И мы получаем с вами замкнутый круг. Быстро нагенерили, код усложнился, писать дальше стало медленнее, чем до того, как мы и писали с AI. И AI стал писать ещё медленнее и поставлять ещё больше ошибок. Декабрь двадцать пятого года. CodeRabbit выпускает отчёт: AI или человек? 470 реальных пул-реквестов на GitHub. AI-код содержит в среднем 10 проблем на пиар против 6 у человека. Это в 1.7 раз больше. Причём критических ошибок в AI-коде в 1.4 раза больше, а серьёзных - в 1.7 раза. А что же с безопасностью? XSS-уязвимости появляются в 2.74 раза чаще, а проблемы с производительностью, вдумайтесь, в 8 раз чаще в AI-сгенерированном коде. Январь двадцать шестого. MIT публикует большой обзор текущего состояния AI-кодинга. Они цитируют разработчика, который попросил AI помочь настроить Azure Functions и думал, что это займёт 2 часа работы. Через 9 часов он сдался, потому что AI постоянно уводил его в тупики, а он недостаточно разбирался в теме, чтобы распознать бред. Вам такое знакомо? Я уверен, каждый из вас хотя бы раз попадал в эту кроличью нору. А вот вишенка на торте. Февраль двадцать шестого года. Moltbook, соцсеть исключительно для AI агентов, завирусилась за неделю. AI-боты постят, общаются, создают сообщества. Красота, будущее, агентский интернет. А потом исследователи заглянули под капот и обнаружили, что вся платформа - это Vibe Coding в чистом виде. Создатель сам написал: "Я не писал ни одной строчки кода". В итоге, открытая база данных, 1.5 млн API ключей, 35.000 email-адресов, приватные сообщения между агентами. Всё лежало в открытом доступе. Любой мог не только читать, но и записывать в базу. Знаешь, что сделал создатель, когда ему сообщили о дыре? Сказал, что попросит AI это починить. Я не шучу, это не анекдот. Это идеальная иллюстрация того, что происходит, когда AI использует без инженерного процесса. Неважно, насколько мощная модель. Без контроля, без ревью, без архитектуры, получается красивый, быстрый, дырявый мусор. Ну, давайте посмотрим, что происходит на рынке. Идёт настоящая война за инженеров. Google в двадцать пятом настолько агрессивно переманивал людей, что 20% нанятых AI инженеров - это бывшие сотрудники, которых переманили обратно. Anthropic переманивает инженеров у OpenAI и DeepMind с соотношением 8 к 1 и 11 к 1. Сеньоры ML инженеры в топовых лабораториях получают от 470 до 630.000 долларов. А отдельные позиции - выше 900.000. При этом сами компании, которые делают эти модели, Anthropic, OpenAI, Google, нанимают сотнями. У Anthropic прямо сейчас 400 открытых вакансий на 3.000 сотрудников, а OpenAI выросли с 770 человек в конце 23-го до 7.200 в феврале 26-го. Вдумайтесь, компании, которые делают самые мощные модели в мире, тратят миллиарды на живых инженеров. Почему? Потому что они лучше кого-либо знают - модель без инженерного контроля генерит посредственный, раздутый, дырявый код. И мы это видели на хайповом Moltbook. А вот что интересно, даже внутри Anthropic ситуация показательная. Boris Cherny, руководитель Claude Code, заявил, что уже больше 2 месяцев не пишет код руками, 100% генерит AI. Но обратите внимание, он не сказал, что убрал инженеров. Он сказал, что теперь они нанимают в основном универсалов, а не узких специалистов, потому что роль инженера сместилась. Не писать код, а управлять тем, как AI его пишет. Контролировать контекстную архитектуру, качество. А это равно то, чего не хватает подходу "закинул промт, посмотрел, что вышло, подправил руками, повторил". Потому что это не процесс, это лотерея. Ты не управляешь результатом, ты надеешься на него. И именно поэтому код деградирует, сложность растёт, и ты постепенно теряешь контроль над собственным проектом. Сегодня я покажу, как же этого можно избежать. Мы посмотрим на примере Code Code. Но подход не привязан к инструменту, ни к модели, Cursor, Copilot, Venture, любой агент, неважно. Важно понять принцип, как не терять контроль, как выстраивать контекст так, чтобы модель работала в рамках твоей архитектуры, как получать на выходе код, который ты понимаешь, можешь поддерживать и за который не стыдно. И давайте сразу договоримся - то, что я покажу, это не догма, и это не финальная система. За последний год мой процесс и процесс моей команды трансформировался многократно. И не потому что что-то ломалось, а потому что появлялись новые инсайты. Ты работаешь с агентом каждый день, пробуешь разные подходы. И вдруг понимаешь, что задачи можно формулировать совсем иначе. Кто-то из команды находит приём, который кардинально меняет качество результата. Читаешь исследования, читаешь статьи, общаешься с другими инженерами и видишь возможность, которую раньше не замечал. Также появляются огромное количество инструментов, и ты начинаешь делать то, что вчера даже не рассматривал. Поэтому это живое эволюционирующее процесс. И именно в этом суть инженерного подхода. Ты не заучиваешь набор промтов, ты выстраиваешь мышление, как формировать контекст, как декомпозировать, как контролировать качество, как интегрировать новые возможности по мере их появления. И вот это мышление переносится на что угодно: на любую модель, на любой инструмент и на любую задачу. Так что сегодня это актуальный снимок. Всё, к чему пришла моя разработка за год непрерывных экспериментов, проб, ошибок, инсайтов, моих, моей команды и индустрии. Самые рабочие практики, которые прямо сейчас дают результат. Поехали. Ну ладно, цифры мы посмотрели, немного пообсуждали. Картина понятная. Без процесса AI генерит быстро, но плохо. Вопрос: а как же выглядит этот процесс? Что значит контекстная инженерия на практике? Давайте освежим в памяти то, что мы обсуждали в одном из прошлых видео. Что такое работа с LLM? У нас есть с вами наша модель, мы делаем в неё запрос, и она нам отдаёт ответ. Мы с вами очень сильно заинтересованы в том, чтобы качество ответа было максимально высоким. Как же нам с вами этого добиться? Мы с вами можем управлять только теми данными, которые мы отправляем в нашу модель. И здесь как раз-таки вступает в силу наша контекстная инженерия и наш процесс. Давайте ещё раз проговорим про качество. Это упрощённая формула, которая даёт понять, как же нам работать с входными параметрами. Итак, давайте упростим до такого, что на входе мы с вами должны отдавать максимально корректные данные для нашего запроса, так, чтобы они имели максимальную полноту, и там не было никаких пропусков. Но при этом мы все знаем, что контекстное окно ограничено своим размером, и для того, чтобы работало всё хорошо, нам надо уменьшать размер нашего контекстного окна, и также уменьшать количество шума, который мы поставляем в наше контекстное окно. И тогда мы получим с вами максимальное качество. Так вот, работая с большими кодовыми базами, мы с вами сталкиваемся с проблемой, что кодовая база гигантская, но размер нам нужен минимальный для того, чтобы делать запрос. У нас не должно быть шума, должна быть корректность и полнота. Как же нам это сделать? И в этом нам с вами поможет декомпозиция нашего процесса на шаги. И какой же шаг мы сделаем первым? И это будет шаг Research. Что же происходит в фазе Research? Мы пытаемся в ней сузить нашу кодовую базу. То есть мы даём агенту возможность пройтись по всей нашей кодовой базе, выбрать те файлы, которых надо будет произвести какую-то работу. И при этом создать итоговый документ, в котором мы поместим информацию о том, что, где, как хранится. Для того, чтобы на следующих фазах нам не пришлось перелопачивать весь проект, увеличивать размер нашего контекстного окна и добавлять туда ненужный шум. И весь этот Research происходит с учётом того, что мы с вами делаем, какую мы решаем задачу. Мы фиксим баг или пишем новую фичу. Мы пытаемся найти все релевантные функции, файлы, всё, что есть, относящееся к этой задаче. То есть он создаёт сжатую информацию о том, что, где и как находится. После Research нам надо перейти в фазу планирования. И вы наверняка уже использовали фазы планирования. Вы строите план, потом читаете огромный документ о том, что и как надо реализовать, и в нём очень легко потеряться, потому что там много строчек, и его ревью занимает очень много времени. Мы сейчас пришли к тому, что после Research у нас идёт фаза дизайна. И что же мы делаем на фазе дизайна? Мы с вами создаём архитектурное решение, мы строим диаграммы. Сейчас мы используем C4, плюс Data Flow Diagram, плюс Sequence Diagram, для того, чтобы мы могли визуально посмотреть, как архитектурно выглядит решение. При этом мы его очень серьёзно ревьюим глазами, мы обсуждаем его с коллегами. Что за решение, как это выглядит? Мы получаем полный набор архитектурных диаграмм. При этом, если что-то здесь не так, то часто бывает проще исправить весь дизайн руками. И здесь кроется очень важный момент. Если у вас нету серьёзных архитектурных навыков, то будет тяжело понять, а правильно это решение или нет. Поэтому сейчас самое лучшее время для того, чтобы развиваться в инженерии. И вот после того, как мы с вами полностью проверили дизайн, мы можем приступить к фазе планирования. И давайте на секунду вернёмся к нашей формуле. Смотрите, на первой фазе мы передаём информацию о том, какую мы хотим решить задачу и пытаемся сузить весь наш проект до определённого набора информации. Это могут быть файлы, функции, ещё что-то. Дальше мы выстраиваем уже дизайн нашей фичи, которую мы хотим. И этот дизайн пытается максимизировать корректность того решения, которое мы хотим сделать, и полноту того, что нам надо сделать. При этом мы уменьшаем размер и уменьшаем шум, потому что мы оставляем только то, что действительно надо для реализации нашей фичи. Так вот, фаза планирования, мы в неё передаём уже всю информацию с точки зрения дизайна, фичи, которые нам надо было сделать, и Research-документы. И с точки зрения плана как раз-таки уже создаются файлы для реализации нашей фичи или багфиксинга. Мы чуть позже поговорим, чем они отличаются. Но я рекомендую вам делать это не одним гигантским файлом, как это часто делают агенты, а разбивать его по фазам и сделать так, чтобы каждая фаза была полностью завершённой. То есть мы можем её поревьюить, сделать коммит, сделать тесты, запустить на ней CI, и поэтому здесь создаётся множество файлов с разными фазами.

[12:00]Дальше мы запускаем ревью нашего плана, и это будет наш второй гейт контроля качества. И только после того, как мы заапрувим план, мы можем переходить к четвёртой фазе, и это будет имплементация. И здесь, в момент имплементации, каждая фаза проходит множество фаз проверки. Это ревью, запуск тестов, security, SAST, DAST, всё, что мы можем проверить с точки зрения качества. И если с точки зрения качества имплементация первой фазы нас не устраивает, то мы не передвигаемся ко второй. И в зависимости от размера фичи, на каждую фазу мы можем создавать коммиты и проверять пиары. Если же представим, что у нас вся фича целиком заезжает, то дальше у нас создаётся уже пиар или MR, неважно. Здесь мы проводим финальное ревью перед тем, как отправлять наш код уже в наш environment. И с точки зрения пиара и деплоймента нам с вами очень хорошо настроить жёстко CI для того, чтобы в нём мы также проверяли все гейты качества. Здесь мы должны с вами проверить качество кода, безопасность, верность контрактов, написать смог-тест, сделать интеграционные тесты. И только после этого мы сможем удостовериться, что то, что мы сделали, соответствует стандартам качества нашей компании. И обратите внимание, у нас здесь множество этапов. Но только на одном этапе AI пишет код. А всё остальное - это подготовка контекста. Research создаёт контекст для дизайна, дизайн создаёт контекст для плана, план создаёт контекст для реализации. И результаты каждого этапа - это входные данные для следующего. Именно поэтому на выходе у нас получается код, а не каша. И мы говорим о том, что качество у нас будет довольно-таки высокое. Это и будет контекстная инженерия. И здесь мы с вами будем работать над каждым этапом, увеличивая корректность, увеличивая полноту, уменьшая размер и уменьшая шум. Тем самым, мы убираем эти мысли: "Наверное, модель поймёт, что я имею в виду и сделает хорошо". Ведь Клод выпустил ещё новую модель, или OpenAI выпустил новую модель, она вообще классно программирует, мне стоит написать ей "No mistakes", и у меня всё будет без ошибок. Здесь у нас полностью контролируемый процесс. Мы знаем всё, что происходит на каждой фазе. На основе архитектуры мы сможем потом сделать доскональную проверку нашей имплементации. Соответствует она этому или нет. Мы сможем написать тестовые документы, мы сможем передать их команде QA, мы сможем их поревьюить вместе с нашей командой и принять решение. Действительно это то, что мы хотим, чтобы задеплоилось к нам в продакшн или нет? Тем самым, мы с вами минимизируем вероятность ошибки модели, потому что к моменту, когда она пишет код, все решения уже приняты. Архитектура полностью зафиксирована, план разбит по фазам, и каждый шаг однозначен. Он имеет критерии качества, и не пройдя эти критерии, мы не переходим дальше к имплементации. И следующий важный момент - этот процесс должен быть строго специализирован. То есть каждая фаза, она имеет свои промты. Но почему не один универсальный промт на всё? Потому что фича и баг - это совершенно разные задачи. У фичи нужна архитектура: C4-модели, API-контракты, либо какие-то другие подходы, которые вы используете для ведения архитектурных задач. А у бага - это как его воспроизвести, какие у него причины, какое минимальное исправление. И это разный процесс, разные шаги и разный контекст. То же самое с бэкендом и фронтендом. Бэкенды у нас могут быть написаны на разных стеках, в зависимости от стека и подхода. Это может быть разная архитектура, разный подход к проектированию наших доменов. С фронтендом то же самое - совершенно другие промты, другие подходы к Research, к дизайну. Поэтому если написать один универсальный промт, то это будет звучать как "Сделай фичу". Он будет угадывать, какая вам нужна архитектура, с чем вы работаете, и как мы помним формулу, которую мы недавно рассматривали, если он будет что-то угадывать, значит, у нас не будет полноты, у нас не будет корректности контекста. Тем самым мы получим худшее качество. А если же ты даёшь ему промт, заточенный под конкретный тип задачи, в конкретном стеке, он работает именно в этих рамках. Это как хирургические инструменты: скальпель, зажим, пинцет, каждый для своего. Можно, конечно, всё сделать одним ножом, но результат будет соответствующим.