# Why AI Photo Editing Needs More Than a Good Prompt > Source: > Published: 2026-11-05 04:41:31+00:00 A prompt can describe a convincing scene. A useful photo editor also has to preserve the parts of the image that the user never asked to change. Consider a simple request: put a ceramic mug on a different background. The background may look excellent while the handle changes shape, the glaze becomes smoother, or the small lettering drifts. The image succeeds as a composition and fails as an edit. A reliable workflow has to answer two questions: did the requested change happen, and did everything else remain acceptable? “Make this photo better” leaves too many decisions open. Separate the intended change from the constraints: These constraints do not guarantee model compliance. They establish a review target. Masks can narrow the edit region, but transparent materials, thin chains, and openings still need inspection. An output can be a valid image file and still be the wrong result. File checks can establish that an image decodes, has the expected dimensions, and uses a format that supports transparency. They cannot establish that a label still says the same thing or a reflection makes physical sense. Use separate checks: Automate objective rules. Keep a side-by-side view for visual judgments. A thumbnail helps assess composition; lettering and edges need full-size inspection. **Repeated submission:** the user clicks twice or a client repeats a request after losing a response. This should not accidentally create two independent paid jobs. **Transport retry:** a temporary provider condition, such as throttling, triggers a bounded retry policy. **Creative retry:** the user wants another result because the first image is unsatisfactory. This is a new decision, with its own cost and output history. These operations should not share one undifferentiated “Try again” path. A timeout does not prove that remote generation never started. A useful task-creation pattern is: ``` begin transaction find existing task by workspace and idempotency key if found: return existing task create task and reserve credits commit enqueue task after commit ``` This is a control-flow sketch. A production implementation also needs to handle concurrent requests and enforce the intended uniqueness in its persistence layer. Application-level idempotency does not make an external provider call exactly-once. If a provider completes work but the response is lost, blindly calling it again can still duplicate remote work. Provider request IDs, status reconciliation, and explicit uncertain states matter where supported. [PicViva](https://picviva.ai/en?utm_source=devto&utm_medium=article&utm_campaign=beyond_prompts) provides a concrete implementation example: task creation includes a workspace-scoped idempotency lookup, task creation and credit reservation happen in a transaction, and queueing is deferred until after commit. Its shared external-call wrapper retries qualifying throttling failures within a configured attempt limit, using increasing waits. Other errors are propagated. Those choices address submission and accounting consistency. Visual quality remains a separate concern. The general design principle is to give each concern its own owner: A resize may cut through the subject. A transparent image may be flattened unexpectedly. A preview may hide that the downloaded file has different dimensions. Check the actual downloaded output. Keep crop position explicit and choose transparency deliberately. Review every channel-specific version rather than assuming one successful crop transfers to every aspect ratio. Choose three inputs: a straightforward subject, one with difficult boundaries, and one with readable text or reflective material. Run the same task and record what needed correction. Count accepted outputs, retries, and review effort. Reuse this acceptance set when changing a model, prompt, or export step. The prompt remains important. The surrounding workflow makes its result inspectable, recoverable, and ready to use.