What Everyone is Getting Wrong About AI and Productivity!

The technology industry is currently gripped by an aggressive push toward AI integration. Regardless of whether a firm is product-based or service-based, there is a top-down mandate - from junior developers to VPs - to adopt AI at every level of the lifecycle. While the motivation is efficiency, we must examine if this momentum is premature. Speaking strictly as an engineer within a product-based firm (and representing my own views, not those of my employer), I believe we are overlooking a critical cost.

AI is undeniably capable of generating boilerplate code and unit tests. However, it falters significantly when confronted with "deep-core" system infrastructure. When a high-severity production issue strikes, AI cannot traverse thousands of lines of legacy logic to identify a nuanced root cause.

Historically, humans solved these deep engineering problems through the act of writing code manually and digging through the details of the systems. Coding is not merely a task of completion; it is a cognitive stimulant. It demands low-dopamine, high-effort concentration that keeps the brain agile. Debugging, refactoring, and redesigning systems from scratch are the very activities that grant an engineer "ownership" and mastery over a codebase.

With AI, the requirement for ownership is being replaced by high-level abstraction. Engineers lack the granular knowledge required for expert-level debugging. AI is a lamp in one's hand, but if one is heading in the wrong direction, a lamp will not help them navigate out of a tunnel.

Unlike previous generational shifts where humans adapted to stay ahead of the curve, AI is actively outsmarting the user in a way that encourages cognitive atrophy. As we outsource the "hard tasks" to models, our collective competence to handle complexity diminishes.

Promoters claim massive time savings, but I would argue that AI saves, at most, 20% of an engineer's time. The author must still verify the AI’s output for consistency and correctness - a task that is often more tedious than writing the code originally. Furthermore, over 50% of development time is spent reaching a consensus with peers. We are now entering a bizarre reality where AI writes the code and AI reviewers critique it. I have personally received pushback from authors citing AI-generated arguments that are difficult to refute because they are grounded in synthetic logic rather than lived experience.

This extends to documentation, which has become a repository for "garbage". We are seeing an influx of verbose, grammatically inconsistent, and elongated content. This "garbage in, garbage out" cycle feeds back into the models, creating a churn of insufferable content. Design documents have become so wordy that the core architectural intent is lost.

Let’s put all this into perspective using Objectives and Key Results (OKRs). Even if we assume 20% increase in delivery speed, we must account for the fact that roughly 90% of technical projects are eventually scrapped or pivoted. If AI makes us 20% faster on projects that only have a 10% survival rate, the actual efficiency gain is a negligible 2%.

The cost of this 2% gain is the "mundanity cycle". We are risking a future where AGI is achieved not because machines became significantly smarter, but because humans lost the capacity to think critically.

My stance is clear: If AI only saves a marginal amount of time at the cost of critical thinking, we should reconsider its necessity. Saving two hours in an eight-hour day is not worth the loss of technical mastery. To corporations: Stop tracking AI usage as a metric. It is a form of micromanagement that mirrors forcing a developer to use IntelliJ regardless of their preference to use Vim. Measure productivity by the achievement of OKRs - not by how much an engineer relies on a digital crutch.