Stop Asking Every Developer to Become an AI Expert

Stop Asking Every Developer to Become an AI Expert

Why Enterprise AI Adoption Depends on a Layered Operating Model

Over the past several months, I’ve had the opportunity to work with engineering organizations adopting AI-assisted software development. One pattern keeps emerging, regardless of the company, technology stack, or large language model (LLM) they choose.

The biggest obstacle isn’t the AI.

It’s the operating model.

Many organizations unintentionally ask every feature team to become AI platform engineers. Developers are expected to learn prompt engineering, build Claude skills, configure MCP servers, integrate Jira and Confluence, create reusable automation, maintain agent frameworks, and still deliver sprint commitments.

That simply doesn’t scale.

The problem isn’t that developers can’t do it.

The problem is that it’s not their job.

The Unit of Innovation Is Not the Unit of Adoption

This may be the most important lesson I’ve learned during enterprise AI implementations.

The team that invents an AI capability is rarely the team that should own it forever.

Feature teams are measured on outcomes such as:

• Delivering Jira stories

• Shipping production software

• Fixing defects

• Meeting sprint commitments

• Keeping systems stable

They are not measured on building reusable AI infrastructure.

When organizations ask every repository team to create its own skills, agents, prompts, integrations, and automation, adoption slows dramatically. Every team reinvents the same capabilities while trying to deliver business value.

Eventually, AI becomes “one more thing” developers are expected to do.

We’ve Solved This Problem Before

Enterprise software has already lived through this transition.

Developers don’t build Kubernetes.

They consume Kubernetes.

They don’t build GitHub Actions.

They consume GitHub Actions.

They don’t build enterprise identity providers.

They consume authentication services.

AI engineering is heading toward exactly the same operating model.

The organizations that scale will separate platform engineering from application engineering.

A Layered Operating Model

The model is surprisingly simple.

Layer 1 — Enterprise Shared Services

A centralized platform team owns reusable AI capabilities.

This includes:

• MCP integrations

• Jira, Confluence, and Figma connectors

• Shared Claude skills

• Prompt libraries

• Slash commands

• Governance

• Observability

• Security

• Enterprise standards

These capabilities are built once and improved continuously.

Every repository benefits.

Layer 2 — Enterprise Intent Platform

Business requests begin as Jira stories.

Instead of every team manually transforming those stories into prompts, a shared platform retrieves enterprise context, validates requirements, generates structured intent, scores completeness, and improves the intent before it ever reaches a repository.

The output is a high-quality implementation package instead of a partially written user story.

This becomes the standard interface between business intent and engineering execution.

Layer 3 — Repository Teams

Repository teams continue doing what they’ve always done best.

They build software.

Instead of constructing AI infrastructure, they consume it.

Their workflow becomes remarkably straightforward:

Business Request → Jira Story → Shared Services → Validated Intent → Claude Code → Pull Request

The repository team focuses on implementation while the platform handles the complexity.

Why This Model Scales

The greatest return on investment rarely comes from making hundreds of developers AI experts.

It comes from enabling a small group of specialists to build capabilities that hundreds of developers can reuse.

One well-designed shared skill may save thousands of engineering hours.

One reusable MCP integration can eliminate duplicate work across dozens of repositories.

One governed intent-generation pipeline can dramatically improve implementation quality across an entire organization.

Platform capability compounds.

Individual heroics do not.

The Conversation Changes

Instead of telling developers:

“You need to become an AI expert.”

We tell them:

“Describe your feature clearly.”

Everything after that becomes enterprise infrastructure.

That’s a much easier ask.

It’s also a far more scalable one.

The Future of Enterprise AI

Successful organizations won’t ask every engineer to master every AI tool.

They’ll build shared platforms that allow engineers to benefit from AI without becoming AI platform builders themselves.

That’s how cloud engineering evolved.

That’s how DevOps matured.

And I believe that’s how enterprise AI engineering will scale.

The future isn’t every developer building AI.

The future is every developer consuming a world-class AI platform their organization has already built.

Final Thought

The companies that achieve AI at enterprise scale won’t necessarily have the smartest prompts or the newest models.

They’ll have the best operating model.

When AI capabilities become shared enterprise services instead of individual developer responsibilities, adoption accelerates, governance improves, and engineering teams can stay focused on what they do best—delivering business value.