How to Avoid Hiring an AI-Fuelled Technical Debt Machine
The short answer
Generative AI creates a new archetype: the engineer who ships code at velocity but creates crippling technical debt. Your current interview process likely rewards this behaviour. Screen for stewardship, not just speed. Shift from 'build this' tasks to 'refactor this' and code review exercises to test for judgement and maintainability.
AI tools amplify the 'rockstar developer' problem
The 'rockstar developer' who trades maintainability for cleverness is not a new phenomenon. What is new is that generative AI equips every developer with the tools to become one. These tools excel at generating thousands of lines of code at inhuman speed, but they lack context. They do not understand your existing architecture, your team's conventions, or the long-term cost of their suggestions. The result is a new-look technical debt. It looks like perfectly valid, often complex code that solves an immediate problem. But it is disconnected, hard to debug, and nearly impossible for other team members to build upon. As one analysis of the pattern notes, <a href="https://www.codingwithjesse.com/blog/rockstar-developers/">AI agents don't care if a system is becoming more or less understandable</a>. For talent leaders, the risk is clear. Hiring for raw coding velocity now carries a significant, hidden cost. The engineer who appears most productive in the short term may be the one who quietly grinds your product roadmap to a halt in six months. Your best senior engineers will pay the price, spending their time cleaning up messes instead of shipping value.
Your tech tests now reward the wrong behaviour
Most scale-up interview processes for engineers are designed to test for speed and problem-solving under pressure. Whiteboard sessions and timed take-home assignments inadvertently favour the candidate who can generate a solution fastest. With AI coding assistants, this is no longer a useful signal for engineering quality. An engineer can produce a functioning, complex solution in a fraction of the time, not through deeper understanding but through sophisticated prompt engineering. By rewarding speed, you are selecting for candidates who are adept at using AI to produce output, not for those who apply critical judgement to its use. This makes <a href="/why-hiring-speed-alone-is-a-misleading-metric-in-saas">hiring speed a dangerously misleading metric</a> when evaluating technical talent. The process creates a strong incentive to prioritise a quick solution over a maintainable one, hiding the very technical debt you need to uncover. It's time to re-evaluate whether your assessment is testing for the right skills. A process that cannot distinguish between productive and destructive velocity is a liability.
Screen for stewardship with code review challenges
To identify true engineering quality, you must shift your interviews from creation to curation. Instead of asking a candidate to build something from scratch, give them a complex, messy, or even AI-generated piece of code and ask them to improve it. This type of exercise tests for a completely different, and more valuable, set of skills: an ability to diagnose issues, a pragmatic approach to refactoring, and an understanding of software design principles that lead to maintainable systems. Ask them to perform a code review. What would they flag? What questions would they ask the original author? What trade-offs are they considering? Their answers reveal their engineering maturity far more effectively than a coding challenge ever could. Documenting these criteria is vital for ensuring fairness and repeatability, which is why <a href="/how-interview-scorecards-improve-hiring-decisions-saas">structured interview scorecards are critical</a> for making this change stick. By standardising this approach, you start hiring for the engineers who make the whole team faster, not just themselves. Building these robust, consistent processes is a focus for any mature <a href="/raas">Recruitment-as-a-Service</a> model.
Frequently asked questions
- Should we ban candidates from using AI tools in our tech tests?
- No, that's unrealistic and misses the point. Instead, design tests where AI use is irrelevant or even encouraged, but the focus is on the candidate's strategic choices, trade-off analysis, and explanation of the final code quality.
- What's one change I can make to our engineering interviews this month?
- Introduce a code review stage. Provide a 100-200 line code sample with subtle bugs and design flaws, and ask the candidate to critique it as if they were reviewing a teammate's pull request. This immediately shifts the focus to quality and maintainability.
- How do I sell this change to my VP of Engineering?
- Frame it as a risk-mitigation strategy. Explain that the current process rewards velocity, which AI has made a poor signal for quality, and that this change helps you screen out candidates who create long-term technical debt that will slow down their team.
- Is this 'AI rockstar' problem limited to junior engineers?
- No. While juniors may lack the experience to spot the danger, senior engineers chasing speed or novelty can be just as susceptible. The issue is about mindset and habits, not just seniority.
- Does this mean we should stop valuing speed entirely?
- Not at all. The goal is to value 'sustainable speed'. The interview process should test a candidate's ability to deliver quickly without compromising the long-term health and maintainability of the codebase.
The Saiyō Briefing
Liked this? Get the next one in your inbox.
One short email every Thursday with hiring benchmarks, patterns and frameworks for technology leaders. Unsubscribe anytime.