The AI Coding Workflow I Built by Watching Myself Code

I remember back in the fall of 2025 the online chatter seemed to be that coding was getting "solved." Claude skill libraries & coding harnesses like Superpowers (288k ⭐) and Spec-Kit (138k ⭐) and AWS's Kiro IDE were arriving fast and furious. Folks online were alternately singing their praises or calling them useless.

Many of the criticisms resonated with me: these frameworks felt mismatched to the scale of my projects and my usual approach. They burned massive amounts of tokens on work a more targeted process could solve in a quarter of the time. As an experienced developer, I no longer felt like I was developing; I was a glorified product manager, pushed away from both the code and the process. Worse, I was making bad software - constant regressions, slow test suites that tested nothing, slow features, and architecture with a massive blast radius - without noticing until later because I wasn't reading the code. The meat-metal divergence problem.

A few cases where the models kept churning for hours on what seemed like simple bugs to fix made me realize these were not for me. I ended up throwing away everything I built with them and starting over with a new process.

The process I used was pretty simple: build code the same way I used to, watching myself do it, and then slowly extract the process into a unified set of skills as it became clear exactly what the process was. It was actually quite an enlightening process as it helped me take a step back and realize how I code - previously I would work without really thinking about the how.

Very practically, once I was giving the agent the same prompt a few times, I'd save copies of the prompt I actually used, then paste them into a separate agent running in my home ~/.claude/skills directory to turn into a reusable and composable skill. I'd then pay close attention to what that skill was doing the first few times before trusting it to do the right thing.

It also exposed a surprising amount of tacit knowledge. Things I’d been doing automatically for years suddenly had to be made explicit if I wanted an agent to reproduce them.

Here's a concrete example. Back in the old hands-to-keyboard coding days, I would create "design documents" that were really glorified problem statements paired with a checklist documenting that phased approach that I would take based on my current understanding of the codebase. I would then go through the codebase and validate my understanding - pasting random snippets of code or file paths or sudden epiphanies to fill out that document.

The first few times I did this with Claude, I'd write something like this:

Please write up a brief design document ADD_FEATURE_X_DESIGN.md that adds the ability for users to X in the Y section of the app using .....

Create a summary paragraph at the top explaining what we're trying to achieve, then break the project into separate phases - each phase must only touch one part of the app - Business Logic, API, Frontend and be separately testable.

Document the approach for each phase below the phase table - referencing the actual code and any gotchas.

After a few rounds of fine-tuning that language, I'd extract it into a skill in an agent running in ~/.claude/skills with something like:

Please create a /design skill that does the following:
[ Paste of the last prompt, slightly generalized ]

Please ask me questions if there are things that are unclear or could be improved.

And voila! I'd have a reusable skill that I could use in all my projects from then on. Most projects end up in devcontainers, so I mount that skills directory read-only and every project immediately gets the latest version.

But since development isn't one-size-fits-all, I quickly realized that every project needs both a base skill and project-specific overrides. Each project gets an agent-spec/ directory with markdown files such as ARCHITECTURE.md and REVIEW.md. The global skills capture the overall approach, agent-spec/ files describes what’s different about this project. For example, the ARCHITECTURE.md would describe architectural invariants that apply to only this project. REVIEW.md would describe how to actually fire up playwright-cli and login to the dev server.

Next I'd run that skill a few times, review the created markdown file and tweak the skill until I was happy with its output. That ~/.claude/skills/ directory lives in git and gets committed so I have a history of my skills evolution.

Now I realized I would almost always end up telling the agent to review the designs in a clean-context subagent and raise any issues to me to decide on. This was extracted into a /devil skill ("the devil's in the details") that verified designs and claims in a generated document and raised issues.

After I got tired of answering obvious questions, I extracted a /quick-devil skill that calls the /devil skill, applies all the obvious fixes and only raises actual architectural questions and concerns.

Finally I realized I could move the abstraction up a level and create a /devil-design skill that both writes the doc and reviews with clean subagent context in one fell swoop. Each of these skills wasn't rewritten, but was composed into another.

This process-extraction has continued unabated for the past year, each time slowly moving up the abstraction chain once I'm comfortable I don't need to be that involved, to the point where I now have a /forge skill that takes an architecture doc and a phasing doc and will run for basically ever until it's done or hits a real roadblock. See a case study of how an unattended build on a mobile app called Habitizer went.

The funny things is I don't use that full /forge skill all that often - usually I use the smaller sub-skills it calls or point it at single phase. And that gets to the point - having an intimate knowledge of all the now 38 skills that have been extracted and composed allows me to continue to do software development the way I always have, applying the right scale of the solution to problem I'm facing. When something isn't working, I also feel completely comfortable iterating on those skills without worrying I'll mess up someone else's workflow or worrying that someone else is going to mess up mine with a PR.

Over the past year this has grown into a Design / Build / Review / Fix / Retro loop, with each part evolving the same way: do the work, notice the repetition, extract it, and only move up a level of abstraction once I trust what’s below it.

It seems obvious now, but it appears the solution to bad abstractions in AI-assisted development is the same as the solution to bad abstractions in software development - stop designing them ahead of time and extract them naturally from concrete use.

I haven't created a software factory nor "solved" software development. I've simply extracted my process to make it executable by an Agent. I can now also parallelize my work extremely effectively without losing the thread of what's going on.

More importantly the point is that this whole thing has evolved naturally with me in the driver's seat. AI feels more like an extension of how I used to develop than a process foisted upon me.

I feel like a Centaur again, rather than a Reverse-Centaur.