Even when a coding agent scaffolds the frontend, API, and infrastructure code, you want the outcome to be predictable. The AWS PACE team (Prototyping and AI Customer Engineering) hit this on their customer engagements and packaged their setup as an Nx plugin.

So let's dive into how it works, why the Nx Devkit underneath it matters more now that agents can write this kind of automation, and where to start if you want to build your own plugin.

The Nx Plugin for AWS

AWS announced the Nx Plugin for AWS v1.0 this week, and Jack Stevenson wrote up how it works on the AWS Open Source blog. I won't repeat everything here, so go read that blog post or check out my walkthrough:

The TL;DR is you can create a brand new AWS + Nx workspace with:

(You can obviously also use npm)

Then explore the plugin capabilities using the plugin documentation, which covers them in detail, including a Dungeon Adventure tutorial that builds a complete application. Or just point an agent to it.

Why they built it

The PACE team's job is to explore difficult problems for their customers, and they approach it through prototyping.

We are part of PACE, the Prototyping and AI Customer Engineering team at AWS, and we face the tension between speed and production readiness daily. We work with customers on problems that do not have an obvious answer yet, or the technically risky ideas that have not been built before.

We are part of PACE, the Prototyping and AI Customer Engineering team at AWS, and we face the tension between speed and production readiness daily. We work with customers on problems that do not have an obvious answer yet, or the technically risky ideas that have not been built before.

So they required a tool that allows them to move fast, agnostic to the language being used.

Building on AWS usually means infrastructure as code, backend services, a frontend, and often more than one language in the same project. We needed a build system that was agnostic to the language we chose and could manage a project made of many moving parts. Our teams landed on Nx and have used it for several years for exactly this [...]

Building on AWS usually means infrastructure as code, backend services, a frontend, and often more than one language in the same project. We needed a build system that was agnostic to the language we chose and could manage a project made of many moving parts. Our teams landed on Nx and have used it for several years for exactly this [...]

The goal is to have a working and deployed prototype, which already contains the building blocks that can be directly taken and integrated into the actual product. Before going with an Nx plugin, they explored various options, such as templates or a library-based approach.

Nx generators were what finally fit. Instead of a template you fork or a library you depend on, a generator writes code directly into your workspace. You own that code from the moment it is generated, and working with it requires nothing plugin-specific. When you need to change something the generator did not anticipate, you can edit the code as you usually would. And where the template left generated code to fall behind, Nx migrations let the improvements we ship reach workspaces you scaffolded earlier. [...] Each generator is deliberately self-contained [...] in higher-level building blocks: whole components you can assemble with a single command, whether you are working by hand or with an AI assistant

Nx generators were what finally fit. Instead of a template you fork or a library you depend on, a generator writes code directly into your workspace. You own that code from the moment it is generated, and working with it requires nothing plugin-specific. When you need to change something the generator did not anticipate, you can edit the code as you usually would. And where the template left generated code to fall behind, Nx migrations let the improvements we ship reach workspaces you scaffolded earlier. [...] Each generator is deliberately self-contained [...] in higher-level building blocks: whole components you can assemble with a single command, whether you are working by hand or with an AI assistant

The generators are deterministic. The agent decides which ones to run and how to connect them. When the result needs adjusting for a specific use case, the agent can edit the generated code just like any other code in the workspace.

The Nx Devkit as an extensibility API

Everything the AWS team built sits on the Nx Devkit, the same API that Nx's own plugins use. It covers custom install packages like create @aws/nx-workspace, generators that scaffold and modify code, executors, and project graph plugins that teach Nx about new tools and languages.

Building on the Devkit used to take real time. You had to learn the generator APIs and how plugins infer projects and tasks, so custom automation had to save your team a lot of work to be worth building. Coding agents are good at exactly this kind of tooling code, so you can now delegate a large part of it.

Some examples:

Local workspace generators - Point an agent at an existing library and have it extract a generator that scaffolds new ones with the same structure. I showed this in a video on workspace generators.
Custom lint rules - Team conventions that no public ESLint plugin covers can live in the workspace as custom workspace ESLint rules.
Language support - A project graph plugin reads a toolchain's config files and turns them into Nx projects, tasks, and dependencies. The Add Language Support to Nx guide walks through it with Python and uv, and it includes a prompt you can hand straight to your agent.

Language support is also how Nx works with stacks beyond JavaScript. The community @monodon/rust plugin brings Rust into the task graph, which I used to combine Rust and TanStack in one monorepo. The community @nxlv/python plugin does the same for Python projects built on Poetry. The .NET, Maven, and Gradle plugins from us (the Nx core team) are built on the same Devkit fundamentals.

Build your own plugin

If your organization has its own way of starting new projects (a standard auth library, an internal deployment setup, approved frameworks), it likely fits the same shape as the AWS plugin. These guides in the Extending Nx section are good starting points:

Create an organization-specific plugin to hold your generators
Local generators for automation that only one workspace needs
Create an install package for your own create-* command, like @aws/nx-workspace
Publish your plugin to share it across repositories

AWS also documents building a plugin with their ts#nx-plugin generator, which exposes your generators to AI assistants through an MCP server.

Learn more

Nx Plugin for AWS documentation
Build full-stack AWS applications in minutes with AI-powered scaffolding
Extending Nx docs
Nx on YouTube

So let's dive into how it works, why the Nx Devkit underneath it matters more now that agents can write this kind of automation, and where to start if you want to build your own plugin.

The Nx Plugin for AWS

The TL;DR is you can create a brand new AWS + Nx workspace with:

(You can obviously also use npm)

Why they built it

The PACE team's job is to explore difficult problems for their customers, and they approach it through prototyping.

We are part of PACE, the Prototyping and AI Customer Engineering team at AWS, and we face the tension between speed and production readiness daily. We work with customers on problems that do not have an obvious answer yet, or the technically risky ideas that have not been built before.

So they required a tool that allows them to move fast, agnostic to the language being used.

Building on AWS usually means infrastructure as code, backend services, a frontend, and often more than one language in the same project. We needed a build system that was agnostic to the language we chose and could manage a project made of many moving parts. Our teams landed on Nx and have used it for several years for exactly this [...]

Nx generators were what finally fit. Instead of a template you fork or a library you depend on, a generator writes code directly into your workspace. You own that code from the moment it is generated, and working with it requires nothing plugin-specific. When you need to change something the generator did not anticipate, you can edit the code as you usually would. And where the template left generated code to fall behind, Nx migrations let the improvements we ship reach workspaces you scaffolded earlier. [...] Each generator is deliberately self-contained [...] in higher-level building blocks: whole components you can assemble with a single command, whether you are working by hand or with an AI assistant

The Nx Devkit as an extensibility API

Some examples:

Local workspace generators - Point an agent at an existing library and have it extract a generator that scaffolds new ones with the same structure. I showed this in a video on workspace generators.
Custom lint rules - Team conventions that no public ESLint plugin covers can live in the workspace as custom workspace ESLint rules.
Language support - A project graph plugin reads a toolchain's config files and turns them into Nx projects, tasks, and dependencies. The Add Language Support to Nx guide walks through it with Python and uv, and it includes a prompt you can hand straight to your agent.