I have been using AI coding assistants for quite some time, and one thing became very clear to me:

Writing code is not always the difficult part. Understanding the system is.

This becomes even more obvious when working with microservices.

Imagine I am working on order-service and I ask my AI assistant:

“Update the checkout flow so that payment is processed through the payment service.”

The AI can write the code.

But there are some questions it cannot reliably answer just by looking at the file I currently have open:

  • Which service actually owns the payment API?

  • What payload does that API expect?

  • Which database tables are involved?

  • What other services consume the resulting event?

  • If I change this API, what else could be affected?

This is the problem I started exploring with ArchMCP.

The problem with AI coding assistants

Normally, an AI coding assistant works with the context available to it — your open files, repository, documentation, and whatever you provide in the prompt. That works quite well for a small application. But consider a system like below:

user-service
     ↓ HTTP
order-service
     ↓ HTTP
payment-service
     ↓ event: order.paid
notification-service

Now imagine changing an endpoint in payment-service.

The important information isn't only inside payment-service.

The change may affect the service calling it and the services consuming its events.

You can give all of this information to an AI manually, but that quickly becomes impractical. ArchMCP takes a different approach: let the AI ask for the information when it needs it.

So, where does MCP actually help?

This is where MCP becomes useful.

An MCP server like ArchMCP can scan a project and discover services, API routes, database schemas, message queues, background jobs, Docker relationships and inferred service dependencies.

For example, after scanning a project:

archmcp scan ./my-project

the architecture becomes queryable by the AI assistant. Now the conversation can become much more practical.

Instead of asking the AI to inspect everything, it can ask:

“Who owns /payments/charge?”

ArchMCP can answer through find_api_owner.

Then:

“What does that service depend on?”

→ get_service_dependencies

Then:

“What tables does this service own?”

→ get_database_schema

And the question I find particularly interesting:

“If I change this service, what could be affected?”

→ analyze_blast_radius

These are not prompts that I hardcoded into an AI workflow. They are actual tools exposed through ArchMCP for an AI assistant to use when needed.

From code generation to change understanding

This is the part I find most interesting.

Suppose I want to modify /api/v1/orders.

A normal AI workflow might start generating code immediately.

With architectural context available, the workflow can be different:

Change request
      ↓
Find API owner
      ↓
Understand service dependencies
      ↓
Check database / events
      ↓
Analyze blast radius
      ↓
Generate the change

Now the AI isn't only answering:

“How should I write this code?”

It can also help answer:

“What should I understand before changing this code?”

That is a much more useful problem to solve in a large system.

This is what I mean by AI-native development

For me, AI-native software development is not simply adding an AI assistant to an existing development workflow. It is about changing the workflow so that AI can actually interact with the engineering environment.

The same idea can be applied beyond architecture.

An MCP server could expose your issue tracker, logs, deployment system, database metadata, monitoring system or internal documentation.

The important part is that the AI doesn't need everything all the time.

It needs the right context at the right moment.

That is the idea behind ArchMCP.

I built it as an experiment around one specific question:

What if an AI coding assistant could query the architecture instead of making assumptions about it?

I don't think MCP itself solves software development.

But it gives us a standard way to connect AI with the tools and information that developers already depend on.

And I think that is where things start getting interesting.

The future of AI-assisted development may not be about giving AI more code.
It may be about giving AI better context.

My takeaway

If we want AI to become a real part of software engineering, giving it more code is not always the answer. We also need to give it access to the context developers use to make decisions. For me, MCP is interesting because it provides a practical way to build that connection — and ArchMCP is my small exploration of what that could look like for software architecture.