Software engineering is a collaborative discipline, in which a single engineer typically works closely with others in a cross-functional team. Collaboration happens at the point of input (product specification), output (delivery of working software to the business), and internally (team practices that improve quality, supportability, and maintainability of the software).
Common examples of the latter include intra-team discussions around technical design, and peer review of code prior to deployment. Software engineering organisations have evolved a set of practices that keep these competing forces in equilibrium:
As I have previously written, generative AI is disrupting how engineers produce software, including by allowing others to do so with a far lesser degree of technical knowledge than previously required. But even in teams of experienced software engineers, the impact of AI on how a team functions goes far beyond accelerating the writing of code.
Collaboration practices are being overturned by AI coding agents that blur the line between tool and collaborator, and fundamentally shift intra-team practices. Let’s consider three shifts that are happening in teams today.
Disintermediation of technical design collaboration #
There is a wide spectrum of practices for making technical design a collaborative process within software engineering teams. These range from highly informal (standup discussions, rubber ducking, endless Slack threads) to formalised (technical design reviews, ADRs, backlog grooming), from exploratory (whiteboarding, prototyping) to direct collaborative delivery (pair programming).
All such forms of collaboration happen during the implementation stage of the software development lifecycle. And all are being gradually replaced by engineers conversing directly with their AI coding agents instead of their colleagues. Naïve adoption leads to such design processes being bypassed, as individual engineers are incentivised to cut red tape from their process and focus on faster delivery.
Of course, this is entirely by design: coding agents are built to be conversational, and so in using them it is difficult to avoid slipping from an instructional to an inquisitive pattern of interaction. But as with the trap of over-reliance on AI to write code, treating your agent as both architect and peer at the expense of speaking to your teammates will give only a short-term gain, while damaging the team’s ability to grow their collective expertise.
Starvation of product requirements #
A product manager typically has a broad and varied role serving as an interface between many functions within the business, including strategy, customer service, technology, design, and legal, among others. The function is usually responsible for gathering and then specifying requirements, i.e. a list of things it is desired that the software should do, and for engineering teams the PM tends to be the representative of “the customer”.
The complexity of this role means that an extensive toolset is employed, and much of the work is research, strategy, and consensus-building, carried out through human collaboration. As such, while AI tooling is starting to mature, product managers are not yet experiencing the order of magnitude shift in potential delivery speed that is available to engineering teams.
As engineering capacity is no longer a bottleneck, some engineering teams are starting to experience product starvation: a complete draining of the requirements backlog, and the establishment of a new equilibrium in which only minimal specification is fed to the team before implementation charges ahead, leading to more fragmented and iterative development practices.
Some teams have embraced this by moving the exploratory design phase into the engineering phase, and encouraging teams to start the development process by jumping straight into building prototypes. Whether this or other process adaptations prove the winning formula is yet to be seen.
Saturation of code review capacity #
While product starvation comes from the demand excess produced by accelerated engineering teams, there is also an impact from the corresponding supply excess for the next downstream process from coding. In most teams, this is code review, in which peers from within the team will review each other’s code for correctness, readability, and other measures of quality. A review practice is foundational in most engineering teams, because it serves an important dual purpose: it provides an enforced gate for quality control of the software, and it embeds lateral knowledge sharing in daily operations, reducing bus factor risk of knowledge being siloed within the head of a single engineer.
Both of these goals are difficult to attain when using automated AI-powered reviews that take the human out of the loop. Quality is at higher risk, particularly in novel domains in which different AI models are likely to exhibit similar blind spots and biases. In addition, of course, any process that omits human oversight will obviously degrade knowledge sharing, by removing the need for anyone beside the author to read the code.
As such, many teams are choosing to continue using a human-led review process, to retain both the quality gate and growing collective expertise. Review therefore becomes the new delivery bottleneck, and an increasing proportion of engineering time must be dedicated to it.
Finding a new equilibrium #
AI coding agents have disrupted the delicate balance of engineering teams, by dramatically increasing the rate at which each individual engineer can produce code, putting huge strain on existing team practices. New practices will inevitably emerge in response, but as we experiment with new ways of working, we should be careful not to mistake every collaborative practice for red tape or unnecessary friction.
Software engineering organisations evolved their collaboration practices over decades, balancing not only the competing demands of speed and quality, but also the need to distribute knowledge across the team. This distribution of knowledge allows teams to build collective expertise that is broader than any single engineer could possess, yet remains deep and relevant to each business and its unique problems.
As we develop new team practices that allow us to capture the benefits of AI more fully, we must also be careful not to lose our ability to collaborate effectively with one another.