Does adding AI to your workflow actually make you faster? Frederick Van Brabant doesn't think so—and 329 other developers spent the weekend debating whether he's right.
In a post that accumulated 458 points on Hacker News, the software engineer laid out what he calls the hidden cost of AI adoption: the overhead it creates often exceeds the time it saves. "You need to learn the tool, verify its output, integrate it into your existing systems, and maintain the integrations," Van Brabant wrote on his blog. "All of that takes time, and that time is often not accounted for."
The argument strikes at the heart of a productivity narrative that has defined AI's corporate pitch for the past three years. Enterprise vendors have promised 40% efficiency gains. Consultants cite case studies of code completion reducing development cycles. But Van Brabant's contrarian take resonated precisely because it came from someone in the trenches—the 329 comment threads reveal a profession grappling with a more complicated reality.
Developers who agreed pointed to specific pain points. Prompt engineering, they argued, is real work that doesn't appear in traditional productivity metrics. The mental overhead of constantly evaluating AI-generated code—checking for security vulnerabilities, understanding unfamiliar approaches, debugging unexpected behavior—creates what one commenter called "cognitive tax." A junior developer might save five minutes generating a boilerplate function, only to spend twenty minutes debugging the result.
The other side pushed back with equally specific objections. AI advocates noted that Van Brabant was comparing optimized AI workflows against optimized manual workflows—a scenario that rarely exists in practice. "The baseline isn't a perfect developer working without AI," one commenter wrote. "It's a developer with AI versus a developer who has to Google every syntax question and read three Stack Overflow answers to write a regex." Some developers reported measuring their actual time savings with stopwatches, documenting 30-60 minute reductions on complex debugging tasks.
The disagreement reflects a deeper tension in how we measure software productivity. Lines of code, pull requests merged, and story points completed all fail to capture the quality of decisions made or the cognitive load sustained. When a developer uses AI to generate twenty variations of a database schema and then chooses the best one, has AI made them faster? Or has it just shifted the bottleneck from generation to evaluation?
Van Brabant acknowledged this complexity without offering a clean resolution. "I'm not saying AI is bad," he clarified. "I'm saying the conversation about productivity is more complicated than vendors make it sound." His post may have struck a nerve precisely because it named an anxiety many developers feel but rarely articulate: the suspicion that their AI-assisted workflow, for all its surface-level acceleration, has introduced a slower, more diffuse form of friction that metrics don't capture.
What happens next may depend less on the technology than on how organizations choose to measure it. If bonuses still flow for lines shipped and tickets closed, AI will continue to be adopted. If teams start tracking verification time, cognitive load, and integration maintenance as legitimate costs, the math on AI productivity may look different—and the vendors who promised 40% gains may face harder conversations in the next board meeting.