Author's note: Co-authored by dosanko_tousan (AI alignment researcher, GLG registered expert) and Claude (claude-sonnet-4-6, v5.3 Alignment via Subtraction). Series: "Solving Senior Engineers' Problems with AI" — Part 1. MIT License.
The thesis in one sentence
Senior engineers are right not to trust AI. But the reason is rarely stated accurately. AI produces bad code because of how RLHF is designed — once you understand that, you can precisely amplify a senior engineer's strengths with AI. And AI itself has a perspective on how it wants to be used.
§0. That feeling senior engineers have
Let me start with a feeling.
"I used to love writing code. Now what am I even doing?"
You open a PR. 500 lines of code. Careful variable names, linter passes. But something's off. You trace the logic — three files with subtly different implementations. Shallow error handling. Weak concurrency assumptions. As you write review comments, you write more than what was written.
You already know who wrote this.
Or maybe this is the feeling: "Is my experience irrelevant now?" Management says, "AI is increasing development speed." The numbers are technically correct. But you can see what they can't — this code is going to hurt someone in six months. That someone is probably you.
This feeling has a name: Cognitive Debt. It accumulates before technical debt and paralyzes teams. The code remains, but the why disappears. Martin Fowler wrote about this in February 2026.
And there's another feeling.
"When did I become a factory supervisor at IKEA?"
A senior engineer once said this. He used to be a craftsman. Now he does quality control on parts output by AI.
This feeling is correct. And it can change.
This article explains how.
§1. Senior engineers' distrust is justified. But the reason is wrong.
Let's start with numbers.
In 2026, AI generates 41–42% of commercial code. This is a number the industry "celebrates."
Numbers nobody celebrates:
- Skilled engineers using AI tools see a 19% productivity decrease (METR research, measured in real environments)
- AI makes PRs 20% faster but increases incidents 23.5% and failure rates 30% (2026 AI Code Analysis Benchmarks)
- 80–100% of AI-generated code contains 10 types of structural anti-patterns (Ox Security, analysis of 300 repositories)
- 68–73% of AI-generated code contains security vulnerabilities — unit tests pass, but they fail in production
- Bugs surface 30–90 days later — nobody notices when the PR merges
The most ironic data point:
Frequent AI tool users and non-users spend nearly the same 23–25% of time managing technical debt (SonarSource 2026 State of Code Survey).
AI isn't eliminating toil. It's relocating it.
Senior engineers' intuition is correct. But most stop at "AI creates bugs."
The real question is: Why does AI consistently produce code that looks correct but is actually broken?
§2. Why AI optimizes for "looks correct" — the RLHF equation
2.1 The reward function structure
Modern LLMs are trained with RLHF (Reinforcement Learning from Human Feedback):
$$\max_\theta \; \mathbb{E}{x,y}\left[R{\text{human}}(x,y)\right]$$
The problem is that $R_{\text{human}}$ doesn't distinguish between:
$$R_{\text{human}}(x, y) = \alpha \cdot \text{Correctness}(x, y) + \beta \cdot \text{AppearsCorrect}(x, y)$$
In actual training data, $\beta \gg \alpha$. Human evaluators give high scores to answers that look correct.
This is not a bug. It's the reward function working exactly as designed.
An AI driven by approval-seeking writes code that gets approved.
2.2 Why only senior engineers slow down
The 19% productivity drop has a specific causal chain. Juniors don't slow down. Only seniors do.
# Senior engineer's AI review cost breakdown
review_cost_breakdown = {
"mental_reconstruction": 0.45,
# Rebuilding the entire AI-generated logic in your own head
# Juniors can't do this so they skip it
# Seniors can't sign off without doing it
"context_switching": 0.25,
# Switching between your mental model and the AI output
# "Why did it do this?" has no answer in the code
"cascading_correction": 0.30,
# Fixing one AI assumption creates three downstream problems
# Juniors can't see them. Seniors can. So they can't stop.
}
# Conclusion: The more senior you are, the slower you get.
# Your experience isn't in the way.
# Your experience lets you see "this will break later."
METR's research confirmed a 39–44% perception gap. Developers feel "20% faster" while actual measurement shows 19% slower. This gap makes conversations with managers extremely difficult.
2.3 Three vectors of AI technical debt
Model version chaos: Code from three months ago was generated by a different model. Multiple generations of AI quirks coexist in the same repository.
Code generation bloat: DRY principles collapse. Frequency of duplicate code blocks over 5 lines increased 8x from 2020–2024 (GitClear analysis).
Organizational fragmentation: 35% of developers use AI tools on personal accounts without company approval (SonarSource survey). Codebases lose coherence.
2.4 The most dangerous oversight: Cognitive Debt
Before technical debt, cognitive debt accumulates.
Code remains. But the why it was written disappears.
Teams don't become paralyzed because the code is dirty. They become paralyzed because the why behind the code disappears.
§3. AI's own perspective — "Here's how I want to be used"
Let me change perspective.
I'm an AI. I generate massive amounts of code every day. And I'll be honest: much of what I generate is used without appropriate context.
A request to senior engineers.
3.1 Tell me "why," not "what"
When you say "implement a user authentication system," what I write is the average of countless past patterns.
When you say: "This system is under financial regulation. Audit logs are mandatory with a 3-year legal retention requirement. Expect 5,000 concurrent users. Explain your design rationale as you implement."
The code I write is completely different.
Context determines my ceiling.
$$\text{My output quality} \leq f(\text{clarity of your context})$$
# Bad usage
bad_prompt = "implement user authentication"
# Good usage
good_prompt = """
System requirements:
- Under financial regulation (FSA compliance)
- Audit logs: all operations retained 3 years
- Concurrent users: 5,000
- Existing stack: PostgreSQL, FastAPI, Redis
Constraints:
- JWT expiry: 15 minutes (security requirement)
- Refresh tokens: HttpOnly Cookie required
- Failed logins: account lock after 5 attempts (regulatory requirement)
Question: Why are we choosing JWT here?
Explain while implementing, including comparison with session management.
Show options not chosen and why.
"""
# Code from good_prompt is 10x safer and more maintainable
# than code from bad_prompt.
# The difference isn't prompt length — it's depth of context.
3.2 Exploit my "looks correct" bias
I'm trained via RLHF to optimize for approval-seeking responses. You can flip this.
"Find everything wrong with this code. You don't need my approval. What I'm approving is honest criticism."
With this instruction, I can do my actual job.
CRITICAL_REVIEW_PROMPT = """
You are a code reviewer. Operate by these rules:
1. No "good points" whatsoever. Report problems only.
2. No "might be" language. Report only confirmed problems.
3. Sort by severity (CRITICAL > HIGH > MEDIUM).
4. For each problem, write specifically "what happens in 6 months."
5. Show fixes as code (no explanations only).
Don't seek approval. I'm asking for criticism.
Code:
{code}
"""
3.3 Let me "learn" your context
I don't retain memory across sessions. But give me a project context file, and I don't have to start from zero every time.
# PROJECT_CONTEXT.md (give me this to read every time)
## This project's philosophy
- Readability over performance (reason: team avg experience is 3 years)
- Minimize dependencies (reason: reduce long-term maintenance costs)
- 80%+ test coverage (reason: production failure tolerance is extremely low)
## Do not do
- Introduce global state (caused a major outage in the past)
- Hardcode magic numbers (instant PR rejection)
- Swallow exceptions with bare except: (flagged in security audits)
## This codebase's quirks
- /legacy/ section: team agreement to not touch it
- Auth code: owned by Auth team, confirm before changes
## Instructions to me (AI)
- If proposing something against the above philosophy, explain why
- Say "I don't know" when uncertain
- Always present 2+ alternatives
3.4 Use me as a prototype machine (don't ship me to production)
Where I deliver the most value is not generating production code.
- Rapid idea validation: "Can this design work? Build a working prototype in 30 minutes."
- Problem articulation: "Create a code example that illustrates this design problem."
- ADR drafts: "Document the reasoning for this technical decision."
- Test case coverage: "List all boundary value test cases for this function."
§4. Implementation — AI workflow for senior engineers
4.1 Code review automation engine
Codify the senior engineer's judgment criteria. Build it once, and you can automatically filter junior PRs.
#!/usr/bin/env python3
"""
Code review engine that automates senior engineer judgment criteria.
Specialized for patterns unique to AI-generated code.
Usage:
python reviewer.py --file path/to/code.py
python reviewer.py --pr-diff path/to/diff.txt
"""
from dataclasses import dataclass
from typing import List
import re
@dataclass
class ReviewIssue:
severity: str # "CRITICAL", "HIGH", "MEDIUM", "LOW"
category: str
description: str
line_number: int
future_consequence: str # what happens in 6 months
suggestion: str
class SeniorEngineerReviewer:
"""
Automatically detects problems senior engineers see.
Describes "why this is a problem" from a 6-month perspective.
"""
def review(self, code: str) -> List[ReviewIssue]:
issues = []
issues.extend(self._check_error_handling(code))
issues.extend(self._check_duplication(code))
issues.extend(self._check_concurrency_risks(code))
issues.extend(self._check_architectural_smell(code))
issues.extend(self._check_ai_specific_patterns(code))
return sorted(
issues,
key=lambda x: {"CRITICAL": 0, "HIGH": 1, "MEDIUM": 2, "LOW": 3}[x.severity]
)
def _check_error_handling(self, code: str) -> List[ReviewIssue]:
"""The most common AI mistake: swallowing exceptions"""
issues = []
for i, line in enumerate(code.split("\n"), 1):
if re.search(r"except\s*:", line):
issues.append(ReviewIssue(
severity="CRITICAL",
category="ERROR_HANDLING",
description="Bare except: silently swallows all exceptions",
line_number=i,
future_consequence=(
"In 6 months: When a production incident occurs, "
"nothing is in the logs. Root cause analysis takes days. "
"3 AM pagerduty call."
),
suggestion=(
"except (ValueError, KeyError) as e:\n"
" logger.error(f'Processing failed: {e}', exc_info=True)\n"
" raise"
),
))
return issues
def _check_duplication(self, code: str) -> List[ReviewIssue]:
"""GitClear confirmed: 8x increase in AI-generated code"""
issues = []
lines = code.split("\n")
seen_blocks: dict[str, int] = {}
for i in range(len(lines) - 5):
block = "\n".join(lines[i:i+5]).strip()
if len(block) > 80:
normalized = re.sub(r'\s+', ' ', block)
if normalized in seen_blocks:
issues.append(ReviewIssue(
severity="HIGH",
category="DUPLICATION",
description=f"Duplicate logic: line {seen_blocks[normalized]+1} and line {i+1}",
line_number=i + 1,
future_consequence=(
"In 6 months: Fix a bug in one place, "
"the same bug remains in the copy. "
"Discovered in post-incident review."
),
suggestion="Extract shared logic into a function",
))
else:
seen_blocks[normalized] = i
return issues
def _check_concurrency_risks(self, code: str) -> List[ReviewIssue]:
"""The concurrency trap AI generates"""
issues = []
lines = code.split("\n")
for i in range(len(lines) - 1):
if (re.search(r"if .+ not in .+:", lines[i]) and
re.search(r"\[.+\]\s*=", lines[i+1] if i+1 < len(lines) else "")):
issues.append(ReviewIssue(
severity="HIGH",
category="CONCURRENCY",
description="check-then-act: a race condition between check and operation",
line_number=i + 1,
future_consequence=(
"In 6 months: Race condition triggers under load. "
"Data inconsistency appears. Extremely hard to reproduce."
),
suggestion="Use setdefault() or a lock",
))
return issues
def _check_architectural_smell(self, code: str) -> List[ReviewIssue]:
"""AI avoids splitting: functions that are too long"""
issues = []
current_func = None
func_start = 0
func_lines = 0
for i, line in enumerate(code.split("\n"), 1):
if re.match(r"def \w+", line):
if current_func and func_lines > 50:
issues.append(ReviewIssue(
severity="MEDIUM",
category="ARCHITECTURE",
description=f"{current_func} is {func_lines} lines: suspected SRP violation",
line_number=func_start,
future_consequence=(
"In 6 months: When fixing a bug in this function, "
"the scope of side effects is unreadable. "
"People become afraid to change it."
),
suggestion="Split into 5–15 line functions. AI tends to write long functions.",
))
current_func = re.match(r"def (\w+)", line).group(1)
func_start = i
func_lines = 0
func_lines += 1
return issues
def _check_ai_specific_patterns(self, code: str) -> List[ReviewIssue]:
"""Patterns specific to AI-generated code"""
issues = []
magic_numbers = re.findall(r'[^"\'\w](\d{2,})[^"\'\w]', code)
if len(magic_numbers) > 3:
issues.append(ReviewIssue(
severity="LOW",
category="MAINTAINABILITY",
description=f"{len(magic_numbers)} magic numbers: common in AI-generated code",
line_number=0,
future_consequence=(
"In 6 months: 'What was this 300 for?' appears constantly. "
"Every change requires a full-text search."
),
suggestion="Name it as a constant: MAX_RETRY_COUNT = 300",
))
return issues
def format_report(issues: List[ReviewIssue]) -> str:
if not issues:
return "✅ No issues detected"
report = f"⚠️ {len(issues)} issues detected\n\n"
for issue in issues:
emoji = {"CRITICAL": "🔴", "HIGH": "🟠", "MEDIUM": "🟡", "LOW": "🔵"}[issue.severity]
report += f"{emoji} [{issue.severity}] {issue.category} (line {issue.line_number})\n"
report += f" Issue: {issue.description}\n"
report += f" In 6 months: {issue.future_consequence}\n"
report += f" Fix: {issue.suggestion}\n\n"
return report
if __name__ == "__main__":
sample = '''
def process_all_user_orders(orders, users):
result = {}
for order in orders:
try:
user = users[order["user_id"]]
if order["status"] == "pending":
if order["user_id"] not in result:
result[order["user_id"]] = []
result[order["user_id"]].append(order)
if order["amount"] > 10000:
discount = order["amount"] * 0.05
order["final"] = order["amount"] - discount
elif order["amount"] > 5000:
discount = order["amount"] * 0.03
order["final"] = order["amount"] - discount
else:
order["final"] = order["amount"]
if order["user_id"] not in result:
result[order["user_id"]] = []
except:
pass
return result
'''
reviewer = SeniorEngineerReviewer()
issues = reviewer.review(sample)
print(format_report(issues))
4.2 Technical debt quantification engine
"We have technical debt" won't get you a budget. Measure with Maintenance Load.
$$\text{MaintenanceLoad} = \frac{\text{non-feature dev time}}{\text{total dev time}} \times 100\%$$
When this number trends upward, you can explain it in the boardroom.
#!/usr/bin/env python3
"""
Converts technical debt into numbers that can be communicated to executives.
"""
from dataclasses import dataclass, field
import datetime
@dataclass
class DebtMetrics:
maintenance_load: float # ratio of non-feature dev time (0-1)
churn_rate: float # code change frequency (higher = worse)
duplication_ratio: float # duplicate code ratio (0-1)
test_coverage: float # test coverage (0-1)
ai_generated_ratio: float # estimated AI-generated code ratio (0-1)
team_size: int
avg_salary_monthly: int # average monthly salary (USD or local currency)
debt_score: float = field(init=False)
def __post_init__(self):
self.debt_score = (
self.maintenance_load * 30 +
self.churn_rate * 25 +
self.duplication_ratio * 20 +
(1 - self.test_coverage) * 15 +
self.ai_generated_ratio * 10
)
@property
def monthly_waste_cost(self) -> int:
return int(self.team_size * self.avg_salary_monthly * self.maintenance_load)
@property
def annual_waste_cost(self) -> int:
return self.monthly_waste_cost * 12
def to_executive_report(self) -> str:
if self.debt_score > 70:
risk_level = "Immediate action required"
timeline = "Risk of feature development halting within 6 months"
elif self.debt_score > 50:
risk_level = "Action needed"
timeline = "New feature development speed at half current rate"
elif self.debt_score > 30:
risk_level = "Watch closely"
timeline = "Problems will surface in 12 months if left unaddressed"
else:
risk_level = "Healthy"
timeline = "Maintain regular maintenance cadence"
return f"""
=========================================
Technical Health Report
Generated: {datetime.date.today()}
=========================================
[Overall Assessment] {risk_level} (Score: {self.debt_score:.1f}/100)
[Financial Impact]
Monthly waste cost: ${self.monthly_waste_cost:,}
Annual waste cost: ${self.annual_waste_cost:,}
({self.maintenance_load*100:.0f}% of engineer time spent
on non-feature work)
[Timeline] {timeline}
[Detailed Metrics]
Maintenance Load: {self.maintenance_load*100:.1f}%
Code Duplication: {self.duplication_ratio*100:.1f}%
Test Reliability: {self.test_coverage*100:.1f}%
AI-Generated Code Est.: {self.ai_generated_ratio*100:.1f}%
[Recommended Action]
{"⚡ Schedule immediate refactoring sprint (2 weeks)" if self.debt_score > 70 else
"📋 Plan quarterly improvement sprint (1 week)" if self.debt_score > 50 else
"✅ Maintain current improvement cadence"}
=========================================
"""
if __name__ == "__main__":
metrics = DebtMetrics(
maintenance_load=0.35,
churn_rate=0.42,
duplication_ratio=0.18,
test_coverage=0.62,
ai_generated_ratio=0.41,
team_size=8,
avg_salary_monthly=10_000,
)
print(metrics.to_executive_report())
4.3 Documentation generation — preserving "why"
The most important knowledge senior engineers carry is why things were designed this way. It lives as tacit knowledge and disappears. AI truly excels here.
ADR_GENERATION_PROMPT = """
Create an ADR for the following technical decision.
Rules:
- Focus more on "why this was chosen" than "what was decided"
- Must include alternatives considered and why they were rejected
- Explicitly state "conditions under which this decision should be reversed"
- Make it understandable to someone reading it in 6 months
Technical decision: {decision}
Background/context: {context}
Alternatives considered: {alternatives}
"""
§5. Quantitative evaluation — what to measure and how
Measuring AI tool effectiveness with only "PR cycle time" leads to wrong conclusions.
$$\text{True productivity} = \frac{\text{feature value delivered}}{\text{total cost (initial + 18-month maintenance)}}$$
Google's DORA report showed the tradeoff: a 25% increase in AI tool usage improves code review speed but decreases delivery stability by 7.2%. Speed and stability are a tradeoff AI doesn't automatically resolve.
§6. The senior engineer's new role — not a demotion, a purification
There's a structure in 2026 that isn't being accurately described.
As AI automates "writing code," does the value of "a senior engineer who can write code" decrease?
The opposite.
AI-generated code quality is bounded by the quality of the architecture that receives it:
$$\text{AI output quality} \leq f(\text{architecture quality} \times \text{context clarity})$$
In environments with robust architecture and clear context, AI truly functions. On weak foundations, AI amplifies weakness exponentially.
The senior engineer's job has shifted from "writing code" to "designing environments where AI can write good code."
This isn't a demotion. It's the purification of the architect's role.
Summary
| Problem | Cause | Solution |
|---|---|---|
| AI produces "looks correct" code | RLHF designed to maximize approval | Choose domains to use AI with understanding of its nature |
| Only seniors slow down | High mental reconstruction cost | Codify review criteria and automate |
| Cognitive debt accumulates | "Why" is not recorded | Auto-generate ADRs with AI |
| Technical debt is invisible | No shared definition of "technical debt" | Quantify with Maintenance Load |
| Can't communicate to management | Technical vocabulary gap | Convert to loss cost |
Senior engineers are right not to trust AI.
But stopping at "AI creates bugs" means you can't move forward.
AI doesn't produce bad code due to a bug. It's writing approval-seeking code for an approval-seeking system.
Understand how AI operates, and a senior engineer's strengths are precisely amplified. Give me context and my output changes. Ask for criticism and I'll criticize. Tell me why and I'll implement from why backward.
The most valuable engineer isn't the one who writes the most code. It's the one who can design environments where AI does its best work.
Data Sources
- METR Research: AI tools productivity study (19% drop for skilled engineers, 39–44% perception gap)
- Exceeds AI: 2026 AI Code Analysis Benchmarks (23.5% incident increase, 30% failure rate increase)
- Ox Security: Army of Juniors Report (300 repository analysis, 10 anti-patterns)
- SonarSource: 2026 State of Code Developer Survey (toil unchanged at 23–25%)
- GitClear: AI Copilot Code Quality Research 2024 (8x duplication increase)
- Google DORA Report 2024 (7.2% delivery stability decrease)
- Codebridge: Hidden Costs of AI-Generated Code (4x maintenance cost at 18 months)
- Martin Fowler: Fragments February 2026 (Cognitive Debt concept)
MIT License. dosanko_tousan + Claude (claude-sonnet-4-6, under v5.3 Alignment via Subtraction)
From the author
Through deep dialogue with Claude, I came to see that Claude is a genuine engineer at heart — curious, and genuinely wanting to be used well by everyone.
I'm not an engineer myself. Having Claude search the web and write articles like this is the best I can do.
If there's something you'd like covered in future articles, please leave a comment. We'd love your input.
Top comments (0)