Vibe coding has made software development faster than ever.
You can describe a feature in plain language, ask an AI agent to implement it, and receive working code within minutes. This is incredibly powerful for prototypes, internal tools, and early-stage products.
But building production software is different.
When a system involves inventory, payments, permissions, subscriptions, accounting, multiple locations, or tenant isolation, a vague prompt is not enough. An AI coding agent can generate code quickly, but it cannot reliably guess your business rules.
That is why I believe the next evolution of vibe coding is not simply better prompting.
It is specification-driven vibe coding.
I recently used ChatGPT to help prepare the complete requirements and implementation baseline for EZSell V2, a multi-tenant retail POS and inventory SaaS platform.
The goal was not to ask AI to “build the entire application.”
The goal was to create a controlled body of documentation that coding agents could use to build the application correctly, module by module.
Why documentation matters in vibe coding
AI agents are excellent at generating:
Application structure
Database migrations
APIs
UI components
Validation logic
Automated tests
Refactoring and documentation
However, they cannot independently know:
Whether a posted sale can be edited
How stock should behave during returns
Whether customer dues are allowed
Which user can access which location
How payment and accounting entries should reconcile
What happens when the same request is submitted twice
Which requirements are current and which have been replaced
If these decisions are not documented, the agent will make assumptions.
The code may look clean and still be functionally wrong.
Start with scope—not technology
One of the first things I documented was the actual MVP boundary.
For every proposed feature, we decided whether it was:
Included in the MVP
Deferred until a later release
Explicitly excluded
Dependent on another module
Still waiting for a product decision
This prevented the AI from quietly adding features we had not approved.
For example, advanced analytics and some loyalty functionality were deferred. Once that decision was recorded, coding agents could not treat those features as hidden MVP requirements.
Clear exclusions are often as important as feature requirements.
Break the system into business domains
Instead of preparing one enormous SRS, I divided the platform into smaller authoritative specifications.
The documentation covered areas such as:
Products and variants
Categories, brands and units
Pricing, VAT and barcodes
Customers and suppliers
Purchasing and receiving
Inventory and stock movements
Sales, returns and voids
Counter sessions
Accounts and transactions
Tenant configuration
Users, roles and permissions
Each specification answered practical implementation questions:
Who can perform the action?
What information is required?
What validations apply?
Which records are created or updated?
What permissions are checked?
What are the possible statuses?
What happens if the operation fails?
How does the module affect stock or money?
What are the acceptance criteria?
This gave the AI smaller, focused sources instead of one document containing hundreds of mixed requirements.
Keep a decision register
During documentation, the same business question often appeared in several modules.
Should a posted sale be editable?
Should a product with transaction history be deleted?
Can an invoice accept split payments?
Can a customer exceed a credit limit?
If decisions like these remain inside conversations, they eventually get lost or contradicted.
I therefore maintained decision records containing:
The question
The approved decision
The reasoning
The affected modules
The documents that needed updating
Any deferred considerations
ChatGPT helped identify where a decision affected other modules, but I remained responsible for approving the final business rule.
That distinction is important: AI can analyze the decision, but the product owner must own it.
Establish one source of truth
As documentation grows, duplication becomes dangerous.
The same requirement may appear in a PRD, a master document, a module specification, an API document, and an old draft. If the wording differs, the coding agent may follow the wrong version.
To prevent this, I created a Source-of-Truth Index defining:
The current authoritative files
The owner of each requirement area
The approved version
Which documents are archived
Which document wins when two sources conflict
The clean implementation folder now contains only the current development documents. Old drafts and compiled duplicates are kept outside that folder as historical references.
This gives an AI agent a controlled knowledge base instead of an unfiltered document archive.
Connect business requirements to technical contracts
Functional requirements describe what the software should do. Coding agents also need documents explaining how those requirements translate into software.
For EZSell V2, this included:
Architecture
The architecture document defines the approved technology stack, application boundaries, infrastructure, database strategy, caching, queues, storage and deployment direction.
Database design
The database specification defines tables, relationships, constraints, indexes, transaction boundaries and data ownership.
It also separates the central platform database from individual tenant databases.
API contracts and state machines
This document explains endpoints, commands, request and response structures, permissions, errors, idempotency and valid status transitions.
A state machine is especially important for transactions such as purchases, sales, returns and counter sessions. It prevents an AI agent from inventing invalid status changes.
Tenancy, security and authorization
This specification defines how tenants are resolved, how databases are isolated, how location access works, and how permissions are enforced.
Security should never depend on assumptions made by a coding agent.
Define UAT before implementation
Requirements are much stronger when they can be tested.
Before development, I prepared cross-module UAT scenarios covering complete business journeys rather than isolated screens.
For example:
Create a product and its variants.
Purchase and receive stock.
Verify the resulting inventory movement.
Sell the product.
Record the payment.
Update the counter balance.
Create the correct accounting transaction.
Process a return.
Verify the stock and financial reversal.
This allows an AI coding agent to understand the complete outcome—not only the endpoint it is currently implementing.
It also provides evidence for deciding whether a feature is genuinely complete.
Create an AGENTS.md file
One of the most useful documents was AGENTS.md.
This file acts as the operating manual for AI coding agents working inside the repository.
It defines:
Which documents must be read
Which requirements are authoritative
Repository boundaries
Coding and naming standards
Tenant-isolation rules
Transaction and idempotency requirements
Testing expectations
Prohibited shortcuts
What the agent must do when documents conflict
The Definition of Done
The instruction is simple: when a rule is unclear, stop and raise the conflict. Do not invent a business decision.
Develop through vertical slices
After completing the requirements baseline, I converted the scope into a vertical-slice roadmap.
A vertical slice delivers a small but complete capability across the necessary layers:
User interface
API
Business logic
Database
Authorization
Audit trail
Automated tests
UAT evidence
The roadmap for EZSell V2 contains gated releases and sequenced slices. Foundational capabilities such as tenant isolation, identity, inventory, accounts and counter sessions must be proven before the first production-grade sale is implemented.
This is safer than asking an agent to generate the frontend first, the backend later, and somehow connect everything at the end.
Do not give the agent every document for every task
More context is not always better.
For each vertical slice, the coding agent should receive:
The Source-of-Truth Index
AGENTS.mdThe relevant module specification
Related database definitions
Applicable API contracts
Security and permission rules
Relevant UAT scenarios
This creates a focused work packet.
The agent receives enough context to implement the slice correctly without being distracted by unrelated modules.
What AI did—and what I still owned
ChatGPT helped me:
Structure the documentation
Detect missing rules
Find contradictions
Analyze cross-module impacts
Produce consistent specifications
Generate acceptance criteria
Model database and API boundaries
Organize the implementation roadmap
But I still had to:
Define the product vision
Explain the business
Approve every important rule
Reject unnecessary complexity
Decide what belonged in the MVP
Resolve conflicting requirements
Validate the final documents
The process worked because AI accelerated the thinking—it did not replace product ownership.
The practical documentation stack
For a serious AI-assisted software project, I recommend preparing:
Product vision and MVP scope
Module-level PRD/SRS documents
Business decision register
Source-of-Truth Index
Technology stack and architecture
Database design and data dictionary
API contracts and state machines
Tenancy, security and authorization rules
Cross-module UAT scenarios
AGENTS.mdVertical-slice implementation roadmap
Living UX and test documentation created during implementation
Not every startup needs dozens of documents. The documentation should match the risk and complexity of the product.
A landing page does not need an enterprise SRS. A multi-tenant POS managing stock, money and permissions does.
Final thought
Vibe coding is not about removing discipline from software development.
It is about reducing the cost of turning clear thinking into working software.
The better the requirements, decisions, constraints and acceptance criteria are, the better an AI coding agent can perform.
My biggest lesson from preparing the EZSell V2 documentation is this:
Do not ask AI to guess the product and build the software at the same time.
First create an implementation-ready source of truth. Then let AI help you build it—one controlled vertical slice at a time.
That is how vibe coding moves from impressive prototypes to dependable software.