davit.cc Writing

My agentic coding workflow

2026-10-23T12:00:00+04:00

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.

How to use Claude Projects the right way

2026-10-23T12:00:00+04:00

If you're trying to figure out how to use Claude Projects well, my advice is to treat a project as one ongoing stream of work that you brief once and keep feeding. Since the September 2026 redesign, a project is a chat with a coordinator that starts a thread for each task, and each thread is a full Claude Code session. You get the most out of it when your standing rules live in the project instructions, memory picks up your decisions as you go, and you answer the threads that are waiting on you. I run this site, davit.cc, in a project, so every example here is from my own setup.

What changed in September

Anthropic announced it on September 17, 2026, in Projects redesigned: from folder to conversation. The old Projects in claude.ai chat were basically a folder: some reference files, custom instructions and the chats you had inside it. The new ones live in Claude Code. You talk to one coordinator in the project chat, and it decides whether to just answer you or start a thread. Each thread is a cloud session with its own branch and its own copy of the repo. Threads report back to the coordinator, share one memory, and leave their files in the project's Library.

A few practical things from the Claude Code docs, as of October 2026:

Projects are in public beta on the Pro and Max plans and still rolling out. They aren't on Team or Enterprise yet.
You use them at claude.ai/code, in the Code tab of the desktop app and in the mobile app, but not in the terminal CLI or the IDE extensions.
The old folder-style projects in claude.ai chat and Cowork keep working until the new version reaches them.

A lot of the guides that rank for "how to use Claude Projects" still describe the folder version. This one is about the new one.

When a project is worth it

A project makes sense when the work has a goal that outlives one session and keeps producing new tasks. The docs give examples like one change across many repos, an area you keep feeding bugs into, a migration that's bigger than a session, and work that isn't code at all, like a folder of contracts you keep asking questions about.

If it's one task that fits in one session, a normal cloud session is enough. If every step needs your own machine, a local session fits better. And a job that runs on a schedule with nobody talking to it is a routine.

My personal site is the ongoing kind. Since October 8 the davit.cc project has done a full redesign, a new favicon, four small Playground experiments and these blog posts. None of that fits in one session, and all of it follows the same rules.

Let Claude propose the setup

I didn't write my setup myself. The first thing I sent in the new project was this:

Help me set up this new project from my recent work. Look through my recent sessions and repositories, identify the main thread of work, and propose a project setup: a short name, the repositories it should include, an environment, concise project instructions drawn from what kept coming up, and one or two optional routines. Show me the proposal before changing anything.

Claude went through my last 46 sessions from the previous four weeks, picked out the one line of work that belonged here (deploying davit.cc), and came back with draft instructions and an optional weekly check of the live site. Nothing changed until I said "yes". If you already have a cloud session doing the work, "Continue as project" in its menu does the same thing from there.

Write instructions a thread can follow

Project instructions are the brief the coordinator and every new thread start from, and they can be up to 16,000 characters. A good brief says what the project is for, where the work happens (repo, branch, how pull requests are named), how a thread checks its own work, what to do when something it needs is missing, and what needs your go-ahead.

Mine for davit.cc fit in 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 first version was wrong, by the way. It said the site was served from the master branch. The first thread read the repo, found a Cloudflare Worker serving main, and a few minutes later the coordinator had fixed the instructions. The rule about pushing straight to main came a day later, when I told a thread to remember that I'm the only one working on the site and I don't want pull requests. The preview rule came right after that, once we'd confirmed that every push deploys.

Two things are easy to miss. Changing the instructions only affects new threads, so a thread that's already running keeps the old brief. And instructions are for rules. Facts about one repo, like build commands, belong in that repo's CLAUDE.md.

Instructions, memory and CLAUDE.md

A project keeps context in three places, and each one has its own job:

Where	What goes in it	Example from davit.cc
Project instructions	Rules every thread needs from its first message	Push straight to main, and show a preview of visual changes first
Project memory	Decisions and pitfalls Claude collects as you work	"Pixel is better": the favicon and Pet the Shiba use the pixel-art Shiba
`CLAUDE.md` or `AGENTS.md` in the repo	How the code is built and styled	"Light only. Never use green accents."

Project memory is a set of files Claude writes itself. Every cloud thread reads the index file, MEMORY.md, when it starts and opens the other files when it needs them, and you can read and edit them under Project settings > Memory. You fill it just by asking: "remember that Unposed goes last in the Projects list" is enough. Mine holds the design decisions from the redesign, the fact that Paper only runs on my Mac, and the three topics I picked for this blog.

If you only write one of the three, make it the repo file, because every session reads it, in a project or not. My AGENTS.md is 64 lines on how the site is built, shipped and styled, and CLAUDE.md just points to it, so every thread and every other agent reads the same rules.

Send work, then walk away

Once that's set up, you talk to the coordinator the way you'd talk to a colleague. A quick question gets an answer right in the chat. New work becomes a thread, or goes to a thread that's already working in that area, and if you send a few unrelated things in one message, they become separate threads. This blog started with one message from me, and the coordinator started a thread with context from memory already attached: the three post topics I'd picked two weeks earlier.

The Overview pane groups threads by state: Ready for review, Waiting on you, Working, Landing, Idle and Resolved. When a choice changes what I'm building, the thread asks on a card with two to four options and a recommendation. For my CV, the card asked whether Claude should edit the PDF or I'd export it myself, and I picked "I'll do it".

You can also just tell the coordinator how you want the project run. The docs give examples like "Propose threads and wait for my go-ahead before starting them", "Run at most two threads at a time" and "Only post when something finishes or is blocked". Claude saves these to memory and follows them, though a thread limit set this way isn't enforced.

Approvals are the one part that isn't obvious. Threads run in auto mode, so most commands just run, but when a thread does need your approval, the prompt shows up inside that thread. Telling the coordinator "go ahead" doesn't reach it, so open the thread and answer there.

Run a thread on your own computer

Some work has to happen on your own machine: a local database, a device simulator, or an app that only runs on your laptop. For me that's Paper, the design tool I use, which only runs on my Mac. A project can run that one thread on your computer through Remote Control while everything else stays in the cloud.

To set it up in the desktop app, go to Settings > Claude Code, turn on "Use this computer from your phone and claude.ai" and add the folder. Or run claude remote-control in that folder from a terminal. Both need Claude Code v2.1.280 or later. Then pick "Work locally" from the + menu in the project chat, describe the task, and allow it on the card.

A thread on your computer uses that machine's files, tools, MCP servers and settings. It gets the project instructions but not the memory files, so anything it needs to know has to be in the instructions or the task. It also pauses while the computer sleeps.

Keep usage under control

Projects use up your plan faster than a single session, because every thread is a full Claude Code session and several can run at once. New projects run threads on Opus at high effort, and you can change the models and effort for threads and the coordinator in Project settings > General. There's also a hard limit of 200 new threads per day across all your projects.

Long threads cost more than they look. The redesign thread grew to 165 replies over two days. When a thread has been idle longer than the cache lifetime (an hour on Pro and Max), the next message makes Claude re-read the whole conversation before it does anything. So now new work gets a fresh thread, and I resolved the redesign thread. Threads that watch a pull request also wake up when CI fails or a review comes in, so tell a thread to stop watching once you're done with it. The Usage tab in project settings shows where the tokens went, by thread and by model.

Frequently asked questions

When should I use a project instead of a chat?

When the work outlasts one session and keeps producing tasks, like a product, a migration or a site you keep improving. A one-off question is fine in a chat, and a single coding task fits in one cloud session.

What's the difference between Claude Projects and Claude Code?

Projects are built on Claude Code. Every thread is a Claude Code session, usually in the cloud. The project adds the coordinator, shared instructions and memory, the Library of files, and the Overview pane that keeps track of every thread.

Can I share a Claude Project with my team?

Not during the beta. A project belongs to one person, and thread transcripts can't be shared. If your team wants to give Claude work together in Slack, Anthropic points to Claude Tag instead.

Do cloud threads get my local skills and MCP servers?

No. Cloud threads get the connectors on your claude.ai account, the skills you've enabled there, and the skills, agents and commands committed to the project's repos. Anything installed only on your laptop is missing unless the thread runs on your computer.

I wrote more about the day-to-day side in my agentic coding workflow, and the rest of my background is on my CV.

Languages and frameworks don't matter anymore

2026-10-23T12:00:00+04:00

For most of my career, picking the stack was the first big decision on any new project. Now that coding agents write most of the code, I think it's one of the smaller ones. If you're wondering what the best language for AI coding is, my answer is: one where an agent gets a clear pass or fail quickly, that has lots of public code to learn from, and that you can still read when you review what it wrote. Plenty of languages pass that test. The research I cite below does show real differences between languages, but almost all of them come down to feedback and tooling.

Fifteen years of picking stacks

I've been writing software for more than 15 years, and the stack changed with almost every job. At Shogun, the Y Combinator page builder where I was the first engineering hire, it was Ruby on Rails and React. At Blocks I moved a big application from Rails to Elixir and Phoenix for performance and scale. EverAI, where I was the founding engineer, ran on Rails and React with LLM, image, voice and video APIs. TurbaMedia was Node.js, TypeScript and React, and Copia was TypeScript and Python. Somewhere in between there was React Native and a few years running an agency. The full list is in the Experience section.

For most of that time the stack really did decide a lot: who you could hire, which libraries you got for free, and how fast the team could move in the first few months. Switching languages cost you real time.

What changed with agents

Now agents write a lot of the code, in whatever language the project uses. Andrej Karpathy said that within a few weeks in December 2025 he went from writing most of his code himself to having agents write almost all of it (Yahoo Tech). Simon Willison opens his Agentic Engineering Patterns guide with a chapter called "Writing code is cheap now". Armin Ronacher, who wrote Flask, put it as "the cost of coding is going down dramatically" (A Language for Agents).

My own work this year is spread across a bunch of stacks:

Rillow, a Next.js app.
Bundle, which I build alone: one repo with an iPhone app, an Android app for e-ink tablets, a Chrome extension, a backend and a website.
This site, plain HTML, CSS and JavaScript with no framework and no build step, plus Shiba Land, a small platformer in three.js.
TypeScript and Python at Copia.

In each case the platform and the product picked the language. An agent reads and writes all of them well enough that my time goes into deciding what each product should do.

The data says languages still differ

To be fair, there's decent evidence that languages aren't equal for agents.

José Valim, who created Elixir, made the strongest case for one language in Why Elixir is the best language for AI. He cites Tencent's AutoCodeBench, which compared 20 languages across more than 30 models. Across all models, 97.5% of the Elixir problems were solved by at least one model, the highest of any language, and Claude Opus 4 scored 80.3% on Elixir, ahead of C# at 74.9% and Kotlin at 72.5%. He puts it down to immutability, which keeps a function's effects visible without loading the code around it, and to stability: Elixir has been on version 1.x since 2014, so old examples still work.

GitHub's Why AI is pushing developers toward typed languages cites a 2025 study that found 94% of compilation errors in LLM-generated code were type-check failures. TypeScript also became the most used language on GitHub in August 2025, ahead of Python and JavaScript.

Armin Ronacher gets specific. He says Go works well for agents because the code is easy to grep, import cycles aren't allowed and test results are cached, and he now uses TypeScript where he used to use Python. On the other side, he finds Swift's tooling painful enough that agents struggle, and Python's significant whitespace harder for an agent to edit cleanly.

Put together, they keep pointing at the same things: fast, clear feedback, and code an agent can understand from a few files. Those come from the type checker, the compiler, the test runner and the project's conventions much more than from the syntax.

What still matters

The first thing I look at is whether an agent can check its own work. A type checker, a compiler with helpful errors, tests that run in seconds and one command that says pass or fail do more for agent output than choosing between two languages. Armin's line is "The more uniform the tooling the better", and I agree. Even this site, which has no build step at all, has a check: a thread runs the site on a local server before a push and opens the live page after.

Conventions matter for the same reason. Rails and Phoenix put files where an agent expects them, and a stable language means the examples the model learned from still compile. A codebase with five ways to do the same thing confuses an agent the same way it confuses a new hire.

The platform still matters too. An iPhone app goes through Xcode, signing and App Review whatever language you write it in, and that tooling shapes an agent's day more than the language does.

And you still own what ships. Pick something you can read well enough to review, because you'll be reading a lot more code than you write.

So what is the best language for AI coding?

For a new project, I'd go with the language the platform expects and turn on the strictest checks the team can live with. For a web app that usually means TypeScript, because its type checker catches exactly the kind of error the GitHub study found most often, and there's a huge amount of public TypeScript for models to learn from. If you love Elixir, Valim's numbers say agents do well there too. If your team already knows Rails, keep Rails and put the effort into tests. An agent can work in any of them. What it struggles with is a codebase that gives it no way to check its work.

What this means if you hire engineers

Years in one framework tell you less than they used to. An engineer who works well with agents can get productive in an unfamiliar stack quickly, because the agent already knows it. The harder skills to find are breaking a feature into tasks an agent can finish, checking the result properly and deciding what not to build. That's what I'd interview for now.

Where I still choose carefully

There's still code where the language is worth real thought: hot paths where performance is the product, native platform work, and very new frameworks with little public code. Armin's take on Zig is a good example. It changes quickly and there isn't much training data, so it works, just not as well. And a big team on a long-lived codebase gets more from consistency than from any one language feature.

For everything else, pick the stack that fits the platform, make the feedback loop fast, and spend the time you save on the product. If you want to see what that looks like day to day, I wrote up my agentic coding workflow, and my CV has the rest of my background.