Where Does the Man-Month Go? How AI Coding Agents Are Rewriting Software Pricing

ZenChAIne·June 23, 2026

AI agentssoftware outsourcingpricingin-housing

Introduction

The questions that land on a software shop's desk have changed. "Can you analyze this legacy system with AI and rebuild it?" "We dropped our SaaS contract and built it in-house with Claude Code." "We're planning to pull our existing vendor and rewrite everything with an LLM." And almost always, the closer: "It should be cheaper with AI, right?"

This column is about what quietly breaks behind that last sentence: the man-month, the convention of pricing software by how many person-months it consumes. The more AI compresses the time it takes to write code, the less power "how many hours did people work" has as a basis for a price.

Key takeaways

AI has broken the correlation between effort (man-months) and value, so pricing by hours is losing its explanatory power.
Outcome- and value-based contracts are already ahead in the US: over 40% of new outsourcing deals and roughly a quarter of McKinsey's revenue are now outcome-linked.
With Claude Code and Codex as the baseline, what vendors sell shifts from "implementation time" to judgment, guarantees, and operations.

Why doesn't the man-month work anymore?

The man-month wobbles because AI broke the proportional link between effort and outcome. The moment you can ship the same feature with fewer people in less time, "how many person-months will it take" stops working as a basis for a price.

The numbers back this up. Teams that adopt AI coding tools systematically report delivering the same outcomes with 30–40% fewer engineering hours, and some studies put the reduction in raw coding time at around 55% (getmonetizely, "2026 Guide to SaaS, AI, and Agentic Pricing Models").

The effect is far from uniform, though. In a 2025 randomized controlled trial by the research group METR, experienced open-source developers were actually 19% slower when using AI (METR later noted measurement limitations in a 2026 update). So "AI always makes you faster" is not a safe claim. The real point isn't speed—it's that effort and value have decoupled, so hours can no longer be the sole basis for a price.

This creates a conflict of interest. Hourly billing is a model where getting faster shrinks your revenue. If your invoice drops by exactly the amount AI made you more efficient, you have no incentive to be efficient. Investors see it too: shares of IT-services firm EPAM fell sharply after earnings on fears of "AI deflation"—faster delivery meaning fewer billable hours.

In other words, the man-month carries a built-in contradiction: the more honestly it passes AI's gains to the client, the more it erodes the vendor's own revenue.

What kinds of contracts are emerging overseas?

The short answer: in the US and Europe, the move from selling time (Time & Materials) to selling outcomes (outcome / value-based) already shows up in the data. The contract desk is moving before the debate even starts.

A few headline figures:

Outcome-based contracts made up roughly 43% of new outsourcing deals in 2025, the fastest-growing contract type (getmonetizely).
IDC forecasts that by 2028, 70% of software vendors will migrate to consumption-, outcome-, or capability-based models, making per-seat pricing structurally obsolete.
McKinsey disclosed at a November 2025 London event that about a quarter of its global fees are now outcome-linked (Hunt Scanlon Media). Clients increasingly arrive with the outcome they want and ask the firm to price against actually delivering it.

The pricing shapes are concrete too. Value-based deals are framed as 10–40% of the cost savings or revenue gains an AI initiative produces (Stack, "AI Consulting Proposals"). Fixed price is making a comeback: US legacy-modernization vendor Baytech Consulting agrees a fixed price and timeline per engagement and runs in short sprints—rebuilding an aging healthcare education platform into a new LMS in about 7 months for roughly $600,000.

Outcome- and value-based pricing is not "a vendor's excuse to charge more." It works partly because firms like McKinsey have the leverage to make it work. Drop it into an engagement where you can't pin down the requirements or the success metric, and the risk lands entirely on the vendor.

How does the content of an estimate change with Claude Code and Codex?

With Claude Code or Codex as the baseline, the single largest line item—"time spent hand-writing code"—shrinks. In its place, the estimate fills with requirement framing, design decisions, review and verification, and post-launch guarantees.

The crucial caveat: AI coding is not free. Running agents heavily on token-based billing can reach $500–$2,000 per engineer per month (getDX / morphllm). Part of what used to be labor cost turns into AI execution cost—a variable cost. The estimate rebuilds from "man-months × rate" into "outcome + AI execution cost + the price of judgment and guarantees."

The shift on the buyer side matters just as much. In Retool's 2026 survey of 817 enterprise builders, 35% of teams had already replaced at least one SaaS tool with a custom build, 78% planned to build more, and 60% of those builds happened as shadow IT outside official procurement. Yet in the same survey, only 8% of teams ship AI-generated code unmodified. In-housing is both downward price pressure and, in reverse, a new source of demand for quality assurance and governance.

For a vendor, that is both downward price pressure and a forced redefinition of role. In an era where a business operator can prototype something over a weekend, the part you can still charge for is not the speed of building—it's the judgment to build it correctly and run it without breaking things.

The traps in outcome-based models

Outcome-based and fixed pricing are not silver bullets. The biggest trap: when you're made to promise an "outcome" while the requirements stay vague, the entire uncertainty risk lands on the vendor. The margin AI created by working faster gets eaten by the rework of changing requirements.

The antidote is an explicit outcome-measurement (acceptance) agreement. Unless the contract defines up front what counts as "outcome achieved" or "problem solved," a missed KPI turns into a dispute over attribution—was it the vendor's implementation, or the client's data quality and operational follow-through? Tellingly, even AI SaaS vendors are swinging back from pure outcome pricing toward fixed + usage + outcome hybrids, because measurement, attribution, and budget predictability are hard.

There's a second paradox: the easier something looks to build with AI, the harder it is to win as a contract. If it looks easy, the buyer concludes "we'll just build it ourselves," and the engagement disappears. Competing on cheapness actively shrinks your own market.

So the practical path is not to leap straight to pure outcome-based pricing. Start with a hybrid—fixed price for design and judgment, usage-based for AI execution and operations, plus a slice of outcome-linked upside tied to KPI improvement. Quietly move the unit of pricing from "man-months" to "problems solved."

Will outcome-based pricing take hold in Japan?

Honestly, "pure outcome-based pricing" is unlikely to take hold broadly in Japan any time soon. But "100% man-month" can't survive either. Our read: it arrives through a distinctly Japanese gradient—shallower and slower than in the US.

Four structural walls make it a hard fit. First, multi-tier subcontracting: in the prime → first-tier → second-tier → staffing chain, only the prime controls the outcome; the lower tiers, whose reason to exist is supplying people, have no channel to pass outcome-linked terms down. Second, a build-up budgeting culture where buyers approve "how much will it cost," making "pay X% of the savings" hard to push through internal approval. Third, relationship-first commerce that dislikes measurement and attribution disputes. Fourth, vendors' low risk appetite (a demerit-driven mindset).

That said, outcome-style pricing already exists in pockets in Japan: ad-operations retainers (a % of ad spend), per-ticket BPO billing, SLA penalties in maintenance, revenue share on startup work. And usage-based billing is already normalized via cloud and SaaS. So what lands first in Japan is not pure outcome pricing but a sequence: usage (AI execution cost) → SLA-based and limited outcome links in operations → a capped gainshare of a few percent of cost savings.

The key point: this is a question of "who," not of the whole industry. It fits the primes who control outcomes, partners who ride alongside as quasi-in-house teams, and AI-native small vendors. For staffing-centric firms, outcome-based pricing isn't a rescue—it's the force eroding their footing. And the trigger for the shift is, ironically, the client's own "can't you make it cheaper with AI?" That one line erodes the legitimacy of the man-month from within, and when it collapses, only the vendors prepared to speak in outcomes can turn it into a bargaining chip.

So how does this estimate actually get built—line items and KPIs—on the ground in Japan? That's the subject of Part 2 of this series, How to Build an AI-Era Estimate, down to a four-block sample estimate and KPI design for systems that don't touch revenue directly.

FAQ

Q. Will the man-month disappear entirely?

A. Not immediately. It will linger in exploratory phases where requirements aren't fixed and in maintenance work where you want a clear line of responsibility. But it stops being the headline price and becomes one component combined with fixed, usage-based, and outcome-linked terms.

Q. If AI makes it cheaper, should I lower my estimate?

A. Not across the board. Lower the price of "hands-on-keyboard time"; raise the price of correct judgment, non-breaking design, and operational guarantees. The point is to restructure the line items, not to cut the total.

Q. Does outcome-based pricing favor the buyer or the vendor?

A. It favors whoever controls the success metric. It benefits both sides when requirements and measurement are agreed up front; introduced vaguely, the risk skews to the vendor. Keep outcome-linked terms to a slice of the total at first.

Q. As in-housing spreads, do software vendors become unnecessary?

A. "Build-only" work shrinks, but demand doesn't vanish. Shadow-IT builds inevitably hit walls on quality, security, and operations. Vendors who can take that on gain a new role rather than losing the old one.

Summary

The man-month is fading because AI broke the proportional link between effort and value. The migration to outcome- and value-based pricing is already underway by the numbers overseas, and that wave is reaching every market.

Here's the honest part: the falling unit price of "building" software can't be fully dodged by articulating value. The downward pressure is unavoidable. But a lower unit price is not the same as a vendor's revenue disappearing. As building gets cheaper, legacy systems that were never worth modernizing cross the line into "now it pays," and the pool of work widens. Unit prices fall while the total volume of addressable projects actually grows—a shift already starting on the ground.

So what separates the survivors isn't who refused to discount. It's who—taking unit-price deflation as a given—can recover it through higher project volume, recurring maintenance, and upstream judgment, and who rebuilds their cost base and staffing to make that possible. When AI takes the grunt work, how do you still train juniors and survive as a vendor? That question is the subject of Part 3 of this series.

ZenChAIne supports decisions in this transition from both sides—building delivery teams around Claude Code and Codex, and designing estimates that don't depend on the man-month. For the related shift in the proposal process itself, see The End of the RFP.

References

🇯🇵 日本語で読む