AI can generate more code.

More pull requests.

More tests.

More documentation.

More implementation plans.

More branches that look suspiciously productive at 1:37 a.m.

More retrospectives where the chart goes up and the team is somehow more tired.

But more activity is not the same as more value.

Software teams have always had a measurement problem. We measure what is easy to count: tickets closed, story points completed, pull requests merged, commits created, deployments completed, lines changed. Then we hope those numbers somehow add up to value.

Sometimes they do.

Often they do not.

And now AI makes the problem sharper.

AI-assisted development can increase the amount of code produced, the number of iterations attempted, and the speed at which a developer can move from idea to implementation. Coding agents can pick up issues, generate branches, run tests, self-review, scan for security issues, and hand back pull requests. GitHub’s 2026 updates to Copilot coding agent show this direction clearly: model selection, self-review, built-in security scanning, custom agents, and CLI handoff are becoming part of the agentic software workflow.

That sounds like acceleration.

But acceleration toward what?

That is the question value-driven development forces us to answer.

Value-driven development is not a new ceremony or a shiny methodology. It is a simple operating principle:

Build, measure, and improve software based on the value it creates, not the volume of engineering activity it generates.

In classic software delivery, this was already important.

In AI-assisted delivery, it becomes much harder to skip.

Because when code becomes cheaper to generate, judgment becomes more expensive.

The Old Trap: Output Pretending to Be Outcome

A team ships five pull requests.

Is that good?

Maybe.

A team reduces average PR size by 40%.

Is that good?

Probably, but not always.

A team increases AI-assisted code generation by 60%.

Is that good?

Nobody knows yet.

This is the central problem with many engineering metrics: they describe activity, not value.

A PR can be technically excellent and strategically irrelevant.

A ticket can be closed and still not improve the customer experience.

A feature can be delivered on time and still fail to move the business metric it was supposed to move.

A refactor can look elegant and still not reduce future delivery cost.

A codebase can become busier while the product becomes worse.

AI makes this trap more dangerous because it lowers the friction of producing software artifacts. A developer can ask an assistant to generate a migration script, test cases, API scaffolding, documentation, monitoring queries, and a first implementation. Agents can produce branches. Code review tools can comment. Security scanners can run earlier.

All of that is useful.

But more artifacts do not automatically mean more value.

In fact, Harness’s 2026 DevOps Modernization research describes this exact shape of problem: AI is accelerating code production, but many organizations have not modernized the testing, security, and deployment systems that must absorb the increased output. The result is more downstream work, more deployment instability, and more pressure on engineering teams.

So the question is not:

How do we make engineers produce more with AI?

The better question is:

How do we make sure AI-assisted work is connected to meaningful, validated outcomes?

That is the real AI-SDLC measurement problem.

What Value-Driven Development Means

Value-driven development means every meaningful engineering effort should be connected to a value hypothesis.

Not a vague statement like:

Improve platform scalability.

But something more concrete:

Reduce onboarding time for new enterprise customers by cutting manual provisioning steps from five to one.

Or:

Reduce production incident recovery time by improving service ownership, alert routing, and rollback safety.

Or:

Increase support deflection by allowing customers to self-serve the top three account configuration changes.

Or:

Reduce the average time to safely change pricing logic from two weeks to two days.

The difference is not cosmetic. The second version gives the team something to measure after delivery.

Value can come in several forms:

Value Type Example
Customer value Faster onboarding, fewer errors, better experience
Business value Revenue, conversion, retention, cost reduction
Operational value Fewer incidents, faster recovery, less manual toil
Engineering value Faster future delivery, reduced complexity, better testability
Risk reduction Security, compliance, privacy, reliability
Learning value Validating or invalidating a product assumption

The important point: value is not only revenue.

A security patch can be value-driven.

A flaky test fix can be value-driven.

A dependency upgrade can be value-driven.

A refactor can be value-driven.

But the value needs to be named.

“Refactor billing service” is an activity.

“Reduce the cost and risk of future pricing changes by simplifying billing rule ownership and increasing test coverage around the pricing decision path” is value-driven engineering.

Why AI Changes the Measurement Problem

The AI-SDLC changes the economics of software work.

Historically, implementation effort was a major constraint. Engineers had to spend significant time writing boilerplate, exploring APIs, creating tests, updating docs, and wiring systems together.

AI reduces some of that friction.

But every acceleration creates a bottleneck somewhere else.

In AI-assisted teams, the bottleneck often moves to (a shift I explored in more depth in The Pace):

New Bottleneck What It Looks Like
Problem selection Teams build more, but not necessarily the right things
Specification quality AI starts quickly, but from vague or incomplete intent
Review capacity Senior engineers spend more time validating generated work
System understanding Code is produced faster than humans understand consequences
Test quality More tests exist, but confidence does not increase proportionally
Product validation Features ship before teams know whether users need them
Maintenance burden AI makes creation cheaper, but ownership remains expensive

Stack Overflow’s 2026 article on the developer AI trust gap puts a sharper number on this: AI tool usage among developers has climbed to 84%, while trust in those tools has fallen to 29%. People are using more AI and believing it less. The same article argues that teams need developers who understand fundamentals, tests, scale, and reliability — what is actually happening under the hood — before pushing AI-assisted work into production.

That is a useful leadership framing.

AI does not remove the need for engineering judgment.

It increases the importance of judgment because more work can now be attempted faster.

PR Tracking Is Useful, But Not Sufficient

Pull request metrics are tempting because they are available.

GitHub, GitLab, Bitbucket, Jira, Linear, and internal engineering dashboards can usually tell you:

PR Metric What It Can Reveal
PR count Activity volume
PR size Batch size and review difficulty
Review time Collaboration bottlenecks
Time to merge Flow efficiency
Reopen rate Requirement churn or quality issues
Comments per PR Review complexity or disagreement
Author/reviewer distribution Knowledge concentration
Change failure after merge Delivery risk

These are useful. I would track many of them.

But they are not enough.

The problem is that PR metrics mostly describe the movement of code, not the realization of value.

A team can optimize PR flow and still build the wrong thing.

A team can reduce merge time and still increase production defects.

A team can produce more AI-assisted PRs and still create more review burden than delivery capacity.

A team can split PRs beautifully and still fail to improve customer outcomes.

PR metrics are like measuring how fast food leaves the kitchen. Useful, yes. But they do not tell you whether customers liked the meal, whether they came back, or whether the restaurant made money. A kitchen sending out forty plates an hour and a kitchen sending out forty plates an hour that nobody finishes look identical from the pass.

In the AI-SDLC, PR metrics are even more incomplete because AI changes the meaning of activity.

A developer may generate more code with less effort, but reviewers may absorb more hidden work.

The visible PR count goes up while invisible cognitive load increases.

The dashboard says throughput improved.

The team feels worse.

That is not productivity.

That is cost shifting — and it changes what “trust” in an engineering team needs to mean, which I dig into in How Teams Learn to Trust in the Age of AI.

This concern is showing up in current industry research too. Harness’s 2026 engineering excellence report reported that many engineering leaders believe AI has improved productivity and satisfaction, while also reporting that developers spend more time in code review after adopting AI coding tools.

That is the paradox.

AI may make code generation cheaper while making validation more expensive.

PR metrics should be treated as diagnostic metrics, not success metrics.

They help answer:

Where is the delivery system getting stuck?

They do not fully answer:

Did this work matter?

The Missing Layer: Value Traceability for AI Work

This is where I think AI-SDLC needs a new operating pattern: value traceability.

Every meaningful AI-assisted task should connect back to a structured work item before implementation begins.

That work item could be a Jira ticket, RFC, incident, product requirement, architecture decision, or technical debt item. In many companies, Jira is the natural system of record.

Not because Jira is sacred.

Jira is not sacred. Sometimes Jira is where good ideas go to age like cheese in a forgotten office refrigerator.

But a Jira ticket can provide something a prompt usually does not: traceability of intent.

AI work should not start from a random prompt.

It should start from a clear unit of intent.

That is the idea behind a Claude skill I am experimenting with: before AI performs meaningful engineering work, the skill checks whether the work is connected to a Jira ticket. Then it checks whether the ticket actually describes the problem, expected value, prerequisites, and acceptance criteria. It can also record token usage and approximate AI cost back to the ticket.

The goal is not process theater.

The goal is to prevent AI from accelerating poorly understood work.

The AI Work Ledger

One practical pattern is an AI Work Ledger.

The idea is simple: every meaningful AI-assisted task should leave behind a traceable record.

The record should answer:

Question Why It Matters
Why does this work exist? Connects implementation to intent
Who benefits? Clarifies customer, business, operational, or engineering value
What is the expected value? Defines what should improve
What are the prerequisites? Prevents AI from acting on missing context
What is in scope? Reduces uncontrolled expansion
How will we validate it? Forces measurement after delivery
How much AI assistance was used? Makes AI cost visible
What human validation happened? Makes review and risk visible
What happened after release? Closes the value loop

A Claude skill can enforce or assist this flow:

Developer or Agent Prompt
        ↓
Value Traceability Check
        ↓
Linked Jira Ticket?
        ↓
Problem, Value, Scope, Acceptance Criteria?
        ↓
Prerequisites and Risks Clear?
        ↓
AI Work Allowed / Blocked / Needs Clarification
        ↓
Implementation, Tests, Docs, PR
        ↓
AI Tokens + Approximate Cost Written Back
        ↓
Post-Delivery Value Review

This turns AI assistance into a measurable part of the delivery system.

The interesting metric is not simply:

How many tokens did we spend?

The interesting metric is:

How much useful, validated work did we get for the total cost of AI assistance, human review, rework, and operational risk?

That is a much better question.

What the Claude Skill Should Check

A weak version of this system would only check whether a Jira ticket exists.

That would create compliance theater:

Ticket exists. Proceed.

A useful version checks whether the work is meaningful, ready, and measurable.

1. Intent Check

Does the ticket explain why this work matters?

Weak ticket:

Update account provisioning flow.

Better ticket:

Reduce enterprise account provisioning time by automating manual configuration steps currently handled by support.

Best ticket:

Reduce enterprise account provisioning time from three days to one day by automating the three most common manual configuration steps. Measure impact using provisioning duration and related support ticket volume one month after release.

The skill can classify the work type and ask the right value question:

Work Type Value Question
Feature What customer behavior or outcome should change?
Bug fix What user pain, incident, or correctness issue is resolved?
Platform work What future delivery or operational friction is reduced?
Refactor What change, test, reliability, or comprehension cost improves?
Security work What risk is reduced?
Experiment What assumption are we trying to validate?

This prevents implementation-only tickets from becoming AI fuel.

2. Readiness Check

AI is very good at confidently acting on incomplete context.

The skill should check whether the ticket contains enough prerequisites to proceed safely:

Readiness Area Example Questions
Dependencies Are required APIs, schemas, designs, or upstream changes available?
Ownership Which service, team, or domain owns the change?
Constraints Are there performance, privacy, compliance, or compatibility limits?
Existing behavior Is the current behavior described or linked?
Rollout Is this behind a flag, migration, or gradual release?
Testing What tests or verification steps are expected?

This matters even more in agentic workflows. GitHub’s 2026 work on an agentic memory system for Copilot points toward agents that can preserve more context across coding sessions. The more agents participate across the lifecycle, the more important it becomes to give them high-quality context before they act.

3. Value Classification

The skill should require the ticket to name the value category.

Value Category Example
Customer value Faster onboarding, fewer errors, better UX
Business value Revenue, retention, conversion, cost reduction
Operational value Lower incident rate, faster recovery, less manual toil
Engineering value Faster future changes, better testability, simpler ownership
Risk reduction Security, compliance, reliability, privacy
Learning value Validating an assumption before larger investment

This is important because otherwise business-facing work gets privileged and engineering work gets mislabeled as “internal cleanup.”

Good engineering work creates value.

The team just needs to say what kind.

4. AI Cost and Token Tracking

Tracking token usage and approximate cost is useful, but only if framed correctly.

The goal is not “spend fewer tokens.”

That would be like measuring engineering effectiveness by keyboard wear.

The goal is to understand AI cost per useful outcome.

The skill could append metadata like:

Field Example
Model used Claude Sonnet, Claude Opus, local model
Prompt tokens 42,000
Output tokens 9,500
Approximate cost $X.XX
AI task type Analysis, planning, implementation, tests, docs, refactor
Number of AI iterations 7
Human review required Yes
Rework required Partial
Final disposition Merged, abandoned, reverted, converted to research
Value status Not measured, confirmed, unclear, negative, learning captured

Over time, this becomes powerful.

You can ask:

Question Why It Matters
Which work types consume the most AI tokens? Finds expensive workflows
Which AI-assisted tasks actually reach production? Separates useful work from experimentation
Which tasks get abandoned after high AI spend? Reveals unclear intent or poor readiness
Which prompts/spec formats reduce rework? Improves team practice
Which areas create high AI cost and high review burden? Identifies complexity hotspots
Does AI cost correlate with value delivered? Moves beyond novelty adoption

This creates a more mature metric: AI-assisted value efficiency.

Not tokens.

Not PRs.

Not prompt count.

Value efficiency.

5. Reasoning and Meaningfulness Check

This might be the most important part.

The skill should not expose or require private chain-of-thought style reasoning. But it can require a concise decision rationale.

For example:

Field Description
Why now? Why is this work worth doing at this point?
Alternatives considered What simpler or safer options exist?
Expected impact What should improve?
Risk of not doing it What happens if we defer?
Confidence level High, medium, low
Evidence Metrics, customer feedback, incidents, support tickets, roadmap priority

This becomes a lightweight reasoning gate.

Before an AI agent starts work, the skill can ask:

This ticket does not explain why the work is needed now. Add a short rationale or link to supporting evidence.

Or:

This appears to be a refactor. What future change, reliability issue, or maintenance cost does it improve?

Or:

This task requests implementation, but no validation plan is listed. How will we know the change worked?

This avoids one of the worst AI-SDLC failure modes: using AI to make low-value work feel productive.

How to Set This Up for a Team

A practical value-driven AI-SDLC setup does not start with a giant dashboard.

It starts with operating discipline.

Step 1: Add a Value Hypothesis to Every Meaningful Work Item

For any epic, project, or non-trivial technical investment, require four fields:

Field Question
Problem What problem are we solving?
Beneficiary Who benefits?
Expected value What should improve?
Measurement How will we know?

Example:

We believe improving the account provisioning workflow will reduce manual support escalations for enterprise onboarding. We expect to reduce average provisioning time from three days to one day and reduce related support tickets by 30% within one month of release.

This does not need to become heavyweight bureaucracy.

It can be one paragraph in a Jira ticket, RFC, project brief, or AI work request.

Step 2: Create a Definition of Ready for AI Work

Before significant AI work begins, the work item should satisfy a lightweight Definition of Ready:

Requirement Example
Linked work item Jira ticket or RFC exists
Clear value Customer, business, operational, or engineering value named
Acceptance criteria Done means something observable
Context links Relevant docs, code areas, APIs, incidents linked
Risk level Low, medium, high
Validation plan Tests, rollout, metrics, or manual verification described

This is not about slowing the team down.

It is about making sure acceleration starts in the right direction.

Step 3: Separate Delivery Metrics From Value Metrics

Do not let the dashboard confuse these two categories.

Delivery metrics:

  • PR cycle time
  • deployment frequency
  • lead time
  • review time
  • build time
  • incident recovery time

Value metrics:

  • adoption
  • conversion
  • customer task completion
  • support ticket reduction
  • revenue impact
  • cost reduction
  • operational toil reduction
  • developer time saved
  • risk reduction
  • validated learning

Both matter.

But they answer different questions.

Delivery metrics tell you whether the system moves.

Value metrics tell you whether movement mattered.

Step 4: Instrument AI-Assisted Work Explicitly

AI-assisted development needs its own visibility, but not for surveillance.

The goal is not:

Which developer used AI enough?

That is the wrong question.

Better questions:

Question Why It Matters
Which types of work benefit most from AI? Helps focus adoption
Where does AI create review burden? Prevents hidden overload
Does AI reduce cycle time without increasing defects? Measures net value
Are generated tests catching real regressions? Separates quantity from confidence
Are AI-assisted PRs larger or riskier? Protects delivery stability
Which prompts/specs produce better outcomes? Improves team practice

Teams can track AI involvement at the work-item level:

Field Example Values
AI involvement None, assisted, agent-generated, AI-reviewed
AI use case Planning, implementation, test generation, refactor, docs, analysis
Human validation Author reviewed, peer reviewed, owner reviewed, production verified
Risk level Low, medium, high
Outcome Merged, reworked, reverted, abandoned, learning captured

This should be used to improve the system, not rank individuals — the same posture I argued for in Engineering Management Evolution in Agentic Engineering, where the management instrument surfaces evidence, not verdicts.

Step 5: Keep PRs Small, Especially With AI

AI can generate large changes quickly.

That does not mean humans can review large changes safely.

In fact, AI makes small-batch discipline more important.

A good team rule:

AI can produce the first draft quickly, but humans should shape delivery into small, reviewable, reversible changes.

Track:

  • median PR size
  • review time by PR size
  • rework rate by PR size
  • incidents by PR size
  • AI-assisted PR size compared with human-only PR size

If AI-assisted PRs are consistently larger, slower to review, or more likely to require rework, the team has not improved delivery.

It has moved the cost downstream.

Step 6: Add Human Validation Levels

Not all AI output carries the same risk.

A generated README update and a generated billing migration should not receive the same review treatment.

Use simple validation levels:

Validation Level Meaning
L1 Human skimmed and accepted low-risk output
L2 Human reviewed code and tests carefully
L3 Domain owner reviewed architecture or risk
L4 Production validation, rollout, or security review required

This gives the team a shared vocabulary for AI risk.

It also prevents a dangerous fiction: that all AI-assisted work is equally trustworthy.

Step 7: Create a Value Review Ritual

Most teams review delivery.

Fewer review value.

Add a lightweight biweekly or monthly value review:

Question Discussion
What did we ship? Delivery recap
What value did we expect? Original hypothesis
What happened? Actual signal
What did AI help with? Planning, code, tests, docs, review, research
What did AI cost? Tokens, tool cost, review cost, rework
What did we learn? Product, technical, operational learning
What should change? Continue, adjust, stop, double down

This is especially important for AI-generated or AI-accelerated work.

If AI helped deliver something faster, the team should still ask whether faster mattered.

A Practical Dashboard Structure

A useful value-driven AI-SDLC dashboard should avoid one giant productivity score.

One score will lie to you.

Instead, use layered measurement:

Layer Metrics Purpose
Value Adoption, revenue, support reduction, time saved, SLO improvement Did the work matter?
Flow Lead time, PR cycle time, deployment frequency, blocked time Can we deliver repeatedly?
Quality Defects, rollback rate, change failure rate, security findings Are we safe?
AI Impact AI-assisted work type, token cost, rework rate, review load Is AI helping net productivity?
Traceability Percent of AI work linked to Jira, percent with value hypothesis, percent validated after release Is AI work connected to intent?
Team Health Review load, focus time, satisfaction, burnout indicators Is the system sustainable?

The key is balance.

If value improves but quality collapses, the system is fragile.

If flow improves but value does not, the team is busy but ineffective.

If AI usage increases but review burden explodes, productivity moved from visible coding to invisible validation.

If PR count increases but customer outcomes stay flat, the organization is measuring motion.

Watch for AI Waste

AI waste is not tokens used.

AI waste is AI-assisted work that produces no useful artifact, no validated learning, and no shipped value.

Examples:

  • an agent generates a large PR that is abandoned
  • an AI refactor consumes review time but does not improve maintainability
  • generated tests assert implementation details and are later deleted
  • a prototype is built without a decision or learning outcome
  • AI-created documentation is not accurate enough to trust
  • a ticket gets “implemented” even though the original problem was never validated

This is one of the strangest parts of AI-SDLC.

Waste can now look impressive.

It can look like a large diff.

It can look like a detailed plan.

It can look like a polished document.

It can look like progress.

It can even look like a demo, which is the most expensive disguise.

In the AI-SDLC, waste does not only look like idle time. Waste can look like beautifully generated work with no value path.

That is why value traceability matters.

What Engineering Leaders Should Watch For

Value-driven development can fail in predictable ways.

1. Turning Value Into Bureaucracy

If every small bug fix requires a business case, people will hate the process.

Use value hypotheses for meaningful work, not every tiny change.

2. Over-Indexing on Business Metrics

Some engineering work creates second-order value.

Platform reliability, test infrastructure, security, and observability may not map cleanly to revenue this quarter. That does not mean they are low value.

The right move is to name the engineering value clearly.

3. Using Metrics to Judge Individuals

This is dangerous in normal software development and worse in AI-SDLC.

AI changes activity patterns. Some engineers may generate lots of code. Others may spend their time reviewing, designing, debugging, validating, or preventing bad work from entering the system.

A naive dashboard may reward the person creating visible artifacts and punish the person protecting the architecture.

4. Measuring AI Adoption Instead of AI Impact

“Percentage of engineers using AI” is not a value metric.

It is an adoption metric.

Better questions:

  • Did AI reduce cycle time?
  • Did it reduce toil?
  • Did it improve test quality?
  • Did it increase review burden?
  • Did it increase or reduce defects?
  • Did it help us validate more ideas faster?
  • Did customer or business outcomes improve?

AI adoption is only useful if it improves the system. The shape of the role matters more than the headcount using the tool — a point I made in The New Engineering Roles With AI.

5. Forgetting the Human Cost of AI Work

AI can make code generation feel cheaper.

But review, validation, debugging, incident response, and long-term maintenance are still human-heavy.

The team should measure the full system cost, not just the generation cost.

The Core Shift: From Shipping Code to Managing Value Flow

In the AI-SDLC, engineering leadership becomes less about asking:

How do we get people to write more code?

And more about asking:

How do we make sure more generated code turns into more realized value?

That shift changes the role of specs, tickets, PRs, reviews, metrics, and team rituals.

Specs become value contracts, not just implementation instructions.

Jira tickets become units of intent, not just backlog containers.

PRs become delivery checkpoints, not productivity proof.

Dashboards become learning tools, not performance theater.

AI cost becomes part of engineering economics, not a mysterious platform bill.

Claude skills and coding agents become governance mechanisms, not just productivity toys.

The best teams will not be the ones that generate the most code.

They will be the ones that build the strongest connection between intent, implementation, validation, and value.

That is value-driven development in the AI-SDLC.

Not “move faster.”

Move faster toward something that matters.

References