Events photography is my hobby. Among all of them, Tanzabend in Darmstadt always draws me back, and a night there concludes exactly the same way each time: I return home carrying 2,000 to 3,000 images captured in challenging lighting conditions with subjects who are constantly in motion. Buried somewhere within that collection are the shots worth preserving.
That search is where the actual effort lies. You require denoising that produces clean enough results to evaluate images in poor illumination, and you need to navigate between photos without any hesitation, because sifting through 3,000 images means even a fraction of a second delay drains most of your evening. Applications capable of this do exist, but their pricing targets professionals who bill customers. I don't bill anyone. So I created it myself.
That is not what makes this story worth telling. Photographers have coded their own utilities before. What makes this interesting is that I wrote almost none of it, and how that completely upended the cost-benefit analysis of building something just for yourself.
The app I discarded
I put together an initial version back in April as a web application. It functioned adequately, but by summer I felt the urge to rebuild it on sturdier ground. So one late July morning I outlined my vision, and an agent generated a specification followed by a brand-new web application. Going from a fresh branch to an open pull request consumed roughly 55 minutes.
Forty-eight hours later I tore it all down. A single message sufficed: let's start from scratch.
Seven days on, the entire repository had been scrubbed clean: seventy-eight files, over 11,000 lines of functioning code, removed in one commit, because what I truly needed, rapid RAW decoding and heavy-duty denoising, resides within Apple's native frameworks, and no web-based approach would ever access it. Erasing that much working code used to be a gut-wrenching choice you would talk yourself out of making. When the code cost you a morning rather than a month, deletion becomes mere editing. That web app was never a disaster, it was a prototype, and prototypes belong in the trash.
Forty-eight hours
The native rebuild began Friday morning inside an empty repository. By Saturday night, version 0.1.0 was out: a signed, notarized macOS application with a Swift engine handling all image processing.
My involvement bore no resemblance to traditional programming. The agent and I spent the opening hour in a back-and-forth exchange that yielded a feature catalog and an implementation roadmap divided into phases, each protected by its own test checkpoint. After that, my messages usually consisted of just two words: start with phase 1. Commit and push. Continue.
I also attempted something that felt mildly ridiculous and ended up being the wisest call of the weekend: I launched a second session dedicated entirely to auditing what the first one produced, acting as a messenger between the two. The reviewer operated with its own context, executed every test suite independently, and each cycle it uncovered genuine bugs that the builder's passing test indicators concealed, including a vulnerability where a specially crafted project name could write files beyond the photo library boundary. My complete review routine, from my end, was typing a single word: rereview.
During the following week I kept working through evenings and weekends: curves editing, zoom, crop and straighten tools, an auto-updater, an AI rating capability, a landing page. Within one two-day window I sent 88 messages and the agents executing them performed roughly 2,100 actions, from editing code to driving the application and submitting pull requests. Every feature began as a page of disposable HTML design mockups with lettered variants, and my design review boiled down to replying with something like "A3 + S2 + G2."
Trusting code you never authored
The immediate question: how can you trust thousands of lines you never personally scanned?
You can't, and that is precisely the insight. Before any change gets merged, adversarial review agents scrutinize it, each pursuing a single objective: correctness bugs, data loss, security vulnerabilities, unnecessary bloat. Their findings also aren't accepted blindly. Independent verification agents attempt to reproduce each finding in practice. One proved, against a specially crafted file, that a bug could have permanently obliterated orientation data in original photos. This second layer caught regressions in proposed fixes twice before anything reached the commit stage.
The process still isn't flawless. One evening the application froze while I was editing genuine photos from a shoot. The culprit was the agent's own mistake: every adjustment appended a complete tone curve to the photo's metadata file rather than replacing the existing one, until one file accumulated 4,400 curve points and each save operation took seconds. What reassured me wasn't the bug's existence. It was what followed: the agent acknowledged plainly that the freeze was its fault, corrected it, wrote a regression test, and repaired the corrupted file in my actual photo library.
Where the limits lie
Autonomy has boundaries, and I encountered two of them.
The first boundary is taste. The one feature I rolled back twice was the workflow, the fundamental question of how you actually progress through a photo shoot. The agent constructed precisely what I requested, and my request was flawed, and additional building would not have fixed it. What actually helped was the agent setting down its tools and asking me questions until I understood my own workflow well enough to articulate it. Agents vastly outperform humans at the mechanical tasks. The "this is the feature, this ships" portion has not shifted one bit. It simply gained considerably more leverage.
The second boundary is consequences. Agents do not ship products. But they made shipping so effortless that releasing ceased to be a milestone. The entire pipeline is agent-built: a release is a single command that opens a pull request with the version bump, a changelog, and fresh screenshots captured by driving the actual application. CI signs and notarizes the build, and the updater picks the new version up on its own. The sole remaining step is the merge, and that stays intentionally mine. Seven releases across eight days does not reflect discipline. It reflects that each one costs me a single command.
The app I didn't set out to make
Here is what my photo workflow looked like back then:
memory card, 2000-3000 ARWs
│
copy to disk
│
Adobe Bridge cull, first pass through the night
│
copy the picks to a new folder
│
DxO PureRAW batch denoise, wait, DNGs land in yet another folder
│
editor?
├── Lightroom wait for everything to upload
└── Luminar wait forever for every single adjustment
│
edit exposure, curves, crop
│
export JPEGs
│
manage the pile ARWs, picks, DNGs, edits, all separate foldersThree applications, a copy operation between each pair, and constant waiting: for PureRAW to finish its batch, for Lightroom to push everything to a cloud I never requested, for Luminar to process each adjustment at its own speed. Here is that same workflow today:
memory card, 2000-3000 ARWs
│
copy to disk
│
open the folder in Photopipe
│
cull denoised previews, arrow keys, ratings, AI presort
│
edit sliders, curves, crop, same window
│
export JPEGs edits baked in, ratings stay in the filesA single application reading one folder, with the filesystem as the sole truth. The denoising still runs, it just completes so fast you never notice.
The surprising thing is that I never meant to construct an editor. Photopipe was only ever going to help me cull, editing would stay where it always had. A tone curve, highlight and vibrance sliders, exporting a polished image: that was premium software, the kind you pay for, not the kind you cobble together between weekends. But it is all there now, because every time I reached the point where I would normally jump to another app, I described what was missing to an agent instead, and by the next evening it existed. The reasons to leave the app faded away one by one.
Now the entire workflow, from card to final export, lives inside one responsive tool that belongs to me. No external utilities, no reliance on someone else's cloud, no clunky interfaces built for someone else's needs. When something is missing or broken, I do not submit a feature request and cross my fingers. I just build it or fix it. And because it is open source, anyone can use it, fork it, and add whatever features matter to them.
Did it work?
For culling, yes. Going through a night of photos is genuinely easier, and the denoising means I can judge sharpness and expression in shots I would previously have squinted at.
Looking back, I accidentally built the best Lightroom alternative for my use case. It doesn't do everything, and it doesn't need to. It just does the things I actually do, without the subscriptions, the cloud dependency, or the interface bloat. And it does it blazing fast. That was never the plan, but it's exactly what I needed.
One honest caveat: Photopipe has an AI rating feature built on Apple's aesthetics scoring, and it is still far from human taste. I benchmarked it against my own keepers and rejects from real shoots. It has a good tendency, better than random, and that is all I can claim. It does not know that the slightly blurry photo is the one where everyone is laughing. It sorts the pile. It does not pick the picture.
Which is the whole project in miniature. The machines sort the pile now. Picking is still mine.
Photopipe is free, MIT licensed, and runs entirely on your Mac. You can get it at photopipe.net.