A founder's idea often arrives as a collection of screens: a dashboard, a mobile view, a notification panel, and an assistant. Those screens may be useful eventually, but they do not define a working product. A product begins when a particular person can complete a meaningful job and the team can explain why that job matters. AI can help implement the path once the path is clear.
Chapter 1 established boundaries for AI-assisted engineering. This chapter applies them to a first working slice. We will continue with the hypothetical maintenance-request tracker and move from an ambiguous idea to a small release that can be demonstrated, tested, and revised. The goal is a coherent workflow with known limits.
Translate the idea into an observable outcome
Start with a concrete event. A coordinator receives a maintenance request and needs to assign someone responsible for it. The desired outcome is that the request has an owner and a visible status. “Build a smart operations dashboard” does not tell the team whether that outcome has been achieved.
Write one sentence for each important step: the coordinator enters the request, assigns a technician, and sees confirmation that it was saved. Then describe the most important failure: a request must not appear saved when the write failed. These statements become the beginning of an acceptance checklist.
Ask the agent to identify missing decisions before writing code. It might ask whether the technician must belong to the same organization or whether a request can be edited after assignment. Answer the decisions that affect the first slice and explicitly postpone those that do not.
Choose a vertical slice that crosses the real boundaries
A vertical slice contains enough interface, server logic, and storage to complete one job. For the tracker, that could be creating and viewing an assigned request. A set of disconnected mock screens is easier to generate, but it cannot reveal whether authorization, validation, and persistence work together.
Keep the slice narrow. Email intake, automated scheduling, analytics, and offline operation can wait unless they are essential to the first test. A manual input form may be sufficient to learn whether a shared queue is useful. Record the excluded capabilities so that nobody mistakes the first release for a complete system.
This is where business and engineering should agree on the trade-off. A founder may accept manual request entry for a pilot. They should not have to accept silent data loss or unrestricted access to another organization's requests simply because the product is early.
Create a task packet the agent can inspect
Describe behavior and constraints
Include the user, workflow, success condition, important failures, and existing conventions. State which parts of the codebase should be reused. If the project already has a database layer and validation pattern, direct the agent to inspect them before introducing another approach.
Ask for a small implementation plan
The plan should name the relevant modules and checks, not predict every line of code. Review it for unnecessary infrastructure and hidden assumptions. If a one-form change suddenly requires a new queue, service, and identity provider, investigate why before accepting the expansion.
Keep decisions with the task
Save answers in the repository or task record rather than relying on a long chat. Future work should be able to recover why assignments are limited to a particular organization and why email integration was postponed. This context prevents the next agent or engineer from undoing a deliberate choice.
Define the data contract before polishing the interface
For a first request record, you might need an identifier, organization identifier, summary, assignee identifier, status, and creation time. Decide which values the server supplies and which come from the user. Treat identifiers and organization membership as server-validated facts rather than trusting hidden form fields.
Specify the response for success and for expected errors. A validation error should let the coordinator correct the form without losing their work. A storage failure should make it clear that the request was not saved. These details are part of the product behavior, not an optional cleanup task.
Use synthetic records to test the contract. Include an unknown assignee, an excessively long summary, and a missing required value. Ask the agent to explain how each case reaches the validation boundary and what the user receives in response.
Implement in increments that preserve reviewability
One practical order is data access, server behavior, interface connection, and end-to-end verification. The order may change with the existing application, but each step should leave a visible piece of evidence. Avoid combining broad refactoring with the first feature unless the feature cannot be implemented safely without it.
Review the diff after a bounded change. Look for duplicated validation, newly introduced dependencies, accidental changes to existing routes, and configuration that contains sensitive values. Ask the agent to explain surprising edits by pointing to the requirement they support.
When a test fails, preserve the failure information before changing code. A test that cannot start because a service is unavailable says something different from a test that reaches the feature and finds incorrect behavior. Accurate diagnosis keeps the team from fixing the wrong layer.
Make the first demonstration resemble real work
A useful demonstration starts with a new request and ends with another authorized user finding the assigned work. It should include at least one correction or failure. Have the coordinator change an invalid assignee or retry after a simulated failed save. These paths reveal usability and state-management problems that a successful screenshot hides.
Use a separate test environment and explain the limits of the demonstration. If notifications are simulated, label them as simulated. If the data is temporary, say so. A pilot participant should know which parts are ready for practical use and which exist only to explore the workflow.
Record observations in ordinary language: “The coordinator could not tell whether clicking Save twice created two requests.” That is a stronger follow-up task than “improve user experience,” because the engineer can identify a concrete behavior to change.
Keep a release note and a rollback path
Before a small release, write down what is included, what remains manual, and what the team will watch. Include the location of the previous deployable version and any database change that affects rollback. Reverting application code does not automatically reverse a data migration.
For the tracker, the release note might say that coordinators can create requests, assign technicians within their organization, and view saved requests. Email import and automated reminders remain outside the release. Support questions should have a named owner, even if that owner is also the developer.
The first chapter's working agreement on AI-assisted development applies here: the person approving the release must understand the implemented behavior. An agent's completion message is useful context, while the release evidence comes from the code, checks, and demonstration.
Decide what to build next from the result
After the demonstration, classify feedback into a failed acceptance condition, a new requirement, or an observation needing investigation. Fix failures before declaring the slice complete. Investigate repeated confusion before adding unrelated features. Do not treat every suggestion as a commitment for the next release.
If users cannot find their assigned requests, improve that path before adding an AI summary. If the shared queue is unused because requests still arrive through an inaccessible channel, revisit the workflow assumption. The result may call for discovery work rather than more implementation.
Conclusion: turn ambiguity into a small, dependable path
A first working product is a carefully chosen path through a real job. Define the outcome, connect the necessary boundaries, test meaningful failures, and preserve the decisions that explain the result. AI can accelerate each step when the task remains understandable enough for a person to review.
Your next exercise is to write the first slice as a short acceptance checklist and walk through it with a potential user. In Chapter 3, we will examine how to organize the system so that later changes remain manageable as the first slice grows.
