You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
Key takeaways:
- The bottleneck moved from writing code to reviewing it, and reviewers are paying the price.
- Mandating AI use adds code but not value. Authors still own quality.
- Measure the whole delivery system, including review time, not just output.
One year ago, companies were asking “how can AI help us”? Today they’re asking a very different question: “why hasn’t AI made us faster?”
AI has become a standard tool in the software development pipeline, but its adoption has brought consequences that many organizations did not plan for. Engineers are reviewing more code, carrying more cognitive load, and spending less time collaborating with one another.
The bottleneck in software development hasn’t disappeared. It’s moved.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
In late 2025, Anthropic estimated that “current-generation AI models could increase the US labor productivity growth by 1.8% annually over the next decade.” Many tech leaders translated projections such as this into a finite expectation: if AI helps engineers produce work more quickly, teams should deliver more code with fewer resources.
However, producing code more quickly is not simply a typing problem. Outsourcing entire parts of the engineering process to AI, or asking AI-augmented colleagues without technical backgrounds to produce code, has consequences which impact the quality of our systems and the mental wellbeing of those engineers responsible for them.
A tool which was once thought of as a catalyst for shipping more with less is now creating bottlenecks in places they were not intended to be.
The cognitive cost of AI
Why doesn’t AI automatically make us more productive? The biggest misconception is that generating code more quickly creates faster software delivery.
While AI can complete tasks quickly, the work still requires human judgment. In many teams the constraint has shifted from writing code to reviewing it. Pull requests accumulate faster than engineers have the capacity to understand, test, and approve.
It’s easy to prompt an agent to complete a ticket. It’s much harder to verify that the result fully satisfies the business requirements, upholds the desired architecture, reflects organizational knowledge, handles vital edge cases, and will be maintainable long-term.
The bottleneck transfer from code writing to code reviewing has a human cost. A reviewer who repeatedly encounters obvious syntactical or logical errors is not simply reviewing pull requests, they are reconstructing the author’s logic. Over time, this can erode trust between colleagues.
This dynamic is further complicated when non-technical colleagues open pull requests to solve a business need. While their initiative could be valuable, they may not understand the broader implications of their change. When a reviewer requests a revision, the author may feed the comment back to an AI agent and push the immediate fix without understanding the underlying issue. This can become a cycle: find a problem, request a change, prompt the AI, push the change, repeat.
AI also causes concentration fragmentation. Engineers may begin one task, launch several agents, switch to another task, and return later to validate the output. Each switch requires them to rebuild context. The work of prompting, monitoring, correcting, and refocusing can leave engineers exhausted.
The risk of AI slop in our codebases
There is an assumption that leveraging AI tools and agents will allow all kinds of tasks to be streamlined. Some have responded by mandating usage or asking less technical roles and engineering leads to produce technical work through AI.
This mandate may increase the amount of AI-generated code without increasing its value. Harvard Business Review reports that employees spend an average of one hour and 56 minutes handling each instance of ‘workslop,’ and that 40% of survey respondents had reviewed workslop in the past month.
The time that seems to be saved by the author becomes time spent by the folks downstream responsible for reviewing the work. In a codebase, this cost compounds.
Common risks include:
- Security vulnerabilities: generated code may introduce vulnerabilities or deprecated technologies.
- Codebase bloat: AI may duplicate existing logic or include unnecessary code (i.e. tests) which over time compound.
- Edge case bugs: AI may not identify organizational edge cases, leading to unintentional bugs.
Regardless of whether a pull request was written by a person or generated with AI, the person who initiated the work is responsible for the quality. They should be able to explain the change, test it, and review it before asking a colleague to do so. AI can produce code, but it cannot take accountability for maintaining that code years down the line.
More like this
AI can’t replace creative collaboration
One of the least acknowledged side effects of AI adoption is what happens when people spend more time collaborating with machines than with one another.
Innovation comes from a multitude of ideas, disagreement, domain expertise, and different experiences. AI can generate alternatives and shorten execution timelines, but it cannot replace the constructive friction that occurs between people when they challenge each other’s assumptions.
Human connection matters for trust as well as creativity. In a survey of more than 1,000 US-based full-time employees, Harvard Business Review discovered that 42% of respondents perceive colleagues who sent them AI-generated workslop as less trustworthy, while 37% perceived them as less intelligent.
When collaboration is reduced to a series of AI interactions, the conversations that shape architecture and make products beloved become easier to skip over in the pursuit of speed. Teams risk shipping minimum viable products in order to be the first, rather than shipping products that customers genuinely value.
What healthy AI adoption looks like
The answer is not to abandon AI. It’s to build it into a culture where AI augments human judgment instead of replacing it.
First, responsibility should be preserved with the author. Team members should validate and understand AI-generated work prior to handing it over to someone else for review. AI is useful for challenging assumptions, generating alternatives, and validating a line of reasoning, but the final judgment must remain with the human.
Second, teams should be taught how AI actually works. Engineers must understand hallucinations, common failure modes, security risks, and effective prompt engineering. Shared expectations for AI-augmented work makes review clearer and reduces frustration created by workslop.
Third, document institutional knowledge to make it accessible. Architecture decisions, coding standards, product constraints, and edge cases should be noted where both people and approved AI tools can use them. Explicit context improves output, but does not eliminate the need to verify it.
New York • September 8 & 9, 2027
Loved LDX3 New York? Pre-sale tickets for 2027 are now available.
Fourth, protect the review process. Define what must be true before AI-augmented code can be submitted for a review, for example the author must be able to explain it, relevant tests pass, and security and privacy concerns must be met. Measure the entire delivery system, not just how quickly code is produced but also the time needed to review the influx of work, rework, and maintainability.
Finally, protect time for human collaboration. Review your team rituals and question whether they still create space for engineers, product managers, and designers to think together. A weekly mob-programming session, architecture discussion, or “what I built this week” showcase can restore human connection.
The primary question for engineering leaders should not be “how much more code can we squeeze out of each individual contributor.” It should be, “how can we use AI to help our teams build better products without sacrificing judgment, trust, or the people who make our products possible?”
AI may increase capacity over time, but when organizational expectations rise faster than people can adapt, learn, and build trust, productivity gains turn into burnout. Sustainable adoption requires leaders to optimize for the entire system, not only the speed at which code appears.
