A few weeks ago I read Simon Willison’s write-up on StrongDM’s “Software Factory” approach. The line that stuck with me wasn’t even about agents or tooling — it was the mantra: • Code must not be written by humans • Code must not be reviewed by humans I found it fascinating… and honestly a bit uncomfortable. Not because it’s wrong, but...

This is what I’m aiming for with AI-assisted dev: every job produces a small PR + CI green + a prompt spec + a run log (commands/tests) so you can audit what happened. Diff is output. Evidence attached.

Every PR now includes: the prompt spec (goal + acceptance criteria) the run log (what the agent did + command/test outputs) the checks as the gate (CI green or it isn’t done) It turns AI work from vibes into something you can audit, replay, and trust: instructions in → software out → evidence attached. Screenshot is a real example: pro...

I was worried AI would take the fun out of engineering. My early experiences felt a bit like “autocomplete on steroids” — faster, but less satisfying. It’s gone the other way. I feel energised. The work is more playful now: I give it context, tighten constraints, adjust guardrails, and see what it comes back with — then steer, test, an...

When AI generates code, it can look convincing even when it’s wrong. So I don’t assess the implementation first. I run the specs first. In traditional development, you wouldn’t submit (or even entertain) a change that fails CI. Why would you treat AI-generated code differently? If tests are failing, I ask the model to fix them until ev...

There’s a lot of fear right now. People can feel the ground moving under how we work, how we buy things, and how businesses acquire customers. The questions are reasonable: • What does this mean for my job? • What does this mean for my business? • Are websites and apps about to become irrelevant? This is my attempt to add some reality:...

One of the easiest ways to waste time with AI is to do everything in a single long thread. It starts well, then the context grows, quality drifts, and you end up with a messy mix of strategy, partial implementations, and conflicting decisions. You get “context rot”, but you also get something worse: you lose your own clarity. The appro...

Engineering interviews have always been a proxy. We can’t fully simulate real work in an hour, so we use exercises and questions to approximate signal: • how someone thinks • how they trade off speed vs quality • how they handle uncertainty • whether they validate and de-risk • whether they communicate clearly The final code someone pr...

PR review was never really about the code. Yes, we look at the diff. But the real thing we’re trying to assess is judgment: • did the engineer understand the problem? • did they make sensible trade-offs? • did they spot the risks? • did they validate behaviour? • did they leave the codebase better than they found it? The uncomfortable ...

When teams start writing agent instructions, there’s a very common instinct: Make the instructions “safe” by turning them into a big set of deterministic rules. It usually starts with something small, often around wording. For example: • if a delivery date is in the past, say “was due” • if a delivery date is in the future, say “expect...

If writing agent instructions is programming, it follows that the best instructions aren’t written by one person in isolation. They’re a team sport. When I say “business” here, I often mean a PM — that’s how we do it. But it could just as easily be a founder, ops, customer support, or anyone close to the user and the outcomes. The key ...

When people talk about “prompting”, it can sound like the skill is writing clever English. But when you’re giving instructions to an agent that’s meant to do real work reliably, it feels much closer to programming than copywriting. You’re not just asking for an answer. You’re specifying behaviour. That changes what “good” looks like. G...

Most teams like the idea of “appetites over estimates” until you try to run an actual planning cycle. Let’s say you’re planning a 4-week cycle: 3 weeks of development and 1 week cooldown. You’ve got a set of pitches on the table. The business sees the list and asks the most natural question in the world: “How long will each pitch take?...

The biggest difference is it pushes back. It flags risks, calls out contradictions, and suggests sensible alternatives, instead of the default "you’re absolutely right" even when I’m clearly changing my mind mid thread. It’s starting to feel like an actual engineering partner.

When an AI thread gets long, quality drops. It gets slower, forgets earlier decisions, and starts confidently guessing. My reset prompt is: “Hey ChatGPT, I think you’re suffering from context rot. Can you summarise the key context from this thread so we can move to a fresh chat and keep the momentum going?” Then I paste that summary in...

Most software work starts the same way: • get a happy-path flow working • surface rabbit holes early • produce a first draft Then we all say the same thing: “We’ll refactor it later.” Sometimes that happens. A lot of the time business pressure wins, and the first draft becomes production. That’s not laziness. It’s reality. The part tha...

Estimation in software has always been broken. Not because people are bad at it, but because we keep asking it to do something it can’t: predict outcomes in complex, uncertain systems. AI hasn’t changed that. What it has changed is speed — and that makes estimation more dangerous, not less. Speed increases confidence faster than unders...

Lately, working with AI has reminded me a lot of how Test-Driven Development felt when I first learned it. Not the dogma. Not the purity debates. But the feedback loop. What TDD was really doing (for me) When I interview engineers and ask about TDD, I often hear the same answer: ““It helps catch bugs.”” That’s true but it was never the...

Every startup carries tech debt. Not because teams don’t care — but because speed, uncertainty, and evolving requirements make it inevitable. Most of it never gets “paid down”, and full rewrites are usually too risky to attempt. AI doesn’t remove that reality. But it does change how we can move forward without being trapped by it. This...

AI has dramatically lowered the cost of building software. With agentic development, copilots, and increasingly capable models, it’s never been easier to go from idea to working implementation. You can explore solution space faster, test assumptions sooner, and ship proofs of concept in days rather than weeks. That’s a genuine shift — ...

Agentic development has improved massively in the last six months. In the summer of 2025, I tried using Copilot to build a moderately complex feature. At the time, I was genuinely amazed by what it could do — but in practice it got more wrong than right. I spent too much time correcting and reworking the output, and overall the experim...

When scoping/planning development work for the engineering team the first question from the developer is always: When does this have to be done? How long have we got? Generally these deadlines are never met and it's always accepted that a software development project will go beyond the given allocation, it's rarely launched before/on t...

Regardless of the engineering teams competency bugs are part and parcel of the life cycle of every software development project. Within the software development paradigm there are best practices for nearly every part of the development life cycle except bug management. I have participated and witnessed several different approaches over...