Pete Hodgson

“Have you tried out Ralph Wiggum loop?!”

“Why would Claude Code work differently than my IDE’s coding agent, if they’re both using the same models under the hood?”

This is the full list of tools available to Claude Code as of Dec 9 2025, captured using the technique described in Same Model, Different Results: Why Coding Agents Aren’t Interchangeable.

This is the full Claude Code system prompt as of Dec 9 2025, captured using the technique described in Same Model, Different Results: Why Coding Agents Aren’t Interchangeable.

Managing your coding agent’s context is super important.

“Listen, I’m wondering if our engineers are doing enough with AI…” your CEO says, as the two of you sit down for your 1:1.

The new wave of asynchronous AI coding platforms makes it entirely possible for your CEO to make a feature request via a Slack message and have a fully autonomous coding agent such as Devin or Codex pick up the task and start implementing it.

Current discourse on AI-assisted coding is very polarized.

As an engineering leader at a startup, you find yourself wearing a lot of hats.

Despite the breathless hype from some corners of the internet, vibe-coding - fully autonomous AI coding - isn’t going to replace engineers in the near future.

After a few hours of experimenting with Claude Code, I’m starting to take Agentic Coding/Vibe Coding seriously.

Basically every product out there has added ✨AI-powered✨ features in the last year or so.

Adding a new feature to a software system sometimes requires making a breaking change in a database schema or API schema.

We’re going to add feature flagging to a node service in under five minutes using OpenFeature, the open, vendor-agnostic feature flagging SDK.

I’ve recently been involved1 in OpenFeature, an effort to define a standard API and SDK for feature flagging.

An Explaining Variable is a code-level pattern which reduces the need for code comments, making your software a little more self-documenting.

Almost every company feels pain when it comes to organizing work that spans multiple teams.

I once knew a team who built a beautiful platform that almost no-one used.

Every engineering leader at a growing startup encounters the same challenge at some point: how to ensure your teams are making decisions in a roughly coherent way.

Every codebase carries some amount of technical debt.

When looking at the work ahead of them, product delivery teams need to see both the big picture - the vision of where we want to take the product - as well as all the details - the detailed requirements for each feature.

As engineering organizations move towards smaller services and more autonomous teams, it’s common to run into situations where teams are duplicating effort on “table stakes” platform functionality.

“Sorry, that just sounds… dangerous”.

I wrote recently about how a Strategic Architectural Initiative (SAI) helps align autonomous teams around a technical strategy.

Software companies always have an unended stream of product features for engineers to work on.

Deploying something useless into production, as soon as you can, is the right way to start a new project.

This post is part of a series, covering techniques for testing redux reducers.

This post is part of a series, covering techniques for testing redux reducers.

This post is part one of a series, covering techniques for testing redux reducers.

Here’s a crazy idea: software companies should require new engineers to make a production code change on their first day at work.

I once thought that code review was all about catching bugs, but I was wrong.

Building software is an inherently creative endeavor.

Engineering decisions made at the very early stages of a product’s life can have repercussions which extend far into the future.

In this article I’ll show that the typical approach for deploying sophisticated static sites is not sufficient, and explain how we can apply the principles of Continuous Delivery to improve the situation.

Engineering decisions made at the very early stages of a product’s life can have repercussions which extend far into the future.

The founding engineer at a new startup carries a heavy weight upon their shoulders.

The testing ecosystem in JavaScript today is full of tools which keep re-inventing the same wheel - Matchers.

I’ve had articles published on various other websites besides my blog here.

In this post I’ll show three different techniques for encapsulating internal state in JavaScript, concluding with my preferred approach, a pattern I’m calling “Symbol-keyed State Accessor”.

I brew beer as a hobby, and one of the secrets to really good homebrew is happy, healthy, plentiful yeast at the start of fermentation.

I travel a fair bit for work and have discovered that when you’re living in a hotel it’s the simple comforts that you miss the most.

I had the opportunity to present at Forward JS a few weeks ago on “different.js”.

I was doing some research today on preventing slow/flakey external javascript files from 3rd-party sources from slowing down your perceived page load times.

I got to present a talk at RailsConf this year. video is here, slides are here.

.

I’m a bit fan of static sites, and have created a fair few little static one-page demos and toy apps over the last few years.

Martin Fowler recently added a bliki entry for the Page Object pattern.

I’m pleased to announce rack-flags, a very simple way to add feature flags/bits/toggles to your Rails app (or any other rack-based web app).

##TL;DR I’ll be running a couple of free workshops on iOS Unit Testing in San Francisco in late August/early September.

Travis CI is a cloud-based Continuous Integration service which is free to use (but only on public github projects).