DEV Community

Cover image for My AI Passed Every Test. It Still Broke the Architecture
Faris Kurnia
Faris Kurnia

Posted on

My AI Passed Every Test. It Still Broke the Architecture

AI coding assistants have become part of my daily workflow. Whether I'm using Kilo Code, Claude Code, or GitHub Copilot, I rarely start a new feature without asking AI for help first.

A few days ago I asked Kilo Code to implement a login flow. Within minutes the feature was finished, the code compiled, unit tests passed, and the pull request looked perfectly reasonable. Everything suggested it was ready to merge.

Then I opened our architecture diagram.

The implementation generated JWT tokens inside the User Service, even though our architecture clearly defined that responsibility for the Authentication Service. Nothing was technically broken, but the architecture had already started drifting.

That was the moment I realized something.

AI has become very good at writing code.
We still don't have a good way to verify whether that code follows the architecture.

Code Reviews Aren't Designed for Architecture

Most code reviews focus on implementation quality. We look for bugs, naming issues, performance problems, security concerns, and whether the tests are passing. Those are all important, but they answer a different question.

They tell us whether the code is good.

They don't tell us whether the implementation is still consistent with the system design.

Repositories only show AI what exists today. They don't explain why services are separated, why a request follows a particular sequence, or which component owns a business responsibility. Those decisions usually live inside architecture diagrams, technical documentation, or simply inside the heads of senior engineers.

As AI generates more production code, that missing context becomes increasingly important.

What If AI Could Read the Architecture?

That question eventually led me to build StartWithUML.

Originally, the idea was simple: make it easier to create PlantUML diagrams and generate technical documentation with AI.

But while integrating it with coding agents through MCP (Model Context Protocol), I discovered something much more interesting.

Instead of treating UML diagrams as documentation, I could use them as architecture context for AI.

Rather than asking a coding agent to guess how the system works, I could let it retrieve the architecture directly before reviewing or implementing code.

That completely changed my workflow.

A Practical Workflow with Kilo Code

Today, my workflow starts exactly the same as before.

I ask Kilo Code to implement a feature.

Implement CSV Import Validation
Enter fullscreen mode Exit fullscreen mode

Once the implementation is finished, I don't immediately start reviewing the code. Instead, I ask Kilo Code to retrieve the architecture from StartWithUML through MCP.

The first tool it usually calls is:

startwithuml_list_my_diagrams
Enter fullscreen mode Exit fullscreen mode

This will generate a list of the diagrams we have in StartWithUML

or, For deeper reasoning, the agent retrieves structured architecture data using:

  • startwithuml_get_diagram_context, or
  • startwithuml_get_diagram_by_id "cmqw0jxal000dkmukeuyodjnm"

The Most Interesting Part

The real value isn't that AI writes code faster.

It's what happens after the code is generated.

Instead of asking:

"Does this code compile?"

I now ask:

Please check whether my implementation or code is in accordance with the diagram or architecture, startwithuml_get_diagram_by_id "cmqw0jxal000dkmukeuyodjnm"

In practice, this has helped me find things like:

  • Validation steps described in sequence diagrams that were never implemented.
  • Services that communicate directly with other services when the component diagram requires communication through an API gateway.
  • Unimplemented validation.
  • Business logic placed in the wrong application layer.

None of these issues caused compilation errors.

None of these issues failed unit tests.

All of them were architectural violations.

That's the kind of review I'd typically expect from a senior engineer—not an AI coding assistant.

More Than Just a UML Tool

I don't consider StartWithUML a diagram generator.

Diagrams are just one part of the system.

The real value is giving AI access to architecture, technical documentation, and design decisions whenever it needs them.

Instead of writing increasingly lengthy commands, I let the coding agent get context directly from the source of truth.

The repository tells the AI ​​what exists.

The architecture explains why it exists.

Good engineering requires both.

Final Thoughts

Everyone is racing to build smarter AI coding assistants.

I think the next challenge isn't generating more code.

It's making sure that AI-generated code remains consistent with the architecture your team has already agreed upon.

If architecture can become first-class context for AI, code reviews may evolve beyond checking syntax and tests. They can become architecture reviews as well.

That's the direction I'm exploring with StartWithUML, and I'm excited to see where it leads.

🎉 50% OFF for Dev.to Readers

If you'd like to try this workflow yourself, I'd love to invite the Dev.to community to give it a try.

Use the coupon code:

DEVTO50
Enter fullscreen mode Exit fullscreen mode

to get 50% OFF your first StartWithUML Pro subscription.

With the Pro plan you'll get access to AI-powered diagram generation, technical documentation, diagram sharing, and MCP integration so coding agents like Kilo Code can retrieve architecture context directly during development.

👉 https://startwithuml.cloud

Top comments (0)