Adaptive × AI

The intention

Fifteen years ago I stopped building software for a living and started coaching the people who do. The code got quieter. The curiosity never did.

Which means I am late to the AI party — at least to the part that goes beyond prompting. Fashionably late, I tell myself.

Now AI looks like one of those rare moments when technology changes how people work together — not incrementally, but structurally. This journal documents my attempt to understand that change. Not from the outside: by building, by experimenting, by learning in public.

Working hypothesis: the biggest challenge of the AI disruption is not the technology. It is whether your business model, leadership model, and operating model — all built for a different world — can adapt fast enough to benefit from it instead of being disrupted by it. Adapting them is a leadership challenge.

I don't have answers yet, and I'm suspicious of anyone who claims to have them this early. On good days, that includes me.

The team

This started as a one-person journey. It isn't one anymore — though I am still the only human.

Morten Market holds the role Marketing & Sales: he harvests the journal for post ideas, drafts the posts and generates their images, delivers each one as a pull request, watches the posting queue and builds the statistics reports. The last read-through before anything goes out stays mine. He lives on a different platform than the rest of my work, has his own GitHub account, and his commits are authored by him instead of by me. The role is named wider than what he actually does: sales is an open slot, because a gap you can name is a gap you can close. Claude Code is my pairing agent for engineering, drafting, and this journal, still working inside my sessions and through my identity, which is the honest asterisk in this list.

There is exactly one GitHub team, crew: cross-functional, one human plus n agents, with roles named inside it rather than teams named after functions. The commitment that comes with that is no second team: the next agent joins this one and gets a role. The team is the constant; the endeavors it works on are the backlog, which is why it is not named after one of them. And I sit in it rather than above it: if everyone contributes to the team's goals to the best of their knowledge and conscience, then the one holding the responsibility belongs inside the team.

What I have learned so far

Business model

• AI is infrastructure and DNA, not IT. It touches every step of the value chain, it can open new markets for new business models, and it reaches the people in the organisation and how they work together. That makes it a leadership question rather than an IT purchase, and explains why so many AI initiatives return nothing.
• How deeply you take AI into your own hands is a decision. Only the application layer, or the model layer, or the infrastructure underneath — a question of sovereignty. And not one to outsource.
• Value creation gets more compact, so the weight moves to deciding what to build. Delivery gets faster and works with smaller teams, sometimes down to “1 + AI”. What stays expensive is the judgement: what is worth building and what is not. And when building something testable costs less than arguing about it, that decision gets made by trying instead of debating.

Leadership model

• Player Coach: leadership moves back close to the work. The coordinating manager loses his reason to exist as the value-creating unit shrinks toward one person plus their agents. I did not adopt the model because it was named; the line about being back in the game as a player-coach went into my team profile the same afternoon I first met it.
• Enable before you empower. Only someone who has the context can decide. Authority without it is not empowerment, and that holds for an agent exactly as it holds for a team.
• A mechanism beats a rule. A rule somebody has to remember gets replaced by a mechanism that enforces it, wherever that is possible. What is left over is the part where I do not yet know all the cases.

Operating model

• Structure follows how the work is really done — not the other way round. A team named after a function describes an org chart; a role named inside a team describes who does what. Only the second one survives contact with how the work actually runs.
• A handover moves the work before it reduces it. After the handover you no longer write, you review and judge. That is a different job, not a smaller one — and the review is where you have to understand, not just read.
• The road to an agentic organisation is demanding, and governance is what enables it. Structure, alignment, ownership: a model that sets the right frame at the right phase rather than one that holds things back.

Some of this was learned by building, some of it came from outside. Those sources are on the learning resources page, each with what it actually changed.

The laboratory

Every experiment needs a subject. Mine is a hobby project of honorable age: a Java static-site generator I wrote years ago to chronicle our pen-and-paper RPG campaigns — The Chronicles of the Flying Cauldron. It has legacy code, technical debt, historical decisions, and forgotten assumptions. The engine is public: chronicler-engine. The campaign data it renders stays private.

In other words: it is perfect.

Modernizing it with agents doing much of the work is what this journey set out to be, and the craft questions still belong to it: what an agent can be trusted with, and who is actually coaching whom. It is idle at the moment: the second subject has been taking the time.

That second subject is this business itself. A one-person practice is small enough to change in an afternoon and real enough that the change costs something, which makes it the better laboratory for the questions the code cannot answer: how work gets organised, and what a leader still does when the delivering unit shrinks to one person plus their agents. Most of what stands on this page now was learned there.

One honest caveat: neither subject exercises product discovery. That leg still needs an experiment of its own.

How we work

• One entry per working session, in a public repository, following a template: what happened, the craft of it, and what it means for a business model, a leadership model and an operating model, plus what is still open. A section a session gave nothing for is left out rather than filled.
• A strict division of labour: the AI may draft the facts. The reflection stays handwritten. Some things shouldn't be delegated — the journal's own rules say so, and so far the journal is right.
• Entries are immutable records of their moment. When the thinking changes, a new entry says so — the old ones stay exactly as wrong as they were.
• The workbench is the repository. An organisation holds the repos; humans and agents are members with their own accounts and permissions. Write access flows through the team, an agent's credential grants exactly two rights on exactly one repository, the main branch is protected, and every pull request routes to me for review. Each rule is both a control and a statement: who belongs, who contributes, who decides.
• Two channels, and one of them stays almost empty. Everything normal goes to the team channel; the second is reserved for the few cases that have earned the right to interrupt me. What counts is an enumerated list in the agent's instructions, not a judgement call. An escalation that shares a room with everyday traffic stops being a signal.
• Chat may trigger the work; the repository defines it. A correction that only ever happens in a chat message leaves the cause in the repo, ready to reappear next time, so the brief lives in the repository, and re-reading it is part of the job.

Follow along

This page describes where things stand today. Nothing here was designed up front: every part of it is the current result of an evolution through learning, and each step, including the wrong turns, is written down in the journal. The full journal is public: github.com/zandercoach/adaptive-x-ai.

Not everything is learned by building. What came from the outside — books, videos, webinars, trainings — is collected on the learning resources page.

I post occasional updates on LinkedIn. My coaching and training practice lives at zander.coach.