I let AI write 182,688 lines. Then I deleted 42% of them — and it got faster.

The very first commit is a 228-line Python script called PhotoRanker. It opens a black Tkinter window, shows you two of your photos side by side, and waits. You click the better one. It updates a chess Elo rating for both, loads the next pair, and waits again.

That's the whole idea, and it's a good one. A 1–5 star scale collapses under its own subjectivity by the third shoot — is this sunset a 4 or a 5? Elo sidesteps the question entirely. Every click is a tiny, honest comparison, and thousands of them resolve into a single global order. The best photos naturally rise; the pairing is even biased toward the current top ten, so your leaders keep getting stress-tested against each other.

In February 2026 the project restarts as a web app. Two commits. The Tkinter window becomes a FastAPI server and a dark HTML page. But the interesting change isn't the stack — it's a new way to ask the question.

Instead of a strict two-up duel, there's now a mosaic: a grid of candidates where you pick the single standout and everything else takes a small loss. More judgments per click, less fatigue. The same Elo math, fed faster.

April 21st is the most important day in the whole history. Read the commit list in order and you can watch a tool become a product:

CLIP active learning → a unified bottom bar → an AI panel with effective-Elo pairing → a Library page with a justified grid and AI search → Qwen3-VL-Embedding-8B for state-of-the-art search → rename PhotoRanker → photoArchive → lightbox, find-similar, duplicate detection, EXIF, k-means auto-collections → Qwen3-VL-2B-int4 "to fit the GPU alongside other apps."

The core realization: a photo library shouldn't make you type tags. It should understand the pictures. Embeddings turn every image into a vector; suddenly you can search "golden hour over water" in plain language, find everything visually similar to a frame you love, and cluster a shoot automatically — all without a single keyword.

With intelligence in place, photoArchive got obsessed with speed — the way only a tool you use every single day can. Over four days the commit log reads like a benchmark changelog, and each win came from the same move: stop asking the slow disk, and answer from memory.

The headline win — thumbnails 30–50× faster — is almost embarrassingly simple in hindsight. Every thumbnail request was doing an os.stat() on a spinning HDD plus a lock-contended SQLite lookup, even for images already sitting on the SSD. The fix: build a (size, image_id) → path dictionary once at startup and never touch the database on the hot path again.

Over a single weekend, ~130 commits with names like refactor: drain compare route facades land back to back. A monolithic app.py is dismantled into feature modules; the thumbnail cache becomes its own package; every route, every controller — loupe, mosaic, date-scrubber, pregeneration — is extracted and given a home.

It's tedious to read and it was surely tedious to do. But you cannot bolt a physically-modeled darkroom onto a ten-thousand-line file. This weekend is the foundation the entire second half of the story is built on. Boring, and load-bearing.

By summer the product vision crystallizes into a single sentence and a hard split. On the phone, photoArchive should feel like Google Photos — effortless, scrollable, one-handed. On the desktop, it should feel like Lightroom Classic — dense, keyboard-driven, serious. In June a native Kotlin/Compose Android client is born; in early July the desktop /d and mobile /m surfaces get a unified redesign with real writes, stacks, safe trash, share links, and smart collections.

This is the technical peak of the whole project. In three days, a full RAW develop module appears: a live WebGL2 pipeline with Lightroom-ordered panels, an interactive tone curve, HSL, a clipping histogram, crop, masking, and history — plus its own RAW decoder, its own color science, and a film emulation engine that models actual photochemistry.

Here's the central discipline of the whole module. Every editing operation exists twice: once in NumPy (the export truth) and once in GLSL (the live preview). If they disagree, your edit looks one way on screen and exports another — the cardinal sin of a photo editor. So both twins are pinned to a single shared constants table, and a test enforces that they land within 0.4 of 255 on every pixel, across 53 operations.

The showpiece is film.py — a physically-modeled film emulation engine. It is not a LUT or a color grade. It models the photochemical chain: spectral layer exposure, halation, H&D characteristic curves, DIR coupler inhibition, and per-layer grain. The famous CineStill 800T red glow around bright lights isn't painted on. It emerges, because bright scene light physically bounces off the film base and back into the red-sensitive layer.

Lightroom's lossy DNGs (JPEG XL, DNG 1.7) can't be unpacked by LibRaw at all. So the develop module grew its own decoder: read the LinearRaw pyramid directly, then apply the DNG spec's color pipeline by hand — black/white levels, AsShotNeutral white balance, ForwardMatrix to XYZ, a Bradford-adapted matrix to linear sRGB, BaselineExposure. A 2048px base decodes in 0.4 seconds. And the whole thing is calibrated to be pixel-matched to Sean's actual Lightroom exports — a B&W conversion pair came out "near-indistinguishable."

The three faces from Chapter 05 needed to actually share a library. So the app grew a satellite ↔ hub architecture: a catalog mirror, tiered thumbnails, predictive prefetch, and an oplog that converges rather than a request that blocks. The governing rule — the laptop never waits on the server. You cull on the plane; it reconciles when you land. Geodata backfill, a Google Timeline importer, and keyword/IPTC support land in the same window.

photoArchive → Azimuth Photo. A brand layer across the wordmark, the PWA manifest, the Android launcher, the Tauri desktop shell; bundle IDs move to app.azimuthphoto.*. Crucially, the internal identifiers, paths, and database names are left untouched and sequenced behind in-flight work — a rename done like an engineer, not a marketer. A Docker image, a compose file, an Unraid template, and an INSTALL.md for NAS boxes turn it into something installable. A full Google-Photos-replacement Android client — timeline, auto-backup, free-up-space — ships the same week.

July 2026 has 1,133 commits — 72% of the entire project. Read them and a structure emerges: a session-lane charter, an explicit org model of "CEO / CTO / managers / subagents," and hundreds of merges from named branches — qfix-workers, ux2-perf, errhonesty, dt-gfilter. This is a human designer directing a fleet of frontier models, each taking a lane, with cross-model review as a hard rule: whoever wrote it cannot be the one to bless it.

This is the part I would have left out if I were writing as I went. The fleet was very good at producing software. Left to itself, it was not good at producing the right software.

Every lane closed its tickets. Every merge got reviewed. The tests were green. Underneath all that, two things were quietly true: 24% of the 2,203 commit subjects were repair-shaped (fixes, hotfixes, regressions, seams), and simple changes had started taking days. It took me a while to see that those were the same problem.

Then, in August, the owner wrote down the sentence that turns this whole story around.

The catalog was measured on the live library. 2.4 GB across 84 tables — and 41 of those tables were empty. Not sparse. Empty. Machinery that had been built, wired, tested, and never had a single row put in it.

Then the real question. Of everything in the 43 tables that did hold data, how much of it was a decision a human being actually made — a keep, a star, an edit, a name? Everything else is a machine's opinion about bytes it can read again.

That number changed how I read the previous two years. The machinery wasn't protecting anything precious. It was bookkeeping: backlogs tracking what still needed computing, cursors remembering where they'd got to, presence tables recording what each disk held, and more tables reconciling those against each other. Storage you don't need isn't free. You pay for it in reconciliation, every day, forever.

It also meant smaller and safer pointed the same way for once. Usually those two fight each other.

The reasoning is blunt, and I think correct. A codebase isn't only something you run. It's something you and your tools have to move around in. Every dead subsystem taxes every future change and every attempt to work out what is actually going on. Past a certain size the code stops being an asset and starts being terrain.

So the waves went in, each one committing green — boot, film import, grid, develop — with git history as the archive:

A deletion program that only reports its wins isn't worth much. I kept the errors in the history too, and the commit subjects say it plainly:

Once I accepted that 99.94% of the catalog could be recomputed, a much smaller design fell out on its own. Azimuth needs to know four things about a photograph: what it is (its bytes), where the copies are, what you decided about it, and what the machine worked out from it. Only the third of those can't be rebuilt.

Four facts became five tables and seven functions:

The best single insight in the rewrite is small enough to fit in one line, and it explains years of bugs:

That one decision is behind the drive-probing, the hub_remote column, missing_at, the mass-missing circuit breaker and rebind_moved_source. Five separate subsystems, all trying to recover a drive letter from a string that had swallowed it. None of them were bad code. They were careful, tested answers to a question that only existed because of how I'd stored a path.

Store the tail and compute the path instead. Now a renamed root is one row. A new drive letter is one row. The same photo sitting on two disks stops being a reconciliation problem and just becomes the two-tier setup working as intended. I didn't fix those five subsystems. They stopped having a reason to exist.

The same trick worked on background work. Every backlog table, progress ledger and resume cursor existed to answer one question: what still needs doing? Ask that as a query instead of maintaining the answer, and it collapses to a single anti-join for photos with no cache row of that kind. Nothing to resume, nothing to expire when a worker dies, because there was never really a queue.

The results weren't subtle. All measured on the live 157k-photo catalog. Worth noticing why the grid got fast: no new cache, just 86 indexes on one table dropping to 5. Most of them had been maintaining answers to questions nobody asked any more.

The cleanest evidence is forty years old. In 1986 Jon Bentley set a word-frequency problem in his Programming Pearls column. Donald Knuth answered with a literate program in WEB/Pascal: ten-plus pages, a purpose-built data structure, beautifully documented. Doug McIlroy answered with six shell commands.

So the more crafted artifact was the less elegant one. That reframed the whole thing for me. Elegance didn't live in the workmanship. It lived in noticing the problem was already expressible in what existed.

Dijkstra supplies the other half of the definition, and he takes it straight from a dictionary: elegance is “ingeniously simple and effective.” The conjunction does real work. It rules out minimalism and code golf on the spot, because a shorter thing that does less has not won anything.

The corollary is where the working advice comes from. If elegance is structural agreement, then bloat is the residue left wherever your model of the problem and the real problem disagree. Every wrapper, flag, guard and status column is a patch over one of those gaps. Which means refactoring isn't tidying. It's correcting the model, and the machinery falls away on its own because it only existed to hold the mismatch together.

Three people arrive at the same place from different directions. Ousterhout defines complexity as dependencies plus obscurity — and notably treats obscurity as part of the definition, which makes readability a technical property rather than a style preference. Hickey names the unit: complecting, the braiding together of two things. His line is that multiple instances of a thing don't make a system complex; interleaving does. Brooks splits difficulty into essential and accidental, and points out the arithmetic: since tools only attack the accidental, a tenfold gain requires the accidental to have been more than 90% of the work.

Hickey's other distinction is the one I use most. Simple is objective — one fold, one braid, a property you can inspect in the artifact. Easy is relative to you, from a root meaning “to lie near.” Familiar code feels simple and often isn't.

Everyone's heuristic is that big files are bad. But the metrics literature has a warning that should stop anyone from trusting that. In a study of a large industrial C++ system with faults traced to real field failures, the standard object-oriented metrics predicted fault-proneness only until class size was controlled for. Afterwards, none of them survived. The authors concluded the existing body of validation work was cast into doubt, and set the bar every metric has to clear:

Does this metric predict defects beyond size?

So I ran that test here. 312 surviving source files, 2,304 commits, tests excluded. The outcome is how many repair commits touch a file. The coupling measure is how many non-repair commits touch it, which keeps the predictor disjoint from the thing being predicted.

The file that makes it concrete is web/app.py. It is 120 lines and it has the worst repairs-per-line in the entire repository. It's the assembly point, so everything eventually needs it. By size it looks like the safest file in the tree. By coupling it's the most dangerous, and coupling turned out to be right.

Which gives the most useful thing I took from any of this: stop asking how big a file is. Ask how often unrelated work has to touch it. That's computable from git history on any repository, with no instrumentation at all.

Richard Gabriel's Worse Is Better is usually cited as proof that elegance loses to pragmatism. When I actually read it, the picture was stranger and more useful. It's a thesis about piecemeal evolutionary growth, much closer to Gall's law — a complex system that works is invariably found to have evolved from a simple system that worked — than to an argument that low quality is desirable. Gabriel then argued the opposite side himself, publishing an attack on his own thesis under a pseudonym. A decade later at an OOPSLA panel he submitted both a pro and an anti position paper and said he still couldn't decide.

The genuinely useful part is how he frames the two camps. Both of them rank simplicity highly. The decisive difference is where the simplicity is placed: one camp holds that interface simplicity outranks implementation simplicity, the other holds the reverse. That isn't elegance versus pragmatism at all. It's a question about whose life you're making simpler, the caller's or the implementer's. Ousterhout's deep module is just the first position stated as a rule.

Carmack is cited constantly against small functions, usually for the wrong reason. His argument isn't performance and isn't readability. It's state: pulling code into a named subfunction creates a callable shortcut that someone later uses to do a partial update, and most bugs come from execution state differing from the programmer's mental model. His 2014 retrospective reframes it further — the load-bearing idea is controlling unexpected dependency and mutation, and inlining is just one fairly poor tactic for that. He also ranks duplication as worse than the problems shared functions cause.

Sandi Metz points the other way: duplication is cheaper than the wrong abstraction. Her mechanism is precise. A near-fitting requirement arrives, someone adds a parameter and a conditional rather than revisiting the abstraction, and enough loops of that turn it into a procedure made of special cases. It survives because of sunk cost, since existing code reads as evidence of its own necessity. Her remedy runs against instinct: re-inline it into every caller, delete what each caller doesn't need, then derive the abstraction again.

Every model I used could write good code. Most of the bad code I got was my doing: I asked for a task instead of a shape, took the first thing that worked, and let it tell me it was finished instead of checking. Before the patterns, though, it's worth knowing what the measured effect of all this actually is, because it surprised me.

Two things in there changed how I work. The first is GitClear's reading of the mechanism, which I think is correct: this is an incentive mismatch, not a model defect. Assistants get pointed at maximising the volume of code written, and volume-oriented use is what produces the clone-and-churn signature. My own July is that signature exactly — 1,491 commits and nearly a third of them repairs.

The second is the METR finding that assistance degrades most in codebases with high standards and a lot of implicit, unwritten requirements. Which is to say: AI helps least exactly where the code is already good. The better your codebase gets, the more the value moves from writing to deciding, and the more the deciding has to come from you.

None of these are clever. They're mostly just refusing to accept the first working answer.

Make the invariant mechanical. “A recipe is never a timestamp” sat in a comment for a year and got violated anyway, by me and by every model that touched it. It stopped being violated the day it became a function that raises. Written rules decay under pressure. A ValueError doesn't care how late it is.

Don't iterate on bad output. Take it back. When something came back mediocre my instinct was to explain more and try again, and that almost always cost more than doing it myself. The second attempt usually inherits the shape of the first. Now a weak result means I stop delegating that piece.

One decent idea, which is that you can't honestly rate a photograph but you can always pick between two. Then two years of machinery piling up on top of it. Then a month spent digging it back out. That's the whole shape.

What I'd tell someone starting a project like this. The hard part was never getting code written. Once I had a fleet of models working lanes, code was the cheapest thing in the building. The hard part was deciding what deserved to exist, and I was slow to understand that the answer to "should we build this?" almost never comes back from the thing building it.

Speed is something you defend, not something you report. Profile first, and don't widen a budget to hide slowness. That's why boot went from 65s to about 5s, and why the grid later went from 180ms to 0.22ms by taking 81 indexes out rather than putting a cache in.

Honesty turned out to be structural. A UI that won't fake a success toast. A backup that insists on byte proof before it calls a photo safe. A live preview that has to match its export to within 0.4 of 255. A deletion program that writes down the three deletions it got wrong. Same move every time: don't let the system, or the write-up, claim something it can't back.

Knowing what's irreplaceable is what makes you brave. Every scary moment in three years was the same fear in different clothes, which is losing a photograph I can't get back. Working out that 0.06% of the catalog was the part I couldn't rebuild is what made it safe to delete the rest without flinching.

The best code I wrote this year was code that stopped being necessary. Five subsystems didn't get fixed. They stopped having a reason to exist once a path was stored as a drive plus a tail. Every backlog and cursor collapsed into one anti-join. I don't know a refactoring pattern that beats noticing a question nobody asks any more, because it's the only move that makes a codebase smaller and more capable at once.

Azimuth 2.0 isn't finished. The UI is staying: 39k lines of grid, loupe and keyboard work that were always the good part. It's the backend underneath that's learning to be small.