The CAPEX trap

Government budget structures systematically favour outsourcing. A one-off consultancy contract is typically categorised as CAPEX (capital expenditure); permanent salaries are mostly OPEX (operational expenditure). On annual budget cycles, the CAPEX option consistently appears cheaper - even when it is dramatically more expensive over three to five years and builds no lasting capability. The NAO has identified this as a structural problem. The same structural logic - outsourcing as project spend, salaries as a permanent liability - has produced equivalent distortions in Australia, Canada, and across the EU, where governments have quietly built 'shadow workforces' of contractors that dwarf the civil service headcount they were designed to circumvent. HM Treasury had a target to reduce consultancy spend by £550 million in 2024–25.

The Cost Evidence for In-House Capability

The most common objection to building in-house AI capability is cost. The evidence consistently points the other way: in-house capability is substantially cheaper than the contractor alternative - and unlike contractor arrangements, it compounds rather than resetting to zero at contract end.

What in-house actually costs

i.AI draws on the government's published DDAT (Digital, Data, and Technology) pay framework, with London weighting. A senior AI engineer or data scientist in permanent government employment costs a fraction of what an equivalent contractor through a prime supplier charges per day - and that permanent employee compounds domain knowledge year on year. A contractor resets the knowledge clock when the engagement ends.

What the contractor alternative costs

Indicative rates for a senior developer through a government prime supplier are £800–£1,200 per day. A Big Four consultant on an AI project: £900–£1,400 per day. At 230 working days per year, that quickly adds up. And this does not include the management overhead of procurement, the knowledge loss at contract end, or the premium on repeat engagements when the expertise walks out the door.

Published evidence supports the structural case. POGO (US, 2011) found contractors cost federal agencies on average 1.83× equivalent permanent staff - and in over a third of roles studied, more than double. The UK NAO's November 2025 report (HC 1381) documented £1.36 billion in central government consultancy spend in 2022–23, with the MCA reporting £5.3 billion across the wider public sector in 2023. The NAO found the government 'does not have consistent data on how much individual departments spend on consultants' - suggesting these figures understate the real cost.

Alexander De Ville et al.

On a technical level, probably the most important thing is having your external boundaries correct. So if you have some old legacy code and it's kind of difficult to go in and refactor and rename it internally, that can be okay. But in your API or your events you publish to other domains, that's somewhere where you can do the mapping and you can kind of, so the interfaces between your different contexts can be the new model and you can try to keep the old model hidden inside. And then at least that way you can refactor it over time and it doesn't spread.

Nick Tune

I'd just shipped the first release of a side project. Feeling productive, I immediately started setting up changesets, release automation, and versioning infrastructure. Then I paused. This project had one contributor (me), zero users, and exactly one release. Why was I adding release tooling designed for teams managing dozens of packages?

This happens a lot when you work alone. There's no one to say "do we actually need this?" So I built a Claude Code skill to be that voice.

The Problem

Solo developers don't have the natural friction that teams provide. On a team, proposing a new tool or architectural pattern means writing a proposal, getting feedback, defending the complexity. Working alone, you skip straight from "I heard about X" to npm install X. The gap between impulse and implementation is dangerously short.

I wanted something that would slow me down just enough to think clearly - without the overhead of a full team RFC process.

How I Built It

Claude Code skills are modular packages that extend Claude's capabilities with specialised knowledge and workflows. A skill is essentially a SKILL.md file (with YAML frontmatter and markdown instructions) plus optional reference files.

I used the Anthropics skill-creator to guide Claude Code to create an effective skill, giving it context of an RFC process I'd written up before and a prompt describing the skill I wanted to create. This created two files:

SKILL.md - The main skill definition with a 4-stage workflow:

1. Problem Framing - Forces you to articulate the actual problem before discussing solutions. Asks pointed questions: "What happens if you do nothing for 3-6 months?"
2. Research & Options - Explores your actual codebase first, then builds an honest comparison. Always includes "do nothing" as Option A.
3. Decision - Applies a complexity filter: "Is this the simplest thing that could work at your current scale?"
4. Document - Writes a lightweight RFC to docs/decisions/ as a persistent record.

references/rfc-template.md - A stripped-down decision document template with sections for: Summary, Problem, Options Considered, Decision, Rationale, and Next Steps.

The skill triggers automatically when you say things like "should I add X?", "is this overkill?", or "do I need Y?" - exactly the moments where premature complexity creeps in.

The key design decisions were:

• "Do nothing" is always an option. This is the core mechanism. Describing what "do nothing" actually looks like in practice reveals it's rarely as bad as you assumed.
• Codebase-aware. Stage 2 explores your actual project before researching solutions, grounding the discussion in reality rather than hypotheticals.
• Produces a decision record. Even if the decision is "do nothing," documenting why is valuable when you revisit the question six months later.

Local install

To install it for my user across all Claude Code sessions, I copied the skill directory to ~/.claude/skills/solo-rfc/.

Publishing to Tessl

If you want to share a skill beyond your own machine, you can publish it to the Tessl registry:

# creates the tile.json manifest file
tessl skill import ./solo-rfc --workspace nickrowlandocom

tessl skill publish --workspace nickrowlandocom ./skills/solo-rfc

The import tool will ask "Should the tile be public?". Selecting yes will set the private flag to false in the tile.json manifest file. This flag will make it discoverable by anyone, or keep it private to your workspace.

Publishing gives you:

• Discoverability - Others can find and install your skill from the registry with tessl skill install
• Versioning - Proper semantic versioning so consumers can pin to stable releases
• Distribution - Team members in your workspace get access automatically; public skills are available to the entire community
• Validation - Published skills are automatically linted and evaluated

For a skill like this, publishing publicly means any solo developer using Claude Code can benefit from the same "slow down and think" workflow - without building it themselves. I've published the solo-rfc skill — you can find it on the Tessl registry.

My COROS Pace 3 is brilliant for following workouts at the gym, but the manual data entry in the Training Hub or COROS App is tedious. So Claude and I built an MCP server so Claude could talk to COROS's APIs. Now I just chat with Claude about what I need – my fitness level, goals, any weak points – and Claude designs a tailored strength programme. Once I'm happy with it, Claude pushes the workout straight to COROS using their full exercise catalogue (~383 exercises). It syncs to my watch automatically, no copying and pasting required.

I decided to reverse engineer the API because I noticed people didn't have much luck trying to speak with COROS directly, waiting months to hear nothing back. It felt like a problem worth solving, and it gave me an excuse to explore Claude Code agent teams, develop my intuition on how to work effectively with Claude Code, and learn more about MCPs. The first version does exactly what I set out to build.

Building it was straightforward enough. I used the just-released Claude 4.6 Opus and found the pace at which I was working fitted comfortably into the Pro plan usage limits. The code is available at https://github.com/rowlando/coros-workout-mcp/.

But like all projects, the scope is growing—in the best way. It's already opened up possibilities I hadn't anticipated. For example, progressive overload isn't factored into COROS workouts. You'd have to manually review your training data and edit each strength workout, or rely on memory (which I often do poorly). So I'm exploring how Claude could analyse my training data periodically and adapt the workouts accordingly, improving something the COROS UX doesn't currently handle well.

For the technically curious - If you're interested in how we actually built this - the reverse engineering process, the MCP architecture decisions, the tricky bits like payload construction and the calculate-then-add API flow - I've written a detailed technical breakdown: How We Built v1 of coros-workout-mcp. It covers the full journey from Chrome DevTools network captures to Claude Code implementation to Claude Desktop integration, all the way through to open-sourcing. It's a pretty good case study in human-AI pairing, if you're exploring that kind of collaboration yourself.

Yes, it does feel a bit weird saying "we".

Anthropic’s Agent SDK is essentially the Claude Code agent as a library for Typescript or Python. It makes it trivial to build agents for other purposes than coding using the same agent harness. You define the tools and skills and the right sandboxed environment and you can now prompt an agent to work towards a goal.

Mathias Biilmann

I've been reacquainted with Ruby lately. I had it lying around on my machine but couldn't quite remember how I managed versions and switched between them. It turned out I was using Homebrew, ruby-install, and chruby. I updated the packages to their latest versions, then installed the latest version of Ruby:

brew upgrade ruby-install chruby
ruby-install 3.4

This installed Ruby 3.4.6.

If configured, chruby will automatically switch to the current version of Ruby when you cd into a directory. It looks for a .ruby-version file.

A newer alternative

I recently came across Mise, a "polyglot tool version manager". It aims to replace many version managers like nvm, ruby-install, and so on. I installed Mise (after editing my .zshrc file) and ran mise use -g ruby@3.4. It worked fine. Mise also manages environment variables and includes a task runner. I also installed Node.

Mise looks promising. For me, the main benefit is improved shell start-up time. My machine is a 2015 MacBook, so it's a bit slow when loading multiple version managers. It took about 1 or 2 seconds to start a shell with nvm and chruby in the mix; with Mise the shell starts immediately.

I'll give it a go for a while.

Update

After trying to install ruby gems, I was getting mixed success.

The Problem: I was running Ruby 3.4.7 (via mise), but gem env showed gems were being installed to my old Ruby 3.2.0 directory. The gems existed, but their compiled C extensions were built for 3.2.0 and couldn't work with 3.4.7.

The Cause: Old GEM_HOME or GEM_PATH environment variables in my shell config, pointing to the 3.2.0 installation and overriding mise's proper paths.

The Fix:

unset GEM_HOME
unset GEM_PATH

# Reload shell
source ~/.zshrc

# Reinstall gems

The past has shown that the best way for us to stay in control of what we’re building are small, iterative steps, so I’m very skeptical that lots of up-front spec design is a good idea, especially when it’s overly verbose. An effective SDD tool would have to cater to an iterative approach, but small work packages almost seem counter to the idea of SDD.

Birgitta Böckeler

I'm pairing with Claude Code to build a progressive web app, but Service Workers weren't working. The feedback loop between testing in the browser and reporting what I was seeing in Chrome DevTools was painfully slow.

I wondered: is there a DevTools MCP?

There is! On 23 September 2025, the Chrome team blogged about Chrome DevTools (MCP) for your AI agent.

I added it to Claude Code with a single command:

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

After starting Claude Code, I tested it:

Please check the LCP of web.dev.

It worked!

Now for the real problem. I put Claude Code to work:

Research why my PWA service worker isn't registering in Chrome DevTools. Check the manifest, service worker file, and registration code. Create a plan to fix it, then implement.

After 5 to 10 minutes of debugging attempts, Claude Code concluded that we needed to migrate away from next-pwa to a modern successor called Serwist.

That's when it hit me: I hadn't noticed that Claude Code had selected next-pwa, a library whose last release was in December 2022. When working with teams of human software developers, one of my responsibilities is guiding them to choose dependencies carefully. "Popularity and adoption" is always a key factor.

It turns out Claude Code needs the same guidance.

I recently discovered there are two different ways to connect Claude and GitHub, and honestly, the naming made them sound like they did the same thing. They don't. At all.

Let me explain what I learnt—and why one of them is perfect for my situation whilst the other would cost me quite a bit extra.

What's the Difference?

GitHub MCP Server lets my AI tools (Claude Desktop, VS Code, etc.) access GitHub. I ask Claude something, it queries GitHub through the MCP server, and gives me an answer. The flow is: me → Claude → GitHub.

Claude Code GitHub Actions works the opposite way. I mention @claude in a GitHub issue or PR, and GitHub spins up a cloud runner, executes Claude Code there, and pushes results back to my repo. The flow is: me → GitHub → Claude (running in the cloud).

The Cost Situation

Here's where it gets interesting for me as a Claude Pro subscriber.

When I use Claude Code on my laptop, it's included in my £18/month Pro subscription. Brilliant.

But Claude Code GitHub Actions requires:

1. An Anthropic API key (pay-as-you-go, separate from Pro)
2. GitHub Actions runner time

So even though I'm already paying for Claude Pro, I'd be adding two new line items to my monthly costs. That's not what I'm after as a solo developer keeping expenses tight.

Why GitHub MCP Server Works for Me

The GitHub MCP Server costs me nothing extra. It's free, open source, and works with my existing Claude Pro subscription.

Once set up, Claude Code can interact with GitHub directly from my laptop. I can ask it to check PR status, list open issues, review workflow runs, or analyse commits—all within the subscription I'm already paying for.

As a solo developer experimenting with AI-assisted development, this is exactly what I need. I'm working interactively with Claude anyway, so having it access GitHub whilst I'm present is perfect. I don't need autonomous agents running in the background whilst I'm asleep.

What I'm Missing (And Why That's Fine)

The GitHub Actions approach offers some genuinely powerful features:

• Background automation (Claude works on tasks without me present)
• Parallel agents (multiple Claude instances on different issues simultaneously)
• Autonomous responses (automatic reactions to @claude mentions)

These are impressive capabilities, but they solve problems I don't have yet. I'm experimenting, learning, and building. I don't need multiple AI agents working in parallel—I need one good assistant that can access my GitHub repositories when I ask it to.

When I Might Reconsider

If my situation changes, GitHub Actions could become worthwhile. Specifically:

• If I start managing multiple repositories that need regular automated maintenance
• If I build a team and want AI to handle initial PR reviews automatically
• If background processing becomes more valuable than the API + runner costs
• If I hit my Claude Pro usage limits regularly and need to scale up anyway

But right now? The MCP server gives me 90% of the value at 0% of the additional cost.

The Takeaway

For solo developers with Claude Pro who want to experiment with GitHub integration, the GitHub MCP Server is the obvious choice. It's cost-effective, powerful enough for interactive development work, and doesn't require managing API credits or monitoring runner costs.

Claude Code GitHub Actions is brilliant for what it does, but it solves a different problem—one that comes with a price tag that doesn't make sense for my current situation.

Sometimes the best tool is the one that does exactly what you need without costing you extra. For me, that's the GitHub MCP Server.

P.S. Here's a sequence diagram that makes this super clear.

Blogmark: Organisational design and Team Topologies after AI (via)

I'm a massive fan of the book Team Topologies and looking forward to the 2nd edition. I listened to the authors talk on this podcast. Here's some bits that stood out to me:

Technology As Empowerment: Evaluate AI by whether it enables teams to achieve goals, not by novelty or adoption metrics.

Don't optimise locally without understanding the bigger picture: Assess downstream capacity and maintainability before accelerating code generation. Remember that teams are related to each other in a system or organisation.

Generative AI Powers Product Development: Generative AI can generate many options (text, images, product ideas, versions of a service) to test against synthetic users to quickly arrive at an A/B test.

Team Topologies As Infrastructure For Agency: Team Topologies, when originally written, was about trying to provide agency, empowerment, autonomy to teams of humans within an organisation. The principles and patterns behind Team Topologies apply to agents too... respect cognitive limits (context), make changes small and safe, aligned to a business domain. Perhaps even the three team interaction modes could be a way of thinking about agent-to-agent interaction via MCP?

Prepare Foundations Before Scaling AI: The capabilities that predict high performing software delivery - https://dora.dev/capabilities/ - plus work organised around business domains (think DDD). Decoupled, well-defined boundaries, with solid engineering practices in place, will position organisations to take advantage of AI agents and work in parallel. Without these foundations, which is already true for human-only teams, delivery of value will tend to be poorer.

Train Teams To Be Risks Assessors: People should know when to worry about risks that AI presents. Building prototypes the risk is lower, whereas building for production comes with much higher risk, so everyone should be asking what could go wrong, whether that's in the code an agent has built or an AI tool that is deployed. Teams should already be employing techniques like threat modelling anyway so continue to employ this type of practice.