What building an AI development lifecycle taught us
For the past few months I have been building an AI development lifecycle with a delivery team.One system, many years in the field, and a team that handles customer-specific requests on top of it. We started like any other change project, with a two-week assessment. In it we mapped how work actually moves today, from […]
Claude Code for Developers
1-day Workshop · Practical AI training · Hands-on workshop23/12/2026 · 09:00 – 17:30 👉 Save Your Seat HERE Overview AI coding agents have changed what a developer’s day looks like. Most developers have tried one. Far fewer use one well. The gap isn’t the tool. It’s knowing what the agent knows, how to ask […]
Somewhere in your AI adoption there’s a line. Cross it, and things may stop working as expected.
What changes when the line is crossed is how much your team understands the system.Nobody got worse at their job.Code simply arrives faster than anyone can keep up. Most of our practices rest on an assumption we never had to say out loud: someone on the team understands this code.Code reviews, design reviews and testing […]
Where the regime changes [Part 3]
The Three Physics of Software: when you can no longer review 100% of changes In this series I’ve been describing a regime change. When code is written at machine speed, some of the rules we have always built software on stop holding. A regime change has to happen somewhere. This post is about where the […]
Why your agent keeps building what you already have
Last month an agent I was working with wrote a completely new paging mechanism.The problem was that the system already had a built-in way of doing this. The agent didn’t use it.This was not the first time I noticed it. Over the last few months I have seen it as a pattern.Coding agents prefer creating […]
You can generate code faster than you can delete it [Part 2]
(The Three Physics of Software — part 2 of 2: disposability, and the escape surface) Left alone, that only goes one way: the codebase accumulates and complexity rises. Part 1 is the reason it matters.The same codebase behaves like a heavier object at higher velocity, so the cost per change goes up.And slowing down does not […]
Nothing was added to your codebase. It got heavier anyway [Part 1]
(The Three Physics of Software — part 1 of 2) All our software building practices were formed with a single constraint in mind: people wrote the code. Therefore, producing it was slow and expensive. Reviews, onboarding, design docs, keeping modules small. All of it tried to maximise the effectiveness of the people writing the code. […]