The Vibe-Coding Temptation: Why Supply Chain Leaders Must Think Before They Build

‍

Across supply chain organizations, a tempting idea is gaining traction. I worry it is the wrong one. It goes something like this: “We have the domain knowledge. We have the business logic. We have the workflows. And now, with AI coding tools, we finally have the means to build exactly what we need.” 

It's a compelling pitch. But it's one that supply chain leaders should approach with serious caution.

Vibe-coding — the practice of using AI to rapidly prototype and generate software from natural language descriptions — has lowered the technical barrier to building software dramatically. What once required a team of developers and months of sprints can now produce a working prototype in days. This is genuinely exciting. It's also genuinely dangerous when applied to supply chain planning without discipline.

 Yes, someone can build an app quickly. That part is real. But the posts that celebrate the prototype almost never answer the harder questions: Can it scale? What about security? What's the roadmap when requirements change in six months? Who handles maintenance when the person who built it moves on? And the question nobody wants to answer — does your team actually have both the deep domain knowledge and the technical expertise to own what they just built? Domain knowledge and software engineering are two different competencies. Vibe-coding makes it dangerously easy to assume you only need one.

 The question has never been can you build it. The question is should you.

‍

The Allure of Building (and Why IT and Centers of Excellence Fall For It Every Time)

It starts with a reasonable premise: our supply chain is unique. Our constraints, our supplier relationships, our planning logic — no off-the-shelf software truly captures it. So why not build something that does?

 I’ve spoken with thousands of companies and have seen this pattern for years:  the belief that an organization's requirements are truly unique and that their team can build supply chain software. Most requirements that feel unique are usually well-served by commercial software.  The perceived gap between what exists and what's needed is usually a configuration problem, not a fundamental software gap.

 And yet, usually IT teams and Centers of Excellence remain perennially tempted to build. There are understandable reasons —  ownership over the roadmap, no vendor dependency, flexibility, software tailored to the business. AI coding tools have added fresh fuel to this instinct by making the initial act of building feel almost frictionless. A domain expert can now describe a planning workflow in plain language and watch working code appear. The prototype looks promising, confidence rises, and the decision to build gets made before the harder questions are asked. 

‍

Before You Build Supply Chain Software, Answer These Four Questions

 The build conversation usually starts before anyone has asked the harder question: are we even really using what we already have? So before your organization commits to building supply chain software — or before that "quick proof-of-concept" becomes someone's full-time job to maintain — four questions need to be asked out loud:

•  Do you have it already?  This sounds obvious, but it's routinely skipped. Existing platforms — whether your WMS, TMS, or planning suite — may already have the capability you're proposing to build. It may be underutilized, poorly configured, or simply unknown to the team reaching for a new solution. Audit before you architect.
•  Have you used it successfully?  Capability on paper and capability in practice are different things. If your organization hasn't fully adopted and optimized what you already own, adding a new custom-built system won't solve the problem — it will layer complexity on top of it.
•  Can you use it better? Data quality, configuration, training, process redesign, and change management are unsexy but high-return investments. Before concluding that the software is insufficient, determine whether the “use” of the software is insufficient. The gap is often there, not in the product.
•  What is the business case for something more or different ? If you've genuinely answered yes to the first three questions and a gap remains, then a business case for new capability is warranted. But it should be a real business case — with defined ROI, resource requirements, risk assessment, and a realistic view of total cost of ownership.

‍

The Gartner Framework: What AI Has Changed — and What It Hasn't

Gartner's pace-layering framework has long offered a useful lens for supply chain software decisions, categorizing applications into three layers based on rate of change and purpose. The key is to identify the right technology for your specific business need.  This may often mean not acquiring the “best” or deepest functionality available, but rather the right blend of functional and nonfunctional capabilities to support your maturity targets.  But AI is putting real pressure on the original model, and Gartner's most recent thinking has evolved in ways that supply chain leaders need to understand.

 The original Pace-Layered model has served us well, but it is time for an update.  Full disclosure I searched for an updated Gartner Pace-Layered framework and have not found one… perhaps it is in the works or available behind the paywall. 

 The original thinking was:

•  At the foundational level, Systems of Record (SOR), as an example, your core supply chain planning capabilities should almost always be purchased as commercial off-the-shelf solutions. These are well-established processes, common across industries, and well-served by mature vendors. This is not where you build.
•  At the next level, Systems of Differentiation (SOD), support more advanced maturity needs and capabilities that enable unique organizational processes or deep industry-specific functionality. Here, a buy-and-configure approach is appropriate.
•  Only at the highest level, Systems of Innovation (SOI),  does building or heavy customization enter the conversation. These are experimental capabilities built to address emerging requirements and competitive frontiers. But even here, I recommend and caution co-development with a vendor rather than pure in-house builds.

 The critical self-awareness required: most organizations overestimate where they sit on this maturity curve. Teams operating with spreadsheets and fragmented data pipelines often believe they are ready to deep dive into emerging technology. They are almost never right. Building a system of innovation on a system of record foundation doesn't accelerate maturity,  it typically accelerates chaos.

 BUT here is where AI has fundamentally changed the calculus — and not in the way most people may expect.

 AI isn't just living at the SOI layer anymore. It is being woven into every layer simultaneously, and the original pace-layering model, which assumed each layer changes at a distinct and separate pace, no longer fully holds. More importantly, Gartner's latest research has recast the System of Record not as the boring, stable foundation but as the most strategically critical layer in an AI-enabled enterprise.

 The System of Record is now the control plane for AI agent execution. Winning vendors, according to Gartner, will embed agent orchestration directly into systems of record, expose policy-aware execution APIs, and enforce identity, permissions, and audit trails at that layer. The SOR is where AI agents will be given — or denied — the authority to act. Gartner predicts that by 2030, software companies that bolt AI onto legacy applications rather than redesigning for agentic execution will face margin compression of up to 80%.

 What does this mean practically? Your choice of SOR vendor is now inseparable from your AI strategy. A homegrown system of record won't have the governance infrastructure, API surface, compliance controls, or the vendor investment in agent orchestration that commercial platforms are racing to build. You would need to build not just the planning software, but the entire control plane underneath it.

 Meanwhile, at the SOI layer — where AI agent experimentation lives — Gartner's numbers should give any organization pause: over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value, or inadequate risk controls. And this is for organizations building on top of proven commercial platforms. The failure rate for experiments running on custom-built infrastructure will be higher still.

 For supply chain specifically, Gartner predicts that by 2030, 50% of cross-functional supply chain management solutions will use intelligent agents to autonomously execute decisions. My point being that the organizations positioned to capture that opportunity will be the ones whose commercial SOR vendors have already built the orchestration layer — not the ones still maintaining a homegrown planning system that no agent can plug into cleanly.

‍

The Hidden Costs that the Business Case Often Misses

Custom-built supply chain software carries costs that are chronically underestimated in the business case and chronically overrun in practice. These include:

 Maintenance: Every line of custom code is a line your team owns (forever). Bug fixes, performance issues, compatibility updates as data sources and systems change — all of it falls to you. There is no vendor support line. There is no product roadmap delivering improvements on a schedule. There is only your team.

 IT resources: Building requires developers. Maintaining requires developers. Evolving requires developers. Most companies that don't have software development as a core competency will find themselves either under-resourced or paying dearly for external support.

 Knowledge loss: If the software was built by a small team or a single passionate expert and that team turns over, the institutional knowledge walks out the door with them. Commercial vendors encode best practices from thousands of implementations. Custom builds encode the logic of whoever happened to be in the room when decisions were made.

 Security and compliance: This one is frequently invisible until it isn't. Custom-built software still needs to be deployed, maintained, and secured. The liability from inadequate security in homegrown systems is real and it sits entirely with the organization that built it. Commercial vendors have security teams, compliance certifications, and audit trails as table stakes. Your custom build starts from zero.

 The AI readiness gap: This is the hidden cost that didn't exist five years ago. As AI agents become the primary interface through which supply chain decisions get executed, your systems need to be composable, API-first, and capable of delegating authority to agents in a governed way. Commercial vendors are investing heavily in exactly this. A custom-built system creates a second, parallel engineering challenge: not just maintaining the application, but making it agent-ready — a capability that will need to be rebuilt from scratch as standards evolve.

 The compounding problem: Perhaps the most underappreciated risk —  using custom-built software to automate poor business processes doesn't fix the processes. It makes them faster and harder to change.  The spreadsheet your team can't get rid of? That's the mild version of this problem. 

‍

Be Bimodal — But Be Honest About Which Mode You're Really In 

There is a strong case for experimentation in supply chain technology — and a legitimate organizational structure to support it. Think of it as the samurai and the ninja. Every organization needs both. The samurai owns the core: stable, accountable, optimized. The ninja explores the edges: fast, experimental, unconstrained. But these roles only work when there's a clear boundary between them.

This concept is often known as the Bimodal approach — one mode focused on stable, reliable operations; the other actively experimenting and innovating. At its heart, it's the tension between reliability and agility, where the latter sometimes requires bending the rules. The danger isn't having both modes, but when they collapse into each other.

What's often missed is that the two modes are also interdependent. No organization survives long on only one. A company that understands bimodal IT gradually opens its Mode 1 systems to enable innovation, while Mode 2 experiments are eventually brought back into the fold — automated, industrialized, and absorbed into the core. The exchange between modes starts small and grows over time. The samurai and the ninja, it turns out, need each other.

 However, bimodal doesn’t necessarily mean building  production supply chain software from scratch in the name of "innovation."

‍

Know Your Organization Before You Decide

Every organization likes to believe it has the culture and capability to pull off what others couldn't. Supply chain leaders owe it to themselves and their companies to pressure-test that belief before making a build decision.

•  Risk appetite: How does your organization actually respond when a system fails or underdelivers? Is there genuine tolerance for the learning curve, or does the first outage trigger blame and retreat?
•  Change Agility: Has your organization demonstrated the ability to adopt and embed new technology successfully?
•  Innovation Posture: Is there executive commitment to fund and sustain a build initiative through the full lifecycle including the unglamorous years two, three, and four of maintenance?
• Software as a core competency: Be honest here. There are a handful of companies in the world whose primary competency is not software development that have successfully built their own supply chain software at scale. Are you actually one of them?  Amazon, Walmart, and Tesla as an example are the companies everyone talks about.  But they also have engineering organizations that most companies will never come close to replicating. 

‍

A Decision Framework for Leaders

When the build-vs-buy question comes to the table, here's a practical way to structure the conversation:

 Start with the Coverage: Does the commercial off the shelf software cover 80% or more of your functional requirements? If yes, buy it and invest in configuration and change management to close the remaining gap. The delta between 80% and 100% is almost never worth the cost and risk of building.

 Assess your maturity honestly: Are you seeking a system of record, differentiation, or innovation? Be rigorous. Most teams that believe they need advanced capabilities will find that these are already available in a system of record or system of differentiation.

 Ask whether your System of Record is AI-ready.  In 2026 and beyond, this question belongs in every vendor evaluation. Can your system of record go headless? Does it expose policy-aware APIs? Can AI agents execute within it with proper governance and audit trails? Does it help manage your token usage? 

 Run the full cost model: Include development, integration, maintenance, security, staffing, knowledge transfer, and AI readiness;  not just the initial build cost. Add a risk premium for timeline overrun (the rule of thumb is to double your estimate).

 Evaluate resource constraints: Do you have the IT capability to sustain this for 2 years? What happens if your key developers leave?

 Define competitive advantage: Will this software provide a defensible and quantifiable competitive edge that commercial solutions cannot replicate? 

 Apply the Build Test: Your organization wouldn't build (I hope) its own email server or web search platform. Apply the same logic. If the capability is available commercially, the question isn't whether you could build it — it's whether there's any reason you should.

‍

Resist the Temptation, Seize the Real Opportunity

The vibe-coding era has made it easier than ever to mistake the ability to build for a reason to build. Domain experts who can now turn their supply chain knowledge into working prototypes will feel — understandably — that they've found a new superpower. In some specific, bounded, experimental contexts, it might seem right, but without well defined processes and the right decision making framework, software that seems cool as a prototype is destined to fail under production use. 

The System of Record is no longer the boring back-office foundation — it is the control plane through which AI will execute supply chain decisions at scale. Getting that foundation right, choosing a vendor with the architecture and roadmap to support agentic AI, is one of the most consequential technology decisions a supply chain leader will make in the next three years.

The opportunity in this moment is real: AI is genuinely transforming what supply chains can do. But capturing that opportunity requires a foundation of reliable, integrated, well-governed platforms — not a collection of custom-built tools held together by the institutional knowledge of whoever happened to build them.

 Do experiment. Adopt commercially what the market has already solved. And reserve your scarce capacity for the problems that only your organization can solve.

‍