This newsletter is brought to you by our friends at Unblocked!
Agents can generate code, but getting it right for your system, team conventions, and past decisions is the hard part. MCPs give agents access to information but not understanding – so you end up wasting time and tokens in correction loops.
For this reason, the teams pulling ahead use a context layer to give agents exactly what they need.
Unblocked is the context layer that turns code, docs, tickets, and conversations into actionable context, so engineers move faster and agents stay on track 👇
There are a lot of *bad* ways to measure how well your team uses AI, including counting lines of code, tokens spent, and more!
To me, we should measure effectiveness, which is a function of leverage: how much useful output you get per unit of human input.
This is different from measuring AI usage. E.g. a team can maximize AI-generated code by writing incredibly detailed specs that are basically pseudo-code. The AI may write the final syntax, but the human still did most of the hard work.
That is not real leverage!
So a better question is: how much context does a human need to provide before the AI can do the job well? Some of the prompt will always be task-specific. If you ask for a new button, the AI needs to know where the button goes and what it should do. But a lot of the prompt should not have to be repeated every time: design rules, product conventions, architecture patterns, testing style, existing components, release constraints.
So you can think at a scale that goes like this:
🏜️ Negative leverage — people spend more time fighting the AI than doing the work themselves.
🌱 Low leverage — the AI writes code, but only after humans write exhaustive instructions.
🪴 High leverage — the AI can reuse enough context from the system that prompts become short and results stay good.
🌳 Maximum leverage — the AI one-shots meaningful work from tiny prompts because the factory already knows how good work should be done.
I wrote more about this in the recent article series about the new software factory 👇
One of the most popular articles we published on Refactoring last year is from Anna Shipman, CTO at Kooth and one of my favorite authors.
She described the translation layer that is needed to make engineering understood by executives, and the article is packed with great examples and mental models.
One of the pieces of advice that stuck with me is to always lead your communication (spoken or written) with an executive summary that includes the most important information: what action you are looking for.
Or, as Anna calls it: bottom line up front.
An exec summary tells the reader in a few short sentences what this document is going to cover. If this is a presentation rather than a document, include an executive summary slide. If this is a conversation, set it up right by explaining first what the purpose of the conversation is. If you are asking for a decision, make sure you’ve included what the decision is.
Here are some example exec summaries.
For a document:
This proposal recommends consolidating our infrastructure onto a single cloud provider to reduce operating costs by 20% over three years, improve reliability, and accelerate feature delivery. The alternative is to retain our split between AWS and Azure. The work will reduce capacity of the platform team by 50% for six months, delaying completion of the work on pipelines until Q4 2026.
We request an additional budget of £50k for the engineering team to have access to an AI coding assistance tool. We have demonstrated in our trial that use of Cursor increases throughput of work by 25% meaning over a year we would deliver extra features equivalent to the salary of four additional engineers, therefore this would pay for itself by end Q1 next year.
In a conversation you might say:
“I want to propose we start upgrading our data handling now rather than in Q3 as planned because our latest planning session raised a flag that we may not hit the deadline. We’d have to pause the work on the new dashboards to do that.”
“There’s a strong business case for investing more in developer experience in next year’s budget. I can show you the ROI calculation we’ve done, but I would like your take before we move forward with the budget preparation.”
By the time you read this newsletter I’ll probably be in London to attend LDX3. This year I will interview the one and only Rands on stage, for a live episode of the Refactoring podcast.
So, while preparing for this, I thought about my interview with Meri Williams last year. Meri is the long-time host of LeadDev conferences, and every year they have to run through hundreds of talk submissions to select only a handful of truly great ones.
I asked them what makes for an amazing talk, and they said it’s three things:
📖 Personal story — or a case study. Anyway, areal experience that grounds the content.
🧠 Framework — the author abstracted their experience into a theory that can be applied broadly.
⚡ Practical application — the story + framework combination has clear takeaways that the audience can implement.
You can find the full interview with Meri here:
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
The bottom line up front idea really stands out here. It’s a simple habit that makes technical communication way clearer, especially when AI and speed are involved
The leverage framing fixes the core measurement error. A team can max AI-generated lines by writing specs that are basically pseudo-code, which means the human still did the hard part and the model just did syntax. The metric that actually matters is how much of each prompt is reusable system context versus task-specific instruction. Once design rules, conventions, and test style live in the context layer, prompt length drops and that fixed cost amortizes across every task instead of getting re-specified each time.
The bottom line up front idea really stands out here. It’s a simple habit that makes technical communication way clearer, especially when AI and speed are involved
The leverage framing fixes the core measurement error. A team can max AI-generated lines by writing specs that are basically pseudo-code, which means the human still did the hard part and the model just did syntax. The metric that actually matters is how much of each prompt is reusable system context versus task-specific instruction. Once design rules, conventions, and test style live in the context layer, prompt length drops and that fixed cost amortizes across every task instead of getting re-specified each time.