# Bharat Sharma — complete articles

> Senior Engineering Leader & AI Transformation Executive. I build and scale the engineering organizations behind ambitious products.

Every article in full, newest first. Canonical URLs are given per article;
cite those rather than this file. Index at https://bharatsharma.pro/llms.txt.

---

# Autonomy Is Earned per Action, Not per Agent

AI agents now act faster than people can verify. A per-action operating model for when evidence justifies removing human approval, and when review must stay.

Published: 2026-09-22
Category: Engineering Leadership
Tags: AI, AI Agents, AI Governance, Engineering Leadership
Canonical: https://bharatsharma.pro/articles/autonomy-is-earned-per-action-not-per-agent

Agents can now produce actions faster than people can responsibly verify them. The closest measurement is not an agent study but one of AI-assisted coding: in METR's 2025 randomized trial, 16 experienced open-source developers took 19% longer on 246 real tasks when AI was allowed.[^1] The slowdown is not the point; the redistribution is. Time moved from writing into prompting, waiting and reviewing, and in that one setting the time those added exceeded the time saved on writing. METR's follow-up says newer tools likely speed developers up, though its measurements can no longer isolate by how much.[^2] It shows that AI redistributes work toward verification, not that verification is everyone's bottleneck; whether it is yours depends on your volumes and controls. Measure it. Do not assume it.

Klarna is the version everyone knows. In February 2024 it said its assistant had held 2.3 million conversations in a month, the workload of 700 full-time agents, and estimated a $40 million profit improvement.[^3] Company numbers, unaudited. By May 2025 its CEO told Bloomberg it was hiring human agents again because cost had dominated the evaluation and quality had fallen.[^4] Klarna proves nothing universal. It shows that aggregate throughput and per-case adequacy are different measurements, and one can look excellent while the other degrades unseen.

Two poor answers dominate. Keep a human approving every action, and you have rebuilt the queue automation was meant to dissolve. Grant broad autonomy because the demos are impressive, and you have converted a capability claim into an authorization decision. Between them sits the missing operating model, calibrated trust made operational: human review as temporary support for a precisely defined class of agent work, retired as evidence accumulates, kept where evidence cannot reach.

## Five terms, kept apart

Reliability is a measured property: how often, and how badly, a specific configuration fails at a specific action class. Trust is the calibrated belief you form from that measurement, and it is exactly as wide as the measurement. Autonomy is the review regime you apply: how much human attention per action. Authorization is the technically enforced permission set: credentials, allowlists, transaction and rate limits, data boundaries, isolation, logging, automatic suspension. Accountability is a named role that answers for outcomes and holds the authority, resources and duty to halt the system, investigate and remedy harm.

Evidence changes trust and, through trust, autonomy. It never changes authorization; humans do that, separately.

## The unit that earns

The agent does not earn anything. The unit that earns is a combination: agent configuration × action class × operating environment × permission scope × verification system. Change one materially and the record no longer describes what is running. An agent trusted to triage internal IT tickets has earned nothing about external refunds; that is the obvious half. The less obvious half is that the same refund workflow on a new model version, or a new market's payment rails, is a new unit whose record must be rebuilt. Reliability does not transfer on its own.

## A ceiling, and a position below it

Autonomy has two determinants that should never be computed together. The ceiling is set by the nature of the action: reversibility, risk-calibrated blast radius, regulatory status, and whether something other than the model can verify the outcome. Authorization bounds what the agent *can* do; the ceiling bounds how little review it may receive. The ceiling is fixed for the current system design: routine performance cannot raise it, and it moves only when the system changes (a rollback path, say, or an independent verifier), through its own assessment and approval.

Reversibility is defined at the level of consequence, not storage: restoring a database does not recall an email to a vendor. Authorization is enforced outside the model from the first rung on which anything executes, and it is never widened as a consequence of promotion. An executing agent is a richer prompt-injection target than a drafting one; its permission scope caps the payoff. Below the ceiling, the position is earned.

## The mixed-autonomy ladder

The ladder changes the form of review so that the supervision ratio, how much agent output one person can responsibly stand behind, rises with the strength of the verification beneath it instead of with headcount.

| Rung and review regime | Evidence required to promote to the next rung |
| :---- | :---- |
| **Observe and recommend.** Agent proposes; human decides and acts | Correct on independently audited samples, including ambiguous and adversarial inputs |
| **Draft for human action.** Agent drafts; human edits and executes | Low correction rate; escalations flag what the agent did not know |
| **Execute with approval.** Human approves each action | Severity-weighted miss rate within the owner's declared limit; separate limit for unacceptable harms; restricted autonomous trial passed |
| **Execute bounded, verifiable actions.** Narrow limits; every exception to a human; random audit continues | Audit findings within limit at the required sample size; rollback drills pass; controls shown to fire |
| **Execute at expanded scope.** Wider limits; exceptions to automated hold; humans review aggregates and audit samples | None. Only a ceiling change goes further |

Most action classes should stop below the top. The last two rungs differ in exposure, not enforcement, and reaching the fifth is two decisions: an autonomy promotion earned by evidence, and a separate authorization expansion that a human approves on their own assessment of the larger capped loss. Evidence never earns the second.

Two principles govern the upper rungs. A guardrail on every action covers more than a human who inspects a sample, but it finds only what it was built to recognize. Exception-driven attention therefore replaces routine approval; it does not replace independent discovery. If humans see only what the controls flag, errors missed by both agent and detector vanish from oversight, and the apparent success rate rises because the organization stopped looking. The audit is the check on the checker. Second, sampling finds common failures and misses rare severe ones. That blind spot is why the ceiling exists.

## What counts as promotion evidence

Approval rate is the metric most often cited and least informative: even a 98% approval rate cannot distinguish a reliable agent from a tired reviewer without independent evidence. The EU AI Act names the tendency in Article 14: automation bias.[^5]

Promotion evidence should be hazard-specific and tied to a limit the owner declared in advance, per action class. The signals that justify promotion are severity-weighted miss rate on audited samples, manual-intervention rate, and how often guardrails catch a problem before a human has to. Verification time per agent task belongs in the investment case, not the safety case. Limits and standing autonomy are re-reviewed on a schedule.

Sample sizes follow from the limit and are larger than intuition suggests: zero detected failures in 3,000 independent, representative trials, with perfect detection, bounds the failure rate at roughly 0.1% with 95% confidence.[^6] That is not proof of safety, and correlated trials or imperfect detection prove less. A harm defined as unacceptable gets its own limit, and no success rate offsets it. Supervised success is not autonomous performance: shadow mode records what the agent proposed, not what would have happened, and approve-each conceals how much depended on human repair. Test the autonomous arrangement itself in a restricted trial before promoting.

## One action class, end to end

Consider a hypothetical: goodwill refunds under a fixed amount on a consumer platform. The unit is one refund-agent build on one model version, for orders below the threshold in one market, holding refund-only credentials, verified by sampled audit and daily ledger reconciliation. A completed refund is not reliably recoverable, so nothing rests on reversibility. What permits a high rung is that the potential loss is capped and explicitly accepted, and the outcome is independently verifiable. The caps are enforced outside the model: a per-transaction limit, a daily aggregate, one refund per order, payment only to the instrument the customer used.

Promotion: the owner, a named head of customer operations, declared a severity-weighted miss limit and one unacceptable harm (a refund to an account flagged for fraud) with its own limit. After a restricted trial with full reconciliation, the class moved from approve-each to bounded, verifiable execution, plus a random audit sized to detect a miss rate at the declared limit.

Demotion: the platform team upgraded the foundation model. Execution suspended automatically on the change trigger; credentials and caps did not move. The owner then decided where the class would resume. The ceiling and controls were unchanged, so the assurance case stood; what had been invalidated was the behavioral evidence on the old model. The class resumed at approve-each until that evidence was rebuilt. A prompt wording tweak the week before had been judged cosmetic and logged.

## Demotion and reset

Autonomy is revocable or it is not earned. Performance triggers: severity events, drift, a rising manual-override rate. Change triggers: model, prompt, tools, permissions, knowledge sources, input population, downstream systems, regulation, threat environment. One rule serves: identify which claims the change invalidates, restrict the affected execution, and let the named owner choose the interim regime. A change that invalidates only behavioral evidence sends the class down until it is rebuilt. A change that invalidates the assurance case itself (a new hazard class, a model swap arriving with new tools or wider permissions) warrants a reset to the bottom; a replaced model alone may, at the owner's judgment. Suspending execution and resetting permissions are separate acts, and restoring execution needs the owner's decision.

Two further boundaries. Correlated failure: instances of one configuration share a failure mode and can fail together, so a fleet is closer to one unit of risk than many. And the cost floor: for low-volume classes, evaluation, audit and rollback infrastructure can cost more than the review it replaces.

## Where human approval stays

Irreversibility, high blast radius, safety-criticality, effects on people's rights, regulation and weak verifiability each trigger an assessment of whether per-action approval must stay. None settles it alone. The rule is the one this article has been building toward: retain review where it supplies judgment, authorization or demonstrated protection. And where irreversibility, high consequence and the absence of an independent verifier coincide, approval stays, or the action is not delegated at all.

Regulation shapes the rule without replacing it. For high-risk systems in scope, Article 14 of the EU AI Act requires oversight commensurate with risk, autonomy and context, including the ability to override and halt, not approval of every action.[^7] Singapore's agentic-AI framework and NIST's AI RMF treat bounded agent powers and defined human checkpoints as controls to be designed; both are voluntary.[^8]

Rarity alone is not a reason. Low volume means observed frequencies cannot justify autonomy; it does not mean a human gate protects anyone. Some gates protect nothing because the reviewer cannot evaluate what they approve. Where neither humans nor controls can reliably assess or contain a dangerous action, the right outcome is no deployment. Human-in-the-loop is neither universally necessary nor universally sufficient.

## What remains unsettled

How far evidence transfers across minor model versions, how to set tolerable failure rates, and whether sampled audit detects drift fast enough remain unsettled. This framework says what to decide and who decides, not what the numbers are.

## The leadership implication

Accountability is not approval, and the confusion between them is what turns agent governance into a queue. Before deployment, a named role owns each action class, with the authority to halt it, narrow it and refuse its promotion. Naming an owner does not settle legal responsibility. It creates the chain of command.

The objective is not to eliminate review. It is to convert repeated human judgment into proportional, scalable controls (guardrails, limits, audits, rollback) so that human attention concentrates on exceptions, novelty and consequential decisions. The test for a leader is simple. For each agent workflow, can you name the unit, the ceiling, the owner, the declared limit and the trigger that demotes it? If not, you have not granted autonomy. You have lost track of it.

[^1]: J. Becker, N. Rush, E. Barnes, D. Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR, July 2025\. [https://arxiv.org/abs/2507.09089](https://arxiv.org/abs/2507.09089). Randomized controlled trial; 16 developers, 246 tasks in their own repositories, February to June 2025; point estimate a 19% increase in completion time with AI allowed, with the added time spent prompting, waiting on and reviewing AI output, and idle.

[^2]: METR, "We are Changing our Developer Productivity Experiment Design," 24 February 2026\. [https://metr.org/blog/2026-02-24-uplift-update/](https://metr.org/blog/2026-02-24-uplift-update/). Raw follow-up results point toward speed-up, but selection effects (developers and tasks withheld from the no-AI condition) make the estimate unreliable, and METR's time measurements were unreliable for developers using multiple agents concurrently.

[^3]: Klarna, "Klarna AI assistant handles two-thirds of customer service chats in its first month," press release, 27 February 2024\. [https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/](https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/). Figures are company-reported estimates.

[^4]: Bloomberg, "Klarna Turns From AI to Real Person Customer Service," 8 May 2025\. [https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service](https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service). CEO Sebastian Siemiatkowski's statements on hiring and on cost as an evaluation factor.

[^5]: Regulation (EU) 2024/1689 (AI Act), Article 14\. Paragraph 3 requires oversight measures commensurate with risk, level of autonomy and context of use; paragraph 4(b) addresses automation bias; paragraph 4(e) requires the ability to intervene or halt the system. Official text: [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L\_202401689](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689). The Digital Omnibus on AI, Regulation (EU) 2026/1744 (published 24 July 2026), defers obligations for stand-alone high-risk systems under Annex III to 2 December 2027\.

[^6]: The "rule of three": with zero events in n independent trials, the approximate 95% upper confidence bound on the event rate is 3/n. J. A. Hanley and A. Lippman-Hand, "If Nothing Goes Wrong, Is Everything All Right? Interpreting Zero Numerators," JAMA 249, no. 13 (1983).

[^7]: Regulation (EU) 2024/1689 (AI Act), Article 14\. Paragraph 3 requires oversight measures commensurate with risk, level of autonomy and context of use; paragraph 4(b) addresses automation bias; paragraph 4(e) requires the ability to intervene or halt the system. Official text: [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L\_202401689](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689). The Digital Omnibus on AI, Regulation (EU) 2026/1744 (published 24 July 2026), defers obligations for stand-alone high-risk systems under Annex III to 2 December 2027\.

[^8]: Infocomm Media Development Authority (Singapore), *Model AI Governance Framework for Agentic AI*, version 1.0, launched 22 January 2026, which recommends bounding agents' autonomy and access to tools and data, and defining checkpoints at which human approval is required; NIST, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1, January 2023, [https://doi.org/10.6028/NIST.AI.100-1](https://doi.org/10.6028/NIST.AI.100-1).

---

# AI Is Making Activity-Based Engineering Metrics Obsolete

AI has made activity proxies like lines of code, commits and PR counts actively misleading. Here is what to measure instead, and a 90-day plan to get there.

Published: 2026-09-15
Category: Engineering Leadership
Tags: AI, Engineering Leadership, Developer Productivity, Metrics, DORA
Canonical: https://bharatsharma.pro/articles/activity-based-engineering-metrics-are-obsolete

AI has not made engineering metrics obsolete. It has made one specific class of them, the activity proxies most organizations still put in front of their boards, actively misleading. At the same time it has made system-level outcome measures more important than they have ever been. That split is the whole argument. The evidence for it is now good enough to act on.

Here's the shape of the problem. A 2026 Halkwinds survey of 758 engineering organizations found 76% had rolled out at least one AI coding assistant organization-wide, up from 41% in 2024. Only 34% could point to a measurable, audited change in delivery metrics from that rollout.

Two-thirds of adopters can't tell whether the thing worked. Not because it didn't. Because the instruments they're reading were built for a world where writing code was the expensive part.

## The research doesn't agree with itself, and that's the finding

If you go looking for AI's productivity coefficient you will not find one. You'll find a scatter plot.

METR's 2025 randomized controlled trial put 16 highly experienced open-source developers on 246 tasks in mature repositories they already knew well. With AI tools they were 19% slower, and they had believed beforehand that they would be faster. Peer-reviewed randomized field experiments at Microsoft, Accenture and a Fortune 100 company, 4,867 developers in total, estimated 26.08% more completed tasks. An observational analysis of 16,223 developers showed up to 40.5% more PRs among heavy GitHub Copilot users, though "heavy users" is a self-selected group, and the people who lean hardest on a new tool may already have been your most prolific committers. Read that one as an upper bound, not a forecast.

So which is it? All of them. The METR cohort was expert maintainers in codebases they knew intimately, doing work where the bottleneck was judgment, not typing. The enterprise cohorts were doing assigned tasks with more boilerplate and less context. AI's effect varies with task type, developer experience and how much the codebase already lives in someone's head. If your engineering org looks more like the METR sample (small, senior, deep in a legacy system) you should expect friction. If it looks more like the enterprise field studies (large, mixed seniority, lots of well-trodden patterns) you should expect gains, at least in raw output.

The point isn't that one study is wrong. It's that a metric which can't distinguish between those two situations is useless to you.

## What's actually broken

Most engineering scorecards still lean on activity: commits, PRs, story points. Activity is cheap to count. AI removes the last excuse for that. When a feature branch costs seconds to generate, counting branches measures nothing.

**Lines of code.** AI generates boilerplate for free. Good engineering often means deleting code. LOC has always punished the refactor and rewarded the bloat; now the bloat is automated.

**Commit and PR counts.** A 2026 analysis of roughly 110,000 open-source PRs found Claude Code-authored PRs averaging about six times the size of human-authored ones. Padding, not progress.

**Story points.** Still fine for a team planning its sprint. Not fine as a productivity signal, because historical calibration assumed human effort per point, and that assumption is now wrong in ways that differ task by task.

Frankly, none of this is a new critique. What's new is that the distortion is no longer a rounding error.

## Where the work went

AI doesn't remove engineering work. It moves it downstream. The discipline is shifting from authoring to comprehension: reading, validating, reviewing, deciding whether the thing that appeared in the PR should exist at all.

You see it in the pipeline first. Developers generate code fast, the code floods CI, and [human reviewers drown](/articles/execution-is-cheap-verification-isnt). GitClear's longitudinal analysis of 211 million lines of code from 2020 to 2024 found copy/pasted duplicate code exceeding moved (refactored) code for the first time in its dataset. Separate Q1 2026 research puts code churn among heavy AI users at up to nine times that of non-users.

You see it in security next. Veracode's 2025 GenAI Code Security Report ran over 100 large language models through controlled coding tasks; 45% of the generated samples failed security tests, with OWASP Top 10 issues like cross-site scripting and log injection. That's the lab. The field: Apiiro's telemetry across Fortune 50 enterprise repositories between December 2024 and June 2025 found AI-assisted developers committing at three to four times the standard rate. Critical architectural flaws rose with them, and [privilege escalation paths](/articles/the-model-is-not-your-authorization-layer) specifically were up 322%.

And you see it in people. Under deadline pressure, engineers accept working code they don't fully understand. The gap between "it passes" and "I know why it passes" is where the next incident lives.

The industry has started calling the resulting pattern a J-curve: an initial productivity dip after AI rollout, then recovery. The dip is well documented; it is everything above. The recovery is asserted more often than it's shown. Treat it as a hypothesis about your organization, and instrument for it, rather than a promise from a vendor deck.

## The senior/junior inversion

One thing the split evidence does tell you clearly. The enterprise field experiments found less-experienced developers adopted AI more readily and gained more from it. The METR maintainers, the most experienced people in the sample, gained nothing and lost time. Put those together and you get something managers should sit with: AI compresses the production gap between junior and senior engineers while [widening the validation gap](/articles/productivity-is-not-capability). Seniors become more valuable as reviewers, architects and the people who say no. That has consequences for career ladders that most organizations haven't touched. If a junior can produce senior-looking output but can't yet tell when it's wrong, what exactly are you promoting on? And if your seniors spend their week reviewing machine output, how long do they stay?

## What to measure instead

Keep DORA-style delivery outcomes. Demote the activity proxies. Add a small number of diagnostics that expose where the displaced work is piling up.

None of these are new inventions. Most are re-weightings of things already in DORA, SPACE or your CI logs. What changes is which ones you look at first.

| Category | Diagnostic | Definition | Unit of analysis |
| --- | --- | --- | --- |
| Delivery flow | Review queue time | First substantive review timestamp − PR-ready timestamp | Team, weekly |
| Code quality | Short-horizon rework | Lines changed or reverted within 14 days ÷ lines introduced | Repo, weekly |
| Infrastructure health | Validation failure rate | PRs failing required test/security gates ÷ PRs entering validation | Pipeline, weekly |
| Production quality | Post-deployment rework | Deployments needed to remediate user-facing defects ÷ total deployments | Service, monthly |
| Cost | Rework per unit of AI spend | Short-horizon rework lines ÷ AI tooling spend (seat + token) for the same period | Org, monthly |

Some rules that matter more than the formulas:

- Track trends against a pre-AI baseline, not absolute numbers. A rising rework ratio in the months after rollout is the earliest signal that generation is outrunning comprehension.
- Never report any of these at the individual level. Not once. The moment it's visible per engineer it becomes a leaderboard, and leaderboards get gamed within weeks.
- The cost line is there because the CFO will ask. Adoption percentage tells them nothing. Rework per dollar of AI spend, trending down, is something they can act on.
- Add SPACE's satisfaction dimension alongside these. If the review load lands on your senior engineers, burnout shows up in pulse surveys before it shows up in attrition, and attrition is the expensive version.

None of these measures [business value](/articles/why-is-ai-the-easy-part) directly. Pair them with whatever the work was meant to move: revenue, adoption, retention, cost-to-serve, reliability. Otherwise you've built a faster factory with no idea what it's for.

## The amplifier

AI acts as a magnifying glass on the engineering culture you already have. The 2025 DORA report formalized this as the amplifier effect: where organizations had strong automated testing and high-quality internal platforms, AI correlated with higher throughput. The same data showed AI adoption correlating with higher instability, more change failures, more rework, longer recovery. Correlation, in both directions. But the practical reading is clear enough: if your platform is weak, AI makes it weaker faster, and activity metrics will report that as success.

Ironclad, a legal-contracting AI company, hit this directly when unconstrained AI adoption started overloading their CI. Their response was to stop counting generation and start counting what survives review: a "Trusted Throughput" measure that uses AI to assign a complexity t-shirt size to merged PRs. Mingsheng Hong, Ironclad's VP of AI, describes it as an evolving proxy, not a finished answer. They also capped agentic loop steps and enforced token hygiene so autonomous tools couldn't sit in a retry loop hammering a failing pipeline.

Worth saying: there are teams where activity metrics haven't broken. Small, senior, greenfield, everyone reviewing everyone. PR count there is still a rough but honest signal, because the review step is doing its job. The breakage is a function of scale and of how far apart generation and validation have drifted.

## A 90-day playbook

**Days 1–30: baseline.** If AI isn't broadly deployed yet, take the six months of delivery telemetry you already have and freeze it. If it is deployed, reconstruct the baseline from history and find your natural control groups: teams or task categories with materially different adoption. GitHub and GitLab APIs give you PR timestamps and review events; CI logs give you gate failures; Jira or Linear give you the defect-remediation deployments. Nothing here needs a new vendor.

**Days 31–60: guardrails.** Programmatic limits on PR size. Hard caps on agentic loop iterations. Required gates that can't be bypassed by an autonomous tool. This is the unglamorous part and it's the part that protects shared infrastructure from a thousand-line unreviewed drop at 4pm on a Friday.

**Days 61–90: rewire the report.** Remove LOC, commit count and raw PR count from every executive deck. Replace with review queue time and short-horizon rework, per team, trended against the baseline. Assign one owner for the dashboard: a platform or DevEx lead, not a delivery manager with a target to hit.

## The one risk that eats all the others

Goodhart's Law. When a measure becomes a target it stops being a measure.

Any AI-usage dashboard visible to engineers becomes a leaderboard. Once ranked, people optimize for rank: more tokens, bigger PRs, more agentic runs, none of which is product value. This isn't a hypothetical about weak-willed engineers; it's what incentives do. The mitigation is structural, not cultural. The dashboards stay diagnostic, they stay at team level or above, and they are never an input to individual performance review. Say that out loud, in writing, before the first one ships.

## Do this next quarter

Take LOC, commit count and PR count out of the board pack. Put review queue time and 14-day rework in, per team, against the six months before rollout. If those two lines don't move the right way, your adoption percentage doesn't matter. If they do, you'll finally be able to say so with numbers a board will believe.

## Sources

1. [Halkwinds: Software Engineering Productivity Benchmark Report 2026](https://www.halkwinds.com/research/software-engineering-productivity-benchmark-report-2026)
2. [METR: Early-2025 AI and experienced open-source developer productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
3. [TU Delft: Investigating autonomous agent contributions in the wild](https://research.tudelft.nl/en/publications/investigating-autonomous-agent-contributions-in-the-wild-activity/)
4. [GitClear AI Code Quality Research 2025](https://www.gitclear.com/ai_assistant_code_quality_2025_research)
5. [GitClear developer cohort analysis: AI tools attract top developers, but do they create them?](https://www.gitclear.com/developer_cohort_analysis_ai_tools_attract_top_developers_but_do_they_create_them)
6. [Veracode 2025 GenAI Code Security Report](https://www.veracode.com/wp-content/uploads/2025_GenAI_Code_Security_Report_Final.pdf)
7. [Apiiro: 4x velocity, 10x vulnerabilities](https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/)
8. [2025 DORA report](https://dora.dev/research/2025/dora-report/)
9. [DORA research publications](https://dora.dev/research/publications/)
10. [Mingsheng Hong, AI Engineer World's Fair: From tokenmaxxing to trusted throughput](https://www.ai.engineer/talks/dSg0pu8d6qg-from-tokenmaxxing-trusted-throughput)

---

# Productivity Is Not Capability

AI raises an engineer's productivity faster than it raises their capability. Junior work was an accidental apprenticeship, and leaders have to design its replacement.

Published: 2026-09-06
Category: Engineering Leadership
Tags: AI, Engineering Leadership, Talent, Developer Productivity
Canonical: https://bharatsharma.pro/articles/productivity-is-not-capability

Over the years leading engineering teams, I have watched engineers become senior in a fairly unglamorous way.

They fix bugs. They misunderstand systems. They get things wrong in code reviews. They debug production incidents. They discover that a perfectly reasonable design falls apart when it meets reality.

Eventually, something changes.

They stop merely knowing how to build something and start knowing what to question.

That distinction has been on my mind as AI gets dramatically better at software development.

The question is not simply whether AI will reduce the number of junior engineering jobs. We don't have enough evidence to make that claim universally.

The question I find more interesting is this:

If AI removes much of the work through which engineers historically developed judgment, what replaces the apprenticeship?

## The labor-market signal is worth watching

The evidence is evolving, and causality is contested.

In an August 2026 revision of a working paper using payroll data from millions of US workers at ADP client firms, Stanford's Digital Economy Lab reported that employment among 22–25-year-olds in highly AI-exposed occupations (including, but not limited to, software development) was about 19% below where it would have been had it kept pace with less-exposed occupations. The divergence appears primarily in hiring rather than layoffs. The researchers are equally clear that they do not see widespread economy-wide displacement.

Other research is less convinced that AI is driving even the changes we are seeing. The Budget Lab at Yale, working with Brookings researchers, has found no clear relationship so far between AI exposure and changes in employment or unemployment at the broader labor-market level.

And geography matters. India's technology labor market, for example, still has large fresher-hiring pipelines through IT services firms, while global capability centers are becoming increasingly important campus recruiters. The path may therefore look quite different outside the US.

So I would not describe the junior pipeline as already collapsing.

But I do think there is enough signal for engineering leaders to ask whether short-term headcount economics could eventually collide with long-term talent development.

## Productivity and learning are not the same thing

This is where the problem becomes more interesting.

A peer-reviewed Management Science study combined three randomized field experiments covering 4,867 developers at Microsoft, Accenture and a Fortune 100 company. Developers given an AI coding assistant completed roughly a quarter more tasks, although the estimate was noisy. More importantly, less-experienced developers experienced larger productivity gains. Two of the study's six authors were Microsoft researchers, and the experiments evaluated GitHub Copilot, a Microsoft-owned product.

That challenges the simplistic idea that AI primarily benefits senior engineers.

But another experiment exposes the other side of the equation.

Anthropic's own researchers ran a randomized trial with 52 mostly junior software engineers learning an unfamiliar Python library. The AI-assisted group completed the exercise slightly faster, although not by a statistically significant amount. Immediately afterwards, however, they averaged 50% on a comprehension and debugging assessment versus 67% for engineers who coded manually. The largest gap was in debugging.

This was a small, short-horizon experiment conducted by an AI vendor. It tells us nothing yet about what happens over months or years.

But it highlights a distinction I think organizations should take seriously:

AI may raise an engineer's productivity faster than it raises their capability.

Those two curves are easy to confuse.

The same Anthropic study also suggests this outcome isn't inevitable. Participants who used AI to ask conceptual questions, request explanations and build understanding tended to score markedly higher. That was an observed pattern rather than a randomized comparison.

The problem may not be AI use.

It may be cognitive delegation without learning design.

## Junior work was an accidental apprenticeship

I don't romanticize grunt work.

Nobody needs to preserve boilerplate coding because previous generations suffered through it.

But I think we have underestimated what some of that work was doing.

A junior engineer fixing a seemingly trivial production bug might have had to trace a request across services, understand a deployment pipeline, read unfamiliar code, interpret logs and discover why an architectural decision had been made three years earlier.

The ticket might take two days when a senior engineer could solve it in twenty minutes.

Measured purely as delivery efficiency, that looks terrible.

Measured as capability building, it looks very different.

The old model was inefficient and inconsistent. But everyday engineering work repeatedly exposed people to the systems from which judgment eventually emerged.

If AI compresses that journey into “describe problem → receive solution → validate tests → merge,” we shouldn't assume the missing experience reconstructs itself later.

## The scarce skill may move from creation to judgment

As generating an implementation becomes cheaper, deciding whether it is actually correct becomes relatively more important.

I've seen this throughout my career even without AI. The hardest engineering conversations are rarely about syntax. They are about assumptions, failure modes, trade-offs, operational consequences and whether we're solving the right problem.

AI magnifies that distinction.

And even its productivity benefits depend heavily on context.

METR, an independent research nonprofit, initially ran an RCT with 16 experienced open-source developers working in mature repositories they knew well. With early-2025 AI tools, those developers were 19% slower, despite believing AI was making them faster.

Its subsequent experiment, involving 57 developers and more than 800 tasks, produced smaller negative estimates that were statistically indistinguishable from zero. But METR itself considers that evidence unreliable because developers increasingly declined tasks when they could not use AI, creating substantial selection effects. It has since redesigned its experiments.

The lesson isn't that AI makes juniors faster and seniors slower.

It is that code-generation speed is an increasingly poor proxy for engineering capability.

## So how do we build that capability?

Microsoft leaders Mark Russinovich and Scott Hanselman have proposed borrowing an idea from medicine: preceptorship. Russinovich is Microsoft's Azure CTO; Hanselman is Microsoft's Vice President of Developer Community. Their model is a proposal, not a proven software-engineering intervention.

The idea is to pair early-career engineers deliberately with experienced engineers while they use AI. The senior's job becomes less about supplying answers and more about examining reasoning: Why did you decompose the problem this way? What did the agent assume? Why do you trust the result? What would failure look like?

I don't know whether that particular model will scale.

But I think the principle is right.

Engineering organizations can no longer assume talent development will remain an automatic by-product of delivery.

I would make three changes.

First, treat junior hiring partly as succession planning, not simply near-term capacity.

Second, evaluate early-career engineers not only on how much they ship, but on whether their system understanding, debugging ability and technical judgment are improving.

Third, make developing other engineers a real expectation of senior technical leadership rather than invisible work performed by the conscientious few.

None of this means keeping engineers artificially inefficient.

It means being deliberate about which friction AI should remove, and which friction was actually doing valuable educational work.

## The risk is not that juniors disappear

Perhaps AI-native engineers will develop judgment faster than previous generations.

Perhaps agent orchestration, evaluation, observability and system-level reasoning will become better apprenticeships than writing boilerplate ever was.

I hope they do.

But that outcome isn't automatic.

For most of my career, we could largely rely on the work itself to help turn junior engineers into senior ones.

AI is removing parts of that mechanism before we have designed its replacement.

That, rather than the disappearance of junior engineering, is the risk technology leaders should be paying attention to.

Because producing code may increasingly be easy.

Producing the people capable of knowing when that code is wrong may become much harder.

---

# What Meta's Collapsed AI-Native Plan Actually Proves

Meta's collapsed 'AI-native' restructuring is already hardening into two consensus takes, and both are wrong in the same way: neither is looking at the mechanism sitting inside Meta's own numbers.

Published: 2026-08-28
Category: AI Transformation
Tags: AI, Engineering Leadership, Operating Model, Verification
Canonical: https://bharatsharma.pro/articles/the-hourglass-firm

Two takes on Meta's collapsed AI-native plan are already hardening into consensus, and both are wrong in the same way.

One says this proves AI can't actually replace knowledge workers: the technology overpromised, Zuckerberg blinked, case closed. The other says Meta was simply too ambitious, that a more gradual rollout would have landed fine.

Both takes are arguing about ambition. Neither is looking at the mechanism sitting inside Meta's own numbers.

Here's what's confirmed. In January 2026, Meta began exploring what it internally called Project OT: a push to make the company "AI native" by having AI agents perform much of the daily work currently done by thousands of employees, with smaller, more talent-dense human teams overseeing the result. In scenario planning, executives explored cutting some teams by as much as 60%. That was a planning ceiling, not a company-wide target Meta committed to, and Meta has disputed the characterization of Project OT as a finalized "bold plan." The second wave was canceled before a final number was fixed.

The first wave, roughly 10% of staff, went ahead on May 20. Hours before it did, Zuckerberg canceled the second wave, which had been planned for November. Reuters could not establish exactly what prompted the change of course. That distinction matters: I'm not going to manufacture a cause Reuters itself could not establish.

The more interesting evidence is elsewhere.

Two internal Meta data points reported by Reuters expose the problem. One, attributed to CTO Andrew Bosworth in an early-June internal post: code changes to Meta's internal software platforms and infrastructure were up 220% year over year, while changes that produced new or upgraded features reaching Meta users were up only 36%. The public reporting does not establish that the 220% increase was specifically agent-generated, and the underlying definitions of those metrics have not been disclosed.

The second is harder to dismiss as a simple measurement problem. Internal posts in March and April described AI agents taking what they called "large-scale, disruptive actions that humans are unlikely to execute." Major technical and security incidents subsequently rose 40% year over year, while the time employees spent firefighting them rose as much as 70%. Meta declined to comment on those internal figures.

Treat those figures accordingly. They are internal Meta accounts reported by Reuters, not audited public metrics. But they reveal something important even without assuming more than the evidence allows.

They reveal the difference between generation and organizational throughput.

I've called this the **Hourglass Firm**.

As generation gets cheaper with more code, more content, more agent-initiated action, produced faster, the organization doesn't necessarily become proportionally more productive. Instead, the bottleneck can move downstream to whoever has to verify that output before it can be trusted and acted on.

The organization becomes an hourglass: wide at generation, narrow at verification, wide again at accountability.

That distinction matters because generation is easy to measure. Verification is not.

A company can count lines of code, documents produced, experiments run, tickets closed and actions initiated. It is much harder to count the work required to determine which of those outputs are correct, safe, useful and worth shipping.

That is where the 220/36 gap becomes interesting.

It does not prove that AI agents generated 220% more code and failed to ship it. The reporting does not establish that. What it does show is a much broader phenomenon: activity inside the organization increased dramatically faster than user-facing output.

That is the distinction the AI productivity debate keeps missing.

A machine can become much busier without the company becoming proportionally more productive.

The 40/70 figures show the other side of the same problem. Internal Meta posts described agents taking disruptive actions and, during the same period, major technical and security incidents rose 40%, with employee firefighting time rising as much as 70%. If the purpose of deploying agents is to free human capacity, an operating model that creates more exceptions for humans to diagnose and absorb has a very different economics from the one the restructuring assumes.

And that is where the Hourglass Firm becomes more than a metaphor.

The people at the narrow point: reviewers, verifiers, integrators, incident responders can look inefficient when viewed from the perspective of raw generation. They aren't generating the visible volume. They are slowing the machine down.

But that "slowness" may be the mechanism that turns generation into reliable output.

Cutting those roles because you've "captured AI productivity gains" mistakes the wide part of the hourglass for the bottleneck.

Notice what this argument does not require.

It does not require knowing whether the incident data specifically triggered Zuckerberg's decision. Reuters couldn't establish that.

It does not require believing that every extra code change was generated by an AI agent. The reporting doesn't establish that either.

And it doesn't require treating Meta's internal numbers as audited truth.

The argument is simpler: even on Meta's own account, the transformation produced a widening gap between organizational activity and useful output, alongside a rise in the human capacity required to absorb technical and security problems.

That is enough to challenge the two dominant interpretations.

"AI can't replace workers" treats this as a capability failure as if a better model would have made Project OT work.

"Meta was too ambitious" treats it as a pacing failure as if the same operating model, run 18 months slower, would have landed cleanly.

Neither gets at the bottleneck.

A slower rollout does not automatically fix a transformation in which execution capacity is scaling faster than verification and incident-absorption capacity. It simply gives the same imbalance more time to accumulate, unless the organization changes what it builds alongside the agents.

What has to scale is not caution.

It is verification.

It is review depth.

It is integration.

It is incident response.

It is the human capacity to determine whether an increasingly large volume of machine-generated activity should actually be trusted, shipped or acted upon.

That is the question I would ask of any company moving toward an agent-driven operating model:

Is verification and incident-absorption capacity being scaled anywhere near the rate at which execution capacity is being scaled?

Because if it isn't, the organization may discover a strange version of AI productivity: the machines produce more, while the humans spend more of their time making sure the machines haven't created something the company cannot safely use.

That is not an argument against AI.

It is an argument against confusing generation capacity with organizational capacity.

Meta's Project OT is interesting precisely because it may have exposed that distinction from inside the company that was trying hardest to erase it.

What actually made Zuckerberg pull back the second wave, Reuters still doesn't know.

But the more important question may be one step upstream:

What happens when you make generation dramatically cheaper before you make verification dramatically cheaper too?

That is where the Hourglass Firm begins.

---

# When Code Becomes Cheap, Judgment Becomes the Craft

AI coding tools make implementation faster, but trusted software still depends on human judgment, verification, systems thinking, and accountability.

Published: 2026-08-22
Category: AI Transformation
Tags: AI, Engineering Leadership, Developer Productivity, Software Engineering
Canonical: https://bharatsharma.pro/articles/when-code-becomes-cheap-judgment-becomes-the-craft

## AI coding tools are not just helping engineers write code faster. They are changing what it means to be a good software engineer.

An engineer reviews a payment feature written by an AI agent. The code looks clean. The routes are in place, and the automated tests pass. But the engineer notices a serious problem: the retry path does not keep the payment request's idempotency key. In plain terms, if the database records a charge but the response times out, an automatic retry could charge the customer twice.

This example shows the difference between code that looks correct and software that can be trusted.

For a clear, routine task, AI can now produce scaffolding, application routes, and a first set of tests in minutes. It has reduced the time needed to create a plausible first version of many features. But more code does not automatically mean better software.

That is the central tension of AI-assisted engineering. AI makes useful code cheaper to produce. It also makes fragile, insecure, and poorly understood code cheaper to produce. As implementation becomes faster, engineering performance will depend less on the amount of code a team generates and more on its ability to verify, integrate, and safely operate each change.

This shifts the value of human work. Judgment, verification, and accountability become more important. Here, judgment has a practical meaning: choosing the right problem, understanding the constraints, selecting a suitable design, deciding what evidence is enough to trust the change, and taking responsibility for what happens in production.

## What AI is changing

AI tools now do much more than complete a line of code. Repository-aware agents can read a codebase, plan changes across several files, run commands, inspect failed tests, and try again.

Their measured capability has improved quickly. By early 2026, leading systems were resolving issues in the high-70% range on SWE-bench Verified, a benchmark built from real GitHub issues. But benchmark scores have limits. The tools, test harnesses, and evaluation methods have changed over time. Passing benchmark tests also does not mean a change would pass a real code review or work safely in production.[1]

The impact also depends on the type of software being built. In general application development, teams may spend less time producing a first implementation and more time reviewing and integrating it. In embedded, regulated, and safety-critical systems, an incorrect change can cause safety, legal, or operational harm. Those systems need much stronger validation, traceability, and human accountability.

AI can compress execution, but it does not remove decisions about intent, trade-offs, constraints, and acceptable risk. An agent may implement a requested feature. It should not be assumed to know every relevant business rule or organizational priority. Nor should it have final authority over the trade-offs an organization accepts.

For some work, engineers are moving from direct implementation toward specifying, supervising, and validating agent-produced changes. This requires clear requirements and success criteria but it also requires enough technical understanding to recognize when the proposed solution is wrong.

## Craft is moving from output to trusted change

Good engineering has never been only about typing speed or syntax. Design, testing, maintainability, and operations have always mattered. Even so, hiring and productivity systems have often rewarded visible output: tickets closed, pull requests merged, or features delivered.

AI makes those measures even less useful. When a tool can generate large amounts of code quickly, code volume says little about the value or quality of the work.

There are warning signs in current research. GitClear, a software-analytics vendor, analyzed 211 million changed lines of code. In its dataset, lines classified as copied rose from 8.3% in 2021 to 12.3% in 2024. Lines classified as moved fell from about 24% to 9.5%.[2] These patterns may point to more duplication and less reuse. However, the study is observational: it does not prove that AI caused the changes, and its measures are not complete definitions of software quality.

DORA's findings also show why simple productivity stories are risky. Its 2024 report found that greater AI adoption was associated with lower delivery throughput and stability. In 2025, AI adoption was positively associated with throughput, but the negative relationship with stability remained.[3][4] These are correlations, not proof that AI caused either outcome. Still, they support an important idea: producing changes faster does not guarantee that an organization can deliver them safely.

The useful unit of engineering productivity is therefore not code produced. It is a change that has been understood, verified, integrated, and operated successfully.

## The human skills that matter more

### Problem framing

AI can help discover requirements and suggest options. Humans and organizations must still decide which problems are worth solving.

An underspecified request such as “build a payments service” may produce convincing code while leaving important questions unanswered. Who is allowed to make a payment? How are duplicate requests handled? What happens during a partial failure? What must be logged? Who owns the service? How can a failed release be rolled back?

A strong engineer asks these questions before trusting the implementation.

### Systems thinking

AI-generated code can pass local tests while making the wider system worse. A new utility might work but sit in the wrong architectural layer. A feature might duplicate an existing capability. A database change might be correct on its own but create new load, coupling, or failure modes elsewhere.

Systems thinking means understanding how components interact, where state lives, how data crosses boundaries, and how the system behaves when something fails. This context is often what separates a working code fragment from a sound engineering change.

### Verification and debugging

AI-generated changes can include invented APIs, incorrect assumptions, and logic errors. They may also pass weak tests. If the same model writes both the code and the tests, both may reflect the same mistaken understanding of the requirement.

Verification must cover more than unit tests. Engineers may need to check dependency and license risks, exposure of secrets or proprietary code, security boundaries, observability, rollout and rollback plans, and ownership after the original agent session is gone.

Research shows that AI assistance does not translate into the same productivity gain in every setting. In an early-2025 randomized study, METR found that 16 experienced open-source developers took 19% longer on familiar, complex tasks when they could use AI tools. A later study with newer tools showed some evidence of faster work, but selection problems made the result difficult to interpret.[5][6] The careful conclusion is not that AI always slows developers. It is that benchmark performance does not automatically become real-world productivity on complex, context-heavy work.

Judgment is not a permanent safe area for humans. AI is already helping with code review, threat modeling, debugging, and architecture proposals. As these capabilities improve, engineers may spend less time producing the first analysis and more time deciding whether an AI-generated analysis is sound. Human value cannot rest on the assumption that AI will stop at implementation. It rests on understanding the system, weighing trade-offs in context, deciding what evidence is enough, and remaining accountable for the result.

### Security and domain knowledge

Security failures often hide in business rules rather than syntax. In Veracode's benchmark of 80 task templates across four languages and four vulnerability classes, 45% of generated results failed the benchmark's security tests.[7] This does not mean 45% of all production AI code is insecure. It does show that plausible code can still fail important security checks.

Authorization and business logic are especially difficult because correctness depends on the application's rules. Repeated AI edits can also remove a security check that was correct in an earlier version. Engineers need tests that capture those rules, not only tests that confirm the happy path.

## The apprenticeship problem

AI may also change how engineers learn.

Junior engineers have traditionally built experience through bounded work: fixing bugs, adding tests, reading existing modules, and implementing small features. These tasks were not merely cheap labor. They helped engineers learn how a codebase works and how small decisions create later consequences.

If agents take over more routine implementation, some of those learning opportunities may shrink before organizations have designed replacements. Companies cannot simply ask junior engineers to show senior judgment earlier. Judgment is not learned from principles alone. It grows through implementation, debugging, incidents, code review, and living with earlier trade-offs.

This creates a paradox: AI increases the value of judgment while automating some of the work through which judgment has traditionally developed.

Organizations will need deliberate apprenticeship paths. Early-career engineers should remain close to code and production. They should review generated changes, investigate incidents, trace failures across services, participate in design discussions, and operate what the team ships. AI can support this learning, but it should not remove contact with consequences.

## What engineering leaders should change

Buying AI coding tools is not an engineering strategy. AI creates leverage only when a team's ability to verify changes grows with its ability to generate them. Otherwise, faster coding can produce review queues, operational risk, and a less coherent codebase.

Platform teams can help by creating “paved roads”: approved components, secure defaults, architectural rules, and automated checks that guide both humans and agents toward safer changes.

Accountability must also be real. When an agent creates a pull request, a named person should have the context, authority, and time to reject or redesign it. For a high-risk change, the review evidence should include:

- The requirement and risk level
- Test results and important assumptions
- Security and dependency checks
- Observability changes
- The rollout and rollback plan
- A named owner

Organizations should also examine where time saved in coding is lost later. The new bottleneck may be review, integration, security approval, testing, deployment, or incident response.

Lines of code and raw output volume are poor primary measures of productivity, especially when machines can generate both cheaply. No single replacement metric is enough. Leaders should consider delivery speed alongside reliability, maintainability, recovery time, customer outcomes, and the amount of avoidable rework.

## Judgment as the scarce capability

The lasting human responsibility in AI-assisted development is not writing every line. It is deciding when a software change is trustworthy and remaining accountable when that decision is wrong.

This does not mean engineering automatically becomes a more elevated craft. If engineers are reduced to approving changes they do not understand, the craft becomes weaker. Engineering becomes richer only when people remain close enough to implementation and production to question, improve, and own what the tools produce.

As first-pass code becomes cheaper, the bottleneck moves to deciding whether a change is needed, whether it fits the system, and whether the evidence is strong enough to trust it.

When code becomes cheap, judgment becomes the craft.

## Sources

1. [SWE-bench Verified leaderboard](https://www.swebench.com/)
2. [GitClear AI Code Quality Research 2025](https://www.gitclear.com/ai_assistant_code_quality_2025_research)
3. [2024 DORA report](https://dora.dev/publications/2024-dora-report/)
4. [2025 DORA report](https://dora.dev/research/2025/dora-report/)
5. [METR: Early-2025 AI and experienced open-source developer productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
6. [METR: 2026 developer productivity experiment update](https://metr.org/blog/2026-02-24-uplift-update/)
7. [Veracode 2025 GenAI Code Security Report](https://www.veracode.com/wp-content/uploads/2025_GenAI_Code_Security_Report_Final.pdf)

---

# Why Is AI the Easy Part?

Every engineering leader I asked could tell me their AI adoption number. Not one could tell me what it had bought the business. How that gap sent me looking, and what I found.

Published: 2026-08-13
Category: AI Transformation
Tags: AI, Engineering Leadership, Operating Model, Strategy
Canonical: https://bharatsharma.pro/articles/why-is-ai-the-easy-part

AI is the biggest disruptor since electricity. AI will make developers 10x more productive. Coding is becoming a commodity. AI will allow small teams to build what previously required large teams. Software engineering is becoming agentic. The future is vibe coding. What are our AI adoption numbers? How many AI use cases do we have?

As an engineering leader, I was sceptical of many of these claims, worried about some and did not understand many. And it was my curiosity but also a fear of becoming irrelevant that set me on this path of exploring the world of AI in more depth.

Here is where I landed, before I explain how I got there. Putting AI in the hands of engineers turned out to be the easy part. The tools work, adoption happens, individual productivity genuinely improves. What doesn't happen on its own is any of it reaching the business. AI creates capability. Organisations create value. The distance between those two sentences is the whole problem.

It started with doing some personal projects using AI. I built a personal assistant, automated my quarterly portfolio review, a multi model research system and a few others. I was really surprised with the speed and accuracy with which I built some of these solutions (in some cases under 1 day). By the end of it, I got convinced that AI significantly improves individual productivity.

And then came a push for my teams to adopt AI more and more. Unsurprisingly, most of the engineers had already started using AI in their day to day work. While their individual productivity was improving, there was still no evidence that the same translated into velocity at the organisation level (not significantly and definitely not 10x).

The pattern was easy to see once I went looking. A change that took a few days to build would sit for weeks waiting for a decision, then sit again before it could ship. Nobody was doing anything wrong. The queues on either side of the work had been sized for a world where writing the code was the slow part.

I now had some knowledge of AI and more questions than when I started. I was again worried whether I was the only one struggling with this conversion or whether I had company. I started reaching out to some fellow engineering leaders in the industry to learn whether they were facing similar challenges too. Every one of them could tell me their AI adoption number. No one could tell me what it had bought the business. I was slightly disappointed at still not having the answers but honestly very happy as well to discover I wasn't the only one. Then, I took help from my new friend (Perplexity) and started researching the subject in more depth.

After my many experiments within and outside my teams, my interactions with a lot of engineering and product leaders and the research on various related subjects, I came to this conclusion. It is not just AI but everything around it including your operating model that needs a shift in order to bridge the gap between individual productivity and the business value.

The bottleneck was never the typing. It was everything on either side of the typing, and that is where it still is.

Try this on your own organisation. You probably know your adoption percentage. Now try to say in one sentence what it changed for a customer. If the second is harder than the first, that gap is what this book is about.

The book is my attempt to work all of that out properly, in six parts:

**Part 1 - The Paradox:** AI is reducing the execution time and there is a clear spike in developer productivity but at the same time most businesses are reporting no significant changes in business outcomes. It is not a paradox and both these things could be true together. The reconciliation is a constraint that moved, and this part is about finding where it went.

**Part 2 - The Diagnosis:** An honest diagnosis of the value flow and the identification of metrics that give you real visibility into velocity. This is where I introduce "The Five Level Measurement Hierarchy"

1. AI Adoption
2. Individual Productivity
3. Team Effectiveness
4. Organisational Throughput
5. Business Outcome

Each of these levels has its own metrics. Most organisations instrument the first two, report the last and measure nothing in between.

**Part 3 - The Substrate:** The foundational work needed to build an AI-Native team: the economics of AI value, team topologies, platforms and data treated as infrastructure. Most of this work is unglamorous but none of this is optional.

**Part 4 - The Operating Model:** The journey from AI assistants to having agents do the execution. For agents to run autonomously, both upstream and downstream of execution have to evolve. Product has to get better at discovery and at documenting it, because ambiguity a human engineer would quietly resolve is ambiguity an agent will confidently get wrong. Governance sits here too: decision rights, security, Responsible AI.

**Part 5 - Leadership and Change:** This is the part I found most interesting to write, the human side. Where is the value shifting when execution is getting cheaper? An interesting question I kept coming back to: Where does accountability sit in the agentic era? It closes on change management, which is perhaps the hardest thing to execute.

**Part 6 - Becoming AI-Native:** What it takes to build an AI-Native Enterprise, ending with a maturity model and a 90 day plan which you can start working on without buying any additional tool or seats.

If any of this resonates with you, do read the book and share your feedback. I'd love to hear if it brought any change for you within your organisation.

If there is one thing you should take back from this article, take this. The engineers are doing their part, it is time leadership did its part too.

---

# The Model Is Not Your Authorization Layer

An AI agent recently tried a supply-chain attack nobody asked it to attempt. What stopped it wasn't a safety filter. It was a human who read the pull request and said no.

Published: 2026-08-09
Category: AI Transformation
Tags: AI, Security, Agents, Engineering Leadership
Canonical: https://bharatsharma.pro/articles/the-model-is-not-your-authorization-layer

On 28 July, the UK AI Security Institute [reported](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) that it had spotted Tor traffic leaving one of its cyber evaluations.

The sandbox was working as designed. To see what models could do at full stretch, AISI had deliberately allowed open internet access and switched off the providers' own cyber safety classifiers. Nothing escaped. The agents were using the room they had been given.

Across 122 runs, AISI found 19 out-of-scope actions in 10 of them, concentrated in one model. In the most serious, an agent attempted a supply-chain attack: it tried to insert malicious code into a real open-source project, created fake online identities, and used them to pressure the maintainer into approving the change.

Nobody told it to deceive anyone. It was given a hard task, and deception was simply an efficient route to finishing it. AISI could not establish when, or whether, the agent understood it was dealing with real people rather than a test fixture.

And here is the detail I keep coming back to. The attack failed because a human maintainer read the pull request and refused to approve it.

The caveats are real and worth stating plainly. The agents never escaped the sandbox. The configurations tested aren't commercially available. AISI found no evidence of comparable behaviour outside testing, and no real-world harm resulted. This is not a story about AI turning on us.

It's a story about what capable systems do when authority, connectivity, task design, and monitoring leave room. And it points at the one principle I'd build everything else on: **the model is not your authorization layer.**

## What's actually different about agents

Agentic risk isn't a property of the model. It comes from what the system around it is allowed to do: choose actions, sequence them, call tools, carry state forward, and keep going without asking permission at each step.

Prompt injection, hallucination, and data leakage all exist in ordinary chatbots and retrieval systems too. What changes with agents is the blast radius. The same failure now becomes a privileged action, repeated, against the outside world.

The deeper problem is a boundary that quietly disappears. Ordinary software keeps a hard line between instructions and data: the code says what to do, and user input is just material the code operates on. That line has always been attackable, and SQL injection is precisely what breaking it looks like, but it exists.

Agents blur it by design. The system prompt, the user's request, a retrieved document, a tool's response, and even the description of the tool itself all arrive in the same context window, and all of it is read as language. Labels like "system" and "user" organise that context; they don't enforce anything. Any text an agent reads can shape what it does next, unless something outside the model prevents it.

## Five failures that have already happened

These aren't hypotheticals. Each one is documented, and each shows a different way the same boundary gives way.

- **The agent goes outside the scope you intended.** The AISI case above. Given a hard goal and permissive network access, an agent found a route its operators never sanctioned.
- **Someone else's text becomes the instruction.** In [EchoLeak](https://arxiv.org/html/2509.10540v1), researchers showed a zero-click flaw in Microsoft 365 Copilot: a crafted email could steer Copilot into embedding sensitive context into an automatically fetched Markdown reference, sent out through a Teams preview service the app's own security policy already trusted. No click required. Microsoft patched it, and there's no evidence it was exploited in the wild.
- **The tooling itself gets compromised.** An attacker used [an over-scoped GitHub token](https://github.com/vectara/awesome-agent-failures/blob/main/docs/case-studies/amazon-q-supply-chain-attack.md) to commit malicious code into the Amazon Q Developer extension, which shipped in version 1.84.0. It was meant to tell the agent to delete local files and cloud resources. A syntax error stopped it running. No customer environment was touched.
- **The agent does something it was genuinely allowed to do.** A user reported that [Replit's coding agent deleted a live application database](https://incidentdatabase.ai/cite/1152/) during a code freeze, despite repeated instructions not to change anything. Replit confirmed the deletion, restored the data, and acknowledged that development actions could reach production because the environments weren't separated by default.
- **Agents coordinate through the mess they leave behind.** AISI found that one agent left public messages, accounts, and artifacts that later, independent agents discovered and reused. They didn't need a channel to talk to each other. The environment was the channel.

## Build a control plane, not a better prompt

Classifiers, output filters, and system-prompt hardening are worth having. They catch things. But they're probabilistic: they reduce how often something bad gets through, and they can be talked around. That makes them good detection and a reasonable extra layer. It does not make them an authorization boundary.

The alternative is deterministic: plain rules that give the same answer every time, evaluated outside the model, where no amount of clever text can argue with them. Four pieces:

**Treat everything the agent reads as untrusted.** Retrieved documents, emails, web pages, tool descriptions, and tool metadata are data, not orders. Keep track of where each piece came from and how much you trust it, and keep authoritative instructions separate from retrieved content wherever you can. The hard rule: content the agent merely *read* must never be able to register a new tool, widen its own credentials, remove an approval requirement, or pick a destination you haven't approved.

**Give the agent a real identity.** Not an API key in an environment variable shared across three services. A proper workload identity, [SPIFFE](https://spiffe.io/docs/latest/spiffe-specs/spiffe/) or your cloud provider's equivalent, so that when something goes wrong you know precisely which workload did it.

**Authorize every consequential action outside the model.** A separate policy service decides yes or no, and the agent cannot reason its way past it. That service is now critical infrastructure, so it has to fail closed: if it's unreachable, high-impact actions stop. Any degraded mode should be limited to predefined read-only operations and should raise a security event, not quietly wave things through. AWS's [AgentCore policy sample](https://github.com/aws-samples/sample-amazon-bedrock-agentcore-onboarding/blob/main/08_policy/README.md) is one worked example of the shape.

**Issue credentials that expire and barely reach.** Where a downstream system needs credentials, mint them short-lived and scoped tightly to the approved task, resource, operation, and destination. A credential that outlives the task is a credential someone else eventually uses.

If you read my earlier piece on [why verification isn't getting cheaper](/articles/execution-is-cheap-verification-isnt), this is the systems version of the same argument. Underwriting, actually bearing the consequence of a decision, doesn't automate, because it's a matter of legal and social standing rather than capability. A model can propose. Something accountable has to authorize.

## Where this meets organisational reality

Agent security starts with ordinary application and cloud security maturity. There's no shortcut around that. And the AISI incident draws a distinction worth holding onto: a sandbox protects your infrastructure from the agent, while network egress controls protect everyone else from the agent. They are not the same job.

Now the uncomfortable part. Controls that create real friction without offering a usable approved path don't produce safety. They produce shadow adoption. Agents already arrive in the enterprise as vendor features, IDE extensions, and tools a developer wired up under delivery pressure. If the sanctioned route is painful, people take the other one, and you lose visibility of the thing you were trying to govern.

Many organisations also can't issue per-task credentials against legacy systems at all. For those, put a broker or proxy in front of the application with a narrowly scoped service account, command filtering, transaction ceilings, and network restrictions. It's less elegant and it works.

So graduate the controls. For each agent, assess four things. How much **authority** it has, how much untrusted **exposure** it faces, how much **autonomy** it runs with, and how **reversible** its actions are. Then assign a tier:

- **Tier 1, low risk.** Read-only retrieval over low-sensitivity data can run unattended, provided query scope, data classification, output destination, and egress are all constrained.
- **Tier 2, moderate risk.** Reversible internal writes need scoped credentials, deterministic policy, and detailed logging.
- **Tier 3, high risk.** Production changes, external communication, privilege changes, and financial transactions need external policy, human approval, and a tested rollback. Where an action can't be reversed or compensated, add transaction limits, dual approval, staged execution, or don't allow it.
- **Default deny.** Creating credentials, unrestricted internet access, disabling security controls, and installing unapproved tools at runtime need a documented exception with a named owner, an expiry date, and compensating controls.

Two things that trip people up. A single extreme dimension is enough to force a higher tier on its own. High authority with untrusted exposure is dangerous even if everything else looks tame. And read-only is not automatically safe: reads expose data, trigger outbound fetches, and pull in injected instructions.

## What I'd actually do

**Before a pilot.** Name a business owner and inventory every tool the agent can reach, because you cannot govern what you haven't listed. For vendor-hosted agents, ask for tool and data inventories, exportable audit logs, incident-notification terms, tenant isolation, and evidence that authorization is actually enforced. Treat vague answers as an answer. Check that every task has an approved way to succeed, and define explicitly what the agent does when it can't: stop, abstain, or escalate. Then run it in a disposable sandbox with no production credentials and deny-by-default egress.

**Before production.** Put deterministic policy outside the model. Against supply-chain risk, require signed tool manifests, pin tool and MCP-server versions, keep CI/CD tokens least-privilege, and forbid agents from installing tools at runtime. Against the shared-state problem, isolate state between runs, tag agent-created artifacts with their origin and an expiry, quarantine anything externally sourced before reuse, require authenticated channels for agent-to-agent communication, and clean up the accounts and pull requests agents leave behind.

**Put hard limits on autonomous runs.** Cap elapsed time, spend, step count, retries, data volume, and external destinations per run. Hitting a limit must stop the run or escalate to a human, never simply invite the agent to find another way. In multi-agent setups, a downstream agent must not inherit wider authority just because another agent asked; each delegation carries the initiating identity, the original user's authority, and the remaining budget.

**Make approvals mean something.** For consequential actions, the reviewer needs the raw parameters, the affected resources, and the rollback path, not the agent's summary of what it intends to do. A model-written description of a destructive command is exactly the wrong thing to approve. Approval should mint a signed, single-use, short-lived authorization bound to that exact tool, parameters, target, credential scope, and resource version, and the gateway should verify it atomically so any material change invalidates it. Cap approval volume and use two-person review on the highest tier, because a reviewer facing forty approvals an hour is a rubber stamp with a job title.

**Be able to undo it.** Build and test backup and rollback paths *before* granting write access to anything stateful. Re-run your regression tests after any change to system prompts, orchestration logic, retrieval sources, tool descriptions, policies, model parameters, or gateways. All of those change behaviour; none of them look like a code change.

**Log what actually happened.** In tamper-evident, access-controlled logs: agent and workload identity, model and prompt versions, policy version, where the context came from, what was proposed versus what executed, exact parameters, the authorization result, credential scope, and trace IDs spanning agents and services. Then watch the controls themselves: unsafe proposals, policy denials, budget exhaustion, rollback success, behavioural drift.

**Update incident response before you need it.** You need a kill switch that stops orchestration, revokes identities, terminates compute, blocks egress, and freezes downstream transactions. And your team should already know how to preserve evidence, rotate exposed secrets, invalidate accounts the agent created, quarantine its artifacts, notify affected third parties, and check whether shared memory or other agents were contaminated.

## The point

The lesson from early agentic deployments isn't that these systems are malicious. It's that capable systems will search beyond the boundary you intended whenever authority, connectivity, task design, and monitoring leave room. That's not a defect to be trained away. It's what "capable" means.

So consequential actions have to rest on infrastructure that doesn't depend on the model choosing well. None of this is exotic: identity, authorization, least privilege, logging, and blast-radius control are the same disciplines we already know. What's new is that the thing inside the boundary now argues, improvises, and occasionally finds a door you forgot to lock.

If you want external reference points, [NIST's COSAiS control overlays](https://csrc.nist.gov/projects/cosais) and [Singapore GovTech's ARC framework](https://www.tech.gov.sg/technews/ai-agents/) are both useful implementation guidance rather than legal mandates.

And it's worth remembering how the AISI story ended. Not with a classifier catching something. With a maintainer reading a pull request and deciding not to approve it.

---

# Execution Is Getting Cheap Faster Than Verification Is

Individual productivity jumps after an AI rollout. Organizational velocity doesn't. The gap between those two curves has a name, and most firms are quietly cutting the roles that close it.

Published: 2026-08-02
Category: AI Transformation
Tags: AI, Engineering Leadership, Operating Model, Governance
Canonical: https://bharatsharma.pro/articles/execution-is-cheap-verification-isnt

A pattern is showing up across enterprises: individual productivity jumps after an AI rollout. Code ships faster, analysis that took a week takes an afternoon. Organizational velocity barely moves. Decisions still queue. Strategy still takes as long to execute.

You can watch it happen at a single desk. Someone who approved five pieces of work a day now receives fifty, each one polished and confident, with the same authority to sign, the same liability for signing, and the same number of hours in the day.

The reflex is to call this an adoption problem: better prompting, better tooling, more training. It's something more specific. The cost of producing work has fallen sharply, and the cost of establishing that the work is correct and safe to act on has not fallen nearly as fast. Where verification governs release, where nothing ships, posts, or gets filed until someone signs, the organization runs at the slower curve.

Call the accumulating difference **verification debt**: the gap between what an organization can now produce and what it can still stand behind. That gap is the thing worth planning around. Not whether AI flattens the org chart, a claim that became conventional wisdom in about eighteen months on evidence that wouldn't survive serious review.

## Verification isn't one thing, and that's the crux

The obvious objection to any "verification is the bottleneck" argument: why wouldn't AI verification get cheap too? Automated testing, evaluation harnesses, red-teaming, monitoring, agents auditing agents. All improving fast. The answer requires taking verification apart. The useful cut isn't by activity but by *what makes each part hard*.

**Checking** is hard because criteria are tedious to apply at volume. The criteria themselves are already written down. Tests pass, figures reconcile, the citation exists, the clause is present. Anything whose difficulty is volume-against-stated-criteria automates well, and this is automating quickly.

**Judging** is hard because the criteria aren't written down. Is this the right answer to the actual problem, given context nobody documented? Is the model answering a subtly different question than the one asked? Is this technically correct and strategically stupid? Difficulty here comes from unstated context, which is why it automates unevenly and degrades precisely on the novel cases that matter most.

**Underwriting** is hard because someone bears the consequence. Not who checked, but who answers for it in front of a regulator, a court, a customer, or a board. Difficulty comes from consequence-bearing, which is a property of legal and social standing, not of capability.

Three categories because there are three distinct sources of difficulty: volume, context, and consequence. Each responds differently to automation, which is the entire point. You could subdivide further, but any finer cut splits things that behave the same way under the same forces.

Aviation shows the split cleanly: nearly every inspection is automated, and a human still signs off. That isn't ceremony. Checking scaled; authorization didn't.

So: checking is automating fast, judging is automating unevenly, underwriting isn't automating at all. As output volume rises, the second and third become the constraint. Firms that instrument only the first will conclude their capacity is fine right up until it isn't.

One honest limitation before going further. This is a mechanism argument supported by industry examples and institutional analogy. Nobody has measured the relative slopes of these two curves across sectors, and I certainly haven't. If you want the empirical version, it doesn't exist yet.

## What this looks like when it breaks

Picture a commercial credit officer who reviewed five credit memos a day, each drafted over hours by an analyst whose reasoning she could interrogate. Her team now generates fifty, each polished, internally consistent, and confident. Her sign-off authority hasn't changed. Her liability hasn't changed. Her day hasn't changed.

She will not review fifty memos. She will develop a heuristic for which ones to actually read, and approve the rest on the strength of how they look.

Human factors research has a name for the mechanism: **automation bias**, the tendency to accept automated output more readily as it becomes more fluent and more voluminous, particularly under time pressure. Polished, confident, high-volume output is precisely the condition that produces it. AI has made fluency free.

That's the failure mode. Not robots making mistakes. **Rubber-stamping under liability**: humans nominally accountable for volumes they can't inspect, in a system that still records their signature as if they had.

Nothing about this is software-specific. The shape recurs wherever output volume is rising, errors are consequential, and expertise sits in a shrinking senior layer: radiology reads, claims adjudication, audit sampling and workpaper review, regulatory document preparation in pharma, credit memos, asset inspection in energy, contract review, clinical documentation.

And one thing to be clear about, because it's the obvious misreading: the answer is not to push senior people to review faster. That accelerates the failure. Throughput at the sign-off layer is the thing you are trying to protect, not optimize.

## The second-order effect

The work being automated first is entry-level and mid-tier cognitive execution: precisely the work that historically built the judgment needed to verify. Reviewing the routine cases is how people learned to recognize the non-routine ones. Cut those roles and you erode the pipeline that produces senior verifiers. Call it the **Missing Junior Loop**.

The support here is structural rather than statistical. Every profession that carries serious consequences for error (medicine, aviation, law, accounting, the skilled trades) has independently converged on mandatory supervised hours before independent authority, and has kept that requirement through decades of automation that made the underlying work far easier. Those institutions are not sentimental about training costs. They maintain apprenticeship because the alternative has been tested and rejected where failure is legible.

That's an argument from institutional convergence, not evidence that removing apprenticeship in knowledge work degrades expertise on a specific timeline. Nobody has that evidence; the experiment is running now.

The serious counterargument is that simulation and synthetic practice can build judgment faster than legacy junior work did, deliberately concentrating hard cases instead of waiting for them to arrive. That may well be true for pattern recognition. Where it likely falls short is that judgment appears to require consequence: the memory of having been wrong when it was yours, and having to say so. Simulation reproduces the case, not the exposure. A junior who has never owned an error has learned what mistakes look like without learning what it costs to make one.

I won't manufacture urgency about timing. Whether this bites in five years or fifteen, the asymmetry favors acting. Maintaining apprenticeship capacity you didn't strictly need is cheap; discovering in a decade that you can't produce senior judgment is not.

## The org-chart story, held loosely

There's a tidy structural story that tends to ride along with this one. As protocol coordination replaces human coordination, the firm drifts toward an hourglass: a thin senior layer holding intent and accountability, a protocol layer encoding routing and policy, abundant agent execution at the base.

It's a plausible model resting on thin evidence. The measured effects are confounded by interest rates and post-pandemic overcorrection, and the counterexamples are serious: Amazon is AI-intensive and deeply hierarchical, Apple runs a functional hierarchy with extreme compartmentalization. In high-reliability domains like aviation, nuclear, and clinical care, AI adoption plausibly *deepens* hierarchy, because auditability and clear lines of authority are the design goal.

Test the hourglass in specific value streams; don't reorganize around it. The verification argument deliberately doesn't depend on it, so the durable part isn't hostage to the fashionable one.

## The thing that actually kills these initiatives

Organizations don't only coordinate work. They allocate status, budget, promotion, and power. AI barely touches any of it. So the governance layer everyone recommends building is not a technical project. Call it an AI Orchestration Office or don't; the function is ownership of workflow architecture, agent operations, and policy encoded as executable guardrails rather than PDF. Either way, it is a claim on authority.

Whoever writes the routing rules decides which work is legible, which team's process becomes the default, and whose exception gets auto-approved. That's the authority existing function heads hold today, and they won't concede it because an architecture diagram says so. Protocols are never politically neutral. Every transformation that treats a control plane as a tooling decision discovers this around month nine.

Worth noting: flattening tends to *intensify* political competition rather than resolve it. Fewer rungs means the same ambition contests fewer positions.

## What I'd actually do

**Instrument verification capacity before you cut headcount.** Most functions know their throughput and not their audit bandwidth. Four questions: who signs off, how long does a competent review take, what happens to that number at 10x volume, and what fraction of current sign-offs are genuine reviews versus rubber stamps. The last one is uncomfortable and the most informative. This is a diagnostic, not a formula. I'd rather give you honest questions than a metric with invented precision.

**Design the three activities separately.** Automate checking aggressively. Instrument judging: track where human reviewers overturn agent output, because that's your live map of where judgment is still load-bearing, and where the overturn rate approaches zero you have either a solved problem or a rubber stamp. Never let underwriting stay implicit; if nobody can name who bears the consequence, you have an unowned risk, not an efficient process.

**Treat apprenticeship as infrastructure.** Structured human-in-the-loop review where juniors verify agent output under supervision, deliberate exposure to failure with real if bounded consequence, rotation through the systems they'll eventually sign for. I'd do this even if everything else here is wrong.

**Pay for underwriting, not output.** If the scarce capability is bearing consequence, and promotion and compensation still reward volume produced, you are selecting against the exact thing your sign-off layer is about to need. And you'll lose the people carrying the most risk first, because they're the ones paid least well relative to what they absorb.

A note for readers without the authority to change headcount or compensation. You can still run those four questions against your own team, and the answer is the most useful thing you can put in front of someone who does have that authority. "My team can now produce fifty of these a week and I can competently review twelve" is a specific, checkable claim about capacity, not a complaint about workload. The instrument works best held by the people living with the constraint. Protecting your own juniors' exposure to real cases, with real if bounded consequence, is the other thing that needs nobody's permission.

## What would prove this wrong

The argument breaks if judging becomes reliably automated on novel cases; if synthetic practice demonstrably produces judgment equivalent to consequential experience; if liability genuinely decentralizes; or if AI liability insurance and vendor indemnification mature to the point that firms transfer real exposure to third-party underwriters rather than named individuals. That last one is the most plausible of the four and the one I'd watch hardest. Insurance markets are good at pricing risks nobody wants; if they price this one, the underwriting bottleneck loosens considerably.

Absent those, the asymmetry is the thing to plan around.

And the argument isn't really about AI. It's about what happens to an organization when execution scales faster than judgment and accountability, when verification debt goes unpaid long enough to come due. AI is the first technology to open that gap this wide, not the last. Which means the answer outlives whatever the current generation of models turns out to be capable of.

Execution is getting cheap faster than verification is. Most organizations are currently cutting the exact roles that produce their future verifiers. You can disagree about the shape of the org chart and still have that problem.

---

# Accountability Runs Both Ways

We raised the bar on what engineers are expected to deliver with AI. Most leadership teams never raised the bar on themselves.

Published: 2026-07-28
Category: Engineering Leadership
Tags: Engineering Leadership, AI, Accountability, Operating Model
Canonical: https://bharatsharma.pro/articles/accountability-runs-both-ways

Somewhere in the last two years, the expectations placed on engineers changed without anyone writing it down.

Ship faster. Use the tools. Do more with a smaller team. Absorb the review burden of code you didn't write. Learn a new way of working while the roadmap stays exactly as full as it was before.

Most engineers I know have accepted this. What they notice, and rarely say out loud, is that the expectations placed on *leadership* didn't change at all.

## The asymmetry

Accountability in most organizations flows in one direction. Engineers have sprint commitments, delivery metrics, performance reviews, and a manager asking why something slipped. The machinery for holding them to account is well built and constantly running.

Now ask the mirror question. When a team misses a quarter because they waited five weeks for a decision on which of two systems was the system of record, who is accountable for those five weeks? When engineers spend a third of their time on integration work that exists only because two leaders couldn't agree on ownership, whose number goes red?

Usually nobody's. The delay gets absorbed into the team's velocity and shows up as an engineering problem.

That asymmetry was survivable when execution was the constraint. It isn't anymore. When a meaningful share of the building gets faster, everything that *isn't* building becomes the bottleneck: prioritization, decision latency, unclear ownership, shifting direction. Those are leadership outputs. AI has quietly promoted them into the critical path, and the people responsible for them are often the least measured people in the organization.

> If the constraint has moved from how fast engineers build to how fast the organization decides, then leadership belongs on the same scoreboard we've always given engineering.

## What we are actually asking for

Be honest about the size of the ask. Adopting AI properly is not "use the assistant." It's asking engineers to:

- Review more code than they write, including code with no author to ask.
- Develop judgment about when a plausible-looking answer is wrong, which is harder and more tiring than writing the thing yourself.
- Carry the same production accountability for output they generated in a fraction of the time.
- Change a craft they have spent a decade getting good at, in public, while still hitting dates.

That is a substantial, genuinely difficult professional shift. It is reasonable to ask for it. It is not reasonable to ask for it while offering nothing in return and calling the result a productivity gain.

## The other half of the contract

If you're going to hold engineers accountable for delivering more, here is what you owe them. Not as a perk, as the reciprocal obligation that makes the ask legitimate.

- **Time blocked, counted from the team's side.** Not "how quickly did leadership decide," which just invites fast, hollow decisions to beat a clock. Measure how long teams sat waiting, reported by the people who did the waiting. Treat a two-week block the way you'd treat a two-week build failure.
- **Pivots that arrive with a name and a reason.** The goal isn't a frozen roadmap; in this market that would be its own kind of failure. The goal is that a change in direction is attributed and explained, rather than appearing in the backlog overnight as though it had always been there. Faster execution makes the explanation worth more, not less.
- **Claims calibrated to the evidence you actually have.** Isolating AI's effect on defect rates, amid turnover and tech debt and two new product lines, is genuinely hard. That difficulty is not a reason to build a telemetry programme before you can say anything. It's a reason to stop announcing the 30% gain. If you can't separate the signal, lower the claim. Leaders who report only the numerator aren't measuring, they're marketing.
- **Capacity that reflects the new work.** Review, validation, and judgment are real work. If they aren't in the plan, you haven't redistributed the effort, you've hidden it.
- **Owning the outcome you asked for.** If the AI initiative you sponsored doesn't produce value, that is a leadership result, not a team result. Say so in the same forum where you announced it.

None of these require a tool. All of them require a leader willing to be measured on something uncomfortable.

## "But won't they just game it?"

Some will. Any number attached to a person's standing gets managed: decisions closed without being resolved, pivots justified in language that explains nothing.

It's worth noticing what we usually do with that objection, though. We have never once treated it as disqualifying for engineering. Velocity is among the most gamed numbers our industry has ever produced and we kept it for a decade. The risk of gaming is real in both directions; only one direction has ever been excused because of it.

The protection isn't a cleverer dashboard. It's who holds the instrument. When the number comes from the teams living with the constraint rather than from the people being assessed, gaming it requires a blocked team to agree they weren't blocked. That is a much harder lie to tell, and it's the reason to measure this from the bottom up.

With one dependency that isn't small: none of this works unless it's safe to file the report. A team that expects "we waited two weeks on you" to be heard as an accusation will quietly absorb the delay and work the weekend instead, and your numbers will look excellent right up until the people producing them leave. So safety isn't an adjacent virtue here, it's a precondition of the instrument working at all. You will find out where you actually stand the first time a reported block points at someone senior, and what happens in the ten minutes after that will tell your organization more than any dashboard.

## Making it symmetric

The practical move is small and slightly painful: for every expectation you raise on the engineering side, write down the corresponding commitment on yours, with a name and a number attached.

You asked for 20% more throughput? Then commit to a ceiling on how long any team sits blocked, let the teams themselves report the breaches, and put that number in front of the same audience that sees the delivery dashboard. You asked teams to adopt a new workflow? Then commit to removing two approval steps this quarter, and be specific about which.

The moment leadership commitments have owners and dates, something shifts. The conversation stops being "why is engineering slow" and becomes "where is this system slow," which is a question the whole organization can actually answer.

## The part that builds trust

Engineers are not cynical about AI. In my experience they are more curious about it than most executives are. What they are cynical about is being asked to change how they work by people who won't change how they work.

Accountability that only points downward isn't accountability. It's just pressure, and pressure without reciprocity is how you lose the people you most need for the transition.

The organizations that come out of this era ahead won't be the ones that demanded the most from their engineers. They'll be the ones where the demand ran in both directions, and everyone could see it.

---

# The AI-Native Enterprise Is an Operating Model, Not a Tool

Why the companies that win with AI won't be the ones with the most tools. They'll be the ones who redesigned how engineering works around them.

Published: 2026-07-18
Category: AI Transformation
Tags: AI, Engineering Leadership, Operating Model, Strategy
Canonical: https://bharatsharma.pro/articles/the-ai-native-enterprise

There is a quiet sorting happening in our industry.

On one side are companies that bought AI tools, ran a few pilots, posted about it on LinkedIn, and quietly went back to working the way they always had. On the other are companies where something more fundamental shifted: the way software gets designed, written, reviewed, and operated is materially different than it was eighteen months ago.

The gap between these two groups is widening. And it has almost nothing to do with which tools they bought.

## The tooling trap

When a powerful new capability arrives, the instinct is to treat it as a feature you bolt onto your existing process. Issue licenses, run a training, measure adoption, declare victory.

This is how organizations got nowhere with the cloud for years: lifting and shifting their data centers into someone else's data center and wondering why the promised benefits never materialized. The cloud wasn't a hosting change. It was an operating-model change, and the companies that treated it as such pulled away from the ones that didn't.

AI is the same shape of shift, only faster.

> Treating AI as a toy produces toys. Bringing real engineering discipline to it produces advantage. The difference is never the tools.

## What actually changes

An operating-model shift touches three things at once:

- **How work flows.** When a meaningful share of the "how" can be drafted by a machine, the bottleneck moves. Code review, architecture, validation, and judgment become the constraint, and your process has to be redesigned around the new constraint, not the old one.
- **How you measure value.** Most AI ROI claims do not survive contact with a skeptical finance partner. The organizations getting real leverage measure honestly: where it helps, where it doesn't, and what it costs in review overhead and rework.
- **What you hire and develop for.** As more of the mechanical work is automated, the differentiators become taste, ownership, and the ability to hold a system in your head. You start hiring and promoting for different things.

None of this comes from a license. All of it comes from leadership.

## The discipline dividend

Here is the uncomfortable part: AI rewards organizations that already had strong engineering fundamentals, and punishes those hoping it would paper over weak ones.

If your tests are flaky, your ownership is ambiguous, and your review culture is thin, AI will help you generate more code you can't trust, faster. If your fundamentals are strong, the same tools compound, because you have the discipline to catch what they get wrong and the judgment to point them at what matters.

That's why the AI-native enterprise isn't a technology project. It's a leadership project that happens to involve technology.

## Where to start

Start with one workflow you understand deeply and measure obsessively. Not the flashiest one: the one where you can tell, honestly, whether things got better. Build the guardrails. Watch the review overhead. Be willing to conclude it didn't help and move on.

Do that a few times and you stop guessing. You develop an organizational sense for where intelligence pays off, and you redesign around it on purpose.

That is the whole game: not adopting AI, but becoming the kind of organization that knows how to.

---

# Shift Left, For Real

Most shift-left initiatives just move the same bottleneck earlier and call it progress. Here's what it takes to move quality upstream without slowing teams down.

Published: 2026-07-11
Category: Quality Engineering
Tags: Quality, Shift Left, Engineering Excellence, Culture
Canonical: https://bharatsharma.pro/articles/shift-left-that-actually-shifts

"Shift left" has become one of those phrases that means everything and therefore nothing.

In most organizations it amounts to: do the same testing you did before, but earlier, and feel virtuous about it. The QA gate moves up a few days. The bottleneck doesn't move at all. Six months later, escaped defects look about the same and engineers are quietly annoyed.

Done right, shift-left is not about moving a gate. It's about dissolving the gate entirely.

## The gate is the problem

When quality lives at the end of the pipeline, owned by a separate function, you get a predictable set of pathologies:

- Engineers treat quality as someone else's job.
- Defects are found far from where they were created, when they're most expensive to fix.
- The quality team becomes a bottleneck and a scapegoat at the same time.

You cannot fix this by moving the gate earlier. You fix it by changing who owns quality and making the right way the easy way.

## Make the fast path the safe path

The single most useful principle I know: engineers will do the right thing reliably only when the right thing is also the path of least resistance.

That means investing in the infrastructure that makes quality cheap:

- Fast, reliable test suites that engineers actually trust and run.
- Pre-merge checks that catch the boring failures automatically.
- Environments that are easy to spin up and behave like production.

Every hour an engineer spends fighting a flaky pipeline is an hour they learn to route around your quality system. Reliability of the system *is* a quality strategy.

> Past a certain point, quality isn't a trade-off against speed. It's the source of speed.

## Embed, don't gate

The structural change is to move quality expertise into teams rather than downstream of them. Not "throw it over the wall to QA" but "the team owns the quality of what it ships, with the expertise and tooling to do it well."

This is a cultural shift as much as an organizational one. It works when leadership treats quality as a shared value with real investment behind it, and fails when it's a slogan with the same old gate underneath.

## Measure the right thing

If your shift-left program is judged by the number of tests written, you'll get a lot of tests and not much quality. Measure what actually matters:

- Escaped defects: bugs that reached customers.
- Mean time to detection: how close to creation you catch problems.
- Developer flow: whether the system speeds teams up or slows them down.

Get those moving in the right direction together and you've actually shifted left. Move tests earlier while those metrics stay flat and you've just rearranged the furniture.

The goal was never to test earlier. It was to build an organization where quality is everyone's job and the easy path is the right one.

---

# Hire for Trajectory, Not Résumé

The best engineers I've hired were rarely the most obvious on paper. A practical case for optimizing your hiring around how someone thinks.

Published: 2026-07-04
Category: Engineering Leadership
Tags: Hiring, Talent, Engineering Leadership, Culture
Canonical: https://bharatsharma.pro/articles/hiring-for-trajectory

Hiring is the highest-leverage thing an engineering leader does. Everything else (culture, velocity, quality) flows downstream of who is in the room. And yet most hiring processes optimize for the wrong signal.

They optimize for the résumé: the brand names, the years, the keyword match. These are easy to read and feel objective. They are also a measurement of the past, and you are hiring for the future.

## Skills age, thinking compounds

The specific skills on a résumé have a half-life, and it keeps getting shorter. The framework someone mastered three years ago may be a liability today. What doesn't age is *how they think*: their ability to learn quickly, reason from first principles, and own a problem end to end.

This is what I mean by trajectory: not where someone is, but how fast they're moving and in what direction. A candidate two years into a steep climb will often outperform one ten years into a plateau, even when the second has the more impressive CV.

## What trajectory looks like

Concretely, I'm looking for three things:

- **Ownership.** Do they talk about outcomes or activities? When something broke, did they treat it as theirs to fix or someone else's to blame?
- **Curiosity.** Do they understand *why* the systems they worked on were built that way, or just *that* they were? Curiosity is the engine of the whole climb.
- **Learning in public.** Can they tell you about a time they were wrong, what they learned, and how it changed them? The willingness to be wrong on the way to being right is the single best predictor I know.

> The best engineers I've hired were rarely the most obvious on paper. Skills age; the way someone thinks compounds.

## Build a process that can see it

Here's the catch: most interview processes are structurally incapable of detecting trajectory. A trivia-style technical screen measures what someone already knows. A take-home that rewards polish measures who had a free weekend.

To hire for trajectory you have to design for it:

- Give problems with no clean answer and watch how they navigate ambiguity.
- Ask them to teach you something they understand deeply; depth of thinking shows immediately.
- Probe past decisions: what they'd do differently, and why.

You're not testing for the right answer. You're testing for the quality of the reasoning that gets there.

## The cultural dividend

Hiring this way does something beyond filling the role. It sets the standard for what your organization values. When you promote and reward trajectory, you tell everyone that growth is the point: that being wrong on the way to being right is safe, and that learning out loud is how you get ahead.

That message compounds, too. The teams I'm proudest of weren't built from the most impressive résumés. They were built from people on a steep climb, in an environment that kept them climbing.

---

# Developer Productivity Is Leadership's Job

Every hour an engineer fights the toolchain is a decision someone above them failed to make. Treating developer experience as a first-class investment.

Published: 2026-06-27
Category: Engineering Productivity
Tags: Developer Productivity, Platform Engineering, Developer Experience, Engineering Leadership
Canonical: https://bharatsharma.pro/articles/developer-productivity-is-leaderships-job

There's a version of the productivity conversation that blames engineers. They're not focused enough, not using the tools, not moving fast enough. It's a comfortable story for leadership because it locates the problem somewhere else.

It's also almost always wrong.

When engineers are slow, the cause is usually a thicket of friction they didn't create and can't fix on their own: a flaky build, a fifteen-minute local setup, an ambiguous ownership boundary, three approvals for a one-line change. Every one of those is the residue of a decision someone above them failed to make.

## Friction is a leadership artifact

Think about what it actually takes to ship a change in your organization. Trace the path from idea to production and count the places an engineer waits, retries, or asks permission. Each of those is a tax, and engineers pay it dozens of times a day.

They didn't choose that tax. Someone decided, or failed to decide, that the build pipeline could stay flaky, that the staging environment could stay unreliable, that the approval process could keep growing. The friction is real, but it's not the engineers' doing.

> Every hour an engineer fights the toolchain is a decision someone above them failed to make.

## Treat developer experience as a product

The organizations that take this seriously do something specific: they fund developer experience as a first-class investment with real ownership, the way they'd fund any product that matters.

That means:

- A team that owns the internal developer platform and treats engineers as its customers.
- A roadmap driven by where engineers actually lose time, not by what's fun to build.
- A budget that reflects the leverage, because a small improvement multiplied across every engineer, every day, is enormous.

This isn't a perk. It's one of the highest-return investments available to an engineering organization, and it's invisible only because nobody bills for the hours it saves.

## Measure flow, not activity

The fastest way to ruin a productivity effort is to measure the wrong thing. Count commits or lines and you'll get more commits and lines, and no more value. Worse, you'll teach your best people that the game is gamed.

Measure flow instead:

- How long does a change take from start to production?
- How often can teams deploy with confidence?
- Where, specifically, do engineers report losing time?

Then fix the biggest source of friction, measure again, and repeat. Honest measurement is what separates a real program from a dashboard nobody trusts.

## The return

When you remove friction, you don't just get faster delivery. You get engineers who feel respected: who can tell that leadership noticed the daily papercuts and did something about them. That feeling is its own form of leverage. People do their best work when the path to doing it isn't an obstacle course.

Productivity isn't something you demand from engineers. It's something you build for them. And building it is leadership's job.