One thing I've noticed after using AI for development over the past year is this:
The code it generates is usually correct.
The architecture slowly isn't.
That doesn't happen because AI writes bad code.
It happens because architecture rarely erodes all at once.
Imagine a modular application with clear boundaries.
The billing module talks to the orders module through its public interface.
Authentication is isolated.
Notifications are independent.
Everything is predictable.
Now imagine hundreds of AI-assisted commits over the next few months.
One suggestion imports an internal class because it already exists.
Another bypasses a service layer because it's shorter.
A helper gets copied into another module.
A database query is duplicated instead of reused.
None of those changes are catastrophic.
In fact, every pull request probably gets approved.
The application still builds.
The tests still pass.
Customers never notice.
Until one day, making a simple change requires touching five different modules because everything has quietly become connected.
That's architecture debt.
And unlike a failing test, it doesn't show up immediately.
One thing I've realized is that our current tooling doesn't really watch for this.
Unit tests verify behavior.
Integration tests verify interactions.
Linters enforce style.
Static analysis finds bugs.
All of those are important.
But none of them are asking questions like:
- Should this module depend on that one?
- Did someone bypass a defined boundary?
- Are we introducing new architectural coupling?
- Is the overall architecture getting healthier or worse over time?
Those questions usually get answered during code review.
Or worse, during a production incident.
The interesting part is that AI isn't really the problem.
If anything, it's doing exactly what we ask it to do.
It optimizes for solving the problem in front of it.
Architecture, on the other hand, is about protecting the system as a whole.
Those are different goals.
As AI makes us write code faster, architectural drift also happens faster.
I wanted something that didn't rely on someone remembering to ask those questions during a review.
That's what led me to start building ArchPilot.
The idea wasn't to build another AI code reviewer.
It was to build something deterministic that continuously validates architectural rules and tracks architecture health over time, so architectural drift gets caught before it becomes expensive.
I'm curious whether others have noticed the same thing.
Have AI coding tools made your team faster without hurting architecture?
Or have you started seeing subtle architectural drift that wasn't there before?
If this resonates, I've been building ArchPilot to solve exactly this.
Top comments (0)