The Loudest Proof That SDD Works at Scale Is One Account, Not an Audit — Mercado Libre

Full case study of SDD adoption at Mercado Libre — what’s confirmed, what’s a lead, what’s missing, and how to read enterprise SDD evidence without naivety.

The loudest enterprise proof that Spec-Driven Development works at scale doesn’t come from an audit or from Mercado Libre’s official engineering blog. It comes from a single article by a single engineer.

This matters to everyone who needs to convince leadership to adopt a spec-first approach. Alan Julián de Angelis’s account of rolling out SDD across nearly 20,000 developers became the go-to reference in 2026 — cited as proof of enterprise scale — despite not containing a single audited outcome metric. Spec-Driven Development is a methodology where a structured specification is written and validated before any code, and the spec itself — not the code — is the primary expression of intent.

There’s one important detail about the source that changes how you should read it. “The Spec Is the New Code” isn’t a post on MELI’s engineering blog — it’s an X Premium article, published by an individual technical leader on a personal account. That distinction doesn’t disqualify the content. It determines how you cite it.

Over the next ten minutes, I’ll reconstruct this case study from public sources and show you what’s a hard fact, what’s only a lead, and what’s missing entirely — so you can apply the MELI pattern to your own organization without buying into the narrative.

Quick Win — The Core of This Story

Mercado Libre is today’s most-cited enterprise SDD example, but a careful reading of the sources changes the conclusion most people draw from it. What’s confirmed is one thing: scale. MELI has around 23,000 engineers and 30,000+ microservices, and one of its technical leaders publicly described rolling out SDD to nearly 20,000 developers, with over 5,000 having attended hands-on workshops (those last two numbers are the author’s self-reported figures). The scale figures come from credible, independent sources.

What’s missing is equally important: not a single audited outcome metric attributed specifically to the SDD framework — no before/after data for velocity, defects, or review time. MELI has announced operational AI-adoption metrics across the organization, but the claim that SDD specifically works at scale ultimately traces back to one author’s text. That doesn’t disqualify the story — it makes it more valuable as a lesson in reading evidence.

The strongest, most transferable takeaway from MELI is about process and culture, not tooling: adoption works when it’s a practice — a workshop on a real task — not a top-down decree. Before you transfer the “enterprise SDD case” to your own team, sort the information into three buckets: what the company says about itself, what independent sources confirm, and what’s only a lead. The rest of this article does exactly that with the MELI case.

Let’s start with the question everyone skips — why this particular organization became the face of SDD.

Why Mercado Libre

MELI’s scale isn’t a curiosity — it’s a causal mechanism. With hundreds of teams, a specification as a shared contract solves a coordination problem that smaller companies simply don’t have at this intensity. When you have over twenty thousand developers and 30,000 microservices, the biggest challenge isn’t writing code — it’s making sure everyone builds the same thing.

The scale numbers are well-documented, and it’s worth separating them from the numbers about SDD itself. Cat Wu (Head of Product, Claude Code, Anthropic) publicly mentioned at the Code with Claude conference in May 2026 that MELI has around 23,000 engineers — a figure confirmed by an independent live blog from someone present in the room. MELI’s SEC 10-K annual report for fiscal year 2025 (filed February 2026, data as of December 31, 2025, SEC EDGAR) reports 20,347 IT and product employees, who — per the same filing — generate approximately 30% of production code with AI involvement. That’s context, not proof of SDD’s effectiveness — but it’s precisely this context that makes the spec a shared contract.

MELI in numbers from public sources — the context that makes the spec a shared contract between teams.

The ground for spec-first was prepared by years of prior investment, not a sudden trend. MELI has long operated with an internal AI developer platform where developers often never see source code — a philosophy in which natural language is the central mode of work, and the human becomes a co-pilot to AI. That’s conceptually very close to SDD: the source of truth is intent expressed in language, not handwritten code.

The second layer of preparation was a code-sharing culture. MELI treats README and CONTRIBUTING files as mandatory artifacts — and yet, of 26,000 active repositories, only just over 200 achieved InnerSource-Ready status (Pablo Rivero, MELI official engineering blog, November 2024). That’s the same coordination problem SDD solves at the implementation level — and proof that adoption is hard even with institutional backing.

All of this sits on top of the IDP — the Internal Developer Platform, on which all microservices run and through which standards are enforced. That’s a critical detail for anyone thinking “I’ll just copy MELI.” An organization without that enforcement layer needs to build it first. MELI’s motivation wasn’t “we wanted a new process” — it was coordinating API contracts between teams across thousands of microservices.

With the foundation clear, let’s look at how the rollout actually unfolded — and whether it was a mandate or something else entirely.

Rolling Out to Twenty Thousand Developers

The most important rollout decision MELI made was cultural, not technical. Converting “overhead” into “advantage” happens in a workshop room, not in a policy document — and that’s the most transferable element of this entire story. They didn’t mandate that everyone write specs by decree. They ran workshops showing that it works, because people are convinced by experience, not by explanation.

The public trail of this rollout can be arranged on a timeline. It started with a community talk on SDD and Spec Kit (November 2025), continued through an article on an agent harness (February 2026), through “The Spec Is the New Code” and a mention at Code with Claude (May 2026). There’s one discrepancy worth flagging honestly: the original thread is dated March 2026, while the author’s page shows June 2026 — most likely the date of the last page modification, not publication.

The public trail of SDD adoption at MELI — with the disputed date on “The Spec Is the New Code” marked.

The rollout scale is stated directly by the author — and it’s his self-report, not an independently audited number. In his words: they’re introducing SDD to nearly 20,000 developers, with over 5,000 having participated in hands-on workshops so far. The mechanics of those workshops are what’s worth copying: a participant writes a spec, generates a plan, breaks it into tasks, and implements it with an agent — all in a single session. That experience drives adoption, not a policy email.

The author names two barriers explicitly. The first is habitual: developers are used to jumping straight into code, and writing a spec first feels like unnecessary overhead — until they see the result. The second is contextual: the methodology alone isn’t enough. The agent needs knowledge of internal tools, SDKs, and platform conventions — which is where the agent harness comes back in: a set of controls (rules, MCP servers, test loops, hooks) that shapes what the agent knows and how its work is validated. It’s like onboarding a new employee, but for AI.

Here’s a distinction that’s critical for accuracy. There’s no evidence of a formal adoption mandate at MELI — meaning a top-down organizational requirement to use SDD. The author describes it as a “progressive methodology,” a graduated practice, not a decree. The number of teams actually using SDD isn’t stated anywhere — that’s the biggest gap in the entire case study.

One more clarification that belongs at the top of any discussion about the author: Alan Julián de Angelis is not the same person as another MELI employee he’s sometimes conflated with in some roundups. These are two separate people; merging them is an error that corrupts all the rest of the analysis. The author of “The Spec Is the New Code” holds one specific title — GenAI Technical Leader — and authored one specific article, to which all the evidence trails lead.

With the scale and approach clear, the million-dollar question emerges — what results did this actually produce?

What’s Confirmed, What’s a Lead, What’s Missing

“Extraordinary claims require extraordinary evidence.” — Carl Sagan, astronomer

This is the heart of this case study. Separating the confirmed facts, the leads, and the missing data matters more than any individual number — because it’s what protects you from transferring unsupported conclusions to your own context. MELI is genuinely enormous and genuinely uses AI at scale. But “SDD works for us” is still one person’s word, without a single audited outcome number.

The cleanest approach is three buckets: confirmed, leads, missing.

In the confirmed bucket: scale numbers. Around 23,000 engineers and a target of “90% autonomous coding by Q3 2026” — both stated by Anthropic and confirmed by an independent live blog from the same event. Approximately 30% of production code generated with AI involvement, from the SEC filing (MELI 10-K FY2025). Microservice and deployment scale from multiple independent presentations. These are hard facts — but all of them describe the engineering organization generally, not SDD adoption specifically.

In the lead bucket — meaning signals that require hard confirmation, to be treated as a trail, not a fact — are several things circulating in the discourse as “proof.” The most frequently cited view count on the post appears in only one snapshot; two other sources don’t confirm it, because that platform’s metrics aren’t publicly accessible. There’s also a striking quote circulating about “SDD not being a trend” — most likely a misattribution, because a similar phrase comes from a completely different author’s text. De Angelis’s actual closing reads differently: “Vibe coding builds demos and MVPs. Spec Driven Development builds production systems.” A single community reaction sometimes cited as confirmation likewise remains unverified.

Source rigor in one image — what’s fact, what’s a lead, and what simply doesn’t exist about SDD at Mercado Libre.

In the missing bucket sits the most important thing in this entire story: there is not a single audited outcome metric attributed specifically to the SDD framework — no before/after for velocity, defect rate, review time, or the percentage of code regenerated from a spec. That caveat needs to be stated precisely. MELI has announced operational AI-adoption metrics — at Code with Claude, numbers were shared about agent-reviewed pull requests and modernized applications, and the SEC annual report mentions growth in merged contributions. But those are figures about AI adoption across the entire organization, announced by the company and its vendor, not an audited measurement of SDD’s effectiveness. Every claim that SDD specifically works at scale ultimately traces back to one author’s text — not to an independent measurement of that framework.

This is where you need to watch out for the temptation that distorts most MELI commentary. The scale numbers are confirmed; SDD effectiveness metrics don’t exist publicly. That is not the same as saying “MELI proved SDD works because it has 23,000 engineers.” Scale is not evidence of effectiveness.

Having a massive organization and massive AI adoption still leaves unanswered how much of that is SDD and what results it produced. Those two things live in separate buckets, and conflating them is exactly the error this article is meant to prevent.

The “90% autonomous coding” target itself is a textbook version of this trap. The target is confirmed, but the attribution is indirect — it comes from Anthropic, not directly from MELI. “Autonomous coding” isn’t necessarily the same as SDD. Autonomous code generation can mean AI writing code without any structured specification. The relationship between that target and the SDD framework is unconfirmed — these could be two different processes easily collapsed into one marketing sentence.

With a clear picture of what we actually know, it’s worth seeing how MELI does it — because the process is better documented than the results.

Process, Tools, and Agent Harness

MELI’s process is better confirmed than its outcomes, because the author described it directly — and that reveals the most important thing for anyone who wants to replicate it: SDD is a methodology, not a product. What’s transferable is the discipline, not any specific tool. First, you write what needs to be built and how; then, you break it into small tasks, and AI implements them one at a time. The secret is giving the agent context about your organization.

The process has four steps: Specify, Plan, Tasks, Implement. The spec is the “functional layer” — it describes what a feature does, not how it’s implemented, and it’s deliberately technology-agnostic. Separating “what” from “how” reduces model uncertainty. Acceptance criteria are written in the Given/When/Then format — a structured representation of a precondition, an event, and an expected outcome — and they simultaneously become the test plan. This isn’t documentation for decoration; it’s an executable contract.

The four-step SDD process described by MELI — and the harness without which, according to the author, the methodology alone isn’t enough.

There’s one piece of advice here that sounds counterintuitive but is the strongest in the entire description. The author recommends letting the agent write the specifications too — because it’s easier to correct a generated spec than to write one from scratch. That shifts the human role from document author to intent editor, which is exactly what large-scale work demands.

The heart of the effectiveness, though, isn’t the process — it’s the harness around it: four context levers. First: custom rules, rule files kept concise, under a few hundred lines. Second: MCP servers connecting the agent to internal systems. Third: feedback loops — tests, linters, type checks. Fourth: hooks, led by a Stop hook that the agent simply cannot bypass until the checks pass.

Those four levers, not the methodology itself, make the difference in an organization. Each one requires knowledge of internal conventions — and that’s precisely why you can’t copy MELI by copying only the process. Without a harness tailored to your SDK and standards, the agent doesn’t know what it’s building.

It’s worth knowing the industry taxonomy of three spec maturity levels, because it organizes the whole discussion. At the spec-first level, you write the spec, then build it, and the code remains a maintained artifact. At the spec-anchored level, the spec lives in the repo alongside the code and evolves with it. At the spec-as-source level, the spec is the source, and the code is a regenerated, disposable output — you change the spec, not the code. MELI aims higher, but there’s no evidence it has reached spec-as-source at scale — it’s still described as the frontier of the experiment, not an established state.

The cost is stated directly — and that’s part of an honest picture too. According to de Angelis, a full SDD session can consume two to three times more tokens than standard agent prompting — this is his own observation, without a published measurement methodology. SDD isn’t free. It pays off at the level of complexity where ambiguity would derail an agent — not for a minor bug fix. As for specific tooling: Spec Kit and the built-in Plan mode both exist in the ecosystem, but which exact variant MELI uses internally hasn’t been confirmed.

With the process and its cost understood, the most important question for the reader remains — what transfers to your context, and what stays with MELI.

What You Can Take Away, and What You Can’t

The most valuable lesson from MELI is about process and culture, not tooling. Take MELI’s mindset — the spec as a shared language and adoption through practice — not their size. Your company almost certainly doesn’t have twenty-some thousand engineers or a proprietary AI platform. An honest assessment of what’s transferable matters more here than enthusiasm about the scale.

On the transferable side, four things stand out. First: adoption as practice — a workshop on a real task, where the team runs the full loop of spec → plan → tasks → implementation in a single session. Second: the spec as a coordinator for distributed teams; the API-first pattern has confirmed precedents for reducing cycle time in organizations working with multiple independent services.

Third: graduation over decree — pilot, formalize, iterate, scale. Fourth, and in my view the strongest: shifting the review question from “Is this code good?” to “Should this code exist?” That attention shift from form to intent is free and works in a team of any size.

The decision filter — what to take from the MELI case study, and what to leave as context that can’t be copied.

On the MELI-specific side: things you can’t copy by decree. The inter-team coordination scale — most companies simply don’t have hundreds of teams clashing on API contracts. The IDP layer that centrally enforces standards. A proprietary AI platform instead of plugging in an off-the-shelf tool.

The eighteen-country, multilingual context that changes what a “shared language” in a spec even requires. These aren’t insurmountable obstacles — they’re layers MELI had ready, and that you’ll need to build or replace.

There’s also a warning written into the story itself. Enterprise mandates often end with the spec becoming bureaucracy — another document nobody reads. MELI’s own example with code-sharing culture — just 200+ of 26,000 active repositories achieving InnerSource-Ready status — shows adoption is hard even with full institutional backing. If someone with a large organization convinces themselves that “announcing SDD will be enough,” that one metric should sober them up.

Hence the honest perspective that closes this section. Without audited metrics, treat MELI as a process pattern to test in your own context, not as a proven return on investment. That distinction isn’t pedantry. The difference between “test this pattern” and “this has a proven ROI” determines how much political capital you’ll stake on the rollout before you see your own first numbers.

What remains is to close out the trajectory — what MELI signals next, and what that says about the direction of SDD as a whole.

Summary

MELI’s trajectory points toward increasing agent autonomy. The publicly signaled target of “90% autonomous coding” by Q3 2026 and the partnership with a model vendor point toward agentic SDD, where the spec becomes an orchestration layer for multiple agents. There are two caveats that bear repeating: that target is attributed indirectly, and “autonomous coding” isn’t necessarily the same thing as the SDD framework. The most durable lesson from this story, however, isn’t about MELI — it’s about reading evidence.

Practical takeaways for Monday morning:

• MELI’s scale is confirmed; SDD outcome metrics are not. Scale is not evidence of effectiveness — don’t conflate them.
• Roll out spec-first through a workshop on a real task, not a policy email. It’s the strongest transferable element.
• Invest in an agent harness with context from your own tools — because according to de Angelis, the methodology alone isn’t enough, and the cost is two to three times higher than direct prompting (de Angelis’s observation; no published measurement methodology).
• The spec as a single source of truth solves coordination across hundreds of teams — the value scales with the degree of distribution, not with trends.
• Before citing any enterprise SDD case, separate the information into three buckets: confirmed, lead, missing. It’s a ready-made template for any architecture review.

Thank you for making it this far — because source rigor makes for unglamorous reading, and you chose it over a headline. If this article changed how you read enterprise evidence, share it with someone who’s currently trying to convince leadership using numbers from a single post. And if you want to go deeper into the economics of SDD and when the higher token cost actually pays off, I’ve written about that separately.