If you're not familiar, “vibe coding” refers to non-technical people using LLMs (aka generative AI) to build apps and software. You can tell an LLM in plain English what you want and it writes you the code to build that thing.
Maybe the best use case I’ve seen for vibe coding is building a prototype really fast. Let’s say you’re a manufacturing CEO and you have a vision for an app that would help shift managers schedule shifts more easily and deal with last-minute callouts. But you don’t have a technical background.
Vibe coding can save the day. Within an hour or less, you can have a functioning prototype of the tool you want.
But if you let your team use that version, you might have problems: is it secure enough to protect the personal information you’d have to feed it? Does it need an API to, say, your HR system? Are you confident it won’t introduce any insecurities to that system? And what happens if it breaks? Will you be able to troubleshoot to get it back up and running?
These are the kinds of questions that any industrial leader should be asking about vibe coded software. They’re also key to why, when it comes to building secure, compliant systems for clients, we work with LLMs via a much more rigorous process: spec-driven development.
In this piece, I’ll explain how spec-driven development gives you the best of both worlds when it comes to developing software in the age of AI: increased speed paired with functionality, security, and compliance that meet industry standards.
What is spec-driven development?
Vibe-coding is what happens when someone with no engineering background uses an LLM to build software. Spec-driven development is a rigorous process that engineers use to build enterprise-ready software (read: compliant, secure, functional, maintainable) with LLMs.
The two aren’t mutually exclusive. In the example above, for instance, the CEO’s vibe-coded prototype may be a super-helpful way to show an engineering team what the vision is for a finished product.
It’s when you’re ready to get to the finished product that spec-driven development comes into play. Whereas a vibe-coded solution starts with an idea and leaps straight to generating code, spec-driven development starts with an idea and then requires a lot of information gathering to make sure the code that eventually gets generated actually works for the organization that’s going to use it.
For example, let’s imagine we’re building a dashboard to analyze and interpret data from the density tests your organization conducts. Right now, the information from tests lives in spreadsheets and is hard to use beyond identifying test results.
The dashboard will make it easier to use the data to spot trends and opportunities.
If we vibe-coded the dashboard, it would probably look pretty good. It would pull in the data you fed it and structure a dashboard based on its best guess about what was important and relevant.
That’s the first problem. If you’re doing specialized work like materials density testing, there's a good chance there isn’t a lot of information on the internet about what the most important information is from those tests, and there's almost certainly no information about what information is important to the specific business decisions you hope to make based on this data.
So in spec-driven development, we don't start with the code. We start with in-depth interviews with various people from your organization.
How we develop specs: detailed conversation, rigorous analysis
These interviews might take a few weeks, depending on how many people we talk to. We’ll try to understand a few things:
What's in the density testing data?
What's the most important metric?
What does that metric tell your business?
What kinds of business decisions will you make based on the metrics you see?
How are the density metrics and your larger business related?
Who will be viewing this dashboard?
What follow-up questions will people have after seeing these metrics?
What data can answer those questions? Where does that data live?
And so on. In other words, we can’t confidently tell the LLM what kind of code to write until we really understand what business function the code will help you improve.
We’ll also ask about what other types of data you might want to interrogate in the future. Maybe, for example, you also perform hardness testing. Or maybe you gather citations to see how researchers use your data. When we zoom out and understand the bigger picture, we can build a better dashboard because we can build one that can accommodate more types of data in the future and therefore help you modernize more aspects of your organization.
Part of the work of spec-driven development for a project like this is identifying which categories data should fall into. When we do this well, we can build tools that have a long shelf life and can be adapted and reused across the organization.
Once we’ve asked enough questions to understand the larger context of the data and the purpose of the tool we’re building, we create detailed specifications. Only once we have these do we loop in an LLM.
Related: The AI-human advantage in manufacturing
AI-generated code is a small piece of the final product
When I have my detailed specifications, built from weeks’ worth of conversations, I feed them to Claude with instructions to generate code to those specifications.
But that’s only the start of the code-development process. Once I have the code, I review and test it. For example, I want to make sure it’s consistent throughout. This makes it easier to maintain.
I might also run tests for security and accessibility to ensure that the code will work within the larger context of the business it’s being built for. The important thing to keep in mind here is that it’s my expertise and experience as an engineer that makes me able to assess the code and the accuracy of the tests I’m running.
The LLM speeds things along, but without an expert human overseeing the process, it wouldn’t be valuable.
In some ways, the use of an LLM in spec-driven development is like the use of CAD software in architecture. The architect is using software to speed up certain parts of the design process, but their skill and expertise are still essential to getting to completion.
AI alone can’t modernize your operations
Industrial leaders know that technologies like AI can modernize their operations. But it’s not always clear how that might happen.
Plenty of leaders have been disappointed by the results of early AI trials, whether from vibe-coded apps or off-the-shelf tools. That’s because AI, like any technology, can only deliver on its promise of transformation when it’s applied strategically within the larger business context. Without that context, tools aren’t able to deliver relevant enough information or meaningfully improve processes enough to drive real change.
But when you use AI within a process like spec-driven development, you’re able to bring the full organizational context to the technology you’re developing. That’s when meaningful, lasting improvements emerge.
