AI coding agents put software discipline back on the table

Martin Fowler’s June 16 fragments connect a set of arguments that now sit at the center of software work: teams have more powerful coding agents, higher AI bills and a sharper need for engineering discipline.

Fowler starts with Dave Thomas, co-author of The Pragmatic Programmer, who feared LLMs would drain the joy from programming. Thomas found the reverse. He describes programming as a medium for turning thought into action, and he says AI tools remove drudge work, shorten feedback loops and reopen old projects.

That account matters because it treats AI assistance as a change in the programming loop, not a magic replacement for programming judgment. A developer still chooses the model, frames the task, checks the result and owns the code in production.

Fowler then points to Domain-Driven Design after DDD Europe. Eric Evans and others have argued for years that teams need shared language around business rules. AI makes that need sharper. A model can produce code fast, but the team must still define the domain, name the invariants and decide which concepts deserve first-class APIs.

Chelsea Troy’s framing of LLM conversation registers gives teams a useful operating model. She separates exploration from implementation. A team that asks a model to brainstorm options should treat the answer as raw material. A team that asks for implementation should bring a decision, tests and boundaries.

That split maps cleanly to distributed systems work. You do not want a coding agent to invent a consistency model while it writes a storage layer. You want engineers to decide whether a workflow needs linearizable reads, read-your-writes behavior or eventual convergence. Then the model can help express that decision in code and tests.

The same pattern applies to API design. Teams need humans to choose idempotency semantics, pagination contracts, versioning rules and failure modes. An LLM can draft handlers and client code after engineers define those contracts. Without that order, a model may produce a pleasing API surface that breaks retry safety, hides partial failure or returns data with unclear freshness guarantees.

Charity Majors, co-founder of Honeycomb, sharpens the risk. AI enthusiasts see teams ship more code with fewer handoffs. AI skeptics see review queues fill with code that no engineer has read with care. Both groups see part of the system.

Majors asks teams to treat AI adoption as an engineering problem. That means you measure the cost of review, the defect rate, the age of code ownership and the on-call burden. You do not settle the argument through taste or status. You put agents inside a feedback loop and ask which controls lower risk.

A mature team can reduce review work without removing review. It can require design notes for storage changes, mandate tests for concurrency paths and route risky pull requests to owners with domain context. It can also let agents handle low-risk edits, migrations and test scaffolds. The point lies in risk tiers, not blanket permission.

Scale turns that discipline into a survival issue. A small service can absorb a few unclear abstractions. A platform with many teams cannot. Once developers generate code across service boundaries, each API contract carries more load. Retry storms, stale reads and schema drift can spread through systems faster than teams can read diffs.

Simon Willison reads enterprise pricing changes from Anthropic and OpenAI as evidence that coding agents have found a business model. Tools such as Claude Code and Codex move token use from experiments into daily engineering work. Larger bills signal more usage, and more usage means companies now depend on these tools for delivery capacity.

That dependence changes vendor risk. Teams need policies for prompt logging, source access, model choice and data retention. They need exit plans for agent workflows the same way they need exit plans for cloud services. A coding assistant that sits inside the commit path becomes infrastructure.

Mike Masnick’s argument about decentralization gives the AI story a second frame. The open internet promised disintermediation, then large platforms rebuilt the middle layer around attention and algorithmic control. Users gained reach, then lost exit power as their communities and data sat inside closed systems.

AI tools can repeat that pattern. A provider that controls the agent, the context store and the deployment path can steer developer behavior. The team may gain speed, then lose the ability to move its workflows, history and evaluation data elsewhere.

Good engineering practice pushes in the other direction. Keep source of truth in the repository. Store decisions in docs that humans can read. Treat prompts, evals and agent scripts as portable assets. Favor APIs that let teams swap models and compare outputs. Build review gates around observable system behavior, not vendor trust.

That approach also helps with consistency. In distributed systems, teams document the promises a service makes under failure. AI-assisted teams need the same habit for generated code. A pull request should say which invariant the change preserves, which failure case it handles and which tests prove the claim. The model may draft the text, but an engineer must own the statement.

Fowler’s fragments do not argue for restraint as nostalgia. They describe a software practice that can absorb faster tools without giving up ownership. Developers can enjoy LLMs, shorten feedback loops and ship more. They also need domain language, explicit contracts and review paths that match risk.

The durable lesson lands in the workbench. Use agents to remove friction. Use engineering discipline to decide where friction protects the system.