When I started working with AI tools, I felt lost. Too many new concepts, too many ways to engage with them. My early experiments ended in disappointment, and I caught myself asking: “Is that all?” and “Am I using these tools the wrong way?”

So I went back. I expanded my knowledge, connected more dots, and lined up pieces of different workflows. The results improved, and I understood something I couldn’t yet name: my approach had to match the kind of work I was trying to accelerate. Brainstorming in a chat window and directing tasks in a CLI don’t call for the same tone, or the same intent.

The turning point

Then I found Anthropic’s free course, AI Fluency: Framework & Foundations. The lessons flew by, and they changed how I see this moment.

The AI revolution is not just another technological leap that asks engineers to add hard skills to their baggage. It asks for a different set: soft skills, the ones engineers usually meet when they step onto the leadership path, as a Tech Lead or a Technical Director. The course’s 4D framework (Delegation, Description, Discernment, Diligence) gave names to the struggles I had in all my experiments with AI and agentic workflows.

Four tiers

The course inspired me to build what I call the Delegation Framework. It’s not the most original name, but naming things is the hardest job there is. As far as I know, the tiers are my own addition, not part of Anthropic’s framework.

It is a simple vocabulary for describing how a human and an AI worked together on a piece of work. Whatever the work is, it asks: who owns this line? Who owns this pixel? Who owns this result?

  • T1: I wrote it independently.
  • T2: I wrote it, with AI answering questions.
  • T3: AI drafted it, and I own every line.
  • T4: I fully delegated it to AI.

Two questions separate neighbouring tiers: who wrote the code that landed, and who read it. A T4 is code I accepted because it behaved, not because I read it.

An experiment on myself

I wrote a small set of skills that teach Claude, and AI agents in general, what the tiers mean and how to use them. Then I ran an experiment: since April, I have tagged my commits with the tier that describes how I produced them, and I asked Claude to judge our collaboration as strictly as possible.

What the numbers say

352 of my 423 commits carry a tier tag (83%; the largest untagged block is my coroutines course). The split: T1 11%, T2 21%, T3 35%, T4 32%.

Delegation tiers of 352 commits by month and by project, April to October 2026. T1 falls from 48% of commits in April to 2% in October, while T4 rises from 7% to 51%.

Three things stand out:

  1. T1 is rare, and it lives in one place. 31 of my 39 T1 commits are in the Pac-Man game, the project where I wanted to reconnect with C++ and write the code myself. In April, 48% of my commits were T1. In October, 2%.
  2. T4 grew from 7% in April to 51% in October. Most of that is Lodestar, my WoW addon, where 59% of the commits are T4, in a domain I was exploring for the first time.
  3. T3 is the backbone. In kitbash, 71% of my commits are T3, and none are T4.

To me, the tier is not a grade. T1 is not virtuous and T4 is not lazy. The tier tracks a choice: where I wanted to learn, I kept the keyboard; where the value was the result, I let go. That is the point of the framework. Delegation should be a decision I make on purpose, not a default I drift into.

The number I watch most closely is T4. When half of my commits are fully delegated, the question is no longer “is the code good?” It is “do I still understand what we built?”

How it changed my work

The framework gave me no new prompting technique, only structure: before each piece of work, I ask whether it is worth my time to write it, and whether I can close the knowledge gap later if I let Claude do it. I built my SPEC-driven workflow around the tiers, so every task in a plan carries a tier and a one-line reason, and at the end of each plan I ask: “Do I still feel that I own and understand what was built?”

What I haven’t solved

The boundary between T3 and T4 is still fuzzy, because “did I read every line?” is a self-assessment, and the easiest answer to bend. The data is also self-reported and judged by an AI that works with me, so I treat the numbers as a mirror, not a measurement. Still, as agents start to keep memory of our collaboration, I see that a more structured and intentional engagement produces more deliberate, more coherent results, in the code, in the architecture, even in casual conversation.

Try it yourself

If you’re curious, read my delegation-tiers skill and borrow whatever helps. Tag your commits for a few months, then look at your own numbers. Notice where you hold the keyboard and where you let go, and ask whether that was a choice.

I also strongly recommend the free AI Fluency: Framework & Foundations course. In my opinion, it is worth the time for anyone who wants to work with AI in a meaningful and effective way.

AI will keep getting better at doing the work. What we choose to own is still up to us.