Recently, I often see the phrase "Contract Development is Dead" on my timeline. It is usually discussed in the context that AI is making software faster and cheaper to build, so the traditional model of "building and delivering exactly what the customer asks for" is rapidly losing value.
At first, I honestly thought, "Is this just another 'X is dead' hype cycle?"
After all, people have been saying "Contract development is dead" for decades, even before AI. In-house development, the cloud, multi-tier subcontracting, offshoring—every time, people said "this time it's really going to die," yet contract development survives like a zombie.
Actually, I spent a long time working for product companies, so I used to watch these topics from the sidelines. I remember thinking that contract development looked difficult and was something I didn't want to get close to.
Then, three years ago, I joined Hololab Inc., and now I am right in the middle of client work, including contract development. To be honest, when I joined, the term "contract development" gave me some pause. Still, the challenge of transformation brought by new technology and the appeal of the company itself won out. I figured it would be uncool to complain about "contract development" without actually trying it.
Three years have passed since then. I joined the management team and have faced contract development head-on. That's why this time, I want to face the phrase "Contract development is dead" without running away.
Is "Contract Development is Dead" True?
It is true.
Even before AI, there were movements toward no-code in the context of DX (Digital Transformation) and a trend toward in-house development. Then the wave of AI (especially AI agents) arrived, and this trend intensified instantly. Even non-engineers can now create software.
When this topic comes up, engineers who make a living from it tend to make a fuss about "quality" or "security," arguing that "software development isn't that easy."
However, the quality required for software varies depending on the purpose and use case. Software for customers or production environments requires a certain service level. On the other hand, the level required for internal tools or PoCs (Proof of Concept) is often relatively low. And this is exactly the area that is easily replaced by AI agents—or rather, where replacement has already begun.
Regarding security and quality, I feel the gap is closing every year as models evolve and human knowledge of AI utilization accumulates. Just two or three years ago, the mainstream view was "AI can assist, but it's too early to let it write code," yet now AI is writing code more often than not. Looking at this speed of change, even in areas where it's currently difficult to delegate completely, a situation where "AI is more reliable than humans" could easily happen in the near future.
To be honest, as an engineer myself, part of me doesn't want to believe that the work I've done can be so easily replaced. But I can clearly see what is dying right in front of me. This isn't hype or a position talk; it's a change that is actually happening.
However, this doesn't mean "contract development as a whole is dying." What is dying is not contract development, but software development that is "just building." I will explain why I think so.
1. You Can't Lump All "Contract Development" Together
Even if you say "contract development" in one breath, the content varies from companies that just sell man-months to SIers, consultants, product partners, PMOs, and DX support. So the question to ask is not "Is contract development dead?" but "What exactly is dead?"
When you break it down, the decline in value due to AI doesn't happen all at once; it progresses in stages. The first wave hits the value of the act of "writing code." In fact, development productivity is rising, and the profit structure of projects is starting to change.
And this wave won't stop at writing code. It will gradually spread to design, requirements definition, and the conceptualization phase before that. That's why I want to distinguish which values will drop first and which will remain.
So, what's dying is the job of "just writing code as told." Whether it's contract development or not doesn't matter. And this area is already shrinking.
However, the shrinkage is not uniform. Small to medium contract developers and small in-house developments are feeling the full force of the in-house and generative AI waves, and projects are starting to disappear. On the other hand, I often hear that complex systems for large enterprises aren't in much trouble yet because they can't be handled by in-house teams alone. The impact varies greatly depending on scale and customer base, so mixing them up blurs the conversation.
2. Customers Aren't Buying "Code" in the First Place
When you think about whether customers are contracting because they want code written, the answer is no.
What customers expect is problem-solving: they want to organize business strategies, think through requirements together, get help with decision-making, assist with internal coordination, and reduce risks. Code is just one means to that end.
Thinking this way, the logic that "code became cheap = contract development is dead" is quite shortsighted. The means became cheaper, but the expected substance hasn't disappeared at all.
This matches my own experience of working in both product companies and contract development. There are contract development sites that dive deep into the business, and there are in-house development teams that act like internal contractors, just building what the business department tells them. Drawing a line between "product company vs. contract development" no longer captures the reality.
Moreover, this isn't just about contract development. The boundary between development and consulting is also melting. Consulting firms are increasingly building development teams, and SIers are starting business support. "SaaS is dead" follows the same structure: companies that just sell software are finished, while companies that dive into BPO, operations, partnership, and performance guarantees are growing. Consulting, SIers, SaaS, and product companies are all overlapping more and more. The destination is "value" for the customer.
3. "Thinking" and "Building" are Getting Closer
For a long time, the cost of building software was far too high. Therefore, "thinking" and "building" were inevitably separated. Roles were divided, job titles were divided, organizations were divided, and even companies tended to be divided.
AI has lowered the cost of "building." As a result, "thinking" and "building" are naturally starting to converge. Roles, job titles, organizations, and companies are all getting closer. This is the change happening now.
And what Agile development wanted to achieve was exactly this: bringing "thinking" and "building" closer together. We are finally approaching the ideal that couldn't be fully realized back then because the cost of building was too high.
In fact, in our own client work, cases that don't end with just development are increasing. What starts as normal development often turns into "we want to consult on how to proceed with the business," expanding to PMO, business model design, project promotion, and decision-making support. Nowadays, there are sites where we spend more time "building the business" than "building the system." I wondered at first if this was still contract development, but I've stopped caring about the boundaries.
I've been hearing the term FDE (Forward Deployment Engineer) a lot lately, and it's likely part of the same trend. Entering the customer's site, thinking about issues together, and writing code if necessary. Not a "thinker" and a "builder," but a "person who builds while thinking." A common misunderstanding here is that the essence is being on-site or physically close to the customer. It's not. It's about being close to the problem-solving.
However, this change is a double-edged sword. I recently heard this story at a large company: It started with a business strategy. System development began. Midway through, building became the only goal. The strategy vanished. And a massive amount of unused systems remained. This reality existed long before AI. But as AI lowers the cost of building, this tragedy will happen more easily and in greater volume. The easier it becomes to build, the heavier the weight of "what to build" becomes.
Therefore, for contract development that dives into problem-solving, AI is a tailwind, not a headwind. It's far from being "dead." However, the moment you step away from problem-solving, that tailwind turns into a "mass-production machine for useless things."
4. Ultimately, the Source of Value is "People"
When you get this far, it seems that the source of value for contract development, consulting, and SaaS is the same. It's not the software itself. It's the people.
Work that any company can solve will be replaced. Work that AI can solve will also be replaced. But "it has to be these people solving it" remains. "I want to work with these people" also remains.
So the goal is not to deliver a product, but to be a partner for the customer to reach value. Make them feel value in the people, not the object.
The prime example is decision-making. AI can generate any number of candidates. But the one who decides is a human. And you only get better at decision-making by making decisions.
How we train people is also changing. In my department, we are shifting toward "thinking + building," and of course, there are struggles. But this isn't something you learn in training. It only grows within the work.
I'll mention hiring briefly. Recently, more companies are reducing junior hiring because of AI. The logic is, "If AI writes code, we don't need juniors." But I believe the opposite. AI-native juniors, because they lack fixed ideas, have the potential to devise ways of using it that we would never think of. Even if hiring is restrained in the short term, if you can't create an environment where people grow, that industry will only decline. That's not AI's fault; it's just a failure to adapt to the changes AI brought.
The profession of engineer is not disappearing. The job of an engineer who "just builds" is disappearing.
All Software Development is Approaching "Value"
"Contract development is dead" is true. However, it's not that contract development is dying, but that software development that is "just building" is dying. It's not that the profession of engineer is disappearing, but that the job of an engineer who "just builds" is disappearing. And it has already begun. Contract development just happens to be on the front lines.
If you step back and look at these changes, a bigger picture emerges. Contract development diving into business. Consulting firms with development teams. SaaS stepping into performance guarantees. FDEs entering customer sites. The positions and formats are all different, but the direction is the same. All software development is approaching "value" in its own way.
Moreover, this isn't a new trend. Engineers have known for a long time that "just building isn't enough," and have tried to get closer to customers, users, and value. The representative example is Agile development. It's been 25 years since Agile was born. That ideal of bringing "thinking" and "building" closer together is being accelerated all at once by AI in these few years. That's how it looks to me.
So, we shouldn't be obsessed with the "form" of software development anymore. Contract development or product company? SIer or consultant? Instead of wasting energy there, the question to ask is, "How deep can you dive into value?"
On 7/24, I will have a live discussion on the theme "Contract Development is Dead" until morning
On 7/24, I will be speaking at an event hosted by Creationline titled "The Future of Contract Development in the AI Era — Beyond 'Contract Development is Dead'."
https://creationline.connpass.com/event/398146/
Friday, July 24, 2026, 19:00–20:30, held via Zoom, free to attend.
I will have a thorough, honest discussion with @samuraiRed and @sasakendayo on the theme "Contract Development is Dead."
Since we are three people who might talk about things we shouldn't, I told the organizers during the prep meeting, "Please stop us if it gets out of hand." There will surely be a sense of presence that you can only experience in real-time.
What kind of things will we talk about?
The answer is... Tranquilo! Don't rush it!
I'll be waiting for you on the day.
Blog is here:
