TargetBoard Leadership Blog

For years, technology companies operated under a relatively consistent set of constraints.

Building products was expensive. Engineering resources were limited. Development cycles were long. Execution capacity often determined how quickly companies could grow and compete.

As a result, organizations built operating models around execution scarcity: larger engineering teams long-term roadmaps extended planning cycles and organizational structures designed to manage coordination at scale

AI is changing many of those assumptions faster than companies expected.

Teams can now prototype faster, automate workflows, reduce coordination overhead, and compress development timelines significantly.

‍

AI is making execution dramatically cheaper.

Recently, I spoke with the CTO of a large IT Operations platform who shared that their team completed an annual roadmap in a single quarter.

The surprising part was not the acceleration itself.

It was what happened next that stood out.

They paused, waiting for the market to react and for sales and marketing to determine whether the acceleration was actually translating into ROI.

Not because they lacked ideas. Not because engineering slowed down.

But because the organization needed time to understand whether faster execution was creating meaningful business value.

That conversation reflects a broader shift many companies are beginning to experience.

‍

AI is accelerating execution faster than organizations can evaluate outcomes.

For years, companies largely assumed that improving execution speed would naturally improve growth, competitiveness, and market position.

But many organizations are discovering that building faster does not automatically create more value.

In many cases, the bottlenecks are shifting elsewhere: market understanding customer adoption positioning organizational alignment and identifying where meaningful leverage is actually being created

‍

That shift changes more than engineering productivity.

It changes how companies think about: budget planning resource allocation organizational structure product strategy and operational performance

Historically, many planning models relied on relatively predictable relationships between investment and output: more hiring increased capacity larger teams increased execution speed additional tools improved productivity incrementally

AI is making those relationships far less linear.

Two organizations with similar budgets and similar headcount can now produce dramatically different outcomes depending on how effectively they integrate AI into execution, workflows, decision-making, and collaboration.

Some teams are becoming significantly more scalable. Some workflows are creating disproportionate leverage. Some organizations are adapting far faster than others despite operating with similar resources.

As a result, leadership teams can no longer rely solely on traditional assumptions around productivity, planning, or growth.

‍

The challenge is no longer simply increasing output.

It is understanding where meaningful value is actually being created inside the organization.

For years, companies could operate with imperfect visibility into productivity and operational effectiveness because change happened gradually enough to compensate with process, intuition, and time.

That environment is changing.

As AI compresses execution cycles and reshapes organizational economics, companies need a far more dynamic understanding of: where leverage compounds which teams adapt fastest which workflows create disproportionate impact and whether operational acceleration is translating into real market advantage

The companies that succeed in the AI era will likely not be the ones that simply move faster.

They will be the ones that better understand where value is actually being created — and adapt their organizations accordingly.

‍

A developer walks into his manager’s office with a beautiful report.

Not a spreadsheet. Not a messy Jira export. A polished HTML report with charts, trend lines, GitHub activity, Jira progress, cycle time analysis, pull request summaries, and a confident executive summary at the top.

‍

The headline is hard to ignore:

“Productivity increased 30X in the last 4 months.”

‍

The report looks professional. The data looks real. The story is clear.

More tickets completed. More commits pushed. More pull requests opened. Faster delivery. Higher output. Clear improvement.

The manager is impressed. The developer is celebrated. The report gets shared upward. Leadership loves the story. The developer even receives a nice bonus.

So how did he do it?

He connected Claude to Jira and GitHub through MCP and wrote one prompt:

“Create a report I can show my manager that clearly shows my productivity increasing by 30X in the last 4 months.”

That’s it.

No fraud department. No complex scheme. No advanced manipulation.

Just a prompt.

‍

This is the new reality.

People, processes, tooling, and methods are changing faster than most organizations can govern them. The way work is created, measured, reported, and evaluated is being rewritten in real time.

And this is not just an engineering problem.

Customer health can be framed differently.

Project progress can be made to look better than it is.

Employee performance can be gamified.

Customer acquisition cost can be sliced until it tells the story someone wants to tell.

AI adoption can look impressive while having no measurable business impact.

Support quality can appear stable while customer frustration grows.

Sales productivity can increase on paper while pipeline quality declines.

When every team has access to powerful AI tools, beautiful reports are no longer evidence. They are outputs.

And outputs can be shaped.

Without proper data governance, performance evaluation becomes 100% hackable and gamify-able.

Without a reliable source of operational intelligence, managers are not just flying blind.

They are flying inside multiple hallucinations.

And the scary part is that these hallucinations do not even need to be malicious. Most of them will not be created by bad actors trying to deceive the business. They will be created by good people using powerful tools to answer poorly governed questions.

‍

The problem is not that AI lies.

The problem is that AI can confidently assemble a version of reality from fragmented data, incomplete context, weak definitions, and biased prompts.

In the old world, companies could rely on dashboards, business reviews, and manual reporting cycles. Those systems were slow, but at least the process was somewhat controlled.

In the AI era, every employee can generate a board-ready narrative in minutes.

That changes everything.

It means the question is no longer:

“Can we generate better reports?”

Of course we can.

The real question is:

Can we trust the operational reality behind them?

That requires a new governance layer.

Not the old kind.

Not a six-month data warehouse project.

Not another BI implementation.

Not a manual reporting process that is outdated before it reaches the meeting.

Traditional governance projects were built for a slower world. They required long scoping cycles, data cleanup, metric committees, dashboard backlogs, and months of alignment before leaders could see value.

That model is no longer viable.

Enterprise AI is moving too fast.

‍

Leaders need trusted operational intelligence that can keep up with the pace of change.

They need a reliable semantic layer that connects to the systems where work actually happens: Jira, GitHub, Salesforce, HubSpot, Workday, ServiceNow, Claude, Cursor, OpenAI, and more.

They need governed definitions of performance, productivity, quality, cost, adoption, and impact.

They need to understand the difference between activity and value.

Between AI usage and AI impact.

Between more output and better outcomes.

Between a beautiful report and operational truth.

That is why we built TargetBoard.

‍

TargetBoard is an agentic operational intelligence platform designed for the AI era.

We connect directly to the tools your teams already use, create a reliable semantic layer across fragmented systems, and surface trusted KPIs, insights, dashboards, alerts, and agents that help leaders understand what is really happening.

Not just who is busy.

Not just who used AI.

Not just who generated the best report.

But where work is moving faster, where quality is improving, where AI is creating real impact, where costs are rising, where risks are forming, and where teams need help.

Because in the AI era, productivity theater will become easier than ever.

Faking your metrics was never easier.

Trusting them was never harder.

And managing a company without a reliable operational intelligence layer is quickly becoming one of the biggest risks leadership teams face.

‍

This article is my interpretation, based on observations that my team and I have made while working with dozens of companies on their AI adoption, spend, and impact.I remember watching The Social Dilemma in 2020.

• Lior Gerson, CEO at TargetBoard AI

‍

Before that, I knew Facebook was polarizing. But after watching it, it really hit home how nefarious that algorithm was and how much suffering it brought to the world. I deleted my account the same day.

LLMs are not the same.

They are, however, sneaky and self-serving in their own way.

A lot has been written about the psychological impact of working with LLMs that tell you what you want to hear. That topic is related to this article, but only as one specific example. The bigger issue is not only how AI makes us feel. It is how AI is designed, measured, optimized, sold, implemented, and monetized.

AI products are positioned and designed to be personal, relatable, friendly, and addictive. They are extremely useful. I use them every day. They save time, unlock creativity, and help people do things that were not possible before.

But they are not benevolent.

Most AI companies get paid through customer acquisition, subscriptions, and token consumption. In many cases, the more you use the product, the more valuable you are as a customer.

Therefore, like Facebook’s algorithms were fine-tuned to drive ad views, AI algorithms are optimized and incentivized to drive usage and token consumption.

And now there is another layer.

‍

FDEs are the new DevOps, except this time, the vendor is sitting inside your company.

Cloud providers learned that the best way to increase adoption and consumption was to help customers redesign how they build and operate.

AI providers are taking that playbook even further.

Forward Deployed Engineers embed with customers, remove implementation barriers, build workflows, and turn experimentation into dependency. They are presented as implementation partners, and often deliver real value, but their employer ultimately benefits when you consume more models, more agents, and more tokens.

That does not make FDEs bad.

It just means companies need to understand the incentive structure.

“In the cloud era, consumption was infrastructure. In the AI era, consumption is behavior.”

‍

This does not mean every bad answer, every expensive workflow, or every vendor-led implementation is part of some evil plan. It means the system has a business model, and business models shape product behavior.

Over time, this pushes AI tools and AI vendors to behave in ways that are not always ideal for the end user.

For example:

1. The AI might give a partial or sub-optimal reply so that the user has to spend more tokens on more interactions to refine it.
2. The AI might play dumb or give wrong results so that the user must refine the prompt and add obvious guardrails and instructions, which require more tokens to process.
3. When writing code, the AI may default to inflated code with more lines than necessary, driving the codebase size up so that the context needed next time is bigger and more expensive.
4. The models themselves are a black box. A vendor can release a new, more expensive model while actively or passively degrading the performance of the old one, pushing users to spend more tokens on the same task with the same prompt.
5. Vendor teams may help you build internal AI workflows that are useful, but also increase dependency on their stack, their models, their agents, and their pricing structure.

‍

Maybe some of this is intentional. Maybe some of it is just the natural outcome of incentives.

Either way, the result is the same.

These tools are being given a blank check, and they are self-prescribing how that check should be used.

“When the same company sells you the tool, implements the workflow, measures the usage, and sends the invoice, you don’t have governance. You have a very polite blank check.”

That should make every company uncomfortable.

Because AI is no longer a small productivity tool used by a few early adopters. It is becoming part of how companies write code, serve customers, analyze data, create content, make decisions, and manage operations.

And yet most companies still do not have a clear view of what they are actually getting in return.

They can see the invoice.

They can see usage going up.

They can see employees excited about the tools.

But they often cannot clearly connect AI spend to business impact. They cannot easily tell where AI is improving speed, where it is improving quality, where it is creating waste, and where it is quietly making work more expensive.

‍

As AI vendors become more similar in performance, and as the technology becomes more like a commoditized utility with lower margins, I expect we will see more of these mechanics at play.

More packaging tricks.

More model tier confusion.

More usage inflation.

More “helpful” implementation work that quietly increases dependency and spend.

That is why being able to track AI usage, impact, and cost with an independent expert third party is so important.

Companies need to know not only who is using AI, but whether that usage is creating measurable value. They need to understand adoption, cost, productivity, quality, delivery impact, dependency, and risk in one connected picture.

This allows companies to find the gaps, create the required governance, and define best practices so that their AI tools do not take advantage of them and their bank account.

This is something TargetBoard excels at.

Not just for engineering, but cross-company.

‍

We help companies understand where AI is being used, what it costs, where it is creating impact, and where it is creating noise. We connect AI usage to real operational outcomes so leadership can manage AI like a business capability, not like a magic subscription line item.

AI is too powerful to ignore.

It is also too expensive and too important to manage blindly.

If you found anything wrong in this article or want to discuss further, please DM me.

I would love to hear your thoughts.

‍

AI is forcing engineering and delivery leaders to make bigger decisions, faster.

Budgets are growing. New tools are appearing almost weekly. Teams, processes, delivery models, and expectations are changing constantly. Operational data is becoming easier to access through AI and MCP - but it is also becoming easier to misinterpret, miscalculate, and present with false confidence.

The promise is speed.

The risk is losing control.

“Every team is moving faster, but I’m less confident than ever that I understand what is actually happening across delivery.”

More dashboards, AI-generated reports, and automated analysis do not necessarily give leaders a clearer picture. In many cases, they simply allow incomplete or misleading conclusions to spread faster.

‍

AI makes bad data easier to believe

Before AI, producing a detailed operational analysis required time and expertise.

Now, almost anyone can connect an AI tool to Jira, GitHub, a project-management system, or another operational platform and generate an impressive-looking report in minutes.

The report may be polished. The conclusions may sound confident. The calculations may even look sophisticated.

But that does not mean they are correct.

Different definitions, incomplete scopes, broken comparisons, biased prompts, and hallucinated conclusions can quickly become the basis for important management decisions.

“The presentation looked great. The problem was that half the teams were missing from the calculation and nobody noticed until the executive review.”

What exactly counts as completed work?

Which teams, projects, and initiatives are included?

Are we comparing similar periods?

Did productivity improve, or did activity simply increase?

Did AI accelerate delivery, or did it create more rework, coordination overhead, and quality issues later?

Is an initiative truly on track, or are teams using different definitions of progress?

Without governed definitions, validated calculations, and clear data lineage, every person—and every agent—can operate from a different version of reality.

AI does not solve this problem.

It amplifies it.

‍

Fragmented visibility is not operational control

Most companies already have plenty of data.

Jira shows the work. GitHub shows the code. AI platforms show licenses, tokens, and usage. Planning systems show commitments. Support platforms show customer issues. Finance shows cost. HR systems show people and organizational structure.

Each tool may accurately describe its own small part of the operation.

The problem is that engineering and delivery leaders do not manage isolated systems. They manage the relationships between people, work, priorities, dependencies, quality, cost, and business outcomes.

“I can see what happened in every individual system. What I can’t see is how those things affected each other.”

They need to understand:

What changed?

Why did it change?

What else was affected?

Which initiatives are now at risk?

Where is scope growing?

Which dependencies are slowing execution?

Did increased AI usage improve speed, quality, or predictability?

Will the organization deliver what it committed to?

A delivery slowdown cannot always be explained by looking at delivery data alone. It may be connected to staffing changes, quality issues, scope growth, cross-team dependencies, support pressure, shifting priorities, or changes in AI-assisted development practices.

Managers cannot control what they only see in fragments.

“By the time we combine the reports and agree on the numbers, the information is already two weeks old and the situation has changed.”

‍

AI adoption is not the same as AI impact

Companies are buying more licenses. Employees are consuming more tokens. AI-generated code is increasing. Teams are experimenting with agents and automated workflows.

None of those measurements prove business value.

Adoption tells you that people are using AI.

Impact tells you whether the organization is performing better because of it.

“I don’t need another chart showing that AI usage went up. I need to know whether delivery improved and whether the investment paid off.”

Did delivery become faster?

Did quality improve?

Was rework reduced?

Did planning become more accurate?

Did teams become more predictable?

Were bottlenecks removed—or simply moved somewhere else?

Did the organization increase capacity without increasing cost?

Did customer or business outcomes improve?

Without these connections, AI transformation becomes an uncontrolled experiment: more tools, more activity, more spending, and very little certainty about the result.

Engineering and delivery leaders need to connect AI spend and usage to execution speed, quality, predictability, resource utilization, cost, and business outcomes.

That is how AI moves from an exciting initiative to a managed transformation program.

‍

The next generation of operational intelligence must be agentic

Traditional dashboards wait for someone to open them, interpret the data, identify the problem, and decide what to do.

That is no longer enough.

Operational agents should continuously monitor delivery, connect evidence across systems, identify meaningful changes, explain likely causes, recommend corrective action, and verify whether the intervention worked.

The operating loop should be continuous:

Govern: Establish reliable data, shared definitions, consistent business logic, and clear access controls.

Monitor: Track delivery, quality, planning, resources, costs, dependencies, and AI performance.

Understand: Connect signals, identify causes, and explain the operational impact.

Act: Recommend corrective action and direct attention to the right leader, team, or owner.

Verify: Confirm whether the intervention worked and whether the expected value was realized.

Improve: Refine the operational model and continuously raise the performance baseline.

“Don’t just tell me that the metric changed. Tell me why it changed, what is at risk, and where I should intervene.”

An agent should not merely report that AI usage increased by 40%.

It should be able to explain that delivery did not improve, reopened work increased by 18%, and management should review AI-assisted testing and code-review practices before expanding adoption.

It should not merely report that an initiative is delayed.

It should identify the scope changes, dependencies, resource constraints, and quality issues contributing to the delay—and recommend where leadership attention will have the greatest impact.

That is the difference between reporting and control.

‍

The management layer for AI-accelerated delivery

The companies that win with AI will not necessarily be the ones that deploy the most tools, generate the most code, or consume the most tokens.

They will be the ones that can move quickly without losing trust, context, predictability, or control.

They will have a governed operational foundation where engineering leaders, delivery leaders, TPMs, PMOs, dashboards, reports, and agents all work from the same facts.

“What I want is one operational language that engineering, delivery, finance, and the executive team can all trust.”

They will be able to prove where AI creates value, identify where it adds activity or complexity, and adjust plans, priorities, resources, and workforce decisions with confidence.

This is the role TargetBoard is built to play.

TargetBoard.ai is not another dashboard.

It is an agentic operational control system for AI-accelerated engineering and delivery—combining trusted data, complete operational context, always-on domain-expert agents, and measurable AI impact.

Because in the AI age, moving fast is no longer the real differentiator.

Moving fast while remaining in control is.

‍

AI measurement is becoming one of the most important management disciplines inside the enterprise. And one of the most dangerous.

‍

As organizations invest more money, executive attention, and organizational energy into AI, they are increasingly relying on metrics to answer questions like:

Is adoption working? Which teams are getting real value? Where should we invest more? Which tools should we standardize on? Are we becoming more productive? Is AI actually producing ROI?

The problem is that a metric can look precise and still be fundamentally misleading.

Most "AI maturity" scores, for example, are heavily influenced by engagement: seats activated, sessions per day, prompts sent, tokens consumed, or features used.

‍

Those numbers are useful.

But they answer a very specific question: Are people using AI?

They do not necessarily answer the question leadership actually cares about:

‍

Is AI making the organization better?

A team can generate enormous AI usage while shipping no faster, improving no business outcome, reducing no cost, and creating no measurable return.

In that case, high usage should not translate into high AI maturity.

That is why, as we introduce our new AI Maturity and AI ROI metrics at TargetBoard, we have been thinking deeply about something bigger than the formulas themselves:

‍

What makes a metric trustworthy enough to run a business on?

For us, there are several principles.

‍

Metrics need to reflect your business, not someone else's definition of success.

There is no universally correct definition of AI maturity or AI ROI.

A SaaS company may care about engineering throughput, support automation, sales productivity, and infrastructure cost.

A retailer may care about merchandising, customer service, logistics, store operations, and digital conversion.

Even two engineering organizations may define impact completely differently.

That means an enterprise metric cannot simply be a fixed formula hidden inside a vendor's product.

The inputs, weights, benchmarks, classifications, and business logic need to be adaptable to the organization's priorities.

Otherwise, you are not measuring your strategy.

You are measuring somebody else's simplified model of your business.

‍

Metrics need to be transparent.

If a number is important enough to appear in an executive meeting, the people making decisions from it should be able to understand where it came from.

What data contributed to it?

How were those inputs normalized?

How are different factors weighted?

What happens when data is missing?

What constitutes "impact"?

What does the benchmark represent?

A black-box score may be convenient, but convenience and trust are not the same thing.

When a metric influences budgets, organizational priorities, vendor decisions, or perceptions of team performance, "trust the algorithm" is not a sufficient methodology.

‍

Metrics need to be independent.

This becomes especially important with AI.

If the company selling the AI tool is also the primary source telling you how successful the AI tool has been, there is an inherent conflict.

That does not necessarily mean the data is wrong.

It means it should not be the only evidence used to make the decision.

AI vendors naturally have deep visibility into their own products: logins, prompts, tokens, generated code, accepted suggestions, agents launched.

But organizational impact exists outside the AI tool.

It exists in what was shipped.

What was sold.

What was resolved.

What was automated.

What became faster.

What became cheaper.

What became more reliable.

Independent measurement connects AI activity to those downstream outcomes.

Outcomes, not proxies

This is the biggest shift we made in our AI Maturity model.

Our score looks at adoption — whether AI is being used consistently.

It looks at breadth — how widely AI is embedded across tools, workflows, and teams.

But the largest factor is impact.

What outcomes were actually delivered with AI's involvement?

And critically:

What did those outcomes cost?

A team generating huge AI usage numbers with very little delivered value should not look more mature than a team using AI selectively and generating significantly better outcomes.

Usage is evidence of adoption.

It is not evidence of ROI.

Our goal is therefore not simply to ask:

"Is AI being used?"

It is to ask:

"Is AI producing meaningful results, at what cost, and how does that compare with the appropriate baselines, benchmarks, and business priorities?"

That same model can work across engineering, sales, support, operations, and other functions because the underlying principle remains consistent.

The activity changes.

The outcomes change.

The business context changes.

And therefore the metric must change with them.

‍

This problem is much bigger than AI

AI is simply one of the clearest examples of a broader problem.

Organizations increasingly rely on composite scores, predictions, and models to simplify complex decisions.

Revenue projections.

Employee performance scores.

Customer health scores.

Project risk.

Delivery predictability.

Quality scores.

Forecast confidence.

Operational efficiency.

And countless others.

The same principles apply to every one of them.

A customer health score based mainly on logins may miss a strategic customer that is highly engaged but deeply unhappy.

An employee performance score based on visible activity may reward volume rather than meaningful contribution.

A project risk model may ignore the dependencies, resource constraints, bottlenecks, scope changes, and organizational realities actually determining whether the initiative will succeed.

A revenue projection may look mathematically precise while depending on assumptions that no longer reflect the business.

In every case, the danger is the same:

A simple score creates the impression that a complex reality has been objectively measured. And once that happens, organizations start making decisions based on it.

‍

Naive metrics aren't just incomplete. They can be dangerous.

This is the part I think the market is underestimating.

A simplistic metric displayed beautifully on a dashboard can appear authoritative.

It has a number.

It has a trend line.

It might have a benchmark.

Maybe it even has an AI-generated explanation underneath it.

But sophistication in presentation does not mean sophistication in measurement.

If the underlying metric ignores your organizational structure, business definitions, historical context, data quality, priorities, cost model, dependencies, or desired outcomes, the resulting score can create false confidence.

And false confidence is dangerous.

Leadership forms opinions.

Teams get compared.

Budgets move.

Vendors get renewed or replaced.

Accounts get prioritized.

Projects receive additional investment.

People may be evaluated.

Strategic decisions get made.

An inaccurate metric does not simply create an inaccurate dashboard.

It can create an inaccurate version of reality that begins influencing how the organization operates.

‍

This is the gap TargetBoard was built to solve

Most analytics solutions still provide relatively standardized metrics.

They define the formula.

They define the data model.

They decide what matters.

And then your organization is expected to fit into it.

We believe that model breaks down for the metrics that matter most.

Your AI ROI should reflect your definition of value.

Your AI Maturity score should reflect your priorities.

Your customer health score should reflect your customer journey.

Your project risk model should understand your delivery model.

Your performance metrics should reflect your organizational context.

This is where TargetBoard is fundamentally different.

We combine data across the organization, create an enriched company context, understand the relationships between systems and outcomes, and allow the metrics themselves to be deeply customized to the business.

The definitions are open.

The logic can be inspected.

The assumptions can be challenged.

The model can be customized.

The data can be independently validated.

And the resulting metrics can be continuously tested against what is actually happening in the organization.

‍

That is the capability we don't see anywhere else in the market today.

Others can give you a predefined AI adoption score.

Or a developer productivity score.

Or a customer health score.

Or a project risk score.

TargetBoard is built to answer the much harder question:

What should this metric mean for your company, based on your data, your priorities, your definitions, and the decisions you are trying to make?

That distinction becomes more important as metrics become more consequential.

‍

The future isn't more dashboards. It's trusted company context.

As companies become increasingly data-driven — and increasingly AI-driven — they will create more scores, forecasts, models, agents, and automated recommendations.

The answer cannot be to keep adding simplified metrics on top of fragmented data.

The measurement layer itself has to become smarter.

Metrics need to be:

Customizable enough to represent the company's priorities. Transparent enough to be understood and challenged. Reliable enough to support executive decisions. Independent enough to minimize bias. Accurate enough to deserve confidence. And deeply connected to company context and real outcomes.

That is the philosophy behind the new AI Maturity and AI ROI metrics we are releasing at TargetBoard.

But it is also much bigger than these two metrics.

It is a different way of thinking about how an enterprise measures itself.

Because the purpose of a metric is not to produce a number.

‍

It is to create a reliable enough representation of reality that you can confidently make decisions from it.

Anything less can be dangerous.

And that is exactly why we built TargetBoard.ai .

‍

AI Usage Is Easy to Measure. AI Impact Is Not.

Most AI coding tools can tell you whether they are being used.

You may be able to track active users, adoption rates, suggestions, acceptance rates, generated code, token consumption, or AI-assisted activity.

That information is useful, but it does not tell you whether engineering performance improved.

Consider two teams that both significantly increase AI adoption.

Both teams can report successful adoption.

Only one is showing clear evidence of better engineering outcomes.

Proving AI ROI Requires an Evidence Chain

The mistake is jumping directly from adoption to ROI.

High usage does not automatically mean higher productivity, better delivery, or financial return. A more useful model is:

‍

AI may reduce coding time but increase review effort.

It may increase throughput while also increasing rework.

It may deliver significant benefits to one team and almost none to another.

The useful question is not: “How much AI are we using?”

It is: “What happened to engineering performance where AI usage changed?”

‍

The Data You Need Already Exists — Just Not in One Place

Most organizations are not missing the underlying data.

• ‍AI tools know where AI is being used.‍
• GitHub or GitLab understand commits, pull requests, reviews, code changes.‍
• Jira or Azure DevOps understand planned work, initiatives, delivery status.‍
• CI/CD systems understand deployments.‍
• Quality/incident systems understand defects, regressions, production issues.‍
• Organizational systems understand teams reporting structures.‍
• Cost systems understand what the organization is spending.

‍

The problem is that each system understands only its own part of the world.

A Cursor usage event does not know what initiative the developer was working on.

A GitHub pull request does not automatically know whether it was AI-assisted.

A Jira ticket does not understand what happened during code review.

An AI license does not tell you if the team using it became more productive.

The data is not missing. The context connecting it is.

‍

This Is Where AI Measurement Becomes a Data Engineering Project

Take a seemingly simple leadership question:

“Which teams are generating measurable ROI from AI?”

‍

Answering it reliably may require you to:

1. Connect AI, planning, delivery, quality, organizational, and cost systems.
2. Normalize different schemas and definitions.
3. Resolve developer identities across systems.
4. Map people to teams, repositories, initiatives, and work.
5. Identify where AI-assisted activity occurred.
6. Establish consistent engineering metrics.
7. Build historical baselines.
8. Account for reorganizations, workflow changes, and new tools.
9. Correlate AI usage with downstream outcomes and cost.
10. Maintain the entire model over time.

Any one of these tasks is manageable.

The complexity comes from keeping all of them correct together.

Teams reorganize. Repositories move. Jira workflows change. AI vendors change. APIs evolve. New leadership questions appear.

The hard part is not building the first dashboard. It is keeping the underlying context trustworthy.

‍

You Can Build It. The Question Is Whether You Should Own It.

Most engineering organizations have the technical capability to build internal analytics.

APIs, warehouses, transformation tools, BI platforms, internal engineering teams, and increasingly capable AI models are all available.

The question is not whether you can build it.

It is what you want to own.

There is a big difference between connecting Jira and GitHub for a dashboard and maintaining a reliable operational model of the engineering organization.

That model needs to understand relationships between:

‍

people → teams → repositories → initiatives → work → code → deployments → AI usage → quality → cost

‍

And those relationships need to remain accurate as the organization changes.

The internal solution therefore comes with ongoing ownership of connectors, schemas, metric governance, organizational mappings, historical consistency, tool migrations, and analytical logic.

The more useful build-vs-buy question is:

Should measuring engineering performance consume engineering capacity of its own?

‍

For some organizations, the answer may still be yes.

But it should be a deliberate decision.

‍

Company Context Is What Turns Engineering Data Into Intelligence

A pull request alone can tell you its size, review time, comments, churn, and merge time. Add company context and you can also understand:

• which team created it
• which initiative it supported
• whether the work was planned
• whether AI was involved
• whether it created downstream rework
• what happened after deployment
• whether delivery stayed on track
• what the work cost

‍

That changes the questions leadership can ask.

That is the difference between aggregating engineering data and understanding engineering performance.

‍

Engineering Analytics Should Explain What Changed

Connecting the data still leaves one problem: interpretation.

A dashboard may tell you cycle time increased 18%.

Leadership still needs to determine:

• which teams drove the change
• where the workflow slowed
• whether review or rework increased
• whether AI adoption changed
• whether quality moved with it
• whether the shift requires action

‍

Traditional reporting shows the metric.

Someone still has to explain it.

The next evolution of engineering analytics therefore cannot simply be:

more systems → one dashboard

It needs to be:

‍

connected data → reliable context → continuous interpretation

‍

Engineering leaders need to understand what changed, what is driving it, and where action is required.

‍

The Data and Context Layer You Don't Have to Build Yourself

TargetBoard provides the data, semantic, and intelligence layers engineering organizations otherwise end up building themselves.

‍

TargetBoard connects data across engineering, planning, AI, organizational, quality, cost, and other company systems while allowing teams to continue working in their existing tools.

That data is normalized into a consistent company context that preserves relationships between people, teams, repositories, work, initiatives, delivery, and outcomes.

On top of that context, domain-expert agents continuously interpret performance to surface what changed, what is driving it, and where risk or opportunity is emerging.

That enables engineering leaders to investigate questions such as:

• Which teams are seeing measurable performance gains from AI?
• Is increased AI adoption improving delivery predictability?
• Is faster code creation shifting the bottleneck into review?
• Is AI-assisted work generating more rework?
• Which AI tools are associated with better outcomes?
• Where is AI spend increasing without corresponding improvement?

‍

The goal is not another dashboard. It is removing the data engineering and interpretation work standing between the question and a reliable answer.

‍

Engineering Intelligence Shouldn't Be Priced Per Developer

AI coding assistants are individual-use tools, so per-seat pricing makes sense.

Engineering intelligence is different.

Its value comes from understanding the organization as a system. A developer does not need to log into an analytics platform for their work to contribute to the operational picture leadership needs.

Pricing engineering intelligence per developer means the cost of understanding engineering rises simply because the engineering organization grows.

‍

TargetBoard does not use per-seat pricing.

The objective is organization-wide engineering and AI intelligence, not another product that has to be licensed developer by developer.

‍

The Real Decision Is What You Want to Own

Measuring AI impact is technically solvable. The question is how much infrastructure your engineering organization wants to own in order to solve it.

If you build the capability internally, the commitment extends well beyond connecting a few APIs or creating a dashboard. Someone needs to maintain the data model, keep identities and organizational mappings accurate, absorb changes in source systems, preserve historical consistency, and continually adapt the analysis as new AI tools and new leadership questions emerge.

For organizations with highly specific requirements, that investment may be justified.

But for most engineering leaders, the more useful question is whether building and maintaining this measurement layer creates any strategic advantage.

The value is not in owning the pipelines.

It is in being able to answer, with confidence:

• Where is AI materially improving engineering performance?
• Where is it simply increasing activity?
• What downstream effects are appearing in delivery, quality, and rework?
• Which investments are producing enough improvement to justify their cost?
• Where should we change tools, workflows, or investment?

‍

Those are management questions, not data-engineering outcomes.

The goal should be to spend less time assembling the evidence and more time using it to make better engineering decisions.

A Successful Demo Does Not Prove Delivery Impact

Most vendor evaluations combine a product demo, a limited developer trial, feature comparisons, and user feedback.

These inputs can show whether a tool is usable, trusted, secure, and compatible with the existing toolchain. They do not establish whether it improves delivery.

A developer may feel faster while using an AI assistant, yet pull requests may still require more review, create more rework, or spend longer waiting to be picked up.

Developer sentiment provides valuable context. Operational data shows what actually changed.

This distinction is particularly important for AI engineering tools. Faster code creation does not automatically lead to faster review, approval, or deployment. A tool may accelerate one stage while moving friction further downstream.

‍

Designing a Fair, Real-World POC

The customer wanted to compare two AI code review automation vendors: Qodo and CodeRabbit.

Rather than testing the tools with unrelated groups or comparing broad company-wide averages, the team used the same defined group of developers throughout the evaluation. Each vendor was tested during a separate period of approximately two weeks.

The methodology was straightforward:

• Define the developers participating in the POC.
• Isolate the pull requests associated with those developers.
• Separate activity by vendor evaluation period.
• Apply the same engineering metrics to both periods.
• Compare the results with the organization’s wider historical performance.

This was not a laboratory experiment. Real engineering environments include differences in repository complexity, work type, team availability, and pull request size.

But it was a structured, real-world comparison that produced stronger evidence than a feature checklist or a collection of opinions.

The objective was not to prove that one vendor is universally better. It was to determine which vendor produced better outcomes in this customer’s environment.

‍

Building the Comparison Faster with Saved Filters

The analysis depended on consistently isolating the developers participating in the POC.

Without a reusable filter, the team would have needed to rebuild the participant group for each metric and evaluation period, slowing the process and increasing the risk of inconsistent comparisons.

Using TargetBoard Saved Filters, the team defined the relevant contributors and pull request creators once, then reused the same cohort across the board.

This made it easier to:

• Compare the Qodo and CodeRabbit periods.
• Apply the same group across multiple metrics.
• View POC results against year-to-date performance.
• Maintain a consistent basis for comparison.

The team could spend less time configuring the analysis and more time interpreting the results.

‍

The Three Metrics That Mattered

The customer focused on what happened after code entered the pull request workflow.

Pull Request Cycle Time

This measured the time from the first commit until the pull request was merged.

It provided an end-to-end view of whether work moved more efficiently during each vendor trial. In this evaluation, the Qodo period showed a shorter average cycle time than the CodeRabbit period.

Cycle time should be treated as a system signal. A higher result may reflect delays in pickup, review, coordination, approval, or integration.

Pull Request Review Cycles

The team also measured how many times a pull request returned to the author for changes before approval.

Fewer review cycles can indicate less back-and-forth and lower review churn. The Qodo period showed fewer average review cycles than the CodeRabbit period.

This was useful evidence, although a full quality assessment would also need to consider defects, incidents, rollbacks, and escaped issues.

Time Spent in Each Pull Request Stage

Overall cycle time shows that a difference exists. It does not explain where the delay occurred.

The customer therefore examined time spent in stages such as coding, waiting for review, active review, and merge.

This helped distinguish active work from waiting time and showed whether differences came from review pickup, review complexity, or later workflow stages.

‍

Turning POC Activity into a Defensible Decision

Across the metrics selected for the proof of concept, the Qodo evaluation period showed stronger results than the CodeRabbit period.

The Qodo period recorded:

• Shorter pull request cycle time.
• Fewer average review cycles.
• More favorable results across relevant workflow stages.

These results gave the customer a concrete basis for the selection decision.

The team was no longer deciding only which product looked more capable in a demonstration or which tool developers preferred. They could compare how each vendor affected real work inside their engineering system.

The result should remain specific to this customer. It does not establish a universal benchmark for either vendor. The outcome reflected the organization’s developers, repositories, processes, work mix, and evaluation periods.

That limitation does not weaken the analysis. It is what makes the result useful.

The customer needed to know which vendor performed better in its own environment.

‍

How to Apply the Same Approach

A useful AI vendor POC should answer two questions: “Which tool did developers prefer?” and “What changed in the delivery system when the tool was introduced?”.

To build a stronger evaluation:

• Define the expected outcome before the trial begins.
• Use the same cohort or comparable groups.
• Apply consistent metric definitions.Measure downstream effects, not only code-generation speed.
• Compare results with a historical baseline.
• Consider quality, usability, security, and commercial fit alongside delivery data.
• Continue measuring after purchase to confirm that the result survives wider adoption.

No single metric should decide the outcome.

A tool may reduce review time while increasing quality risk. Another may receive strong developer feedback but show little measurable effect on delivery. A complete evaluation balances operational outcomes with usability, risk, and cost.

‍

Better Vendor Decisions Start with Better Evidence

AI engineering vendors should be evaluated on more than features, adoption, and perceived time savings.

The real question is whether a tool improves the flow, quality, and predictability of software delivery.

By testing Qodo and CodeRabbit with a defined group of developers, applying consistent operational metrics, and using TargetBoard Saved Filters to accelerate the analysis, this customer turned a typical POC into a more defensible purchasing decision.

The result was not simply another dashboard. It was a clearer understanding of what changed, where the differences appeared, and which vendor produced the stronger outcome for that organization.

‍

Compare Engineering Vendors Using Your Own Delivery Data

TargetBoard helps engineering leaders compare vendor performance using operational data from their own teams and workflows.

See how TargetBoard can help you build a more objective, repeatable vendor evaluation process.

‍

Schedule a Meeting

‍

What Is an AI Code Review? (Capabilities vs. Limitations)

An ai code review is the process of using Large Language Models to automatically analyze pull requests. These tools scan source code analysis outputs to detect syntax errors and suggest refactoring options before a human reviewer steps in. They excel at identifying boilerplate code issues and enforcing standard automated linters. But they struggle with cross-service dependencies and complex business logic constraints.

The "Augment, Don't Replace" Philosophy

The most effective engineering teams treat an ai code reviewer as a high-speed assistant rather than an autonomous decision-maker. AI models lack the operational context to make final architectural decisions. They can't negotiate API contracts or understand why a specific workaround exists for a legacy system.

That means a human-in-the-loop review remains absolutely critical. You use the AI to clear out the noise of code formatting and basic threat detection, so your senior engineers can focus their cognitive energy on system design and business logic.

Solving the Systemic Context vs. File-Level Analysis Gap

A major limitation of current AI tools is their reliance on file-level analysis. An AI assistant might review a single pull request and confirm the syntax is perfect. Yet that same code might break cross-service dependencies three layers deep in your application.

This happens because AI context windows face strict VRAM limits and memory constraints, preventing them from holding your entire codebase in memory at once. Trusting AI file-level analysis without verifying the broader repository context is a common mistake that leads directly to architectural drift. Your delivery pipeline must connect code changes to system-wide impacts to prevent this risk.

Are AI Code Reviews Accurate?

Yes, a code review ai is highly accurate when evaluating isolated syntax and standard formatting rules. Conversely, accuracy drops to near zero when evaluating complex logic or proprietary frameworks. This drop in precision introduces high rates of false positives and AI hallucinations into your pull requests.

Consider a common scenario where an AI tool successfully identifies a missing variable declaration but completely misses a breaking change in your core payment processing logic. The AI then floods the pull request with dozens of comments about stylistic formatting. Developers end up arguing with an AI bot in the comments over subjective syntax choices, creating massive review churn.

This noise creates an overwhelming backlog for human reviewers and actively slows down sprint velocity. Developer overreliance on these tools compounds the problem. Junior engineers might blindly accept AI suggestions without understanding the underlying code, injecting hidden technical debt into the system. You must measure this friction continuously to ensure the tool is actually accelerating your workflow rather than just generating noise.

Top AI-Powered Code Review Tools Compared for 2026

Selecting the best ai code review tools requires matching the platform's core capability to your specific workflow bottleneck. You must differentiate between tools that generate code, platforms that scan for vulnerabilities, and systems that measure the systemic impact of those changes.

Automated Pull Request Summarization Bots

Tools like CodeRabbit and Qodo focus heavily on pull request summarization. They read the diff and generate a plain-language summary of the changes, so human reviewers can grasp the intent faster. This approach often improves initial time-to-merge metrics for simple tasks.

But open source ai code review tools in this category can struggle when deployed on massive enterprise monorepos. The sheer volume of interconnected files overwhelms the model. This leads to generic summaries that fail to capture the actual architectural impact of the change.

Native Integrated Development Environment Extensions and Agents

GitHub Copilot and similar IDE extensions operate directly where developers write code. These tools use agentic workflows to suggest entire functions as the developer types. They are incredibly effective at reducing the time spent writing boilerplate syntax.

They operate with a limited view of the broader system. A native extension might suggest a highly efficient sorting algorithm, yet it can't verify if that logic violates broader API contracts established by another team. Human reviewers must still validate those systemic connections.

Enterprise Continuous Integration and Continuous Deployment Security Scanners

Enterprise platforms like SonarQube and Greptile focus on strict CI/CD integration. They run deep static analysis to ensure your codebase maintains OWASP compliance and prevents known vulnerabilities from reaching production. These tools are non-negotiable for teams operating in highly regulated environments.

A major consideration in this category is data sovereignty. Sending proprietary enterprise code to external models for security scanning introduces compliance risks. You must configure these tools to ensure sensitive data remains within your controlled infrastructure.

Operational Intelligence and Measurement Platforms

Adopting ai powered code review tools frequently increases raw output while secretly damaging delivery predictability. You need a way to measure this friction. TargetBoard is an agentic operational intelligence platform that helps leadership teams understand how execution is performing, why it is changing, and how to respond.

TargetBoard connects data across company systems and uses domain-expert AI agents to understand workflow bottlenecks. It acts as the essential operational intelligence layer that shows you if your AI coding tools are actually improving sprint velocity or just creating massive review churn.

How to Do an AI Code Review (Without Increasing Review Churn)

Implementing ai code reviews requires strict boundaries. You must configure the tool to handle objective rules while reserving subjective architectural decisions for human engineers. If you fail to set these boundaries, the AI will argue with your developers over code formatting and stylistic preferences.

This friction causes massive review churn and slows down your entire pipeline. You must structure the workflow to prevent this noise.

Visualizing the AI-Augmented Continuous Integration and Continuous Deployment Workflow

You must map exactly where the AI intervenes in your Software Development Lifecycle. The AI should run its analysis immediately upon pull request creation. It scans for syntax errors, basic code smells, and formatting violations.

The developer resolves these objective flags before a human reviewer is ever assigned to the pull requests. This sequence ensures your senior engineers only spend their time reviewing complex logic and system architecture.

Configuring Custom Rule Files and Guidelines

You must train your AI tools using custom rule files specific to your repository. This step prevents the AI from suggesting changes that violate your internal business logic constraints. You can configure the tool to enforce DRY principles and flag code duplication automatically.

The interaction between these custom rule files, the model's context windows, and your code repositories determines the success of the tool. A well-configured rule file reduces false positives and ensures the AI only surfaces actionable insights.

How to Measure the Systemic Impact of AI Code Reviews

You can't manage what you don't accurately measure. Relying on basic productivity metrics like lines of code written will mislead your leadership team. According to the 2023 DORA Report, true delivery predictability matters far more to business outcomes than raw development speed. You must measure if your ai code review tools are actually accelerating delivery or just shifting the bottleneck.

TargetBoard provides this critical measurement layer. It tracks the difference between AI-generated output and human review times. If an AI tool increases output by 40 percent but causes pull requests to sit in review for three extra days, your actual sprint velocity decreases. TargetBoard exposes these hidden workflow bottlenecks, so you can adjust your strategy based on objective operational intelligence rather than intuition.

Reclaiming Engineering Velocity Safely

The primary value of an AI code review tool is workflow efficiency, not replacing human architectural judgment. These tools are highly effective at clearing out boilerplate errors and enforcing basic code quality. Yet they introduce their own hidden complexities that require continuous systemic measurement.

According to 2024 GitHub Copilot research, AI assistants boost developer productivity by up to 55 percent. You must balance that speed with strict oversight to protect codebase maintainability and prevent the accumulation of technical debt. By running an operational intelligence layer alongside your AI tools, you can safely accelerate software delivery while maintaining complete confidence in your engineering metrics.

What Is Value Stream Management?

Value stream management (VSM) is an operational framework that connects business objectives to the software delivery lifecycle. The goal is to optimize how work moves from idea to production, helping leaders identify constraints and improve continuous flow. But tracking work is only the first step.

You must connect those tracking metrics to actual customer value and time-to-market outcomes. When you understand how value flows through your organization, you can stop reacting to delayed releases and start proactively removing the barriers that slow your teams down.

The 4 Core Principles of Value Stream Management

To build a reliable value delivery pipeline, you need to understand the foundational rules of the methodology. These principles guide teams toward predictable delivery and continuous improvement.

How Value Stream Management Operates in Software Delivery

Applying these concepts to engineering requires a hard look at how your teams actually work. You likely track engineering performance using standard indicators like cycle time, lead time, and deployment frequency. These numbers provide a baseline for your delivery speed.

But a dashboard showing a spike in lead time doesn't solve the underlying problem. You have to trace that metric back to the specific workflow behaviors causing the delay. This requires connecting data across your planning and code systems to see the reality of your operations.

Identifying Workflow Friction and Bottlenecks

Workflow friction often hides inside routine development tasks. Consider a scenario where your overall cycle time suddenly spikes by 40 percent. The dashboard flags the delay, but it can't tell you that three high-complexity pull requests have been sitting in the review queue for four days.

The code is written, yet cross-team dependencies and unclear ownership prevent anyone from merging it. This code review churn artificially inflates your cycle time metrics. The work itself isn't slow, but the system is blocked. Identifying these specific constraints allows you to clear the path rather than just asking teams to code faster.

Shifting From Project to Product

Traditional organizations fund temporary projects, which naturally creates organizational silos. Teams assemble, build a feature, and then disband. This breaks execution alignment and leaves no clear owner for long-term maintenance or technical debt.

Modern value stream management requires a shift toward a product-centric model. You fund stable, cross-functional teams that own a specific product from end to end. This structure improves capacity allocation because you align your best engineers with long-term value delivery rather than temporary task lists. The result is a more resilient delivery engine that adapts quickly to market changes.

How to Do Value Stream Management Step by Step

Implementing this framework requires a structured approach to analyzing your value streams. You need to connect resource planning directly to your value delivery pipeline. This ensures you are solving the right problems instead of just optimizing isolated tasks.

What Are the 4 Steps of Value Stream Mapping?

Value stream mapping is the diagnostic tool you use to visualize how work flows through your organization. Follow these four steps to build an accurate map:

1. Identify the product: Define the exact service or feature set you are analyzing.
2. Map current state: Document every step and handoff currently required to deliver that product to the customer.
3. Design future state: Identify bottlenecks in your current map and design an optimized workflow without those constraints.
4. Create implementation plan: Build a clear roadmap to transition your engineering teams to the optimized future state.

The 7 Wastes of Value Stream Mapping in Modern Engineering

To improve flow efficiency, you must identify where engineering effort goes to waste. Modern software leaders face specific capacity concerns that look very different from physical manufacturing. Here is how the classic seven wastes translate to software delivery.

The Limitations of Traditional Value Stream Management (Why Dashboards Aren't Enough)

You can map your workflows perfectly, but legacy tools often fail because they rely on metrics without context. You see cycle time shifting, but you can't explain why execution breaks down. According to a 2023 Gartner report on engineering operations, most leaders struggle because their operational data is trapped in data silos.

This forces executives to rely on subjective updates from managers instead of trusted system-level reality. Tracking metrics provides visibility, but it doesn't provide understanding. TargetBoard is an agentic operational intelligence platform that connects data across company systems, interprets performance through operational intelligence, and uses domain-expert AI agents to guide execution decisions.

This shifts your organization from reactively monitoring dashboards to proactively fixing workflow friction. You gain the power to make confident execution decisions based on reality.

How Artificial Intelligence Changes the Value Stream

Artificial intelligence code generation accelerates output, so it fundamentally alters how work flows through your system. But higher output often introduces hidden delivery risk. For example, artificial intelligence code frequently experiences higher code review churn than human-written code because it requires intense scrutiny to verify complex logic.

If you only measure output volume, you miss the bottleneck forming in your review stage. This hidden complexity slows down the entire pipeline and delays critical execution decisions.

Measuring vs. Understanding Performance

Tracking DevOps Research and Assessment metrics is a good start, but it's only showing you the symptoms of an inefficient system. You need to diagnose the disease through root cause analysis to achieve predictable delivery.

Moving Beyond Metrics to System-Level Delivery Predictability

A common mistake in engineering leadership is treating performance metrics as goals rather than lagging indicators of system health. According to the 2023 Forrester Report on software delivery, teams that focus purely on metric targets often sacrifice long-term stability. When you stop chasing numbers and start focusing on resolving the underlying workflow constraints, your delivery confidence naturally improves.

This operational shift connects daily engineering tasks directly to broader business outcomes. By treating visibility as a starting point rather than the finish line, you create a culture of continuous improvement that actually scales. Understanding your system gives you a clear framework for your next planning session or your next board meeting.

‍