An AI-Built App Broke After a Change. What Should You Send for Help?
By Zechariah Myrick · September 23, 2026 · 7 min read
If an app you built with AI stopped working after a change, send a small reproducible issue packet: one link or version, the exact path to try, what you expected, what happened instead, and the smallest safe example. That gives a skilled reviewer something they can open and test. A long prompt history, a screenshot with no steps, or ‘it is broken now’ usually does not.
This is for a person in Naples or Collier County who has already made something real with ChatGPT, Claude, Grok, Gemini, a no-code tool, or generated code: perhaps a project dashboard, a family-story organizer, a product chooser, or a simple internal workspace. You do not need to diagnose the code. Your job is to preserve the evidence of one failure before another change hides it.
Start with one path, not every problem
A reproducible problem is one another person can follow and see. Pick the first path that fails. For example: ‘Open the fictional garden-plan demo, choose Spring Notes, press Save draft, then the confirmation never appears.’ Compare that with ‘saving is weird.’ The first gives a reviewer a starting point; the second makes them guess which screen, version, account, data, and result matter.
- The version or address: the deployed link, repository branch, download, or dated file that showed the failure. Do not send credentials or a private production database.
- The steps: three to six actions from a fresh page to the failure. Include any test choice needed to reproduce it.
- Expected result: the visible behavior you had approved, such as ‘a draft confirmation appears and the title remains unchanged.’
- Actual result: the observation, error message, blank screen, wrong value, or unexpected navigation. Copy the exact message when it is safe to share.
- A safe example: fictional, public, or approved test material that lets someone repeat the path without client records, secrets, payment information, or private files.
Make a before-and-after record before asking AI to repair it
Generated code can make a fast-looking repair that changes a different part of the app. Preserve the last known good version, the change made just before the failure, and a screenshot or short screen recording of the result. Then ask one bounded question: ‘Using this issue packet, explain what you need to inspect before proposing a fix.’ Treat an explanation as a lead to test, not proof that the AI has found the cause.
Git and GitHub are useful here because version control records changes and lets a project keep a history while work is reviewed and merged. You do not need to become a software engineer to benefit from the principle: name the working version, name the changed version, and avoid overwriting the only version that still works. GitHub's overview of Git explains the version-history model in plain terms.
A fictional issue packet example
Imagine a fictional studio has a one-page ‘scene chooser’ for an original children’s story. Yesterday it showed three approved scenes. After an AI-assisted layout update, the third scene button opens a blank panel on a phone.
- Review address: `https://example.test/story-scenes` on the September 23 preview.
- Steps: Open the address; choose ‘Harbor’; press ‘Lantern scene’; rotate the phone once.
- Expected: the approved lantern scene opens with its caption and Back button.
- Actual: a blank content panel appears; the Back button remains visible.
- Boundary: use the provided fictional scene names only. Do not connect a real account, upload a manuscript, or replace the working desktop path while investigating.
- Next decision: repair the phone path, keep the previous layout, or pause for a scoped review if the cause cannot be confirmed.
That packet is enough for a developer, an independent project reviewer, or an AI coding assistant to begin responsibly. It does not prove a repair will be small, and it does not authorize a change to the rest of the project.
What a careful reviewer adds
A careful review connects the reported path to the actual version, checks whether the failure can be reproduced with safe material, identifies which assumption still needs evidence, and tests the proposed repair without silently changing approved behavior. That aligns with the practical intent of NIST's voluntary AI Risk Management Framework: build trustworthiness considerations into the design, development, use, and evaluation of AI systems. It is a useful discipline for a small project, not a certification or guarantee. Read the NIST AI RMF overview.
When the issue packet is not enough
Pause and get the right specialist involved if the failure touches payments, health information, legal advice, security controls, regulated data, a live customer workflow, or a system that can take an irreversible action. Keep the app read-only or return to the last safe version while the boundary is clarified. For a smaller project that first needs a shareable path, see what makes an AI-generated app reviewable. For material that must survive a change of builders, keep the broader AI project handover package.
AI Dream Builders provides independent, hands-on help with existing AI projects in Naples; we are not account support for any AI provider. If you have a real project stalled by one repeatable problem, describe what you want the app to do and where the path fails. Include the tool, intended result, actual result, and a safe test path—never passwords, keys, private customer data, or confidential source files. We can discuss a scoped paid review, a safe repair path, or a clearer next version before you choose further work. Learn more about the studio on About or see the kind of project work we discuss on Work.
Sources and local context
- What is GitHub? — GitHub Docs
- AI Risk Management Framework — National Institute of Standards and Technology