Effective writing from a practitioner is a style distinct from academic writing or thought-leadership content. It relies on authority from experience (not credentials), naming tensions but letting them live, keeping the author in the writing, and the expectation that readers recognize the pattern from their own experience.

Subagents get justified by time saved and parallel execution, but that's not what matters most in long-running multi-agent work. Every token in the orchestrator's context is competing for its attention, and the real value of a subagent is what it keeps out of that context, not how fast it runs. I argue that subagents should be treated as a tool for protecting the orchestrator's working memory, offloading reasoning it doesn't need to hold onto. Doing this well means giving the orchestrator explicit ground rules for when and how to delegate. This is exploratory work, built from one real incident, and it ends with more open questions than settled answers.

This article explains the approach I used to modernize a Java 1.5 codebase that no longer built reliably on modern machines. My early use of LLMs gave me plausible answers that did not hold up in the codebase. Progress came when I grounded the process in evidence, using AI to support analysis, validation in a stable Docker environment, and gradual refactoring protected by tests. The main takeaway is practical: AI was most useful when constrained by evidence, clear roles, and a step-by-step modernization strategy.

LLMs generate code incredibly fast, but to ensure they generate exactly what is intended, they need clear boundaries. Abstractions and Domain-Specific Languages (DSLs) provide a strong harness that guides LLMs right from the start. The example of Tickloom - a domain model and DSL for illustrating distributed system behavior - shows how we can use an LLM as a partner to iteratively build a DSL and as a natural language interface to use it. Such a DSL can act as the key source of truth for software systems in the world of LLMs.

Mechanical Sympathy was term coined by Sir Jackie Stewart, a three-time Formula 1 World Champion, to describe the understanding a driver needed to have for a car's capabilities in order to drive it well. That term was then imported into software development by Martin Thompson. Thompson's view was that developers need a rough understanding of the hardware in order to create efficient software.

Thoughtworks hosted a pair of Open Space workshops called “The Future of Software Development”. They bring together various Thoughtworkers and friends of Thoughtworks to exchange observations and analysis for a day and a half on how the rise of AI and LLMs would affect our profession.

This paper presents the Preclinical Information Center (PRINCE), a cloud-hosted platform developed by Bayer AG with Thoughtworks to address pharmaceutical industry challenges in drug development. PRINCE leverages Agentic Retrieval-Augmented Generation and Text-to-SQL to integrate decades of safety study reports. We describe PRINCE's evolution from keyword-based search to an intelligent research assistant capable of answering complex questions and drafting regulatory documents. We reflect on key engineering decisions through the lens of context engineering—how information was shaped and routed between specialized agents—and harness engineering—how orchestration, recovery, and observability were built around the models to maintain control and reliability. The system prioritizes trust through transparency, explainability, and human-in-the-loop integration. PRINCE demonstrates AI's transformative potential in pharmaceuticals, significantly improving data accessibility and research efficiency while ensuring governance and compliance.

“Vibe coding” - the practice of non-technical citizen builders using generative AI tools to rapidly develop applications, this has significantly accelerated software prototyping. However, because AI agents naturally prioritise the path of least resistance, they frequently recommend insecure configurations, creating systemic security exposure across industries. To combat this we need to write a security context file to guide the AI, be cautious with AI permission requests, create a daily security intelligence feed, and provide builders with a secure-by-default harness and templates.

In a recent article about harness engineering for coding agent users, I laid out a mental model for expanding a coding agent harness: a system of guides and sensors that increase the probability of good agent outputs and enable self-correction before issues reach human eyes. This article is a more practical follow-up where I walk through my experience with using sensors that help keep the codebase maintainable.

Vibe coding is building a software application by prompting an LLM, telling it what to build, trying it out, prompting for changes - but without looking at any of the code that the LLM generates. This technique can be used by people without any knowledge of programming. However the resulting software often shows problems with maintainability, correctness, and security - so is best used for disposable software written for a limited audience.

Increasingly software developers are not typing code into their IDEs. Instead they prompt an LLM to do so, then review the results. This is a profound change to the nature of programming, where humans oversee LLM agents who generate the code. Humans are still responsible for what the software does and how it works, but use different skills to create their products.

At the GOTO Conference in Copenhagen in 2025, Kent Beck and I spent some time on stage talking and answering questions from the audience - a format I refer to as “two old geezers on a park bench”. We talk about our experiences with LLM-augmented programming (at that point - October 2025), we show our frustration on what we've been saying for thirty years that still needs to be said, we say how anything like a manifesto reunion needs to be led by a younger generation, and answer a question from a junior developer about what they should be focusing on in their career.

When we need an LLM to perform a complex task, we often need to feed it a lot of context. Coming up with a design for a new feature requires descriptions of how we want the feature to appear to the user, guidelines on how it should be implemented, information on external systems to consult, and so on. All this can be several pages of markdown. The obvious way to do this is for a human to write this context, but an alternative is to use an LLM to write this context after interviewing a human.

Code has two distinct but intertwined purposes. It is a set of instructions for a machine, and it is also a conceptual model of the problem domain. A well designed codebase is a representation of the vocabulary of a domain. These abstractions reveal themselves only as developers build the software. Programming languages act as thinking tools, enabling the construction of a conceptual model that supports later evolution. With LLMs, code acts as essential context: good abstractions, executable behavior, tests, types, and invariants all help constrain the model and make its output more useful.

In the early 1960s, Fred Brooks managed the development of IBM's System/360 computer systems. After it was done he penned his thoughts in the book The Mythical Man-Month which became one of the most influential books on software development after its publication in 1975. Reading it in 2026, we'll find some of it outdated, but it also retains many lessons that are still relevant today.

November 2025 marked an important point in the development of AI-assisted programming. In that month Anthropic released Opus 4.5 and OpenAI released GPT-5.2. The former in particular, coupled with the Claude Code harness, represented a key moment for using AI.

LLM programming assistants have demonstrated considerable value, but mostly with individual developers. The internal IT organization in Thoughtworks has been using them for their teams and have developed a method and workflow called Structured Prompt-Driven Development (SPDD). The article describes a simple example of this workflow with details in github. This workflow treats the prompts as a first-class artifact, kept with the code in version control, and used to align development with business needs. We have found that developers need three key skills to be effective: alignment, abstraction-first, and iterative review.

The practices that make human pair programming effective—onboarding, structured design discussion, shared standards—apply equally to working with AI coding assistants. I propose five patterns that bring this collaborative scaffolding to AI-assisted development, shifting the experience from correcting a tool to collaborating with a capable teammate.

I attended the first Pragmatic Summit early this year, and while there host Gergely Orosz interviewed Kent Beck and myself on stage. It's always good to get in a conversation like this with Kent, as I commented during the the session my career is “mostly about writing down Kent Beck’s ideas”. Given the timing, AI dominated the conversation - we compared it to earlier technology shifts, the experience of agile methods, the role of TDD, the danger of unhealthy performance metrics, and how to thrive in an AI-native industry. Gergely summarized the conversation in his newsletter.

Modern hardware is remarkably fast, but software often fails to leverage it. Mechanical sympathy - a concept borrowed from racing and popularized in software by Martin Thompson - is the practice of creating software that is sympathetic to its underlying hardware. This practice can be distilled into a set of everyday principles: Predictable memory access, awareness of cache lines, the single-writer principle, and natural batching. Together, these principles can be used to optimize everything from an AI inference server to a distributed data platform.

To let coding agents work with less supervision, we need ways to increase our confidence in their result. As software engineers, we have a natural trust barrier with AI-generated code - LLMs are non-deterministic, they don't know our context, and they don't really understand the code, they think in tokens. This article explores a mental model that brings together emerging concepts from context and harness engineering to build that trust.

An Architecture Decision Record (ADR) is a short document that captures and explains a single decision relevant to a product or ecosystem. Documents should be short, just a couple of pages, and contain the decision, the context for making it, and significant ramifications. They should not be modified if the decision is changed, but linked to a superseding decision.

This article reflects on an ideological discomfort with software patents, a direct experience of patent aggression in the software industry, and the practical constraints faced by startups. It argues that while the patent system remains deeply flawed, defensive patenting can function as a shield in an asymmetric legal environment, especially for open-source innovators.

If you've hung around agile circles for long, you've probably heard about the concept of servant leadership, that managers should think of themselves as supporting the team, removing blocks, protecting them from the vagaries of corporate life. That's never sounded quite right to me, and a recent conversation with Kent Beck nailed why - it's gaslighting. The manager claims to be a servant, but everyone knows who really has the power.

I've heard a number of reports recently about people setting up LLM agents to work on their email and other communications. The LLM has access to the user's email account, reads all the emails, decides which emails to ignore, drafts some emails for the user to approve, and replies to some emails autonomously. It can also hook into a calendar, confirming, arranging, or denying meetings.

I'm increasingly seeing a lot of technical and business writing make heavy use of bold font weights, in an attempt to emphasize what the writers think is important. LLMs seem to have picked up and spread this practice widely. But most of this is self-defeating, the more a writer uses typographical emphasis, the less power it has, quickly reaching the point where it loses all its benefits.

A conversation between Unmesh, Rebecca, and Martin on how LLMs help us shape the abstractions in our software. We view our challenge as building systems that survive change, requiring us to manage our cognitive load. We can do this by mapping the “what” of we want our software to do into the “how” of programming languages. This “what” and “how” are built up in a feedback loop. TDD helps us operationalize that loop, and LLMs allow us to explore that loop in an informal and more fluid manner.

Many teams have turned into tribes wedded to exclusively adaptation or optimization. But this misses the point that both of these are important, and we need to manage the tension between them. We can do this by thinking of two operating modes: explore (adaptation-dominant) and exploit (optimization dominant). We tailor a team's operating model to a particular blend of the two - considering uncertainty, risk, cost of change, and an evidence threshold. We should be particularly careful at the points where there is a handoff between the two modes

Six favorite music acquisitions in 2025