AI Writes the Code, You Write the Spec: What to Prepare Before Custom Software
AI can now write most of the code, and the bottleneck in software is moving. In 2026, spec-driven development has become one of the most repeated phrases among developers: write the requirements, constraints and acceptance criteria into a clear specification first, then let AI generate code from it. A Microsoft engineer put it plainly in an official post in June: as development becomes AI-native, the limiting factor is no longer how fast code gets written but how clearly intent is captured and validated. For a business owner about to commission custom software, that is good news and new homework. How clearly you write down what you need now decides how accurate the system you receive will be.
What spec-driven development is, and why everyone is talking about it in 2026
Put simply, spec-driven development treats the specification, not the code, as the project's central document. The Microsoft for Developers blog, in a post dated June 10, 2026, defines it as a spec-first approach in which teams define requirements, constraints and acceptance criteria up front, then use AI to generate code and supporting artifacts from that shared context. The lifecycle it describes has seven phases, from setting principles, writing the spec and clarifying ambiguities, through planning the architecture, breaking down tasks and implementing, to validating the result against the spec.
The tooling has caught up. A June overview on DEV Community lists GitHub's open-source Spec Kit, AWS Kiro, Claude Code, Cursor, OpenSpec, Tessl and Google's Antigravity as all shipping some form of spec-driven workflow. The approach took off because AI is very good at writing code and very bad at guessing what you meant. Without a spec, it produces code that looks reasonable, runs fine and quietly solves a different problem.
What it means for business owners: code got cheap, clarity got expensive
Commissioned software used to cost mostly engineering hours, and requirements interviews were often treated as a formality before the real work. That ratio has flipped. Code arrives faster and faster, while one vague requirement gets turned, very efficiently, into a complete set of wrong features.
Microsoft's post calls this translation loss: a requirement travels from the owner's head to a project manager's notes, to a design, to code, and loses fidelity at each handoff. The spec exists so that every person and every AI agent works from the same document.
For an owner, two things follow:
- Your involvement matters more, and it is concentrated at the start. The person who knows the business rules best is you, not the development team and certainly not the AI.
- The spec is your asset. It records how the system is supposed to behave, which gives you a basis for changing teams, changing tools or adding features later.
The four parts of a good spec
You do not need to code. Before commissioning a build, prepare at least these four things:
1. Goals and users
Who will use the system? How do they do the job today? Which number should improve afterward? "I want a booking system" is not enough. "Let customers book on their phone in three steps and halve the time the front desk spends on calls" is a goal that can be checked.
2. Acceptance criteria
Write what "done" means as individual, testable sentences. A common format is EARS, for example: "When a customer cancels a booking, the system shall release the time slot and notify the shop." People can read it, and AI is unlikely to misread it.
3. Boundaries: what this version will not do
Any boundary left unwritten will be imagined by the AI and the engineers. List the features out of scope, the existing processes that must not change, and the regulations and brand rules that apply.
4. Data and existing systems
Where does the data live now: spreadsheets, a POS, a membership system, a LINE official account? What must be integrated, what must be migrated, and who is allowed to see what? This is the part most often discovered after work begins, and the part most likely to blow the schedule.
A spec is not a cure-all: when you can skip the detail
Spec-driven development has critics. The DEV Community overview notes that some see it as waterfall development with a new name, and that Thoughtworks places it at "Assess" rather than "Adopt" on its Technology Radar. The common risks are:
- The spec itself is wrong: code that perfectly matches a wrong spec still solves nothing.
- Over-specification: a spec detailed enough to be the program written twice slows everything down.
- Process as ceremony: tools and documents pile up without matching value.
So it depends. A throwaway prototype, a short-lived tool built by one person, or exploratory work where the requirements are still unknown does not need the full process. Building something to try is faster. Once a system touches customer data or payments, or a team will rely on it for years, the spec is worth writing first. We drew the same line in Built It With AI? When Vibe-Coded Tools Should Move to Professional Development: prototypes optimize for speed, production systems for stability.
Conclusion: keep the thinking with people
Spec-driven development is a reminder of something plain: software turns out well when the problem was thought through at the start. AI can write code quickly and neatly. Which problem to solve, for whom, and how good is good enough still has to be decided by people. That is what TitApeX means by "AI handles perfection, people create emotion."
If you are considering a custom system and are not sure how to organize your requirements, we can start with a spec and work through it with you. Take a look at our custom development services or get in touch.
Comments