How AI grows me
Coding gives you reps every day. Architecture and leadership do not. Thirteen architecture katas, a leadership trainer that role-plays the hard conversation back at you, and a Friday audit that refuses the phrase "good week" without evidence.
Most AI use is about producing things. Code, configs, docs, summaries. Faster output, same job.
This is about the opposite. Not producing anything, and getting better on purpose.
The reason is a gap that took me a while to name. You get better at coding by coding. It is constant and hands-on, and you get reps every day whether you mean to or not. Architecture and leadership do not work like that. At work I design inside one domain, with constraints that rarely change, so the range of problems stays narrow. Leadership is the opposite kind of problem: the hard moments are unpredictable, always live, and you never get a second take.
Neither one gives you a safe place to practise. So I built one.
A kata is a practice drill you repeat to sharpen a skill. Mine run with AI as the sparring partner: it sets the problem, I solve it, and it argues back. That is the whole inversion. AI as the thing that pushes back, not the thing that does the work.
Architecture: thirteen problems in domains I do not work in
I read a stack of architecture and system design books. Finished each one feeling smart, then stalled on real designs. Reciting tradeoffs is not the same as making them under pressure.
So the trainer, built with Claude and drawing on those books, mainly Fundamentals of Software Architecture and Domain-Driven Design.
Version one, the first nine katas, traded depth for volume. Claude hands me a fresh system-design problem. I solve it. It scores the design and writes two reference solutions to argue against mine. Nine problems, nine domains, fast.
Version two, from kata ten, trades volume for depth. One problem stretched across a week:
Monday I dump my instinct answer
Midweek Claude interrogates every decision with nothing but "why?"
Thursday I rewrite the weakest part
Friday one question: can you defend this to a principal engineer?
No score anymore. Just that question.
Thirteen done, the fourteenth in progress. Event ticketing, multi-tenant SaaS, an internal developer portal, a legacy API gateway migration, IoT fleet monitoring, active-active disaster recovery, event-driven order processing, clinical trial enrollment, real-time sports betting, live streaming, multi-region networking, zero-trust service mesh.
The best part was not planned. Every kata is a domain I do not work in, and something always sticks. From the live-streaming one: how personalised ads get spliced into a stream mid-broadcast. Am I an expert? No. But the problem is on my map now, with an entry point for when I need to go deeper. Thirteen domains of that, for the cost of a weekly drill.
The trainer still beats every book on the shelf, and the reason is not the model. It is that a book cannot ask me why.
Leadership: rehearsing the conversation before it happens
Same idea, harder problem. The architecture version drills design decisions. This one drills the conversations you normally only rehearse live, on a real person, with real consequences.
It is not a method I would prescribe to anyone, because it is built around how I specifically operate. When I started mentoring sessions last year, one of the first things I was asked to do was CliftonStrengths, so I would understand how I lead. Top of my list: Relator, Learner, Responsibility, Achiever. Excellent for ownership and depth. They also push me to over-own, and to reach for logic before people feel heard.
That is the useful part. The trainer is tuned to those specific tendencies rather than to leadership in general.
Scenarios come from leadership books (Extreme Ownership, Radical Candor, The Coaching Habit) across three areas. Strategic: stakeholders, priorities, org change. People: feedback, conflict, trust. Self-leadership: my own blind spots.
Three I keep coming back to, one from each:
- Saying no to a senior stakeholder without it sounding like you cannot deliver
- Giving honest feedback to someone more experienced than me
- Knowing when to stop optimising a decision and just make the call
The mechanic that makes it work: Claude writes up a scenario, I write how I would handle it, then it role-plays the other side, in character, pushing back. It is easy to plan a calm, reasonable approach. It is much harder when the person gets defensive and the script you wrote falls apart three messages in.
Afterwards it scores the exchange and runs a blind-spot check tuned to those exact tendencies. Did I challenge directly but still care personally? Did I ask before I started solving?
This does not make me a better leader on paper, and I cannot measure that. What it gives me is reps. I have walked these murky situations in training mode, so when a real one lands I am not meeting it cold, and not as easily thrown.
The loop that catches me lying to myself
A busy week and a good week feel identical from the inside. That is the trap.
A full week feels productive, but if none of it went toward a goal you end up where you started, and you will not notice for months.
I have two goals this year: go deeper into platform architecture, and grow as the lead of a team of four. The architecture katas and the reading feed the first. The leadership katas and books feed the second. But a goal with no feedback loop is a wish. So: two questions, one at each end of the week.
Monday is planning. It reads my calendar and the two lists that always fight for my time: the sprint board, which is loud and urgent, and a backlog of bigger platform-wide problems that never carry a deadline. Left alone, the sprint board wins every time. Monday makes me name the one or two things that actually move a goal, and block the time before the week fills up.
Friday is the audit, with one rule: no claim without evidence. When I type “good week”, it asks “based on what?”
Did any of this move a goal, or did I just stay busy?
Did a decision this week make next week easier?
The loop works because of how I am wired. I need data and something to optimise, and once I can see it move, it carries me through the weeks when motivation is gone.
Six months in, the proof is concrete: books finished instead of stacked, the katas run most weeks, and my name on real platform decisions I would have let slip in a reactive week.
Busy and invested are not the same thing. Most of us only track one.
Why the layers matter more than any layer
These look like three separate habits. They are layers feeding one thing.
the coach
challenges me, names blind spots,
hands me a plan I did not want
▲
│ feeds
the weekly loop
Monday: what moves a goal
Friday: did I actually move?
▲
│ feeds
the inputs
architecture katas · leadership katas
books · notes
The katas, the reading and the notes feed the weekly recaps. Months of those recaps feed a coach. So when I ask where I am drifting, it is not guessing from one clever prompt. It is reading the whole paper trail of how I have actually spent my time, what I keep avoiding, where I said one thing and did another.
That is the part you cannot fake in a single session. The value is not the model. It is the context underneath it, written down week after week until the patterns cannot hide.
What it gives back: the blind spots I route around, the gap between where I am and where I want to be, and a plan I did not want.
The honest part
What it concludes stays with me. But the structure is the point, and the structure has a hole in it: a coach is only as honest as the data you are willing to keep on yourself.
Mine is incomplete in the direction you would expect. The weeks I skip the Friday audit are not random weeks. They are the bad ones, which are exactly the ones worth the evidence. The katas run “most weeks”, and the gaps cluster in the months when work got loud, which is precisely when practice matters and precisely when it stops.
None of this makes the loop useless. It does mean the record is biased toward my better weeks, and I have not solved that. A system that only measures you when you feel like being measured is a system with a very specific blind spot, and naming it is the least I can do about it.