Working on Sparx EA from your coding environment: Claude Code, VS Code and Cursor

A technical architect spends much of the week beside code. They read interface specifications, review infrastructure definitions and check pull requests against the design. The architecture model in Sparx EA describes the same system, and it drifts whenever the model and the code are worked on in different places. This article covers what a technical architect can now get done on a live repository from the coding environment, what each job asks of the architect, and which documented route gets them there.

Three jobs a technical architect does beside the code

Keeping the model in step with what was built

Today, by hand. After a release, the architect opens EA, finds the application components and interfaces that changed, and edits them one at a time from the release notes and from memory. In a busy week it slips, and the model falls behind the code.

AI-augmented. The architect works with the AI in the same workspace as the specifications and configuration that changed. They say what the release changed and which parts of the model describe it. The AI reads the files, proposes the model updates, and makes them in EA once the architect agrees.

The skill it asks. Knowing which model elements describe which parts of the code, and saying so precisely. The AI cannot tell that your Payments API component is the service in a given folder unless someone tells it.

Turning a specification into model content

Today, by hand. The architect retypes operations, data structures or deployment nodes from a specification into EA, or leaves them out of the model because there is no time.

AI-augmented. The architect points the AI at the specification, states which modeling language and which stereotypes the result should use, and reviews what it creates before anyone else sees it.

The skill it asks. Knowing your modeling conventions well enough to state them, and reading the result critically. Output that looks finished tends to get accepted, so the review has to be a real one.

Checking the model before a design review

Today, by hand. Someone opens the diagrams and looks for missing tagged values, unconnected elements and stereotypes applied out of habit.

AI-augmented. The AI runs the team’s validation rules against the package and reports what fails. The architect decides what each failure means and what to fix before the review.

The skill it asks. Writing down what complete means for your team, so there are rules to check against. Automation checks completeness, people own correctness.

Which documented route gets you there

Each of these jobs needs an AI that can read and change the live repository from the architect’s own machine. AI Power Tools for Sparx EA, free for every Sparx user and published by NovoCircle, provides that. It runs on Windows 10 or 11, with Enterprise Architect installed on the same machine. It documents two routes.

Claude Code in the Claude desktop app. Two free parts work together. The Claude Desktop extension is the MCP server, and the same install serves Claude Desktop chat and Claude Code in the desktop app. The ai-power-tools plugin from the novocircle marketplace carries the skills, the written procedures the AI follows for modeling, validation, MDG work and reporting. Both are needed. This is the route for an architect who wants the method as well as the access.

GitHub Copilot in VS Code on Windows. The AI Power Tools VS Code extension gives GitHub Copilot the same MCP server, and VS Code loads the same skills. There is no computer use in VS Code today, so the architect opens EA and checks diagrams in its window. Teams that have standardized on Copilot and VS Code, and teams that want the choice of AI model, often work this way.

On either route, the architect still decides what should change in the model. The skills give the AI a procedure to follow. They do not tell it what your design should be.

What is not documented

Cursor is not a documented surface for AI Power Tools. Remote VS Code sessions are not documented either, where the editor is attached to WSL, a container or an SSH host, because the server has to run in the same Windows environment as Enterprise Architect. Claude Code run from a terminal is not the documented route; Claude Code in the Claude desktop app is. We do not describe setups for any of these as supported. If your architects work in one of them, do the model work in the Claude desktop app or in VS Code with Copilot on the Windows machine where EA runs. Setup for both documented routes is in the NovoCircle documentation.

A different job: engineers who only need answers

Everything above is about an architect changing the model from their own machine. A delivery team that wants to look things up in the architecture from its editor, across the enterprise, is doing a different job. That job belongs to the read-only MCP server in Kernaro AI Hub, a Sparx Systems product that runs on a server and answers questions without changing the model. Our piece on architecture answers in the engineer’s editor covers that job.

Choosing

• An architect who wants the AI to open EA and check diagrams in its window: Claude Code in the Claude desktop app, with the extension and the plugin.
• An architect or engineer already working in VS Code with GitHub Copilot on Windows: the VS Code extension and the same skills, with the architect doing the steps in EA’s window.
• Anyone working in Cursor or a remote session: neither is a documented route. Use one of the two above on the Windows machine where EA runs.
• Engineers who need read-only answers across the enterprise: Kernaro AI Hub’s MCP server.

The organization also has to permit Claude or GitHub Copilot. The comparison of AI options for Sparx EA sets all of them side by side.

Questions people ask