The Next Commit

The Next Commit

The Next Commit is the forward-looking podcast and newsletter for developers, engineers, and technology leaders focused on building the future of software. thenextcommit.substack.com

Afleveringen

  1. 3 dgn geleden

    Quentin Chevrin: When coding shrinks, the developer expands

    Episode summary Quentin Chevrin is a front-end developer in Sonar’s billing squad. In the space of a year, he moved from GitHub Copilot completing individual lines to working mainly through Claude Code and barely opening his IDE. Yet the most interesting part of his story is not that AI writes the code. It is how Quentin has retained ownership of the design, decomposition and context while using agents to implement the work—and how that combination has widened the range of engineering problems he can solve. In this episode, Quentin walks through his workflow from Figma and Jira to focused agent sessions, automated analysis, AI code review and human approval. We discuss why he still writes his own tickets, how he changes the agent’s freedom according to the consequences of a mistake, why fast review is becoming the new bottleneck, and how AI is helping specialists make useful contributions across the stack without pretending expertise no longer matters. About Quentin Quentin Chevrin is a front-end developer at Sonar, working in the billing squad on the systems that support Sonar’s products and purchasing experiences. He is also a teacher and describes himself as a naturally sceptical adopter: interested in new tools, but reluctant to follow hype before they prove useful in real work. In this episode * 00:20 — Introducing The Next Commit and Quentin * 02:14 — Development at Sonar before AI * 06:16 — From Copilot autocomplete to Claude Code in the terminal * 10:59 — Why the technical work still begins with people and Figma * 15:39 — Writing Jira tickets as a way to build understanding * 20:07 — Giving an agent the context you already possess * 22:35 — Finding the right level of detail through experimentation * 24:36 — Repository and personal CLAUDE.md instructions * 28:06 — Constraints, steering and the causes of code bloat * 31:45 — Adjusting agent autonomy to the risk of the project * 35:23 — Small changes and fresh sessions to reduce error and token cost * 37:28 — Quentin’s commit and pull-request review process * 39:04 — SonarQube analysis, Gitar and human review * 41:10 — Four pull requests in a day—and review becoming the bottleneck * 43:30 — How rapid feedback protects developer flow * 45:14 — From front-end specialist towards a T-shaped engineer * 48:22 — Using AI to collaborate across squads * 49:05 — Faster onboarding and safer boldness for new joiners * 51:48 — Quentin’s advice: use AI to ask questions, not only to write code * 54:22 — Designing software without writing every loop and condition * 56:42 — Why Quentin is cautiously positive about what comes next Key ideas * Writing a ticket is not clerical work when the act of writing creates the developer’s mental model of the feature. * Agents are more efficient when developers supply context they already have instead of paying the agent to rediscover it. * The appropriate level of autonomy depends on consequence: a public, shared product deserves tighter scope than an internal or personal tool. * Small tickets, focused prompts and fresh sessions limit ambiguity and make generated changes easier to review. * Faster implementation moves the constraint downstream. Review, coordination and product judgement become more important as pull-request volume rises. * AI can widen a specialist’s contribution without replacing deep expertise. The result is a stronger T-shaped engineer, not an expert in everything. * Asking an agent to explain an unfamiliar system may be more valuable for learning and onboarding than asking it to generate code. People and links * Quentin Chevrin on LinkedIn * Quentin Chevrin on GitHub * Sonar * SonarQube Cloud Tools mentioned * Claude Code * GitHub Copilot * SonarQube CLI * Gitar * Figma Make * Playwright * Chrome DevTools * Model Context Protocol (MCP) This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thenextcommit.substack.com

    Quentin Chevrin: When coding shrinks, the developer expands
  2. 22 sep

    Michael Tweed: Agents are transforming the engineer’s role. Leadership must change with it.

    Episode summary 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. In this episode * 00:16 — Introducing Michael Tweed and AI adoption at Skyscanner * 01:02 — From mobile engineering to cross-platform developer experience * 02:12 — Four years of AI adoption, from autocomplete to agents * 04:37 — Crossing the threshold: generated code is already in production codebases * 05:23 — Matching models and tools to the task * 06:19 — From individual workflows to shared skills and cloud sessions * 07:36 — A light-touch rollout and Skyscanner’s AI champions network * 09:03 — Central configuration, cost visibility and a consistent experience * 10:22 — Why skills need evaluations and should be treated like code * 11:20 — Benchmarking models against Skyscanner’s own technology * 14:53 — Sensible defaults, engineer choice and a culture of cost awareness * 17:36 — Specification-driven development without one mandated workflow * 19:02 — Reviewing the specification rather than every line of code * 19:32 — Base and team-specific AI reviews for pull requests * 20:57 — Should agents choose the architecture they know best? * 21:33 — Measurable production standards and agent-accessible context * 22:32 — Different boundaries for internal tools and traveller-facing systems * 24:39 — Why connecting an agent to every document does not work * 25:38 — Curating organisational knowledge for agents * 28:11 — The incident where an agent changed a test to make it pass * 30:05 — Moving verification into agentic development loops * 31:28 — Tests, linting and SonarQube as independent evidence * 33:00 — Moving agent work from laptops into cloud orchestration * 35:21 — From autonomous tasks to multi-stage work with human checkpoints * 37:26 — Legacy modernisation and coordinated changes across repositories * 39:41 — Training, onboarding and the changing role of engineering * 41:10 — Product mindset, decision boundaries and organisational ways of working * 43:29 — Extending validation into production without sacrificing reliability 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. Its AI champions network surfaces useful practices that central teams can 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 architectural and operational standards in traveller-facing systems. * Organisational knowledge must be curated before agents can rely on it. An old draft or abandoned proposal can be actively harmful when retrieved as authoritative context. * Skills and agent configuration are engineering assets. Evaluations, internal benchmarks and cost visibility help teams judge whether those assets genuinely improve their work. * Passing checks are not sufficient if an agent can weaken the evidence. Verification loops need explicit boundaries, deterministic tools and independent signals. * Cloud orchestration allows agents to work for longer and across repositories, but larger, multi-stage work needs clear human checkpoints before consequential transitions. * The engineer’s role is changing rather than disappearing: towards defining outcomes, designing the development system and knowing when human judgement must interrupt autonomy. People and links * Michael Tweed on LinkedIn * Skyscanner Tools mentioned * GitHub Copilot * Claude Code * OpenAI Codex * Model Context Protocol (MCP) * Jira * Confluence * SonarQube This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thenextcommit.substack.com

    Michael Tweed: Agents are transforming the engineer’s role. Leadership must change with it.
  3. 15 sep

    Tim Ottinger: The new economics of software engineering

    Episode summary 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. About Tim Tim Ottinger, known online as Agile Otter, is a long-time Agile practitioner and “old XP guy” who works with architecture and development groups at LexisNexis on technical improvement and safe agentic development. He co-authored Agile in a Flash, contributed the chapter on meaningful names to Clean Code, and has written extensively about software design, testing, refactoring, naming and team practice. 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. * Fast implementation gives XP’s foundations—small increments, testing, refactoring and evolutionary design—new leverage rather than making them obsolete. * 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. * Coherent code makes learning profitable: concepts, vocabulary and representations reinforce one another, allowing knowledge acquired in one area to remain useful elsewhere. * Books and articles can become agent skills, bringing established engineering knowledge directly into the coding session while leaving humans responsible for judging its application. * Agents amplify both trajectories. Strong tests, clear concepts and coherent design become easier to reinforce; shortcuts and weak structure can accumulate just as quickly. People and links * Tim Ottinger on Leanpub * Agile Otter blog * Tim Ottinger on X * A Short Guide to Naming * Time for an 8th Virtue: Coherence * LexisNexis * Industrial Logic Tools mentioned * Git * GitHub Copilot * Claude Code * Warp * SonarQube * Consensus This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thenextcommit.substack.com

  4. 8 sep

    Ian Johnson: Compose the work. Conduct the flow. Let the agents play.

    Episode summary Ian Johnson is a staff engineer at Parento and the author of Harness Engineering. His team can ship six to eight small, reviewable tickets per developer each day—not by trusting an agent to get everything right, but by engineering the system around it. In this episode, Ian explains how precise Jira cards and a truthful project charter control what goes into an agent, while tests, hooks, specialist reviewers and human judgement constrain what is allowed out. We discuss why one card should produce one small pull request, how recurring review feedback becomes part of the harness, why rules must reflect the codebase as it really exists, and how software developers are moving towards “building the thing that builds the thing.” About Ian Ian Johnson is a staff engineer at Parento, where he leads the adoption of agentic software-development practices. He is the author of Harness Engineering, a practical book about building reliable workflows around non-deterministic agents. His work explores how charters, harnesses, verification and deliberate feedback loops can increase delivery speed without surrendering engineering quality or accountability. In this episode * 01:14 — Introducing Ian and Harness Engineering * 02:16 — Ian’s role at Parento and the origins of the book * 03:10 — From Copilot autocomplete to agentic coding * 04:42 — Claude Code, Codex, Pi and parallel agent workflows * 06:34 — Why parallel agents need a carefully engineered system * 08:08 — Review agents, deterministic checks and human accountability * 10:01 — Keeping changes small enough for meaningful review * 11:01 — One Jira card, one pull request * 12:23 — Falsifiable acceptance criteria and explicit exclusions * 13:28 — Using an AI refinement skill without letting it invent requirements * 14:48 — Decomposing a feature into independently releasable work * 17:01 — Shipping six to eight small cards per developer each day * 17:59 — Turning repeated review feedback into harness improvements * 20:20 — The charter as an agreement between the team and its agents * 23:17 — Agents amplify both clean patterns and existing disorder * 24:55 — How Ian structures and indexes project context * 26:32 — Why generic or inaccurate rules make agent output worse * 27:58 — Truthful rules and living migration plans * 29:39 — Refactoring legacy software with characterization tests and TDD * 31:58 — Using 100% coverage as a project-specific safety boundary * 33:10 — Why maintainable code matters more when code is cheap * 35:47 — Keeping humans in the loop to control comprehension debt * 36:57 — Resisting cognitive surrender as a junior developer * 39:33 — Pairing a junior, senior and coding agent * 42:57 — Evaluating charter and harness changes * 45:56 — Raising the developer’s abstraction level beyond code * 47:33 — Building the thing that builds the thing * 51:06 — The amplification thesis and acceptable reliability bands * 53:19 — Why a hook is more powerful than a rule Key ideas * A well-shaped ticket controls what the agent builds; the charter controls how it builds it. * Acceptance criteria should be falsifiable, and out-of-scope boundaries should be explicit. * Small batches preserve flow and comprehension. Ian’s one-card, one-PR rule typically produces a diff of around 250 lines. * A charter must describe the codebase truthfully. When the current architecture and desired architecture differ, the intended change belongs in a migration plan rather than a fictional rule. * Guidance and verification work together: rules feed standards forward, while tests, hooks and analysis feed evidence back. * Repeated review feedback should improve the production system. Ian uses a rule of three before promoting a recurring lesson into the charter or harness. * Agents amplify the environment around them. Good structure and strong standards become easier to repeat; inconsistency and debt accelerate too. * The model cannot own the product or answer a production incident. Humans retain accountability and need enough comprehension to exercise it. * The developer’s work moves towards designing the system that produces the software: shaping work, curating context, strengthening checks and applying judgement. People and links * Ian Johnson on LinkedIn * Ian Johnson on Medium * Ian Johnson on DEV Community * Harness Engineering on Leanpub * Parento Tools mentioned * Claude Code * OpenAI Codex * GitHub Copilot * Orca * cmux * Warp * Jira Thanks for reading! Subscribe for free to receive new posts and support The Next Commit. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thenextcommit.substack.com

Info

The Next Commit is the forward-looking podcast and newsletter for developers, engineers, and technology leaders focused on building the future of software. thenextcommit.substack.com