---
type: "article"
title: "AI-assisted software development in 2026. Part 2 of 2"
summary: "Adoption, measurement, and the risk of amplified waste\n\nAs I mentioned in the previous part of this article, we are living through an “interesting” moment in the tech industry.\nOver the last year, team morale has been affected by layoffs, including frequent AI-related layoffs, return-to-office mandates, a professional identity crisis, pressure to adopt AI, and broader economic uncertainty.\nThis context does not make it easy for people to understand how they should approach the AI revolution. Many teams are being asked to adopt AI quickly, even evaluated based on their AI usage, but without a clear explanation of what problem they are solving, what good adoption looks like, or how success will be measured. \nThat is why we need clarity.\nStatements such as “we need to use more AI” or “everyone is adopting AI, so we cannot fall behind” have become common during this first half of the year, and they do not explain what problem we are trying to solve, what success looks like, or how we will know whether AI is actually improving the way we work.\nPerformance evaluation should not be based on AI usage. \nMeasuring individuals by how much they use AI, how fast, or how many features they produce using it can create strong perverse incentives. And we still remember when they wanted to measure their performance based on the number of lines of code produced in the past. That was silly then, and it is silly now. People will optimize for the metric, and not necessarily for better outcomes.\nIf AI helps us become more effective and productive, expectations will naturally rise. And if someone can maintain that level of performance without using AI, why should we put extra pressure on them?\nWhat matters more, their performance or whether they use AI to get there? Honestly, choosing the latter reflects short-term thinking and misses the point, at least to me.\nIf we force people to use AI through rewards or punishments, we risk undermining the intrinsic motivation needed to cultivate the mindset we actually want.\nThe importance of a well-designed, shared, harness-based workflow\nA good harness can help us a lot. They provide guidance, clarity, and clear rules based on shared ways of working for AI-assisted software development. Combined with a strong vision, this can be especially valuable for teams navigating this uncertain moment.\nEven if they are useful, we should avoid enforcing these workflows as the only acceptable way to use AI in software development. Enforcing one concrete harness or tool as the only way of working with AI is like trying to hold back the tide.\nA better approach is to present the harness as a golden path. As the recommended way of working, with clear governance, contribution rules, and enough flexibility for teams to adapt it to their context and contribute to the shared skills and other resources in the harness.\nHowever, sharing a concrete visión, a concrete strategy, and concrete ways of working would not be effective if we don’t understand how the paradigm is evolving.\nOur value is changing\nCoding is becoming more individual, but software development still requires collaboration. The difference is that collaboration is moving earlier in the process.\nBecause our work is evolving more and more to multitasking, practices like pair programming are becoming more difficult. So maybe these practices should move to other stages of the workflow, such as discovery, design, review, or validation.\n\nThe problem was never about delivering more features or creating more code. It was about working on the right things.\nNow we can see more clearly that the value is no longer in typing plumbing code. The value is in framing problems, making trade-offs, validating assumptions, and designing systems that can evolve safely.\nInstead of building more just because we can, we should use this new capacity to run more experiments and create more PoCs. This will help us to ensure that the right features enter our delivery flow, rather than generating tons of new features that are not necessarily aligned with customer needs.\nProductivity without effectiveness moves the bottleneck to review\nIncreasing productivity without improving effectiveness just moves the bottleneck downstream to review.\nMore output does not mean more progress. Without effectiveness, productivity only creates a bigger review bottleneck.\n\nAgain, AI can help teams produce more, but the challenge has never been just about producing more. The real challenge has always been about deciding what is worth building.\nAuthors such as Melissa Perri, with Escaping the Build Trap, and Eliyahu Goldratt, with The Goal, taught us this years, and even decades, ago.\nIf we build more features and they are not aligned with our customers’ needs, we are creating inventory. And inventory is expensive. These new features will require review, observability, cloud infrastructure, governance, and maintenance. And this means more cost. \nEven if nobody is using them.\nMeasuring the impact\nDORA helps us measure the delivery system once code starts flowing through it. Its four key metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) give us strong signals about delivery performance and operational health, but it does not tell us whether we are building the right thing.\n\nBecause, as I have repeated throughout this article, AI can help us create value much earlier in the process, like during discovery, problem framing, task definition, and architectural decision-making.\nAnother popular framework is SPACE. It gives us a broader view of developer productivity across different dimensions. Those dimensions are satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.\nSo SPACE is useful to understand developer productivity and experience, but it should not be treated as direct proof of business impact.\nWhat else can we measure?\nDesigning a workflow is a good opportunity to ask ourselves a few questions, frame them as hypotheses, and decide which metrics would help us validate them.\nThis approach helps us understand which parts of the workflow are most important to iterate on, and what impact our AI usage may have in terms of ROI.\nSome questions and metrics to answer them\nIn addition to metrics, we also need success stories. Narratives help show what teams can now build with AI that they could not realistically build before with the same resources.\nConcrete stories are often more persuasive than abstract productivity dashboards. For example, stories like a team shipping a feature in less time, with fewer people, while maintaining or improving quality; a team increasing test coverage as part of the workflow; a team improving documentation and traceability without adding extra process overhead.\nThese examples make the value of AI adoption easier to understand because they connect the metrics with visible outcomes. They show not only that teams are moving faster, but also what they are able to do differently.\nBut we also need to manage expectations. AI adoption does not usually create immediate linear improvement. At the beginning, teams may experience a kind of J-curve. Productivity can temporarily slow down while people learn the tools, redesign their workflows, define new practices, and build trust in the outputs.\nThe intent and cognitive debt\nTechnical debt is no longer the only debt problem. AI-assisted software development introduces additional forms of debt that teams cannot ignore. These are the cognitive and intent debt. The risk is that these can remain invisible while delivery and other metrics look healthy.\nCognitive debt is the gap between how a system actually works and how well the people responsible for it understand it. A system with high cognitive debt will become difficult to maintain, troubleshoot, or evolve because understanding is no longer distributed across the team.\nWe can measure it through indicators such as the number of people able to review or modify a component confidently, the concentration of knowledge in specific individuals, and comprehension checks during reviews. \nPractices such as shared ownership, knowledge-sharing sessions, architecture walkthroughs, and automated comprehension quizzes help reduce cognitive debt by spreading understanding across the team.\nIntent debt is the gap between what a system does and why it was designed in a concrete way. So teams may know how a feature works, but not the reason it exists, what risk it was mitigating, or what alternatives were rejected. As intent debt grows, future changes become riskier because engineers are forced to make decisions without understanding the rationale that shaped the current design.\nWe can measure it through indicators such as the percentage of decisions that lack documented rationale or lack decision records, the number of features whose original objectives cannot be explained, the frequency of “we don’t know why this exists” discussions, or the inability to trace code changes back to requirements. \nPractices such as requirement briefs, ADRs, or at least lightweight decision logs, audit logs for decisions made during AI implementation, traceability between requirements and implementation, and periodic reviews of past decisions help to reduce the intent debt.\nFor both debt types, documentation alone is not enough. \nWith AI, we can generate many more documents than before. But increasing the amount of documentation can become a problem if those documents are not automatically updated, easy to discover, and actively used.\nWe need to socialize them. They need to stay active by being reviewed, discussed, and challenged by the team.\nOne possible automation that can help measure and reduce both cognitive debt and intent debt is a lightweight knowledge check at the end of a task implementation. Or before merging a new feature into the main branch.\nFor example, a subagent can trigger a short quiz generated from the feature context, asking the engineer or reviewer about key aspects of the change.\nQuestions like what concrete problem the feature solves, what new business logic has been introduced, and which technical decisions drove the implementation.\nThe goal would not be to evaluate individuals, but to detect gaps in shared understanding. If people struggle to answer those questions, that is a signal that the AI-assisted workflow may be creating or hiding cognitive and intent debt.\nMeasuring those gaps over time could help teams understand the implications of excessive delegation to AI during implementation.\nWe also need to ensure that our harness provides proper audit logs. If agents and subagents are implementing, reviewing, validating, or modifying software, teams need a clear record of what happened during each session. So we can review which actions were executed, which tools were used, what files were changed, what decisions were made, and where human approval was required.\nFinal ideas\nWe should not forget what we have learned over the last 30 years. Our engineering and product principles are still valid. For example, small tasks help us deliver more efficiently and get feedback sooner.\nWe should invest in discovery by enabling speed and autonomy for experimentation, rather than obsessively increasing the number of new features entering our delivery pipeline. This means taking advantage of the AI power to create more PoCs and more experiments before investing in more features.\nOtherwise, we risk falling into a huge build trap. In the context of AI-assisted development, this trap can result in a nightmare of more reviews, more validation work, and higher token costs, at least until local models become good enough for more use cases.\nCreating inventory is still expensive, so the goal is not to become more productive for the sake of it.\nThe goal is to become more effective."
newsletter: "Asier Marqués tech blog"
newsletter_handle: "asiermarques-tech"
newsletter_url: "https://usecommune.com/n/asiermarques-tech"
author: "Asier Marqués (@asier)"
published: "2026-06-13T18:28:28.000Z"
canonical_url: "https://usecommune.com/n/asiermarques-tech/a/ai-assisted-software-development-in-2026-part-2-of-2"
markdown_url: "https://usecommune.com/n/asiermarques-tech/a/ai-assisted-software-development-in-2026-part-2-of-2.md"
chat_url: "https://usecommune.com/n/asiermarques-tech/a/ai-assisted-software-development-in-2026-part-2-of-2/chat"
source_url: "https://asiermarques.medium.com/ai-assisted-software-development-in-2026-part-2-of-2-66071a9a0d35?source=rss-ec154a1e4f1e------2"
body_source: "imported"
likes: 1
replies: 0
body_words: 1906
---

# AI-assisted software development in 2026. Part 2 of 2

Adoption, measurement, and the risk of amplified waste

![](https://cdn-images-1.medium.com/max/1024/1*Eif_yHY7cq57G0aoH2o8FA.png)

As I mentioned [in the previous part of this article](https://medium.com/@asiermarques/ai-assisted-software-development-in-2026-part-1-of-2-95a546d4e45c), we are living through an “interesting” moment in the tech industry.

Over the last year, team morale has been affected by layoffs, including frequent AI-related layoffs, return-to-office mandates, [a professional identity crisis](https://hojberg.xyz/the-programmer-identity-crisis/), pressure to adopt AI, and broader economic uncertainty.

This context does not make it easy for people to understand how they should approach the AI revolution. Many teams are being asked to adopt AI quickly, even evaluated based on their AI usage, but without a clear explanation of what problem they are solving, what good adoption looks like, or how success will be measured.
That is why we need clarity.

Statements such as “we need to use more AI” or “everyone is adopting AI, so we cannot fall behind” have become common during this first half of the year, and they do not explain what problem we are trying to solve, what success looks like, or how we will know whether AI is actually improving the way we work.

**Performance evaluation should not be based on AI usage.**
Measuring individuals by how much they use AI, how fast, or how many features they produce using it can create strong perverse incentives. And we still remember when they wanted to measure their performance based on the number of lines of code produced in the past. That was silly then, and it is silly now. People will optimize for the metric, and not necessarily for better outcomes.

If AI helps us become more effective and productive, expectations will naturally rise. And if someone can maintain that level of performance without using AI, why should we put extra pressure on them?

What matters more, their performance or whether they use AI to get there? Honestly, choosing the latter reflects short-term thinking and misses the point, at least to me.
If we force people to use AI through rewards or punishments, we risk undermining the intrinsic motivation needed to cultivate the mindset we actually want.

#### The importance of a well-designed, shared, harness-based workflow

A good harness can help us a lot. They provide guidance, clarity, and clear rules based on shared ways of working for AI-assisted software development. Combined with a strong vision, this can be especially valuable for teams navigating this uncertain moment.

Even if they are useful, we should avoid enforcing these workflows as the only acceptable way to use AI in software development. Enforcing one concrete harness or tool as the only way of working with AI is like trying to hold back the tide.

A better approach is to present the harness as a golden path. As the recommended way of working, with clear governance, contribution rules, and enough flexibility for teams to adapt it to their context and contribute to the shared skills and other resources in the harness.

However, sharing a concrete visión, a concrete strategy, and concrete ways of working would not be effective if we don’t understand how the paradigm is evolving.

#### Our value is changing

Coding is becoming more individual, but software development still requires collaboration. The difference is that collaboration is moving earlier in the process.

Because our work is evolving more and more to multitasking, practices like pair programming are becoming more difficult. So maybe these practices should move to other stages of the workflow, such as discovery, design, review, or validation.

![](https://cdn-images-1.medium.com/max/1024/1*p7GDTB1-lco2MYwu4m58jA.png)

The problem was never about delivering more features or creating more code. It was about working on the right things.

Now we can see more clearly that the value is no longer in typing plumbing code. The value is in framing problems, making trade-offs, validating assumptions, and designing systems that can evolve safely.

Instead of building more just because we can, we should use this new capacity to run more experiments and create more PoCs. This will help us to ensure that the right features enter our delivery flow, rather than generating tons of new features that are not necessarily aligned with customer needs.

#### Productivity without effectiveness moves the bottleneck to review

Increasing productivity without improving effectiveness just moves the bottleneck downstream to review.

More output does not mean more progress. Without effectiveness, productivity only creates a bigger review bottleneck.

![](https://cdn-images-1.medium.com/max/1024/1*GSL8QNzeOi8TyaKVoh7RLg.png)

Again, AI can help teams produce more, but the challenge has never been just about producing more. **The real challenge has always been about deciding what is worth building.**

Authors such as Melissa Perri, with [*Escaping the Build Trap*](https://www.goodreads.com/book/show/33369253-escaping-the-build-trap), and Eliyahu Goldratt, with [*The Goal*](https://www.goodreads.com/book/show/113934.The_Goal), taught us this years, and even decades, ago.

If we build more features and they are not aligned with our customers’ needs, we are creating inventory. And inventory is expensive. These new features will require review, observability, cloud infrastructure, governance, and maintenance. And this means more cost.
Even if nobody is using them.

#### Measuring the impact

DORA helps us measure the delivery system once code starts flowing through it. Its four key metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) give us strong signals about delivery performance and operational health, but it does not tell us whether we are building the right thing.

![](https://cdn-images-1.medium.com/max/1024/1*S6m-ulyaXNkk9Wa23Df6IQ.png)

Because, as I have repeated throughout this article, AI can help us create value much earlier in the process, like during discovery, problem framing, task definition, and architectural decision-making.

Another popular framework is SPACE. It gives us a broader view of developer productivity across different dimensions. Those dimensions are satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.

So SPACE is useful to understand developer productivity and experience, but it should not be treated as direct proof of business impact.

#### What else can we measure?

Designing a workflow is a good opportunity to ask ourselves a few questions, frame them as hypotheses, and decide which metrics would help us validate them.

This approach helps us understand which parts of the workflow are most important to iterate on, and what impact our AI usage may have in terms of ROI.

![](https://cdn-images-1.medium.com/max/1024/1*fiiN194Dtz7lZ5PDtC_Wjw.png)

*Some questions and metrics to answer them*

In addition to metrics, we also need success stories. Narratives help show what teams can now build with AI that they could not realistically build before with the same resources.

Concrete stories are often more persuasive than abstract productivity dashboards. For example, stories like a team shipping a feature in less time, with fewer people, while maintaining or improving quality; a team increasing test coverage as part of the workflow; a team improving documentation and traceability without adding extra process overhead.

These examples make the value of AI adoption easier to understand because they connect the metrics with visible outcomes. They show not only that teams are moving faster, but also what they are able to do differently.

But we also need to manage expectations. AI adoption does not usually create immediate linear improvement. At the beginning, teams may experience a kind of [J-curve](https://medium.com/soul-guided-systems/the-productivity-j-curve-and-the-hidden-economics-of-ai-transformation-7362afca5d21). Productivity can temporarily slow down while people learn the tools, redesign their workflows, define new practices, and build trust in the outputs.

#### The intent and cognitive debt

Technical debt is no longer the only debt problem. AI-assisted software development introduces additional forms of debt that teams cannot ignore. These are [the cognitive and intent debt](https://queue.acm.org/detail.cfm?id=3807966). The risk is that these can remain invisible while delivery and other metrics look healthy.

**Cognitive debt** is the gap between how a system actually works and how well the people responsible for it understand it. A system with high cognitive debt will become difficult to maintain, troubleshoot, or evolve because understanding is no longer distributed across the team.

We can measure it through indicators such as the number of people able to review or modify a component confidently, the concentration of knowledge in specific individuals, and comprehension checks during reviews.
Practices such as shared ownership, knowledge-sharing sessions, architecture walkthroughs, and automated comprehension quizzes help reduce cognitive debt by spreading understanding across the team.

**Intent debt** is the gap between what a system does and why it was designed in a concrete way. So teams may know how a feature works, but not the reason it exists, what risk it was mitigating, or what alternatives were rejected. As intent debt grows, future changes become riskier because engineers are forced to make decisions without understanding the rationale that shaped the current design.

We can measure it through indicators such as the percentage of decisions that lack documented rationale or lack decision records, the number of features whose original objectives cannot be explained, the frequency of “we don’t know why this exists” discussions, or the inability to trace code changes back to requirements.
Practices such as requirement briefs, ADRs, or at least lightweight decision logs, audit logs for decisions made during AI implementation, traceability between requirements and implementation, and periodic reviews of past decisions help to reduce the intent debt.

For both debt types, documentation alone is not enough.
With AI, we can generate many more documents than before. But increasing the amount of documentation can become a problem if those documents are not automatically updated, easy to discover, and actively used.
We need to socialize them. They need to stay active by being reviewed, discussed, and challenged by the team.

One possible automation that can help measure and reduce both cognitive debt and intent debt is a lightweight knowledge check at the end of a task implementation. Or before merging a new feature into the main branch.

For example, a subagent can trigger a short quiz generated from the feature context, asking the engineer or reviewer about key aspects of the change.
Questions like what concrete problem the feature solves, what new business logic has been introduced, and which technical decisions drove the implementation.

The goal would not be to evaluate individuals, but to detect gaps in shared understanding. If people struggle to answer those questions, that is a signal that the AI-assisted workflow may be creating or hiding cognitive and intent debt.
Measuring those gaps over time could help teams understand the implications of excessive delegation to AI during implementation.

We also need to ensure that our harness provides proper audit logs. If agents and subagents are implementing, reviewing, validating, or modifying software, teams need a clear record of what happened during each session. So we can review which actions were executed, which tools were used, what files were changed, what decisions were made, and where human approval was required.

### Final ideas

We should not forget what we have learned over the last 30 years. Our engineering and product principles are still valid. For example, small tasks help us deliver more efficiently and get feedback sooner.

We should invest in discovery by enabling speed and autonomy for experimentation, rather than obsessively increasing the number of new features entering our delivery pipeline. This means taking advantage of the AI power to create more PoCs and more experiments before investing in more features.

Otherwise, we risk falling into a huge build trap. In the context of AI-assisted development, this trap can result in a nightmare of more reviews, more validation work, and higher token costs, at least until local models become good enough for more use cases.

Creating inventory is still expensive, so the goal is not to become more productive for the sake of it.

The goal is to become more effective.

![](https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=66071a9a0d35)

***

## Discussion

No replies yet.