Rubber-Stamping AI-Generated Code
Developers accept AI-generated code without verifying it against acceptance criteria, allowing functional bugs and security vulnerabilities to ship because “the tests pass.”
8 minute read
Developers accept AI-generated code without verifying it against acceptance criteria, allowing functional bugs and security vulnerabilities to ship because “the tests pass.”
8 minute read
Fixed scope committed to months in advance causes pressure to cut corners as deadlines approach, making quality flex instead of scope.
8 minute read
Only specific individuals can work on or review certain parts of the codebase. The team’s capacity is constrained by who knows what.
5 minute read
Story points are used as a management KPI for team output, incentivizing point inflation and maximizing velocity instead of delivering value.
8 minute read
Hours are spent estimating work that changes as soon as development starts, creating false precision for inherently uncertain work.
8 minute read
Story points or velocity are used to evaluate individual performance. Developers game the metrics instead of delivering value.
6 minute read
Developers throw code over the wall to a separate team responsible for deployment, creating long feedback loops and no shared ownership.
9 minute read
A small team owns too many products. Everyone context-switches constantly and nobody has enough focus to deliver any single product well.
6 minute read
The team has no dedicated product owner. Tech leads handle product decisions, coding, and stakeholder management simultaneously.
6 minute read
Testing is someone else’s job - developers write code and throw it to QA, who find bugs days later when context is already lost.
9 minute read
Arbitrary deadlines override quality, scope, and sustainability. Everything is priority one. The team cuts corners to hit dates and accumulates debt that slows future delivery.
6 minute read
The belief that CD works for others but not here - “we’re regulated,” “we’re too big,” “our technology is too old” - is used to justify not starting.
9 minute read
Certain individuals are relied upon for critical deployments and firefighting, hoarding knowledge and creating single points of failure.
9 minute read
Post-mortems focus on who caused the problem, causing people to hide mistakes rather than learning from them.
10 minute read
Teams are rewarded for shipping features, not for stability or delivery speed, so nobody’s goals include reducing lead time or increasing deploy frequency.
8 minute read
Code is written by one team, tested by another, and deployed by a third, adding days of latency and losing context at every handoff.
9 minute read
CD adoption is deferred until a mythical rewrite that may never happen, while the existing system continues to be painful to deploy.
9 minute read
100% of capacity is allocated to feature delivery with no time for pipeline improvements, test automation, or tech debt, trapping the team on the feature treadmill.
10 minute read
The team builds services but doesn’t run them, eliminating the feedback loop from production problems back to the developers who can fix them.
9 minute read
Work is assigned to individuals by a manager or lead instead of team members pulling the next highest-priority item.
9 minute read
Management pressures developers to skip or shortcut testing to meet deadlines. The test suite rots sprint by sprint as skipped tests become the norm.
9 minute read
Developers accept AI-generated code without verifying it against acceptance criteria, and functional bugs and security vulnerabilities reach production unchallenged.
4 minute read
It takes longer to explain the task to the AI, review the output, and fix the mistakes than it would to write the code directly.
4 minute read
AI tools produce working code quickly, but the codebase is accumulating duplication, inconsistent patterns, and structural problems faster than the team can address them.
6 minute read
When a developer is stuck, the item waits with them rather than being picked up by someone else. The team has no mechanism for redistributing blocked work.
3 minute read
The team is exhausted. Every sprint is a crunch sprint. There is no time for learning, improvement, or recovery.
4 minute read
There are no documented response procedures. Critical knowledge lives in one person’s head. Incidents are improvised every time.
3 minute read
Stories are marked done but rejected at review. The developer built what the ticket described, not what the business needed.
3 minute read
Changes cannot ship without approval from architecture review boards, legal, compliance, or other teams that are not part of the delivery process and have their own schedules.
3 minute read
Code reviews wait overnight. Questions block for 12+ hours. Async handoffs replace collaboration.
3 minute read
Business terms are used inconsistently. Domain rules are duplicated, contradicted, or implicit. No one can explain all the invariants the system is supposed to enforce.
3 minute read
The board shows many items in progress but few reaching done. The team is busy but not delivering.
3 minute read
Slow CI servers, poor CLI tools, and no IDE integration. Every step in the development process takes longer than it should.
3 minute read
The same problems surface every sprint. Action items are never completed. The team has stopped believing improvement is possible.
3 minute read
Management does not understand why CD matters. No budget for tooling. No time allocated for improvement.
3 minute read
No explicit agreements on branch lifetime, review turnaround, WIP limits, or coding standards. Everyone does their own thing.
3 minute read
Deployment procedures, architecture diagrams, and operational runbooks describe a system that no longer matches reality.
3 minute read
New team members are unproductive for their first week. The setup guide is 50 steps long and always out of date.
3 minute read
Services in five languages with five build tools and no shared pipeline patterns. Each service is a unique operational snowflake.
3 minute read
Pull requests queue up and wait. Authors have moved on by the time feedback arrives.
3 minute read
Post-mortems and retrospectives show the same root causes appearing in the same areas. Each new team makes decisions that previous teams already tried and abandoned.
3 minute read
A new developer joins or is flexed in and delivery slows for weeks while they learn the domain. The pattern repeats with every rotation.
2 minute read
Defects that should be straightforward take days to resolve because the people debugging them are learning the domain as they go. Fixes sometimes introduce new bugs in the same area.
3 minute read
A cultural split between shipping speed and production stability. Neither side sees how CD resolves the tension.
3 minute read
Members are frequently reassigned to other projects. There are no stable working agreements or shared context.
4 minute read
Work is distributed unevenly across the team. Some developers are chronically overloaded while others finish early and wait for new assignments.
3 minute read
Teams cannot provision environments, update configurations, or access infrastructure without filing a ticket and waiting for a separate platform or ops team to act.
3 minute read
Work is complete from the development team’s perspective but cannot ship until a separate QA team tests and approves it. QA has its own queue and schedule.
3 minute read