Open Source or Custom in Enterprise AI Systems?

Once code generation gets good enough, teams start measuring the wrong things. PR counts go up. Number of changes explode. Review cycles get shorter. Spikes appear faster. Demos look better. On paper, this feels like acceleration.

In practice, it often means the system is accumulating surface area faster than the team can validate it.

We saw this clearly in a sensitive project built around a core authentication and authorization module. Development throughput was high. Reviews were fast. Exploratory spikes kept moving. The real question was not whether we were shipping fast, but whether we were validating the right things deeply enough.

The spike review process was too light for the risk surface.

That kind of gap rarely hurts during demo week. It hurts later, during validation, security review, or direct client scrutiny, when architectural weaknesses become expensive to hide and even more expensive to fix.

One subtle failure mode kept appearing: AI treats everything in the codebase as equally valid. It doesn’t understand which parts are actually alive, trusted, or safe to use.

We saw implementations built on top of dead code (e.g., inactive user activation paths), unused database tables, or the ignoring of multiple auth flows depending on feature flags.

This is why velocity metrics used in isolation are weak proxies in AI-assisted teams. When code generation gets cheaper, output volume becomes meaningless. What matters is whether the system remains:

The split between senior + AI and junior + AI becomes sharper. One uses AI to remove toil while protecting design quality. The other can generate code, APIs, and abstractions faster than they can reason about them.

AI amplifies engineering maturity. It does not replace it.

That also changes what the review is about. It is no longer enough to review the diff. Teams need to review the design first: boundaries, invariants, trust model, rollback path, observability, and failure handling. AI can fill in a pull request. It cannot certify that the decomposition is sound.

The interesting bugs are no longer in the scaffolding. They are at the boundaries.

With frameworks like FastMCP, it is now easy to get a server running quickly. Built-in middleware patterns cover much of the obvious cross-cutting work: caching, logging, rate limiting. The demo appears fast. The first version looks clean.

But the real engineering work starts one layer deeper:

That is the part the agent has to live with in production. And that is where low-quality systems become excessively nondeterministic.