Michael Tweed is a principal software engineer helping lead AI adoption across Skyscanner's engineering organisation. After four years of experimentation, Skyscanner has moved beyond treating AI as an individual productivity tool: agents now help generate specifications, implement changes, review code, run validation loops and work across repositories.

In this episode, Michael explains what that transition means for engineering leaders and for the responsibilities of developers themselves. We discuss how Skyscanner turns local experimentation into shared capability through an AI champions network, skills marketplace and central configuration; why engineers increasingly review specifications and outcomes rather than every line of code; and how standards, curated knowledge and deterministic verification make greater autonomy possible. Michael also describes the move towards cloud-based orchestration, the human checkpoints required for larger work, and why the engineer's role is changing rather than disappearing.

About Michael
Michael Tweed is a principal software engineer at Skyscanner, working across its engineering platforms on AI adoption and developer experience. He began in mobile engineering before moving into mobile platform and developer-experience work. He now helps shape how several hundred Skyscanner engineers use agents, shared skills, organisational standards and validation systems to build software at scale.

Key ideas

• Agent adoption at organisational scale is not principally a tool rollout — leaders have to change the engineering environment around a changing division of work.
• Skyscanner combines distributed experimentation with shared infrastructure, using an AI champions network to surface useful practices that central teams make repeatable through skills, configuration and platforms.
• As agents perform more implementation, engineers increasingly concentrate on intent, specifications, architecture, constraints, verification and product outcomes.
• Autonomy should reflect consequence: Skyscanner gives internal tools more freedom while preserving deliberate standards in traveller-facing systems.
• Organisational knowledge must be curated before agents can rely on it, since an old draft or abandoned proposal can be actively harmful when retrieved as authoritative context.
• Passing checks are not sufficient if an agent can weaken the evidence, so verification loops need explicit boundaries, deterministic tools and independent signals.
• The engineer's role is changing rather than disappearing: towards defining outcomes, designing the development system and knowing when human judgement must interrupt autonomy.

Links
Michael Tweed on LinkedIn: https://uk.linkedin.com/in/mtweed
Skyscanner: https://www.skyscanner.net/

Tools mentioned: GitHub Copilot, Claude Code, OpenAI Codex, Model Context Protocol (MCP), Jira, Confluence, SonarQube

Tim Ottinger brings decades of Extreme Programming, Agile and software-craft experience to the demanding end of agentic engineering. His work asks how agents can accelerate delivery without eroding the architecture and knowledge that consequential, long-lived software depends on.

In this episode, Tim explains why an agent’s simplest path through a task can gradually erase a system’s design—and why the foundations of XP are gaining new leverage. We examine his use of small end-to-end slices, test-driven development and a distinctive checkpoint at which the agent stops before refactoring. Tim also shows how agents, tests and Git make ambitious legacy modernization more practical, how repository evidence can support better structural decisions, and why coherence became his eighth Code Virtue. The result is more than old practice with new technology: agents may allow teams to apply their best engineering disciplines more consistently and with fewer compromises.

In this episode

00:57 — Introducing Tim Ottinger and his place in the early Agile community
02:11 — Moving boldly—and safely—into agentic development
03:10 — Code as knowledge representation, not only instructions
04:32 — Why agents favour primitive solutions that gradually erase design
06:04 — Architecture recovery, tripwires and technical safety
07:03 — TDD, atomic commits and managing cognitive load
09:07 — What is the agent equivalent of trained intuition?
11:07 — Turning principles and heuristics into usable evidence
13:18 — Finding hidden coupling in Git co-change history
16:09 — Deterministic tools that help an LLM decide where to investigate
20:51 — Small end-to-end slices and a disciplined test-first workflow
23:30 — Why the agent stops when it proposes a refactor
25:14 — Teaching a skill to reject coincidental duplication
27:09 — Bringing books and articles directly into agentic work
28:50 — Coherence as the eighth code virtue
30:27 — Profitable and unprofitable intellectual labour
33:25 — Preventing agents from reproducing legacy design problems
34:13 — Refactoring an unfamiliar legacy codebase with agents
38:07 — How agents change the economics of refactoring
38:57 — Git makes ambitious structural experiments disposable
39:39 — Why testing has become dramatically more viable
40:28 — Learning software engineering when agents write the code
43:31 — Focus, pairing and the art of doing one thing at a time
45:02 — Combining hand coding, agents and mutation testing in training
48:36 — Slicing and verification as critical developer skills
50:41 — Why established Agile practices are gaining new leverage
51:42 — Vibe-coded applications and choosing an appropriate engineering level
54:12 — Turning a prototype into production software
55:23 — A Short Guide to Naming and skills as a new publishing form

Key ideas

- Agents tend to choose solutions that are mechanically simple and locally safe, but repeated local exceptions can gradually erase a system’s design.
- Small end-to-end increments keep work demonstrable and preserve opportunities to steer when complexity or consequence demands close control.
- Tim stops the agent whenever it proposes a refactor. The transformation may be easy to automate, but deciding whether an abstraction represents something true about the system remains a critical judgement.
- Agents, automated tests and Git make ambitious legacy experiments more practical. Work that would once have been too expensive to try can be generated, assessed, discarded or attempted differently.
- Tim gives agents an evidence base through skills, architecture recovery and deterministic analysis of Git history, which can expose coupling that source dependencies miss.

Ian Johnson’s team ships six to eight small tickets per developer each day. The real story is the system behind that speed. Ian explains how precise requirements, a truthful project charter, small pull requests and layered verification make coding agents dependable. We discuss comprehension debt, legacy refactoring, the amplification thesis and why the developer’s emerging role is to build the thing that builds the thing.

Ian Johnson is a staff engineer at Parento and author of Harness Engineering, a practical guide to reliable workflows for non-deterministic agents. His work explores how charters, verification and feedback loops can increase delivery speed without surrendering quality or accountability.

• 01:14: Introducing Ian and Harness Engineering
• 02:16: Ian’s role at Parento and the book’s origins
• 03:10: From autocomplete to agentic coding
• 04:42: Claude Code, Codex, Pi and parallel agents
• 06:34: Engineering a system for parallel agents
• 08:08: Review agents, checks and human accountability
• 10:01: Keeping changes small enough to review
• 11:01: One Jira card, one pull request
• 12:23: Falsifiable criteria and explicit exclusions
• 13:28: AI-assisted refinement without invented requirements
• 14:48: Decomposing features into releasable work
• 17:01: Shipping six to eight cards per developer daily
• 17:59: Feeding review lessons back into the harness
• 20:20: The charter as an agreement with agents
• 23:17: Agents amplify order and disorder
• 24:55: Structuring and indexing project context
• 26:32: Why inaccurate rules damage output
• 27:58: Truthful rules and living migration plans
• 29:39: Refactoring legacy code with tests and TDD
• 31:58: 100% coverage as a local safety boundary
• 33:10: Why cheap code must still be maintainable
• 35:47: Human oversight and comprehension debt
• 36:57: Resisting cognitive surrender
• 39:33: Pairing a junior, senior and coding agent
• 42:57: Evaluating charter and harness changes
• 45:56: Raising the developer’s abstraction level
• 47:33: Building the thing that builds the thing
• 51:06: Amplification and acceptable reliability
• 53:19: Why a hook beats a rule

• Tickets control what an agent builds; the charter controls how it builds it.
• Small batches and falsifiable acceptance criteria keep agent work reviewable.
• Tests, hooks and analysis turn standards into evidence.
• Agents amplify their environment, but humans retain accountability.

• Ian Johnson on LinkedIn
• Ian Johnson on Medium
• Ian Johnson on DEV Community
• Harness Engineering on Leanpub
• Parento