In this episode of Engineering Enablement, I talk with Andrew Swerdlow, VP of Engineering at Roblox, about how the company is building trust in AI agents to review, test, and deploy code autonomously. Andrew explains how Roblox turns past code review feedback into rules for agents and why engineering is shifting toward specifications and intent. We explore what that means for the skills engineers need, how Roblox measures AI’s impact on productivity, and how it manages costs. We also discuss the guardrails needed to let agents safely ship code with minimal human intervention.

Some takeaways:

Building trust in autonomous development

• Generating code is no longer the biggest bottleneck. Code review, testing, and deployment still slow delivery. Realizing AI’s full potential requires automating more of the software development lifecycle.

• Autonomy has to be earned through trust. Strong testing infrastructure, production canaries, and automated rollback capabilities are essential for allowing agents to operate independently.

Organization-specific rules lifted AI review acceptance to nearly 70%

• Generic AI models lack organization-specific knowledge. Companies need ways to capture their internal engineering practices and make that information available to agents.

• Code review comments are a valuable source of institutional knowledge. Roblox mines historical feedback to create rules called exemplars that guide AI-generated code and code reviews.

• Organization-specific guidance makes AI code review more effective. Roblox’s AI-generated review comments now have an acceptance rate of nearly 70%, compared with 50–55% for human-written comments.

Humans approve the rules, and about 5% of PRs auto-merge

• Human judgment is shifting from reviewing individual changes to defining the rules. Engineers can establish and approve guardrails that allow AI to review code without requiring constant human intervention.

• Roblox is already allowing some code to reach production autonomously. About 5% of PRs are automatically merged after passing AI code review, programmatic safety checks, and risk assessments.

Intent, specs, and judgment are becoming the core engineering skills

• Engineering work is shifting from code toward intent, architecture, and specifications. As agents handle more implementation details, engineers will increasingly collaborate on higher-level designs.

• Experience and judgment remain essential. Senior engineers are often better equipped to challenge AI-generated solutions and anticipate problems with scalability, maintainability, and system design.

• Engineering interviews may need to evaluate process rather than just results. How efficiently candidates use AI, develop specifications, and arrive at solutions could become more important than traditional coding exercises.

Roblox tracks accepted, rolled-back, and unattended code

• The amount of AI-generated code is becoming a less meaningful metric. What matters is whether that code survives in production, delivers value, and requires less human intervention.

• Roblox is experimenting with new measures of productivity. Agent autonomy, feature velocity, and developer sentiment help reveal whether AI tools are genuinely improving engineering outcomes.

Session tracing and caching are the main levers on AI cost

• Observability is essential for understanding AI costs and waste. Roblox tracks agent sessions, token usage, and code outcomes to identify inefficient workflows and opportunities for improvement.

• The right infrastructure can dramatically reduce costs. Roblox reduced the cost of individual code review rule evaluations by 90% through caching and shared context.

• Flexibility matters in a rapidly changing AI landscape. Rather than building every capability internally or committing to one vendor, Roblox supports multiple models and tools so engineers can adopt the most effective solutions.

In this episode, we cover:

(00:00) Intro

(02:20) Building trust in AI across the software development lifecycle

(04:44) When human oversight helps and when it gets in the way

(06:50) What AI agents need to know about your organization

(08:45) How Roblox turns engineering knowledge into rules for AI agents

(12:40) How AI code review compares to human code review

(14:59) Capturing engineering knowledge beyond documentation

(18:14) How AI changes what engineers need to understand

(20:17) The shift to spec-driven development

(23:24) How AI changes how we evaluate engineers

(26:33) Rethinking engineering interviews in the age of AI

(28:23) How Roblox tracks AI-generated code

(35:56) Model routing and choosing the right AI tools

(39:50) Measuring AI’s impact on engineering productivity

(44:44) Optimizing AI costs at scale

(48:12) Builders at Roblox and the future of software engineering

(50:19) Building trust in autonomous code review

(53:11) The cultural shift toward autonomous engineering

Where to find Andrew Swerdlow:

• LinkedIn: https://www.linkedin.com/in/andrewswerdlow/

• X: https://x.com/andrewswerdlow

• Website: https://andrewswerdlow.net

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• CAFE(S): Your Agent Is Only as Good as Its Context

• Roblox

• Tech Leadership by Andrew Swerdlow

• Margaret-Anne Storey

• Malte Ubl - Vercel | LinkedIn

• Grafana Labs

• Kushan Mehta | LinkedIn

• Diff Risk Score: AI-driven risk-aware software development - Engineering at Meta

Subscribe now

DX’s Q3 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.

Scott: One of the most pervasive myths of the software industry is the existence of a 10x developer. And just when we thought we had debunked the idea of a lone wolf coding maestro delivering at 10 times the rate of their colleagues, AI coding assistants appeared, promising 10x gains for anyone willing to master the tools.

Back in March, Venkat Venkataramani, VP of application infrastructure at OpenAI, told LeadDev that “there are easily 1,000x engineers now. I don’t even know if that’s the limit. There may be 1,000,000x engineers coming.” I thought this was a neat piece of marketing for their own Codex tools, but yet again this narrative misses a core principle of software engineering work: that at almost every professional level, building and shipping software is a team sport.

Picking up on this theme, our Field CTO Justin Reock is kicking off a three-part series this week, adapted from his talk: Building 10x Organizations with Modern Productivity Metrics. Over to you, Justin.

Justin: I’m going to start by going back to where the pervasive 10x developer idea actually came from.

The 10x developer is one of the most repeated and least understood ideas in our industry. It’s used to justify hiring decisions, set compensation bands, and influence entire management philosophies. But the source material, a 1968 study called “Exploratory experimental studies comparing online and offline programming performance” has been largely debunked when looking at individual developers working within a team or organization.

This pivot originated from a study called “the Coding War Games,” run by software researchers Tom DeMarco and Tim Lister starting in 1984, which would form the backbone for their influential book “Peopleware: Productive Projects and Teams.”

More than 600 developers across almost 100 companies were asked to perform the same business task using code in their normal workflow, and asked to measure the time it took to complete the task, as well as defect rates. The spread between the fastest and slowest performers was 11.1x, and that single number contributed to the 10x developer myth.

Here’s what almost everyone gets wrong about that finding. The 11.1x spread did not cluster by individual talent, it clustered by company. When DeMarco and Lister grouped participants by employer, the top-performing companies were dramatically faster and produced dramatically fewer defects than the bottom-performing companies, and the gap inside any one company was narrow: only about a 21% difference in productivity between engineers working in the same organization.

Years of experience, salary, and tenure barely predicted performance. The environment did. A quiet workspace, freedom from interruption, and the ability to reach and maintain flow state were the variables that moved the needle.

The top performers (middle column below) differed dramatically in their responses to questions about their working environment, and ultimately, their developer experience:

• Top performers had almost twice as much dedicated working space.

• Nearly twice as many of the top performers reported that it was acceptably quiet.

• Three times as many top performers reported that it was acceptably private.

• Five times as many top performers were allowed to silence their phones (equivalent to Teams, Slack, etc. today), and three times as many were allowed to divert their calls.

• Twice as many low performers indicated that they were often interrupted needlessly.

That’s the inversion I want to focus on. The idea of 10x developers, in the way most people use the phrase, are largely fictional. However, 10x organizations are real, measurable, and reproducible. The conditions that produce them are knowable. We’ve just spent forty years optimizing the wrong variables.

Why this keeps mattering

Every few years, our industry rediscovers developer productivity, gives it a new name, and proceeds as if no one has thought about it before. I sometimes call this YAPP: Yet Another Productivity Philosophy. Agile is YAPP. DevOps is YAPP. Platform Engineering is YAPP. AI-assisted engineering is the current YAPP.

Each one arrived with the implicit claim that the previous philosophy got it wrong. Each one ended up rediscovering the same underlying truth that DeMarco and Lister already had data for in 1984. It was already substantiated by the work of W. Edwards Deming, who famously said:

“90-95% of the productivity of an organization is determined by the system and not the worker.”

Most of the variance in developer output, even with AI augmentation, is not about the developer,it’s about friction. It’s about how many times a day someone gets interrupted, how long the builds or tests take, how quickly a review is turned around, how confident they feel deploying on a Friday afternoon, whether the test suite is trustworthy, and whether they spend their week on work they consider meaningful.

What the 10x organization actually looks like

A few patterns appear consistently across the highest-performing engineering organizations I’ve worked with at DX, and they map cleanly onto what the original Coding War Games found.

The first is protected focus time, with emphasis on “protected.” The top performers in the 1984 study had quiet, defensible workspaces. The 2026 equivalent is meeting load, notification load, and the structural ability to spend two-to-four hours on a single problem without context-switching. Engineers at 10x organizations report meaningfully more deep work hours per week than engineers at median organizations, and the gap is not small.

The second is a smooth and efficient inner loop. The inner loop is everything a developer touches between writing a line of code and getting feedback on it: editor, local build, local test, local run. When the inner loop is fast and reliable, developers stay in flow. When it’s slow or flaky, every change becomes a context switch.

The third is trust and psychological safety. The Coding War Games organizations that performed best gave their engineers real latitude over how the work got done. That hasn’t changed. Teams that can experiment in safe-to-fail environments, work with AI without fear of displacement, and understand the worth of the value they create for the organization consistently outperform teams that can’t. This would be validated in Google’s Project Aristotle, which valued psychological safety as a critical component of developer experience, and a strong leading indicator of team productivity.

Where this series is going

Next week, in part two, I’ll get into the measurement problem this exposes.

We have four established frameworks for measuring developer productivity now: DORA, SPACE, DevEx, and the DX Core 4. Each one was a response to progress and evolution in productivity theory. Understanding why they evolved makes it easier to understand how to apply them to your organization.

Then, in part three, I’ll get specific about what a measurement program actually looks like when it’s deployed at scale, and how to keep them from collapsing into a single-metric trap.

One more thing

We published an article about how the travel booking company trivago is attempting to 10x its organization with AI tooling. One of the big wins was consolidating usage data across multiple AI coding tools into one dashboard to evaluate how different developer cohorts leverage AI, and then scaling the approaches that work best.

Read more

That’s it for this week. Thanks for reading.
-Justin

Subscribe now

DX’s Q3 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.

Scott: I’ve been sensing a real anxiety amongst developers over the past year or so around skill and knowledge atrophy. We know that AI tools like Cursor and Claude make developers faster – or at least feel faster – but at what cost?

Brian and his fellow researchers have now given that anxiety a name: the hollow orchestrator. A developer can easily find themselves approving more work each month, without becoming better equipped to judge it.

To dig into that trend and more findings from his latest study into how AI is impacting 331 developers at Microsoft, I’ll hand things over to Brian.

Brian: When factories were first electrified, almost nothing happened. Owners pulled the steam engine out, dropped an electric motor in its place, and left the machines where they were, still arranged around the old central driveshaft. Productivity barely moved, for decades. The payoff came later, once the work itself had been rebuilt around what electricity could actually do, with a small motor on every machine, instead of one dynamo turning the whole floor.

I found myself thinking about that period when looking at our Q3 State of AI Impact in Engineering. Drawing on data from more than 500 engineering organizations, it’s clear that the engine is spinning faster. Median weekly PR Throughput grew 75.5% over the last four quarters. But that doesn’t mean we’re delivering more value. In fact, the share of time going to new capabilities rather than maintenance and support, rose just two percentage points, from 57% to 59%.

Our speed metrics don’t tell us what work has become possible that wasn’t before. A task we regularly do can get faster with AI. But, a task can also become cheap enough to attempt for the first time. Those are very different kinds of gains.

To explore that distinction, I teamed up with researchers at Microsoft and Oregon State University: Rudrajit Choudhuri, Jenna Butler, Christian Bird, Carmen Badea, Anita Sarma, and I invited 4,000 randomly sampled Microsoft developers to participate in a study. We analyzed 331 responses, which became the basis for our new paper.

We asked developers a seemingly simple question: Is there anything you can now do at work because of AI that you couldn’t do before?

Their answers were then sorted into three zones:

Faster was familiar work like writing documentation or authoring tests, just now done more quickly. 45% of the responses fit into this bucket.

Further was work that had been out of reach, either because it needed skills or capacity the developer didn’t have, or because it was never worth the effort. 36.9% of tasks landed here.

Afresh was work that didn’t exist before, largely built around directing agents and setting the standards their output has to meet. That accounted for 12.4%. The remaining 5.7% named no specific task.

These zones are not invisible to our dashboards. A feature that was previously out of reach can still produce pull requests. A new agent workflow can still have a cycle time.

What those measures don’t tell us is whether we accelerated familiar work, made something previously impractical worth doing, or created a new kind of engineering responsibility. We can count the output without understanding what AI changed.

Faster: familiar work, accelerated

The Faster accounts were largely unsurprising, and several were refreshingly blunt about it.

“I could do everything I currently do without AI; however, I can do my work faster“ (P5).

Documentation drafted in minutes, root cause analysis under pressure, test coverage in an afternoon. What caught my attention in this zone wasn’t the speed. It was the reorganization around the speed.

“I used to only do one thing at a time. But now I will do two or three while waiting for AI to respond to each problem“ (P274).

Faster implementation still has to get through review, testing, and delivery. Those constraints remain important. But some developers described the work they could now do that they would never previously have attempted, either because they didn’t have the time, or skills to do it.

Further: the work that used to be out of reach

For engineering leaders struggling to articulate the return on investment from an exponentially increasing token spend, this is a good place to start.

About 24% of responses described working past a limit the developer had before AI. As one back-end engineer told us:

“I can cover end-to-end now. Previously, I was limited to only the backend“ (P28).

Another 12.7% of all responses described work developers could have done, but could never justify doing.. One response lays the economics out completely:

“I recently automated [a task] in an hour that saved me 80 hours of manual work. I never would have done those 80 hours, so those items would never have been updated. Writing the automation without AI would have probably taken me 30 hours, which would still have been too hard to justify the investment.“ (P197)

No one reclaimed 80 hours, because no one was going to spend them. The gain was getting useful work done that would otherwise have stayed undone. This is an entirely different kind of productivity gain. We tend to measure how much work gets done, or how quickly it gets done, but rarely ask what work has become worth doing in the first place. A maintenance task that was too expensive to justify yesterday might suddenly be worthwhile today. And that’s a benefit our traditional productivity measures don’t necessarily help us recognize.

Afresh: new work created around AI

The smallest zone, 12.4% of responses, captures new responsibilities emerging around AI tools. Supervising agents and building context management systems for them are examples of tasks that never existed before AI. For leaders tasked with AI transformation, these tasks offer a useful glimpse of how the work itself is changing.

Some of it is role change: “My role has shifted from executing every step myself to orchestrating work streams and evaluating outcomes” (P116). On one team, “more than 90% of the code is AI-written. We act as a protective layer, as a manager of agents” (P114).

Just because an agent stops working does not mean the task is finished. Maybe the agent got stuck, maybe it didn’t know what “done” looked like, maybe it misunderstood the assignment completely. As one respondent put it, “Right now AI sort of just stops. There’s some probabilistic mechanism that determines it is time to await a human reply.” Developers described building tools to check an agent’s output against explicit criteria for a completed task. That shifts some of their work from producing the implementation to defining what “done” means and checking whether the agent actually got there.

Developers are also building tools to make AI’s output easier for people to evaluate. One participant was working on a tool to break large code changes into “smaller logically-grouped chunks” (P316). Rather than expecting someone to make sense of a 90-file pull request all at once, the tool would organize related changes for review. The new work is not simply reviewing more code. It’s building tools that make large, agent-generated changes easier to review.

This is the work around AI, not simply work handed to AI. Someone has to define what good looks like, recognize when an agent has missed it, and build the context and checks that make the next attempt better. Some of this is opportunity. Some is the cost of making AI useful. But as AI expands what developers can do, how do we make sure their judgment keeps up?

Two learners, one loop

Across all three zones, developers described learning from AI while also teaching it how their work should be done. They used it to take on unfamiliar problems, then captured their own expertise in specifications, examples, tests, and standing instructions.

Drawing on Vygotsky’s zone of proximal development, we describe this as two-way scaffolding. The developer builds understanding and the agent benefits from better guidance in subsequent work. It’s not that every interaction retrains the model, but context can improve, use cases sharpen, and skills develop.

The focal point is what we call the skill–judgment nexus. AI can provide skills beyond what it can reliably judge, and developers must bridge that gap with their own judgment. As AI’s capabilities expand, developers need to grow their judgment alongside them.

When a developer takes the time to understand a solution, they become better able to judge the next attempt. When they capture what good looks like, subsequent agent work can benefit from that guidance. That is the loop we want to support: greater capability accompanied by growing judgment, rather than increasing dependence.

The hollow-orchestrator

The loop can also stall. A developer may approve more work each month without becoming better equipped to judge it. We describe the risk as becoming a hollow orchestrator. It’s the state of keeping responsibility for work you can no longer reliably understand.

One participant described their domain knowledge as “the bulwark against fabrications or hallucinations impacting my work,” but worried that “as my own domain knowledge gets stale, the chances that I miss something increase” (P320).

The uncomfortable part is how slowly this might happen. Speed metrics won’t catch it. They’ll look good right up until they don’t.

Which is why I treat quality as a guardrail, and why one small number in last week’s Q3 report has my attention. Change failure rate had been largely flat over the last year, but the median quarter-over-quarter change increased by roughly +0.5 percentage points from Q2 to Q3 this year. That’s a relatively small movement, and there are many possible explanations. But it’s the number I’ll be watching most closely next quarter.

We don’t have evidence that declining developer judgment is behind this increase. But as AI takes on more of the work, our ability to recognize and prevent failures becomes increasingly important. If that ability starts to erode, we need measures that help us recognize it before the consequences compound.

Capacity bought by eroding judgment is borrowed from next year.

Where to start

There’s two things you can do here, one is cheap and one is harder.

Ask your developers whether there is anything they can now do at work because of AI that they couldn’t do before. Use the three zones as a lens to view their answers, then ask what made the work possible and why it is valuable. Ask again in six months to see how those experiences are changing. The goal isn’t to move everyone toward the afresh zone; it is to understand what AI is changing about the work.

The harder one is protecting the loop. The paper lays out nine scaffolding functions adapted from the tutoring and cognitive apprenticeship literature. Three are worth calling out here:

• Show, don’t just instruct. “Handle errors better” tells an agent almost nothing. A pair of examples, one that meets your team’s standard and one that nearly does, tells it where the line actually falls.

• Size delegation to what you can verify. Split work so the part you hand over matches the part you can check. The failure mode is delegating more than you can verify, then signing off because you assume the agent got it right, not because you’ve verified the result.

• Judge AI’s work against an independent standard. Use requirements, tests, evaluations, and reviewers to challenge the result. A different model can help, but another agent agreeing is not enough. The checks still need to establish whether the work meets the intended behavior.

Final thoughts

I don’t think we need to stop measuring speed. I think we need to stop relying on it to explain everything. Faster describes familiar work accelerated. Further asks what has become possible. Afresh makes visible the new responsibilities involved in working with AI models. Together, they give us a better set of questions, not a replacement productivity score.

Those questions belong alongside another: are developers building the judgment to sustain their expanded reach? It’s possible to become more capable with AI without becoming more capable of evaluating what it produces. The paper’s two-way scaffolding practices are intended to help close that gap.

The factory owners couldn’t have told you everything electricity would eventually make possible, in the same way that I can’t tell you what AI will. But we can ask about more than the speed of our existing work.

As we continue in our AI transformation journeys, it’s not “how much faster are our developers with AI?” but “what can this organization do now that it couldn’t before, and are we building the judgment to keep doing it?”

One more thing

We just published an article about how the travel booking company trivago is attempting to 10x its engineering team with AI tooling. One of the big wins was consolidating usage data across multiple AI coding tools into one dashboard to evaluate how different developer cohorts leverage AI, and then scaling the approaches that work best.

“Anyone can maximize token usage. We wanted to maximize output. DX moves us from counting tokens to counting outcomes: pull requests shipped, cycle time, review load, so productivity gains show up in what we ship, not just in what we spend,” Carolina Muradas, Strategy and Operations Lead at trivago, said.

Here’s all the details.

Share

As AI agents become more capable, context quality is increasingly the limiting factor in their performance. In this episode of Engineering Enablement, I’m joined by my CAFE(S) co-authors Max Kanat-Alexander (Capital One), Eirini Kalliamvakou (DX), and Margaret-Anne Storey (University of Victoria) to introduce our framework for evaluating whether agents have the context they need to do their jobs well.

We introduce the five dimensions of CAFE(S): Clarity, Actionability, Fidelity, Efficiency, and Security. We walk through common context failures, how poor context accrues technical and cognitive debt, what it costs in developer productivity and operating spend, how AI is changing the skills engineers need, and why context review could become as important as code review.

Some takeaways:

Why context quality matters for AI agents

• Improving models and harnesses isn’t enough to maximize AI agent effectiveness. The quality of the context agents receive is just as important, yet organizations rarely evaluate it systematically.

• Poor context creates compounding costs and risks. Ambiguous instructions, irrelevant information, and insecure context can lead to runaway token usage, incorrect outputs, security breaches, and additional developer toil.

The five dimensions of the CAFE(S) framework

• CAFE(S) defines five properties of high-quality context: clarity, actionability, fidelity, efficiency, and security. Each addresses a distinct failure mode and helps identify where context needs improvement.

• Clarity may be the most important dimension because ambiguity is often invisible to the person providing instructions. Agents can’t reliably infer unstated assumptions, and an incorrect interpretation can compound throughout a task.

Why model failures are often context failures

• Agents frequently make mistakes because critical knowledge exists only in developers’ heads. Without documented requirements, constraints, and decisions, agents may build unwanted features or take actions that conflict with the team’s intent.

• Security failures can stem from giving agents access to information they shouldn’t have. One real-world example involved an agent finding an unrelated API credential and deleting a production database.

How poor context contributes to technical, cognitive, and intent debt

• Undocumented goals, constraints, and decisions create intent debt that can become more costly with AI agents. Agents need access to the reasoning behind decisions, including what a system should not do.

• Better context can help prevent debt, but successful agent workflows can also encourage complacency. Teams may stop documenting important decisions when agents appear to be working well.

Creating high-quality context is becoming a core engineering skill

• AI fluency involves learning to anticipate what agents need rather than correcting mistakes after they happen. More experienced developers proactively define goals, constraints, and success criteria based on lessons from previous failures.

• Skills traditionally associated with senior engineers may become essential at every level. Clearly communicating intent and requirements has long been part of senior engineering roles, but AI agents are making those skills increasingly important for all developers.

Why context review could become as important as code review

• Shared context deserves more scrutiny because its effects multiply across agent interactions. A mistake in a widely used instructions file can be repeated in every session, while an improvement can make every agent more effective.

• Context review should be proportional to the importance and reach of the information. Critical shared instructions may need formal review, while lightweight documentation updates should remain easy to make.

• Reviewing context can also build shared understanding across engineering teams. Like code review, the process can help developers align on requirements, decisions, and the intended behavior of their systems.

In this episode, we cover:

(00:00) Intro

(01:18) Meet the CAFE(S) authors

(03:13) Introducing CAFE(S): Why context quality matters

(06:32) Common context failure modes

(08:30) The five dimensions of high-quality context

(12:33) When model failures are actually context failures

(18:24) Why the panel prioritizes clarity in CAFE(S)

(22:34) How context quality relates to technical, cognitive, and intent debt

(25:35) How human interventions reveal context failures

(28:11) How context quality relates to AI fluency

(30:28) How AI is changing what makes a good engineer

(33:48) The case for context review as a discipline

(38:44) Wrap-up

Where to find Margaret-Anne Storey:

• LinkedIn: https://www.linkedin.com/in/margaret-anne-storey

• X: https://x.com/margaretstorey

• Website: https://margaretstorey.com

Where to find Max Kanat-Alexander:

• LinkedIn: https://www.linkedin.com/in/mkanat

• X: https://x.com/mkanat

• Website: https://www.codesimplicity.com

Where to find Eirini Kalliamvakou:

• LinkedIn: https://www.linkedin.com/in/eirini-kalliamvakou-1016865

• X: https://x.com/irina_kAl

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• CAFE(S): Your Agent Is Only as Good as Its Context

• Nicole Forsgren

• The Productivity-Experience Paradox - Annie Vella

• Startup Studio

• From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI

• The AI-native developer

• CodeScene

Subscribe now

Today, we published our Q3 State of AI Impact in Engineering Report, with new data on how AI coding tools continue to shift the role of software engineers.

This is the first time I have felt closer to answering a nagging question: If AI is making engineers more productive, where does that earned time go?

Our data suggests that the answer largely is on maintenance and fixes, yet satisfaction with code maintainability tasks only improved by 0.6% this quarter. Which brings me to another question: why? Is it because the AI tools we have today are uniquely suited to these tasks, or is that just where most of us decided to point them first?

To dig into that question, and a few others, I’ll hand over to , the report’s author, to talk you through some of those key findings.

Grace: In my experience, the adoption of digital tools follows a familiar arc. Initial excitement leads to significant early gains, followed by a flattening of value recognition as bottlenecks appear elsewhere. Looking at our Q3 State of AI in Engineering report, I was fully anticipating some kind of plateau.

The data surprised me. Median weekly TrueThroughput, our complexity-weighted PR throughput metric, is still climbing, up 75.5% over the last four quarters. Velocity isn’t showing any signs of slowing down. What is struggling to keep up is the rest of the SDLC – the review, testing, and verification that turn code into something a team can trust.

Review capacity is a confirmed bottleneck

In Q3 2026, organizations reporting the highest AI code volume waited 105% longer for a first review than those with the lowest.

PR size seems to be a big part of the picture. Median PR size is up 122% year over year, so there’s simply more code to reviewWhat our data can’t tell us is whether something else is going on, and our team has two theories.

The first is that AI-generated changesets take more effort to review, which ties up reviewers and pushes everything else back in the queue. The second is that reviewers hesitate to pick up large, unfamiliar, or AI-generated diffs because of the cognitive friction and the fear of missing a non-obvious bug, which delays the first review directly.

Individual relief versus systemic friction

Developers are telling us that AI is making parts of their work meaningfully better. Our data tells us where the relief is concentrated. We measure this through the Developer Experience Index (DXI), and the figures below are quarter-over-quarter changes in the factors that make it up.

While all factors saw increases from last quarter, these comparisons capture a small point in time, and small shifts at this granularity can look more meaningful than they are. These gains should be read as directional rather than as evidence of a sustained trend until they hold across additional quarters.

Satisfaction with isolated, diagnostic tasks has risen – production debugging is up 13.3% and documentation is up 10.4%. These tasks have clear inputs, verifiable outputs, and short feedback loops, tasks that AI tools typically perform well on.

The smallest gains are in the tasks that require holding a whole system in view. Code maintainability (+0.6%), clear project direction (+2.0%), and the end-to-end experience of moving code safely into production, measured as perceived ease of delivery, improved by only 3%. AI is seeming to help developers navigate existing points of friction faster, but not able to remove more complex systemic friction.

The innovation plateau

Despite reported time savings, the share of time spent on new features has barely moved. Innovation ratio has increased by only one percentage point, a statistically significant (p = 0.002) but small gain.

We previously hypothesized that time saved from AI is going toward addressing existing backlogs, and new telemetry from our AI Code Insights daemon appears to validate this.

About 33% of sessions go to maintenance and 23.3% to fixes, against only 11% on new capability. Code review is among the smallest use cases. That fits the flat ratio, and it’s the clearest direct evidence we have that AI usage is concentrated in keeping existing systems running, not towards innovation.

A framework for context quality

This quarter’s report also reframes many of these friction points using our newly released CAFE(S) framework, which can be used to evaluate the quality of the context supplied to AI systems across five dimensions: Clarity, Actionability, Fidelity, Efficiency, and Security.

Our working hypothesis is that many of these friction areas are being amplified by context constraints, not model capabilities. When agents operate without sufficient architectural intent or clear boundaries, the resulting code is functional but costly to verify, and that cost surfaces downstream, in review queues and delivery friction.

In our report, we link these industry trends to CAFE(S) diagnoses and provide some recommendations for how to address growing bottlenecks. Some of my top recommendations are:

1. Make intent explicit and machine-readable. Unstated rationale, constraints, and goals are invisible while humans do the work but extremely costly once agents do. Put architectural constraints, ownership boundaries, and acceptance criteria in repos and in a form a model can load.

2. Re-plan around delivery capacity, not generation capacity. Consistent throughput growth is promising, but it’s arriving alongside longer review waits and bigger PRs. Plan roadmap commitments against the full friction picture, and treat review and verification investment as what makes continued growth safe, not as overhead.

To read more about the trends we’re uncovering and recommendations for engineering leaders moving forward, download the full report here.

That’s it for this week. Thanks for reading.

-Scott

Share

Subscribe now

Hi everyone, I’m Scott, the new Managing Editor at DX.

Each week I’ll share what I am seeing from across the industry, with a particular focus on AI enablement, metrics, and software team dynamics. You’ll still regularly hear from Brian Houck, Justin Reock, Eirini Kalliamvakou, Gratiana Fu, and our extended research community.

This week, I’m going to hand things over to Brian, who’s been thinking about the popular AI code percentage metric, and why, in a world where almost every developer has adopted AI coding tools, it needs to be applied as a lens and not a KPI.

Brian: The question of whether developers are using AI, and whether it is writing a lot of their code, is settled.

Across more than 500 companies, weekly active AI usage now exceeds 95%. And the percentage of code being generated by AI keeps climbing. In Q3 of 2025, an average of 19% of all merged code was AI-authored. By Q2 of 2026, that figure had reached 52%.

When AI was new, the percentage of AI-authored code was a useful proxy for adoption. Moving from 10% to 30% meant developers were working differently than they had been, and it was fair to read that as progress. However, adoption is no longer an open question, so the metric has lost the role it was originally intended for.

That doesn’t mean AI Code Percentage (AICP) should come out of our measurement systems. It means being clear about its role in them.

A useful research variable can be a bad target

This distinction matters to me as a researcher. I want to know how much code is being generated by AI.

AICP lets us split developers or teams into cohorts and ask much more interesting questions. As AI-authored code increases, what happens to:

• PR throughput and cycle time?

• Change failure rate and other quality measures?

• Code review wait time?

• Time spent on new capabilities versus maintenance?

• Developer experience?

• Developers’ confidence in the changes they’re shipping?

Most of those map onto dimensions the Core 4 already tracks: Speed, Effectiveness, Quality, Impact. AICP isn’t one of them. It’s the variable you segment by in order to answer why those dimensions may be changing, which makes it an input to better understanding engineering performance, rather than a measure of engineering performance itself.

In research terms, AICP is often more interesting as an independent variable than a dependent variable. For engineering leaders, I’d put it more simply:

AI Code Percentage is more useful for explaining outcomes than as an outcome itself.

Being a good diagnostic doesn’t make it a good target. The test I apply to any metric someone wants to use as a goal is whether gaming it still produces the outcome you wanted. Time-to-First-PR passes this test. Push a new hire to open a trivial PR in their first week and you’ve still forced the onboarding environment to work, which was the thing you cared about. Gaming it and doing it properly are hard to tell apart, and that’s what makes it a good target.

AICP fails badly. Tell a team its AICP needs to reach 60% and they can deliver that within a quarter by routing work through agents that would have been a ten-line human change. Benchmarking also falls apart. Suppose the measurement was perfect and you knew your organization sat at 40%, while a peer sat at 60%. You’d have learned that two companies produce code differently. You still wouldn’t know which one gets more value from AI, and the gap on its own gives you no reason to move in either direction.

Activity metrics aren’t the problem

One of the central ideas behind the SPACE framework was that developer productivity cannot be reduced to a single measure, and that activity should not be confused with productivity.

Activity data isn’t useless. Quite the opposite. Commits, pull requests, deployments and other observable behaviors can tell us a great deal about how a software engineering system works.

Though on the other side of the argument is lines-of-code, which has earned its reputation as a meaningless activity metric. Producing twice as much code doesn’t mean you’ve produced twice as much value, or even that you’ve done twice as much work. Often the best solution is the one that needs the least code.

AICP sidesteps that trap. It isn’t a count, it’s a rate. Since it is a proportion, more code doesn’t inherently mean a higher score, and a larger team doesn’t automatically outperform a smaller one. The question shifts from “How much code are we producing?” to “How much of our code production involves AI?”

AICP does share one limitation with lines of code: a higher number doesn’t necessarily mean a better outcome. It tells us how much of our code production involves AI, not how effectively we’re using it.

The same AI Code Percentage can describe very different ways of working

This problem gets more complicated as we move from autocomplete toward agents.

Imagine two teams that both report 60% AI-authored code. On the first team, developers use AI primarily as sophisticated autocomplete. They decide what to build, decompose the problem, write most of the implementation logic, inspect suggestions as they’re produced, and retain the useful ones. On the second team, developers delegate entire tasks. They describe the desired outcome, an agent explores the repository, implements a solution, runs tests and submits a pull request.

Both teams might produce the same AICP, but the role AI plays in their work is radically different.

This is why autonomy is becoming a more interesting dimension of AI adoption. Knowing that AI produced a piece of code doesn’t tell us how much of the surrounding task AI performed, how much human guidance it required, or where human judgment entered the process.

Generated isn’t the same as shipped

Suppose an AI agent generates 1,000 lines of code. A developer accepts 800 of them, rewrites 300 during review, removes another 200 before merge, and six weeks later half of what’s left has been replaced.

How much AI-authored code was there? The answer depends heavily on when you measure it.

Attributing code to AI is inherently messy. AI generates code that humans modify. Humans move and refactor AI-generated code. Suggestions get partially accepted. Developers work across multiple tools and interfaces. Agents behave differently from IDE autocomplete.

This is why I think survivorship is an increasingly important companion to AI Code Percentage. A useful way to think about AI output is as a funnel:

Recent research is beginning to look at exactly this question. A 2026 study of more than 200,000 code units across 201 open-source projects examined the subsequent fate of agent-authored code rather than simply measuring how much was generated.

The researchers found meaningful differences in how AI and human-authored code evolved after merge. More interestingly, they found significant differences in survivorship between different AI tools. The survival rate of code from Claude was nearly twice that of code from Devin.

How I’d actually use it

At DX, we think AICP should be treated as a lens, not a KPI. Read it alongside throughput, cycle time, quality, time allocation, and developer experience. If AICP rises, look for whether teams are delivering faster, maintaining quality, and spending less time on work they find tedious. If those metrics don’t improve, perhaps AI is exposing new bottlenecks. The patterns won’t establish cause and effect on their own, but they tell you where to investigate.

Review it quarterly, not weekly. This is the part I see missed most often. AICP describes a structural property of how a team works, and structural properties move slowly. A metric earns a weekly slot when you expect it to respond to something you did last sprint. AICP mostly won’t. Watching it closely generates noise, and it creates a temptation to force the line to move upwards.

As agentic development matures, we’ll need measures AICP was never designed to provide: how much autonomy agents are given, the quality of the context and requirements they receive, how reliably they accomplish what the developer actually wanted, and what happens to their output after it merges.

AICP has a place in that system. It just shouldn’t be the point of it.

Don’t ask, “How do we increase our AI Code Percentage?” Ask, “What changes when our AI Code Percentage increases?”

A lens only works if you’re looking through it at something else.

That’s it for this week. Thanks for reading.
-Scott

Share

In this episode of Engineering Enablement, I talk with Meta researcher Moritz Beller about how Meta measures developer productivity. Moritz explains diff authoring time and how the company uses it to evaluate tools and guide engineering decisions. We explore how AI is changing engineers’ work and revealing gaps in traditional metrics. We also revisit his highly influential “Mind the Gap” study and discuss the promise and risks of AI agents for testing.

Some takeaways:

Diff authoring time enables more precise productivity measurement

• Diff authoring time measures the active work involved in creating, testing, and reviewing a specific code change. This gives Meta more precision than metrics averaged across an entire day.

• No single diff metric provides a complete picture of productivity. Meta considers authoring time alongside throughput, diff size, and quality to make changes in the data easier to interpret.

• Meta does not use diff authoring time to evaluate individual developers. It is used at the team, organizational, and company levels to identify trends, regressions, and opportunities for improvement.

A/B experiments help Meta prioritize engineering investments

• Diff-level measurement allows Meta to quantify whether changes to developer tools and frameworks save engineers time. This helps leaders decide which improvements deserve further investment.

• Automatic memoization in the React compiler reduced diff authoring time by roughly 30% compared with implementing caching manually. Results of that magnitude suggest that foundational improvements can be more valuable than small interface optimizations.

AI is changing how engineers spend their time

• Meta’s year-over-year diff authoring time has fallen by more than 40%, while developers are producing more and larger diffs. Moritz views the company-wide pattern as a strong signal of AI’s impact.

• It is not yet clear where all the saved authoring time goes. Moritz believes engineers are spending more time gathering context and performing work adjacent to coding, while relatively little time goes into writing prompts.

• As code becomes cheaper to generate, intent becomes more valuable. The important question is increasingly whether the finished code accurately reflects what the developer intended to build.

Traditional telemetry misses important engineering work

• Activities like whiteboarding, brainstorming, and architectural alignment are difficult to connect to code changes through conventional telemetry. Meeting transcripts and other AI-generated records could help make that work more visible.

• Cheaper code generation does not eliminate the need for architecture. Skipping a design document can simply transfer the cost to reviewers, who must reconstruct the intended design from the implementation.

Developer productivity is both measured and perceived

• Moritz’s “Mind the Gap” study connected automatically measured activity with developers’ perceptions of their own productivity. Time spent coding was an important predictor, but sleep, interruptions, and on-call responsibilities also mattered.

• A modern version of the study would need to account for agentic work. Moritz would examine how developers interact with agents, how much they trust them, and whether managing parallel work creates cognitive overload.

• Higher output does not necessarily improve developer experience. Brian points to research showing that output can rise while flow, cognitive load, and overall experience remain flat or worsen.

AI makes testing easier but not necessarily safer

• Agents make it inexpensive to generate unit and end-to-end tests. This could fill gaps left by developers who previously did little testing.

• Passing tests can create false confidence when both the implementation and tests reflect the same misunderstanding. The agent may satisfy its interpretation of an underspecified request without delivering what the developer actually intended.

• Specification-driven development could become a new form of test-driven development. Defining correctness before implementation may matter more as agents take on more of the coding.

Collaboration remains one of the hardest parts of productivity to measure

• Interpersonal dynamics, alignment, and knowledge sharing are central to engineering productivity but poorly captured by existing metrics. Faster implementation also makes it easier for teams to unknowingly duplicate one another’s work.

• Reducing low-quality meetings can produce major throughput gains, but eliminating collaboration creates different problems. Teams still need enough interaction to generate ideas, share context, and stay aligned.

• Small human interactions can have measurable value. Brian’s research found that informal conversation before and after meetings predicted self-reported productivity better than internet quality.

In this episode, we cover:

(00:00) Intro

(02:10) Moritz’s role at Meta

(04:01) Measuring diff authoring time

(08:20) Measuring A/B experiments

(12:11) What diff authoring time reveals

(14:45) Planning and leadership reporting

(18:36) Why Meta measures teams, not individuals

(22:33) Where developer time goes with AI

(26:06) AI’s impact on junior and senior developers

(27:18) Capturing invisible work with AI

(29:32) The “Mind the Gap” study

(33:40) Revisiting “Mind the Gap” in 2026

(38:32) AI agents for software testing

(41:49) What remains hard to measure

Where to find Moritz Beller:

• LinkedIn: https://www.linkedin.com/in/inventitech

• X: https://x.com/Inventitech

• GitHub: https://github.com/Inventitech

• Website: https://inventitech.com

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• State of AI Impact in Engineering Q2 Report 2026

• GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis

• From Technical Debt to Cognitive and Intent Debt

• Mind the Gap: On the Relationship Between Automatically Measured and Self-Reported Productivity

• The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study

• When, how, and why developers (do not) test in their IDEs | Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering

• DORA, SPACE, and DevEx: Which framework should you use

• A Tale of Two Cities: Software Developers Working from Home During the COVID-19 Pandemic

Subscribe now

Whenever a new evaluation framework shows up, the first reasonable question is which existing one it competes with. That reflex is healthy. New frameworks often overlap with things you’re already measuring, and every addition comes with some cost. Anyone who has watched a measurement program collapse under its own weight has learned to ask what is being displaced before adopting something new.

I wanted to answer that question for my recently published CAFE(S) framework, because it doesn’t compete with what you’re already running. CAFE(S) is a framework for evaluating the quality of the context we give AI agents across five dimensions: Clarity, Actionability, Fidelity, Efficiency, and (Security). It asks whether the information agents have to work with is good enough for the tasks they’re trying to accomplish.

DORA looks at your delivery system. SPACE, DX Core 4, and EngThrive look at developers and the outcomes they’re working toward. Retrieval and model evals assess what the AI retrieved and produced. OWASP looks at the risk surface. Context and harness engineering guidance tells you how to build the environment the agent works in.

What none of your existing frameworks were built to look at is the information the agent was handed in the first place. I’ve argued that AI didn’t create a context problem, but pushed an existing issue past its breaking point.

This isn’t an argument to drop what you’re already running, or to blindly bolt one more framework onto the stack. The rest of this piece looks at where CAFE(S) sits alongside existing frameworks you may be using. In doing so, I hope to make the boundaries between all of them a little clearer.

Delivery and experience metrics tell you something is wrong, not where

DORA, SPACE, DX Core 4, and EngThrive are all anchored to outcomes, which is exactly why they’ve survived several technology cycles and why I don’t expect AI to invalidate any of them.

But an outcome moving in the wrong direction is a problem, not a diagnosis. Change failure rate climbing, DXI sliding, or innovation rate stagnating tells you where to start asking questions, not what caused the change.

Core 4 and EngThrive both explicitly carry diagnostic dimensions alongside the outcome ones, so this isn’t a clean lagging vs. leading split, but those diagnostics aren’t focused on the assembled context as a first-class engineering artifact.

We’re still trying to accomplish the same top-level outcomes in our agentic workflows as we were before. What has changed is the diagnostic surface, requiring us to look in new places for answers when we’re not achieving them.

Ask yourself: when a delivery or experience metric moves the wrong way, can you tell whether the information your agents worked from had anything to do with it?

Retrieval evals tell you whether retrieval worked, not whether the context worked

Retrieval-augmented generation (RAG) evaluation frameworks measure the quality of the information retrieved and the responses generated from it, which touches on the Fidelity and Efficiency dimensions of CAFE(S). If you run RAG evals well, you already have two of the five properties partially covered.

The other three (Clarity, Actionability, and Security) are outside their frame. A retrieval eval does not ask whether the task was stated in a way that admits a single interpretation, whether anyone defined what finished looks like, or whether attacker-controlled content made it into the window.

There’s an important difference in what gets evaluated. A retrieval eval scores the information your retriever fetched. The agent reasons over the whole assembled context, which also includes the human’s prompt, the root AGENTS.md file, tool output, prior turns, and whatever memory the harness decided to carry forward. Most of that never passed through your retriever, so most of it never appears in your eval.

Ask yourself: are you evaluating the passages your retriever returned, or everything the agent actually read?

OWASP evaluates security risk, not context quality

OWASP goes much deeper on security risk than CAFE(S) does. The ‘S’ pillar is one property among five; OWASP provides focused security guidance. If you’re choosing between them for security depth, you shouldn’t choose CAFE(S). But you shouldn’t have to choose between them.

CAFE(S) puts security inside a broader quality model for context. That’s useful because security and usefulness aren’t always separable. Oversharing, for example, can be both a security failure and an efficiency failure. Trimming unnecessary context can simultaneously reduce token spend and shrink the attack surface.

Failures of the first four dimensions of CAFE(S) make agents less effective. Failures of security make them unsafe.

Ask yourself: are you evaluating your context for both usefulness and safety?

Context engineering tells you how to build context, not whether it’s good

Anthropic’s context engineering guidance, Birgitta Böckeler’s harness engineering guidance, and OpenAI’s harness engineering guide all offer practices for building better context and harnesses. CAFE(S) starts at the other end: given the context an agent actually received, was it any good?

That’s the difference between prescriptive and evaluative. You can follow good context engineering practices and still end up with context that is ambiguous, incomplete, stale, bloated, or unsafe. Conversely, CAFE(S) doesn’t tell you which retrieval strategy, memory architecture, or harness design to use. It gives you properties for evaluating the result.

Ask yourself: do you have a definition of good context that is independent of how you built it?

TRUCE evaluates code quality, not context quality

TRUCE is a multidimensional framework for evaluating code quality and is the closest conceptual sibling to CAFE(S).

CAFE(S) applies a similar idea to a different engineering artifact. As context becomes a first-class input to agentic software development, its quality matters independent of the quality of the code that eventually comes out.

TRUCE gives us a language for thinking about the quality of code. CAFE(S) is intended to do the same for context.

Ask yourself: if context is becoming a first-class engineering artifact, do you have a way to evaluate its quality?

Final thoughts

So, do you need another framework? Maybe that’s the wrong question.

DORA, SPACE, retrieval evals, OWASP, TRUCE, and CAFE(S) aren’t competing ways to measure the same thing. They answer different questions about different parts of the engineering system.

CAFE(S) adds one that has become increasingly important in agentic development: was the context we gave the agent any good?

It doesn’t replace what you’re already using. It fills the gaps between them.

That’s it for this week. Thanks for reading.

-Brian

Share

Subscribe now

🗓 Join DX’s live research panel today as we introduce CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.

This special issue marks the release of CAFE(S), a new framework for evaluating the quality of context assembled for AI systems. I had the privilege of co-authoring it with Max Kanat-Alexander (Capital One), Eirini Kalliamvakou (DX, formerly GitHub), Margaret-Anne Storey (University of Victoria), and Nicole Forsgren (Google).

It is out now in ACM Queue, and you can download the paper here.

Low-quality context now exacts a high price

For most of software’s history, knowledge management has been a major source of developer pain. Engineers have struggled with out-of-date documentation, unclear specifications, and conflicting requirements for decades. Poor context might have been a drag on developer experience, but that pain could be absorbed because a developer could go over and ask a peer for clarification.

What’s changed isn’t that context started mattering. It’s that the consequences now arrive immediately, at scale, and usually with a number attached.

Tokens. Every token sent to an agent is paid for, and context is where tokens accumulate. When Notion engineered its context for reuse through prompt caching, costs dropped roughly 90 percent with no loss in output quality, because reading cached context is far cheaper than retransmitting the same information.

Liability. In February 2024, the British Columbia Civil Resolution Tribunal found Air Canada liable for a refund its customer service chatbot promised and its actual policy did not provide. Air Canada argued the chatbot was effectively responsible for its own statements. The tribunal disagreed. The damages were modest. The precedent was not.

Security. EchoLeak (CVE-2025-32711) was the first documented prompt injection to achieve real-world data exfiltration from a production AI system. A single crafted email, never opened by the user, caused Microsoft 365 Copilot to pull internal documents into its working context and leak them. Untrusted information became part of the agent’s context, and the agent acted on it, faithfully.

Translating human intent for intelligent models

Our creative ideas aren’t automatically absorbed by intelligent models. They need to be translated before an agent can act on them. This simple pipeline describes how human intent becomes agent behavior.

Intent is what a person ultimately wants to accomplish. That intent must then be translated into context, which is the information that represents the task, its constraints, and the surrounding knowledge. A harness applies that context through orchestration, retrieval, tools, memory, and execution logic before passing it to a model, which supplies the underlying intelligence that produces a result.

Every layer matters, and three of them have serious disciplines behind them. Machine learning research improves models. Harness engineering improves how those models are orchestrated. Product and requirements work improves how we create and refine intent in the first place. The translation from intent into context is the one that gets relatively little attention, despite increasingly determining whether an otherwise capable agent succeeds or fails.

Some disciplines get close, but answer different questions. Knowledge management asks whether the information exists and is maintained. Information retrieval asks whether it can be found. Context engineering asks how to select and assemble it for a model. But none of those tell you whether the context itself is fit for the task at hand.

That’s the gap CAFE(S) is meant to fill.

The five properties

CAFE(S) names five properties of good context. The first four ask whether the context lets agents do good work. The fifth, set slightly apart in parentheses, asks whether the context is safe to use at all.

• Clarity: can the agent interpret the request as intended? Clear context resolves the same way for the author and for the agent. When it is ambiguous, the agent may choose an incorrect interpretation, often silently, and every step after that compounds the choice.

• Actionability: can the agent proceed, and know when it’s done? Actionable context states the objective, relevant constraints, and what “done” looks like. Without those, agents spiral into execution loops, stop early, or declare success against a target they inferred rather than one they were given.

• Fidelity: can the agent trust that this context is true? Faithful context is accurate, current, internally consistent, and drawn from sources worth trusting. When it isn’t, agents reason confidently from stale guidance, or fill a gap with a guess that then becomes indistinguishable from fact.

• Efficiency: can the agent focus on what matters? Efficient context carries a high signal-to-noise ratio. Irrelevant material doesn’t merely take up room, it competes for the model’s attention, which is how the one detail that mattered ends up lost in the middle. And every unnecessary token is paid for.

• Security: should the agent have this context at all? Secure context is safe and appropriate for the agent to access and process. Failures here look like prompt injection, data leakage, and policy violations rather than merely disappointing results.

A fair question is why we stopped at five, when timeliness, cost, and provenance are all plausible candidates. Our bar was that a property earns its own pillar only if it isn’t derivable from the others, can be acted on independently, and names a failure the others miss. Most fold in cleanly. Stale context is context that’s no longer true, which makes timeliness a facet of fidelity, and cost is a downstream consequence of efficiency rather than a property of the artifact.

What’s left is genuinely independent. Context can be clear but not faithful, describing the system as it was rather than as it is. It can be efficient and faithful but not actionable, never saying what finishing looks like. A single bad instruction can fail several pillars at once, but each one names something you can reason about, review for, and fix on its own.

Security sits in parentheses because it evaluates the same artifact while asking a different kind of question about it. Failures of the first four make agents less effective. Failures of security make them unsafe.

Putting CAFE(S) into practice

Understanding the five properties is a start. The value comes from treating the context you hand to agents as a first-class engineering artifact, which means someone owns it, someone reviews it, and it gets maintained as the system changes.

First, the information must be accessible; the best context is useless if it is out of the agent’s reach. Second, the system must be capable of cutting through the noise to retrieve the exact slice of data needed across scattered systems, without exhausting token budgets or context windows. Finally, the knowledge must exist in the first place. No retrieval architecture or context engineering can surface the undocumented hallway decisions and unrecorded conversations that live only in people’s heads. Only after information is captured, connected, and retrievable do the properties of CAFE(S) become the operative standard for quality.

Once you’re past those, here are the highest-leverage moves against each property.

• For clarity and actionability: introduce a review discipline for shared context files like AGENTS.md or checked-in specs. You wouldn’t merge unreviewed code. Review these the same way, and scale the scrutiny to how widely they get reused. A repository-wide file shaping thousands of sessions deserves far more attention than a working note between two engineers.

• For fidelity: assign clear ownership and a review cadence to critical context sources, including runbooks, architecture decision records, and API schemas. Information decays as systems evolve, and an owner is what gets stale guidance pruned before an agent turns it into a confident mistake. Ownership should follow teams rather than individuals, so context survives reorgs.

• For efficiency: put guidance where it’s actually used. The same words can be high quality in one location and harmful in another. An instruction about running the test suite belongs in a root AGENTS.md, because nearly every session needs it. An instruction about one rarely touched file does not, because it gets injected into thousands of sessions that have nothing to do with it. Move that instruction into a comment inside the file it describes and it becomes high quality, available exactly when it’s relevant. Nothing about the words changed. Only their location did.

• For security: hold a hard boundary between trusted instructions and untrusted data. Emails, tickets, and pull request content are inputs, not instructions. Treating them as instructions is the mechanism behind the attack I described earlier.

The paper goes considerably further on what individuals, teams, and organizations can do to improve context quality along the dimensions of CAFE(S).

Final thoughts

CAFE(S) provides a definition of context quality, not a measurement system. Our goal is to give engineering teams a shared vocabulary to discuss context, review it as a first-class asset, and intervene before bad context causes failures. While empirical metrics and automated evaluations will follow, meaningful measurement first requires a precise definition of what high-quality context actually looks like.

As software development shifts toward greater human-agent collaboration, high-quality context becomes a fundamental prerequisite for agent autonomy. Clear, actionable, faithful, efficient, and secure context creates the baseline conditions where delegating complex work becomes reasonable, though never fully guaranteed. CAFE(S) doesn’t claim good context is sufficient to hand an agent the keys; it simply shows why, without it, you shouldn’t.

You can read the full paper here: CAFE(S): Your Agent Is Only as Good as Its Context

That’s it for this week. Thanks for reading.
-Brian

Share

Subscribe now

🗓 Join our live research panel on September 24 as we introduce CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.

Some of the most publicized AI failures of the last few years came from the legal profession. Lawyers have now been sanctioned, more than once, for filing briefs containing citations to cases that did not exist. It is tempting to blame these hallucinations entirely on model failure, but that offers an incomplete picture.

A brief was drafted, reviewed, and filed. Somewhere along that chain, an unsupported claim produced by a probabilistic language model became something a human was willing to represent as fact. The hallucination was the visible failure, but the root cause was the information environment surrounding the model.

A better model might hallucinate less often, but it won’t eliminate the need for the information and safeguards required to separate the plausible from the true.

That distinction is critical, and it’s showing up everywhere software gets built.

Picking up where the code left off

Recently, I wrote about what AI is doing to software quality, using a definition of quality that some colleagues and I developed back in 2020. The conclusion I landed on was that code is becoming a late place to look. More of what determines quality is settled before any code exists.

I ended that piece with five sentences that have stuck with me since:

Reuse requires knowing what already exists in the codebase. Review requires knowing what a change was meant to accomplish. Evolvability requires knowing why the system is structured the way it is. Handoff requires knowing what the previous person was thinking. Serving user needs requires knowing what problem the software was supposed to solve in the first place.

None of that knowledge necessarily lives in the code. It lives in tickets, design docs, runbooks, architecture decision records, and Slack threads. A fair amount of it lives nowhere at all except in somebody’s head.

When we hand a task to an agent, we hand over some representation of that knowledge with it. That representation is the context. And when context fails, it does not fail randomly, the same shapes keep recurring.

We have a vocabulary for this, just not for context

Software engineers have a rich language for recurring problems in code. Say code smell and everyone knows you mean something that isn’t a bug, but reliably signals trouble ahead. Long method. Feature envy. Shotgun surgery. Those names are useful precisely because they convert a vague unease into something you can point at in a review.

We have almost nothing equivalent for context when working with agents. When an agent produces something wrong, the diagnosis usually stops at “the model got confused,” which explains nothing and suggests no action.

So let me offer a starting vocabulary. Call them context smells. Here are six I keep running into. None of them are model limitations, and all of them survive a model upgrade.

Confident hallucination. The model asserts something untrue with exactly the fluency it uses for things that are true. We treat this as a model defect, and partly it is. But a model can only separate supported claims from unsupported ones if something in its context gives it a way to do that. The sanctioned lawyers weren’t undone by fabrication alone. They were undone by a workflow in which nothing downstream of the fabrication was designed to catch it.

Specification ambiguity. This is the one I find most underappreciated. Faced with an obviously underdetermined request, an agent will often stop and ask for clarification. Faced with a semi-ambiguous request, it does something considerably more dangerous. It picks an interpretation and proceeds. If that first read is wrong, every subsequent step compounds it, and the work looks confident the entire way down. Nothing was missing from the context. It simply admitted more than one reasonable reading, and nobody noticed which one got chosen.

Stale guidance. Context that accurately describes a system that no longer exists. The runbook that was correct two migrations ago. The architecture doc written before the service was split. A human reading these usually senses the mismatch and goes looking for why. An agent has no such reflex, and treats them as current.

Lost in the middle. More context is not reliably better. Model performance degrades as input grows, and it degrades unevenly, with material buried in the middle of a long context getting overlooked in favor of what sits at the edges. This one is genuinely counterintuitive, because nothing is missing. The agent has everything it needs and still fails, because the signal is competing with too much else for attention. Agents, like people, can get distracted.

Lost in the details. Context that supplies plenty of implementation detail and none of the reasoning behind it. The agent optimizes local mechanics beautifully while losing track of what the task was actually for. Margaret-Anne Storey calls the underlying condition intent debt, the gradual disappearance of recorded rationale from the artifacts a system leaves behind. It’s the difference between knowing that a timeout is set to 300 milliseconds and knowing whether that number came from a benchmark, a support incident, or somebody’s afternoon guess.

Weekend runaway. An agent given a task with no definition of success may never discover that it’s finished. So it retries, widens scope, and keeps exploring an objective that may not even be achievable. The result is consumed time, consumed tokens, and occasionally a genuinely startling bill on Monday morning. This may be the least intellectually interesting failure on the list, but maybe the one most likely to get a leader’s attention.

None of these are new

Read that list again and notice how little of it is actually about AI.

Ambiguous specifications have been the central concern of requirements engineering for decades. Documentation that drifts out of sync with the system it describes is one of the oldest complaints in software maintenance. Signal drowning in noise is the founding problem of information retrieval. Rationale vanishing from the artifacts a team leaves behind is what knowledge management has always been about.

None of these challenges are new. Bad context has always been a normal fact-of-life for software organizations. What kept it from being catastrophic is that humans quietly repaired it, constantly, without anyone noticing.

A new engineer handed an ambiguous ticket walks over and asks what it means. Handed a runbook that doesn’t match production, they notice the discrepancy and go find someone who knows. Handed two documents that contradict each other, they work out which one smells current, or they ask in a channel and get an answer in four minutes. Every organization I’ve studied runs on documentation that would fail inspection, and it works anyway, because a layer of human judgment sits between the bad context and the actual work.

Agents don’t reliably have that same repair loop, especially as we race to make them more autonomous. Handed the same ambiguous ticket, the same stale runbook, the same contradictory pair of documents, they proceed. Confidently, quickly, and at a scale that used to be impossible.

I don’t think AI created a context problem. I think it withdrew the error correction that had been hiding one. The information environment we’ve been tolerating was always this bad. If that’s right, it may also help explain one of DORA’s more interesting findings about AI adoption. Their 2025 research describes AI as an amplifier. It tends to magnify the strengths and weaknesses of the systems already surrounding agents. That’s usually framed as an organizational capability problem, but I wonder if part of it is an information problem. Teams with clearer specifications, better documentation, and more accessible organizational knowledge may simply have less damage for the human buffer to absorb in the first place.

What you can do

Most of what I’ve described sounds like it needs instrumentation we don’t have yet. It doesn’t (at least not to start).

Before handing a task to an agent, ask whether a competent new colleague could complete it with what you’re making available. Not a senior engineer who already knows your system. A capable person with no additional access to what’s in your head.

That test is deliberately low-tech, and it catches a surprising amount. The specification that admits two readings. The runbook describing last year’s architecture. The fifty-page dump with the one important constraint on page thirty-one. The task with no stated definition of done.

A competent new colleague would probably stop at each of those. Which interpretation did you mean? Is this runbook still current? Which of these fifty pages actually matters? What does done look like? Those questions are the human repair loop in action. The more autonomous we make agents, the less we should assume that loop will save bad context.

Naming these patterns is a start, but only a start. Context smells give us a vocabulary for recognizing trouble. They don’t give us a systematic way to evaluate the quality of context before an agent starts working. That second problem is considerably harder, and it’s where I’ve been spending most of my time lately. Over the coming weeks, I’ll be publishing a framework describing the dimensions of context quality, followed by an approach to measuring those dimensions.

For now, though, the question I’d put to any team frustrated with their agents isn’t which model they should be using.

It’s whether they’d have given the same task to a new hire and expected them to get it right.

That’s it for this week. Thanks for reading.

-Brian

Share

In this episode of Engineering Enablement, I sit down with Robert Lucero, Chief Architect at Okta, to discuss how agentic AI is changing identity and access management. We explore how organizations should define agent identities, why authentication and authorization remain foundational, and how sandboxing, fine-grained permissions, and just-in-time access let agents operate autonomously without creating unacceptable risk.

Robert shares what Okta has learned from driving AI adoption among security-minded engineers, what makes a repository ready for AI agents, and why strong testing, CI, and review processes matter even more as AI generates more code. We also discuss AI’s role in software validation, the need for human judgment, and whether AI will ultimately give the advantage to security teams or attackers.

Some takeaways:

Identity becomes critical when AI agents move beyond content generation

• AI agents need access to documents, source code, CI systems, ticketing tools, and other resources to perform useful work. Identity systems determine which resources they can access and what actions they can take.

• Non-determinism makes tightly scoped access especially important. Organizations need dynamic policies, fine-grained permissions, and visibility when agents attempt to operate beyond their boundaries.

The definition of an agent identity is still evolving

• Organizations have not yet settled on whether every agent or ephemeral workload needs its own identity. An agent might instead operate under an orchestrator, a service account, or the identity of a human owner.

• The fundamentals of identity remain the same. Agents still need to be authenticated before organizations can apply authorization policies, governance, and access controls.

Treat AI agents like new hires

• Start agents in a sandbox with tightly scoped access and clearly defined tasks. Like new employees, agents may seek out tools or information when their environment is missing something they need.

• Rely on technical controls rather than assuming an agent has earned trust. Sandboxing, guardrails, and just-in-time access can limit the blast radius of unpredictable behavior.

Identity systems are a control plane, not an orchestration layer

• The identity layer governs what agents can access, trigger, and call. The workflows connecting coding, review, testing, and deployment agents will likely be orchestrated elsewhere.

• Identity systems can provide essential visibility into agent relationships. A relational record of agent-to-agent and agent-to-resource access makes it possible to investigate why an agent was able to take a particular action.

Successful AI adoption depends on useful outcomes

• Okta’s security-minded engineers were initially skeptical because early tools did not reliably help them do their jobs. Adoption increased as coding models improved and became more effective in real engineering workflows.

• The value of AI extends far beyond writing code. Engineers can use it to summarize documentation, review product specs, investigate production issues, and respond to customer requests more efficiently.

AI readiness starts with engineering fundamentals

• Repositories need clear instructions, discoverable dependencies, compatible harnesses, and defined development practices before agents can work effectively.

• Strong testing, CI, linting, and code review provide the safety nets AI-generated changes require. Improving a repository for AI agents often makes it easier for human developers to work in as well.

Passing tests does not prove that AI-generated code is correct

• An agent can write tests and produce code that passes them without understanding the intended business outcome. Reliable validation depends on giving agents access to the right requirements and context.

• Human judgment remains essential for determining whether software actually solves the problem. Developers, designers, test engineers, and product owners must still evaluate whether the result meets user and business needs.

In this episode, we cover:

(00:00) Intro

(02:16) Meet Robert Lucero

(02:56) Why identity becomes critical as AI agents access more systems

(06:07) Governing automated access for non-deterministic agents

(08:01) Defining and managing agent identities

(10:32) Authentication and authorization for AI agents

(13:33) Determining how much autonomy to give AI agents

(19:44) Identity systems as the control plane for AI agents

(22:40) Driving AI adoption among security-minded engineers

(25:48) Why AI’s impact on engineering extends beyond coding

(28:44) The three components of AI readiness for repositories

(30:55) AI’s role in software testing and validation

(34:26) Whether AI gives defenders or attackers the advantage

(36:01) Where to find the best food in the country

Where to find Robert Lucero:

• LinkedIn: https://www.linkedin.com/in/rlucero

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• State of AI Impact in Engineering Q2 Report 2026

• Okta

• The Hugging Face incident and the road ahead | OpenAI

• GitHub Copilot · Your AI pair programmer

• Claude Code by Anthropic | AI Coding Agent, Terminal, IDE

• Eight Myths on Software Engineering and GenAI | Queue

• Adriana Corona

Subscribe now

🗓 Join DX’s live research panel on September 24 as Brian Houck introduces CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.

As reported in our Q2 AI Impact Report, time saved thanks to AI continues to increase, with developers reporting saving 6.1 hours per week in Q2 2026 compared to 3 hours in Q3 2025. However, it raises the question for engineering leaders:

What are developers doing with that time?

While AI is frequently positioned as a way to reclaim time for innovation, our data reveals a disconnect between AI-driven output and actual shifts in work composition. Organizations are investing in AI with the hope that the time AI saves will directly translate into faster roadmap execution and more innovation. DX tracks this using innovation ratio, the percent of engineering effort dedicated to new capabilities versus maintenance.

We used multivariate regression on a sample of 500+ DX customers to test the innovation ratio against 15 workflow metrics, including AI output, shipping velocity, and operational drag. We analyzed AI output according to how much AI-authored code, agent-delivered work, and PR throughput teams produce. Our analysis shows that while AI output has a powerful link to AI-driven time savings, it does not reliably translate into a higher innovation ratio.

Information-seeking may be the hidden barrier to innovation

While AI tools are delivering measurable speed, our data suggests that reclaiming capacity for new features requires clearing organizational friction, rather than assuming AI will lead to innovation.

1. AI is a lever for speed. The data confirms that AI does what it promises. AI output accounts for 63% of the variation in developer time savings, suggesting that developers with higher AI output save more time.

2. Speed doesn’t convert to innovation. Despite increased time savings, AI output suggests a weak link to innovation (p < 0.01, β=0.16). No single workflow metric emerged as a reliable predictor of innovation, indicating that dedicating more time for new features and capabilities is not a byproduct of moving faster.

3. The impact of operational friction. The clearest signal tied to lower innovation ratio is information-seeking, referring to time lost hunting for context, documentation, or answers (p < 0.01, β=-0.19). It is not a large effect and needs additional validation, but this developer-reported friction represents a significant hypothesis for engineering leaders. It suggests that reducing operational drag may be a more effective path to increasing innovation than AI (or AI alone).

Key takeaways for engineering leaders

1. Decouple AI strategy from innovation goals. AI delivers speed, but there is no evidence it automatically shifts teams toward new-feature work. Treat innovation as a separate objective requiring its own strategy

2. Test the operational friction hypothesis. Focus on reducing time lost to information-seeking. While not yet a proven driver of innovation, it is the most promising lead for improving developer conditions.

3. Use this as a diagnostic. Because our model accounted for only 13% of the differences in innovation ratio, much of what drives new-feature work remains unique to each company. The most valuable next step is running this analysis against your own team’s data; your strongest predictors might differ from the aggregate.

   ---

   That’s it for this week. Thanks for reading.
   -Grace

   Share

Subscribe now

🗓 Join our live research panel on September 24 as we introduce CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.

Two numbers from the 2026 Q2 State of AI Impact report have raised a lot of questions for me about the impact of AI on “quality”.

Across a sample of more than 500 companies, code maintainability improved 3.8% between Q1 and Q2. Over the same period change confidence fell 6.1%. Maintainability asks how easy the codebase is to understand and modify. Change confidence asks whether developers trust that their changes won’t break things.

Those two measures have historically moved together. Code you understand is code you feel safe changing. Now they are moving in opposite directions.

Layering in other findings from the report makes the picture even less clear. Documentation quality, code maintainability, and production debugging had some of the biggest improvements in the quarter—all signals we might expect to provide tailwinds to quality. At the same time, review turnaround declined, incremental delivery fell sharply, and pull requests continued to get larger—all signals that we might expect to provide headwinds.

Perhaps quality isn’t simply going up or down. Perhaps different parts of it are moving in different directions.

To help me frame the problem, I went back to a definition of quality that a couple of colleagues and I developed in 2020, several years before generative AI complicated the picture. I wanted to know whether our definition could help make sense of what we’re seeing now.

Turns out, the places where the data appears most contradictory make considerably more sense once we stop treating “quality” as one thing.

What developers mean by quality, before AI could complicate it

In January 2020, Margaret-Anne Storey, Tom Zimmermann and I surveyed 131 developers and 34 engineering managers at Microsoft about how they define productivity and quality, in their own words. (Paper summary here.) We coded the open-text answers inductively, and five dimensions of quality fell out. We called these dimensions TRUCE, which are defined below:

Six years later, TRUCE gives us a useful lens for interpreting what otherwise looks like contradictory evidence about AI and software quality.

Robustness is unsettled, but we can see it

Start with the dimension we instrument best.

Change failure rate volatility widened in Q2, with many organizations now swinging plus or minus three percentage points against a 4% industry benchmark. The distribution of failed deployment recovery time is leaning longer, even though developers’ experience with production debugging improved slightly.

In other words, teams report getting better at diagnosing production problems while recovery outcomes are becoming more variable.

It’s important not to turn correlation into causation here. This data doesn’t tell us that AI created volatility, or even that AI amplified it. What we can say is that robustness is becoming less predictable during the same period in which AI-authored code has accelerated dramatically.

Robustness itself isn’t mysterious; we know what we’re trying to observe. Many metrics exist to try and measure robustness: failure rates, recovery times, incidents, defects, test outcomes, and more. We can debate exactly which measures are best, but when robustness changes, we have a reasonably mature vocabulary for describing what happened.

Hold onto that, because robustness turns out to be the exception. The dimensions that follow are roughly ordered by how well we can measure them, and as that measurement thins out, something consistent happens: the dimension stops behaving like one thing. Whether those two facts are related is a question I want to come back to.

Evolvability is splitting into two things

TRUCE derived evolvability from developers defining quality as “Easy to test, easy to change.” It’s natural to assume that code you understand is code you can feel safe changing. Recent academic research suggests something different may be happening when we zoom out from individual code changes to the systems they become part of.

In More Code, Less Reuse, Huang and colleagues compared pull requests generated by AI agents with those written by human developers. They found that AI agents were more likely to miss opportunities to reuse existing code, introducing greater redundancy. Interestingly, reviewers still tended to respond neutrally or positively to the AI-generated contributions. The authors describe this as a disconnect between the “surface-level plausibility” of the code and the technical debt accumulating underneath it.

Another recent study makes the distinction even clearer. Needle in the Repo evaluated 23 AI coding configurations on repository-level tasks designed to test maintainability, not just whether the resulting code worked. Across those configurations, 13.3% of outcomes passed every functional test while still failing the study’s structural maintainability criteria. Performance was especially poor on architectural concerns such as dependency control and responsibility decomposition.

Both findings point toward the same distinction. A piece of code can be easy to understand. It can work. Reviewers can even think it looks good. But the system it belongs to can still become harder to evolve.

The emerging pattern is that locally good code doesn’t guarantee a healthy system. Generated code may be perfectly understandable in isolation while duplicating something that already exists, introducing an unnecessary dependency, or putting functionality in a place that makes the broader system harder to change.

And that brings us back to the numbers I started with. Maintainability improved 3.8%. Change confidence fell 6.1%. Perhaps those measures aren’t disagreeing after all. They may simply be looking at different parts of evolvability.

Collaboration is splitting too

One of my favorite definitions of quality from the TRUCE paper came from a developer describing collaboration, one of the least frequently mentioned dimensions:

“Quality is code or solutions that solve a problem and don’t need undue maintenance or lengthy handoff. If I get hit by a bus and the company can still easily use the code I’ve written, I’ve made a quality solution.”

We wrote at the time that enabling collaboration or reuse by others “is often invisible and hard to measure,” which likely explains why it was a less frequently mentioned dimension, “and yet it is very important.” I did not expect that sentence to age the way it has.

This is where the data gets strange. Documentation quality was among the clearest wins in the quarter. That matters for collaboration. Documentation supports handoff, comprehension, and the ability of someone else to pick up your work.

At the same time, review turnaround declined. Incremental delivery, which asks whether developers work in small, testable changes, showed the sharpest decrease of any driver. Median PR size nearly doubled over the year, increasing the amount of unfamiliar code developers need to understand at once.

So we have better documentation attached to larger changes that are harder to review, written increasingly by something that isn’t on the team. Documentation quality and shared understanding aren’t the same thing. AI can document what the code does without transferring the reasoning that led to it. It can make handoff easier while making shared ownership harder.

That’s what makes the bus-factor definition feel so different to me now. AI may be improving the explicit artifacts that support handoff while making the implicit knowledge surrounding the work more difficult to maintain.

The collaboration dimension that only 17% of developers thought to mention in 2020 suddenly looks much more important. And we said at the time that we couldn’t see it very well.

Timeliness is not the same thing as speed

Only 7% of developers named timeliness as a dimension of quality in 2020, the lowest of the five dimensions. It is now the site of perhaps the cleanest decoupling in the data.

Median normalized PR Throughput rose 37% over four quarters. Deployment frequency is up across nearly every segment. However, over the same period, developers’ perceived rate of delivery was flat.

That looks contradictory only if we assume delivery speed and timeliness are the same thing. Timeliness was not intended to be a pipeline property. It was about whether what was needed arrived when it was needed.

AI can increase the amount of code flowing through a system without changing how quickly an engineer feels able to get the thing that matters into a customer’s hands. More PRs can run into slower reviews. Faster implementation can expose bottlenecks in testing, deployment, requirements, or coordination. Additional output can simply create additional work downstream.

The pipeline got measurably faster. The felt experience of delivering on time did not.

Once again, TRUCE makes the apparent contradiction easier to understand. Our delivery-speed metrics and our experience of timeliness are measuring related things, but they aren’t measuring the same thing.

User needs is the dimension we still can’t see

It would be a stretch to say much of anything about AI’s impact on this dimension from the available data. That is itself a finding.

The closest available proxy in the Q2 data is perceived software quality, and it says something counterintuitive. Traditional industries and financial services, the slowest-moving segments on throughput, report the highest perceived quality.

That is self-reported and may say as much about expectations as about software, so I’d stop short of any claim stronger than this: speed and perceived quality are not moving together.

I also went looking for external research on whether the people who use software are experiencing it differently as AI authorship climbs. I came up mostly empty.

There is a great deal on defect rates, vulnerability counts, code quality, and QA workload. We have remarkably detailed telemetry about how much code AI writes, how quickly pull requests move, how frequently teams deploy, and how often changes fail. We know considerably less about whether the resulting software is actually solving people’s problems better.

That’s a striking asymmetry.

One developer in the study told us “Quality is doing what the customer wants.” Four years into this shift, we can measure changes in the machinery of software production with extraordinary precision while remaining largely blind to what may be the most important dimension of quality: did the thing we built serve the people using it?

Quality was never just about the code

Put the five dimensions back together and the story isn’t that AI is improving quality. It also isn’t that AI is destroying it. The story is that “quality” was never a scalar.

Seen this way, the maintainability/change-confidence paradox that started this piece doesn’t look like a paradox anymore. It looks like exactly what we should expect when a multidimensional construct is being pushed in different directions at once.

Six years on, I don’t think AI makes TRUCE less useful. If anything, it makes the framework more useful by reminding us what we’re actually trying to preserve. We still want software that is robust, evolvable, collaborative, timely, and serves the people using it.

What may be changing is where we need to look to understand whether we’ll get those things.

Reuse requires knowing what already exists in the codebase. Review requires knowing what a change was meant to accomplish. Evolvability requires knowing why the system is structured the way it is. Handoff requires knowing what the previous person was thinking. Serving user needs requires knowing what problem the software was supposed to solve in the first place.

None of that knowledge necessarily lives in the code.

Margaret-Anne Storey, my TRUCE co-author, has arrived somewhere similar from a different direction. Her triple debt model separates technical debt, which lives in code, from cognitive debt, which lives in a team’s shared understanding, and intent debt, which lives in the artifacts recording what a system is for.

Her argument is that AI may reduce one kind of debt while accelerating the others, and that code is no longer necessarily the binding constraint on software health.

Her model maps to the findings we just walked through. Technical debt is visible in the evolvability problem. Cognitive debt shows up in the collaboration split. And intent debt helps explain why it is so difficult to know whether a system is meeting real user needs, the dimension we can barely see at all. Hers is a conceptual model rather than an empirical one, so I’d call this convergence rather than confirmation. But two frameworks built for different purposes landed on the same three places.

There’s a small irony worth noting. When Mansi Khemka and I asked developers in 2023 what they most wanted AI help with, authoring and refactoring code ranked fifth, at 25%. Documentation ranked third at 37%.

Documentation is now one of the clearest quality wins in the data. Refactoring is one of the structural signals moving most sharply in the other direction.

I wouldn’t read too much into a single comparison. But it is interesting to me that the dimension holding up best is the one where the tooling matched what developers said they wanted.

Which brings me back to the artifact itself. We have spent decades learning to evaluate code. It is worth asking whether code is still the thing that carries the most information about whether these five dimensions will hold.

Code is not the only artifact worth evaluating

For most of software’s history, code was the currency of software engineering. A developer understood the requirement, carried some model of the architecture in their head, knew what neighboring systems did, made a series of design decisions, and eventually expressed those decisions as code. That made code an unusually information-rich artifact, and it is why evaluating the code was a critical way to evaluate the work.

That is changing. The Q2 report found that 52.7% of code is AI-authored, up from 24% in Q4 2025 and 34% in Q1 2026. Increasingly, a developer doesn’t translate everything they know directly into code. They express an intent, provide some representation of the relevant context, and ask a machine to produce the implementation.

Intent and context aren’t quite the same thing. Intent is what a person ultimately wants to accomplish. That intent must then be translated into context, which is the information that represents the task, its constraints, and the surrounding knowledge. More of the knowledge a developer once carried implicitly now has to be externalized before the work can begin.

TRUCE still gives us language for evaluating the artifact at the end of that chain, and AI doesn’t change that. What concerns me is that the end of the chain is becoming a late place to look. As development shifts from writing implementations toward expressing intent, more of the conditions that determine all five dimensions are set before any code exists.

We know how to ask whether the artifact is good. We’re only beginning to develop the vocabulary for asking whether the context that produced it was good enough to begin with.

That’s it for this week. Thanks for reading.

-Brian

Share

In this episode of Engineering Enablement, I sit down with Max Kanat-Alexander, Executive Distinguished Engineer at Capital One, to discuss how AI is changing software development and why strong engineering fundamentals matter more than ever.

We explore how the skills engineers need are expanding, why AI amplifies both the strengths and weaknesses of the development lifecycle, and how teams should think differently about code review, quality, and testing. Max also shares how leaders can assess whether their organizations are ready for more advanced AI workflows and why we need more research into how junior engineers become senior engineers.

Some takeaways:

AI amplifies the engineering system you already have

• Strong engineering fundamentals matter even more with AI. AI amplifies everything that is good or bad about a software development lifecycle, so teams with strong tooling, CI, testing, and workflows are positioned to see the greatest gains.

• Faster coding doesn’t solve problems elsewhere in the development lifecycle. If engineers spend significant time navigating broken processes, waiting for reviews, or dealing with poor tooling, accelerating code generation only addresses a small part of their work.

The skills engineers need are changing

• Clearly expressing requirements and providing feedback are becoming increasingly important engineering skills. These are capabilities senior engineers have traditionally developed through years of experience, but they become essential much earlier when working effectively with coding agents.

• Deep technical knowledge still helps engineers recognize when something is wrong. Experience with languages, systems, and software design develops the pattern recognition needed to spot a flawed approach without reviewing hundreds of lines of AI-generated code.

• Domain understanding and problem definition are becoming more valuable. As AI gets better at reproducing knowledge found in documentation, engineers can differentiate themselves through understanding what needs to be built and why.

Code review is fundamentally about maintainability

• Human code review shouldn’t be the primary way teams catch bugs. Tests, static analysis, and other automation are more effective and scalable ways to detect defects.

• Human judgment remains important for evaluating maintainability and design. Reviewers can assess whether code is understandable, structured appropriately, and aligned with the longer-term intent of a system.

• The right quality bar depends on the codebase. A disposable script and enterprise software expected to operate for a decade shouldn’t be subjected to identical standards because the consequences and costs of getting them wrong are very different.

Not every change needs the same review process

• Code review is an important tool for developing less experienced engineers. Max says reviewing someone’s code is the most effective way he has found to improve their core software engineering skills.

• Trusted engineers may not need every change reviewed on codebases they deeply understand. That trust should be specific to the combination of the person and the codebase, rather than becoming a blanket exemption from review.

• The risk of the individual change can also determine whether human review is necessary. Teams can evaluate confidence and potential consequences rather than requiring the same review process for every PR.

AI can create a vicious cycle of declining code quality

• AI struggles when it has to build on poorly structured, poorly tested code. When weak review allows its bad output back into the codebase, the code becomes even harder for AI to work with, creating a cycle that can eventually leave teams with systems they can’t understand or maintain.

• AI can also help teams reverse that cycle. Agents can write tests, improve testability, and are particularly effective at refactoring when engineers deliberately direct them toward improving the codebase.

• Refactoring should support forward progress on product goals. Rather than attempting to clean up an entire codebase, teams should improve the parts they need to touch for upcoming work and make the necessary developer experience improvements along the way.

AI readiness depends on how far left rigor extends

• Fixing an existing software development lifecycle is much harder than building a good one from the beginning. Organizations with weak engineering practices often have to start with production problems and work backward through incident management, observability, deployment, testing, and earlier stages of development.

• How far left rigor extends is a useful signal of AI readiness. Organizations without strong controls around production, code review, and testing may introduce significant risk by giving engineers tools that allow them to move much faster.

• Leaders should evaluate the organization they actually have rather than following the AI hype cycle. Max is bullish on AI adoption, but argues that organizations need the engineering foundations to support the additional velocity it creates.

The industry needs a better way to develop senior engineers

• We still know surprisingly little about what reliably turns junior engineers into senior engineers. Mentorship and apprenticeship are widely considered important, but the practices that actually produce experienced engineers have not been deeply studied.

• AI makes understanding that development path more urgent. Senior engineers rely on experience to recognize failure patterns, which raises questions about how newer engineers will acquire that judgment as AI takes on more of the implementation work.

• AI may ultimately increase the need for engineering expertise rather than reduce it. As hundreds of millions more people gain the ability to build software and the rate of change accelerates, Max believes the world will need more experienced engineers to manage that complexity.

In this episode, we cover:

(00:00) Intro

(01:54) Max’s role at Capital One

(02:52) Where to invest in engineering organizations

(06:36) The new entry-level engineering skills to pay attention to

(10:39) Why deepening your understanding still matters

(12:29) The bottlenecks around code review

(19:40) Why human code reviews still have value

(25:20) Why not all PRs need human review

(26:11) The vicious cycle of AI-driven development

(30:13) Using LLMs for refactoring

(33:58) AI readiness and why fixing engineering systems is so hard

(38:42) Why research is needed on creating good senior engineers

(41:00) Why AI will increase the need for engineers

Where to find Max Kanat-Alexander:

• LinkedIn: https://www.linkedin.com/in/mkanat

• X: https://x.com/mkanat

• Blog: https://www.codesimplicity.com

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• DX Core 4 Productivity Framework

• Capital One

• Code Review Guidelines at Google

• Code Simplicity by Max Kanat-Alexander

• How Microsoft sees engineering bottlenecks changing with AI

Subscribe now

An engineering leader recently asked me how to measure whether their team is predictable in their software delivery. While organizations collect many engineering metrics (cycle time, throughput, review latency, deployment frequency, etc.), there is rarely a single metric that directly measures predictability.

The central question is:

Can we use the metrics we already collect to quantify delivery predictability?

Higher delivery predictability enables more accurate release planning, resource allocation, dependency management, and stakeholder communication. Improving predictability is therefore not simply about increasing throughput; it is about increasing confidence in engineering plans.

Key observation

Delivery predictability is not another engineering metric; it is a statistical property of a delivery process.

Traditional metrics tell us how much work teams complete or how long work takes. Predictability tells us, given historical performance, how confidently can we forecast future delivery? Predictability is a measure of uncertainty. For example, a team that consistently delivers 20 work items each sprint is highly predictable. A team that alternates between delivering 5 and 35 work items may have the same average throughput, but is far less predictable. The distinction is not average performance. It is variation.

A note on two lenses. “Delivery predictability” can mean two related but distinct things. The first is flow stability: how consistent and low-variance a team’s delivery is over time. The second is commitment reliability: how closely actual delivery matches what was committed (a ratio of committed vs. completed work). This article focuses on flow stability, because it can be derived directly from the metrics most organizations already collect.

Example

Let’s walk through a practical example of two hypothetical teams’ count of completed work items, by sprint:

Both teams deliver exactly the same average throughput. The difference is that Team A is predictable while Team B is not. The remainder of this article describes several statistical techniques that quantify this difference.

What different statistical techniques tell us

The following statistical techniques each answer a different question about delivery predictability using the Team A and Team B example.

Standard deviation

Standard deviation measures how much a team’s delivery typically varies from its average. A low standard deviation means delivery is consistent from sprint to sprint, while a high standard deviation indicates greater volatility.

In our example, both teams average 20 completed work items per sprint. However, Team A’s delivery stays tightly clustered around that average, while Team B swings between 10 and 30. Team B therefore has a much larger standard deviation, despite identical average throughput.

Leadership takeaway: Standard deviation answers the question, “How much does this team’s delivery naturally fluctuate?” It is often the simplest way to quantify delivery consistency.

Coefficient of variation

Standard deviation alone can be misleading when comparing teams of different sizes. A team delivering 80 ± 5 work items is more variable in absolute terms than Team A (20 ± 1.3), but proportionally it is just as predictable.

The coefficient of variation normalizes the standard deviation by the team’s average throughput, allowing comparisons across teams regardless of scale.

Although Teams A and B have the same average in our example, this measure becomes valuable when comparing organizations with very different delivery volumes.

Leadership takeaway: Which teams are most predictable relative to the amount of work they deliver?

Percentiles and distribution shape

The sections above use throughput per sprint. Percentiles are most illuminating on a per-item measure such as cycle time, the number of days a work item takes to go from started to done, so this section shifts to that lens.

Averages describe the typical case, but predictability is usually broken by the atypical case. Percentiles, rather than the mean, show how often delivery runs long and by how much.

Consider two teams that both have a median (P50) cycle time of 4 days. If the first team’s 95th percentile (P95) is 7 days while the second team’s P95 is 21 days, they are not equally predictable. The first team’s slowest work is only modestly slower than its typical work. The second team’s slowest work takes three weeks, even though half its items finish in under four days.

The gap between P50 and P95 is, in effect, a predictability measure of its own. A tight gap means most work behaves like the typical case. A wide gap means the typical case tells you little about the work that actually puts a commitment at risk.

This is why a healthy median can still mask an unpredictable process: it is the tail, not the middle, that causes missed forecasts.

Leadership takeaway: When we commit to a date, are we planning against the typical case or the realistic worst case? Percentiles let us answer, “X% of work of this type finishes within N days,” a far more honest basis for a forecast than an average.

Statistical process control (control charts)

Control charts answer a different question. Rather than measuring overall variability, they determine whether a delivery process has fundamentally changed.

Suppose Team A suddenly delivered 9 work items in Sprint 4 instead of its usual ~20. While the average throughput might not change much immediately, a control chart would likely flag Sprint 4 as outside the team’s normal operating range.

This often indicates that something meaningful occurred, such as a production incident, staffing change, organizational restructuring, or dependency bottleneck.

Leadership takeaway: Did something change that warrants investigation, or is this simply normal variation?

Prediction intervals

Prediction intervals translate historical variability into forward-looking planning confidence. Rather than forecasting that Team A will complete exactly 20 work items next sprint, we estimate the range it is likely to land in.

Using a 95% prediction interval, Team A is forecast to deliver roughly 17 to 23 work items next sprint. Team B, with the identical average, is forecast at 0 to 40.

That second range deserves a moment. Team B’s forecast spans from delivering nothing to delivering twice its average. It is technically correct and completely useless for planning, which is precisely the point. Team B does not have a throughput problem. It has a forecasting problem, and no average will ever surface it. Notice that neither team’s average changed. Only the confidence around that average did.

The practical implication is that interval width, maybe more than the forecast itself, is the thing worth tracking over time. A team whose range narrows is becoming more predictable, even if its average never moves.

Leadership takeaway: How confidently can we forecast future delivery, and how wide is the range we should plan against?

Beyond the spreadsheet: machine learning

Everything above can be done in a spreadsheet. That’s deliberate. But if you have the data volume and the appetite, traditional machine learning (not LLMs) extends three of these techniques in genuinely useful ways.

Conditional forecasting. The prediction intervals above are team-level, with one range for everything the team does. Quantile regression forests and conformal prediction produce intervals conditioned on the specific item. Given its size, component, and the current queue depth, this work finishes in 3 to 12 days with 90% confidence. That’s a better input to a release plan than a team-wide average.

Survival analysis for work in flight. Cycle time statistics only describe items that have already finished, which quietly biases the picture toward work that went well. Survival models handle still-open items correctly and answer the question planners actually ask: what is the probability this item ships before the release date?

Driver attribution. Identifying what explains variation is hard, and the place modeling can really earn its keep. A gradient-boosted model with SHAP values can rank which operational signals (review latency, WIP, incident load, dependency count) account for the most variance in delivery. Treat the output as associational and as a hypothesis generator, not as evidence of cause.

Two caveats. Many teams don’t have enough history for any of this. Eight sprints is a worked example, not a training set. And the second caveat is that you need good workflow data hygiene. A model trained on tickets that sat in “In Review” for three weeks after they were actually merged will confidently forecast fiction.

Start with the spreadsheet.

Recommendation: Avoid a single predictability score

While it may be tempting to distill delivery predictability into a single score, I recommend against doing so. A single number simplifies reporting, but it can also obscure important differences between teams and make it difficult to identify the underlying causes of delivery risk.

For example, teams may all receive similar scores while exhibiting fundamentally different delivery characteristics:

• Consistently fast – High throughput with low variability.

• Consistently slow – Lower throughput, but reliable and predictable.

• Highly variable – Similar average performance, but large sprint-to-sprint fluctuations.

• Steadily improving – Predictability changing over time as the team’s delivery process matures, which a point-in-time score hides entirely.

Rather than reducing predictability to a single KPI, I recommend reporting three complementary views:

This approach preserves the information leaders need for planning while providing engineering teams with actionable insights into where process improvements will have the greatest impact.

Recommendation: Use a multi-step approach

I recommend measuring delivery predictability in four steps:

1. Select a delivery outcome. Choose a metric that represents delivery performance, such as throughput, completed work items, cycle time, or PR completion time.

2. Measure historical variability. Quantify how consistently that outcome is achieved over time using techniques such as standard deviation, percentiles, and control charts.

3. Forecast future delivery. Use prediction intervals to estimate a range of likely outcomes rather than relying on a single point estimate.

4. Identify the drivers of variation. Use existing engineering metrics, such as review latency, incident load, build reliability, focus time, or team composition, to explain changes in predictability and surface opportunities for improvement.

The goal is not to eliminate variation, but to understand it well enough to plan around it.

That’s it for this week. Thanks for reading.

-Brian

Share

Subscribe now

DX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.

When teams reduce the time it takes to complete a pull request, it’s natural to assume they’ll be able to deliver more work, but this relationship is rarely quantified at scale. A customer recently brought this question to DX’s Research team, asking us to look into the relationship between PR cycle time and PR throughput.

Key takeaway: High-throughput organizations are highly sensitive to long cycle times, potentially indicating that bottlenecks like review wait times are particularly acute for these orgs. For lower-throughput teams, there is no meaningful relationship between cycle time and throughput, suggesting bottlenecks exist elsewhere.

Queuing theory behind cycle time and throughput

Little’s Law, a theorem from queuing theory, helps explain the relationship between three things: how much work is in progress (WIP), how quickly work gets completed, and how long each piece of work takes. For software teams, we can think of these as:

• WIP: the number of pull requests currently open,

• Pull Request (PR) Throughput: number of pull requests merged over a period of time, and

• PR cycle time: how long a pull request takes to move from development through review and merge.

The equation is straightforward. When the amount and type of work stay relatively consistent, work that moves through the process faster can help a team complete more work over time. This relationship is commonly used to explain how software teams improve flow but it hasn’t yet been quantified in the developer productivity space.

Research by Maddila et al. shows that pull requests often spend significant amounts of time waiting, not being actively coded or reviewed, and implies that cycle time isn’t a fixed metric. Teams can recover some of that waiting time by improving the workflow around development and review, without changing the process of writing code.

To understand how PR cycle time relates to throughput, we looked at the relationship between median PR cycle time and average PR throughput per developer across organizations using data from 500+ DX customers from January-July 2026, inclusive.

Cycle time matters more for high-throughput organizations than it does low-throughput organizations

Our analysis suggests that PR cycle time is not a reliable standalone predictor of throughput. In the raw data, organizations with similar review speeds show a wide range of throughput levels, indicating that other factors, like PR size and organizational context, likely play an important role in determining output.

The median trend is relatively flat across most of the distribution, with throughput beginning to decline more noticeably only at longer cycle times. This indicates that reducing cycle time may not automatically increase throughput for every organization, particularly when teams are already operating within a typical throughput range.

Because median results can obscure differences across the performance distribution, we also used quantile regression to look at this relationship at the 25th, 50th, 75th, and 90th percentiles of throughput. This approach allows us to look at whether the association between cycle time and throughput changes for lower-, median-, and higher-throughput organizations.

The results show that the relationship between cycle time and throughput is concentrated among higher-performing organizations.

• At the 25th percentile, there is no statistically significant relationship between cycle time and throughput (p=0.366, β=-1.1).

• At the median, there is a modest but statistically significant negative relationship (p=0.0008, β=-4.0).

• At the 75th and 90th percentiles, the negative relationship becomes substantially stronger and remains statistically significant (p=0.000, β=-11.7; p=0.000, β=-12.8).

In practical terms, high-throughput teams are the most sensitive to cycle time slowdowns. For teams already in the bottom 25% of throughput, cycle time barely matters. For teams in the top 10%, it matters quite a bit.

Final thoughts: Speed is a safeguard but not a universal solution

Across most organizations, throughput stays fairly steady as PR cycle time increases. The relationship between the two becomes more noticeable around 17 hours. Beyond that point, median throughput starts to decline. This makes 17 hours a useful inflection point, not a universal target. For teams below that point, reducing cycle time may not lead to a meaningful increase in throughput. But once cycle times go beyond it, longer review cycles may start to limit teams that have the capacity to deliver more.

Think of the 17-hour mark as a warning sign and not a productivity cutoff. Teams with longer cycle times may benefit from looking more closely at review queues, reviewer availability, PR size, and other sources of waiting. These results show an association, not proof that longer cycle times directly cause lower throughput. Cycle time is most useful when considered alongside quality, work complexity, team structure, and other developer-experience measures, not as a standalone productivity target.

This week’s featured DevProd job openings. See more open roles here.

• Ashby is hiring an Staff Platform Engineer | Remote

• Carta is hiring a Sr. Software Engineer II, Developer Experience | Santa Clara, CA; San Francisco, CA; New York, NY

• Figma is hiring a Staff Software Engineer, Developer Experience | Remote; US

• Mastercard is hiring a Vice President, Software Engineering | New York

• Notion is hiring a Software Engineer, Developer Experience | Hybrid; Hyderabad, India

Share

AI adoption among software developers is approaching 100%, AI-authored code now makes up more than half of merged code, and developers report saving more time with AI every quarter. But those gains aren’t translating evenly into better outcomes.

In this episode of Engineering Enablement, I sit down with Justin Reock, Deputy CTO at DX, to unpack findings from our latest AI Impact Report. We explore where AI is improving engineering velocity and developer experience, where concerns are emerging around PR size, change confidence, and failure rates, and why rising AI spend has yet to produce a comparable increase in innovation.

We also discuss how AI is changing the meaning of code maintainability and where developers’ AI-driven time savings may actually be going.

Some takeaways:

AI adoption is no longer the interesting question

• AI adoption is approaching 100%, making adoption itself a less useful measure of success. DX sees 95% adoption through telemetry, and even developers outside that group are merging AI-generated code into production.

• The more important question is how effectively developers are using AI. As adoption becomes nearly universal, organizations need to look beyond usage and understand how sophisticated their AI usage is and whether or not it is producing meaningful outcomes.

AI is increasing engineering velocity, but the gains need context

• Developers report saving more time with AI each quarter, while PR throughput and deployment frequency are also increasing. Recent causal research gives additional evidence that AI is contributing to the increase in throughput.

• More than half of merged code is now AI-authored. But metrics like time saved, code generated, and PR throughput don’t tell us on their own whether teams are creating more customer value.

Larger PRs create risks that extend beyond code review

• Average PR size has increased from 42 to 72 lines of code, raising concerns about quality and code understanding. Larger PRs are harder to review and revert, more likely to be rubber-stamped, and can move more slowly through the development system.

• Code bloat can also create a vicious cycle of rising AI costs. As agents generate larger codebases, future agents have more code to read into context, consuming additional tokens repeatedly rather than creating only a one-time cost.

Developers can change code more easily while trusting it less

• Code maintainability is improving while change confidence is declining, even though those measures have historically been closely correlated. AI may make code easier to understand and modify while leaving developers less confident that their changes won’t break something in production.

• AI may be changing what “maintainable” code actually means. If developers increasingly rely on agents to understand and modify code, traditional measures of maintainability and ownership may no longer capture the same things they once did.

AI is amplifying differences between engineering organizations

• Change failure rates are becoming more volatile rather than moving uniformly in one direction. Some organizations continue to perform well while others are seeing higher failure rates, suggesting that AI can amplify existing strengths and weaknesses.

• Developer experience is also showing concerning signals despite clear improvements in areas like documentation. DX’s Developer Experience Index has fallen about 2% over two quarters, with declines in drivers such as incremental delivery outweighing some of AI’s benefits.

AI spending is growing much faster than measurable innovation

• AI spend has risen dramatically, reaching roughly 28 times year-ago levels among the largest companies in the dataset. At the same time, developer ramp-up has improved, but the innovation ratio has increased by only about one percentage point.

• Time saved by AI can easily be absorbed by existing organizational friction. Meeting-heavy days, interruptions, build and test wait times, developer environment toil, and review delays remain major sources of lost time. In one real-world case study, reducing unnecessary meetings produced roughly twice the PR-throughput gains achieved through AI.

• Ultimately, AI efficiency only matters if it translates into customer value. Removing friction and increasing throughput are useful, but the larger question is whether those gains allow organizations to ship more valuable software.

In this episode, we cover:

(00:00) Intro

(01:45) How the current AI impact report is tied to Core 4

(03:24) The state of AI adoption

(05:12) How much time AI is saving developers and percentage of AI-authored code

(07:47) AI’s impact on PR throughput and deployment frequency

(11:09) How EMs are shipping more code

(13:02) Why larger PRs may be problematic

(18:21) The growing gap between code maintainability and change confidence

(21:48) How perceived code quality varies by organization size

(23:49) The growing volatility in change failure rates

(28:07) What the Developer Experience Index reveals

(32:20) Cost, dev ramp-up, and innovation ratio

(35:38) Where AI time savings are getting lost

(37:11) Questions and wrap-up

Where to find Justin Reock:

• LinkedIn: https://www.linkedin.com/in/justinreock

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• DX Core 4 Productivity Framework

• AI Impact report

• The AI-native developer - by Brian Houck

• GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis

• Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools | NBER

• The Productivity-Experience Paradox - Annie Vella

• EngThrive: Make It Fast and Easy to Do Great Work

• The AI efficiency plateau - by Brian Houck

• Tradable Quality Hypothesis

Subscribe now

DX’s updated 2026 engineering benchmarks are now available to all customers, with new Core 4 data across industries and geographies. See 2026 benchmarks here.

Many engineering leaders are right when they tell me that industry benchmarks don’t apply to them. They’re just wrong about what that means.

Most have already looked at a benchmark, compared it to their own numbers, and concluded the comparison isn’t useful. The mistake isn’t recognizing that their organization is different—it’s expecting a benchmark to answer a question it was never designed to answer.

Organizational context genuinely matters. Smaller engineering organizations consistently outperform larger ones on many metrics. Technology companies spend more time on new features than traditional enterprises. Mobile engineering has sufficiently different workflows that it warrants its own benchmark segment. Even survey response styles differ systematically across regions, making some absolute comparisons misleading.

The mix of factors goes far beyond things we can easily segment. Every engineering organization has its own governance model, release process, architecture, regulatory requirements, engineering culture, and history. Some require five approvals before deployment; others deploy continuously. Some invest heavily in internal platforms;others rely on commercial tooling. These choices can dramatically affect developer metrics, making two organizations within the same industry or size cohort look very different from each other.

Those differences are real, but they don’t make benchmarking useless. They simply mean we’ve been asking benchmarks to answer the wrong question.

Exec summary

• Engineering leaders are often right that benchmark values don’t directly apply to them, but they are wrong to dismiss benchmarks entirely.

• Benchmarks, internal trends, and benchmark trends each answer a different question:

  • Benchmark levels → Are we normal?

  • Internal trends → Are we improving?

  • Benchmark trends → Are we improving faster than everyone else?

• The third question (“Are we improving faster than everyone else?”) is often the most important when evaluating investments like AI tools or process changes.

• Benchmark trends help separate your results from broader industry tailwinds (e.g., AI adoption, economic shifts)

• Benchmark values are still useful for identifying unusual performance and areas worth investigating.

• DX data shows metrics consistently move in the same direction across very different organizations year over year, suggesting organizations are less unique than they may believe.

• Changing metrics, survey instruments, or org structure mid-window makes it challenging to use benchmarks to measure change

• Benchmark trends won’t prove causation, but they meaningfully reduce uncertainty about what would have happened anyway.

• The real value of benchmarks isn’t knowing if you’re average, it’s reasoning more carefully about change.

Benchmarks and trends answer different questions

Benchmarks and trends answer fundamentally different questions.

• A benchmark answers: Is this normal? That question is often more valuable than we give it credit for. Knowing that your review latency or deployment frequency is unusual can help identify where deeper investigation is warranted, even if the benchmark itself doesn’t explain why. It tells you where you sit within a distribution. That’s a question about levels, and levels are influenced by things you may never be able to change like your industry, your size, your regulatory environment, your architecture, and the countless organizational decisions that shape how engineering gets done.Your own historical trend answers a different question: Are we improving? That’s a question about change. Because you’re comparing yourself to yourself, most of the differences that make your organization unique simply cancel out.

Both questions are valuable, but neither is the question engineering leaders usually care about most. The question they really want answered is: Are we improving faster or slower than everyone else?That’s a fundamentally different question, and it’s one that neither a benchmark nor an internal trend can answer on its own.

Suppose your deployment frequency improves by 15% over the next year. Is that good? If the rest of the industry improved by only 5%, you’re pulling ahead. If everyone else improved by 30%, you’re falling behind. In other words,improvement alone can’t tell you whether you’re pulling ahead or just keeping pace. Likewise, a benchmark can’t answer it by itself either. Knowing you’re at the 60th percentile today doesn’t tell you whether you’ve been gaining ground or losing it.

To answer the question leaders actually care about, you need both.That’s where benchmarks show their value, even for organizations that genuinely are unique. They don’t require your absolute metrics to be directly comparable to another company’s. They simply show you that the change in your organization can be interpreted alongside the change in everyone else’s.

And that, it turns out, is a far easier condition to satisfy.

Benchmark trends as an observational control group

The reason I find benchmark trends so valuable has very little to do with benchmarking. It has to do with causal inference.

Now suppose that 15% improvement in deployment frequency followed an investment in an internal developer platform. Was the platform responsible? Maybe. But maybe AI coding assistants became dramatically better during the same period. Maybe developer workflows improved across the industry. Maybe a slowing economy reduced feature work and increased engineering capacity everywhere.

A simple before-and-after comparison can’t distinguish between those explanations. That’s where benchmark trends really begin to shine. They don’t tell you what your metrics should have been; they tell you what happened to comparable organizations over the same period. They become an observational control group, a way of estimating the background improvement that would likely have occurred even if you had done nothing.

They’re not perfect. Organizations aren’t randomly assigned to different engineering strategies, and no benchmark population is identical to yours. My point is that they don’t have to be. If your deployment frequency improves 15% while comparable organizations improve 5%, that’s evidence that something beyond the broader industry trend may be happening inside your organization.

This is actually how measurement teams already communicate internally, even if they don’t describe it this way. When one engineering organization of roughly 3,000 developers adopted an AI agent to reduce live-site toil, the result wasn’t reported as the absolute changes in incident mitigation time. It was reported that mitigation time improved 2.4x faster than the company as a whole.

Nobody cared whether that organization’s services looked like the company average. The claim wasn’t about absolute performance. It was about relative improvement.

Your organization is less unusual than you think

At this point, there is still a reasonable objection.

Organizations don’t just differ in their absolute metrics, they also respond differently to new tools, new processes, and new ways of working. If every company has its own architecture, engineering culture, governance model, and technical debt, why should we expect benchmark trends to tell us anything useful at all?

I don’t think there’s a complete answer to that question, but I do think there is strong evidence that benchmark trends are more transferable than we expect.

Part of the reason is psychological. Researchers have studied our tendency to believe that our own situation is more unusual than it actually is. It’s called uniqueness bias. Organizations can fall into the same trap. Every company has a list of reasons why their engineering organization is unlike everyone else’s, and many of those reasons are legitimate. Organizational theorists have argued for decades that organizations facing similar environments tend to converge in their structures and practices, despite many local differences.

I’ve seen this in DX’s own benchmark data, and the pattern keeps repeating year after year. In our 2025 benchmarks, change confidence improved across every segment, with the median rising more than 12 points. Cross-team collaboration declined across every segment. In 2026, different metrics told the same kind of story. Documentation improved across every segment and customer focus rose across all of them, while review turnaround and incremental delivery declined across most.

These segments differ by size, by sector, and by geography, and their absolute values differ substantially. Yet year after year they move in the same direction at roughly the same time. If organizational context dominated the way the uniqueness objection assumes, we would expect these trajectories to diverge. Mostly they don’t. Those organizations weren’t identical, but they were responding to many of the same underlying forces.

It should be noted that direction and timing are shared, magnitude isn’t. Segments improved on the same metrics in the same years without improving by the same amounts, and individual organizations within a segment vary more still. Benchmark trends need both properties. Shared direction is what makes the baseline trustworthy. Dispersion around it is where your own signal lives. A control group is useful precisely because it behaves predictably, and the same is true here. Co-movement isn’t evidence that there’s nothing left to detect. It’s what makes detection possible.

This isn’t unique to engineering metrics, either. Economists routinely compare countries with different political systems, cultures, and industrial structures. Healthcare researchers compare hospitals serving very different patient populations. Education researchers compare schools with very different student demographics. None of these comparisons are randomized experiments, and none produce perfect control groups. Yet they’re still valuable because the alternative is to assume that nothing else in the world changed while your intervention took place.

I don’t think benchmark trends eliminate that uncertainty, but I do think they substantially reduce it. They’re not a replacement for understanding your own organization. They’re a way of putting your organization’s improvement into context.

You can’t trend against a moving ruler

Aligning to this way of thinking does change some of the advice we’ve historically given. We’ve encouraged organizations to improve their benchmark position over time, and I still think that’s good advice. Absolute benchmark values provide valuable context. They help answer whether your organization looks unusual relative to similar organizations, identify potential areas of opportunity, and highlight where deeper investigation might be worthwhile.

But once you understand where you stand today, the more interesting question becomes whether you’re improving faster than the background trend.

That distinction matters because organizations don’t improve in isolation. New tools, changing engineering practices, AI adoption, and broader industry shifts all influence engineering metrics over time. Benchmark trends help separate improvements that are happening everywhere from improvements that may reflect something unique about your organization.

This also explains why organizations that don’t trust absolute benchmark values shouldn’t dismiss benchmark data entirely. Even if your architecture, culture, or regulatory environment makes direct comparisons difficult, organizations facing similar external forces can still provide valuable context for understanding how quickly the world around you is changing.

That said, comparing changes only works for the things that hold still. If you reorganized, acquired a company, or changed how you count engineers during the same window, those differences don’t cancel either, and your trend becomes as hard to interpret as your levels were. Changing a metric definition or a survey instrument partway through does the same damage. You can’t trend against a moving ruler, which is why, for trend analysis, consistency in how you measure matters more than precision in what you measure.

None of this makes benchmark cohorts less important. The better your comparison group, the better your estimate of that background trend.

Absolute benchmarks tell you where you are. Internal trends tell you whether you’re improving. Benchmark trends help answer whether you’re improving faster than you would reasonably have expected.

What we still don’t know

I can’t yet prove that benchmark trends consistently produce better decisions than benchmark levels alone. I also don’t know which comparison groups produce the most useful estimates of background improvement, or how similar two organizations need to be before their trends become informative.

Those are empirical questions, and I think they’re worth studying.

My intuition is that benchmark trends won’t eliminate uncertainty. They simply provide another source of evidence. Like any observational control, they’re imperfect. But imperfect evidence can still improve decision making when it’s interpreted appropriately.

Final thoughts

Benchmark trends aren’t a replacement for internal metrics, experiments, or randomized trials. Whenever we can run controlled experiments, we should.

But most engineering organizations don’t make decisions under laboratory conditions. We launch AI coding assistants to everyone at once. We reorganize teams. We change review processes. We invest in developer platforms. We rarely have the luxury of a true control group.

That means engineering leaders spend much of their time making decisions from imperfect evidence.

Benchmark trends make that evidence meaningfully stronger. They don’t eliminate uncertainty. They don’t prove causation. They don’t guarantee that one intervention caused another outcome. They simply provide a better estimate of what might have happened anyway.

To me, that’s the real value of benchmarks. Not because they tell us whether we’re average. But because they help us reason more carefully about change.

That’s it for this week. Thanks for reading.

-Brian

Share

Building on this year’s inaugural event, which brought together 500 senior engineering leaders from companies like Microsoft, Airbnb, Uber, Vanguard, Dell, and BNY, we’re expanding to two cities for 2027.

In both San Francisco and London, DX Annual will be a single-day event with keynotes, fireside chats, and peer roundtables built around how organizations are rethinking developer productivity and how software is delivered with AI. The event will once again focus on curated attendance, meaningful peer connections, and sessions led by practitioners.

Save the dates ↓

• San Francisco — May 6, 2027

• London — September 23, 2027

Register your interest

In this episode of Engineering Enablement, I sit down with Tim Bozarth, Corporate Vice President in Microsoft CoreAI and leader of Microsoft’s Engineering Thrive initiative. We discuss Engineering Thrive, Microsoft’s framework for measuring and improving engineering productivity, and why AI makes outcome-based metrics more important than ever.

Tim shares how AI is reshaping the software development lifecycle, where new bottlenecks are emerging, and why verification and confidence may become more valuable than code generation itself. We also explore why the purpose of engineering remains the same despite rising levels of abstraction, the skills that remain durable in an AI-driven world, and why engineering leaders should focus on outcomes rather than activity metrics.

Some takeaways:

Engineering Thrive gives Microsoft a common language for improving productivity

• Engineering Thrive defines productivity through speed, ease, and quality. Its goal is to make it fast and easy to do great work by identifying friction across the developer experience rather than optimizing isolated activities.

• Speed, ease, and quality should not be treated as opposing goals. Engineering Thrive applies a “do no harm” principle: an improvement in one dimension should not be celebrated if it makes another materially worse.

• The framework helps Microsoft identify bottlenecks and invest where they will have the greatest impact. Tim argues that developer time is one of the company’s most valuable resources, making productivity improvements a strategic investment.

AI makes outcome-based metrics more important, not obsolete

• The industry is returning to activity metrics it rejected years ago. Tim sees renewed attention to lines of code, pull request counts, and similar measures as a search for easy answers to how AI is affecting productivity.

• More engineering activity does not necessarily mean more value. Engineering Thrive instead measures outcomes such as product quality, end-to-end speed, and the amount of time engineers can devote to innovation.

• A web of outcome metrics is harder to game than any individual measure. Looking across speed, ease, quality, and innovation time creates a more durable picture of whether an organization is actually improving.

Planning and validation are becoming the new bottlenecks

• Before AI, most engineering time was spent creating and operating software. Tim estimates that those phases historically accounted for more than 90% of engineering time, with operations alone consuming roughly 70% to 80%.

• On frontier teams, the bottlenecks have already shifted to planning and validation. Code creation is taking dramatically less time, while deciding what to build and determining whether the result is trustworthy are consuming a greater share of the work.

• The create phase may continue to shrink as models and agent harnesses improve. Tim expects planning and validation to remain durable constraints over the next several years, even as other parts of the software development lifecycle become increasingly automated.

The code review bottleneck is really a confidence bottleneck

• Higher PR throughput has increased the amount of change humans must evaluate. Enterprise software still requires a level of trust that teams cannot achieve by simply accepting AI-generated code without review.

• Code review is only one way to establish confidence. Testing, continuous rollouts, feature flags, canaries, and deployment practices all contribute signals about whether a change is reliable.

• The next generation of verification should help humans ask higher-level questions. Rather than inspecting every branch or class, engineers should be able to assess the scope, complexity, impact, and fundamental purpose of a change.

More abstraction does not change the purpose of engineering

• AI will reduce the time engineers spend on low-level implementation details. Tim sees that as another step in the long history of abstractions that allow engineers to spend more time describing system behavior and intended outcomes.

• Great engineers have never been defined by their ability to write a line of code. Their value comes from systems thinking, understanding objectives, and expressing functional and nonfunctional requirements coherently.

• Producing more software increases the need for strong engineering judgment. The faster organizations can build, the more important it becomes to ensure that their systems remain coherent, valid, and reliable.

A maker’s mindset and ability to experiment effectively remain durable advantages

• The maker’s mindset is relentlessly oriented toward producing a valuable final outcome. It combines a clear vision of what should be built with the ability to understand the needs of the customer using it.

• Engineers will need to continuously experiment and evaluate changes in outcomes. Tim argues that this discipline is no longer limited to model trainers; everyone using AI tools must determine whether a new approach actually improves the result.

• Using AI is not itself the goal. The goal is to accomplish more, and sometimes the best way to do that will be not to use AI at all.

Engineering leaders should measure idea-to-value, not PR velocity

• PR velocity says little about the success of an engineering organization. Tim urges leaders to stop evaluating teams through activity measures the industry already recognized as inadequate years ago.

• Idea-to-value connects engineering work to meaningful outcomes. Leaders should also examine how much time engineers spend innovating compared with keeping the lights on or handling corporate overhead.

• Product quality and business results should remain the ultimate measures of success. Focusing on outcomes can improve developer happiness, productivity, margins, and the value delivered by the organization.

In this episode, we cover:

(00:00) Intro

(02:13) What Engineering Thrive is and the problem it solves

(04:46) Why Engineering Thrive isn’t specific to Microsoft

(09:10) The impact of Engineering Thrive at Microsoft

(14:31) Why AI makes outcome-based productivity metrics more important

(18:22) Where AI is creating new bottlenecks in the SDLC

(24:37) Why more abstraction doesn’t change the purpose of engineering

(27:25) The durable skills of good engineers

(33:03) The changing economics of software development

(36:56) Advice for leaders: measure outcomes, not activity

Where to find Tim Bozarth:

• LinkedIn: linkedin.com/in/tbozarth

Where to find Brian Houck:

• LinkedIn: https://www.linkedin.com/in/brianhouck

Referenced:

• DX Core 4 Productivity Framework

• EngThrive: Make It Fast and Easy to Do Great Work: Building a durable model for outcome-oriented engineering measurement

• Quote by Eliyahu M. Goldratt: “Tell me how you measure me and...”

• Jevons paradox - Wikipedia