Before You Build Apps with AI, Watch This (Spec Driven Development)

To our surprise, in this AI-driven world where code is now democratized, the requirements, schemas, configurations actually become the product.

It's no longer code.

Code sort of becomes a very shallow projection of your requirements.

Now, what normally happens with wipe coding is that you go through this process of, you know, multiple prompts to get to what you want to actually build.

This is where specware takes a different approach because on specware, each sort of requirement is a modular entity within itself.

I think this was the year of vibe coding.

And I think 2026 is probably the year of spec-driven development.

It already is changing everything about how we're using AI to build code now.

Because...

Hey, everyone. Today with me are the boys from SpecVIA, Paul and Jake.

SpecVIA is a spec-driven development platform to help engineers and soon solopreneurs like us to work with specifications as we vibe code.

What does that mean?

It means having a whole master list of tasks, of specifications, that your AI can follow so it doesn't get lost, so it doesn't just create a big, jumbly mess, which I have experienced many times before.

I'm sure you have to if you've tried to create apps without actually knowing how to code, but you see the power of AI and so you try to develop something and then it turns into a big mess.

Specifications solves this problem.

And Jake and Paul are going to walk us through the platform right now, today, and show us how this problem can be solved with spec-driven development.

Thanks for joining us, guys.

Thank you for having us, Jordan.

It's a pleasure.

I think you've nailed the introduction.

So just a bit of background.

So I come from the automotive world where specification has been driving product development for decades.

To our surprise, we started looking at agentic coding and using some of these agents to help us with the day-to-day software development.

And we saw the rise in spec-driven development in wipe coding, essentially.

And there was a lot of synergy between both the worlds, and that's where we started piecing the best of both worlds, where we come from a very spec-heavy world into bridging that over to today's agentic or wipe coding, where relying on specifications gives a lot of structure to how you develop an application.

Before we move any further, can you explain what is a specification?

What are specifications?

You said it's big in the automotive industry.

Can you explain it as simply as possible?

Specification is essentially a set of instructions on how something should be built.

And now if you contrast this to just using PROMs with your agent or your model to actually generate code, it is, in all essence, exactly the same bit, where you would be writing down a set of instructions on how to build a product.

So this, in its essence, is a specification.

Now, what normally happens with wipe coding is that you go through this process of multiple PROMs to get to what you want to actually build, and you get lost in this maze of a lot of old PROMs that you've been using to actually build your product.

And this is where specification management comes into play, where you need to now structure your set of requirements and then start building on that set of requirements to actually eventually scale and get to production with your application.

So if you have a large project, if you see on the left side, these are all the individual parts of your project, like the authentication flow, the purchase flow, card system, discounting.

So your large project is broken down into these smaller components, and we store the requirements for each of these components as such.

So when you plug into your development environment, like Claude, or we have a cursor, or any of those things, it will pull in the context from this.

So you don't have to repeat the whole gist of what you build, what is to be built, and all this.

All the context is stored in a structured manner.

So that's what specifications or specification management does.

Managed is all your requirements and specifications in one place.

Now, typically, what you normally sort of experience or you would be experiencing with spectrum and development is the fact that your agent will start creating a bunch of readme files with documentation on what it's trying to build, the planning process with each of these agents on how it's sort of trying to solve a problem that you've given it in the form of a prompt.

The issue with that is the fact that you end up with a lot of multiple readme documents, which is hard to keep track on, and then you start losing modularity because each of those design decisions or instructions gets lost in a maze of large documents.

Now, this is where spec via takes a different approach because on spec via, each sort of requirement is a modular entity within itself.

Now, which means finding a requirement, searching for a requirement, or for an agent to find the relevant context for the required prompt that you sort of given it to build something becomes very, very easy and powerful.

Think of it like a memory layer, right, for your agent or agent decoding platforms. Of course, yeah.

And I noticed like Cloud Code, even Roo code, especially Agent Zero, they all have their own techniques for managing memory.

So Cloud Code, around 75% of its context window, it starts to summarize the conversation to pass it on to a new one.

And that's just a basic markdown file explaining what's been done.

And you can do similar cursor rules inside of cursor for whichever agent or whichever model you're using.

And then Agent Zero has its own persistent memory mechanism.

I'm not sure exactly how that works.

But what I think is interesting about this is this is primary...

This is made for code bases.

And I use other agents for knowledge bases, for my business, for creating business assets, things like that.

So the memory, it's important to have context for its task, for what it's building.

But its memory doesn't necessarily need to be super comprehensive.

And it's the same with code essentially too.

Like you just need write, like whichever components are related, then the AI needs to have an idea of those related components.

So it doesn't break anything while it's coding or while it's fixing code, for example, right?

But what this system shows us is the whole code base, all the specs for everything, and then you can kind of zoom in to each little thing as you're building.

And I haven't tried this yet, but it looks like I might not even really need to zoom in personally.

My AI agent will just take care of it.

It has the list. It knows the specs.

It knows what to do, what to be careful of.

And I think that's going to be...

That's going to completely change the game with vibe coding.

It already is changing everything about how we're using AI to build code now, because this year, I mean, we're doing this at the end of 2025, and I think this was the year of vibe coding.

And I think 2026 is probably the year of spec-driven development where we finally fix vibe coding.

Absolutely.

So if you look at our manifesto, Paul, if you can just sort of scroll to the left there.

So this is sort of like a manifesto for spec-fear.

Now, what we envision is that in this AI-driven world of where code is now democratized, the requirements, schemas, configurations actually become the product.

Now, if you contrast this to any sort of popular application that people might be using or want to replicate, it is the requirements of that product that makes it unique.

It's no longer code.

Code sort of becomes a very shallow projection of your requirements itself.

So that's the bet that we are taking with spec-fear, that as product evolves, the complexity needs to be contained, and that's where spec-fear sort of helps in the whole vibe coding experience by ensuring that your requirements are captured.

And as you start building the product, the product doesn't end up breaking itself, but then it's sort of structured and layered over each other as you start building out features.

And like Jake said, code is a projection of the specification.

So technically, once you have your requirements written down, all the logics are set.

You can even change the code base.

If you want to change the technology, library, all of that is not that hard for you to do it.

What did you say?

OK, so you said code is a reflection of the specifications, and then specifications are a reflection of the requirements.

Or how did you put it, Jake?

Code is just a projection of your requirements themselves.

A projection of the requirements.

So it's very important that as you start building stuff, obviously, in code, you start capturing those requirements in a structured format.

And how much of those requirements are thought out beforehand?

So for example, Kenneth Gonzalez and I, we've done a lot of workshops on product requirements documents, for example, feature requirements documents.

And typically speaking, in an enterprise environment, you would really try to understand everything.

I'm sure this is the same in the automotive industry, is what is every little feature of this car?

How does the door open?

What is the handle?

Every little part of the user experience needs to be thought out.

And they figure that out before they start creating the car.

Before manufacturing begins, every little detail is fixed.

In your opinion, when we're vibe coding with code now, not building cars, how much of these requirements should be figured out right away, versus they're figured out as you build with AI?

That's a very, very good question.

Because with AI, you get unlimited endless possibilities of how you start building a feature.

Because as these models mature-- and I love the new Claude models that have come out, the Opus.

You just need to sort of-- it's incredible.

It's mind-blowing.

Because you just need to give it a hint on what you're trying to build.

And then it starts sort of imagining how the feature should be presented to the user, things about usability, how the UI should be presented.

Now, the caveat here that we're trying to highlight with specVIA is the fact that these models start making a lot of assumptions that you might want to intervene on.

And the only way to do that is if you give these models, who's writing code, access to start documenting these requirements or assumptions that it's taking in order to meet your high-level user requirement?

Now, is it always required?

Probably not.

But as you start building it, you'll start seeing that the lower layers of a user requirement start becoming more and more relevant.

A good example is the fact that-- I think Paul highlighted technology, for instance, that you might start off building your application and come across a piece of technology that you're really interested in doing.

Let's say caching, how caching works in your application or how users are logging into your application for a simple example.

You might find an alternate technology on how people want to log in.

Now, you might be curious on how your product actually handles logging in.

And that's why specVIA now becomes very powerful, because you can go into specVIA and figure out how your product was built in terms of logging, and then prompt your way into upgrading that into the latest technology without actually breaking down the whole application.

So maybe that's a good segue into our demo with the magic mirror repo.

So in this case, it's not our project, but it's an open source project that we can import the code base into specVIA, and you can show us what happens.

So for the sake of a demonstration, we've chosen a popular open source project from GitHub called Magic Mirror.

Now, we chose this project because it's a good blend of hardware and software for people who would be interested in a bit of hardware as well.

So this project-- it's a really good one, actually-- quite an impressive project where you can sort of flush your program onto a Raspberry Pi, which just runs on Node.js, and you get to sort of attach a display behind a mirror, and then that makes it sort of like a magic mirror with stuff like weather

being displayed, and so on.

So what we thought was people would want to innovate from here.

Like when you're starting a project, let's say someone wants to build a magic mirror, but then add more features to it to sort of make it more relevant to their use case.

Real quick, Jake, sorry to interrupt.

I'm just going to show it real quick so it's not as ephemeral of an idea.

But this is like-- it's a smart mirror.

So imagine that you're looking at this stuff, these little widgets, in the mirror while you're getting dressed.

I think there's a picture here somewhere, yeah.

So it's a fascinating implementation of AI and having an assistant in your home.

So that's the project we're using as a demo here, folks.

OK, so it's clear.

Sorry, you're going to have to share your screen again.

So this is sort of what we consider as a starting point in certain cases.

You might want to start off with your existing code base, or you want to start off forking another repository.

That's the sort of demonstration that we're trying to show.

Now, the bit here that is interesting or where specular makes a big difference is the fact that if you were to take this project and you want to start to build on top of it, you've got two options.

One is get yourselves familiarized with the project.

You could use a model to actually create a database out of this whole thing and then start asking questions to do so.

Or the specular way of working would be that you import this whole project into specular, and then you start basically analyzing the requirements from there on and start building your product from there on.

So this is what a typical workspace in specular would look like.

You start off with different workspaces.

So I've created one for AI captains for the purpose of this demonstration.

Now, I've already imported the project.

But essentially what you get is that once you open up your project, you get a structured, documented requirements imported from your code base.

So for instance, you can sort of already see how it's structured the whole project, starting from user requirements down to system architecture and all the way down to the nitty-bitty bits of how the communication protocol is set up, what are the API calls that are being made.

So the depth really goes all the way from high-level user requirements all the way down to how it's actually implemented via code based on what the user is interested in.

And Specfia just does that.

You import the code base and it just does that.

Right. It just does that.

Wow.

So your starting point becomes very easy, right?

So in here, you can sort of see that in the Magic Mirror project, it supports multi-language support.

Now, think of yourself having to understand that it supports multiple language from a code base as compared to importing the requirements into Specfia, where things are very clear to you.

And this is the sort of difference that we are trying to make into spectrum and development by means of Specfia.

Now, benefits actually doesn't stop here because what you then get is the fact that you, Specfia has this mechanism that we call dynamic traceability.

And dynamic traceability is a method by which requirements are not just structured into a tree-like structure that you see on the left, but it also allows for linkages between requirements on multiple tiers.

Linkages between requirements on multiple tiers.

Right. I know that sounds...

Digesting that.

Okay. And that's dynamic traceability.

And is that what's over there? Yeah.

Okay. So show us. Yeah.

Right. So let's look at an example, right?

So you see that on a user level, there's a requirement to support multi-language support.

Now, if you're curious about it, you can use the traceability to understand how this now translates into your code system.

Now, traceability essentially means you have an upstream and a downstream.

So upstream normally signifies what is the cause for a given requirement, and downstream sort of implies what is the effect of having a requirement in place.

The interesting bit that I want to highlight here is the fact that traceability, if you look at any typical application lifecycle management tools out there, is something that is manually linked and set up just to show the traceability of, "Hey, I had a requirement here. This is

how it's implemented in the code.

This is how it's tested," and so on.

To spec, we are automatically doing it for you.

A good instance here is multi-language support on the high level.

User wants to be able to change language.

But now how is it implemented is shown by this downstream requirement, which is a module called the translation system.

If you click on this requirement, it then takes you to that requirement that actually specifies how is that translation system implemented.

Then you start seeing that there is a module called translation system that is implemented in so-and-so place in the code base, how the translation file format is imported, the nativity details of how it is actually implemented.

The way we're using Magic Mirror right now, we're reverse engineering it in a way.

Yes.

Your platform also allows for normal engineering it, not backwards.

Exactly.

It allows for.

You can build it and round up, or you can take some vibe-coded slop you made, and import it in here and see if it's salvageable.

That's how you should market spec via.

Fix your vibe-coded slop.

[LAUGHTER] The reason why we took this approach into the demo is because we've seen 99 percentage of our users not starting from scratch.

Because in this day and age where so many libraries and projects are available, not always do you actually want to start from scratch.

It might just be a code base that you vibe-coded it, and now you want to switch to spec-driven development.

Right.

That's the reason why we took this path into the demo, you've got a project, but maybe you're running into complexities on how you're scaling that application, but then here's maybe how you switch to spec via with it.

There's other alternatives for spec-driven development, and a lot of you have competitors popping up everywhere.

I've used one of them called BrainGrid.

Pretty good experience, but the user interface was a little confusing for me.

But then almost more importantly, there's some open source specification CLI tools, which in theory work really well, but I was having trouble with those too.

What I like about what I see with spec via is just how straightforward and simple it is.

The interface is very clean, and that's what I have not seen yet.

I don't really believe in interfaces anymore.

I think we're seeing the end of the interface.

The interface will just become a chatbot or a neural link, and just removing interface between humans and technology.

But there is still a really important use case for interfaces if they're good.

This is the first spec-driven development interface I've seen that I feel like I could actually maybe work with as a non-engineer.

I just wanted to say that.

You guys have figured out a way to visualize all of this, which is not an easy task.

I think that's really what the struggle of spec-driven development has been for the last couple of months.

It's like, how do we make it user-friendly?

I think we put an intentional effort to make sure that it's not just a chat-based system.

Because the issue with chat-based system is that you will only get so far as getting some cues on what you're after.

The rest of the exploration actually happens if you've got a really good UI.

For instance, the traceability system, you could ask it like if spec-ware was redesigned as just a chat interface, you need to actually know that there's something called traceability to actually figure out there is that path that you can take to understand your project, rather than surfacing that as a relevant action to the user to then understand that, "Hey, you know what?

You've got this requirement, but then this is coming from so-and-so requirement that is derived from where it's actually derived from."

Right. Sorry, Paul. I

cut you off earlier.

Yeah, no. Like you said, this is an interface for you to conversate with the agent.

We are not using a textual approach, just a textual approach, but it's multimodal.

There's comments flying in, there is this relationship mapping in all coming in.

But what I want to chime in on was the dynamic traceability bit.

So when you're having a project, sometimes when you change something somewhere, something else breaks somewhere else.

So that is a big challenge that the dynamic traceability bit will solve for.

So if you're making a certain change here, it will say with all sections that you need to check to ensure there's nothing breaking or something.

So it shows the relationship like that.

And that is not just beneficial for the human, but also the agent.

If the agent is also making any changes, it'll be like, "Okay, let me check this upstream issue, upstream modules and these downstream modules, see if it's all aligned well."

And that's the benefit of dynamic traceability.

Just to add on to what Paul just mentioned, collaboration is another feature that we give a lot of priority for when building spec via.

Because we think even if you've sort of vibe coded your initial application, there is a point at a time where you start bringing in people to sort of collaborate on your project.

So a good example here is the fact that you can sort of comment on requirements, but in spec via, you can also define agents who also become your co-worker in some essence to sort of work on your requirements and flag issues and conflicts for you.

So here is just an example that I sort of opened up to say, "This is a totally different project, but I've got an agent in there who is sort of like an architecture specialist, who I can then just chime in and ask questions about certain parts of my requirement to sort of say, what do you think about something of this sort?

And is there something else that I need to consider when writing a requirement like this or considering this for further development?"

And that's just a comment thread in the middle of a specification.

Exactly.

With an AI.

Yep.

We don't discriminate between AI or a human.

Everyone is given the equal amount of power, unless you don't.

I mean, that's just, it strikes me like, I've been building a notion workspace recently for this new course we're doing on AI Captain, then a human collaborator I'm working with, and comments, and what is our system for comments, and figuring all that out.

And so seeing an AI agent just in the comments, it's kind of, I don't know why it's mind-blowing me right now, because I use AI all day, every day to build things, but I never really see AI in the comments.

So, I mean, this is an example of how we thought chat cannot be just the interface, even though you see a lot of applications these stages going chat-native.

We think it has to have a perfect balance between AI that's built for agentic experience, of course, along with the chat, right?

We're not saying there's no chat, but we think chat alone doesn't suffice.

Another cool feature that I think I wanted to highlight is the fact that diagrams right?

Like humans understand a lot more better with diagrams than actually having to read a lot of requirements.

Yeah.

Like we actually have this feature where you could just, you know, select a bunch of text and then just generate a diagram out of it.

Is it a mermaid diagram?

Not right now.

So we're using something called UML, which is, you know, coming again from where our industry is.

And those like suck to make on your own.

So it's cool that the AI can just make it.

Yeah, it just makes, you know, understanding the requirements so much more easier.

And then just the fact that you could just, you know, select a bunch of text and generate a diagram out of it to better understand what it's sort of talking about.

Wow, this is exciting.

This makes me want to build an app again.

I gave up because I never could get up to work.

This makes me want to try again.

I just don't have the time.

Well, OK, so we see the specifications.

We can make diagrams. We can chat with AI agents.

You can see the downstream upstream relations.

Are there any I guess you closed your window.

So I guess that's all the main features.

I was going to ask, is there anything else in that interface that's worth showing us?

The reports.

Oh, yeah, the MCP.

Yeah, let's look at that.

Yeah, I thought this is right.

OK, so we have that's how it works on the interface for the specs.

Now, how does it work when we're actually building and biodecoding?

Right.

So the key feature, let's say, let's put it that way where spec via now comes down into sort of where you're building your application is via our own MCP interface.

Right.

So this actually changes how spec we actually now becomes part of your day to day development experience.

So here's an example where I just integrated spec via MCP into my VS code GitHub co-pilot.

And this is sort of how I started with magic mirror.

So I told my coding agent that I want to derive requirements from this, but then I want to put that into spec via.

I wanted my co-pilot who's aware of the code to now ingest these requirements into spec via by means of an MCP integration.

So it's just worth mentioning that MCP on spec via works both directions.

So you could bring whatever other application that you're using with MCP into spec via, and then do stuff in spec via with integration to whichever other application you're using.

Or you can do it the other way where spec via now becomes a tool into your biodecoding agent or whatever other agent that you might be using to build your project.

So in here, it's GitHub co-pilot.

I've instructed GitHub co-pilot now to ingest data into spec via.

And you sort of start seeing-- VIA MCP server.

VIA MCP server.

So then you sort of start seeing how then it starts creating folders to sort of arrange requirements and all the way down to adding requirements that you then now just saw on the front end.

Now, this is only one instance of how spec via MCP server becomes useful or powerful.

The other instance is where you want to now do further development from here on.

So in this example, you can see me asking, you know, I'm just curious, what are the external APIs that are being used in the magic mirror project?

And do they actually have a requirement in spec via?

And immediately you can sort of see that your coding agent now starts searching in spec via to see, you know, well, are there any APIs that are being used?

And then it sort of eventually found that the requirements are actually not logged, but in the code base, it sees all of these API being used.

And it immediately proceeds to say that there are some requirements that sort of hint it, but not clearly recommended.

And then immediately you can sort of it'll ask you, like, should I create these as assumption requirements in spec via?

And then boom, you get those requirements also documented in spec via.

It works in the other way as well, where you sort of created a requirement.

So in this other example that I'm going to show you is where I added a requirement into spec via.

And then all I need to do is come in and say, implement the weather app UI as per the new requirement to follow Apple style UI and spec via immediately then searches spec or your GitHub co-pilot immediately searches spec via finds the requirement to do so.

And then, you know, starts building it out systematically.

Instead of me having to sort of throw in a few words in as a prom, you get to now think about how it should function, document that, pass that on to your coding agent to start building.

How would you start a new project on spec via?

Would you upload a PRD?

Great question again.

So spec via has the facility where you can just import a PDF file or any sort of format that you want.

It will again chunk it down intelligently into requirements.

And that is a way you could start going about.

Another sort of way is that say you just have an idea, but then you don't have an expanded version of it.

You can use agents within spec via to start building out a set of requirements for you to then analyze and decide to go further.

All the third option is what we saw in the demo is that you start with an existing code base, import all of that code base in as requirements into spec via and then start your development from there on.

So imagine if I was more comfortable with on VS code, right?

And I wanted to just use cloud code to scaffold a new project.

After I've begun that project, could I say, okay, now you spec via MCP and let's start creating the requirements.

Exactly.

Exactly.

So I could like get it going first.

And then I guess that's just importing an existing code base, right?

Correct.

Because that's why I think I mentioned before, right?

Ninety nine percent of our users, what we've seen is that they never start from scratch on specification.

Or maybe this is a better way to explain it.

Prototyping is key to actually any product development.

You want to sort of prototype and see how it feels.

Does it have the right levers for what you are envisioning as a project?

And there is a turning point where you stop prototyping and then start productionizing.

And that is sort of where the investment into specifications start paying off, not really in your prototyping phase where you're just trying different things.

Does this work?

Is this a cool thing to have?

Would I enjoy using it?

That this is the sort of prototyping phase.

And then as you start moving into production, that's where you now want to document how you've done things and then want to perfect that application user experience.

Right right.

Wow.

Super cool.

Well, thanks for the introduction.

Thanks for showing us.

I mean, you not only showed us Speckvia, but you explained how Speckvia development works very well.

And I think a lot of people like me who have given up might now decide to try again.

Could you, what is the future of the Speckvia platform?

When can people expect to be able to use it?

So we are launching.

So I mean, if you look at the tools that are currently available out there for requirement management, there is no free software to actually build requirements out of.

So a core belief or a core value that we carry with inspect, we have the fact that requirement management should, is something that should be democratized.

Someone should have access to managing requirements because that is not where the real value outcomes.

So on Speckvia, we have a free tier that allows for anyone to sort of manage requirements, including the MCP server.

Where we see this going or are not star is agents, right?

Now as you start building out an application as a solopreneur and so on, you start seeing the need for certain roles such as configuration manager, your cybersecurity analyst and so on sort of popping up.

And that is the sort of, let's say the paid tier on Speckvia, where you get to now define agents to work alongside you.

How this would work if I were to sort of draw a picture is the fact that you as a person building the product is focused on features.

But there are certain bits like cybersecurity that you want someone to sort of watch over the project, intervene where required, make changes or suggest changes, flag changes, for instance.

Those are actually agents, which is the only paid tier for Speckvia.

So if you need a project manager of your own or a cybersecurity analyst of your own, that's where you then start deploying agents on Speckvia to actually help you scale your product more than just a hobby into something that's production ready and being collaborated with by different stakeholders that is normally seen with companies of that scale or for products of that scale.

And these are like predefined agents that Speckvia has already created vetted give the tools, et cetera.

So you sort of get a template of these roles because some of these are need to come with specialized knowledges and so on.

But we think every sort of team or company has their own workflow that they sort of prefer.

So these agents are customizable to your liking, to your workflows, to your means of intervention and so on.

So these templates help people get a quick start into having agents and sort of seeing how you collaborate with them.

But they are fully customizable in terms of tools that it gets access to, capabilities that it gets access to, customized knowledge basis for these agents.

Like in the case of the cybersecurity analyst, you might want to hook it up to Vanta or give it its own threat catalog to sort of monitor your application or SOC 2 and so on and so forth, which you can then bring in as integrations into these agents.

And then it starts working with you on your requirements to ensure that it is cybersecurity compliant or it is addressing certain user requirements that have come in from user feedback and so on.

Performance optimization, whatnot, those kind of things.

I think one of the recent use cases that we've been working on is where there is Slack channels for the product to actually get feedback on.

And there is an agent that's deployed called the product manager that sort of has the Slack integration.

So anytime the user reports a problem or a suggestion, this agent sort of gets or has integration to Slack to sort of pick up on user feedback and then starts commenting on requirements to say, this is a feature that the user XYZ has requested in so and so ways.

It might be the smallest of the smallest things, but then stuff like, can I create certain things in a certain workflow within the application as a user feedback that you probably want to take in?

So it might come in like on your Discord server or your Slack server, but then that can now come into your requirements context or your specification context to help you further define the product.

That making sense or?

Yeah, more or less for a brain like mine.

Yeah.

Cool.

Well, thank you guys.

Thank you for the demo.

Thank you for walking me through it.

And anyone that wants to check it out, specvia.com.