A Practical Guide to AI-Assisted Development

AI can help you build features faster, but generating code is only one part of the job. You still need to define the requirements, check the implementation, test edge cases, review security risks, and deploy the change safely.

This guide walks through a complete development example using Fatleon.

The workflow is:

1. Choose the feature and define what success looks like.
2. Ask AI to inspect the codebase and propose an implementation.
3. Let AI implement the feature in a controlled scope.
4. Test the result against the sandbox and the requirements.
5. Ask AI to find remaining risks, then approve any fixes.
6. Review the final diff for functional and security issues.
7. Commit the change and merge it through the appropriate environments.

The goal is not simply to get AI to write code. It is to use AI as a development assistant while keeping control of the design, security, and release process.

How far a change reaches is graded in Development path. The boundary that change must respect is in Development Security.

1. Choose a Feature

For this example, we will add a status filter to the customer order history page.

The requirement

Customers can already view their orders. We want to make it easier for them to find a particular order by filtering the list by order status.

For example, a customer should be able to select All orders, or one order status. The order statuses in this kit are Pending Payment, Processing, Partially Shipped, Shipped, Delivered, Completed, Cancelled, and Refunding or Refunded. Those names are in Orders and fulfillment. Payment has a separate status (Pending, Paid, Failed, Cancelled, Refunded, or Partially Refunded). The filter uses the order status, not the payment status.

Define what success looks like

Before asking AI to write code, define the expected behavior.

Area	Expected behavior
Default view	Show all orders the signed-in customer is authorized to view
Filtering	Selecting a status displays only matching orders
Reset	Selecting "All orders" restores the complete list
Empty results	Show a helpful message when no orders match the filter
Loading and errors	Preserve the existing loading and error behavior
Authorization	Customers can never see another customer's orders
Data integrity	Filtering must not modify orders or their statuses
Mobile layout	The filter remains usable on small screens

Important: This is a list-filtering feature, not an order-management feature. It must not change order statuses, payment processing, or fulfillment behavior.

2. Prompt AI to Inspect the Codebase First

Do not start by asking AI to implement the feature immediately. First, ask it to understand the existing application.

This reduces the risk of duplicate functionality, incorrect assumptions, unnecessary dependencies, and changes to unrelated code.

Prompt 1 — Inspect and plan

Copy the following prompt into your coding assistant.

You are working on Fatleon, a self-hosted e-commerce application built with Next.js and AWS Amplify Gen 2.

I want to add a status filter to the customer order history page.

Customers should be able to filter their own orders by status and return to the full list by selecting "All orders".

Before changing any code:

1. Find the existing customer order history page and trace how it loads orders.
2. Identify the existing order status values and how they are represented in the codebase.
3. Explain how customer authentication and order authorization are enforced.
4. Identify whether filtering can be implemented using existing data or whether a backend change is necessary.
5. Find existing loading, error, empty-state, and responsive UI patterns that this feature should follow.
6. Identify the tests relevant to the page and its data access.

Do not invent file paths, APIs, schema fields, or order statuses. Inspect the actual code and cite the relevant files and symbols.

Propose the smallest implementation that fits the existing architecture. Prefer reusing existing components and logic over introducing new dependencies or abstractions.

Do not modify any files yet. Return:

• Your understanding of the current implementation.
• The proposed changes and the files they would affect.
• Security and compatibility risks.
• A test plan.
• Any questions that must be answered before implementation.

What you should expect from AI

A useful response should tell you where the order history lives, where its data comes from, what the real order statuses are, and which authorization rules protect the data.

It should also explain whether filtering can be performed on the already-loaded order list or whether the existing query needs to change.

For example, client-side filtering may be sufficient when the application already loads the complete authorized order list. If the list is paginated or the customer can have many orders, server-side filtering may be more appropriate.

Do not accept a proposed implementation until you understand its assumptions.

Your checkpoint: Confirm that the proposed files and data flow actually exist in the repository. Correct any mistaken assumptions before proceeding.

3. Ask AI to Implement the Feature

Once the plan is approved, ask AI to make the smallest necessary changes.

Prompt 2 — Implement the approved plan

Implement the approved order status filter using the existing Fatleon architecture.

Requirements:

1. Reuse the existing customer order history page and UI conventions.
2. Use the actual order status values found in the codebase. Do not create new statuses just for the filter.
3. Provide an "All orders" option and an option for each applicable status.
4. Update the displayed orders when the selected status changes.
5. Show an appropriate empty state when no orders match.
6. Preserve the existing loading, error, authentication, and responsive behavior.
7. Preserve all existing authorization checks. A customer must only be able to access their own orders.
8. Do not change payment processing, order status transitions, checkout, fulfillment, or admin order management.
9. Do not add dependencies or change the database schema unless the inspected architecture demonstrates that this is necessary and I approve the change.
10. Follow the repository's existing coding style and testing conventions.

Keep the diff focused on this feature. Do not refactor unrelated code.

After implementation:

• Summarize the behavior you implemented.
• List every changed file and explain why it changed.
• Identify any assumptions or limitations.
• List the tests you added or updated.
• Report the checks you actually ran and their results.
• Identify any remaining risks or checks that require manual verification.

Do not claim that a test passed unless you actually ran it and observed a successful result.

What to check after implementation

Review the diff rather than relying only on the summary.

Look for:

• Unrelated files that were modified.
• Duplicated order-status definitions.
• New dependencies that are not necessary.
• Changes to authentication or authorization that were not part of the plan.
• Changes to order data, payment logic, or backend permissions.
• Tests that merely repeat the implementation without checking expected behavior.

If AI has changed the schema, authorization rules, or backend functions without a clear reason, stop and ask it to explain why before continuing.

4. Run the Tests and Verify the Actual Behavior

A feature can compile successfully and still be incorrect. Testing should cover both the expected user experience and the cases where things go wrong.

Prompt 3 — Test and verify

Review the order status filter implementation against the original requirements.

First, inspect the available test scripts and relevant tests in the repository. Run the appropriate existing checks, including the relevant unit or component tests and any applicable lint, type-check, or build commands.

Add or update tests where needed.

Verify these scenarios:

1. The page initially displays all authorized orders.
2. Selecting a status displays only orders with that status.
3. Selecting another status updates the results correctly.
4. Selecting "All orders" restores the complete list.
5. A status with no matching orders displays the correct empty state.
6. Loading and error states still work.
7. The filter handles the actual status values and casing used by the application.
8. The filter does not change order data or status values.
9. Existing authentication and authorization behavior remains intact.

If the repository supports integration or end-to-end tests, use them where appropriate.

Do not weaken existing tests, remove assertions, or change production behavior merely to make a test pass.

For every check, report:

• The command or test performed.
• Whether it passed or failed.
• Any relevant output or failure details.
• Any scenarios that could not be verified.

Do not claim that authorization is secure based on frontend tests alone.

Manually test the feature

Use the local sandbox, not the production store.

• The order history page loads correctly.
• All orders are shown by default.
• Each available status filters the list correctly.
• Switching between filters produces the expected results.
• The All orders option restores the list.
• A filter with no matching orders shows a helpful empty state.
• Loading and error states still behave correctly.
• The filter works on mobile and desktop.
• The page does not expose another customer's orders.
• No payment, order status, or fulfillment data is modified.

For the authorization check, use separate test accounts with different orders. Confirm that one customer cannot access another customer's orders through the application's existing data-access paths.

A frontend filter is not a security boundary. If the application has already fetched unauthorized data, hiding those records in the UI does not make the implementation safe.

5. Ask AI to Find Improvements and Remaining Risks

After the initial tests pass, conduct a separate review. Do not ask only whether the code looks good. Ask the model to look for specific failure modes.

Prompt 4 — Challenge the implementation

Review the current diff as a skeptical senior engineer who did not write this feature.

Your task is to find problems, not to praise the implementation.

Examine:

Correctness

• Does filtering work for every actual order status?
• Can the selected filter and displayed results become inconsistent?
• Are empty, loading, and error states handled correctly?
• Does pagination or partial data loading affect the result?

Security

• Does the change preserve the existing authorization boundary?
• Could a customer access another customer's order through a modified request, route parameter, or query?
• Did any change expose sensitive data or widen access?

Performance and maintainability

• Is the implementation appropriate for the size of the order list?
• Does it introduce unnecessary requests, duplicated logic, or new dependencies?
• Does it follow the repository's existing patterns?

Compatibility

• Does it work with the existing order data and status values?
• Could existing order history behavior be broken?
• Are there mobile layout or accessibility issues?

For every finding, provide:

1. Severity: critical, high, medium, low, or informational.
2. The relevant file and line numbers.
3. A concrete explanation of the failure scenario.
4. The smallest reasonable fix.
5. A test that would demonstrate the problem is fixed.

Separate confirmed defects from potential risks that require further investigation.

Do not modify files yet. Present your findings and wait for approval.

How to evaluate the review

Not every suggestion deserves implementation. Prioritize issues that affect correctness, security, or data integrity.

Finding	Recommended action
A customer can access another customer's order	Block the release and fix the authorization issue
Filtering omits a valid order status	Fix the filtering logic and add a regression test
Pagination causes some matching orders to disappear	Determine whether filtering belongs in the query layer and correct the behavior
The empty state is unclear	Improve the message and verify it in the UI
A new abstraction would make the code slightly cleaner	Consider it only if it materially improves maintainability
A potential issue cannot be confirmed from the diff	Investigate before changing code

Prompt 5 — Fix approved findings

After reviewing the findings yourself, use a focused follow-up prompt:

Fix only the findings I have approved.

Preserve the original scope of the feature. Do not perform unrelated refactoring or change authentication, authorization, payment processing, or the database schema unless the approved fix specifically requires it.

For each fix:

• Explain the underlying cause.
• Make the smallest appropriate change.
• Add or update a regression test.
• Run the relevant tests again.
• Report the files changed and the actual results.

Afterward, show the new diff so I can review it.

This review-and-fix cycle can be repeated when necessary. The important point is that AI proposes changes, while you decide which changes are appropriate.

6. Review the Final Diff Before Committing

Once the fixes are complete, inspect the entire diff from the feature branch.

Use the following checklist:

• The implementation matches the approved requirements.
• Only necessary files have changed.
• Existing authorization behavior is preserved.
• No secrets, credentials, or personal data have been added to source files or logs.
• No unrelated schema, payment, or order-processing changes have been introduced.
• Relevant automated tests have passed.
• Manual checks have been completed in the sandbox.
• Remaining limitations are documented.
• The code has been reviewed by a person, not only by AI.

You can ask AI to summarize the final diff, but make your decision based on the actual code and test evidence.

Prompt 6 — Final pre-commit review

Perform a final review of the complete feature branch diff against the approved implementation plan.

Check for:

• Unintended changes.
• Missing or inadequate tests.
• Security or authorization regressions.
• Exposed secrets or sensitive data.
• Unnecessary dependencies or schema changes.
• Changes outside the feature's scope.

Report each issue with file and line references. If no issue is found, say that no issue was identified in this review; do not claim the change is guaranteed to be secure.

Also summarize the checks that were actually run and any checks that remain outstanding.

Do not edit files or commit changes. Wait for my decision.

7. Commit and Merge Safely

Once the final review is satisfactory, commit the change on the feature branch.

Use a descriptive commit message, for example:

feat: add order status filter to customer order history

Then follow the deployment process in Development Security. Branch roles are in Local sandbox.

Stage	Action	What to verify
Feature branch	Commit the reviewed implementation	Diff is clean, tests pass, no unrelated changes
Local sandbox	Exercise the feature using test accounts and orders	Filtering works and customer data remains isolated
staging, if configured	Deploy the branch to the staging Hosting backend	The deployed feature behaves correctly and the staging URL remains protected
main	Merge after the required checks pass	Production configuration is correct and no unrelated changes are included

For a feature that only changes the frontend, this process may be relatively straightforward. If implementation or review reveals changes to schema authorization, Lambda functions, authentication, payment handling, or the amplify/ directory, treat those as higher-risk changes and complete the relevant backend and security checks before deployment.

Do not merge directly to production just because AI says the feature is ready.

Prompt 7 — Prepare the merge summary

Prepare a concise pull request or merge summary for this feature.

Include:

• What changed and why.
• The files and application areas affected.
• The tests and checks actually completed.
• The manual verification performed.
• Any security-sensitive areas reviewed.
• Known limitations and outstanding risks.
• The recommended deployment sequence.

Clearly distinguish completed checks from checks that still need to be performed. Do not claim that a deployment, review, or test has succeeded unless there is evidence that it has.

Do not merge or deploy anything. Leave the final approval and merge decision to the maintainer.

8. What This Example Teaches

The order filter is a small feature, but it demonstrates a development workflow that can scale to more complex changes.

Principle	How to apply it
Plan before coding	Ask AI to inspect the actual codebase and propose a minimal implementation
Keep changes focused	Avoid unrelated refactoring and unnecessary architectural changes
Test behavior, not just compilation	Verify normal flows, edge cases, and existing functionality
Treat security as a boundary	Check authentication, authorization, secrets, and sensitive backend operations
Use AI as a reviewer, not an authority	Require evidence, file references, and concrete test results
Fix issues deliberately	Review proposed fixes before allowing more changes
Deploy incrementally	Validate the feature in the sandbox and staging before production
Keep humans accountable	The maintainer makes the final decision to commit, merge, and release

The same process applies to larger features, but the scope of testing and review should increase with the risk of the change. A UI adjustment does not need the same investigation as a new checkout flow or an authorization change.

The goal is not to make AI development slower. It is to make fast development predictable, reviewable, and safe enough to ship.