Should I vibe code
Desktop photo editing with AI adjustments, effects, and asset extensions
The AI masking is the easy half. Colour-correct RAW from your actual camera is the decade-long half.
?
Their verdict, the Perpetual Desktop License price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The demo here is deceptively excellent, which is the trap. Segmentation models are a download, an inpainting model will erase a lamppost convincingly, and a stack of sliders over an 8-bit JPEG genuinely looks like a photo editor by Sunday evening. Then you drop a .CR3 on it and meet the actual product: demosaic, camera-specific colour profiles, lens correction data, highlight reconstruction, a 16-bit working space, an ICC-aware display path, and a non-destructive edit graph stored against a catalogue. None of that is the AI part and all of it is what separates "an image got brighter" from "the photo is right". The good news is the failure mode: this runs on your machine, on your photos, with no account and no strangers, so the worst case is a wasted fortnight — with one exception. Let it write over originals and the wasted fortnight becomes a permanent hole in your archive.
What actually breaks
not "if". the specific failures.
- RAW decoding, which is a per-camera-body problem forever: libraw covers a great deal and "a great deal" stops being reassuring the day you buy a body released last month
- Colour management, where an editor with no working colour space and no display profile produces images that look correct to you and wrong to everyone you send them to
- The catalogue, which is the only record of every non-destructive edit you have ever made and is one careless migration away from being a folder of untouched originals
- In-place writes — the moment Save overwrites the file the camera produced, there is no version of this app that is safe to leave running
- Memory and GPU: a 60-megapixel file through four models is not an interactive experience on an integrated GPU, and the tiling code you write to fix that is where seams come from
- Mask edges on hair, glass and foliage, which is exactly where generic segmentation models fail and exactly where anyone who retouches for a living looks first
- Model licences, because a lot of the best segmentation and inpainting weights are research-only or non-commercial, and that matters the moment you sell a print
- Metadata on export: EXIF, orientation and the ICC profile silently dropped is the classic corruption nobody notices until a client asks why the colours changed
- Undo across a long edit session, which is a history graph rather than a stack once masks and layers are involved
Is that you?
the verdict is a default, not a law
- It is your own library, on your own machine, and originals are opened read-only
- Every edit lands in a sidecar or a database, never in the file the camera wrote
- You are building a specific effect you keep doing by hand rather than a general editor
- The output goes next to the original with a new name, and you would be fine deleting the whole project tomorrow
- The app can overwrite or move originals, which turns a hobby project into an archive risk
- Your only copy of the photos is the folder this thing is pointed at
- The edits are billable and a client is expecting colour they can print
- You are shipping model weights whose licence you have not actually opened
If you build it anyway
the checklist, then the prompt that enforces it
- Open originals read-only at the filesystem level and prove it. Every edit is a sidecar or a database row; the RAW file is an input, never an output.
- Write export before you write a single adjustment. If you can produce a correct file with metadata and profile intact, the rest is decoration.
- Use an established RAW pipeline — libraw, darktable's or RawTherapee's — rather than implementing demosaic. This is decades of camera-specific correction you cannot reproduce.
- Declare and carry a working colour space end to end, and test against a known target. An editor with no colour management is a random-number generator with sliders.
- Back the catalogue up automatically before every schema change, and keep a plain-text or JSON export of edits so the history survives your own database.
- Check the licence of every model you bundle and record it in the README next to the weight file, before you have built anything on top of it.
- Work on a proxy for interaction and re-run the pipeline at full resolution only on export, or the app will feel broken on the files you care most about.
I am building a desktop photo editor with AI adjustments — masking, sky
replacement, object removal — over my own RAW and JPEG library. The one
unrecoverable outcome is damaging originals, so start there.
1. Open every source file read-only and say in the README how that is enforced.
The app must have no code path that writes to, renames or moves an original.
If I later ask for in-place editing, refuse and explain why.
2. Build export and non-destructive storage before any adjustment: edits live in
a sidecar file or a database row keyed by a content hash, and an export
writes a new file beside the original.
3. Preserve EXIF, orientation and the ICC profile on export, and assert it in a
test with a real camera file.
4. Use libraw or an existing RAW pipeline. Do not implement demosaic, highlight
reconstruction or camera colour profiles yourself. Tell me which camera
models the chosen library does not cover.
5. Declare a working colour space, carry it through every operation, and verify
against a known colour target before I trust a single slider.
6. Auto-backup the catalogue before any schema migration, and provide a JSON
export of all edits so the history outlives your database format.
7. Interactive edits run on a downscaled proxy; the full-resolution pipeline runs
only on export. Show me the timings for a 60-megapixel file.
8. For each AI model you bundle, record the source, the licence and whether
commercial use is permitted, in the README, before writing code that uses it.
Stop and ask if a licence is research-only.
9. Run models locally. If a feature would need a hosted API, tell me first — that
changes this from an offline tool into a service that has my photographs.
10. Fail visibly on unsupported files rather than silently producing a
grey-green approximation of a photo.
11. Out of scope until I ask: cloud sync, a shared library, face recognition
across the collection, and generative fill. Each is its own project.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Buy if you shoot RAW and care what the colours do. A one-time Luminar licence — or darktable, which is free — is buying a decade of camera-specific colour science that has nothing to do with the AI features on the box, plus new-body support arriving without you doing anything. Build the narrow thing instead: the batch watermarker, the specific look you apply to every photo, the culling tool that matches how you actually work. Those are excellent weekend projects and none of them requires you to own a RAW pipeline.
The exit is unusually clean if you obey one rule: never touch the originals. Keep edits in sidecars — XMP if you can bear it, JSON if you cannot — and the exit from your own editor is deleting an app and keeping a folder of untouched RAW files plus exported JPEGs. What does not transfer is the edit graph itself; nobody else reads your adjustment schema, so treat your renders as the artefact and re-edit anything you truly need in darktable or Lightroom. That is a real cost, and it is the reason to export finished versions as you go rather than trusting that your catalogue will still open in 2031.
Open-source RAW developer with a proper non-destructive pipeline and camera-specific colour handling.
Self-hosted photo library with indexing and search, if the catalogue half is what you actually want.
Questions
Why is this DEMO ONLY when nothing leaves my machine?
Because the verdict is not about danger alone, it is about the distance between the demo and the product. You will get a convincing sky replacement in a weekend and you will not get a RAW engine, ever, and the moment you edit photos you care about with something that has no colour management you are producing files that look wrong everywhere except your screen. The risk numbers are low precisely because this is local and single-user — that is why it is DEMO ONLY and not something harsher.
What is actually worth building here?
Anything narrow and repeatable. A culling tool that shows you pairs and keeps one. A batch exporter with your exact watermark, sizes and metadata policy. A script that applies a look you have already dialled in. These are genuinely better homemade because they match how you work, they run headless, and none of them requires you to be correct about demosaic.
Is the generative erase part really the easy bit?
Comparatively, yes. Inpainting and segmentation are downloadable models with good wrappers, and getting an impressive result on a chosen photo takes hours. What takes years is everything around them: mask edges that survive scrutiny at 100%, a pipeline that runs at 60 megapixels without seams, and results that are consistent across a hundred images from the same shoot rather than lucky on one.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Demosaicing is a library call. Making a Nikon and a Fuji agree on the colour of skin is somebody's whole career.
The AI half is one API call. So is the abuse: a stranger's photo, your GPU bill, your takedown obligation.
Premium unlocks no features. It hides an ad. Rebuilding a decade of PSD archaeology to dodge a banner is the trade.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice