Building Photo Cruiser with Claude Code
An analysis of about 75 prompts I wrote across 35 Claude Code sessions (6–11 October 2026). Over those six days I compared technology stacks for a photo app with throwaway prototypes, then built it for real in Rust/iced. This page covers how the prompting differs from someone building software for the first time, which agentic engineering patterns came up, and the vocabulary involved.
1. How it differs from a first-time builder
Explored before committing
I built the same small feature in about 8 stacks (web File API, Electron, Tauri, COSMIC, Kitty terminal, egui, GTK4, Deno desktop, then iced) and compared them on evidence.
First-timer: picks one stack, or lets the AI pick, and is stuck with it.
Weighted criteria for my real situation
8 criteria, weighted for an app for myself, but potentially for my friends who run different OSes
. I spotted that Slint is commercially licensed.
First-timer: judges by "does it work" and how it looks.
Designed for testing first
I asked which stack the agent could test fully, and for headless UI testing not based on screenshots, but in deep understanding of each individual UI part
.
First-timer: tests by clicking around, after something breaks.
Chose the architecture myself
splits gui and lib, is able to be operated from cli and agents
, with a spec, an MVP scope and tickets.
First-timer: asks for "an app that does X".
Protected the repo
why you updated an rs file???
, why a run app should write anything there
, why sudo?
, Why is there so many just commands?
First-timer: rarely notices or questions side effects.
Thought about future features
Before choosing a stack I checked whether it could handle Darktable-level local contrast, sharpening and Samba shares. I still kept scope down: keep it reasonably simple
.
First-timer: overbuilds now, or hits a dead end later.
Judged UX by feel
300 milliseconds are not really great… some smarter ways to improve the feel of speed
. Vim keys, but dont support q, system already got closing app shortcut
.
First-timer: takes the numbers or the defaults at face value.
Edited the copy
You are repeating yourself… Fast photo browser and Instant photo switching
. I cut generic claims and kept the description short.
First-timer: ships AI copy as written.
Prompted in short bursts
Many prompts were y
, go
, commit
, ship
. I let the agent run and steered with one-line corrections.
First-timer: over-explains every step, or approves everything without review.
2. Agentic engineering patterns I used
| Pattern | What it is | Evidence |
|---|---|---|
| Parallel prototyping | Build N throwaway variants of one feature to compare options on evidence. | 5, then about 8, stack prototypes side by side in subfolders |
| Subagent fan-out | Hand independent work to parallel subagents and keep the main context clean. | Use whatever parallelization you want, add 2 more features in subagents to every app, build html in a subagent |
| Spec-driven development | Intent, then shared spec, then tickets, then implementation, all saved as files the agent can re-read. | Intent file and shared spec, then the aiwork protocol: /aiwork:to-tickets, /aiwork:implement |
| Picking the stack by agent testability | Treat "can the agent verify it?" as a criterion for choosing the stack. | which app can best be Tested fully. By your abilities |
| Closing the verification loop | Give the agent a way to run the app and check state, so "done" comes with evidence. | Run and verify skills, script mode, --dump-state, just verify |
| Headless by default, headed on request | The agent's checks run off-screen. A visible window opens only when I want to look. | your tests should go headless but if i need to see it life you need to open headed version |
| Guardrails in context files | Rules and hooks keep the agent's autonomy safe. | CLAUDE.md rules (no OS input injection, scratch files in /tmp), a hook that blocks writes to out/ |
| Autonomy budget | Tell the agent explicitly not to interrupt. | don't bother me with Questions unless it's absolutely Necessary |
| Session handoff | Compress state into a handoff and continue in a fresh context. | /cc:handoff: goal, done, conclusions, next, watch-outs |
| One feature per session | Short, focused sessions keep context small. | About 20 sessions on day 2, each one feature (grid, menu, icon, install…) |
| Parking work in a backlog | Keep the agent on scope and park the rest. | keep other work in the tickets |
| Agent as analyst | Ask for a weighted assessment and a recommendation, not just code. | Weighted HTML comparison, assess, and give directions and pick your winner |
| Show me the variants | Have the agent render alternatives, then choose by taste. | show me both, then both are bad, then a decision |
| Reuse existing code | Point the agent at proven code in another repo. | useJustifiedLayout in ~/code/chrono-albums-2 |
| Testing on real data | Check against real media, not only fixtures. | verify the app is switching faston ~/Documents/test-media, a real 20-photo folder |
| Publishing artifacts | Turn analyses into shareable artifacts. | /publish-html for the comparison (and for this page) |
| Delegated delivery | One word triggers the full delivery process. | licence mit and ship |
| Fast feedback loop | A live-reload window while iterating on the UI. | just dev rebuilds on save and resumes on the same photo |
| Voice input | Dictate long prompts by speech. | Long first prompts; misheard words like "Hades" (HEIC), "Igwe" (egui), "Dino" (Deno) |
3. Technical vocabulary I used
4. The prompts, condensed
Phase 1: comparing stacks (sandbox)
- Build one feature (open a folder, use the arrow keys to move through photos sorted by filename) as 5 prototypes: browser File API, Electron, Tauri, COSMIC, Kitty terminal. Intent file, shared spec, subagents, verify they're runnable, short README.
- Compare them by lines of code and complexity. Pushback: the web version makes you upload the folder.
- Add AVIF/HEIC support and a freehand crop with a 50% darker background to every app, using subagents.
- Which one can you test fully? What about Deno desktop or GTK? Native look and feel?
- Can they handle format conversion, Darktable-style local contrast, sharpening, Samba? Speed and re-render lag?
- Build egui, GTK4 and Deno desktop clones (no Bun or Flutter). Weighted HTML comparison on 8 criteria; pick a winner.
- Challenged the result: could egui be themed native? egui feels limiting; Slint is commercially licensed. Build the iced version and update the comparison.
- Write the initial spec for an iced app: GUI/lib split, operable from CLI and agents, aiwork protocol. Init git. Can iced be tested headless with real UI understanding?
Phase 2: the real app
- Implement the base spec: MVP first, best practices, run and verify skills, subagents.
- No writing to
out/; use a temp folder outside the repo. What's left? Turn it into tickets, kept simple. - Verify switching speed on real media; 300 ms feels slow, so add transitions and improve the feel of speed. Keep the rest in tickets, then commit.
- Full screen task and implementation; remove the double click.
What is a render golden?
- README and GitHub description (cut the repetition), MIT licence, ship.
- Why so many just commands? Headless verification, headed on request.
- Window title with the full path, no em dash, a clean UI with a hidden menu, a menu shortcut, vim keys but no
q. - A grid as the default view, file names hidden with a toggle, and an investigation of the 3-second thumbnail delay.
- Justified layout reused from another repo, with margins, settings and remembered state.
- Machine-wide install with an icon (
why sudo?
), the icon placed in an About entry, and arrow-key navigation in the menu.