Show Notes
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
More from The Next Commit
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.
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. About Ian 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. In this episode 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 Key ideas 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. People and links Ian Johnson on LinkedIn Ian Johnson on Medium Ian Johnson on DEV Community Harness Engineering on Leanpub Parento