Every software engineer should be paying attention to Boris Cherny's Steps of AI Adoption.

The products and tools are obviously Anthropic Claude/Claude Code specific, but it should transfer generally to the likes of Codex, OpenCode and others as these harnesses continue to rapidly mature.

Level 0 and 1

Level 1 is really the entry point into agentic engineering. I'm surprised by the number of engineers I talk to that are still operating here. Things are moving too fast to be complacent at these levels.

The bottleneck things mentioned for level 0, in my opinion, apply at all the levels.

Level 2

Most software engineers are, or should at least be, operating at this level.

Level 3

This is where I spend most of my time. It's incredibly satisfying when Claude is fully autonomously cooking on something, or a few things. Automated maintenance tasks are something I can lean more into, but for features or larger improvements I just don't have enough work in a fully planned design/spec state to be running many things in parallel. The planning/design phase, knowing exactly what to build, consumes a very large portion of my time. The good news is this can be done while Claude is cooking on something else.

Below is an example of a recent feature build I ran using a dynamic workflow script that I have been refining. It's slow and meticulous, taking 13 hours to complete. It handled everything from writing its own implementation plan for a design I gave it, all the way through implementation and verification loops with unit, component and e2e tests, to creating a draft PR for me to review offering proof of completion and a ledger of work completed and decisions made. It was only 66 agents, but the nature of this particular piece of work meant not that many things could run in parallel without the agents stepping on each other's toes. Side note, Opus 5 on this workflow run smashed this piece of work out of the park. 73 files +3431 -1147 lines of code. After self-reviewing and self-testing, not a single thing needed changing; this was a straight 100% complete ready-to-merge change. Fable and Opus 5 are just incredible!

Level 4

To be honest, I was a bit surprised to see here that Claude Code isn't even used at this level, but instead building custom mini-harnesses with the Agent SDK. I can see how this works; it's basically the output of Claude Code creating a dynamic workflow, which is just a script built with the Agent SDK. I haven't tried running these without Claude Code yet, but it would appear these dynamic workflow scripts can be used in just this way.

Getting to this level must mean knowing exactly what the agents should be building. Who is planning this work and getting it into a ready state for the agents to just jump in and start building? Surely it can't be just one person — yet Boris Cherny says he is now operating at level 4. My guess here is that it's larger, more ambitious pieces of work that can run for days or even weeks at a time, provided the goal is clear to the agent and a harness exists to keep them on track on their mission.

This is a continuation from the post I wrote recently titled Designing a Feature with Claude Design – Then Handing It to Claude Code.

In that post, I stepped through how I used Claude Design to create a UX design as well as a set of initial requirements for new tag selection and suggestion functionality in my blog's custom CMS.

This post steps through using those artefacts to drive the actual implementation in the frontend and backend apps. Specifically the goal here is to build this end-to-end using Claude Code's new Dynamic Workflows.

The outputs of the Claude Design exercise were a fully functional interactive prototype of the design and a markdown file with a set of requirements and acceptance criteria.

I already have a structured process for defining per-feature design specs, requirements and implementation plans in the projects repo. It consists of several things, but most relevant here is a folder structure and set of markdown files which I would consider the "spec" as part of the planning phase of this AI-driven engineering workflow. These are used as context for the implementation and verification, which often run across several separate sessions.

Usually when starting a feature I would be starting from scratch, or just a high-level set of requirements from the initial blog design and feature roadmap. For this piece of work, Claude Design gave me a working prototype that was already using my frontend style guide and a detailed set of requirements, which I put into the code base for the duration of the build. So I had a solid starting point. However, those didn't fit into my structured process that I already have in place, and I still needed a design spec for the full end-to-end solution.

For larger pieces of work I like to use Jesse Vincent's superpowers plugin. He has done a fantastic job of baking in real software development methodologies and workflows into a set of agent skills that drastically increase the quality and coherence of what's being built.

The first two skills I normally reach for are the brainstorming skill, which is for creating a design spec and the writing-plans skill, which is for writing an implementation plan for the spec. The design spec is the most important part. For any given feature this is where I spend most of my time. The clearer this is defined upfront, the more seamless the rest of the process will be and the higher the chance of it building what I actually want.

Once I'm happy with the design spec and implementation plan, after rounds of refinement, I would then hand it off to Claude Code to start building, usually with subagent development or agent teams.

I already found a general workflow that I follow when building software with AI. In its most simple form it's the Plan-Generate-Evaluate methodology. But that's a gross oversimplification of the entire underlying process. In fact, for each of the Plan-Generate-Evaluate phases I will run inner Evaluate-Regenerate flows, iterating over this at different phases until outputs are where they need to be. The first outputs are rarely good enough.