Pillar Maturity Assessment Companion
This page is a pillar-by-pillar assessment companion for teams using the canonical AEEF Maturity Model to evaluate organizational AI-assisted development maturity.
It helps organizations:
- translate maturity levels into pillar-specific evidence checks
- identify which pillar is constraining overall maturity
- prioritize investments by pillar gap, not only by overall score
Use this page with the canonical maturity model, not as a separate maturity scale.
Canonical Maturity Levels (Used by This Companion)
This companion uses the same five maturity levels defined in the AEEF Maturity Model:
| Level | Name | Description |
|---|---|---|
| 1 | Uncontrolled | AI tools are used ad hoc by individuals. No organizational standards, training, or governance. Results are inconsistent and unmeasured. |
| 2 | Exploratory | The organization has acknowledged AI-assisted development and begun establishing basic standards. Some teams are adopting structured approaches, but consistency is low. |
| 3 | Defined | Standards are documented and widely communicated. Training programs are in place. Most teams follow defined workflows. Quality gates exist but may not be consistently enforced. |
| 4 | Managed | AI-assisted development is measured, managed, and continuously improved. Metrics drive decisions. Quality is consistent. Teams are proficient and share knowledge actively. |
| 5 | AI-First | AI-assisted development is a core organizational capability. Innovation is continuous. AI is seamlessly integrated into engineering processes with strong governance and measurable outcomes. |
info
Most organizations beginning their AEEF journey will be at Level 1 or 2. Reaching Level 3 is a realistic 2-3 week goal. Level 4 typically requires 4-5 weeks. Level 5 represents best-in-class maturity that requires 6+ weeks of sustained investment. AI tooling accelerates every aspect of adoption — policy generation, CI/CD integration, training, and metrics can all be AI-assisted.
Evaluation Criteria by Pillar
The maturity assessment evaluates capabilities across all five AEEF pillars. Each pillar is scored independently, and the overall maturity level is the minimum of all pillar scores (the weakest link determines overall maturity).
Pillar 1: Engineering Discipline
| Level | Criteria |
|---|---|
| 1 | AI-assisted work is informal and inconsistent. No structured prompting, validation workflow, or AI-specific review discipline. |
| 2 | Teams experiment with basic prompting and review practices, but engineering discipline is inconsistent and person-dependent. |
| 3 | Standardized AI-assisted engineering workflow is documented (prompting, review, testing, validation). Human-in-the-loop expectations are defined and generally followed. |
| 4 | Engineering discipline is enforced through repeatable practices and quality gates. Review/test rigor scales by risk tier, and teams monitor adherence trends. |
| 5 | Engineering discipline is institutionalized and continuously improved using evidence from defects, review outcomes, and operational feedback loops. |
Pillar 2: Governance & Risk
| Level | Criteria |
|---|---|
| 1 | No formal AI governance. Tool usage, data handling, and provenance expectations are undefined. AI-specific risk is unmanaged. |
| 2 | Basic approved tool list exists and some data handling guidance is in place. Governance practices exist but are inconsistently enforced. |
| 3 | Governance framework is documented across data classification, provenance, IP, compliance, and review responsibilities. Audit and exception processes are defined. |
| 4 | Governance controls are actively enforced and measured. Regular reviews/audits occur, exceptions are tracked, and remediation is managed to closure. |
| 5 | Governance and risk management are proactive and increasingly automated. Policies and overlays evolve based on incidents, audits, and regulatory change. |
Pillar 3: Productivity Architecture
| Level | Criteria |
|---|---|
| 1 | No shared productivity assets. Each developer works independently with AI tools. |
| 2 | Basic prompt sharing occurs informally. Some teams have documented workflows. |
| 3 | Centralized prompt repository in active use. Workflow patterns documented. Toolchain standardized. Basic metrics collection. |
| 4 | Prompt repository actively curated with effectiveness ratings. Automation libraries in production use. Comprehensive metrics drive decisions. Feedback loops operational. |
| 5 | Productivity assets are continuously optimized. Reusable components library is extensive. Metrics show sustained, measurable productivity gains. Feedback loops drive innovation. |
Pillar 4: Operating Model Integration
| Level | Criteria |
|---|---|
| 1 | No operating model adaptation. AI-assisted work fits awkwardly into existing processes. |
| 2 | Teams are beginning to adapt estimation and sprint practices. Changes are informal and team-specific. |
| 3 | Sprint ceremonies formally adapted. Estimation methodology documented. Role definitions updated. Change management plan in execution. |
| 4 | Estimation accuracy matches pre-AI levels. Sprint processes are stable and effective. Team structures optimized. Change management is mature. |
| 5 | Operating model seamlessly incorporates AI capabilities. Predictive planning models in use. Team structures dynamically adapt. The operating model itself is AI-augmented. |
Pillar 5: Organizational Enablement & Maturity
| Level | Criteria |
|---|---|
| 1 | No formal training or cultural initiatives. AI adoption is organic and unguided. |
| 2 | Basic training available. Some awareness of cultural needs. |
| 3 | Structured training programs deployed. AI Champions active. CoE established. Cultural norms documented. |
| 4 | Training is tiered and role-specific. Champions network is effective. CoE is a recognized strategic asset. Culture actively supports experimentation and quality. |
| 5 | Continuous learning is embedded in the culture. The organization is recognized externally for AI-assisted development excellence. The CoE drives industry-level innovation. |
Scoring Methodology
Assessment Process
- Assemble Assessment Team: Include representatives from each pillar area: engineering discipline, governance/risk, productivity, operating model, and organizational enablement
- Gather Evidence: Collect artifacts, metrics, and interview data that demonstrate capability levels
- Score Each Pillar: Rate each pillar on the 1-5 scale using the criteria above
- Calculate Overall Score: The overall maturity level equals the minimum pillar score
- Identify Gaps: Compare pillar scores to identify areas most in need of investment
- Set Targets: Define target scores for each pillar for the next assessment period
Evidence Requirements
Each claimed maturity level MUST be supported by evidence:
| Evidence Type | Examples |
|---|---|
| Artifacts | Policies, standards documents, prompt repositories, training materials, configuration files |
| Metrics | Dashboard screenshots, trend reports, survey results, ROI calculations |
| Interviews | Structured conversations with developers, managers, champions, and CoE staff |
| Observations | Attending sprint ceremonies, reviewing code review processes, observing training sessions |
| Audit Results | Security audit findings, compliance review results, quality gate effectiveness reports |
Scoring Rules
- A pillar MUST demonstrate all criteria for a level to be scored at that level
- Partial achievement of a level's criteria scores at the level below
- Self-assessment scores SHOULD be validated by an independent reviewer (another team, the CoE, or an external assessor)
- When evidence is ambiguous, score conservatively -- overestimating maturity prevents necessary investment
warning
Maturity assessment is a diagnostic tool, not a grading system. The purpose is to identify where to invest, not to rank or judge. Organizations that use maturity scores punitively will receive inflated self-assessments that hide real gaps.
Benchmarking
Internal Benchmarking
Organizations with multiple teams or business units SHOULD benchmark maturity across internal groups:
- Compare pillar scores across teams to identify best practices and struggling areas
- Investigate why some teams score higher -- is it tools, training, leadership, or culture?
- Use internal benchmarking to set realistic targets based on what peer teams have achieved
- Share specific practices from high-maturity teams with lower-maturity teams
Industry Benchmarking
Where available, organizations SHOULD compare their maturity scores to industry data:
| Maturity Level | Typical Organization Profile |
|---|---|
| Level 1 | Organizations that have not yet formally addressed AI-assisted development |
| Level 2 | Organizations in early adoption, typically within first 2 weeks |
| Level 3 | Organizations with 2-6 weeks of structured AI-assisted development |
| Level 4 | Organizations with 6+ weeks and strong CoE support |
| Level 5 | Industry leaders with 12+ weeks of mature, measured AI-assisted development |
tip
Do not compare your maturity score to vendor marketing claims or conference keynote aspirations. Compare to peer organizations with similar industry, regulatory, and technical complexity. The Center of Excellence SHOULD maintain benchmarking relationships with peer organizations.
Self-Assessment Checklist
Use this checklist for a rapid initial assessment. For each item, indicate whether it is Not Started, In Progress, or Complete.
Engineering Discipline (Pillar 1)
- AI-assisted development workflow is documented (prompting, review, testing, validation)
- Human review expectations for AI-generated code are defined and followed
- AI-assisted changes use consistent validation/test practices before merge
- Teams can identify and explain AI-specific engineering failure modes (hallucinated APIs, edge-case gaps, async/concurrency mistakes)
- Engineering discipline expectations are reinforced in team routines (PRs, reviews, retros)
Governance & Risk (Pillar 2)
- Approved AI tool list exists and is enforced
- Data classification policy addresses AI tool usage
- IP/licensing and provenance expectations cover AI-assisted outputs
- Compliance requirements for AI-assisted development are documented
- Governance reviews/audits are conducted and tracked to closure
Productivity Architecture (Pillar 3)
- Centralized prompt repository exists and is actively used
- Developer workflow patterns are documented
- Toolchain is standardized across teams
- Productivity metrics are collected and reported
- Feedback loops are operational and driving improvements
Operating Model (Pillar 4)
- Sprint ceremonies are adapted for AI-assisted development
- Estimation methodology accounts for AI acceleration variability
- Role definitions reflect AI-augmented expectations
- Change management plan exists and is in execution
- AI Champions are designated and active in teams
Organizational Enablement (Pillar 5)
- Training programs are available for all engineering roles
- AI literacy is widespread across the engineering organization
- Psychological safety for AI experimentation is cultivated
- Center of Excellence is established and operational
- Maturity assessment is conducted regularly
Assessment Cadence
| Assessment Type | Frequency | Conducted By | Purpose |
|---|---|---|---|
| Quick Self-Check | Monthly | Team leads using checklist | Track momentum, identify emerging issues |
| Formal Self-Assessment | Quarterly | CoE + pillar representatives | Comprehensive scoring, gap identification, target setting |
| Independent Assessment | Annually | External assessor or cross-organizational peer | Validation, benchmarking, strategic planning |
Using Assessment Results
Assessment results MUST drive action. The following framework connects scores to priorities:
Gap Prioritization
When multiple pillars have gaps, prioritize based on:
- Foundation First: Engineering Discipline (Pillar 1) and Governance & Risk (Pillar 2) gaps MUST be addressed before optimizing Productivity (Pillar 3) or Operations (Pillar 4)
- Enablement Parallel: Organizational Enablement (Pillar 5) SHOULD be advanced in parallel with all other pillars
- Biggest Gap: Among equally foundational pillars, address the largest gap first
- Quick Wins: If a pillar is close to the next level, a small investment may yield a level advancement
Target Setting
- Set pillar-level targets for the next assessment period (typically one quarter)
- Advancing one level per pillar per year is an ambitious but achievable pace
- Not all pillars need to advance simultaneously -- prioritize based on gap analysis
- Targets MUST be accompanied by specific investment plans (training, tools, process changes, staffing)
danger
Do not set a target of Level 5 across all pillars within the first year. This is unrealistic and will demoralize teams. Set achievable targets, celebrate progress, and build momentum incrementally. Sustainable improvement beats aspirational failure.