Finishing the documentation for a software product feels like a major milestone.
You have the product requirements. The business rules are defined. The database structure is taking shape. Permissions are documented. API behavior is clear. You may even have acceptance criteria and UAT scenarios ready.
At that point, it is tempting to open an AI coding agent, point it toward the documentation, and say:
“Build the application.”
I learned fairly quickly that this is not a particularly good way to work.
While preparing EZSell V2 for AI-assisted development, I had already spent significant time creating structured product specifications. I had module-level requirements, architecture decisions, database design, API contracts, security rules, and cross-module UAT scenarios.
The documentation was not the problem anymore.
The problem was how to turn all of that information into something an AI coding agent could execute reliably.
Giving an agent too little context caused it to make assumptions.
Giving it too much context made the task unnecessarily broad.
The real breakthrough came when I stopped thinking in terms of:
“How do I give AI my project?”
and started thinking in terms of:
“What is the smallest complete piece of this product that AI can build correctly?”
That changed my development workflow significantly.
Good Documentation Is Not the Same as a Good Coding Task
A PRD is written to explain a product.
A coding task needs to explain a specific implementation objective.
Those are related, but they are not the same thing.
A product specification might explain everything about customer management: creation, editing, categories, dues, collections, loyalty points, permissions, validation rules, and relationships with sales.
That is useful product documentation.
But asking an AI agent to:
“Implement the Customer module according to the SRS”
still leaves a surprisingly large amount of interpretation.
Where should it start?
Should it build every screen?
Should it create the database first?
Which API endpoints belong in the first iteration?
What happens when customer creation is triggered from the POS screen?
Which permissions need to exist?
Which tests prove the work is complete?
What should happen if another specification contains a conflicting rule?
Humans naturally fill in these gaps through conversations and experience.
AI agents fill them with assumptions.
That is exactly what I wanted to avoid.
So I started breaking requirements into implementation-sized work packets.
I Stopped Building Modules and Started Building Capabilities
Initially, it was natural to think in modules.
Products.
Customers.
Suppliers.
Inventory.
Purchasing.
Sales.
Accounts.
That structure is useful for documentation, but it is not always the best structure for development.
A module can be huge.
“Build Inventory” could involve stock balances, movements, transfers, adjustments, batches, expiry, purchasing, sales, returns, audit trails, permissions, and reporting.
Instead, I started thinking in terms of capabilities.
For example:
Create a product with variants and make those variants available for stock receiving.
That is much more useful.
It touches multiple layers, but it has a clear beginning and a clear outcome.
The agent may need to work on the UI, validation, API, database, permissions, and tests, but everything contributes to one business capability.
This is what led me toward vertical-slice development.
Why Vertical Slices Work Well With AI Agents
A vertical slice is a small piece of functionality implemented completely across the system.
Instead of building:
database first → APIs later → frontend later → integration later,
you build one business capability through all necessary layers.
For example, imagine the first slice is:
Create a basic product.
The slice might include the product form, API request, validation, product table, permissions, audit information, automated tests, and the acceptance criteria required to consider the capability complete.
Once that works, the next slice might introduce variants.
Then barcode generation.
Then stock receiving.
Then inventory movement.
Each slice expands a working product.
This gives AI something very important:
boundaries.
The agent knows what it is responsible for right now and, equally importantly, what it should not try to solve yet.
The Context Problem Was More Important Than I Expected
One assumption I had early on was that more context would automatically produce better results.
If the AI agent could read every PRD, every architecture document, every API contract, and every database specification, surely it would understand the application better.
In practice, that is not always true.
There is a difference between having documentation available in the repository and requiring the agent to reason about all of it for every task.
If I am implementing product creation, the agent probably does not need to deeply analyze gift vouchers, customer loyalty, counter closing, and supplier payments.
Those things may matter later.
They do not matter to the current task.
I started treating context almost like product scope.
Only include what is necessary to make the current decision correctly.
For each implementation task, I identify the documents that actually matter.
That normally includes the relevant product specification, database definitions, API rules, permission requirements, architectural constraints, and the UAT or acceptance criteria connected to the capability.
The complete documentation remains available as the source of truth.
But the agent gets a focused working context.
From Requirement to Work Packet
My current approach is to transform a product requirement into a small implementation package before asking an agent to start coding.
A typical work packet contains:
Objective — what business capability must exist when the task is finished.
Scope — exactly what is included and, where necessary, what is explicitly excluded.
Source documents — which files contain the authoritative requirements for this task.
Business rules — the rules the implementation must preserve.
Technical contracts — relevant database, API, authorization, transaction, and architecture constraints.
Acceptance criteria — observable conditions that prove the feature works.
Definition of Done — tests, documentation, migrations, error handling, and other completion requirements.
Conflict rule — what the agent should do if two documents disagree or an important decision is missing.
That is usually enough structure to keep the agent focused without writing an enormous prompt.
The documentation carries the details.
The task tells the agent where to look and what outcome to produce.
A Real Example: Product Creation
Take something that sounds simple:
Create a product.
In a retail system, that can become complicated surprisingly quickly.
A product might have a category, brand, unit, VAT behavior, generated product code, barcode settings, variants, selling price rules, status rules, and permissions.
There may also be restrictions on deleting a product once it has transaction history.
If I simply tell an agent:
“Create the product management feature”
I am giving it plenty of room to make product decisions on my behalf.
Instead, I would define the capability more narrowly.
The objective might be:
Allow an authorized user to create a basic product using the approved product numbering, category, VAT, and status rules.
The agent would then be directed to the Product specification, tenant settings, database design, authorization rules, and the corresponding API contract.
The acceptance criteria might establish that a product cannot be saved without required information, generated numbering follows the configured sequence, unauthorized users cannot create products, validation failures do not leave incomplete records, and the resulting product can be retrieved correctly.
Now the implementation is much harder to misunderstand.
The agent is not being asked to invent Product Management.
It is being asked to implement an already-decided capability.
The Most Important Instruction: Do Not Invent Business Rules
This has become one of my strongest rules for AI-assisted development.
If an implementation decision is genuinely technical, the agent can often make a reasonable recommendation.
If it is a business decision, I do not want the agent silently deciding it.
Consider questions such as:
Can a completed sale be edited?
Can a customer exceed an allowed due amount?
What happens to loyalty points when a sale is returned?
Can a product with transaction history be deleted?
Can stock become negative?
Those decisions affect the product.
They may also affect accounting, inventory, reporting, permissions, and future features.
An AI agent can suggest possible approaches, but it should not quietly choose one just because the implementation requires an answer.
My instruction is therefore simple:
If the documented requirements do not answer an important business question, stop and raise the issue.
That may feel slower in the moment.
It is still much faster than discovering three weeks later that the agent implemented a rule differently across four modules.
Acceptance Criteria Changed the Quality of My Prompts
Another thing I learned is that AI performs much better when “finished” has a concrete meaning.
“Implement customer creation” is vague.
“Customer creation is complete when an authorized user can create a customer with required fields, duplicate constraints are enforced, validation errors are returned correctly, the record is stored in the correct tenant database, and automated tests cover success and failure paths” is much clearer.
The second version gives the agent something to verify.
This is why I increasingly write acceptance criteria before implementation rather than after it.
Acceptance criteria are useful for developers.
They are even more useful for AI agents because they reduce interpretation.
They also make review easier.
Instead of looking at a large code diff and asking:
“Does this look good?”
I can ask:
“Does this implementation satisfy every agreed acceptance criterion?”
That is a much stronger review question.
UAT Gives the Agent the Bigger Picture
Acceptance criteria are usually focused on one feature.
UAT helps connect that feature to the larger business workflow.
For EZSell V2, many of the important workflows cross several modules.
A product is created.
Stock is purchased.
The stock is received.
Inventory increases.
The product is sold.
Payment is recorded.
The counter balance changes.
Accounting entries are created.
A return might reverse parts of that process.
If an agent only understands its current endpoint, it can implement something that works locally while breaking the overall flow.
Cross-module UAT scenarios help prevent that.
They show the agent what the system must ultimately accomplish.
I do not necessarily ask the agent to implement the entire UAT journey in one task.
But I want it to understand where its current slice fits into that journey.
I Separate Product Decisions From Implementation Decisions
This distinction has become increasingly important in my workflow.
There are questions where I expect the AI coding agent to make technical decisions:
How should this service be structured?
Where should this reusable validation live?
What test organization fits the existing repository?
Can this query be improved?
Then there are questions where I want the product documentation to decide:
Can users edit this transaction?
Which roles can perform the action?
Should this operation affect stock immediately?
Can the customer complete the transaction with an outstanding due?
The first category is engineering implementation.
The second category is product behavior.
I want AI to have flexibility in the first category while being constrained by the second.
This gives the agent enough freedom to be useful without giving it control over the product.
AI Tasks Need Explicit Non-Goals
One small change improved my results more than I expected:
I started telling agents what not to build.
Suppose I am implementing the first version of inventory receiving.
The full product roadmap may eventually contain supplier invoices, partial receiving, expiry tracking, stock adjustments, transfers, purchase returns, and reporting.
If those concepts exist somewhere in the repository, an agent may try to anticipate them.
That sounds helpful.
It often is not.
Future-proofing can easily turn into premature complexity.
So a task may explicitly say:
Do not implement stock transfer in this slice.
Do not create reporting APIs.
Do not introduce functionality for requirements marked deferred.
Do not redesign the existing authentication architecture.
Non-goals protect the task from scope creep.
That applies to human developers too, but AI agents can move fast enough that an unnecessary architectural decision may be implemented before you even realize it has expanded the scope.
Review the Plan Before Reviewing the Code
I also changed when I intervene.
Instead of letting the agent immediately change 30 files, I prefer to have it understand the task first.
For a meaningful slice, I want the agent to identify:
which files are likely to change, which requirements apply, what database changes are necessary, what permissions are involved, what tests should be added, and whether it has discovered any conflicts.
Only then should implementation start.
Catching a misunderstanding at the planning stage is cheap.
Catching it after migrations, services, APIs, UI components, and tests have already been generated is expensive.
This mirrors something I already knew from product management:
The earlier you discover misunderstanding, the cheaper it is to fix.
AI does not change that principle.
It makes it even more important because implementation happens much faster.
Commit Small, Because AI Moves Fast
AI coding agents can generate a surprising amount of code in one session.
That is both a strength and a risk.
The larger the change, the harder it becomes to understand exactly what happened.
I therefore prefer small, logical implementation boundaries.
Complete one slice.
Review it.
Run tests.
Validate the behavior.
Commit it.
Then move forward.
This makes rollback easier and debugging much more manageable.
It also gives the next AI session a cleaner starting point.
I would rather have ten understandable commits than one enormous “implemented inventory system” commit containing dozens of unrelated changes.
AI Did Not Remove My Product Manager Role
One of the interesting things about this workflow is that coding agents actually made product thinking more important for me.
When development was slower, some ambiguity could survive for a while.
A question might be discovered during implementation.
Someone would schedule a meeting.
The product decision would eventually be made.
AI compresses that cycle dramatically.
The agent may reach the unanswered decision within minutes.
That means unclear product thinking becomes visible much earlier.
Instead of eliminating product management, AI exposes weak product definitions faster.
I still need to decide:
What belongs in the MVP?
What does the business rule actually mean?
Which edge cases matter?
What should happen when something fails?
Which behavior is configurable?
Which requirements are intentionally deferred?
What must never happen?
The AI can implement answers incredibly quickly.
But somebody still has to provide the answers.
My Development Loop Today
The workflow I am gradually standardizing looks something like this:
Requirement → Vertical Slice → Context Selection → Agent Plan → Implementation → Automated Tests → UAT Validation → Review → Commit
The interesting part is that the prompt itself is no longer the center of the process.
The surrounding system matters much more.
The source documents provide the product truth.
The task provides the immediate objective.
The repository instructions provide engineering guardrails.
The tests provide technical feedback.
The UAT scenario provides business validation.
The human remains responsible for decisions.
That is a much more reliable model than trying to write one brilliant prompt that explains an entire software product.
What I Would Avoid Now
There are a few approaches I used or considered early that I would avoid for serious products.
I would not tell an agent to read an entire documentation directory and “build everything.”
I would not allow it to resolve contradictory requirements silently.
I would not combine several unrelated modules into one implementation request.
I would not treat generated code as complete simply because it compiles.
And I would not rely on chat history as the permanent source of business rules.
Chat is useful for thinking.
The repository needs durable decisions.
The more serious the product becomes, the more important that distinction becomes.
The Bigger Lesson
My first lesson in AI-assisted development was that documentation matters.
The second lesson was more subtle:
Documentation still needs to be translated into executable context.
A 200-page specification can contain everything an AI agent needs and still be a terrible coding task.
The agent needs a clear objective, a bounded scope, authoritative references, known constraints, testable acceptance criteria, and permission to stop when the product definition is incomplete.
That is where I think the real craft of AI-assisted software development is moving.
Not toward bigger prompts.
Not toward asking agents to build entire applications autonomously.
But toward creating better interfaces between product intent and machine execution.
AI is very good at moving from clear instructions to working code.
The difficult part is still creating that clarity.
And in my experience, that is where product management becomes an advantage rather than something AI replaces.
Final Thought
I used to think the important question was:
How much of this software can AI build for me?
I now think the better question is:
How clearly can I define the next thing AI should build?
That change sounds small, but it completely changes the workflow.
You stop asking AI to understand an entire product at once.
You give it one controlled problem.
One source of truth.
One measurable outcome.
Then you build the next slice.
That is how I am trying to move from vibe coding toward something much more dependable: structured AI-assisted software development.