Posts on Jonathan Dean

Engineering with Agent Teams

Thu, 03 Sep 2026 00:00:00 +0000

Working with a single agent produces something that looks finished. But knowing whether it is correct is harder. Over the past few weeks I have been designing a multi-agent workflow in Claude Code, building on the ideas in my previous post on how the team I led uses AI. An engineer’s most valuable contribution shifts: away from writing code, toward directing agents, reviewing their output, and deciding what their disagreements mean.

Eight Months with unFix

Tue, 05 May 2026 00:00:00 +0000

I wrote last September about adopting the unFix model and how I set up the structure. Eight months in, it feels like the right moment to be honest about what has worked, what has not, and where the genuine tensions are.

What is working Link to heading

Ownership is clearer. The Crew model does what it is supposed to do. In a function-organised structure, “who is accountable for this?” is a question that regularly requires escalation. Under the Crew model it mostly has a structural answer. Crews know what they own, and that changes how conversations happen.

AI and the Cost of Doing Things Properly

Wed, 08 Apr 2026 00:00:00 +0000

I recently built a home network configuration system I had been deferring for years. The reason was not complexity. It was overhead. Debian packaging has a lot of well-specified, repetitive mechanical work: the kind where you know exactly what the output should look like but do not want to produce it by hand. With an AI assistant, I described what each package needed to do and got a correct skeleton back in seconds. The overhead that previously made a dozen small packages feel like a large project collapsed to almost nothing. I built it the right way, and it took a weekend rather than a month of accumulated evenings. The technical details are in a separate note.

AI in Engineering: How My Team Works

Fri, 20 Mar 2026 00:00:00 +0000

This post covers how the engineering team I lead is using AI tools in our day-to-day work: what we use, how it works, and what it has changed.

The pressure is real: we are building something genuinely new while simultaneously maintaining several existing products. Speed and quality both matter. We cannot sacrifice one for the other. AI tools are not a pilot or an experiment in that environment. They are how we make it workable.

Beyond Lines of Code

Sun, 01 Feb 2026 00:00:00 +0000

There is a gap between “the team has AI tools” and “the team uses AI tools well”. Filling that gap requires data. Most organisations reach for one metric in particular: lines of code written or committed by AI. It is not the right metric.

I previously built a dashboard pulling usage data from the Cursor admin API and the GitHub Copilot API into a single view. I also built a tool to extract AI commit lines broken down by Bitbucket project. It answers the question that usually gets asked. It does not answer the question I actually care about. What both tools showed, and what they could not show, is what shaped how I think about measuring AI adoption now.

Adopting the unFix Model

Mon, 01 Sep 2025 00:00:00 +0000

Like many engineering organisations, the ones I have led have generally started out organised by function rather than outcome: engineering, product, and QA as separate groups, with hand-offs between them to ship a feature. That shape makes ownership hard to place, and it leaves teams without a shared operating model to work from. I wanted to change it, and I wanted the change to be structural rather than cosmetic.

What is the unFix model? Link to heading

The unFix model was created by Jurgen Appelo as a crew-based organisational framework. Its premise is that organisations should maximise team autonomy and minimise hand-offs, within clear strategic direction from leadership.

Deploy Continuously, Release Deliberately

Wed, 20 Aug 2025 00:00:00 +0000

There is a distinction I find myself returning to constantly as an engineering leader: the difference between deploying code and releasing a feature. Treating them as the same thing is one of the most common sources of avoidable risk in software delivery.

Deployment and release are separate concerns Link to heading

Code deployment is a technical operation. Feature release is a business decision. When you conflate the two, you end up in one of two bad places: either you hold back deployments waiting for the business to be ready, which causes integration pain and large risky merges, or you push features live the moment the code lands, removing the business’s ability to control timing and exposure.