I, the Architect

How I work with Claude Code

Recently I wrote about design with agent-first design – the idea that when you build REST services, you design them so both people and AI agents understand what the service does. That article was born on my in-laws' farm, between milkings.

This one started at the same place in late January, when the sheep were penned up and the rams let in to produce the most viable lambs for spring.

But it's not about the methodology itself – it's about the tools that make it work.

Specifically: how I actually work with Claude Code.

Architecture beats conversation

Most discussions about AI-assisted software development focus on prompts.

The thinking goes: "Write a good prompt and you get good code."

That's like saying: "Give a good description in a construction contract and you get a good house."

Nobody builds a house that way.

The problem is that large language models (LLMs) aren't deterministic. The same action can produce different results each time. If you build your workflow on chat, hoping the agent "understands" what you mean, you're basically playing the lottery.

We're seeing tools like Cursor, Windsurf, and Kiro approach this from the start. They rely on architecture and context to guide the work, rather than informal chat conversations. We can apply exactly that same thinking to Claude Code. By shifting from pure conversation to clear structure, we stop relying on luck and start designing.

Here's the core of it:

If you let all the rams loose without supervision, you'll definitely get offspring, but you have no control over the outcome. Spec-driven flow is about building fences around the AI. We set up clear boundaries in the form of requirements and rules – not to constrain the power, but to make sure that power goes in the right direction, and the output – the code – is what we ordered, not something random wandering off into the mountains.

The four pillars

The process that's worked well for me is built on spec-driven development, using tools like SpecKit from GitHub to manage the flow. To make this approach more concrete, I call it the SKAL method (meaning the agent SKAL, or SHALL, follow the guidelines).

It consists of four main pillars that form an unbreakable chain from idea to finished code:

• S – Structure (Constitution): The constitution of the project. These are the non-negotiable rules for coding style, security, and design that the agent must follow every time.

• K – Knowledge (Specs): Here I use Spec Kit to create a structured contract. We define what problem to solve, which endpoints to use, and how to handle edge cases before a single line of code is written.

• A – Action (Plan): The technical implementation where we choose tools, packages, and architecture. This is the blueprint for the solution.

• L – Labor (Tasks): Atomic and well-defined work items so clear that the agent can execute them without guessing what you might want.

• 
  

By following this hierarchy – Structure → Knowledge → Action → Labor – the agent has no room to stray. It gets a framework, and within that framework it's highly efficient.

Coordinating multiple agents

One agent is rarely enough when projects scale. That's where Claude Flow comes in. It's an orchestrator that manages multiple Claude Code agents running in parallel.

Claude Flow keeps state and context in a SQLite database. This way agents can share memory, spot patterns, and maintain context across work sessions. One explores, another codes, a third tests – all at the same time. When a project needs multiple hands working together, the orchestrator ensures they don't trip over each other.

The plugin marketplace

Claude Code has become an extensible ecosystem of tools. Plugins are packages that bind together capabilities, rules, agents, and commands into a single unit.

By creating your own plugin marketplace – a collection of modules that agents can pull from as each project needs – every plugin stays isolated, organized, and reusable.

A while back I built an auto-pr plugin that's helped me standardize release processes and keep documentation in sync with code changes. It's a good example of how you can use multiple specialized agents to solve complex work.

It creates Git commits, pushes code, and opens pull requests with standardized messages. Instead of one agent trying to do everything, it splits the work across an entire team of agents:

• Orchestrator & Git-automator: Handle the flow and GitHub interactions.

• Security-scanner & Code-reviewer: Ensure quality and security before anything gets submitted.

• Conflict-resolver & Diff-analyzer: Work through complications in the code.

• PR-writer, Readme-updater & Changelog-generator: Update README.md and write clear descriptions based on actual changes.

With commands like analyze and pr, I can let the system review changes, update titles and descriptions based on project templates, and ship everything without manual work.

Each agent then uses the right LLM for the job. For instance, there's no point spending valuable Claude Opus 4.6 tokens just to look at diff results.

From worker to architect

When these pieces click together – the SKAL method and specialized agents – the process becomes nearly predictable. We're not chasing the AI's random outputs anymore; we're directing it with precision. The goal isn't to eliminate creativity, but to channel it – to practice creativity within constraints.

When people ask me how I work with AI, I don't show them a chat window. I show them a system. I show them structure, specifications, and a whole team of agents working in harmony under clear direction.

I code less than I used to, and I design more. I've moved away from the shovel at the bottom of the ditch and started drawing the building. The biggest change in my work: the programmer is no longer a day laborer – they've become the architect of their own software.

And just like with the rams in January, success in May isn't about luck – it depends on how well we set up the pen in the beginning.