Articles

Working through the problems of building software with AI.

Each article deals with one practical difficulty of directing AI through real development work — deciding what to build, keeping changes under control, knowing whether the result can be trusted, and judging how much care the work deserves. They are written to be useful on their own.

Getting your bearings

What has genuinely changed about building software, and how to work in a way you can repeat.

  1. What You Still Need to Understand When AI Writes the Code

    Neither "learn to program first" nor "you need not understand anything" is right. What actually still matters.

  2. A Repeatable Workflow for Building Software With AI

    Tips help with one request. This is what to do next, walked through on a single change end to end.

  3. Building Software Without a Development Background

    Yes, with conditions worth knowing before you start rather than discovering in week three.

Defining the work

Deciding what to build, and how much of it to attempt at once, before any code is written.

  1. How to Plan an App Before You Ask AI to Build It

    AI will build what you describe, not what you meant. Six things worth settling before you open the chat window.

  2. Why the Smallest Useful Increment Beats the Smallest Increment

    Steps so small they do nothing are as unhelpful as steps too large to verify. How to find the size that can be checked.

  3. Let the LLM Interview You: A Technique for Building and Checking Specs

    A technique from Martin Fowler: have an LLM interview you to build a spec, or interview an expert to check one, instead of writing or reviewing it cold.

  4. Describing What Your Software Should Do, in Words AI Can Build From

    A feature name is enough for the work to start and not enough for it to be checked. How to close that gap.

  5. The Decisions to Make Before AI Makes Them for You

    The gaps are invisible because you resolved them years ago without noticing. Five ways to make them visible again.

Keeping control

Stopping changes from spreading further than intended, and keeping decisions from evaporating between sessions.

  1. How AI Projects Drift — and How to Stop It

    A project that worked last week and cannot be trusted this week has usually drifted. The pattern, and how to interrupt it.

  2. An AI Agent Told a Team to Make the Bucket Public. Here's What They Changed.

    A Thoughtworks team hit two security near-misses while prototyping with AI. What they changed: what the agent is told before it writes anything, what a project starts from, and what they watch daily.

  3. Why AI Software Projects Make Fast Progress — Then Stall

    The first two days produce something that works. The second two weeks produce arguments with the software.

  4. When AI Changes Code You Didn't Ask It to Touch

    You asked for one small change and the diff shows four files. Why it happens and how to contain it.

  5. Keeping Context Between AI Coding Sessions

    Chat history is a poor place to keep decisions. What to write down instead, and what not to bother with.

  6. Always Have Something That Works to Go Back To

    Version control gives you a history. It does not tell you which point in that history worked.

Checking the result

Establishing whether what you got is what you asked for, and correcting it when it is not.

  1. How to Test Code You Didn't Write

    Reading the code tells you what it does, not whether that was the point. What to check instead, worked through.

  2. "Production Ready" Is Not Evidence

    A model calling code complete is reporting intent, not test results. The difference between a claim and evidence.

  3. Fixing AI-Generated Code Without Making It Worse

    One thing is wrong and everything else works. How to keep it that way while you fix it.

  4. When a Fix Breaks Something That Was Working

    The change you asked for works. Something you did not ask about has quietly stopped working.

  5. When You Should Get a Professional to Look at AI-Generated Software

    Not a question of project size. What decides it is what happens when the software is wrong, and who pays.

Choosing how to work

Deciding how much structure a piece of work warrants, how much to let run unattended, and how much the choice of tool actually decides.

  1. Vibe Coding and What It Costs You Later

    It defers cost rather than removing it — which makes it correct wherever the cost never arrives.

  2. AI Is Exposing the Limits of PR-Based Code Review - What Should Move Earlier?

    AI-generated code is straining end-stage PR review. Move feedback earlier with pairing, automated checks and human review for higher-risk changes.

  3. Does Telling Your Coding Agent to Use TDD Actually Improve the Result?

    An exploratory study compared TDD and non-TDD agent runs on identical tasks - and found no clear quality advantage for TDD. Here's what that means for your workflow.

  4. The AI Gave You a Confident Answer About Your Legacy Code. Was It Guessing?

    A case study in modernising a 20-year-old codebase with AI: why the first answers were plausible but wrong, and the evidence-first workflow that fixed it.

  5. When Is a Local LLM a Realistic Option for Coding Work?

    A practitioner's hands-on evaluation shows where local models handle agentic coding tasks and where they still fail, and on what hardware.

  6. Use a DSL as a Harness: Constraining What an LLM Can Generate

    A domain-specific language can act as a structural constraint on AI-generated code, not just a written specification - here's how the technique works and when it's worth the effort.

  7. Large Files Cost More Tokens Every Time an Agent Touches Them — One Experiment Measured How Much

    A Thoughtworks engineer measured token costs before and after refactoring a 17,000-line file, giving a concrete way to argue for decomposition.

  8. Subagents Aren't for Speed — They're for Protecting the Orchestrator's Context

    Why subagents in multi-agent AI coding workflows matter more for what they keep out of the orchestrator's context than for how much time they save.

  9. Agents Still Need Someone to Decide What "Done" Means

    An agent reporting success is telling you the work matched its own understanding of the task.

  10. The Tool Matters Less Than How You Direct It

    Not that tools are interchangeable. That one half improves on its own and the other only improves if you work at it.

Several of these have a reusable counterpart — a template, a checklist or a record — in resources.