Blog

Frequently asked questions

What problem does defining architecture with a coding agent actually solve?

It closes the gap between the architecture a team intends and the architecture that actually exists in the codebase. That gap, known as architectural drift, is what causes systems to become brittle and expensive to change. Because agents generate code without understanding intended architecture, this gap widens faster with agentic development than it did with human-only development.

Do I need to learn a new tool to use this?

No. You work through the SonarQube CLI or the SonarQube MCP Server, tools your coding agent already uses to interact with your codebase, and the result appears alongside any architecture you may have already built through the SonarQube Cloud web editor.

What happens when code violates the intended architecture after it's defined?

SonarQube Cloud raises the violation as a maintainability issue during the next analysis, in the same developer workflow your team uses for other findings. There is no overhead for developers as it all fits in the existing workflow.

Who can change the intended architecture once it's set?

Only users with the "Administer architecture" permission on the project can write changes, whether through the agent workflow or the public Web API. Any user with "Browse" permission can read the current and intended architecture.

Can this scale beyond a single project?

Yes. The public Web API endpoints expose the same read and write capabilities used in the agent workflow, so teams can template an intended architecture across many projects or integrate architecture data into their own tooling.