Adoption, measurement, and the risk of amplified waste
As I mentioned in the previous part of this article, 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, 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.
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.
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, and Eliyahu Goldratt, with 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.
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.
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. 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. 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.
