Schlagwort: Developer Experience

Veröffentlicht am

Internal Developer Portals 2.0: How AI Copilots Inside Backstage and Port Are Transforming Developer Self-Service

Internal Developer Portals have spent the past three years earning their place in the platform engineering stack. Backstage — now a CNCF Graduated project — established the blueprint: a service catalog, software templates, TechDocs, and a plugin ecosystem exceeding 900 integrations. For many organizations, that was enough. But static catalogs have hit a ceiling. Developers still context-switch between Backstage, Slack, their IDE, and a dozen dashboards to scaffold a service, request infrastructure, or troubleshoot an incident. The portal that was supposed to unify developer experience became just another tab.

2025 and 2026 have introduced a different paradigm: AI copilots embedded directly inside IDPs. Not chatbots bolted onto the side, but intelligent agents that understand your service catalog, your golden paths, and your organizational policies — and let developers interact with infrastructure through natural language instead of form-driven UIs. This is Internal Developer Portals 2.0, and it changes the economics of platform engineering.

From Catalog-Centric to Action-Centric Portals

The first generation of IDPs was catalog-centric. You browsed a list of services, looked up ownership, maybe triggered a pre-built template. The developer experience was better than nothing, but it still required knowing where to click and which template to use. For a senior engineer who helped build the portal, that was fine. For a new hire on day three, it was another maze.

Action-centric IDPs flip the model. Instead of navigating a catalog hierarchy, a developer types:

"Deploy my payment-service to staging with the new database migration"

The AI copilot inside the portal understands the intent, resolves the service from the catalog, identifies the correct deployment pipeline, checks RBAC policies, and either executes or presents a confirmation step. The catalog is still there — it’s the knowledge backbone — but the interaction layer has fundamentally changed.

This isn’t speculative. Port has shipped an AI assistant that queries its internal software catalog and executes self-service actions through natural language. Cortex integrates LLM-driven recommendations directly into its scorecards. Humanitec has taken an API-first approach that makes AI orchestration a first-class integration pattern. Even Backstage itself is seeing community plugins that expose catalog data to AI agents via standardized protocols.

The Knowledge Graph Advantage

What makes IDP-embedded AI fundamentally different from a generic ChatGPT wrapper is context. An Internal Developer Portal already holds a rich knowledge graph:

  • Service dependencies: which services call which, what databases they use, what message queues connect them
  • Team ownership: who owns what, who’s on-call, escalation paths
  • Runbooks and documentation: operational playbooks indexed per service
  • Deployment history: what was deployed when, by whom, with what configuration
  • Scorecards: production readiness, security posture, cost allocation

When an AI copilot has access to this graph, its responses move from generic to surgical. Ask it "Why is checkout-service latency spiking?" and it can correlate recent deployments, check the dependency graph for upstream changes, pull relevant runbooks, and suggest specific remediation steps — all without the developer leaving the portal.

Compare this to ChatOps bots in Slack that operate with minimal context, or IDE-integrated copilots that understand your code but not your infrastructure. The IDP sits at the intersection of code, infrastructure, and organizational knowledge. That’s where AI adds the most leverage.

MCP Servers: The Bridge Between AI Agents and IDP APIs

The technical glue making this possible is increasingly the Model Context Protocol (MCP). Originally open-sourced by Anthropic in 2024 and now seeing broad adoption, MCP provides a standardized interface for AI agents to discover and invoke tools — including IDP APIs.

An MCP server wrapping your Backstage or Port API exposes capabilities like:

  • Querying the service catalog (list services, get owners, check dependencies)
  • Triggering software templates (scaffold a new microservice, provision a database)
  • Reading and updating scorecards
  • Executing self-service actions (deploy, rollback, scale)
  • Fetching TechDocs and runbooks for context

This decouples the AI layer from the IDP implementation. Your platform team maintains the MCP server as a thin adapter. The AI agent — whether it’s embedded in the portal UI, accessible via Slack, or running inside an IDE — connects through the same protocol. You get a single source of truth for what actions are available and what permissions govern them.

For teams already running Backstage, this is particularly powerful. The existing plugin ecosystem handles data aggregation; an MCP server adds an AI-native interaction layer on top without replacing the portal itself.

Scorecards Meet AI Analysis

Scorecards have been one of the quiet successes of the IDP movement. Tools like Backstage (via the Scorecards plugin), Port, and Cortex let platform teams define maturity criteria — production readiness, security compliance, documentation coverage, cost efficiency — and track every service against them.

AI transforms scorecards from passive dashboards into active recommendation engines:

  • Service maturity gaps: „Your order-service scores 62% on production readiness. Adding health check endpoints and configuring pod disruption budgets would bring it to 85%.“
  • Security posture: „Three services in the payments domain are running container images older than 90 days. Here are the specific CVEs affecting them.“
  • Cost optimization: „Based on CPU utilization patterns over the last 30 days, analytics-worker is over-provisioned by 3x. Recommended resource requests: 200m CPU, 256Mi memory.“

The shift is from „here’s your score“ to „here’s what to do about it.“ When combined with self-service actions, the AI can even generate the pull request to implement the recommendation — turning insight into action in a single interaction.

Dynamic Golden Paths: AI-Generated Templates

Golden paths — the blessed, paved roads for common developer tasks — have traditionally been static. Your platform team creates a service template, a database provisioning workflow, a CI/CD pipeline configuration. Developers pick from the menu.

AI-powered IDPs make golden paths dynamic. Instead of maintaining 15 slightly different service templates for different tech stacks and deployment targets, you maintain a smaller set of composable building blocks. The AI assembles them based on the developer’s intent:

"I need a new Go microservice with a PostgreSQL database, deployed to our EU region, with PII data handling compliance"

The copilot generates a tailored template that includes the correct Helm values for the EU cluster, enables encryption-at-rest annotations for PII compliance, configures the appropriate network policies, and sets up the CI/CD pipeline with the required security scanning stages. The golden path isn’t a fixed road anymore — it’s a GPS that calculates the route based on where you’re going.

This has real implications for template maintenance. Platform teams spend significant effort keeping templates current across Kubernetes versions, policy changes, and infrastructure updates. AI-generated templates that compose from maintained primitives reduce that burden substantially.

Incident Response: The Killer Use Case

If there’s a single scenario where IDP-embedded AI proves its ROI overnight, it’s incident response. Consider the typical flow today:

  1. Alert fires in PagerDuty or Opsgenie
  2. On-call engineer opens the monitoring dashboard
  3. Checks recent deployments in the CI/CD tool
  4. Looks up service ownership in the IDP
  5. Searches for relevant runbooks
  6. Correlates with dependency graph to identify blast radius
  7. Begins remediation

Steps 2 through 6 are pure context gathering — and they happen under pressure at 3 AM. An AI agent inside the IDP can perform all of them in seconds:

  • Correlate the alert with the service catalog entry
  • Identify recent changes (deployments, config updates, dependency upgrades)
  • Pull the relevant runbook and highlight the most likely remediation steps
  • Map the blast radius through the dependency graph
  • Suggest or auto-execute a rollback if the confidence is high enough

The on-call engineer still makes the decision, but the mean time to context drops from 15 minutes to 15 seconds. For organizations running hundreds of microservices, that’s not a nice-to-have — it’s a competitive advantage.

Developer Experience Metrics: Measuring What Matters

AI-powered IDPs also change how we measure developer experience. The DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recovery) and the SPACE framework (satisfaction, performance, activity, communication, efficiency) are becoming first-class citizens in IDP dashboards.

The AI layer adds predictive and diagnostic capabilities:

  • Trend analysis: „Deployment frequency for the checkout team has dropped 30% over the past sprint. The primary bottleneck appears to be flaky integration tests in the payment-gateway pipeline.“
  • Correlation: „Teams using the v3 service template have 40% lower change failure rates than those on v2. Consider migrating remaining v2 services.“
  • Forecasting: „Based on current velocity, the platform migration will complete in Q3 — two weeks later than planned. The blocker is database schema migrations for three legacy services.“

This is where platform engineering ROI becomes measurable. When you can demonstrate that AI-assisted self-service reduces time-to-production for new services from five days to four hours, the investment case writes itself.

Backstage’s Plugin Ecosystem vs. AI-Native Platforms

The market is splitting into two camps, and platform teams need to understand the tradeoffs:

Dimension Backstage + AI Plugins AI-Native Platforms (Port, Cortex)
Flexibility 900+ plugins, infinite customization Fewer but deeper integrations
AI integration Community-driven, via MCP/plugins Built-in, first-class AI features
Maintenance burden High (self-hosted, plugin compatibility) Lower (SaaS, managed updates)
Data ownership Full control (self-hosted) Vendor-dependent
Time to value Weeks to months Days to weeks
Vendor lock-in Low (CNCF, open source) Moderate to high
Knowledge graph depth As deep as you build it Pre-built entity models

Neither approach is universally better. If your organization has strong platform engineering capacity and wants full control, Backstage with AI plugins and MCP servers gives you maximum flexibility. If you want faster time-to-value and your team is lean, an AI-native platform like Port gets you to production-grade IDP faster — at the cost of some flexibility and data sovereignty.

ChatOps vs. IDP-Embedded AI vs. IDE Copilots

It’s worth clarifying where IDP-embedded AI fits relative to other AI integration points:

  • ChatOps (Slack/Teams bots): Good for notifications and simple commands. Limited context about your infrastructure. Works well for quick queries but struggles with complex multi-step workflows.
  • IDE-integrated copilots (GitHub Copilot, Cursor): Excellent for code generation. No awareness of your deployment topology, service catalog, or organizational policies. Wrong tool for infrastructure tasks.
  • IDP-embedded AI: Sits at the intersection of organizational knowledge, infrastructure state, and developer workflows. Best for self-service actions, incident response, and cross-cutting concerns that span multiple services.

The ideal setup uses all three — but the IDP is the orchestration layer. Your Slack bot calls the IDP’s AI capabilities through MCP. Your IDE copilot references the service catalog for context. The IDP is the brain; everything else is an interface.

Multi-Tenancy, RBAC, and Governance

Here’s where many early AI-in-IDP implementations fall short: governance. When an AI agent can trigger deployments, modify infrastructure, or scaffold services, you need the same (or stricter) access controls as your existing self-service workflows.

Critical requirements:

  • RBAC for AI actions: The AI copilot should inherit the requesting user’s permissions, not operate with elevated privileges
  • Audit trails: Every AI-initiated action must be logged with the full context — who asked, what was requested, what was executed, what was the outcome
  • Approval gates: Destructive or high-risk actions (production deployments, database migrations, security policy changes) should require human approval, even when AI-initiated
  • Multi-tenancy: In organizations with multiple teams sharing an IDP, AI actions must respect tenant boundaries. Team A’s copilot cannot access Team B’s secrets or deploy to Team B’s namespaces
  • Rate limiting: Prevent AI agents from executing runaway loops of infrastructure changes

Without these controls, you’re trading developer friction for security risk — not a trade worth making.

The Risks: What Can Go Wrong

Let’s be direct about the failure modes:

  • Hallucinated infrastructure configurations: An AI that generates a Kubernetes manifest with incorrect resource limits, missing security contexts, or wrong network policies can cause outages. Every AI-generated configuration must pass through the same validation pipelines (OPA/Kyverno, CI checks) as human-authored configs.
  • Insufficient audit trails: If an AI agent makes a change and the audit log only shows „AI modified resource X,“ you’ve lost forensic capability. Log the full chain: user prompt → AI interpretation → action taken → result.
  • Shadow IT acceleration: If self-service becomes too easy, developers spin up resources without proper tagging, cost allocation, or lifecycle management. AI-powered IDPs need to enforce organizational policies at the point of creation, not after the fact.
  • Over-reliance on AI recommendations: Scorecard suggestions and incident response playbooks should augment human judgment, not replace it. Build a culture where AI recommendations are validated, not blindly accepted.

Getting Started: A Practical Roadmap

If you’re running Backstage today and want to add AI capabilities, here’s a pragmatic path:

  1. Start with read-only: Build an MCP server that exposes your service catalog, scorecards, and documentation to an AI agent. Let developers query the catalog through natural language. Zero risk, immediate value.
  2. Add scorecard analysis: Connect the AI to your scorecard data and let it generate improvement recommendations. Still read-only, but now actively useful.
  3. Enable template generation: Allow the AI to compose software templates based on developer intent. Route the output through your existing PR review process.
  4. Introduce action execution: Wire up deployment, scaling, and provisioning actions with approval gates. Start with non-production environments.
  5. Extend to incident response: Connect alerting systems and let the AI perform context gathering and remediation suggestions during incidents.

Each step builds on the previous one, and each can be rolled back independently. The key is maintaining human oversight throughout — AI copilots augment your platform team, they don’t replace it.

The Bottom Line

Internal Developer Portals 2.0 aren’t about replacing Backstage or rebuilding your IDP from scratch. They’re about adding an intelligence layer that transforms the portal from a passive catalog into an active assistant. The service catalog becomes a knowledge graph. Templates become dynamic. Scorecards become recommendation engines. Incident response becomes proactive.

The organizations that get this right will see measurable improvements in developer productivity, onboarding speed, and operational resilience. The ones that don’t will keep maintaining static portals that developers tolerate rather than love.

The technology is ready. The protocols (MCP) are standardizing. The question isn’t whether AI belongs in your IDP — it’s how quickly you can integrate it without compromising the governance that makes your platform trustworthy.

Veröffentlicht am

The Platform Scorecard: Measuring IDP Value Beyond DORA Metrics

Introduction

You’ve built an Internal Developer Platform. Golden paths are paved, self-service portals are live, and developers can spin up environments in minutes instead of days. But when leadership asks „what’s the ROI?“, you find yourself scrambling for numbers that don’t quite capture the value you’ve created.

DORA metrics—deployment frequency, lead time, change failure rate, mean time to recovery—have become the default answer. But in 2026, they’re increasingly insufficient. AI-assisted development can inflate deployment frequency while masking review bottlenecks. Lead time improvements might come at the cost of technical debt. And none of these metrics capture what platform teams actually deliver: developer productivity and organizational capability.

This article introduces the Platform Scorecard—a framework for measuring IDP value that combines traditional delivery metrics with developer experience indicators, adoption signals, and business impact measures. It’s designed for platform teams who need to justify investment, prioritize roadmaps, and demonstrate value beyond „we deployed more stuff.“

Why DORA Metrics Fall Short

DORA metrics revolutionized how we think about software delivery performance. The research is solid, the correlations are real, and every platform team should track them. But they were designed to measure delivery capability, not platform value.

The AI Inflation Problem

With AI coding assistants generating more code faster, deployment frequency naturally increases. But this doesn’t mean developers are more productive—it might mean they’re spending more time reviewing AI-generated PRs, debugging subtle issues, or managing technical debt that accumulates faster than before.

A platform team that enables 10x more deployments hasn’t necessarily delivered 10x more value. They might have just enabled 10x more churn.

The Attribution Problem

When lead time improves, who gets credit? The platform team who built the CI/CD pipelines? The SRE team who optimized the deployment process? The developers who adopted better practices? The AI tools that generate boilerplate faster?

DORA metrics measure outcomes at the organizational level. Platform teams need metrics that measure their specific contribution to those outcomes.

The Experience Gap

A platform can have excellent DORA metrics while developers hate using it. Friction might be hidden in workarounds, shadow IT, or teams simply avoiding the platform altogether. DORA doesn’t capture whether developers want to use your platform—only whether code eventually ships.

The Platform Scorecard Framework

The Platform Scorecard measures platform value across four dimensions:

┌─────────────────────────────────────────────────────────────┐
│                   PLATFORM SCORECARD                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │   MONK      │  │   DX Core   │  │  Adoption   │        │
│  │ Indicators  │  │     4       │  │   Metrics   │        │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘        │
│         │                │                │                │
│         └────────────────┼────────────────┘                │
│                          ▼                                 │
│                 ┌─────────────┐                            │
│                 │  Business   │                            │
│                 │   Impact    │                            │
│                 └─────────────┘                            │
└─────────────────────────────────────────────────────────────┘
  1. MONK Indicators: Platform-specific capability metrics
  2. DX Core 4: Developer experience measurements
  3. Adoption Metrics: Platform usage and engagement signals
  4. Business Impact: Translation to organizational value

MONK Indicators: Measuring Platform Capability

MONK stands for four platform-specific indicators that measure what your IDP actually enables:

M — Mean Time to Productivity

How long does it take a new developer to ship their first meaningful change?

This isn’t just „time to first commit“—it’s time to first production deployment that delivers user value. It captures the entire onboarding experience: environment setup, access provisioning, documentation quality, and golden path effectiveness.

Level MTTP What It Indicates
Elite < 1 day Fully automated onboarding, excellent docs
High 1-3 days Good automation, minor manual steps
Medium 1-2 weeks Significant manual setup, tribal knowledge
Low > 2 weeks Broken onboarding, high friction

How to measure: Track the timestamp of a developer’s first day against their first production deployment. Survey new hires about blockers. Instrument your onboarding automation to identify where time is spent.

O — Observability Coverage

What percentage of services have adequate observability?

„Adequate“ means: structured logging, distributed tracing, key metrics dashboards, and alerting. If developers can’t debug their services without SSH-ing into production, your platform isn’t delivering on its observability promise.

Level Coverage What It Indicates
Elite > 95% Observability is default, opt-out not opt-in
High 80-95% Most services instrumented, some gaps
Medium 50-80% Inconsistent adoption, manual setup
Low < 50% Observability is an afterthought

How to measure: Scan your service catalog for observability signals. Check for active traces, log streams, and dashboard usage. Automate detection of services without adequate instrumentation.

N — Number of Services on Golden Paths

How many services use your platform’s recommended patterns?

Golden paths only deliver value if teams actually walk them. This metric tracks adoption of your templates, scaffolding, and recommended architectures versus custom or legacy approaches.

Level Adoption What It Indicates
Elite > 80% Golden paths are genuinely useful
High 60-80% Good adoption, some justified exceptions
Medium 30-60% Mixed adoption, paths may need improvement
Low < 30% Teams prefer alternatives, paths aren’t valuable

How to measure: Tag services by creation method (template vs. custom). Track which CI/CD patterns are in use. Survey teams about why they didn’t use golden paths.

K — Knowledge Accessibility

Can developers find answers without asking humans?

This measures documentation quality, search effectiveness, and self-service capability. Every question that requires Slack escalation is a failure of your platform’s knowledge layer.

Level Self-Service Rate What It Indicates
Elite > 90% Excellent docs, effective search, AI-assisted
High 70-90% Good docs, some gaps in edge cases
Medium 50-70% Inconsistent docs, frequent escalations
Low < 50% Tribal knowledge dominates

How to measure: Track support ticket volume per developer. Survey developers about where they find answers. Analyze search query success rates in your portal.

DX Core 4: Measuring Developer Experience

The DX Core 4 framework, developed by DX (formerly GetDX), measures developer experience through four key dimensions:

Speed

How fast can developers complete common tasks?

  • Time to create a new service
  • Time to add a new dependency
  • Time to deploy a change
  • Time to rollback a bad deployment
  • CI/CD pipeline duration

Effectiveness

Can developers accomplish what they’re trying to do?

  • Task completion rate for common workflows
  • Error rates in self-service operations
  • Percentage of tasks requiring manual intervention
  • First-try success rate for deployments

Quality

Does the platform help developers build better software?

  • Security vulnerability detection rate
  • Policy compliance scores
  • Test coverage trends
  • Production incident rates by platform-generated vs. custom services

Impact

Do developers feel they’re making meaningful contributions?

  • Percentage of time on feature work vs. toil
  • Developer satisfaction scores (quarterly surveys)
  • Net Promoter Score for the platform
  • Voluntary platform adoption rate

Adoption Metrics: Measuring Platform Usage

Adoption metrics tell you whether developers are actually using your platform—and how deeply.

Breadth Metrics

  • Active users: Monthly active developers using the platform
  • Team coverage: Percentage of teams with at least one active user
  • Service coverage: Percentage of production services managed by the platform

Depth Metrics

  • Feature adoption: Which platform capabilities are actually used?
  • Engagement frequency: How often do developers interact with the platform?
  • Workflow completion: Do users complete multi-step workflows or drop off?

Retention Metrics

  • Churn rate: Teams that stop using the platform
  • Return rate: Users who come back after initial use
  • Expansion: Teams adopting additional platform features

Shadow IT Indicators

  • Workaround detection: Teams building alternatives to platform features
  • Escape hatch usage: How often do teams need to bypass the platform?
  • Manual process survival: Legacy processes that should be automated

Business Impact: Translating to Value

Ultimately, platform investment needs to translate to business outcomes. The Platform Scorecard connects capability metrics to value through:

Cost Metrics

  • Infrastructure cost per service: Does the platform optimize resource usage?
  • Time savings: Developer hours saved by automation (valued at loaded cost)
  • Incident cost reduction: MTTR improvements × average incident cost
  • Onboarding cost: MTTP improvement × new hire cost per day

Risk Metrics

  • Security posture: Vulnerability exposure window, compliance violations
  • Operational risk: Single points of failure, bus factor for critical systems
  • Regulatory risk: Audit findings, compliance gaps

Capability Metrics

  • Time to market: How fast can the organization ship new products?
  • Experimentation velocity: A/B tests launched, feature flags toggled
  • Scale readiness: Can the organization 10x without 10x headcount?

Implementing the Platform Scorecard

Start Simple

Don’t try to measure everything at once. Pick one metric from each category:

  1. MONK: Mean Time to Productivity (easiest to measure)
  2. DX Core 4: Developer satisfaction survey (quarterly)
  3. Adoption: Monthly active users
  4. Business Impact: Developer hours saved

Automate Collection

Manual metrics decay quickly. Invest in:

  • Event tracking in your developer portal
  • CI/CD pipeline instrumentation
  • Automated surveys triggered by workflow completion
  • Service catalog scanning for compliance

Review Cadence

  • Weekly: Adoption metrics (leading indicators)
  • Monthly: MONK indicators, DX speed/effectiveness
  • Quarterly: Full scorecard review, business impact calculation

Benchmark and Trend

Absolute numbers matter less than trends. A 70% golden path adoption rate might be excellent for your organization or terrible—context determines meaning. Track improvement over time and benchmark against similar organizations when possible.

Presenting to Leadership

When presenting Platform Scorecard results to leadership, focus on:

  1. Business impact first: Lead with cost savings and risk reduction
  2. Trends over absolutes: Show improvement trajectories
  3. Developer voice: Include satisfaction quotes and NPS
  4. Comparative context: Industry benchmarks where available
  5. Investment connection: Link metrics to roadmap priorities

Conclusion

DORA metrics remain valuable, but they’re not enough to measure platform value. The Platform Scorecard provides a comprehensive framework that captures what platform teams actually deliver: developer capability, experience improvement, and organizational value.

The key insight is that platforms are products, and products need product metrics. Deployment frequency tells you code is shipping. The Platform Scorecard tells you whether developers are thriving, the organization is more capable, and your investment is paying off.

Start measuring what matters. Your platform’s value is real—now you can prove it.

Veröffentlicht am

Measuring Developer Productivity in the AI Era: Beyond Velocity Metrics

Introduction

The promise of AI-assisted development is irresistible: 10x productivity gains, code written at the speed of thought, junior developers performing like seniors. But as organizations deploy GitHub Copilot, Claude Code, and other AI coding assistants, a critical question emerges: How do we actually measure the impact?

Traditional velocity metrics — story points completed, lines of code, pull requests merged — are increasingly inadequate. They measure output, not outcomes. Worse, they can be gamed, especially when AI can generate thousands of lines of code in seconds. This article explores modern frameworks for measuring developer productivity in the AI era, separating hype from reality and providing practical guidance for engineering leaders.

The Problem with Traditional Velocity Metrics

For decades, engineering teams have relied on metrics like:

  • Lines of Code (LOC): More code doesn’t mean better software. AI makes this metric meaningless — you can generate 10,000 lines in minutes.
  • Story Points / Velocity: Measures estimation consistency, not actual value delivered. Teams optimize for completing stories, not solving problems.
  • Pull Requests Merged: Encourages many small PRs over thoughtful changes. Doesn’t capture review quality or long-term impact.
  • Commits per Day: Trivially gameable. Says nothing about the value of those commits.

These metrics share a fundamental flaw: they measure activity, not productivity. In the AI era, activity is cheap. An AI can produce endless activity. What matters is whether that activity translates to business outcomes.

The SPACE Framework: A Holistic View

The SPACE framework, developed by researchers at GitHub, Microsoft, and the University of Victoria, offers a more nuanced approach. SPACE stands for:

  • Satisfaction and well-being
  • Performance
  • Activity
  • Communication and collaboration
  • Efficiency and flow

The key insight: productivity is multidimensional. No single metric captures it. Instead, you need a balanced set of metrics across all five dimensions, combining quantitative data with qualitative insights.

Applying SPACE to AI-Assisted Teams

When developers use AI coding assistants, SPACE metrics take on new meaning:

  • Satisfaction: Do developers feel AI tools help them? Or do they create frustration through incorrect suggestions and context-switching?
  • Performance: Are we shipping features that matter? Is customer satisfaction improving? Are we reducing incidents?
  • Activity: Still relevant, but must be interpreted carefully. High activity with AI might indicate productive use — or it might indicate the developer is blindly accepting suggestions.
  • Communication: Does AI change how teams collaborate? Are code reviews more or less effective? Is knowledge sharing happening?
  • Efficiency: Are developers spending less time on boilerplate? Is time-to-first-commit improving for new team members?

DORA Metrics: Outcomes Over Output

The DORA (DevOps Research and Assessment) metrics focus on delivery performance:

  • Deployment Frequency: How often do you deploy to production?
  • Lead Time for Changes: How long from commit to production?
  • Change Failure Rate: What percentage of deployments cause failures?
  • Mean Time to Recovery (MTTR): How quickly do you recover from failures?

DORA metrics are outcome-oriented: they measure the effectiveness of your entire delivery pipeline, not individual developer activity. In the AI era, they remain highly relevant — perhaps more so. AI should theoretically improve all four metrics. If it doesn’t, something is wrong.

AI-Specific DORA Extensions

Consider tracking additional metrics when AI is involved:

  • AI Suggestion Acceptance Rate: What percentage of AI suggestions are accepted? Too high might indicate rubber-stamping; too low suggests the tool isn’t helping.
  • AI-Assisted Change Failure Rate: Do changes written with AI assistance fail more or less often?
  • Time Saved per Task Type: For which tasks does AI provide the most leverage? Boilerplate? Tests? Documentation?

The „10x“ Reality Check

Marketing claims of „10x productivity“ with AI are pervasive. The reality is more nuanced:

  • Studies show 10-30% improvements in specific tasks like writing boilerplate code, generating tests, or explaining unfamiliar codebases.
  • Complex problem-solving sees minimal AI uplift. Architecture decisions, debugging subtle issues, and understanding business requirements still depend on human expertise.
  • Junior developers may see larger gains — AI helps them write syntactically correct code faster. But they still need to learn why code works, or they’ll introduce subtle bugs.
  • 10x claims often compare against unrealistic baselines (e.g., writing everything from scratch vs. using any tooling at all).

A realistic expectation: AI provides meaningful productivity gains for certain tasks, modest gains overall, and requires investment in learning and integration to realize benefits.

Practical Metrics for AI-Era Teams

Based on SPACE, DORA, and real-world experience, here are concrete metrics to track:

Quantitative Metrics

Metric What It Measures AI-Era Considerations
Main Branch Success Rate % of commits that pass CI on main Should improve with AI; if not, AI may be introducing bugs
MTTR Time to recover from incidents AI-assisted debugging should reduce this
Time to First Commit (new devs) Onboarding effectiveness AI should accelerate ramp-up
Code Review Turnaround Time from PR open to merge AI-generated code may need more careful review
Test Coverage Delta Change in test coverage over time AI can generate tests; is coverage improving?

Qualitative Metrics

  • Developer Experience Surveys: Regular pulse checks on tool satisfaction, flow state, friction points.
  • AI Tool Usefulness Ratings: For each major task type, how helpful is AI? (Scale 1-5)
  • Knowledge Retention: Are developers learning, or becoming dependent on AI? Periodic assessments can reveal this.

Tooling: Waydev, LinearB, and Beyond

Several platforms now offer AI-era productivity analytics:

  • Waydev: Integrates with Git, Jira, and CI/CD to provide DORA metrics and developer analytics. Offers AI-specific insights.
  • LinearB: Focuses on workflow metrics, identifying bottlenecks in the development process. Good for measuring cycle time and review efficiency.
  • Pluralsight Flow (formerly GitPrime): Deep git analytics with focus on team patterns and individual contribution.
  • Jellyfish: Connects engineering metrics to business outcomes, helping justify AI tool investments.

When evaluating tools, ensure they can:

  1. Distinguish between AI-assisted and non-AI-assisted work (if your tools support this tagging)
  2. Provide qualitative feedback mechanisms alongside quantitative data
  3. Avoid creating perverse incentives (e.g., rewarding lines of code)

Avoiding Measurement Pitfalls

  • Don’t use metrics punitively. Metrics are for learning, not for ranking developers. The moment metrics become tied to performance reviews, they get gamed.
  • Don’t measure too many things. Pick 5-7 key metrics across SPACE dimensions. More than that creates noise.
  • Do measure trends, not absolutes. A team’s MTTR improving over time is more meaningful than comparing MTTR across different teams.
  • Do include qualitative data. Numbers without context are dangerous. Regular conversations with developers provide essential context.
  • Do revisit metrics regularly. As AI tools evolve, so should your measurement approach.

Conclusion

Measuring developer productivity in the AI era requires abandoning simplistic velocity metrics in favor of holistic frameworks like SPACE and outcome-oriented measures like DORA. The „10x productivity“ hype should be tempered with realistic expectations: AI provides meaningful but not transformative gains, and those gains vary significantly by task type and developer experience.

The organizations that will thrive are those that invest in thoughtful measurement — combining quantitative data with qualitative insights, tracking outcomes rather than output, and continuously refining their approach as AI tools mature.

Start by auditing your current metrics. Are they measuring activity or productivity? Then layer in SPACE dimensions and DORA outcomes. Finally, talk to your developers — their lived experience with AI tools is the most valuable data point of all.

Veröffentlicht am

Internal Developer Portals: Backstage, Port.io, and the Path to Self-Service Platforms

Platform Engineering: The 2026 Megatrend

The days when developers had to write tickets and wait for days for infrastructure are over. Internal Developer Portals (IDPs) are the heart of modern Platform Engineering teams — enabling self-service while maintaining governance.

Comparing the Contenders

Backstage (Spotify)

The open-source heavyweight from Spotify has established itself as the de facto standard:

  • Software Catalog — Central overview of all services, APIs, and resources
  • Tech Docs — Documentation directly in the portal
  • Templates — Golden paths for new services
  • Plugins — Extensible through a large community

Strength: Flexibility and community. Weakness: High setup and maintenance effort.

Port.io

The SaaS alternative for teams that want to be productive quickly:

  • No-Code Builder — Portal without development effort
  • Self-Service Actions — Day-2 operations automated
  • Scorecards — Production readiness at a glance
  • RBAC — Enterprise-ready access control

Strength: Time-to-value. Weakness: Less flexibility than open source.

Cortex

The focus is on service ownership and reliability:

  • Service Scorecards — Enforce quality standards
  • Ownership — Clear responsibilities
  • Integrations — Deep connection to monitoring tools

Strength: Reliability engineering. Weakness: Less developer experience focus.

Software Catalogs: The Foundation

An IDP stands or falls with its catalog. The core questions:

  • What do we have? — Services, APIs, databases, infrastructure
  • Who owns it? — Service ownership must be clear
  • What depends on what? — Dependency mapping for impact analysis
  • How healthy is it? — Scorecards for quality standards

Production Readiness Scorecards

Instead of saying „you should really have that,“ scorecards make standards measurable:

Service: payment-api
━━━━━━━━━━━━━━━━━━━━
✅ Documentation    [100%]
✅ Monitoring       [100%]
⚠️  On-Call Rotation [ 80%]
❌ Disaster Recovery [ 20%]
━━━━━━━━━━━━━━━━━━━━
Overall: 75% - Bronze

Teams see at a glance where action is needed — without anyone pointing fingers.

Integration Is Everything

An IDP is only as good as its integrations:

  • CI/CD — GitHub Actions, GitLab CI, ArgoCD
  • Monitoring — Datadog, Prometheus, Grafana
  • IaC — Terraform, Crossplane, Pulumi
  • Ticketing — Jira, Linear, ServiceNow
  • Cloud — AWS, GCP, Azure native services

The Cultural Shift

The biggest challenge isn’t technical — it’s the shift from gatekeeping to enablement:

Old (Gatekeeping) New (Enablement)
„Write a ticket“ „Use the portal“
„We’ll review it“ „Policies are automated“
„Takes 2 weeks“ „Ready in 5 minutes“
„Only we can do that“ „You can, we’ll help“

Getting Started

The pragmatic path to an IDP:

  1. Start small — A software catalog alone is valuable
  2. Pick your battles — Don’t automate everything at once
  3. Measure adoption — Track portal usage
  4. Iterate — Take developer feedback seriously

Platform Engineering isn’t a product you buy — it’s a capability you build. IDPs are the visible interface to that capability.