Before AI Writes Code, Ask It to Inspect Your App

Your app already has a login page, buttons, saved data, and design rules. If you ask AI to add a feature immediately, it may miss those parts and build a second version beside them.

The safer first request is simple: inspect the project and report what is already there. Do not change anything yet.

What does “inspect the app” mean?

Inspection does not mean reading every file. It means following the part of the app that your request may touch.

For example, before adding a Download Invoice button, the AI should find:

• The page that shows one invoice.
• The existing button and layout patterns.
• The place where invoice data is loaded.
• The rule that decides which customer can see it.
• The commands the project uses to build and test.

This gives the AI a map. Without that map, it may create a duplicate component, read the wrong data, or skip an access rule.

When is an inspection worth the extra step?

You can skip a plan for a clear, tiny change, such as fixing one spelling mistake. Inspect first when any of these are true:

• The app already has several pages or shared components.
• The change touches login, payments, customer data, or file uploads.
• The feature will change more than one screen.
• You do not know where the current behavior comes from.
• A previous AI change broke another part of the app.
• You care about matching an existing design.

GitHub recommends using a coding agent to research a project and agree on a plan before code is written. Anthropic describes the same pattern as “explore first, then plan, then code.” Read GitHub’s guidance and Anthropic’s Claude Code best practices.

What should your first request say?

Tell the AI what area to inspect, why you need the report, and that this is a read-only task.

I want to add a Download PDF action to the invoice detail page.

Before changing anything, inspect only the parts of the project related to:
- the invoice detail page
- how invoice data is loaded
- customer access rules
- existing button and download patterns
- the project's build and test commands

Report in plain English:
1. How the current invoice flow works.
2. Which existing parts can be reused.
3. Which files would probably need to change.
4. What could break, especially customer access.
5. Any business decision you need me to make.

Do not edit files, install packages, change data, or deploy anything.

The word “only” matters. It keeps the inspection near your task instead of filling the conversation with unrelated files.

What should a useful inspection report contain?

A useful report should help you make a decision even if you cannot read code.

1. Current journey: where the user starts and what the app does now.
2. Reusable parts: existing pages, buttons, data rules, or helpers that fit the job.
3. Likely changes: a short list of areas the AI expects to edit.
4. Risks: working behavior that could be affected.
5. Open choices: questions about customers or the business that code cannot answer.
6. Verification: checks that can prove the feature works.

If the report is full of technical names, ask for a second version:

Explain that report again for a nontechnical founder. Keep the exact risks and decisions, but describe each one as a user action and visible result.

How do you approve a plan without understanding the code?

Review the plan through customer behavior. Ask these questions:

• Does it serve the right user?
• Does it change only the requested journey?
• Does it reuse the app’s current design and data?
• Does it protect the same login and access rules?
• Does every completion check describe something visible or measurable?

You do not need to approve a file name. You do need to approve a change to who can see an invoice.

How can you confirm that nothing changed?

At the end of the inspection, ask the AI to state whether it changed files, installed anything, edited data, or contacted an outside service.

Before we continue, confirm whether this inspection changed any file, package, setting, database record, or live service. If anything changed, list it exactly and do not make another change.

A coding tool with project history may also show a list of changed files. The correct result for this step is an empty list.

What should you say when the plan looks right?

Start a second, smaller request. Refer to the approved plan and repeat the important limits.

Implement the approved Download PDF plan.

Keep invoice calculations, payment status, login, and customer access unchanged. Reuse the existing button style. Do not add a new service or package without asking first.

After the change:
1. Run the project's existing checks.
2. Test one paid and one unpaid invoice.
3. Confirm that one customer cannot download another customer's invoice.
4. Report changed files, test evidence, and anything you could not verify.

Stop and ask if the project differs from the inspection report.

What if the AI starts coding during inspection?

Stop it early. Do not continue from a change you did not approve.

1. Ask it to stop and list every change it made.
2. Use the tool’s checkpoint, undo, or version history to return to the starting point.
3. Confirm that the changed-file list is empty.
4. Repeat the inspection request with the read-only limit at the top.

If the area involves real payments or customer data, ask a developer to review any uncertain change before it reaches customers.

What should you read next?

• Use the six-part template for better AI coding instructions.
• Turn the approved plan into small AI tasks.
• Learn which app settings must stay private.

When the app is ready for real users, JustDeploy gives it a place to run with the services it needs.