ShapedSI Journal · Web & software
App rescue for AI generated code: establish a reliable next release
When an app has been assembled through several rounds of AI coding, the next useful step may be understanding the current state. Start with the repository, the way it is run and the failure you can reproduce. A rescue should make the next release reviewable, with a clear account of what works and what still needs attention.
In this guide
01
Establish a starting point
Keep a recoverable copy before making changes. Record the version of the code, the configuration needed to run it and the environment where the problem occurs. Identify the person who controls the hosting and relevant accounts. Access should be specific to the work being done, with credentials handled through the appropriate private configuration.
Choose one failure that can be reproduced. Describe the steps, expected behaviour and actual result. If the app will not start, begin there. If a customer journey fails, test that journey. Avoid adding another feature while nobody can explain whether the existing version builds and runs reliably.
02
Triage the work by consequence
List the issues and separate release blockers from improvements that can wait. A broken sign-in, lost submission or incorrect purchase path has a different consequence from a spacing adjustment. Ask the owner which journey needs to work for the next useful release. Keep the scope small enough that it can be checked properly.
Read the relevant parts of the implementation before changing them. AI generated code may include assumptions, duplicated behaviour or configuration that was never completed. Confirm how the affected feature is supposed to behave. Treat an explanation from a coding tool as a suggestion to inspect, rather than proof of how the running app works.
03
Fix a slice and check the behaviour
Make a focused change with a clear reason. Run the appropriate checks and test the journey that triggered the problem. Include the error or incomplete case where it matters. Avoid a test that merely repeats the implementation without demonstrating the behaviour the owner needs.
Review the change and the result together. A successful build does not prove that a form reaches the right destination or that a person can complete a task. Record what was verified, the environment used and the limits of the check. Keep production changes separate from an unverified local result.
04
Leave a usable handover
Document how to run, build and release the app, along with the configuration and accounts it depends on. Keep a short list of the remaining issues and the next proposed slice. If the owner changes developers later, those notes should help the next person understand the starting point.
Discuss ongoing changes only after the next release is clear. Agree on review, testing and approval before merging or publishing. A rescue is more useful when it reduces uncertainty for the owner and leaves a maintainable route forward, rather than replacing one unexplained build with another.
Bring this to the conversation
A working brief.
- A recoverable code and configuration copy
- A reproducible failure
- A release blocker list
- Focused behavioural checks
- Run, release and handover notes
A few useful questions.
Should we rewrite the whole app?
Only after understanding the current problems and the cost of preserving useful parts. A focused repair may be the better first decision.
Is an AI code review enough to approve a release?
No. Review the suggestions, inspect the change and test the relevant behaviour with the person responsible for the app.
Original sources
Sources and further reading.
GitHub’s documentation says Copilot review can miss issues or make mistakes and should be supplemented by human review. Required reviews and status checks can help structure a release process.
Shape the next step