The numbers are difficult to ignore.
The Faros AI Engineering Report 2026, based on two years of data across 22,000 developers and more than 4,000 teams, points to a sharp acceleration pattern. High AI adoption correlates with more output, but also with more strain on engineering systems.
The report highlights the pattern plainly:
- PR size is up 51.3%.
- Bugs per PR are up 28.7%.
- Median time in PR review is up roughly 5X.
- Incidents per PR are up 242.7%, more than tripling relative to the low-AI-adoption baseline.
- Code churn is up 861%, about 9.6X the prior rate.
- Bugs per developer are up 54%.
Those numbers do not argue against AI.
They argue against unmanaged AI.
We discussed the report as a working conversation between Srinivas Moorthy (aka RSM), KSR, Murali, and Koushik. The question was not whether AI engineering tools are useful. They clearly are. The question was whether enterprises are redesigning the delivery system fast enough to absorb what these tools now produce.
Koushik framed the discussion this way:
If AI makes execution cheap, what becomes expensive?
The answer was immediate.
Verification. Context. Review. Coordination. Rework. And increasingly, token consumption.
Srinivas Moorthy (aka RSM): Are We Mistaking Activity For Capacity?
Srinivas Moorthy opened as the skeptic.
“The report says output is up. Fine. But the same report says bugs, review time, incidents, and churn are also up. So are we increasing capacity, or are we increasing motion?”
That is the uncomfortable question.
AI coding tools make it easy to begin. They make it easy to generate. They make it easy to expand scope. They make it easy to ask for one more version, one more refactor, one more test, one more architecture suggestion, one more explanation.
But enterprise delivery is not measured by how much code was produced.
It is measured by how much trusted change reached production without creating avoidable operational burden.
Srinivas Moorthy’s concern was not anti-AI. It was anti-theatre.
“If a team generates more code, opens larger PRs, spends longer in review, creates more defects, and burns more tokens correcting itself, why should we call that productivity?”
That is a fair challenge.
AI can compress execution time while expanding verification cost.
If leaders measure only the first part, they will miss the second.
KSR: The Problem Is Not The Tool. It Is The Operating Model.
KSR took the pro-AI position, but with a clear caveat.
“The answer is not to slow AI down. The answer is to change the engineering model around it.”
That distinction matters.
The market should not respond to these numbers by retreating from AI engineering. Claude, OpenAI, Cursor, coding agents, test generators, review assistants, and future product engineering copilots will all have a place in the enterprise stack.
The mistake is assuming any one of them, by itself, is the delivery model.
They are engines.
The enterprise still needs traffic rules, inspection points, lane discipline, exit ramps, recovery paths, and human accountability.
KSR’s view was that AI has exposed a weakness that already existed in many engineering organizations. Requirements were loose. Acceptance criteria were inconsistent. Architecture governance was uneven. Review queues depended too heavily on senior engineers. Product context often lived in conversations rather than structured artifacts.
AI did not create all of that.
It accelerated into it.
“When the operating model is loose,” KSR said, “AI does not merely produce faster. It amplifies ambiguity faster.”
That is the key shift.
AI adoption is not only a tooling decision. It is an operating model decision.
Murali: Token Consumption Is The New Waste Stream
Murali brought the conversation back to economics.
“Everyone talks about code volume. I am more worried about token volume.”
That may be the more important enterprise question.
Token consumption is often treated as a cloud-cost line item or a procurement issue. But in AI-native engineering, token consumption is also a quality signal.
Excessive token use can mean:
- The requirement was unclear.
- The agent loaded too much irrelevant context.
- The workflow had no scope boundary.
- The team asked the model to reason repeatedly over preventable ambiguity.
- The first output was not review-ready.
- The system lacked cheap deterministic gates before expensive model calls.
- Human feedback arrived too late.
In other words, token waste is often process waste.
Murali’s point was practical:
“If a team needs ten AI passes to reach an acceptable output, maybe the issue is not model capability. Maybe the issue is that the work was not specified well enough before execution.”
That is where token consumption becomes a management signal.
Leaders should not only ask, “How much did we spend on AI?”
They should ask:
- Which work consumed the most tokens?
- Which tasks required the most retries?
- Which repositories or domains created the largest context loads?
- Which teams produced the most review-ready output per token consumed?
- Which workflows created high token burn but low production impact?
- Which AI interactions ended in human rework?
Those questions move token management from finance to engineering governance.
Koushik: The Missing Layer Is Multi-Exit Engineering
Koushik moderated the discussion toward the delivery model.
“The answer cannot be one giant AI pipeline that assumes every task should become a PR. Enterprises need multi-exit paths.”
This is important.
Not every AI-assisted engineering activity should proceed to code generation. Some should exit into clarification. Some should exit into architecture review. Some should exit into manual engineering. Some should exit into a smaller proof. Some should exit into a different tool. Some should exit into human approval. Some should stop.
A mature AI engineering platform should support multiple exits:
- Clarify: the business intent is not yet clear enough.
- Specify: the work can proceed only after acceptance criteria are written.
- Simulate: the decision needs scenario testing before implementation.
- Generate: the task is bounded enough for agentic execution.
- Review: the output needs human or expert validation.
- Refactor: the current path produced avoidable complexity.
- Escalate: the risk, cost, architecture, or compliance concern is material.
- Stop: the task should not proceed.
This is where many tool-first approaches are still immature.
They optimize for continuation.
Enterprise engineering needs intelligent exit.
The Roundtable View: More Code Is Not The Goal
At this point, the group converged on a simple position.
AI engineering should not be judged by whether it generates more code.
It should be judged by whether it improves the throughput of trusted outcomes.
Those are different measures.
More code can increase delivery capacity.
More code can also increase review load, token burn, incident risk, architectural drift, and senior-engineer fatigue.
The difference lies in the operating system around the AI.
Srinivas Moorthy’s challenge remained useful:
“If we cannot tell when the system should stop, when it should escalate, and when a human must decide, then we have not built AI engineering. We have built an expensive autocomplete loop.”
KSR agreed, but added the constructive layer:
“The answer is not less AI. The answer is governed AI.”
Murali put it in business terms:
“The advantage is not lower cost per generated line. The advantage is lower cost per trusted outcome.”
That phrase matters.
Cost per trusted outcome is a better enterprise metric than cost per prompt, cost per token, or code generated per developer.
Why EnWithAI CrewPE Fits This Problem
This is the problem EnWithAI CrewPE is designed to address.
CrewPE is not positioned as another coding interface. It is a guided product engineering and execution system for AI-native delivery.
It helps teams move through a disciplined path:
Discover -> Specify -> Prepare -> Execute -> Validate -> Improve
That sequence matters because it creates decision points before and after generation.
Discover prevents weak intent from becoming expensive execution.
Specify converts business and engineering goals into reviewable criteria.
Prepare assembles context, architecture, constraints, prompts, tests, and operating boundaries.
Execute allows AI tools and agents to act within a governed frame.
Validate checks outputs against evidence, not confidence.
Improve turns failures, review patterns, and token-heavy loops into reusable product intelligence.
This is also where CrewPE can be tool-inclusive rather than tool-exclusive.
The future will not belong to a single model or coding assistant. Enterprises will use multiple AI systems across planning, coding, review, documentation, testing, analytics, and support.
CrewPE’s role is to provide the execution fabric above them.
Claude can reason. OpenAI models can generate and analyze. Cursor can assist in the engineering environment. Other agents can test, refactor, document, or review.
The question is not which tool wins.
The question is which operating system makes all of them useful without losing control.
Why FDE Matters For Consulting And Deployment
The report’s findings also point toward a consulting and deployment reality.
Enterprises do not only need licenses.
They need adoption engineering.
That is where Forward Deployed Engineering becomes important.
An FDE-led model can help organizations translate AI ambition into governed adoption by working directly inside the client environment:
- Map real workflows instead of abstract use cases.
- Identify where token consumption is leaking.
- Define acceptance criteria before agentic execution.
- Create reusable prompts, specifications, and validation packs.
- Tune multi-exit paths for each team and domain.
- Establish review gates that protect senior engineering time.
- Build measurement around trusted outcomes, not activity.
- Convert each engagement into reusable product intelligence.
The FDE does not replace the client team.
The FDE helps the client team build the new operating muscle.
This is the difference between selling AI tooling and deploying AI capability.
What Leaders Should Measure Next
If the Faros report is a warning signal, the leadership response should be measurable.
Enterprises scaling AI engineering should track:
- Token consumption per accepted change
- Token consumption per trusted outcome
- Retry count per task
- PR size and files touched per AI-assisted change
- Review time by risk class
- Incidents per PR
- Bugs per PR
- Churn after AI-assisted merges
- Percentage of AI-assisted work exiting to clarification before code
- Percentage of work stopped before wasteful execution
- Human approval points for high-risk changes
- Reusable learning captured per delivery cycle
The most important metric may be this:
How often does AI help the organization decide not to generate code yet?
That is not a failure.
That is maturity.
The NetworkGain Perspective
NetworkGain’s view is straightforward.
The AI engineering problem is no longer whether tools can generate code.
They can.
The problem is whether enterprises can govern the consumption of AI effort so that generation converts into trusted outcomes.
Token consumption is not just spend.
It is a signal of clarity, context discipline, workflow design, and engineering maturity.
The answer is not to choose between speed and control. The answer is to create a delivery model where speed has exits, gates, evidence, and guidance.
That is why the practical path points toward EnWithAI CrewPE, supported by FDE-led consulting and deployment.
CrewPE gives the platform rhythm.
FDE gives the adoption muscle.
Together, they help enterprises move from AI activity to AI engineering.
The best AI tools should want to participate in that model because it makes their outputs more valuable.
Not more code for its own sake.
More trusted outcomes, with less waste, less rework, and better judgment about when not to generate at all.