Tom Wojcik, a seasoned software engineer, recently published an essay that has resonated across developer communities — not because it hypes artificial intelligence, but because it does something rarer: it asks engineers to slow down and think about how much AI assistance is actually helpful. In a profession increasingly saturated with AI-powered coding tools, Wojcik’s argument is both timely and counterintuitive. The right amount of AI, he contends, is far less than most people assume, and finding that sweet spot requires a level of self-awareness that the tech industry rarely encourages.
Writing on his personal blog, Wojcik frames the challenge not as a binary choice between adopting AI wholesale or rejecting it entirely, but as a calibration problem. Engineers must determine where AI genuinely accelerates their work and where it introduces subtle but compounding costs — degraded understanding of their own codebases, false confidence in generated output, and an erosion of the deep thinking that distinguishes competent engineers from exceptional ones.
The Spectrum of AI Dependence Among Developers
Wojcik identifies a spectrum of AI usage among software professionals. On one end are engineers who refuse to engage with AI tools at all, viewing them as a threat to craftsmanship or simply too unreliable to trust. On the other end are developers who have become so dependent on tools like GitHub Copilot, ChatGPT, and Claude that they struggle to write meaningful code without them. Neither extreme, Wojcik argues, serves the engineer or their team well.
The more interesting — and more common — cases fall in between. Wojcik describes engineers who use AI for boilerplate generation, documentation drafting, and test scaffolding, but who maintain full ownership of architectural decisions and complex logic. This middle ground, he suggests, is where the highest-performing developers tend to operate. They treat AI as a junior pair programmer: useful for grunt work, but requiring constant supervision and never to be trusted with the steering wheel.
When AI Assistance Becomes a Crutch
One of the sharpest observations in Wojcik’s essay concerns what he calls the “understanding gap.” When an engineer accepts AI-generated code without fully comprehending it, they create a form of technical debt that doesn’t show up in any linter or code review tool. The code may work. It may even be elegant. But if the person responsible for maintaining it doesn’t understand why it works, the long-term costs can be severe — particularly when bugs surface months later in production environments where quick diagnosis matters.
This concern is not merely theoretical. A 2024 study by GitClear found that code churn — the percentage of lines that are reverted or updated shortly after being written — increased meaningfully in repositories where AI coding assistants were heavily used. The implication is that AI-generated code, while fast to produce, often requires more rework than code written by a human who understood the problem from the start. Wojcik references this dynamic directly, noting that speed of initial output is a poor proxy for overall productivity when maintenance costs are factored in.
The Cognitive Cost Nobody Talks About
Perhaps the most provocative section of Wojcik’s essay deals with cognitive atrophy. He draws an analogy to GPS navigation: most people can no longer find their way around their own cities without a phone, because the constant availability of turn-by-turn directions has eroded their spatial reasoning. Similarly, Wojcik warns that engineers who default to AI for every coding challenge risk losing the problem-solving muscles that define their professional value.
This is not an abstract concern for hiring managers. In recent months, multiple reports have surfaced about candidates performing poorly in technical interviews despite impressive portfolios — portfolios that, upon closer inspection, were heavily AI-assisted. A Bloomberg report detailed how companies including Amazon and Meta have revamped their interview processes specifically to detect candidates who have relied on AI tools to inflate their apparent skill level. The phenomenon Wojcik describes at the individual level is now manifesting as an industry-wide quality assurance problem.
Where AI Genuinely Earns Its Keep
Wojcik is careful not to position himself as an AI skeptic. He readily acknowledges domains where AI tools provide genuine, measurable value. Code translation — converting a function from Python to Rust, for example — is one area where AI excels because the task is well-defined and the output is easily verifiable. Similarly, generating unit tests for straightforward functions, drafting initial documentation, and explaining unfamiliar codebases are all tasks where AI assistance can save significant time without introducing the understanding gap he warns about.
The key distinction, as Wojcik frames it, is between tasks where the engineer remains the primary thinker and tasks where the AI becomes the primary thinker. When AI handles the mechanical translation of a well-understood intent, the engineer retains full comprehension and control. When AI is asked to solve a problem the engineer hasn’t fully formulated, the result may be functional code that nobody truly owns intellectually. This distinction — between AI as translator and AI as thinker — is the core of Wojcik’s framework for calibrating usage.
The Organizational Dimension: Team-Level Effects
Wojcik’s analysis extends beyond individual practice to team dynamics. He observes that when some team members use AI heavily and others don’t, code reviews become more fraught. Reviewers may struggle to assess AI-generated code that follows unfamiliar patterns or uses idioms that don’t match the team’s established style. Over time, this can fragment a codebase into sections that feel like they were written by different organizations — because, in a sense, they were.
This organizational concern has gained traction among engineering leaders. A recent discussion on Hacker News, prompted by Wojcik’s post, drew hundreds of comments from senior engineers and CTOs describing exactly this problem. Several noted that they had begun establishing explicit team policies around AI tool usage — not to ban the tools, but to set expectations about when AI-generated code is acceptable and when human-written code is required. The consensus that emerged was that teams need shared norms around AI usage just as they need shared norms around code style, testing practices, and deployment procedures.
A Framework for Individual Calibration
The most actionable section of Wojcik’s essay offers a simple heuristic for individual engineers: after using an AI tool to generate code, ask yourself whether you could have written the same code from scratch, given enough time. If the answer is yes, the AI saved you time without costing you understanding — a net positive. If the answer is no, you’ve introduced code you don’t fully own, and you should invest the time to understand it thoroughly before committing it. If you find yourself consistently answering no, Wojcik argues, you’ve crossed the line from augmentation into dependence.
This heuristic is deceptively simple but has profound implications for how engineers structure their workdays. It suggests that the right amount of AI is not a fixed quantity but a dynamic one, varying by task, by the engineer’s experience level, and by the criticality of the code being written. A senior engineer working on a well-understood CRUD endpoint might reasonably let AI do most of the typing. That same engineer, tackling a novel distributed systems problem, should probably keep AI at arm’s length until the core design is solid.
The Broader Question for the Software Profession
Wojcik’s essay arrives at a moment when the software industry is grappling with fundamental questions about the nature of engineering work in an age of increasingly capable AI. Companies are investing billions in AI coding tools, and the pressure on individual engineers to adopt them is immense. Productivity metrics, often measured in lines of code or pull requests per week, tend to reward AI adoption regardless of downstream quality effects.
But as Wojcik and a growing number of practitioners are pointing out, productivity measured at the point of code generation is only one variable in a much larger equation. The total cost of ownership of a piece of software includes debugging, maintenance, onboarding new team members, and adapting to changing requirements — all of which are harder when the original code was generated by a tool and accepted without deep understanding. The engineers and organizations that thrive in the coming years will likely be those that resist the temptation to maximize AI usage and instead optimize for the right amount — enough to eliminate drudgery, but not so much that it eliminates thinking.
Wojcik’s framework won’t satisfy those looking for a definitive answer to how much AI is too much. But that, arguably, is the point. The right calibration is personal, contextual, and constantly shifting. The only wrong answer is to never ask the question at all.
WebProNews is an iEntry Publication