Management has mandated roughly a 2x increase in productivity 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 a recent project, that meant about 20 pages of specification and 30 pages of planning. My teammates said it was too much and claimed they couldn't understand it, although activity logs showed that most of them spent only a few minutes looking at the documents. I condensed the material to about five pages, but that removed useful context and didn't improve the reaction.
The resulting change was about 1,000 lines: roughly 200 lines of Terraform and IAM configuration, 600 lines of unit tests, and 200 lines of documentation. The team refused to review it because they considered it too large and complicated. This is especially frustrating because the team routinely merges minimally documented, untested, AI-generated code with little validation. Some of it has contained serious problems that an automated review would have caught, including a roughly 1,500-line Python change that was merged before it could be properly reviewed and later received extensive criticism from an AI reviewer.
I'm the most experienced engineer on the team by a wide margin, but I'm also the only senior person there. My manager says I should find a balance between human and machine-generated work and acknowledges that my approach isn't inherently wrong, but the team dislikes it. Another experienced engineer reviewed the change and supported the design, including wanting to reuse one of its patterns.
I'm struggling to improve engineering quality without alienating the rest of the team. How should I handle the pressure to increase AI-driven output while keeping specifications, reviews, testing, and production safety at a reasonable standard?
3 Answers
AI can make strong engineers much more effective, but it also magnifies weak engineering habits. If the team already skips testing, documentation, and review, faster code generation will usually produce more problems at a higher speed. The central issue here is probably not AI; it’s that the organization has weak engineering standards and no reliable enforcement around production changes.
Set minimum standards that apply to everyone, such as required tests, validation, documentation for operational changes, and an actual review before merging. Otherwise, you’ll keep having arguments about whether one person’s change is too large while much riskier work slips through.
As the senior engineer, try to lead through standards and collaboration rather than repeatedly criticizing individual pull requests. Work with your manager to define a small set of non-negotiable practices, then apply them consistently to everyone: required reviewers, automated checks, tests for meaningful behavior, and a documented reason for exceptions.
A 20-page AI-produced design document may be technically useful, but it can also push a lot of reading and interpretation onto the rest of the team. Give people a concise human-oriented overview and involve them earlier in the key decisions. The goal is not to prove that your workflow is correct; it’s to create a process the team can actually follow without lowering the quality bar.
Try separating the artifacts used to guide the AI from the material humans need to review. A machine may benefit from a very detailed specification and plan, but your teammates probably need a concise design summary: the goal, key constraints, interfaces, risks, rollout plan, and acceptance criteria. Keep the full working documents available, but don’t make everyone digest dozens of pages just to understand the change.
The same applies to the implementation. Split the work into logically independent, reviewable changes where possible. Infrastructure, application behavior, tests, and documentation don’t always need to arrive as one giant change. Make the important design decisions visible first, then let the generated implementation follow those decisions.
My understanding is that the detailed spec-driven artifacts are mainly guardrails for the coding agent, not documents intended for humans to read line by line. The human role is to skim them, identify problems, and request revisions, even though that workflow isn’t especially appealing.
That’s exactly what I’m seeing. A large AI-generated Python change was merged by another junior engineer before I could review it, and an automated review later identified numerous serious issues. It’s already in production, and getting anyone to clean it up is proving difficult.