Skip to content
Highnet
DE

Bringing a team up to date on AI

Most teams aren't behind because they lack tools. The tools were bought and handed out, but review, CI and ownership never changed — so agents write code nobody reviews any differently, and delivery stays exactly as it was.

This is how I fix that: a ladder with five rungs. Each rung ships something useful on its own, and none of them asks you to rewrite how you already work. I find the rung you're on, move you to the next one, and let it hold before proposing anything else.

Finding your rung

Before I change anything, I look at how the team actually works:

  • The repository and its pull requests — instruction files, CI configuration, review history, who approves what.
  • Short conversations with engineers, leads and whoever owns security.
  • A real ticket, paired — watching how AI is used on actual work, not how people say it's used.

How long a rung takes varies by team. I don't promise a date up front; the first weeks of work set the estimate.

The five rungs

1. Autocomplete

What it looks like: Engineers accept completions in the editor. Nothing else about the delivery process has changed — the tool could disappear tomorrow and no process document would need an edit.

Step to rung 2: Start a repository context file. An AGENTS.md that describes the codebase's conventions makes every model answer fit the code it's going into.

2. Chat

What it looks like: A model sits in a side panel. People ask it questions and paste the answers in. Nobody can say which parts of a release were model-written.

Step to rung 3: One agent, real tickets. A volunteer runs an agent on real backlog issues end to end, and every result arrives as a normal pull request.

3. Agents in pilot

What it looks like: One or two enthusiasts let agents do whole tasks. It works for them — and it hasn't spread, because the guardrails live in their heads.

Step to rung 4: Move the guardrails into the repository. Code ownership, review gates and human-only paths become files, not habits. And one rule becomes absolute: no agent, and no author, approves its own work; any new push resets the approval.

4. Governed agentic delivery

What it looks like: The whole team works with agents through ordinary pull requests. Ownership, permissions and review gates are enforced by the repository. Every agent change has the same audit trail as any other change.

Step to rung 5: Four things must be true first. Well-specified issues are the only work queue, and agents claim them atomically. An independent agent reviews every pull request against its issue. CI is trustworthy enough that green can gate a merge. And people approve the specifications agents draft, and own the human-only paths and the escalations.

5. Autonomous delivery loop

What it looks like: A fleet of agents plans, implements, reviews and merges through a protocol, with GitHub as the single source of truth. People hold the human-only paths and settle what the loop can't. How I run mine

Where to stop: Not every team should climb to rung 5. The right rung depends on what a bad change costs you, and a high-stakes team may deliberately stop at rung 4.

Workflow design

  • Start with the instruction file. AGENTS.md is the first artifact and the portable source of truth; tool-specific files such as CLAUDE.md import it.
  • One concern per pull request. The most common failure I see is the huge agent diff that gets approved because nobody can really review it. Decomposing work into small, independently shippable units is the most important skill a team learns.
  • Approval resets on every push. A reviewed change that changes again is an unreviewed change.
  • Two rounds, then escalate. When an agent and its reviewer haven't converged after two rounds of requested changes, a person who can decide takes over. There is no third round.
  • Connect context deliberately. Each MCP connection is a permission decision, scoped to the task.

Governance

  • Human-only paths. Payments and credentials are never changed by an agent. This is enforced, not requested: agent permission deny-lists block edits to those paths outright.
  • No self-approval. No agent approves its own work.
  • Auto-merge on green and review. An agent pull request merges automatically once an independent reviewer has approved it and CI is green — except on human-only paths.
  • Secrets stay out of agent context. Credentials are injected at runtime, never shown to an agent.
  • Vendor and data review before rollout. Data retention, training opt-out and EU hosting are checked before a tool reaches the team.
  • Budgets with alerts. Each team has a spend budget that alerts before it overruns.
  • Measure what changed. Lead time and throughput before and after; change-failure rate, reverts and red CI that don't get worse; and whether the workflow runs without me.

Responsible AI and EU regulation

  • GDPR first. Before a tool or feature ships I map what data reaches the model: which processors see it, how long it's kept, whether it trains anyone's model, and where it's hosted. Personal data stays out of prompts and agent context unless there is a legal basis for it.
  • EU AI Act by use case. Coding agents inside an engineering team are rarely where the obligations sit; AI features in a product can be. I classify each use case by risk before it's built, so transparency duties or high-risk requirements show up at scoping, not at launch.
  • AI literacy is part of the job. The Act expects the people using AI systems to understand them. Enablement done properly — people who know what the tools do, where they fail and when to escalate — is how a team meets that.
  • Responsible AI frameworks as checklists. Fairness, transparency, privacy, security and accountability are reviewed for every AI feature, with a named owner for each.
  • Security of AI features. Prompt injection, over-broad tool access and data leaking through context are treated as ordinary security risks: least-privilege tools, secrets outside the model, and tests for the failure cases.
  • Legal stays with legal. I flag the GDPR and EU AI Act implications of tool choices and data flows, and bring in legal counsel where a decision needs one.

Tool evaluation

I work with Claude Code first, and with OpenAI Codex, OpenCode, GitHub Copilot and Cursor where a team already uses them.

  • Real backlog, never demos. A tool is piloted on real issues from the team's own backlog.
  • Keep it portable. Instructions live in AGENTS.md and workflow state lives in GitHub — issues, labels, branches and pull requests — so switching tools doesn't mean starting over.

Onboarding

  • Start with the willing. The people already using agents go first; the practice spreads from them.
  • Pair, don't present. Enablement happens on real tickets, not in lectures.
  • Half-day workshops in your own repository. Everyone ships one real pull request with an agent before they leave.
  • Take objections seriously. Most objections name a real risk; I turn them into guardrails. Sceptics make the best reviewers of agent output, so that's the role I give them. Adoption is never mandated — results do the persuading — and I show it on their own code, not a toy example.
  • Review is the new craft. Engineers move from typing code to specifying and reviewing it. Juniors learn faster reviewing agent diffs alongside a senior.
  • Beyond engineering. Product managers learn to write specs agents can execute and reviewers can check; designers ship UI with agents and design skills; QA uses agents for test writing, triage and regression checks; operations teams automate docs, runbooks, support and reporting.

What the team keeps

  • Instruction files tuned to the codebase.
  • Guardrails in the repository: code ownership, hooks, permissions, CI checks and deny-lists.
  • Team skills and plugins that package the workflow so the team can run and extend it.
  • A runbook and decision log: how the loop runs, how to debug it, and what was tried and dropped.

Success means it keeps running after I step back.

Email me