Intent is the New Syntax: Introducing the MarkDown Context Protocol
Software failures already cost $1.8T a year. Before AI multiplies that debt, we need a formalized way to capture context and intent.
We are in an era where agentic orchestrators like Google’s Antigravity, tools like Cursor Composer™, and frameworks like the BMAD Method™ are accelerating software execution to unprecedented speeds. But as Large Language Models (LLMs) get smarter at churning out code, they are exposing a massive hole remains in our industry: we are building without intent.
If you don’t record the purpose of a feature and explain to the end user why it solves a problem they face every day, you aren’t delivering value. You’re entertaining yourself with an expensive art project.
I’m an engineer. I build things that address actual problems. And right now, the industry is so hyper-focused on how to get work done with AI that we’re forgetting to ask the foundational question: Is this work worth the effort in the first place? Have we sized the problem? How does this solution compare to the way people are currently ignoring the issue?
The Trillion-Dollar Graveyard
According to a sobering analysis by Robert N. Charette in IEEE Spectrum (“The Trillion-Dollar Cost of IT’s Willful Ignorance”),
[T]he annual cost of operational software failures in the United States in 2022 alone was $1.81 trillion, with another $260 billion spent on software-development failures.
The root cause of this trillion-dollar problem traces directly back to a lack of documentation. Problems were solved in code but never made it back to a Product Requirements Document (PRD). Little quirks became load-bearing features—much like that infamous xkcd comic—that product managers and support specialists never knew existed. They eventually turned into obsolete legacy systems that require expensive specialists just to keep the lights on. We’ve all felt the pain of our favorite feature quietly disappearing from an app because it was an invisible solution to an unknown problem.
Now, ask yourself: If human developers are currently generating $1.8 trillion in software failures, imagine the graveyard we will build when AI allows us to write undocumented code 100 times faster.
The Rules of Documentation Have Changed
To survive this, we have to embrace cross-functional collaboration like never before. We must bring product managers, FinOps, support staff, sales and marketing, tech writers, system architects, and QA engineers to the absolute front of the line in this new era of software design.
All of these disciplines need to be in the room together. Companies that prematurely fire staff in the name of “AI efficiency” risk losing the critical human insights that actually make or break a business. And if you’re a small startup? You still need to explicitly execute and respect the functions of those roles, even if you are just starting out and wearing multiple hats, the functions of those roles must still be explicitly executed and respected.
The bottleneck in development is no longer the ability to regurgitate code syntax. The bottleneck is our ability to accurately architect the system and record the problems our software addresses. Your docs no longer need exhaustive code examples—the LLMs can generate those. Instead, your docs must capture:
Intent and Value: Why does this exist?
User Personas: Who is suffering without this?
System Realities: Is this a greenfield prototype, or a 30-year-old legacy system serving high-value clients?
The Next Step: Building the MDCP RFC
This is exactly why I am embarking on a new endeavor to formalize how we handle system context. As command centers like Antigravity begin leveraging standard protocols (like MCP) to execute complex knowledge work, we need an open standard like MDCP (MarkDown Context Protocol) to provide the proper contextual guardrails.
Ultimately, the goal for MDCP goes beyond just fixing documentation tech debt—it’s about restoring a healthy, collaborative engineering culture. It provides a formal, structured way to deliver context to both humans and computers. By doing so, it creates an environment where new hires and seasoned professionals actually need each other again. In this new era of AI, we must make space to educate younger professionals on system intent, while deeply respecting and retaining the hard-earned architectural wisdom of our veterans. MDCP ensures we can all contribute meaningfully to this new way of working together—learning exactly what is critical to document, and just as importantly, what to let go.
To do this right, it can’t just be a developer effort—it needs to be an industry-wide movement. Whether you are a product manager defining the “why,” a technical writer wrangling the “how,” a junior engineer trying to learn the ropes, or a seasoned architect tired of the tech debt cycle, your perspective is needed.
The first step in this journey is creating a formal RFC (Request for Comments) for the protocol, and I invite you to help me shape it. Here is how you can get involved:
Contribute to the RFC: Connect with me on the GitHub repo to help draft the standard.
Kick the tires: Try the early alpha CLI on NPM and give me your unvarnished feedback on the tool
npm install -D @bwilliamson/mdcp-cliShow support: Drop a ⭐ on the GitHub repo if you believe in the mission of building quality into our systems.
Spread the word: Share this article with your cross-functional teams to start the conversation about the importance of intent.
Sound off below: Drop a comment and let me know—how are you and your team handling the transition into this new era of AI coding?
Let’s ensure the future of agentic coding isn’t just generated faster—it’s designed with intent.
Disclaimer: All trademarks, logos, and brand names are the property of their respective owners. Mention of third-party tools, frameworks, and publications (such as Google’s Antigravity, Cursor Composer™, the BMAD Method™, and IEEE Spectrum) is for informational purposes only and does not imply partnership, sponsorship, or endorsement.