Repair an AI-generated app: scope the first fix
How to scope a first paid repair for an app built with AI, reproduce the failure and decide whether a rewrite is actually needed.
You have built an application with a coding agent. Some screens work, but an invitation fails, access looks wrong or deployment behaves differently from your local environment. Before commissioning a rewrite, turn that observation into a failure someone else can reproduce.
Knowing that AI helped produce the code does not establish how much of it should be replaced. A first repair should help identify what is broken and what can remain.
Describe the failure precisely
Provide the steps, expected result and observed result. Identify the version and environment. Useful logs can be shared after removing credentials and unnecessary personal information.
“Signup is broken” leaves many possibilities open. A better report states which kind of user takes which action and where progress stops. If the cause is unknown, investigating that reproduction can be the first paid engagement.
An exposed credential needs attention before further workflow testing. OWASP's secrets-management guidance covers revocation and rotation. Removing a key from a screenshot or file does not establish that the credential has stopped granting access.
Buy a bounded repair
The proposal should name the behavior to fix and the areas that need inspection. For example, an invitation might lose the account context. Repairing it could include access checks and a regression test without replacing the entire interface.
Set a limit for the investigation. If the work does not reveal a viable repair within that scope, the deliverable should explain the findings and available options. Extending the work requires another budget and timing decision.
Ask for before-and-after evidence
| Check | What it helps establish |
|---|---|
| Reproduce the failure on an identified version | That the reported problem is being addressed |
| A test fails before the change and passes afterward | That the fix covers that behavior |
| Check permissions using different users | That the repair works beyond the developer's own account |
| Exercise related workflows | That nearby behavior has not been broken |
| Document how to return to the previous version | How the team can respond to a release problem |
The right checks depend on impact. Local tests may not cover a failure caused by deployment configuration. Record that distinction rather than presenting a local result as proof of every environment.
Compare repair with replacement
A rewrite recommendation should identify a concrete obstacle. A dependency may prevent the necessary change. Access rules may be scattered across the application, or modifying one feature may affect several others with no clear separation.
Compare a focused repair, partial replacement and a rewrite. Include data migration and the product behavior that would need to be tested again. Base the decision on the inspected system and the business outcome it must support.
Make the result transferable
For an agreed repair, the handover includes the reviewable change, tests and instructions for checking it. If the engagement ends with the investigation, the handover contains the agreed findings and options. It should also state what remains out of scope. Keep accounts and credentials under the agreed ownership. Maintenance after delivery needs explicit terms.
For help with your application's architecture or an integration, send the failure you can reproduce. At Pharosyne, I can scope a first repair or technical review, with scope and price agreed before work begins.
Related service
LLM integration
Add models to your product with evaluation, limits and observability.