The recent Citrini “scenario” (written primarily for investors) showcased a dystopian vision of the future in which vast swathes of human labor were replaced by AI agents, leading to a spike in unemployment and a massive increase in inequality. One of the suggestions of the article was that vibe coding would lead to a plethora of cheap copycats for major software applications, erasing margins in a race to the bottom.
‘A competent developer working with Claude Code or Codex could now replicate the core functionality of a mid-market SaaS product in weeks. Not perfectly or with every edge case handled, but well enough that the CIO reviewing a $500k annual renewal started asking the question “what if we just built this ourselves?”’
Other market participants were quick to refute the Substack post, citing economics or technical feasibility. Some people attacked the authors with ad hominem references to their prior employment or attributed the piece as a sensationalist ploy to generate subscription revenue for their newsletter.
‘According to Citadel Securities, current data show little sign of widespread AI-driven labor disruption, citing surveys from the St. Louis Fed and labor market indicators. Job postings for software engineers — a field seen as vulnerable to automation — have jumped in recent months, and construction hiring appears to be picking up, supported by a boom in AI-related data center projects, wrote macro strategist Frank Flight in a report.
‘Instead of replacing human workers, “it seems more likely that AI will be a complement” for labor in many areas, similar to past technological revolutions, he said. “To frame this debate correctly, one can simply ask: was the advent of Microsoft Office a complement or a substitute for office workers?” Flight added.’
The Citrini piece suggests that independent developers pose the threat. Where there were a handful of leading vendors for a particular class of solution, now there would be dozens. Agents would do the heavy-lifting of figuring out which one to use for any individual transaction.
‘DoorDash (DASH US) was the poster child.
‘Coding agents had collapsed the barrier to entry for launching a delivery app. A competent developer could deploy a functional competitor in weeks, and dozens did, enticing drivers away from DoorDash and Uber Eats by passing 90-95% of the delivery fee through to the driver. Multi-app dashboards let gig workers track incoming jobs from twenty or thirty platforms at once, eliminating the lock-in that the incumbents depended on. The market fragmented overnight and margins compressed to nearly nothing.
‘Agents accelerated both sides of the destruction. They enabled the competitors and then they used them. The DoorDash moat was literally “you’re hungry, you’re lazy, this is the app on your home screen.” An agent doesn’t have a home screen. It checks DoorDash, Uber Eats, the restaurant’s own site, and twenty new vibe-coded alternatives so it can pick the lowest fee and fastest delivery every time.
‘Habitual app loyalty, the entire basis of the business model, simply didn’t exist for a machine.’
These vandals at the gate would see how an application like Stripe works, deconstruct it, and replicate it, selling it for a very low price given that their marginal cost is zero.
People have been knocking off products since the beginning of time. Look at bootleg imitations of luxury branded goods coming out of Asia, for example. Instead of fake Rolexes, there would be hundreds of Stripe competitors flooding the field. Customers wouldn’t care as long as the competitors could get the job done. At a minimum, they might use this newfound choice to force Stripe’s high prices back down to earth, at least for themselves.
Your agent doesn’t care if the Rolex is real, apparently.
If Citrini is directionally correct that there are incipient threats to software developers from vibe coding, the threat in the enterprise may not be from independent developers who compete in an open market as much as it comes from enterprise customers themselves.
There are two dimensions of the risk to outside software developers: replacement of existing software subscriptions and duplication of never-adopted solutions.
In the former case, you cut your subscriptions to Workday because you have a good-enough alternative that your IT team developed in-house.
In the latter case, you never buy Workday in the first place. You figure out what Workday is doing and you build it yourself.
Witness the initial shots across the bow in the enterprise software space. Some market-leading companies cut their long-held subscriptions to well-known services, choosing to replace them with in-house developed products. This was always a threat, of course. But the cost of development in both time and money didn’t justify replacement previously. The easy path was to stick with your incumbent vendor.
Now, once you get to a sufficient number of users, it might make sense to build your own version given that the perceived costs of development, maintenance, and support are collapsing. You already know how your organization is using the service. You already understand how the features work.
‘A recent example that illustrates this shifting paradigm is Klarna, the buy-now-pay-later giant. In a move that has stirred both interest and skepticism in the tech world, Klarna announced plans to “shut down SaaS providers” and replace them with internally built AI solutions. The company has already severed ties with major enterprise software providers like Salesforce and Workday, opting instead to develop its own applications, likely built on OpenAI’s infrastructure.
‘Klarna’s CEO, Sebastian Siemiatkowski, framed this decision as part of a broader strategy to consolidate and streamline operations through AI, standardization, and simplification. The company claims that its AI-powered customer service assistant, launched in collaboration with OpenAI, has already performed the work of 700 human agents and handled millions of interactions.’
The duplication of never-adopted solutions is a hybrid of the replacement theory with the Citrini copycat thesis.
Consider Acme Corp.
They have a problem that they need to solve. There are a dozen software vendors in the market with solutions.
Before AI, they would have used an RFI or an RFP to gather information about the different offerings. This would help them understand problem-solution fit. The bid solicitation may or may not have required information about pricing. After reviewing and comparing the received supplier proposals, Acme would have entered into negotiations with one or more of them leading to a binding contract.
Implicit in the RFI/RFP was the understanding that the buyer would not disclose proposals to third parties. Specifically, an ethical buyer would not share supplier A’s proposal with any of supplier A’s competitors. This understanding was sometimes codified in the bid solicitation document. Or suppliers could mark certain information as confidential. Many suppliers just assumed that this was the case.
In the presence of AI, without this understanding, why would a supplier respond to a software RFI/RFP?
It’s difficult enough to get suppliers to submit proposals given the requisite investment of time and expense, not to mention the uncertainty of a contract after the smoke clears.
Now that enterprise IT departments have access to AI, suppliers are not only competing with themselves; they’re competing with their customers.
The buyer’s Chief Technology Officer will make the case to the internal stakeholder committee that his team can build the product. He doesn’t have to submit a proposal. He can wave his hands when it comes to pricing by throwing up some back-of-the-envelope estimate of vibe coding costs.
We can quibble about the fact that the buyer is building a photocopy of a snapshot of the vendor’s offering or that the buyer is giving up the learning that the vendor enjoys from having multiple customers or that the buyer doesn’t have insight into the vendor’s product roadmap. But for a CTO those arguments are neither here nor there.
So, why would a buyer issue an RFI/RFP?
Because the proposals they receive provide greater detail about how to prompt the LLM.
We’ve flipped the script. It used to be the case that ideas were a dime-a-dozen and execution was everything. Now execution is a commodity and the idea is the seat of the value.
It’s not enough to tell Claude Code to build an enterprise app that does everything Workday does. It’s much better if you get Workday to tell you exactly what you need to do and then feed that into the machine.
The mere issuance of an RFI/RFP does not guarantee a purchase. It’s not a tender offer. The buyer can just say, “We were kicking the tires.”
Buyers who behave this way exploit the supplier’s naive reliance on the buyer’s intent to keep their proposals confidential without realizing that the buyer is now their competitor.
This is negotiating in bad faith for what is an RFI/RFP but the initial step in a negotiation.
Bad faith negotiating means engaging in the process without any authentic intention to get to a fair agreement, substituting instead deception to manipulate the process.
It is IP theft.
It is fraudulent misrepresentation when a buyer intentionally or recklessly makes a false statement of fact to induce a supplier to submit a proposal in response to an RFI/RFP on the supplier’s information and belief that the buyer genuinely wants to purchase a third-party solution, concealing their true intent to duplicate some or all of the supplier’s application. The supplier suffers a loss because of their reliance on this false representation.
Just because you can do something doesn’t mean you should do it.
I can hear it now. Some buyers will say that they never committed to purchasing a third-party solution and that development of a homegrown solution was always on the table. It’s not their fault that the supplier was willing to open their books.
That may be technically and legalistically true, but it’s still also true that the buyer exploited the supplier’s naïve reliance on the buyer’s integrity or the buyer’s pre-AI behavior.
Imagine someone who sets up a startup, call it Bravo Zulu. They get funded by Tech Bros LLC. They issue an RFI for software in some market. They receive a number of responses because everyone is interested by their Tech Bros relationship. And then Bravo Zulu builds a competitor solution in the same space as their RFI, competing at lower prices.
That would be slippery, wouldn’t it?
It’s just as dodgy when a buyer gets their IT department to take the role of Bravo Zulu, even if they only ever have one customer, i.e., the internal users.
It will be interesting to see what happens when the first software OEMs sue a potential client for doing this. If you conclude that you don’t want to have someone like that as a client, then you might as well go for the throat pour encourager les autres.
Unless an RFI/RFP explicitly rules out internal development and commits the buyer to contract with the winner of the process (for example with a tender offer at the terms stated by the supplier in their proposal), why would any software supplier respond? Why should they?
Suppliers beware.
Sextant AI helps companies buy and sell, painlessly. We help teams get ready to execute RFPs and make it easy for them to do so.