Approach to Agentic Coding

Geordi Filiotis

— 2 min read
Approach to Agentic Coding
First they built us, then they improved us, then we improved ourselves.
🧠
This is a live doc: I have been trying various approaches to agentic software development and whatever flavor I'm currently happy with I will describe here.

Start a project, add the specsify stub and run claude:

~$ mkdir my-proj
~$ cd my-proj
~/my-proj$ git init
~/my-proj$ cp -a ../specs .
~/my-proj$ claude
👉
Specsify is a glorified skill, claude is usually very good about keeping the specs up to date, but it is not so good about remembering to commit after a change.

My first message to claude looks like this:

We will follow specification driven development as per the files in specs/. This project is a webapp. It will [what I want the app to do] Use PG as a backing database, I have a preference for [frontend stack, maybe backend stack] Plan on having independent agent driven testing (playwright). Create a relevant Claude.md, and maintain a Readme.md that will get me oriented again in six months. Ask me things so we can scope this fully.

Then I have a Q&A session with the agent, and then it gets started. This typically gets me to a good MVP. Key success drivers:

  1. Spec-driven-development: having the agent build specs first and then code seems to raise the quality floor a lot! Free vibe-coding seems to result in very brittle constructions, in the sense that changes cause a lot of breakage. When I use this spec driven approach, so long as I force the agent to maintain the specs (and reconcile against changes from time to time) it seems to prevent dumb breakage.
  2. Specs in Git: Part of the specsify approach is that git messages are no longer the point of reference for semantic change, the specs are, and they are checked in along with the code. So when you inspect a diff, you can see what machinery changed but you can also see the implicit justification in the change to the specifications.
  3. Simple stack hints: I don't tell the agent how to engineer (data model, abstractions, whatnot), I tell it what the technical perimeter is. Beyond that it builds out the interior. When I used to write code I cared a lot about data models and abstractions, but that's all wasted effort with LLMs spewing out tokens at breakneck speeds. We also gain the benefit of lower abstraction risk, because refactoring is basically free (especially with strongly typed languages).
  4. Playwright testing: claude seems to get off on testing what it's built... by which I mean the output is way waaay better. So having Playwright provide an end to end test toolset make so much sense. There is a double-win because playwright works best when testing to specifications (as opposed to unit testing or something like that) because the agent can produce test activities that directly exercise the decisions encoded in the spec files.

Read more