Uses

How I work with agents.

The setup behind the session count on the home page. The rules here come from the incidents in the field notes.

Agents

Agents do most of the building. Other agents review their work before I read any of it.

A coding agent: It reads the code, writes the change, runs the tests and opens the branch.
A second model as the review gate: A model from a different vendor reviews work before it merges or deploys. What it flags gets fixed and reviewed again until it comes back clean.
Loops with a cap: After a build, the same loop verifies it, commits, opens a pull request, runs the reviews and fixes what they find. It comes back to me only when it is green, and every loop has a limit on how many rounds it can run.
Written rules: How the agents work is written down and loaded at the start of every session, including the rules behind the field notes on this site. A mistake that happens twice becomes a rule.

An agent starts every session knowing nothing, so the work has to remember for it.

Running notes per project: Each project keeps a short record of what was done and what is open. The next session on that project starts by reading it.
Live counters: The numbers on the home page and the Now page are counted from those records and published automatically, at most once a day. Only counts are published.

Each kind of work runs where it fits.

Laptop: For editing, tests and short checks.
A bigger machine: Anything that runs for more than a few minutes, needs a lot of memory or disk, or runs many workers at once.
Cloud: Production runs on cloud machines that are not reachable for remote login from the internet.

The agents move fast everywhere except these places.

Production data: Every change to a production database is shown in full, with how much it will touch, and waits for a yes. One change at a time.
Secrets: Keys never go into a conversation with an agent.
Work that must survive: Anything worth keeping is committed and pushed as soon as it is worth keeping.
Nothing destroyed without asking: Deleting anything needs an explicit yes, with every affected item listed first.

Habits that hold regardless of the stack.

Typed code: Typed languages on both sides of the wire, so a mismatch fails at build time instead of in front of a user.
Plain data: A relational database, with spatial support for anything on a map.
Built once, deployed many times: Releases are built once, tagged by date and pulled by the server. Source code is never copied onto a server by hand.
Checked by eye: Every change to a screen is opened in a real browser before anyone calls it done.