I build with AI agents every day, and my agentic coding workflow is simpler than it sounds. I write down what I want and the rules once. Claude does the work in parallel threads. I spend my time deciding things: what to build, which version looks right, and what's allowed to go live. It's the same setup for this site and for the three products on it.
The redesign of this site is a good example. I sent the first message on a Thursday night, around ten. By Friday evening the new site was live, with the grainy hero, new project cards and a little three.js platformer called Shiba Land. I didn't write that code. I looked at what Claude made, said yes or no, and told it what to remember for next time.
One project per product
Every product I work on has its own Claude Project: this site, Rillow, Bundle and Unposed. Since Anthropic redesigned Projects in September, a project is basically one long chat with a coordinator. I tell it what needs doing and it starts a separate thread for each task. Each thread is a full Claude Code session in the cloud with its own copy of the repo, so three things can be in progress at once without getting in each other's way.
Boris Cherny, who created Claude Code, described doing this by hand back in January: five Claude sessions in numbered terminal tabs, another five to ten in the browser, and system notifications to tell him which one needed him (VentureBeat). A project does that bookkeeping for me. When I open my laptop I can see what finished and what's waiting on me, and it works from my phone too.
I wrote a separate post on how I use Claude Projects, so here I'll stick to the workflow.
I write the rules down once
Every new thread starts by reading the project instructions. For davit.cc they're one paragraph:
Site is davit.cc, built from the main branch of davit-khaburdzania.github.io and served by a Cloudflare Worker (wrangler.jsonc). Davit is the only one working on the site, so don't open pull requests: commit and push straight to main. Every push to main deploys davit.cc automatically within about a minute (Cloudflare's GitHub connection), so a push is a production change: show Davit a preview of visual changes before pushing. Keep profile details (location "Tbilisi, Georgia", website davit.cc) consistent across the site, GitHub and LinkedIn. Verify changes on the live site after each push.
The repo also has an AGENTS.md, and CLAUDE.md just points to it, so Claude and any other agent read the same file. It covers how to run the site locally, which file does what, and the design rules I'd otherwise repeat in every task. A few of them:
- Light only. Mostly cool grey with a faint lavender glow. Davit found stronger lilac "too colourful". Never use green accents.
- Keep pixel art pixel-exact: nearest-neighbour scaling only.
- Motion must respect `prefers-reduced-motion`. WebGL pieces need a non-WebGL fallback.
Almost every rule in there exists because I said no to something once. Mitchell Hashimoto calls this engineering the harness: when an agent gets something wrong, you fix its instructions or give it a tool so the same mistake doesn't happen again (My AI Adoption Journey). Decisions about the project itself, like "Unposed goes last in the Projects list", go into project memory instead. Whenever I correct a thread I tell it to remember, and every thread after that already knows.
Threads write the code, I make the calls
During the redesign, threads built the WebGL hero, the phone menu, four Playground experiments and a pixel-art favicon. What they couldn't do was tell which version felt like mine. These are my actual replies from the redesign thread, copied word for word:
- On the first lavender prototype: "too colourful".
- On the grainy smoke hero, based on the one on slides.com: "i love it".
- On illustrated scenes for the project cards: "childish". On redrawn product screens: "not real". The cards ended up using the hero's dust in each product's own colour.
- On a pixel-art Shiba next to a line-art one: "Pixel is better".
That's taste, and it's most of what I do in a project now. Simon Willison opens his Agentic Engineering Patterns guide with a chapter called "Writing code is cheap now", and that matches what I see. When three versions of a card cost a thread a few minutes, picking one is the job.
My replies are short. A thread shows me a preview, I answer in a couple of words, and it either ships or tries again. If a choice changes what I'm building, Claude asks on a decision card with a few options and its recommendation, and keeps going on the recommended one while I think about it.
The setup behind my agentic coding workflow
A thread can only work with what it can reach, so I connect the same tools I use myself:
- GitHub for code. Threads work on their own branch, or push straight to main where I've said that's fine.
- Rillow, my SEO product. It runs as an MCP server inside Claude or Codex and gives the agent keyword data, live Google results, a content plan and rank tracking, plus a memory of each site.
- My Mac, through Remote Control. I design in Paper, which only runs on my Mac, so when a task needs Paper, Claude starts a session on my machine. The same session can run Bundle and Unposed in the iOS simulator.
- A shared project folder, where threads leave screenshots, logos and drafts for each other and for me.
This post went through the same loop. A thread read the most-discussed posts on agentic coding, pulled a brief from Rillow with the current Google top 10, and wrote a draft with images from Rillow's image tool. My first note was that it sounded like a robot wrote it, so it got rewritten.
What I keep for myself
I decide what gets built and in what order, and I keep anything that can't be undone. On davit.cc every push to main is a deploy, which is why the instructions say to show me a preview of visual changes first. The same goes for anything with my name on it. Claude gave me two rounds of alternative headlines for the homepage, and I kept the one I already had.
Some things I still just do myself. When my CV needed updating, Claude offered to edit the PDF, and I said I'd export it myself. The site links to whatever file I send.
What still goes wrong
Instructions can be wrong. When I set up the project, the first draft said the site was served from the master branch. The first thread read the repo, found a Cloudflare Worker serving main, and the instructions got fixed a few minutes later. A thread that reads the code is more reliable than any summary, mine included.
Agents are good at code and pretty bad at drawing from scratch. A hand-coded SVG Shiba came out "silly", a 3D plush Shiba in three.js was too red and didn't look real, and the illustrated project scenes looked childish. What worked was giving it a style with clear rules, like pixel art, or making the design in Paper first and handing it over.
Long threads also get heavy. The redesign thread hit 165 replies over two days. If a big thread sits idle for more than an hour, the next message makes Claude re-read the whole conversation, so new work like this blog now gets its own thread.
If you want to try this
Pick one thing you keep coming back to, like a side project, and make it a project. Write the instructions as one paragraph: where the code lives, how a change gets checked, and what needs your go-ahead. Put the repo's rules in AGENTS.md. Ask for a preview before anything ships, answer in as few words as you can, and when you correct a thread, tell it to remember.
If you're hiring for this kind of work, my CV has the rest.