Interview with Naresh Jain, Founder & CEO of Specmatic — Executable Specifications, MCP, and a Harness for AI Agents

What problem were you seeing that led you to create Specmatic?

Naresh Jain

About seven years ago, I was advising a large conglomerate in India. They were a relatively young company, but they had scaled incredibly rapidly and were operating more than 40,000 microservices across telecom, retail, financial services, education, media and healthcare. In the early days, their teams could ship to production several times a day. But as the organisation and architecture grew, their ability to ship had slowed down dramatically. Their leadership invited me to help understand why.

I built a small utility called Engioscope to analyse their SDLC process, and one thing immediately stood out in the engineering metrics: change lead time was consuming almost two-thirds of their overall cycle time. In other words, requirements, design and development accounted for only about one-third of the time. Testing, packaging and getting those changes safely into production accounted for the remaining two-thirds. When we dug deeper, a significant part of that delay was integration testing. Teams would independently build their services, bring them together relatively late in the development lifecycle, and only then discover that their assumptions about the APIs didn't match. We were finding design issues, compatibility issues and misunderstandings between consumers and providers very late in the game, and this was proving to be very expensive.

This comes down to a structural difference between monoliths and microservices. In a monolith, the compiler catches function-call mismatches instantly. In microservices, calls cross process boundaries, so mismatches in API calls can only be figured out at integration time.

So the question became: how do we shift-left and get this feedback much earlier?

Contract testing was an obvious direction because it could decouple providers and consumers and allow them to develop and test independently. But when we evaluated the existing approaches, we ran into another problem: they required engineers to write and maintain a significant amount of additional test code. And at this scale, that wasn't a small concern. If adopting contract testing meant convincing thousands of engineers to learn a custom DSL and write and maintain another layer of test code, adoption itself would become the bottleneck. So we realised that whatever solution we built had to be no-code. Engineers shouldn't have to write contract tests. If they had already described the API in a specification, that should be enough.

There was also a more fundamental question: what is the source of truth? Is it the API specification, or is it the contract test code? Our view was that the API specification should be the contract. That led to the core idea behind Specmatic: if the specification is the contract between the provider and consumer, why not turn it into an executable contract?

Specmatic could take the API specification and automatically generate tests to verify that the provider actually conforms to it. From the exact same specification, it could create a wire-compatible mock that the consumer could develop and test against. There was no additional contract test code to write or maintain. Teams could adopt it using an artefact they already had, their API specification. That was extremely important because we weren't just trying to solve the technical problem; we needed a solution that could be adopted rapidly across a very large engineering organisation. Now the provider and consumer could work independently while still having a deterministic way of knowing that, when they later came together, they would be compatible.

That was really the genesis of Specmatic: turn the API specification from documentation into a no-code, executable contract, and move integration feedback from late in the delivery cycle to the earliest possible point.

What would you say makes Specmatic distinctive?

Naresh Jain

What makes Specmatic distinctive is really the philosophy we started with: the specification should be the source of truth, and that specification should be executable. We didn't want the API specification to be something you write for documentation, while the real intent and behaviour of the system is scattered across design documents, acceptance criteria, implementation code, tests and mocks. The moment you do that, you create multiple sources of truth, and over time they inevitably drift apart.

With Specmatic, we try to derive as much as possible directly from the specification. We can generate contract tests from it, create wire-compatible mocks, check backward compatibility, generate boundary-condition tests, and validate whether the implementation actually conforms to what was promised in the contract. And importantly, we wanted all of this to be no-code and deterministic. There is a lot of hard engineering involved in doing these things correctly. Our philosophy is that every individual development team shouldn't have to repeatedly solve the same problems or maintain additional test code. Specmatic should do that heavy lifting for them. Engineers describe the contract once, and Specmatic turns it into an executable engineering artefact that can be used throughout the development lifecycle.

Another thing that was very important to us was providing a unified experience across the different API and communication styles you find in a modern enterprise. A large organisation doesn't have only REST APIs. You might have REST and OpenAPI for one interaction, asynchronous messaging and event-driven architectures for another, gRPC for high-performance internal communication, GraphQL aggregating multiple services, and workflows spanning several of these interactions. We didn't think engineering teams should need a completely different approach every time the underlying protocol changes. So Specmatic is designed around the specification rather than any one protocol. Whether you're working with OpenAPI, AsyncAPI, GraphQL, gRPC or other specification standards, the fundamental idea remains the same: take the contract, make it executable, and use it to deterministically verify the system. That becomes particularly important at enterprise scale. You get a consistent engineering approach across a heterogeneous technology landscape rather than a collection of disconnected tools and practices.

What's particularly interesting today is that this philosophy has become even more relevant with AI and spec-driven development. As AI generates more of our implementation, people are increasingly asking: what is the source of truth that we give the AI? And once the AI has generated something, how do we deterministically establish that what it produced is actually correct? The industry is increasingly coming back to the specification as that source of truth. So in some ways, the fundamental idea behind Specmatic hasn't changed. What has changed is the environment around it. When more and more of the implementation is probabilistically generated, having a deterministic, executable specification becomes even more valuable.

What has the user feedback been like so far?

Naresh Jain

One of the most interesting things we've learned from working with enterprises is just how broad this problem space actually is.

We started Specmatic with a fairly specific problem: how do you decouple API consumers and providers and find integration issues much earlier? But as more organisations started using Specmatic, we began seeing how the same fundamental idea — having a well-defined, executable contract — could solve very different engineering problems.

For example, one customer was building a complex data pipeline with a series of Lambda functions transforming data at different stages. Individually, the components worked, but getting the entire pipeline to work coherently end-to-end was difficult. When we looked at the problem, we realised that every transformation step effectively had a contract with the next one. If those contracts could be explicitly captured using AsyncAPI and independently verified, you could reason about the pipeline much more deterministically instead of discovering incompatibilities only when everything was connected.

Another customer had almost the opposite problem. They defined a unified API that then had to be implemented independently by different regional and country-specific teams. Their challenge was ensuring that all of those implementations remained compatible with the same interface, while also having visibility across the organisation into which implementations were compliant and where the gaps were.

For another enterprise, the challenge wasn't primarily integration at all. They wanted to improve the quality of their APIs themselves, ensuring that their specifications followed certain organisational standards and were sufficiently complete and precise before those APIs propagated across the organisation. These experiences have really broadened our perspective on what Specmatic can become. We started by thinking about executable specifications primarily as a way to solve integration problems. What our users have shown us is that once you establish the specification as the source of truth, you can apply that same principle much more broadly to distributed systems, event-driven architectures, API quality, compatibility, governance and visibility across a large enterprise.

And that's been one of the most exciting parts of building Specmatic. The underlying principle has remained remarkably consistent, but the range of problems that principle can solve has turned out to be much larger than we originally imagined.

MCP is getting a lot of attention right now. How do you see the relationship between APIs and MCP evolving — is MCP essentially a wrapper over APIs, or something more?

Naresh Jain

Historically, when we designed APIs, we were really designing them for another human, a developer, to understand. That developer would read the API documentation or specification, understand the capabilities, and then write custom code to consume it. The actual client was relatively simple: it executed the behaviour that the developer had programmed into it.

With AI agents, that changes quite fundamentally. For the first time, the consumer of your API can itself be intelligent. It can discover capabilities, reason about which ones to use, combine them, and potentially use them in ways that the original API designer hadn't explicitly anticipated. That raises an interesting question. Do we now redesign all of our existing APIs for this new kind of consumer? Or do we introduce an abstraction layer that presents those existing capabilities to agents in a form that is more appropriate for them? I think MCP can play that role.

I don't necessarily see MCP as replacing APIs. In many cases, the underlying business capabilities will continue to be exposed through APIs. MCP provides an agent-oriented layer over those capabilities, potentially aggregating several APIs and presenting them as a smaller number of cohesive tools that are easier for an agent to discover, understand and use. There's another important aspect as well: not everything in an API should necessarily be exposed to an LLM or an agent. Your existing APIs may expose a very broad surface area because they were designed for trusted applications or internal systems. With an agent, you may want a much more intentional boundary. MCP can provide that abstraction layer where you expose only the capabilities and information that the agent actually needs, while hiding the underlying complexity and potentially sensitive or inappropriate operations behind that boundary.

So I see APIs and MCP coexisting. APIs remain the foundation for exposing business capabilities. MCP gives us a way to curate, aggregate and expose those capabilities to a new kind of consumer: an intelligent agent. And I think that distinction is important. MCP isn't interesting simply because it gives us another protocol. It's interesting because the nature of the client has changed.

How does the rise of AI-generated code and specs change the role of contracts — and how do you keep AI-written code honest against a spec?

Naresh Jain

I think there's a fascinating parallel with what happened during the industrialisation of other industries. Take textiles.

Originally, you had skilled weavers sitting at handlooms and crafting cloth. It produced beautiful results, but it obviously wasn't very scalable. Then came the power loom. Suddenly, we had machines capable of producing cloth at vastly greater speed. But there was a problem: people didn't completely trust the machines. So you still needed a person watching the loom, looking for a broken thread or a defect and stopping the machine when something went wrong. You had dramatically increased the productive capacity of the machine, but the human was still sitting inside the critical loop. That limited how much of the potential productivity gain you could actually realise.

I think we're at a very similar point in software development today. We now have incredibly powerful AI coding agents capable of generating vast amounts of code at extraordinary speed. But we don't yet completely trust what they produce. And certainly they have their limitations.

So what have we done? We've effectively put an engineer next to every AI coding agent, reviewing the code it generates and trying to determine whether it has done the right thing. We've dramatically increased the speed at which we can generate code, but we've made human review the new bottleneck. And I don't think that's going to scale.

This is where the history of Toyota becomes particularly interesting. One of Sakichi Toyoda's important innovations in the automatic loom was the ability for the machine to detect when something had gone wrong, such as a broken thread, and stop itself rather than continuing to manufacture defective cloth. That idea eventually became central to what we know as Jidoka: giving the machine the ability to detect abnormal conditions, stop, and bring a human in when human judgement is actually required. Along with ideas such as Andon and Poka-yoke, this allowed humans to move from constantly supervising machines to supervising a system that could increasingly supervise itself.

I think software engineering now needs the equivalent innovation for the AI era. AI coding agents are already extraordinarily capable. What they're missing is the harness around them, the guides and sensors that allow them to operate safely and autonomously at full speed.

API specifications, domain-specific examples, API catalogues and other contextual information can become the guides. They explicitly describe the intent, constraints and boundaries of the system we're asking the agent to build. Executable specifications (testing and mocking), linting, coverage and backward compatibility checks provide the sensors. They continuously give the agent deterministic feedback about whether what it has produced actually conforms to that intent. Once you have both, the development loop starts to change.

Instead of:

AI generates code → human reviews everything

we can move towards:

Specification guides the agent → agent generates → executable specification verifies → agent corrects itself → human is pulled in when judgement is genuinely required.

That distinction is very important to me.

We're not trying to put more barriers around AI. We're trying to build the harness that allows AI to operate with greater autonomy. And that's where I see Specmatic fitting into the AI-native development lifecycle.

Specmatic can turn specifications into executable contracts and provide the deterministic sensors for coding agents, verifying generated implementations against their contracts, checking compatibility, exercising boundary conditions and providing precise, deterministic feedback when something doesn't match. AI is inherently probabilistic, and that's one of its great strengths. It can explore, reason and generate solutions in ways that traditional software cannot. But to let that probabilistic engine operate autonomously, we need deterministic feedback around it.

That's why I think the next important step isn't simply making coding agents more intelligent. It's building better harnesses around them. In much the same way that Jidoka helped machines move from requiring constant human supervision towards autonomation, I believe executable specifications can help AI coding agents move from human-supervised generation to genuinely autonomous software engineering, pulling humans into the loop when their judgement is actually needed.

For teams adopting Specmatic for the first time, are there any tips or things to watch out for when getting started?

Naresh Jain

My biggest advice is: start small, but start with something real. Pick one critical business flow. Within that flow, identify one core service that several consumers depend on. Define the API specification for that service, use Specmatic to contract-test the provider, and then use the same specification to create a mock that at least one consumer can develop and test against. Get that entire loop running both locally on developers' machines and in CI. That's your first proof of concept.

Once teams experience the provider and consumer developing independently, with the specification sitting between them as an executable contract, they very quickly understand the value. From there, adoption becomes much easier. One thing I would strongly recommend is: don't wait for the perfect API or the perfect specification. We see teams getting into analysis paralysis, looking across hundreds or thousands of APIs and trying to decide which is the ideal candidate to start with. In my experience, it really doesn't matter that much. What's important is getting the first end-to-end loop working.

And if you don't have an API specification today, that's okay. Specmatic provides several ways to help you create one. For example, you can run Specmatic as a proxy, observe real API traffic and use that to generate a specification with relevant examples. You can import an existing Postman collection. Or you can use our AI skills to help derive a specification from the existing implementation. Similarly, if you already have a specification but its quality isn't where you want it to be, that shouldn't stop you either. You can use observed traffic or AI to enrich it. You can also use a coding agent together with Specmatic's MCP server to create a validation loop: improve the specification, execute it, identify what's incomplete or inconsistent, correct it, and repeat until you have a high-quality executable contract. So you don't have to already be practising spec-first development in order to get started. Specmatic can actually help you make the transition towards spec-first development.

The other advice I'd give is: don't try to boil the ocean. Go one API at a time. At the enterprise level, however, you do want visibility of the bigger picture. That's where we recommend using Specmatic Insights to capture the specifications across the organisation. That gives you an understanding of the overall API landscape and, importantly, lets you measure your progress as more APIs become covered by executable contracts.

So the pattern I'd recommend is very simple: Get visibility across the enterprise, but adopt incrementally. Start with one meaningful API. Make its specification executable. Contract-test the provider. Mock it for a consumer. Put the whole thing into CI. Once a team sees that working end-to-end, you've moved the conversation from explaining the idea to experiencing it.

What is Specmatic most focused on right now, and where do you see it heading next?

Naresh Jain

When we started Specmatic, our focus was relatively specific: make the API specification executable so that teams could get deterministic feedback much earlier in the development lifecycle to avoid late integration surprises. What we're working towards now is much broader. We want to take that idea of executability across the entire journey from business intent, through architecture and implementation, all the way to continuous governance. I think about that in several layers.

The first is what we call Executable Intent. Today, there is often a huge translation gap between what the business wants and what engineering eventually builds. Requirements get written in documents, interpreted by architects, translated into API designs, implemented by developers, and then validated much later.

We're working on something called Specmatic Genie that tries to dramatically shorten that loop. Imagine describing a business requirement in plain English and immediately entering a prototyping environment where you can explore the API design, generate specifications, simulate the APIs and actually interact with the proposed system before implementing it. I sometimes describe it as Figma for API design. Figma changed product design because you didn't have to build the application before people could experience and validate the interface. We want to bring something similar to APIs: make the intent tangible and executable early enough that business, product, architecture and engineering can validate whether we're building the right thing before we invest in building it.

But if the specification is going to become the source of truth, particularly if humans and AI agents are going to rely on it, then we also need to have confidence in the quality of the specification itself. That's another area we're investing heavily in. We're building a new generation of API linting capabilities. Traditional API linters are largely based on static rules: naming conventions, structural patterns, required fields and organisational style guidelines. Those things are useful, but they don't necessarily tell you whether the specification describes an API that will behave correctly in the real world.

We want to go much further. Because Specmatic can actually execute the specification, our linter can combine static analysis with dynamic, behavioural and runtime validation. We can reason about boundary conditions, constraints, examples, HTTP semantics, compatibility and other characteristics that only become apparent when you treat the specification as something executable. The goal isn't simply to tell you that your specification looks good. It's to give you confidence that the specification is semantically meaningful and executable, and to identify potential problems before the API meets the real world.

The next layer is Executable Architecture. An API rarely exists in isolation. A business capability may involve several APIs, services, events and interactions working together as a workflow. Using standards such as the Arazzo Specification, we can describe those workflows explicitly. Specmatic can then turn that architecture into something executable, creating mocks for the participating systems and generating tests that exercise the workflow against those mocks.

Before all of the individual services even exist, you can have the integration architecture running. That gives architects something very powerful: instead of reviewing an architecture primarily as diagrams and documents, we can actually execute it and validate our assumptions about how the pieces interact. Then, as the real APIs and services are implemented, they progressively replace the mocks. The same harness continues running throughout that journey, continuously telling us whether the implementation still conforms to the architecture we agreed upon. That helps us address something I think is a significant problem in large organisations: architectural drift.

Then comes the implementation itself, and this connects directly to what we discussed about AI. We increasingly see specifications and their surrounding context becoming the guides, while executable specifications and deterministic validation become the sensors. Together, these guides and sensors create a computational harness around AI coding agents. The specification guides the agent towards what needs to be built. Specmatic makes that specification executable, providing deterministic sensors that tell the agent whether what it generated is actually correct. The agent can generate, execute, receive feedback, correct itself and repeat that loop, pulling a human in when human judgement is genuinely required.

This is also where MCP becomes very interesting for us. Agents need access not just to APIs, but also to the engineering capabilities that allow them to understand, build and validate those APIs. Making Specmatic's capabilities available to coding agents through MCP allows those agents to participate directly in these deterministic feedback loops. And because modern enterprises don't operate on a single API protocol, we want this experience to remain consistent across OpenAPI, AsyncAPI, GraphQL, gRPC and other specification standards.

Finally, surrounding all of this is what I think of as Continuous Governance. As an organisation moves from executable intent, to executable architecture, to executable contracts and increasingly autonomous implementation, you need visibility across everything that's happening. That's the role of Specmatic Insights. Insights can continuously collect information from this engineering lifecycle and give organisations visibility across their API landscape: the quality and completeness of their specifications, API dependencies, coverage, compatibility, deprecation, adoption of spec-first practices and conformance with organisational policies.

Rather than governance being a review meeting or a gate that happens at the end, governance becomes continuous and evidence-based. You can start looking at aggregate API quality across an organisation, identify where the risks are, understand where architectural or contract drift is occurring, and establish policies that are continuously verified rather than periodically audited.

So when I think about where Specmatic is heading, I don't really think about it as simply adding more API testing features. The bigger vision is to make the software development lifecycle increasingly executable.

Executable Intent: can we experience and validate what we're proposing before we build it?

Executable Specifications: can we establish that the contract itself is high-quality, semantically meaningful and fit for execution?

Executable Architecture: can we run and validate how the system will work together before all the pieces exist?

Executable Contracts: can we continuously prove that every implementation honours what it promises?

AI Engineering Harness: can we give autonomous coding agents the guides and sensors they need to build and correct software with deterministic feedback?

And Continuous Governance: can the organisation continuously understand the quality, compatibility and evolution of its API ecosystem?

Increasingly, I think of Specmatic as a trust layer for AI-driven API engineering. AI is going to dramatically increase the speed at which we can design and generate software. But speed of generation isn't ultimately the problem we need to solve. As generation becomes cheaper and faster, confidence becomes the scarce resource. We need confidence that the intent has been correctly translated into the specification. Confidence that the specification itself is sound. Confidence that the architecture works. Confidence that the generated implementation conforms to its contracts. And confidence that all of this remains true as the system continuously evolves.

Some of our customers have started referring to this idea as confidence engineering, and I think that's a useful way of thinking about it. We're moving from an era where humans manually inspected software to establish confidence, towards one where confidence itself needs to be engineered into the development system. That's where I see Specmatic heading: the trust layer that provides the executable specifications, deterministic feedback and continuous visibility that humans and AI agents need to build and evolve complex software systems with confidence.