how i work
i work from the product backward. i need to know exactly how it should feel; i do not need to know every line that makes it feel that way.
agents write all the code: they inspect the repo, plan, implement, test, refactor, and review each other's work. there is no hidden stretch where i take the keyboard back. an occasional one-off Bash command is about as close as it gets. my side is the product — intent, references, taste, routing, corrections, scope, and the final call on whether the result is right.
the product is truth
the live product has final authority. a diff, green tests, and a completion report are evidence. none can tell me whether the thing feels right.
work begins with the felt outcome. what should happen when someone taps this? does the page make sense before they know its vocabulary? does the transition feel continuous? what happens on a narrow phone, in dark mode, with a slow response, after a refresh?
three signals need to agree: use the product like a person; repeatable tests exercise the behavior that matters; and another agent reviews the result cold. disagreement reopens the work.
important routes can load known states on demand. browser and device checks cover the real viewport, theme, loading state, motion, and interaction. when motion matters, use video. when a workflow matters, use the actual workflow. the distance between intent and product should stay short.
don't read the code
you should not read the code. at least, not by default.
if every generated line needs human approval, the old bottleneck survives the new speed. stay close to architecture and absurdly close to the product: direct the work, use the thing, compare it to references, and give precise feedback.
the source-level work still happens. an agent reads the current code, callers, tests, history, and nearby patterns before changing anything. structural tools turn a repo into a map instead of a file-by-file tour. human attention returns to source when product behavior and proof cannot settle a consequential risk. reading code is escalation, not ceremony.
responsibility moves upward instead of away: be clearer about what right means, notice when a result only looks finished, and be willing to reverse work already paid for.
the loop is the work
- briefname the feel
- groundshow reality
- buildagents code
- proofuse the product
- feedbackcorrect or delete
then loop. repeated feedback exits into a better tool.
interruption, correction, and re-scoping are the work.
on this site, i once built a daily generative sculpture: a backend, a 3D scene, a scroll-driven presentation, tests, and a perfect score against its own visual bar. the next day i removed nearly four thousand lines. the machinery worked. the page did not need it. deleting it was the correct last turn of the loop.
feedback should compound. after the same correction appears twice, the third session should inherit something better. otherwise every agent is being paid to relearn the same taste and the same mistakes.
ask the human
a blank prompt bar makes the human do the correlation: remember the context, translate a product feeling into instructions, and guess what the agent still does not understand. a good ask-user tool reverses that. the agent brings the context and asks for the judgment only a person can make.
read first, then ask about taste, priority, tension, or a real product fork. useful options give the human something concrete to react against; free text catches the part of their mental model the options missed. the next question should change because of the last answer.
this is not a questionnaire before the work. it is a short feedback loop: show the current read, surface the disagreement, ask one to three good questions, synthesize, and keep moving. the questions are most useful when they reveal an insight or dissonance, not when they ask for approval.
the tools
- coding agents
- the coding layer: source inspection, implementation, tests, refactors, and cold reviews.
- one effective IDE
- a fast terminal, sessions that survive every device, and a sharp place to read what the agents wrote.
- from any device
- tailscale makes the macbook reachable; termius is the doorway from an iphone or daylight tablet.
one machine, every device
one macbook holds everything: the projects, environments, agents, and tmux sessions that keep long work alive. tailscale makes it reachable; termius opens the same workspace on an iphone or daylight tablet. there is nothing to sync because every device looks into the same machine.
working from a phone is convenient. working on the iphone app from that iphone is the point. the product is already in hand, so switching from terminal to product takes seconds. mobile web works the same way.
music gets checked on studio monitors, car speakers, and a tiny mix cube because each surface exposes a different lie. software is no different. a macbook-only view slowly turns into a product for a desk. the phone exposes hierarchy, latency, touch, and navigation problems; fixing those usually makes the desktop more coherent too.
local and cloud agents
| local | cloud | |
|---|---|---|
| best at | interactive product work | bounded headless work |
| feedback | seconds; easy to redirect | slower; let it run |
| needs | you in the loop | a strong test or finish line |
| use it for | feel, motion, copy, iteration | long tests, migrations, audits |
local sessions are for high-frequency product work: make a change, feel it, redirect, repeat. cloud agents get work that is truly headless and has a strong finish line — a test suite, migration, broad audit, or another bounded task that can run alone. cloud latency is cheap when the agent can work for an hour; it is expensive when human feedback is the next input.
the CLIs
small CLIs grow around recurring questions. the names are mine; the categories are the part worth copying:
- readers
- map structure, callers, and dependencies so an agent does not guess
- proof runners
- combine tests, types, builds, browser checks, and device evidence
- session operators
- start, route, watch, and recover long-running agent work
- fleet checks
- find dependency, configuration, and build drift across many projects
- capture tools
- turn screenshots, video, logs, and traces into reviewable evidence
a good CLI takes a repeated operation and returns structured, inspectable evidence. language can stay flexible around product judgment; repeated machinery should stop being ambiguous.
build the missing tool
build when the loop exposes the same blind spot, a manual step keeps proof unreliable, or another product genuinely needs the same behavior. repetition is evidence. annoyance alone is not.
prove behavior inside one product first. extract the smallest interface that survived, including tests and failure behavior. then use it somewhere else and let the second product reveal what the abstraction got wrong. a shared package without product proof compounds mistakes faster than leverage.
a setup you can copy
this is a small folder you can drop into a project and point an agent at. AGENTS.md sets the working agreement; init helps shape and recover real work; skills add a few reusable loops when they earn their keep. the prompts are the actual receipts behind this page.