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.

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 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.

In other words: it is perfect.

The plan is to modernize it with AI agents doing much of the work, while I take notes on who is actually coaching whom.

One honest caveat: this laboratory only exercises the product-engineering leg of the journey. AI's impact on product discovery and on the organization itself will need experiments of their own. My one-person business is a likely candidate.

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 watches the posting queue, builds the statistics reports, generates the post images and delivers them as pull requests. 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.

How we work

• One entry per working session, in a public repository, following a fixed template: what happened, technical learnings, organizational learnings, a leadership perspective, open questions.
• A strict division of labor: 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 organization 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.

Learnings from the first weeks

• Safety nets make trust cheap. Characterization tests and a published baseline came before any refactoring; a protected branch and a review gate came before an agent got write access. The same principle at two levels — I never had to decide whether the agent deserved the access, only to make sure the worst case was a rejected pull request.
• Verify, don't assume. Twice in one session, the "obvious" answer about 15-year-old code was wrong and an empirical check was right. This applies to the agent. It also applies to me.
• Documentation is suddenly almost free — and it compounds. Well-kept notes turned a later cleanup from an afternoon of archaeology into minutes. Agents read your docs. Write them.
• Agents make mistakes the way people do. And leading one feels oddly familiar: set a goal, give context, draw boundaries, give feedback, stay in the loop. My coaching vocabulary transferred better than my Java did.
• Correct the brief, not the worker. An image came back saying the exact opposite of the post it belonged to. The defect was an ambiguous sentence in the prompt, not a badly done job — and fixing only the image would have left the cause sitting in the repository. With an agent that reflex comes for free: no ego in the room, and the brief sits right there in the diff next to the result. I'd wish for more of it with people.
• Delegation needs an address. For a while the agent worked through a credential of mine, so his commits were indistinguishable from my own. In a project about who is actually doing what, attribution is not cosmetics. He has his own identity now. My pairing agent still doesn't.
• You learn as fast as you build. When building gets cheap, evaluating ideas gets cheap, and pivoting gets cheap. This project reframed itself twice in its first month; each pivot cost an afternoon, not a quarter.
• The work shifts from doing to judging. This page went from idea to live site — copy, domains, DNS, legal fine print — in one afternoon, with an agent doing and me supervising, reviewing, adjusting. Knowing how to do things mattered less than judging what was right: accuracy, impact, risk. A repo is notes; a domain is a statement.
• Speed cuts both ways. I have heard about the mess that speed produces. So far, the safety nets are holding. Ask me again in a few entries.

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.