Management has mandated roughly a twofold productivity increase through AI, measured by things like tickets closed and features released. I've been trying to follow a spec-driven development process, which produces detailed specifications and implementation plans before coding. For one recent project, the documents were about 20 pages of specification and 30 pages of planning. The team said the material was overwhelming, although most people barely opened it. I reduced it to about five pages, but that removed so much context that the result was less useful.
The resulting change was about 1,000 lines: roughly 200 lines of Terraform for a bucket, IAM policy, paths, and a module; 600 lines of unit tests; and 200 lines of documentation. The team rejected the change as too large and complicated to review, despite the code being read by me and another experienced engineer who found no significant issues.
Historically, the team frequently merges minimally documented, lightly tested, largely AI-generated code with little validation. I'm the most experienced person on the team by a wide margin, but concerns about engineering quality are often ignored, and changes sometimes get merged without my review. One recent 1,500-line Python change was merged before I could inspect it, and a later AI review identified many serious problems after it had already reached production.
My manager says I need to find a balance between human and machine work, but also says my approach is not technically wrong—the team simply dislikes it. I'm struggling to meet the productivity directive without overwhelming less experienced teammates or allowing quality and review standards to deteriorate. How should I approach this situation?
4 Answers
Run a limited pilot instead of arguing about AI practices in the abstract. Pick one service or change and agree on success measures beforehand: time to production, review time, rework, escaped defects, rollback rate, and operational incidents. Replace the huge initial package with a short decision record covering constraints, interfaces, risks, and acceptance tests. Then split the implementation into smaller, independently reviewable changes and assign reviewers before generation begins.
The important management question is not simply whether AI is being used. It is who owns the production risk and what evidence is required before generated code ships. If changes can bypass review, no amount of prompting or documentation will solve the underlying control problem.
As the senior engineer, try to lead through process rather than repeatedly criticizing individual changes. Work with your manager to define standards that apply to everyone: what requires tests, documentation, human approval, security checks, and staged rollout. A 20-page AI-generated design document may be technically thorough but still impose too much reading and decision-making on the team. Keep the human-facing summary concise, and treat the detailed artifacts as supporting material or machine guardrails.
AI mostly magnifies the engineering culture that already exists. If the team was cutting corners before, faster code generation will probably produce more rushed and problematic changes. The central issue here sounds less like AI and more like missing standards, weak review controls, and unclear ownership for production quality. A tool cannot compensate for a team that can merge large changes without meaningful review.
That matches what I’m seeing. A large Python change was generated, merged almost immediately, and later exposed many issues during automated review. It is now in production, and getting anyone to clean it up will be difficult.
AI can shift the human role away from typing every line and toward architecture, testing, security, performance, and edge cases. For example, ask an AI tool to perform a focused security review when a change adds external access, or a performance review when it introduces another database. That can produce better systems, but it still requires people to define the questions and validate the answers.
I’m effectively the only senior person on the team, and the detailed artifacts are mainly intended to guide the AI workflow. The junior engineers often prioritize the simplest-looking solution and can outvote or dismiss more experienced recommendations, so I’m trying to improve the process without turning every disagreement into a personal conflict.