"If AI can write code, shouldn't it be much cheaper and faster?"—Since entering 2026, when presenting estimates for custom system development, opportunities to be asked this by clients have noticeably increased. Because coding with generative AI has become routine, people feel that person-months and costs should naturally decrease. We understand that feeling. Certain parts of implementation have indeed accelerated.
However, what we actually experience in custom development is a slightly different shift. While time spent "writing" code decreased, time spent "reading, modifying, and assessing whether AI-written code is fit for production" noticeably increased. In total volume, many projects have not necessarily become cheaper or faster. In this article, while confirming with public data that this impression is not mere imagination, we organize from a custom development vendor's perspective how estimates, quality assurance, and client relationships change in post-AI custom development.
The Sensation of "Faster" Versus Measured Reality
First, what we must keep in mind is that the sensation of becoming faster with AI does not always match measured productivity.
A 2025 randomized controlled trial conducted by the non-profit research organization METR soberly illustrates this point. In an experiment where 16 experienced developers completed 246 tasks on mature open-source repositories they had contributed to for over five years, the developers predicted they would be "24% faster using AI." Yet the result was the opposite: under conditions permitting AI, tasks actually took 19% longer to complete. Furthermore, a disconnect between perception and measurement was observed: developers subjectively felt they were "20% faster" in their post-task self-evaluations.
Reading this result as "AI is useless" is premature. In simple, clearly defined tasks (such as writing a small HTTP server from scratch), other research shows figures where AI assistance is 55% faster. What is crucial is that work that accelerates and work that conversely slows down are clearly divided. Green-field implementations with locked specifications are fast. On the other hand, modifications where existing context is complex and breaking changes loom unless implicit rules and historical background are respected—namely, the most common work in custom development: modifying systems built by others—require verifying AI proposals one by one, piling up overhead and failing to meet naive expectations.
The primary battleground of custom development is precisely the latter. The reason the hard parts of custom development do not vanish even as AI becomes ubiquitous is that the challenge lies not in the speed of typing code, but in correctly interpreting the context of existing systems. This structure appears repeatedly in our article on AI-assisted legacy migration, which outlines the difficulties of advancing legacy migrations with AI support.
The Center of Gravity Shifted From "Writing" to "Evaluating"
Where, then, has the center of gravity for workload shifted in post-AI custom development? In short, it shifted from the process of generating code to the process of evaluating generated code.
Industry-wide surveys indicate that approximately 40% of committed code today is generated by AI. As generated volume increases, the burden of deciding "is this acceptable to deploy to production?" grows accordingly. In fact, in a survey summarizing quality assurance trends in 2026, 67% of developers responded that time spent debugging increased after adopting AI, reporting that productivity gains are eaten up by maintenance burdens. A substantial proportion of AI-written code cannot be shipped to production without some form of intervention.
This shift is corroborated by other metrics measuring code quality. When GitClear analyzed over 200 million lines of code changes between 2020 and 2024, code churn (written and quickly discarded or reworked) rose from 3.1% to 5.7%, and code duplication rose from 8.3% to 12.3%. When duplication increases, a fix in one spot easily ripples to unexpected locations. We covered this very structure—where superficially similar code is hastily unified, making it fragile when touched—in detail in our article on reverting over-abstracted code back to duplication. Left unchecked, AI rapidly accumulates this type of debt.
In other words, the scarcity of skills demanded in custom development has inverted. Rather than "someone who can write code," "someone who can evaluate whether this code is safe for production" is now far more valuable. The added value of custom development is shifting there as well.
Why Justifying Estimates Became Harder to Explain
This shift in the center of gravity makes explaining estimates more difficult. While clients hold a simple equation in their minds that "AI = fast implementation = cheap," what we bill for is not implementation, but the person-hours for review, verification, and correction. The question "writing time decreased, so why hasn't the total price gone down?" stems from this disconnect.
Additionally, projects incorporating AI carry uncertainties not found in traditional development. As pointed out in the 2026 guide explaining AI development costs, features utilizing AI require PoC (verification) phases and buffers for trial-and-error risks because "you cannot know what accuracy will be achieved until you build it." The reason price differences of 2x to 10x emerge between companies for the same business requirement is that how this uncertainty is factored into estimates varies widely across firms.
| Process | Weight in Custom Development Pre-AI | Weight in Custom Development Post-AI |
|---|---|---|
| Requirement articulation / Context comprehension | Medium | High (Prerequisite for prompting AI correctly) |
| Implementation (Writing code) | High | Low to Medium (Partially accelerated) |
| Review / Verification / Modification | Medium | High (Centered on evaluating generated code) |
| Testing / Quality assurance | Medium | High (Ensuring validity of AI-generated portions) |
The meaning of the person-month unit has also quietly transformed. Formerly, a person-month was a proxy metric for "the volume of implementation one person can handle in a month." Now that implementation is partially offloaded to AI, what custom development sells is not implementation volume itself, but the judgment to read context, evaluate AI output, and deploy to production with accountability. Negotiations urging "cut person-months because implementation got faster" diverge from the substance of provided value. Justifying estimates became harder to explain because words have not caught up with how the unit's meaning has changed.
Our Case Study: Taking Over an "AI-Built Prototype"
Let us look at a specific example. A mid-sized service company (name withheld) consulted us to take an inventory management prototype built by an internal staff member using generative AI and bring it to production-grade quality. According to the client, "AI wrote 80%. It should just need the remaining 20% polished." The estimate's premise was also that "20%."
However, upon reviewing the actual code, identical inventory calculation logic was duplicated with subtle differences across screens, input validations were missing in various places, and data states during errors remained undefined. While it was a working demo, conditions that "inevitably occur in operations"—such as consistency when multiple users update inventory simultaneously, or handling network drops mid-request—were not accounted for. AI had promptly generated "something that looks functional," but no one had evaluated whether it was safe for production.
What we actually did was not add flashy new features. We consolidated duplicated inventory logic into a single authoritative source, comprehensively introduced input and boundary condition validations, and defined concurrency and error behaviors. In short, we manually backfilled the "evaluation and responsibility" stages that AI bypassed. The "20%" anticipated by the client actually occupied the bulk of the entire engagement. Deciding where business logic should reside followed the exact same criteria covered in our article on organizing domain knowledge placement through refactoring.
What this project taught us is that while the difficulty of creating "something that works" with AI has certainly decreased, the difficulty of "making something that doesn't break in production" has not decreased. Rather, as superficially functional prototypes proliferate, custom development increasingly absorbs the work of bridging the gap between "working" and "production-ready."
What Clients and Vendors Must Agree On Post-AI
Based on the above, key points that clients and vendors must align on upfront to avoid pitfalls in AI-era procurement become apparent.
First, separate "fast implementation" from "cheaper total cost". What AI speeds up is primarily coding, whereas custom development costs have migrated to review, verification, and quality assurance. When comparing estimates, asking "who ensures quality, and how?" rather than looking at code generation speed gets to the heart of the matter.
Second, estimate taking over an AI-built prototype as equal to or greater than green-field development. As illustrated in the case study, a vast gulf lies between a prototype being 80% complete and being ready for production. Ordering under the assumption that "it's almost done" will cause evaluation and refactoring person-hours to balloon later.
Third, do not treat using AI in itself as a guarantee of deliverable quality. What matters is not whether AI is used, but who reviews the generated code against what standards, backed by tests. Whether a vendor has a structure capable of explaining "how AI-generated output is verified" serves as a reliable criterion when choosing a partner.
If you are wondering how to turn an AI-built prototype into production-ready software, want to assess the validity of an AI-oriented estimate, or wish to verify generated code quality with an objective eye, please contact GleamHub. We review existing code and prototypes, frankly evaluate what can be reused as-is versus where evaluation and rework hours are required, and collaborate with you to design a phased path toward reliable production operations.
Sources
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity － METR
- AI Code Quality in 2026: Guardrails for AI-Generated Code － TFiR
- AI Coding Assistants and Developer Productivity: What the Studies Actually Show － CallSphere
- AI Custom Development Market Rates: 2026 Edition － clantable
