Теория: Введение

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

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

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

Самые продвинутые уже соединили таск-менеджер, ci и исходный код, настроили openclaw и попивают сок сидя у себя в квартале.

Эволюция подходов от чата к агентам

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

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

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

Чего стоит одна скорость отладки, которая может сокращаться с нескольких дней упорного исследования до минут. Агент не ленится и быстро запускает множество разнообразных проверок, при необходимости генерируя тестовые скрипты, для того, чтобы убедиться в работоспособности чего-либо или найти точки, в которых ломается. Он сопоставляет код проекта, исходники проекта, состояние системы и базы данных.

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

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

Чат             Автокомплит       Агент             Асинхронный       Проект под
  (копипаста)     и NES             (в проекте)       агент             агента
                                                                        
  Вопрос →        Подсказки         Задача →          Фоновая           AGENTS.md,
  Ответ →         прямо             Исследование →    работа пока       скрипты,
  Копировать      в коде            Правки →          вы заняты         тесты,
  в проект                          Проверка          другим            документация
                                                                        
  ──────────────────────────────────────────────────────────────────────────────▶
                              эволюция подходов

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

Вот что написал в твиттере Matteo Collina, создатель Fastify и core разработчик Node.js по поводу добавления новой фичи в ноду:

@nodejs has always been about I/O. Streams, buffers, sockets, files. But there's a gap that has bugged me for years: you can't virtualize the filesystem. That changes now. We're announcing node

, a Virtual File System landing in Node.js core (PR #61478, ~14,000 lines across 66 files)

Let me be honest about how this happened. A 16,000-line PR would normally take months. This one happened over Christmas 2025 because I built it with Claude Code. I pointed the AI at the tedious parts: every fs method variant, test coverage, and docs. I focused on architecture, API design, and line-by-line review.

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

Вайбкодинг VS разработка с помощью агентов

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

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

Вайбкодинг                          Разработка с агентами
                                       
  "Сделай мне фичу"                   "Изучи модуль, предложи план,
        │                               реализуй, прогони тесты"
        ▼                                      │
  Принять как есть                             ▼
        │                               Ревью каждого шага
        ▼                                      │
  Сломалось? ──▶ Скормить                      ▼
                 ошибку обратно          Контроль качества
                                               │
  ✓ Прототипы, хакатоны,                       ▼
    одноразовые скрипты               ✓ Продакшен, командная
                                        работа, долгоживущий код

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

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

Но это не вся правда. Вайбкодинг применяется в тех случаях, когда проект имеет четко выделенные части, содержимое которых нам не принципиально, потому что это не ядро системы. Одним из таких примеров является markdown-редактор в админке Хекслета. Компонент реакта, который его реализует, состоит из примерно 500 строк полностью сгенерированных агентом. Это компонент никак не влияет на технический долг проекта и полностью изолирован внутри. Единственная коммуникация с внешним миром это колбек, который возвращает значение. Любое изменение такого компонента это запрос агенту, который по своему усмотрению может его целиком переписать. Что кстати регулярно происходит с обновлением моделей и агентов, со временем они умнеют и исправляют свои же ошибки допущенные в прошлых версиях.

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

Что нас ждет в курсе

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

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

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

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

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

Поехали!