Zendoric
← Back to the day · June 28, 2026

When AI codes for you: the productivity dilemma that erodes technical knowledge

🕒 Published on Zendoric: June 28, 2026 · 09:00

Bindu Reddy, CEO of Abacus AI, warns that developers are losing basic skills from over-relying on AI assistants. An Anthropic study quantifies the problem: 17% less code comprehension. The question no one wants to answer is who will fix what AI breaks.

By Zendoric · June 28, 2026.

Bindu Reddy is no ordinary voice in the artificial intelligence ecosystem. As CEO of Abacus AI and one of the most recognized figures in the development of autonomous agents, her warnings carry technical weight and industrial credibility. That is why it is striking that she chose X to raise an uncomfortable alarm: in her own team's technical interviews, candidates appear increasingly disconnected from real coding. These are not isolated cases. According to Reddy, the pattern is systematic: developers who have internalized the AI-assisted workflow to the point of having lost the autonomous judgment to solve problems from scratch.

The phenomenon she describes already has a name in the sector: *vibe coding*, a way of programming driven mainly by prompts where the developer acts more as an orchestra conductor than as a musician. The promise is evident: speed, automation of the repetitive, less friction. The cost, less visible but cumulative, is the atrophy of skills that go unexercised: writing code by hand, bottom-up logical analysis, methodical debugging. These are precisely the capabilities that make the difference when something fails in ways the AI did not anticipate.

What turns Reddy's warning into something more than opinion is that there is data to back it up. According to an Anthropic study cited in the article, developers who worked with AI assistance completed tasks faster but scored 17% lower on tests of immediate code comprehension. The nuance is important: it is not that the AI does the technical work badly, but that it can do it so well that the programmer stops actively processing what is happening. Comprehension becomes optional in the short term, and dangerous in the long run.

This is not a new debate. Linus Torvalds, creator of the Linux kernel, has expressed similar concerns about tools like GitHub Copilot, pointing out that soundness of judgment and problem-solving ability —what makes an engineer truly valuable— are being diluted among those who learn to program with assistants from day one. The argument is not technophobic: it is structural. If a generation of developers' knowledge base is built on the assumption that there will always be a functioning AI available, what happens when that AI generates a complex error, degrades or is simply unavailable?

The question Reddy raises and that no one in the industry has answered satisfactorily is just that: who is going to fix it if the AI breaks everything? Automated systems do not fail in simple ways. When they fail, they do so by generating diffuse problems, errors of opaque logic, hard-to-trace emergent behaviors. Diagnosing and resolving that kind of breakdown requires exactly the type of deep analytical thinking that atrophies with the uncritical use of assistants.

As sector context, it is worth recalling that this tension is not exclusive to programming. Medicine, law and engineering have debated for decades the extent to which automating cognitive tasks improves professionals or makes them fragile in situations that go off-script. The difference in the case of software is the speed of change and the centrality of the technology itself: if the engineers who maintain global digital infrastructure lose technical depth, the systemic impact is not hypothetical.

Reddy's position, and the one that emerges from the Anthropic study, is not a rejection of AI tools. The thesis is more nuanced: AI as a productivity lever is legitimate and powerful, but it demands deliberate, not passive, pedagogical integration. That means that training environments —universities, bootcamps, engineering teams— have to actively design spaces where developers exercise critical thinking without a safety net. Not out of nostalgia for hand-written code, but as a vaccine against cognitive fragility.

What is at stake is not whether programmers should use AI —they are going to, and rightly so— but whether the tech industry is being honest enough about the side effects of frictionless adoption. Reddy, from a position that makes her especially credible in this debate, chooses to be. That, in itself, is a relevant fact.

Sources & references