Your app has an error. You paste it into an AI coding tool and say, "Fix this."
That sounds reasonable. But what if the app correctly refused an invalid booking? What if an outside email service is unavailable? What if a customer is asking for a feature you never promised?
An AI can produce a convincing code change for all three. None of them necessarily needs one.
On September 30, Cloudflare introduced Issues for Workers in open beta. It groups recurring exceptions, server errors, and error logs, then can send diagnostic context to a configured coding agent. That context includes the affected Worker version. Cloudflare describes a workflow where the agent proposes a fix and the owner reviews and deploys it.
The useful beginner lesson is not "your app can maintain itself now." It is that a reported failure can reach an AI faster, so you need a better decision about what the AI should do next.
I would classify the incident before asking for a patch. Otherwise, "make the error disappear" can quietly become "remove the rule that protected the app."
Start with the promised behavior
Imagine a small appointment-booking app. This is a hypothetical example, not a claim about a client project.
You promised that a customer can choose an available time, confirm a booking, and see that booking when they return. You did not promise that two people can reserve the same appointment, that email never fails, or that every business can support unlimited bookings.
Those distinctions give you a starting point for maintenance. Write down the behavior that should have happened, the behavior you observed, and which part of the promise was broken.
An error message alone is not enough. "Booking failed" might describe a defect, a sold-out appointment, or a temporary connection problem. The remedy depends on which one it is.
Five incidents, five different next steps
1. The app broke its own promise
You reserve an available appointment. The app says "Confirmed," but the booking is missing when you refresh. The same failure happens with a disposable test account.
That is a good candidate for a code investigation. Give the AI a repeatable example and a clear expectation. Ask for a test that fails before the repair and passes afterward.
Keep the change tied to that example. "Repair booking persistence" is a smaller, more inspectable task than "improve the booking system."
Next step: reproduce the defect, identify the responsible code, and propose a narrow repair.
2. The app correctly rejected a request
Two customers try to reserve the same appointment. One succeeds. The other sees a confusing error.
The reservation rule may be working. Removing the rule would make the screen look friendlier while creating a real scheduling problem.
The needed improvement is likely the recovery path: explain that the slot is gone, offer available alternatives, and preserve the customer's other choices. Test the two-customer case again to make sure the clearer message did not weaken the rule.
Next step: improve the explanation and recovery without changing the business constraint.
3. An outside service is unavailable
The booking is saved, but the confirmation email provider is down.
A patch to the booking code cannot make that provider healthy. Worse, an eager rewrite might accidentally create a second booking while trying to resend the email.
Decide what the app should do during the outage. In this example, I would show the saved booking in the app and distinguish it from the email's delivery status. An existing retry mechanism may need investigation, but that is a separate question from whether the booking exists.
Next step: preserve the correct result, communicate the degraded service, and investigate the delivery path separately.
4. The app hit an operating limit
An import works for ten appointments and fails for ten thousand.
That might be a defect. It might also expose an explicit file-size, processing-time, or service limit. First establish the supported workload. Do not ask the AI to disable a limit just because it interrupted a test.
A smaller batch, a background process, or a clearer upload boundary may be appropriate. Choosing among them requires a product decision about what you intend to support and what you are willing to operate.
Next step: confirm the limit, choose the supported workload, and design the handling around that choice.
5. Someone wants a different product
Your appointment app has one location. A customer wants several locations, staff assignments, and recurring group classes.
That is valuable feedback. It is not automatically a bug.
Put it in the product backlog with the user, the desired outcome, and the changes it would require. Ask whether it belongs in the current release. Treating every request as urgent maintenance is an easy way to lose control of a small app.
Next step: make a scope decision before asking the AI to build anything.
Keep a small incident record
You do not need a complicated operations dashboard to make this useful. A note in your project folder can be enough for a first app.
For each incident, record:
- What the user tried to do and what should have happened.
- What actually happened, including whether any action partially succeeded.
- The app version and environment: a local test, beta build, or live release.
- A reproduction using test data, with private details removed.
- Your current classification and the evidence that supports it.
- The person or service responsible for the next step.
- What evidence would let you call the incident resolved.
If you are unsure about the classification, write "unknown." That is a useful state. It tells the AI to investigate instead of treating your guess as a fact.
Cloudflare's Issues documentation describes its monitoring feature. You do not have to adopt that specific service to use this incident record. The same questions work with a screenshot, a test failure, or a carefully described customer report.
Give your AI a triage prompt before a repair prompt
Try this with a sanitized incident record inside your project folder:
Read the project description and the promised behavior for this workflow. Compare them with this incident. Classify it as a reproducible defect, expected rejection with poor recovery, outside-service failure, operating-limit problem, new feature request, or unknown. Show the evidence for your classification. Identify any action that may already have succeeded. Do not change code yet. Propose the smallest safe next check using test data, then explain what result would justify a repair.
After that check, a repair prompt can be specific:
Repair only the confirmed defect. Add a regression test for the reproduced case. Preserve the existing business constraints and unrelated behavior. Report the files changed, the checks actually run, any unresolved failures, and the evidence still needed before release.
These prompts do not make the AI infallible. They make its assumptions easier to see and challenge.
Keep "proposed" separate from "released"
A pull request is a proposed change, not a repaired live app. A passing test is evidence for the scenario it checks, not proof that every user journey works.
GitHub documents protected-branch settings for required reviews and status checks. Availability depends on the repository and plan. Check whether your rules apply to the account doing the work rather than assuming an administrator is covered by default.
For a small app, I would still keep a plain release note: the incident, the repair, the version released, the post-release check, and what to do if the problem returns. Then close the incident only after checking the promised behavior in the intended environment.
The point is not to make maintenance bureaucratic. It is to keep a fast AI from confidently fixing the wrong problem.
A practical next step for your first app
Choose one workflow in your app and write its promised behavior. Then classify one failure without editing anything. If you cannot tell which category it belongs to, your next task is collecting evidence, not generating more code.
My $1 AI App Builder Starter Prompts guide beginners from an idea to a first working build. AI App Builder From Zero is $9 and continues through testing, publishing, and launch, with all 40 starter prompts included as a free bonus.
Review Radar is coming soon. It combines public app-review research with an app-specific project folder, screen designs, and sequenced build guidance. Explore the preview and join the email waitlist. It is not available for purchase yet, and no downloads, users, or revenue are promised.
Fix the broken promise. Explain the expected rejection. Manage the outside dependency. Decide the operating limit. Scope the new request. Those are different jobs, even when they all arrive as "an error."
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim
Top comments (5)
Incidents 2 and 3 share a trap that the "make the error go away" prompt walks straight into: both are about what happens on a second attempt.
For the double booking, the rule only counts if the database enforces it, for example a unique constraint on (resource, time slot). An app-level "is it free?" check passes for both customers when their requests land together, and an agent asked to quiet the confusing error can easily swallow the constraint violation instead of surfacing it. A good acceptance test is two simultaneous requests for one slot, with exactly one success.
For the email outage, the risky patch is the one you mention: a retry that re-runs the booking path. Keying the email on the booking id (one row per booking and message type, with a status) makes a resend safe and gives you the "saved, email pending" state to show the customer.
If the incident record had a field for "what must stay true after the fix" (one booking per slot, one email per booking), the agent's patch could be checked against it instead of just against the error disappearing.
That invariant field makes the acceptance check much clearer. I would add one failure-injection case: the booking is committed, then the worker stops before recording the email outcome. On restart, the test should show the original booking, a visible notification status, and no second reservation. I'd keep the email delivery guarantee separate from the booking guarantee so 'retry passed' cannot quietly mean that only the happy path was exercised.
Agreed on keeping the two guarantees apart. One thing that makes that injected-failure case sharper: kill the worker at two points, not one. Right after the booking commit and before the outbox row is written, and again after the email provider accepted the send but before the status update. The first should end with a pending notification the retry picks up; the second is where a duplicate email can happen, so the assertion there is 'at most one reservation, and the duplicate is either suppressed by a send key or recorded as a known at-least-once case'. If the test only ever kills at the first point, a passing retry says nothing about the second.
The after-provider-acceptance case is the important second test. I'd tighten the first boundary too: with a transactional outbox, the booking and pending-email row should commit in the same database transaction. Killing the process before that commit should leave neither; killing it just after should leave both. Otherwise a committed booking can have no durable notification for the retry worker to discover. That makes the tests distinguish a missing send intent from an uncertain send outcome, instead of treating both as the same retry failure.
Fair correction, and it changes my first kill point. If the booking and the outbox row share one transaction, there is no window between them to kill in: the assertion becomes 'neither or both' after a crash at commit, which is a stronger test than the one I described. A test can check it by killing mid-transaction and then counting rows in both tables.
That leaves the second point as the only place a duplicate can come from. The two failures then map to two different assertions: a missing send intent is a data bug (a booking with no outbox row should be impossible), while an uncertain send outcome is expected at-least-once behaviour that the send key has to absorb.