I’ve been doing a lot of software engineering recently using Claude Code and Spec-Driven Development (SDD) using GitHub spec-kit, and something interesting has emerged that has less to do with technology and more to do with how I am working with Claude Code.

I realised that I need to treat coding agents as members of the development team and include them in the decisions we make.

That might sound a little odd. Claude Code isn’t a person, doesn’t attend project meetings and isn’t accountable for the decisions being made. But when an agent is doing a substantial portion of the engineering work, what happens when the human team makes a decision and nobody tells it?

I’ve found that this requires a change in how I think about managing software development.

What is it?

I’m working on an application build and as part of this I’ve built a series of harnesses around Claude Code and spec-kit to automate the analysis of those requirements, organise them into features, identify the tasks, group them into development phases and then work through building and verifying each phase.

There are controls throughout the process. Some are deterministic scripts (hooks), others are instructions governing what decisions Claude Code can make independently and which ones need to be escalated to me. But there is an interesting behavioural change that comes with this.

The coding agent needs to be kept informed, just as another member of the development team would be.

Think about a fairly normal project situation. A meeting takes place with a business stakeholder, and a decision is made to change a workflow. Perhaps managers can no longer approve their own expenses, or a new authorization level is required.

In conventional development, we’d expect that decision to be communicated to the developers. Someone would update the requirements or backlog, and the team would incorporate the change. With an agentic SDD process, it’s surprisingly easy to miss the agent.

The human team understands the change. The project manager and I understand the change. But Claude Code is still working from the specifications and decisions it has been given. Unless we deliberately update that context, the agent can quite correctly implement something that the business no longer wants. And because it’s following a structured specification, it will do a very good job of implementing the wrong thing.

SDD helps address this by making the specification central to development, rather than treating it as documentation that sits alongside the code. Spec Kit provides a structured approach to specifying, planning, breaking down and implementing features, with analysis and convergence steps to help verify consistency and completeness, but it requires a change on our part.

What I’ve come to appreciate is that this isn’t just about providing a better initial specification. It’s about keeping the specifications, decisions and the agent’s understanding of the project aligned as the project evolves.

That includes answering the questions the agent raises, feeding the agent the project decisions, communicating scope changes and ensuring those changes flow through the relevant specifications, tasks and tests.

What does it mean from a business perspective?

I think there are several interesting implications here.

The first is that software development starts to look a little different from a management perspective.

We’re used to managing development teams through requirements, meetings, backlog refinement, design discussions, code reviews and progress reporting. None of those activities necessarily disappears with agentic coding. But the information produced by them needs to reach a participant that isn’t sitting in the meeting, isn’t reading Teams messages and doesn’t reliably retain the history of previous conversations.

That requires a more deliberate approach to recording decisions and making project knowledge available.

The second implication, and potentially the more important one, is institutional knowledge.

For years, one of the risks in software engineering has been the amount of knowledge that resides in individual developers’ heads. We all know the situation. A developer who built an application leaves, someone new takes over, and a considerable amount of time is spent trying to understand not only how the code works, but why certain decisions were made. Documentation helps, assuming it exists and has been maintained.

With SDD, there’s an opportunity to make the documentation and decision history part of the engineering process itself. The repository can contain the validated requirements, specifications, architecture decisions, implementation plans, tests, outstanding questions and the reasoning behind decisions (i.e. the project changes that happen as development has moved along).

The result is much more than a source-code repository. It becomes a record of how the application was designed, built and evolved capturing institutional knowledge and reducing key-person risk.

My hypothesis is that this will significantly reduce the traditional knowledge-transfer problem.

There’s also a governance aspect. I’ve found it useful to distinguish between decisions the coding agent is authorized to make and those that need human involvement. A routine implementation choice of something behind an API might be delegated to the agents whereas a change to business rules, security requirements, scope or architecture may need explicit human approval.

That’s quite a different mindset from simply asking an AI tool to write some code.

What do I do with it?

I think the practical starting point is to stop treating agentic coding as an individual developer productivity tool and start considering how it fits into the team’s working practices.

• Include your coding agent in the information flow. When scope changes, requirements are clarified or architectural decisions are made, establish a process for updating the repository and the context used by the agent. Don’t assume that because the human team knows something, the agent does too.
• Make questions and project decisions part of the engineering record. When an agent raises an ambiguity, record the question, the answer, who made the decision and why. Ensure that any affected specifications and tests are reviewed and updated. I think this is particularly important when development spans many sessions or phases.
• Separate decisions from execution. Define what the agent is allowed to decide, what must be escalated and what evidence is needed before work can be considered complete. Deterministic controls, automated tests and human review all have a role here. A language model declaring its own work complete isn’t sufficient evidence of quality.
• Treat knowledge consistency as part of completion. Before you start working on a feature ask yourself - “Has anything changed during development that hasn’t been reflected in the engineering record?”
• Test whether someone else can take over. This is probably the most interesting test for me. Give another developer the repository, specifications and harness, then ask them to make a meaningful change, maybe a complete feature. See what they can understand independently and what still requires someone to explain the history. That will tell you a great deal about whether you’ve actually captured the institutional knowledge or simply created more documentation.

There’s an important qualification to all of this.

Treating a coding agent as a team member doesn’t mean pretending it’s human. It doesn’t have the same awareness, judgement, accountability or continuity of memory that a person has - that’s precisely why SDD matters. We need to be deliberate about what the agent knows, how it receives new information, what it can decide and how its work is verified.

The technology is making it possible for coding agents to undertake increasingly substantial pieces of development work. But getting the full benefit requires us to change how we manage the work around them.

Perhaps one of the most valuable outcomes won’t be how quickly the software gets built. It will be that when the next developer arrives, human or AI, the organisation can explain not only what the application does, but why it does it.