DORA’s 2025 State of DevOps Report introduced a fifth accelerate metric: Rework Rate — the percentage of engineering work that is reactive rather than planned. The addition is diagnostic. The teams that DORA classifies as Elite performers on the traditional four metrics (deployment frequency, lead time for change, change failure rate, time to restore) are increasingly distinguishable from High performers not by how fast they ship, but by how much of their work is net-new versus rework.
The 2026 software engineering landscape is defined by a specific set of technology investments that have moved from early adoption to standard expectation — and by a set of widely discussed trends that, under closer examination, are producing adoption numbers without the expected productivity improvement. The gap between the trend map and the outcome data is where most engineering leadership decisions are currently being made poorly.
Platform Engineering: The Adoption Paradox
Platform engineering — creating internal developer platforms (IDPs) that abstract infrastructure complexity behind self-service tooling — has reached 55% adoption across engineering organizations surveyed in the 2025 Puppet State of DevOps and Gartner platform engineering reports. Gartner projects 80% of large software engineering organizations will have dedicated platform engineering teams by 2028.
The paradox: 70% of organizations with platform engineering investments report that their platform is failing to deliver meaningful impact on developer productivity. They have built it; developers are not using it. Or they are using it, but not in ways that reduce friction.
The failure modes that repeat across platform engineering programs:
Building for infrastructure teams, not developers. Platform engineering that optimizes for infrastructure engineer abstractions — Helm charts, Terraform modules, Kubernetes operators — without user research on what developers actually find painful produces platforms that solve problems infrastructure engineers have, not problems developers have. Internal developer portals (Backstage, Port, Cortex) are the emerging solution: building a developer-facing UX layer on top of the infrastructure automation, rather than handing developers YAML interfaces to Kubernetes.
Platform as a forcing function rather than a product. Platform engineering teams that mandate platform adoption — “you must use the platform to deploy” — without making the platform genuinely better than alternatives create developer resistance and shadow IT. Platform engineering done correctly treats developers as customers, measures success by voluntary adoption and self-reported friction reduction, and competes on quality rather than mandates.
Missing the feedback loop. Platform improvements that are not measured cannot be attributed to the platform. Teams that instrument their IDP — tracking developer journey through the platform, measuring time-to-first-deployment for new developers, capturing developer satisfaction via quarterly surveys — produce the feedback that drives prioritization. Teams that build features without measurement cannot identify which features are delivering value.
The platform engineering signal that the data does support: developer onboarding time. Organizations with mature IDPs — where a new developer can go from zero to first deployment in a defined, self-service workflow — consistently report new developer time-to-productivity improvements of 30–50% compared to pre-platform baseline. This is the most validated platform engineering benefit, and it is specific: onboarding, not general productivity.
eBPF: The Observability Substrate That Replaced Everything Else
Extended Berkeley Packet Filter (eBPF) is a Linux kernel technology that allows sandboxed programs to run inside the kernel — in response to network events, system calls, function calls — without modifying kernel source code or loading kernel modules. Its original use case was network packet filtering; its current use cases span observability, security monitoring, and network policy enforcement.
For engineering leaders who have not tracked this: eBPF is no longer emerging technology. It is the production standard for observability and networking at large-scale deployments:
- Cilium (eBPF-based Kubernetes networking and security) is the most downloaded CNI (Container Network Interface) plugin in 2025 and is now the default CNI in AWS EKS, GKE, and AKS managed Kubernetes offerings.
- Tetragon (Cilium’s eBPF-based security observability and enforcement) provides runtime security monitoring — detecting privileged process execution, network connections to unexpected destinations, file access patterns — without agents, sidecars, or application instrumentation.
- Pixie (eBPF-based Kubernetes observability, now CNCF) provides automatic instrumentation of Kubernetes workloads with zero application changes — capturing request/response payloads, latency, error rates, and resource usage — by attaching eBPF programs to system calls.
- Parca (continuous profiling) uses eBPF for always-on, production-safe CPU profiling across an entire Kubernetes cluster without application instrumentation.
The implication for engineering teams: eBPF has resolved the instrumentation tax. The previous model — requiring developers to add metrics, traces, and logs to their applications for observability — created overhead, inconsistency, and coverage gaps (uninstrumented code was dark). eBPF-based observability collects network traffic, system calls, and process behavior at the kernel level regardless of whether application code is instrumented.
For teams still running DaemonSet-based APM agents or relying exclusively on application-level instrumentation: evaluating Cilium + Tetragon + Pixie as the observability substrate replaces three separate agent deployments, eliminates the instrumentation requirement for network-level observability, and provides kernel-level security visibility that application-layer agents cannot achieve.
WebAssembly: The Use Case That Finally Emerged
WebAssembly’s adoption story has been complicated by the gap between its technical capabilities and the use cases that actually reached production. In 2026, the adoption data is more specific: WebAssembly accounts for 5.5% of Chrome page loads where Wasm modules are detected. The use cases where WebAssembly has found production traction:
Compute-intensive browser applications. Video/image processing, audio transcoding, 3D rendering, scientific computing in the browser — tasks where JavaScript performance is insufficient. Figma’s use of WebAssembly for rendering performance is the canonical example: computationally intensive operations compiled from C++ to Wasm run at near-native speed in the browser.
Plugin and extension systems. Envoy Proxy (the Layer 7 proxy that underlies Istio and most service meshes) uses WebAssembly for extending proxy behavior without recompiling the proxy itself. Wasm plugins can be loaded at runtime, run in a memory-safe sandbox, and be written in any language that compiles to Wasm. This pattern — Wasm as a sandboxed extension runtime — is appearing in databases (SingleStore, TiDB), API gateways, and CDN edge compute.
Serverless functions at the edge. Cloudflare Workers uses a V8 isolate model (not Wasm by default), but Fastly’s Compute@Edge and several emerging edge platforms use WebAssembly as the execution model. American Express deployed a Wasm-based function-as-a-service platform in 2025 for latency-sensitive edge compute, citing sub-millisecond cold start as the technical motivation.
The browser migration use case — reusing existing C++/Rust/Go codebases in browser applications without rewriting them in JavaScript — is real but narrower than WebAssembly proponents initially claimed. Most applications do not have existing C++ codebases worth porting, and the debugging and tooling experience for Wasm in the browser remains rougher than native JavaScript development.
The teams where WebAssembly investment is justified: those building compute-intensive browser applications, those building plugin systems that need sandboxed extensibility, and those building edge compute applications where cold start time is a hard constraint.
Team Topologies: The Organizational Model That Hardened
Matthew Skelton and Manuel Pais’s Team Topologies framework — defining four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes (collaboration, X-as-a-service, facilitating) — has moved from a book recommendation to an organizational design standard at mid-to-large engineering organizations.
The 2026 state of Team Topologies adoption: organizations that implemented the framework formally report clearer ownership, fewer handoff failures, and better alignment between team structure and architectural boundaries. The inverse — Conway’s Law playing out negatively, where team structure creates unwanted architectural coupling — is better understood and more deliberately managed.
The hardening that has occurred in 2025–2026:
Platform team vs. shared services team distinction. Organizations that renamed existing shared services teams as “platform teams” without changing their operating model — still taking project requests, still operating as a dependency rather than a product — did not get platform engineering benefits. The team topology distinction is operating model, not name.
Stream-aligned team full ownership. Stream-aligned teams that own a service or product area but rely on operations, security, or data teams for common functions retain handoff dependencies that slow delivery. The full-stack ownership model — where stream-aligned teams own their service from code to production, including monitoring, on-call, and database schemas — produces faster iteration at the cost of requiring more senior engineering investment per team.
Cognitive load as a design constraint. The Team Topologies insight that team design should be constrained by cognitive load — that a single team cannot meaningfully own too large a domain — is increasingly used as the justification for extracting services when a team’s domain has grown beyond what a stable team can maintain quality on. This is more defensible than “microservices are better” as a justification for service extraction.
The DORA Rework Rate: What It Actually Measures
DORA’s addition of Rework Rate as a fifth metric in 2025 reflects a specific observation from the dataset: Elite teams on the traditional four metrics were not uniformly improving on the most important outcome metric — the ability to deliver what customers need rather than to deliver and then fix it.
Rework Rate measures the proportion of engineering work that is reactive: bug fixes to recently deployed features, reverting changes, responding to incidents caused by recent deployments. The inverse — the proportion of work that is planned feature development — is a proxy for sustainable delivery velocity.
The benchmark data: Elite-performing organizations have Rework Rates below 15% (less than 15% of engineering work is reactive). Medium performers are at 25–35%. Low performers are above 40% — meaning almost half of engineering work is responding to problems created by previous work.
The engineering practices that most strongly correlate with low Rework Rate in the DORA dataset:
Trunk-based development. Teams shipping to main daily, with feature flags for work-in-progress, have lower Rework Rate than teams using long-lived feature branches. The mechanism: smaller, more frequent integrations catch conflicts and regressions earlier, when they are cheaper to fix.
Comprehensive automated testing with fast feedback. Teams with test suites that run in under 10 minutes and block merges on failure have lower Rework Rate than teams with slow or non-blocking tests. The feedback loop speed determines how quickly defects are caught before they become customer-visible incidents.
Progressive delivery. Canary releases, percentage-based rollouts, and feature flag-controlled releases reduce Rework Rate by limiting blast radius: when a release causes problems, the rollback scope is smaller, the detection is faster (monitoring on a small percentage of traffic), and the incident response is less disruptive than a full rollback.
The Trends That Haven’t Delivered
For completeness: the trends with sustained investment that have not produced the expected outcomes at most organizations:
ChatOps as incident response. Runbooks-as-chatbot interfaces and incident response through chat automation have been piloted extensively and adopted narrowly. The friction of structured chat-based workflows does not match the improvised, high-pressure nature of production incidents at most organizations. The teams that use ChatOps effectively are those who built tools specific to their exact incident patterns, not those who deployed general-purpose ChatOps platforms.
AI-driven sprint planning. Tools that automatically generate sprint plans, estimate story points, or allocate work across engineers based on historical velocity have been adopted by a subset of engineering managers and quietly disabled at most of them. The insight that planning requires context — on team capacity, morale, dependencies, and strategic priorities — that AI tools cannot access without being deeply integrated into team workflow has reasserted itself.
Platform-independent developer experience (DevEx) scores. Quantitative developer experience scoring systems (SPACE framework implementations, custom developer NPS programs) have been implemented at many organizations and have driven few actual improvements. The gap is between measuring developer sentiment and knowing which investments will improve it. The organizations that have improved developer experience have done so by talking to developers, not by scoring them.
How we approach this at Insoftex
Engineering practices at Insoftex reflect the same evidence base: we apply what the data shows works, not what the conference circuit currently promotes.
For clients evaluating platform engineering investments, we scope the IDP against actual developer pain points — using structured developer interviews before any tooling selection — because the most common platform engineering failure is building the wrong abstraction. For clients concerned about AI tool adoption producing quality debt, DORA’s Rework Rate framework gives us a measurement approach that captures the effect before it becomes a production incident pattern.
The software engineering trends that matter in 2026 are the ones with measurable outcomes in production systems. Platform engineering that developers actually use. eBPF-based observability that provides coverage that agent-based approaches cannot. Team structures that match cognitive load to domain complexity. These are specific and testable, not aspirational.
Evaluating your engineering organization’s practices, measurement framework, or platform engineering investment? Our Product Pilot includes an engineering maturity assessment benchmarked against DORA metrics — identifying which investments will move your Rework Rate, deployment frequency, and lead time in the next quarter.