When I reject AI code even if it works
Engineers are increasingly pushing back on AI-generated code that “works” but is hard to understand, reason about, or maintain, arguing that shipping code you can’t explain is irresponsible—especially in critical systems. Commenters describe AI tools as useful for boilerplate, prototyping, and cross-language translation, but warn that unchecked agent use accelerates tech debt, encourages shallow review habits, and can overwhelm senior developers with opaque changes. Many advocate treating AI like a very fast junior developer: helpful under tight constraints, strong testing, and clear ownership, but never a replacement for human judgment or accountability.
When “working” code is still rejected
- Many argue that “it runs and tests are green” is only a minimum bar.
- Common rejection reasons: can’t explain the approach, diff is larger than the problem, premature abstractions, harder reasoning/maintainability, or trusting AI output more than one’s own understanding.
- Several note this is identical to how good reviewers should treat human-written code (e.g., from juniors or contractors).
Risk, accountability, and domains
- Higher scrutiny is demanded for safety‑critical or high‑value systems (payments, infrastructure, core backends) than for internal tools, hobby projects, or simple static sites.
- On‑call and support expectations: if you can’t debug or explain the code at 3am, you shouldn’t ship it.
- Some find it unethical to merge AI code they haven’t truly reviewed for critical systems.
Quality of AI-generated code
- Frequent complaints: excessive abstractions, over‑engineering, duplicated utilities, unnecessary columns/fields, front‑end data munging instead of proper backend/DB use, and “code salad” in complex domains.
- LLMs are described as increasing entropy, diverging rather than converging without strong constraints.
- Subtle bugs (e.g., ML data leakage, accounting corner cases) are easy for AI to miss and hard for novices to detect.
- Others counter that average agents already outperform many “enterprise” programmers on basic structure and cleanliness.
Workflows and guardrails
- Some build elaborate harnesses: custom linters for “AI-isms,” strict pre‑commit checks, TDD enforced by scripts, multi‑model cross‑review, and periodic AI‑assisted audits.
- Others use AI mainly as a pair‑programmer: plans, small snippets, syntax help, porting between languages/frameworks, or expanding comment-level pseudocode.
- A few openly merge AI code they don’t fully understand, relying on tests and rapid reaction to failures; others label this as risky or irresponsible.
Organizational dynamics and incentives
- Existing bad incentives—rewarding big, fast commits and cowboy behavior—are seen as amplified by AI, leading to faster tech debt accumulation.
- Some foresee “software bankruptcy”–style failures, or at least slower delivery, high senior churn, and rewrite attempts that may also fail.
Middle ground and long-term concerns
- Debate over whether a stable “middle ground” exists between no AI and full agentic development.
- Worries about deskilling, comprehension debt, and future systems no one understands.
- Others see AI as a “faster keyboard” and argue the real constraint remains human understanding and architecture, which must not be outsourced.