The Difference Between Governance and Overgovernance in the Age of AI Engineering

The Difference Between Governance and Overgovernance in the Age of AI Engineering

A lot of engineering organizations are going through the same transformation right now.

Executives are coming back from AI conferences convinced — correctly — that AI-assisted engineering is no longer optional. Teams are adopting Claude Code, GitHub Copilot, MCP servers, internal plugins, architecture agents, Jira integrations, Figma integrations, and repository automation at an incredible pace.

And honestly?

Some of it is extremely impressive.

I recently watched teams demonstrate environments where agents can:

• Pull requirements from Jira

• Read Figma designs

• Apply repository standards

• Generate React and .NET code

• Enforce architectural rules

• Validate security policies

• Automatically align with enterprise patterns

That is real progress.

But while watching all of this, I kept coming back to one question:

At what point does governance become overgovernance?

Because there’s a hidden danger emerging in some of these systems.

Not bad intentions.

Not bad engineering.

Not bad architecture.

Just too much machinery exposed directly to the application team.

The New Developer Maze

Many organizations are unintentionally building what I call a developer maze.

A feature team now has to understand:

• Which agent to invoke

• Which plugin to call

• Which MCP server handles which responsibility

• Which repository rules apply

• Which architectural standards must be inherited

• Which shared libraries are mandatory

• Which security workflows are enforced

• Which UI patterns come from Figma

• Which validation layers execute before merge

The result?

The developer spends more time navigating the governance system than solving the business problem.

Ironically, the very systems designed to accelerate engineering can begin slowing engineers down.

The Real Problem Is Not Governance

Governance itself is not the problem.

Enterprises absolutely need:

• Security controls

• Architectural consistency

• Approved frameworks

• Shared libraries

• Auditability

• Platform standards

• Design system enforcement

• Operational guardrails

The problem is where the cognitive burden lives.

If humans must manually remember and obey every rule, the system eventually collapses under its own complexity.

And that leads to the most important realization I’ve had lately:

Governance happens when humans must manually obey every rule.

Good governance happens when the machine discovers, applies, and validates the rules automatically.

That changes everything.

Intent-Driven Engineering Changes the Relationship

This is where Intent-Driven Engineering becomes important.

The feature team should not have to orchestrate the governance machinery manually.

Instead, the feature team should declare intent.

Something closer to this:

intent:

  feature: customer-profile-dashboard

  stack:

    backend: dotnet

    frontend: react

  requirements:

    - use approved component library

    - follow repository architectural standards

    - align with Figma design system

    - enforce enterprise security policies

    - validate accessibility requirements

  success_criteria:

    - tests pass

    - lint passes

    - architecture validation passes

    - ui matches approved design

Notice what’s missing.

The developer never says:

• which agent to invoke

• which plugin chain to execute

• which MCP server to call first

• which parser reads Figma

• which architectural scanner validates the repo

That becomes the responsibility of the platform.

The Platform Should Discover Constraints

This is the shift most organizations are still missing.

The application team should own:

• business outcomes

• feature intent

• local implementation decisions

• user experience

• domain logic

The platform should own:

• rule discovery

• governance enforcement

• orchestration

• compliance validation

• architecture inheritance

• dependency resolution

That is the separation that creates freedom inside governance.

Without that separation, AI engineering environments eventually become heavily instrumented cages.

The Future Is Not Less Governance

The future is actually more governance.

But it will be:

• machine-applied

• dynamically discovered

• context-aware

• repository-aware

• architecture-aware

• continuously validated

The engineer will move away from manually navigating tooling ecosystems and toward declaring governed outcomes.

That’s a fundamentally different model.

And honestly, I think that’s where this entire industry is heading.

Not toward removing developers.

Toward removing unnecessary cognitive friction from developers.

Final Thought

The organizations that win in the AI engineering era will not be the ones with the most agents, plugins, or MCP servers.

They will be the ones that successfully answer this question:

How do we give teams strong governance without turning engineering into a permission maze?

Because eventually, the teams that move fastest will not be the teams with the most tools.

They’ll be the teams where intent flows cleanly through governance, architecture, automation, and delivery — without the engineer having to manually carry the entire system in their head.

Time to move beyond prompts.