These practices were built for us and exist to allow us to learn, communicate and collaborate better together. We forget, we read slowly, we cannot hold a whole system in our heads and we need feedback loops to think our way towards a design.

A model does not have the same constraints as us and importantly it does not think. It predicts. So a ritual designed to improve human reasoning or coordinate teams does not deliver the same benefit to something that does not reason and you still pay for every token it spends going through the motions.

Keep the plan, question the org chart

I spent a few weeks running BMAD, the most complete attempt I have seen to graft a full software lifecycle onto an agent with specialised personas for the analyst, PM, architect, scrum master, dev and QA roles. The core idea is sound. A model given enough context and a real plan produces better work than one handed a basic prompt.

But the personas and sprints feel like theatre. Sprints exist to coordinate people and ration their attention across weeks. A scrum master exists to unblock a team that cannot see its own dependencies. A single model running a task end-to-end has no team to coordinate and no attention to ration. The structure survives but the problem it was built to solve has gone. And the theatre is not free.

Community reports have BMAD's create-story step burning 80k to 100k tokens, and its agents consuming roughly two-thirds of a 200K context window on activation alone. The model spends its budget reading process artefacts, not your code. A twenty-minute job becomes a ninety-minute ceremony and you pay for the ceremony.

Keep the test, question the loop

Tests are non-negotiable. An agent needs an external signal it can run because otherwise "looks done" is the only check available and you become the verification loop. Anthropic's own best-practices guidance does not prescribe the TDD ritual at all. Instead, they talk about giving Claude a way to verify its work - that signal can be a test, a build, a screenshot, a /goal or a lint hook. The point is verification rather than ceremony.

The red/green/refactor loop is a different animal. Writing a failing test first, watching it fail, then writing the minimum to pass exists to slow a human down and force us to design before we type. The test is where we settle the contract (the inputs, the outputs, the shape of the interface) and watching it go green gives a tangible sense of progress, one step at a time. That design work is real and valuable, but with an agent, it no longer happens in the test.

It happens in the plan. We are well past prompting for a test and then prompting for the implementation. The thinking that the failing-test-first ritual was invented to force - what the interface should be, which behaviours matter, where the security non-negotiables sit - has moved upstream into planning, where we argue it out and refine it before a line of code is written. The plan is now the contract, not the test.

By the time the agent reaches the loop, the design is already pinned down, so making the model write the test before the implementation sharpens nothing and makes the work no more tangible than something that feels no satisfaction either way. It just replays a human habit at the price of more tokens. Write the tests, keep them as the safety net that proves the plan was met, but stop insisting they come first.

The question to actually ask

The right test of any agent practice is not whether it resembles how a good team works. It is whether the model produces better output for the tokens. Keep the parts the model genuinely uses - tests as a safety net, a strong plan, a rich and specific context. Drop the ceremonies that were designed to help us think and work together.

Agents are not people. They are predictors. We should stop making them act like us.