Managing a software team when agents write most of the code

When agents write most of the code, managing a software team stops being about waiting for code. It becomes deciding whether it is the right code.

In a traditional team my week was shaped by how long things took to build. Planning, estimates, stand-ups, chasing whatever was late. Code arrived slowly enough that review and testing more or less kept up.

Now the code arrives in hours, and the bottleneck moves to everything around it. One developer can produce more than a team can meaningfully review. So the week goes on three things:

1. Making the specification precise enough that the build has something to be checked against. 2. Making sure whoever tests the work is not whoever, or whatever, wrote it. 3. Deciding what not to build. Building the wrong thing now costs almost nothing, so almost nothing pushes back against it.

Meetings change too. Fewer status updates, because you can look at the running thing. More time with the people who will use it, walking through a working screen and finding out what they actually meant.

What does not change is who is accountable. The agent does not attend the audit. Someone still has to explain why the system does what it does, and that is now most of the job.

If you run a team like this, what took the most adjusting?

*First posted on [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7517110144548388864/).*