Новый рабочий процесс для разработчиков

С момента выхода GitHub Copilot в виде превью летом 2021 года, мы наблюдаем настоящий взрыв продуктов в категории ассистентов для программирования. Изначально такие инструменты использовались как «инструменты автодополнения кода на стероидах», но некоторые решения (например, Cursor и Windsurf) быстро эволюционировали в сторону агентных взаимодействий. Здесь помощник, реагируя на запросы, самостоятельно выполняет действия вроде изменения файлов с кодом или запуска терминальных команд.

Недавно GitHub Copilot добавил собственный «режим агента» — новую функцию встроенного чата, которая позволяет поручать агенту выполнение различных задач. Этот режим — ещё один пример стремительного развития агентных технологий. При этом не стоит путать «режим агента» с «агентом программирования» GitHub Copilot, который запускается из интерфейса GitHub (через github.com или GitHub CLI) и может автономно работать с GitHub Issues.

В этой статье мы разберём, как использовать агентов в процессе разработки ПО и какие изменения это влечёт в повседневной работе разработчика. Чтобы показать, как может выглядеть такой новый рабочий процесс на практике, мы создадим простое Angular-приложение, которое ищет статьи в Википедии и выводит результаты в виде списка, используя «режим агента» GitHub Copilot (см. как получить доступ к агенту в VSCode). Назовём его «Search wiki app».

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

Создание приложения в один шаг

Приложение «Search wiki app» довольно простое. Его назначение и функциональность можно описать в коротком промпте, как показано ниже. Обратите внимание, что технические детали, связанные с Angular, необязательны для демонстрации влияния агента на процесс разработки. Тем не менее, они напоминают нам о том, что даже при работе с агентом разработчику необходимо знать и указывать важные технические детали при формулировании промпта.

Наш промпт для GitHub Copilot, чтобы создать всё приложение целиком:

Создай Angular-приложение, которое отправляет запрос к Wikipedia API, чтобы получить статьи, соответствующие введённому поисковому запросу, и отображает результаты в виде списка.

В приложении должна быть поисковая строка, в который пользователь вводит запрос, и по нажатию кнопки поиска должен происходить вызов Wikipedia API с последующим отображением результатов в виде списка. Каждый элемент списка должен содержать заголовок статьи и краткое описание.

Приложение также должно корректно обрабатывать ошибки и показывать соответствующее сообщение, если результаты не найдены или возникла ошибка при вызове API.

Используй Angular Material для UI-компонентов и убедись, что приложение адаптивное и хорошо работает как на десктопе, так и на мобильных устройствах. Архитектура приложения должна быть модульной: вынеси поисковый бар и список результатов в отдельные компоненты. Придерживайся лучших практик разработки на Angular, включая использование сервисов для вызовов API и использование RxJS для работы с асинхронными данными.

Выбор LLM имеет значение

Режим агента GitHub Copilot (Agent Mode) позволяет выбрать LLM модель, которую будет использовать агент. Наши эксперименты показали: выбор модели критически важен. Это стоит подчеркнуть, чтобы избежать ошибочного восприятия LLM как неких стандартизированных инструментов, различия между которыми интересны только гикам. Такое впечатление может лишь усилиться из-за того, что в интерфейсе GitHub Copilot выбор модели осуществляется через обычный выпадающий список. Однако LLM обладают различными и постоянно развивающимися возможностями, которые напрямую влияют как на стоимость, так и на итоговое качество.

Чтобы это доказать, мы протестировали один и тот же промпт на двух разных моделях: Claude Sonnet 4 от Anthropic и o4-mini (preview) от OpenAI. Обе модели по праву считаются мощными, но они существенно отличаются по природе и возможностям. Claude Sonnet 4 — это гигантская модель с более чем 150 миллиардами параметров, специально дообученная для задач программирования. А o4-mini — гораздо меньшая модель с 8 миллиардами параметров, нацеленная на более универсальные задачи. Поэтому неудивительно, что результаты оказались принципиально разными — это отражение реального положения дел в мире современных LLM, и с этим стоит считаться.

Работа с o4-mini (preview)

С использованием o4-mini агент GitHub Copilot не смог создать работоспособный код. Уже первая версия содержала ошибки, из-за которых приложение не компилировалось. Мы начали диалог с агентом, попросив его исправить ошибки. После нескольких итераций пришлось остановиться: ошибки продолжали появляться, а самое главное — нам было сложно понять логику решения и разобраться в коде, несмотря на хорошее знание Angular. Для заинтересованных: на github можно ознакомиться с кодом, полученным в ходе этого эксперимента.

Работа с Claude Sonnet 4

С Claude Sonnet 4 ситуация оказалась совершенно иной. Уже первая попытка дала рабочий и корректно собранный код, без необходимости дополнительных итераций или ручных правок. Архитектура решения выглядела аккуратно: хорошая модульность, чёткая структура проекта по папкам.

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

Ощущение потери контроля

Несмотря на то, что агент с моделью Claude Sonnet 4 создал рабочее решение и даже оформил документацию, у меня всё равно оставалось чувство, что я не контролирую процесс. Например, чтобы убедиться в точности созданных диаграмм, мне пришлось внимательно пройтись по коду и сопоставить его с диаграммами и документацией. Иными словами, чтобы по-настоящему понять, что сделал агент, приходится фактически выполнять реверс-инжиниринг и валидировать каждую часть результата.

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

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

Пошаговый подход

Возьмите на себя роль архитектора

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

Определите лучшие практики, которым должен следовать агент

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

GitHub Copilot предлагает удобный способ задать такие практики через instruction files — специальные инструкции, которые автоматически добавляются ко всем сообщениям, отправляемым агенту. Можно даже использовать генеративный ИИ (например, обычный чатбот вроде ChatGPT), чтобы составить качественный список таких лучших практик.

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

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

Делитесь и применяйте лучшие практики на уровне всей команды

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

Сборка приложения

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

• Каждый шаг из плана реализации превращается в отдельный промпт для агента.

• После выполнения промпта мы проверяем результат работы агента. Если шаги небольшие и простые, сгенерированный код будет легко понять и проверить.

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

• Когда нас устраивает результат, мы фиксируем изменения (делаем коммит), чтобы зафиксировать изменения перед переходом к следующему этапу.

Мы собираем приложение шаг за шагом, всё время оставаясь в курсе происходящего и сохраняя контроль.

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

• Агент сгенерировал полноценный набор тестов, покрывающих большое количество граничных случаев.

• Во все HTML-шаблоны была внедрена поддержка доступности (a11y) — обычно на это уходит немало времени.

• Агент добавил понятные комментарии к критически важным участкам кода в формате JSDoc.

В итоге мы собрали рабочее приложение всего за четыре шага, используя четыре промпта — и каждый из них дал ожидаемый результат с первой попытки, при использовании модели Claude Sonnet 4 в роли LLM-движка.

Для заинтересованных: на сайте infoq можно ознакомиться с подробным описанием каждого шага, использованных промптов и сгенерированного кода.

Выбор подходящей модели

Как мы уже отмечали, выбор модели действительно имеет значение. Мы протестировали тот же пошаговый подход с другими LLM, используя ту же последовательность промптов. Например, с GPT-4.1 агент также сгенерировал рабочее приложение, почти без необходимости правок (единственные ошибки касались путей импорта), но качество оказалось ниже. В частности, приложение не соответствовало Material Design (что было прямо указано в инструкциях) и не обрабатывало событие нажатия клавиши Enter. Также поддержка доступности не была реализована с первой попытки.

Скорость — важна, но решает не всё 

С этим пошаговым подходом мы смогли создать полноценное работающее приложение с полным набором тестов и другими важными качественными аспектами, с помощью всего четырех промптов. На всё ушло максимум пару часов, а возможно, и меньше. Это впечатляющая скорость, особенно в сравнении с традиционным методом, при котором разработчику перед написанием кода пришлось бы вручную изучать документацию Wikipedia API и актуальные рекомендации по Angular.

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

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

Выводы

Агенты могут стать мощным инструментом в руках разработчиков — особенно если они работают на базе эффективных LLM. Они способны ускорять разработку, выполнять задачи, которые мы зачастую откладываем (например, написание тестов), и при этом придерживаться заданных нами инструкций и лучших практик. Однако вся эта мощь сопровождается риском потери контроля. Можно получить рабочее решение, на понимание которого потребуется время — и тогда возникает соблазн просто «довериться» агенту, не убедившись в корректности результата. Генеративный ИИ может галлюцинировать, и это серьёзная угроза. Даже если представить, что ИИ никогда не ошибается, полагаться на решение, в логике которого вы не разобрались, — это риск.

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

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

Ключевой фактор — опыт

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

Но как нарабатывать этот опыт в мире, где основную часть кода пишут агенты? Это уже другой вопрос — вопрос, который относится не только к программированию, но ко многим интеллектуальным видам деятельности в эпоху генеративного ИИ.

И, пожалуй, ответ на него нам ещё только предстоит найти — он точно выходит за рамки этой короткой статьи.

Технические детали

Использование агента GitHub Copilot в VSCode

В этом разделе рассмотрим, как получить доступ к агенту внутри VSCode.

Агент GitHub Copilot встроен в чат Copilot. Внутри чата можно выбрать как режим агента, так и LLM-модель, которую он будет использовать.

С помощью встроенного чата мы можем поручать агенту выполнение задач. Именно через этот чат мы и будем собирать наше приложение «Search wiki app», как описано ранее.

Проектирование решения и план реализации

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

В плане реализации мы движемся снизу вверх: начинаем с сервисов, которые взаимодействуют с внешними системами, а затем на их основе строим представления (views). Для упрощения приложение использует управление состоянием.

Итак, наш план по созданию Search wiki app:

1. Создать WikiService и добавить в него метод, выполняющий запрос к публичному Wikipedia API для поиска статей по ключевому слову.

2. Создать компонент WikiCard, отображающий отдельную статью Википедии в виде карточки. Он будет использоваться в компоненте WikiList для формирования сетки результатов.

3. Создать компонент WikiListComponent, который управляет всей логикой отображения списка. Поисковое поле и кнопка поиска будут частью этого компонента. По нажатию кнопки должен вызываться WikiService, а полученные результаты отображаться в виде сетки карточек WikiCard.

4. Настроить WikiList как стартовую страницу, загружаемую при запуске приложения.

Этапы реализации и соответствующие промпты

Ниже приведены шаги реализации с указанием промптов, использованных на каждом этапе, а также ссылками на состояние кода после выполнения шагов. 

1. Создание WikiService

Создай сервис WikiService и добавь в него метод, который будет выполнять запрос к API Википедии для получения статей по заданному поисковому запросу. Используй актуальные версии API Википедии.

Также добавь тест для этого API. Не используй заглушки (моки) — тест должен обращаться к реальному API.

Состояние кода после выполнения Шага 1

2. Создание компонента WikiCard

Создай компонент WikiCard — он отвечает за отображение одной статьи Википедии в виде карточки в списке. Статья Википедии представлена объектом, описанным интерфейсом WikipediaSearchResult. Компонент WikiCard будет использоваться в WikiList для формирования сетки найденных статей.

Состояние кода после выполнения Шага 2

3. Создание компонента WikiListComponent

Создай компонент WikiListComponent, который будет отображать список статей Википедии в виде карточек. Он должен использовать компонент WikiCard для отображения каждой статьи. Компонент должен содержать поле ввода для ввода поискового запроса пользователем.

Также должна быть кнопка, по нажатию на которую выполняется запрос к API Википедии. Событие click у кнопки должно инициировать вызов метода WikiService, который возвращает список статей, отображаемый в виде сетки карточек WikiCard.

Состояние кода после выполнения Шага 3

4. Настройка WikiList как стартовой страницы

Сделай компонент WikiList стартовой страницей приложения, загружаемой при его запуске.

Состояние кода после выполнения Шага 4

Инструкции, лучшие практики и контекст

Ниже приведён набор инструкций, которые мы определили и которые агент использовал на протяжении всей работы:

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

- Используй возможности и синтаксис Angular v19.
- Предпочитай standalone-компоненты и функциональные провайдеры, если это возможно.
- Включи строгий режим TypeScript и строгие шаблоны Angular.
- Организуй код по функциональным зонам: src/app/components, src/app/pages, src/app/services.
- Используй Angular CLI для автоматического создания компонентов, сервисов и модулей.
- Следуй лучшим практикам RxJS: избегай ручного управления подписками, используй async pipe в шаблонах.
- Применяй Angular Forms (реактивные или шаблонные формы) для ввода данных.
- Используй Angular Material для UI-компонентов, если требуется дизайн-система.- Пиши юнит-тесты для всех компонентов, сервисов и пайпов, используя Jasmine и TestBed.
- Используй понятные и описательные имена для файлов, классов и селекторов.
- Следуй рекомендациям по стилю Angular и TypeScript.
- Документируй публичные API и сложную логику с помощью JSDoc.
- Избегай логики в шаблонах — они должны быть декларативными и простыми.
- Не используй inline-шаблоны или стили — выноси их в отдельные файлы.
- Используй dependency injection для сервисов и конфигурации.
- Отдавай предпочтение Observables вместо Promises для асинхронных операций.
- Держи компоненты небольшими и сосредоточенными, выноси бизнес-логику в сервисы.
- Храни конфигурации в environment-файлах.
- Используй встроенный роутинг и guard'ы Angular для навигации и контроля доступа.
- Обеспечивай доступность (a11y) для всех UI-компонентов.
- Используй ESLint и Prettier для поддержания качества и форматирования кода.
- Для запуска CLI-команд используй npx ng .., чтобы гарантировать корректную версию.
- В конце каждого файла добавляй строку "code generated by AI".
- Для запуска тестов всегда используй команду:

npx ng test --browsers=ChromeHeadless --watch=false --code-coverage=false.

Согласно лучшим практикам формирования промптов (в частности, тем, что опубликованы Anthropic), инструкции должны начинаться с определения роли, так как они выполняют функцию системного промпта, аналогичного тем, что применяются в API LLM.

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

• Есть инструкция: «создавать юнит-тесты для всех компонентов, сервисов и пайпов» — агент действительно пишет тесты.

• Инструкция по обеспечению доступности (a11y) во всех UI-компонентах — выполняется, по крайней мере, при использовании Claude Sonnet 4.

• Указание документировать публичные API и сложную логику в формате JSDoc — также выполняется.

• Инструкции по bash-командам (например, запуск тестов с нужными параметрами) — агент им также следует.

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

Небольшое замечание о метапромптах

Инструкции задают направление, поэтому они зависят от типа проекта.

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

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

• 29 июля в 20:00
  Страх и ненависть при работе с зависимостями (SCA)
  Как не утонуть в бесконтрольном потоке библиотек, не потерять безопасность и не проклинать SCA-инструменты.

• 30 июля в 19:00
  Стиль разработки 2020-х и среда окружения современного бэкенда
  Почему приложение — это уже не «монолит со всем», какие задачи ушли в инфраструктуру, и как собрать актуальную среду разработки, не застряв в подходах прошлого десятилетия.

Если вы работаете с агентами и автоматизируете разработку, но не уверены, что контролируете инфраструктуру, сборки и безопасность — это повод углубиться в DevSecOps. Пройдите вступительное тестирование, чтобы понять, насколько вы готовы к системному обучению и подойдёт ли курс «Внедрение и работа в DevSecOps» именно вам.