Coding too fast to collaborate | Chris LoyCoding too fast to collaborate<br>Part of AI coding and software<br>19th July 2026 - 5 minute read

Previously:  What temperature are you coding at?

← Back

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...