Connecting an AI assistant to your Angular project is the easy part. Getting real value from it every day is a workflow question: what you ask it to do, in what order, what you check, and where you keep the human in charge. Teams that get this right ship migrations in an afternoon; teams that don't end up reviewing confident, plausible code that doesn't quite fit their app.

This is lesson 12.5 of the Angular Tutorial and the end of Module 12. You've set up the Angular CLI MCP server (12.2), learned what it knows compared with generic servers (12.3), and built a companion server with your own rules (12.4). This lesson puts it together into a workflow for a real feature, from ticket to pull request, and is honest about where AI assistance helps and where it doesn't.

The loop #

Every productive AI-assisted change follows the same loop. The tools from this module map onto it directly:

The two steps people skip are Ground and Plan. Skipping Ground is how you get *ngFor and NgModules in a signals codebase. Skipping Plan is how a "small fix" turns into a 40-file diff.

A worked session: adding a feature #

Say the ticket is: "Add a 'favourites' toggle to product cards, persisted per user, with a filter on the product list."

Ground. Start by pointing the model at the rules, not the task:

"Before we start: read our Angular best practices and our team conventions, then summarise the patterns you'll follow for new components and state."

The model calls get_best_practices and your companion server's check_conventions (or reads your instructions file), and replies with a short list: standalone components, input()/output(), signals for local state, services for HTTP, @for with track. You now know it has the right frame, and so do you.

Plan. Ask for a plan, explicitly without code:

"Plan the favourites feature. List the files you'll create or change and why. Don't write code yet."

A good plan here names a FavouritesService holding a signal of IDs and syncing with the API, a FavouriteToggle component with a productId input, changes to ProductCard and ProductList, and a test for the service. Push back now if it's wrong. It costs one message, not a rewrite.

Change, in slices. Approve the plan one slice at a time: service first, then the toggle, then the list filter. Small slices keep each diff reviewable and give the model a clean build to check after each one.

Verify. After each slice:

"Build and run the unit tests for what you changed, and fix anything that fails."

With the Angular server's action tools enabled, the model calls run_target for build and test, reads the output, and loops until green. If you run it with --read-only, it asks you to run the commands instead, which is slower but gives you full control.

Review. Read the final diff yourself. Check the things the model is weakest at: naming that fits your domain, edge cases in the requirements, and whether the new code matches how your app does similar things. Then let it write the PR description, which it's genuinely good at.

Prompts that work #

A small library your team can copy into its instructions file or a shared doc. Each one builds in the Ground or Plan step:

Three patterns recur: scope (a folder, a class), constraints ("no code yet", "don't change anything", "fix the tests, not the service"), and an exit condition ("stop and ask if…"). Prompts with all three need far less correction.

Where AI assistance shines in Angular work #

Where it falls down #

Be explicit with your team about these, so nobody over-trusts the output:

• Visual and UX work. The model can't see the page the way a user does. It can write CSS; it can't judge whether the result looks right on a phone. Check it in the browser yourself.
• Novel architecture. Choosing between a signal store and NgRx for your constraints, or designing a module boundary, needs context the model doesn't have. Use it to list trade-offs, not to decide.
• Performance without measurement. "Make this faster" produces plausible changes with no evidence. Profile first (Module 8), then ask it to fix a specific, measured problem.
• Business rules. It will fill gaps in the ticket with reasonable-sounding assumptions. Anything ambiguous in the requirements needs a human answer, not a guess.
• Fast-moving APIs. Even with search_documentation, very new or experimental APIs may have thin docs. Treat those suggestions as drafts.

Team workflow #

The individual loop scales when the setup is shared:

1. Commit the MCP config (.mcp.json, .cursor/mcp.json, .vscode/mcp.json) with pinned versions and --read-only as the shared default (12.2).
2. Commit the instructions file that tells the model your Angular version, conventions and which server to use for what (12.3).
3. Version the companion server in tools/ so rules change through code review (12.4).
4. Keep CI as the source of truth. The assistant's check_conventions is advisory; lint rules and tests in CI are what enforce. Promote rules that matter into ESLint.
5. Review AI-written code like any other code. Same PR process, same standards. "The AI wrote it" is never a reason to skip review, and never a reason to reject good code either.

Keep it fast and cheap #

Every tool description and every file the model reads costs context. A few habits keep sessions quick:

• Connect only the servers this project needs. Three focused servers beat ten overlapping ones.
• Scope requests. "Review src/app/orders" beats "review the app".
• Prefer tools over file dumps. One check_conventions call replaces reading dozens of files.
• Start fresh sessions per task. Long sessions carry stale context from earlier work.
• Cap tool output. As in 12.4, return summaries and counts, not thousands of lines.

Common gotchas #

What's next #

That completes Module 12, and with it the AI × Angular track: from what ng mcp is (12.1), through setup, capabilities and custom tools, to a daily workflow. From here, Module 8 is the natural next stop: performance is the area where measuring first and asking the assistant second pays off most.

Try it yourself #

Pick a small ticket from your backlog and run it through the five steps: Ground, Plan, Change in slices, Verify, Review. Time it, then compare with how long the same kind of change usually takes, and note which step saved or cost the most.