When AI Writes 80% of Code, the Interview Answer Is About Responsibility, Not Lines
When producing code approaches zero cost, the developer's job shifts to defining what correct looks like, constraining trade-offs, and owning risk. Teams that ignore this end up with agents generating plausible code that nobody can verify or trust, which is the real bottleneck in shipping software with AI.
The question 'if AI writes 80% of your code, why does a company still need you?' is now a standard interview probe in late 2026, and the article argues that the number itself is a distraction. Metrics vary wildly depending on whether you count characters, lines, tasks, or merged production code, so debating the figure is pointless. A better response starts by accepting that AI has already moved from code completion to operating across the entire software delivery pipeline: repo research, planning, implementation, testing, pull requests, review, deployment monitoring, and fault diagnosis. Products like OpenAI Codex, Claude Code, Gemini 4 Carbon, GitHub Copilot cloud agent, Cursor Projects, Factory Missions, and Devin Oncall all demonstrate this, and domestic Chinese tools like DeepSeek, Qwen Code, and Kimi Code are following the same path.
The article then dismantles three stale defensive answers. Claiming 'AI code quality is poor' ignores that DORA 2025 found 90% of technical respondents use AI and 59% say it improves code quality, even if that is self-perception, not proof. Claiming 'AI lacks business or system context' overlooks the fact that agents can research a repo, clarify requirements, and build acceptance contracts; the real gap is organizational constraints that live outside the repo, such as which APIs must not change due to unmigrated clients or which processes need human sign-off. And claiming 'humans must do code review and on-call' fails because Claude Code already reviews PRs and Devin Oncall investigates alerts; the durable role is designing verification mechanisms, limiting permissions, and owning decision points.
The recommended answer has three layers: define goals and acceptance criteria so the agent implements the right problem, make system trade-offs with full awareness of constraints beyond the repo, and design the permissions, validation, and escalation mechanisms that let the agent run while keeping final responsibility human. The article advises pairing this with a real project story structured as task, agent responsibilities, discovered issues, changes you made, and verification method, with data from actual projects only, not invented improvements.
The 80% figure is a rhetorical trap: the article's real point is that arguing about the number misses the shift from writing code to defining what correct means and verifying it.
The three-layer answer reframes the developer as a systems engineer who designs constraints, permissions, and verification gates around autonomous agents, not as the person who types the code.
The Stack Overflow data suggests the binding constraint is trust infrastructure, not raw agent capability: developers adopt AI widely but demand local execution and security checks before accepting output.
The article's advice to bring real project data implies interviewers now want evidence of working with agents, not just familiarity with their names or features.