Даже когда ИИ-агент создает каркас фронтенда, API и инфраструктурного кода, вам нужен предсказуемый результат. Команда AWS PACE (Prototyping and AI Customer Engineering) столкнулась с этим при работе с клиентами и упаковала свою настройку в виде Nx-плагина.
Давайте разберем, как это работает, почему лежащий в основе Nx Devkit становится еще важнее теперь, когда агенты могут писать такую автоматизацию, и с чего начать, если вы хотите создать собственный плагин.
Nx-плагин для AWS
AWS анонсировала Nx Plugin for AWS v1.0 на этой неделе, и Джек Стивенсон (Jack Stevenson) описал принципы его работы в блоге AWS Open Source. Я не буду повторять всё здесь, поэтому обязательно прочитайте ту статью или ознакомьтесь с моим разбором:
Краткая суть (TL;DR): вы можете создать совершенно новое рабочее пространство AWS + Nx с помощью команды:
(Разумеется, вы также можете использовать npm)
Затем изучите возможности плагина с помощью его документации, в которой они подробно описаны, включая учебное руководство Dungeon Adventure, в котором создается полноценное приложение. Или просто укажите на него агенту.
Зачем они его создали
Задача команды PACE — исследовать сложные проблемы для своих клиентов, и они подходят к этому через прототипирование.
Мы являемся частью PACE, команды Prototyping and AI Customer Engineering в компании AWS, и мы ежедневно сталкиваемся с противоречием между скоростью и готовностью к продакшену. Мы работаем с клиентами над проблемами, которые пока не имеют очевидного ответа, или над технически рискованными идеями, которые еще никто не реализовывал.
Мы являемся частью PACE, команды Prototyping and AI Customer Engineering в компании AWS, и мы ежедневно сталкиваемся с противоречием между скоростью и готовностью к продакшену. Мы работаем с клиентами над проблемами, которые пока не имеют очевидного ответа, или над технически рискованными идеями, которые еще никто не реализовывал.
Поэтому им потребовался инструмент, позволяющий двигаться быстро, независимо от используемого языка.
Разработка на AWS обычно означает инфраструктуру как код, бэкенд-сервисы, фронтенд и часто более одного языка в рамках одного проекта. Нам нужна была система сборки, которая не зависела бы от выбранного языка и могла управлять проектом, состоящим из множества движущихся частей. Наши команды остановили свой выбор на Nx и уже несколько лет используют его именно для этого [...]
Разработка на AWS обычно означает инфраструктуру как код, бэкенд-сервисы, фронтенд и часто более одного языка в рамках одного проекта. Нам нужна была система сборки, которая не зависела бы от выбранного языка и могла управлять проектом, состоящим из множества движущихся частей. Наши команды остановили свой выбор на Nx и уже несколько лет используют его именно для этого [...]
Цель состоит в том, чтобы получить работающий и развернутый прототип, который уже содержит строительные блоки, пригодные для непосредственного переноса и интеграции в реальный продукт. Прежде чем остановиться на Nx-плагине, они рассмотрели различные варианты, такие как шаблоны или подход на основе библиотек.
Генераторы Nx оказались именно тем, что нужно. Вместо шаблона, который вы форкаете, или библиотеки, от которой вы зависите, генератор записывает код прямо в ваше рабочее пространство. Вы владеете этим кодом с момента его генерации, и для работы с ним не требуется ничего специфичного для плагина. Когда вам нужно изменить то, что генератор не предусмотрел, вы можете отредактировать код обычным образом. И там, где шаблон оставлял сгенерированный код устаревать, миграции Nx позволяют доставлять улучшения в рабочие пространства, созданные вами ранее. [...] Каждый генератор намеренно автономен [...] в виде строительных блоков более высокого уровня: целых компонентов, которые можно собрать одной командой, работаете ли вы вручную или с помощью ИИ-помощника.
Генераторы Nx оказались именно тем, что нужно. Вместо шаблона, который вы форкаете, или библиотеки, от которой вы зависите, генератор записывает код прямо в ваше рабочее пространство. Вы владеете этим кодом с момента его генерации, и для работы с ним не требуется ничего специфичного для плагина. Когда вам нужно изменить то, что генератор не предусмотрел, вы можете отредактировать код обычным образом. И там, где шаблон оставлял сгенерированный код устаревать, миграции Nx позволяют доставлять улучшения в рабочие пространства, созданные вами ранее. [...] Каждый генератор намеренно автономен [...] в виде строительных блоков более высокого уровня: целых компонентов, которые можно собрать одной командой, работаете ли вы вручную или с помощью ИИ-помощника.
Генераторы детерминированы. Агент сам решает, какие из них запустить и как их связать. Когда результат необходимо скорректировать под конкретный вариант использования, агент может отредактировать сгенерированный код точно так же, как и любой другой код в рабочем пространстве.
Nx Devkit как API для расширения
Всё, что создала команда AWS, работает на базе Nx Devkit — того же API, который используют собственные плагины Nx. Он охватывает пользовательские установочные пакеты, такие как create @aws/nx-workspace, генераторы для создания и модификации кода, экзекуторы, а также плагины графа проектов, которые объясняют Nx новые инструменты и языки.
Создание расширений на Devkit раньше требовало немало времени. Вам нужно было изучить API генераторов и то, как плагины определяют проекты и задачи, поэтому пользовательская автоматизация должна была сэкономить вашей команде массу работы, чтобы ее стоило создавать. ИИ-агенты отлично справляются именно с таким кодовым инструментом, поэтому теперь вы можете делегировать им большую его часть.
Несколько примеров:
- Генераторы для локального рабочего пространства — укажите агенту на существующую библиотеку и заставьте его извлечь генератор, который создает новые с той же структурой. Я показывал это в видео о генераторах рабочего пространства.
- Пользовательские правила линтинга — командные стандарты, которые не охватывает ни один публичный ESLint-плагин, могут существовать в рабочем пространстве в виде пользовательских правил ESLint.
- Поддержка языков — плагин графа проектов считывает файлы конфигурации цепочки инструментов и превращает их в проекты, задачи и зависимости Nx. Руководство «Добавление поддержки языков в Nx» подробно рассматривает это на примере Python и uv, а также содержит промпт, который можно передать прямо вашему агенту.
Поддержка языков — это также то, как Nx работает со стеками за пределами JavaScript. Сообщество создало плагин @monodon/rust, который добавляет Rust в граф задач (я использовал его для объединения Rust и TanStack в одном монорепозитории). Сообщество плагина @nxlv/python делает то же самое для проектов на Python, использующих Poetry. Плагины для .NET, Maven и Gradle от нас (основной команды Nx) построены на тех же принципах Devkit.
Создайте свой собственный плагин
Если в вашей организации принят собственный способ запуска новых проектов (стандартная библиотека авторизации, внутренняя схема деплоя, утвержденные фреймворки), он, скорее всего, имеет ту же структуру, что и плагин AWS. Эти руководства в разделе расширения Nx станут хорошей отправной точкой:
- Создание специфичного для организации плагина для хранения ваших генераторов
- Локальные генераторы для автоматизации, требующейся только одному рабочему пространству
- Создание установочного пакета для собственной команды create-*, например @aws/nx-workspace
- Публикация плагина для совместного использования в разных репозиториях
AWS также описывает создание плагина с помощью своего генератора ts#nx-plugin, который предоставляет вашим ИИ-ассистентам доступ к вашим генераторам через MCP-сервер.
Узнайте больше
- Документация Nx Plugin для AWS
- Создавайте полностековые приложения AWS за считанные минуты с помощью каркасов на базе ИИ
- Документация по расширению Nx
- Nx на YouTube
