AI Engineering5 min read

AI Coding Tools Are Overhyped—Here's What Builders Should Do

Innotech Development

A sharp critique is making the rounds in the developer community this week. Andrew Kelley, the creator of the Zig programming language, has publicly challenged the narrative that AI coding assistants are revolutionizing software development overnight—and called out Anthropic's marketing claims in the process. The response from builders and engineers has been resounding agreement, and that should tell founders something important about the state of AI-assisted development in 2025.

This isn't just an inside-baseball debate among language designers. It cuts to the heart of a question every founder building a software product needs to answer: how much of the AI productivity story is real, and how much is smoke?

The Gap Between AI Marketing and Engineering Reality

The core tension here is familiar to anyone who has shipped production software with LLM-assisted tools. AI coding assistants—whether Claude, Copilot, Cursor, or others—are genuinely useful in certain contexts. They can accelerate boilerplate generation, help explore unfamiliar APIs, and serve as a decent rubber duck for experienced developers. Nobody serious is arguing these tools are worthless.

But there's a growing disconnect between how AI companies market these capabilities and what professional engineers experience daily. Claims about massive productivity multipliers—10x, even 100x—rarely survive contact with complex, real-world codebases. When someone like Kelley, who has spent years building a systems programming language from scratch, says the emperor has fewer clothes than advertised, it carries weight. He's not a skeptic by disposition; he's a practitioner who knows what building hard software actually demands.

The problem isn't that AI tools don't help. The problem is that overstating their capabilities leads to bad decisions—particularly among non-technical founders and investors who take marketing claims at face value and build plans around inflated assumptions.

Why This Matters for Founders Right Now

If you're a VC-backed founder planning your next product sprint, the AI coding hype cycle creates a specific set of risks:

  • **Underestimating engineering complexity.** If you believe AI tools make every developer 10x more productive, you'll understaff your team and set impossible timelines. When reality hits, you burn runway and trust.
  • **Over-relying on generated code without review.** LLMs produce plausible-looking code that can contain subtle bugs, security vulnerabilities, and architectural debt. Without experienced engineers reviewing and guiding that output, you accumulate risk invisibly.
  • **Chasing tool hype instead of product outcomes.** Swapping tools every quarter because a new AI assistant promises breakthroughs is a distraction. What matters is whether your team can ship reliable software that solves real problems for users.
  • **Confusing demo-quality output with production-quality systems.** AI tools excel at generating impressive demos. Turning those demos into scalable, maintainable, secure production systems is an entirely different discipline.
The most dangerous outcome of AI coding hype isn't that founders adopt bad tools—it's that they adopt unrealistic expectations about what it takes to build production software.

What Experienced Teams Actually Do With AI

At IDG, we use AI tools extensively in our development workflow. We'd be foolish not to—they're genuinely useful when applied correctly. But we treat them as accelerants, not replacements, for engineering judgment. The distinction matters enormously.

Here's what responsible AI-assisted development looks like in practice:

  • **AI handles the low-leverage work.** Generating test scaffolding, writing documentation drafts, converting between data formats, exploring API surface areas—these are tasks where LLMs save real time without introducing unacceptable risk.
  • **Senior engineers remain in the loop on architecture.** No AI tool today can reliably reason about system-level tradeoffs: how a new service will behave under load, where to draw module boundaries, how to design for future extensibility. These decisions still require human expertise and context.
  • **Code review standards don't change.** AI-generated code gets the same scrutiny as human-written code—arguably more, because LLMs have predictable failure modes that experienced reviewers learn to spot.
  • **Productivity gains are real but honest.** We see meaningful speedups in certain phases of development, particularly early prototyping and repetitive implementation tasks. We don't see 10x across the board, and we don't promise that to our clients.

The Founder's Playbook: Cutting Through the Noise

So what should you actually do with all of this? If you're building a product—especially an AI-native one—the right posture isn't cynicism or blind enthusiasm. It's informed pragmatism.

  1. **Staff for reality, not marketing slides.** Your engineering team's productivity should be estimated based on the actual complexity of your product, not on hypothetical AI multipliers. Plan your runway and timelines accordingly.
  2. **Invest in engineering leadership.** AI tools amplify the gap between strong and weak engineering teams. A senior architect using AI assistance is dramatically more effective than a junior developer using the same tools unsupervised. The human expertise layer is more important than ever.
  3. **Evaluate tools by output quality, not hype.** If an AI coding tool helps your team ship better software faster, use it. If it generates code that requires extensive rework, it's not saving you anything. Measure outcomes, not vibes.
  4. **Partner with teams that know the difference.** The most valuable development partners right now are the ones who use AI tools effectively while being honest about their limitations. If someone promises you AI will halve your development timeline with no tradeoffs, run.

The Signal Underneath the Noise

Episodes like this—where respected builders push back on inflated claims—are healthy for the industry. They recalibrate expectations and force more honest conversations about what AI tools can and can't do today. And crucially, the people pushing back aren't anti-AI. They're pro-honesty. There's a big difference.

For founders, the takeaway is straightforward: AI coding tools are a genuine part of the modern development stack, but they don't eliminate the need for strong engineering teams, thoughtful architecture, and realistic planning. The companies that win will be the ones that use these tools wisely—not the ones that believe the marketing most enthusiastically.

We've seen this firsthand across the products we've built for startups and enterprises alike. The AI tooling landscape will keep evolving rapidly, and separating signal from noise is increasingly a core competency for any product team.

If you're navigating these decisions for your own product—figuring out where AI fits, how to staff your team, or how to build something that actually scales—we'd love to talk. It's the kind of problem we solve every day.

Frequently asked questions

Are AI coding tools actually making developers more productive?
Yes, but the gains are more modest and context-dependent than marketing claims suggest. AI tools meaningfully accelerate boilerplate generation, prototyping, and routine tasks, but they don't replace the need for experienced engineers to handle architecture, code review, and complex problem-solving. Real-world productivity improvements are incremental, not the 10x multipliers often advertised.
Should startups reduce engineering team size because of AI coding assistants?
No. Understaffing based on inflated AI productivity assumptions is one of the biggest risks founders face right now. AI tools amplify the effectiveness of skilled engineers but don't replace them. Startups should plan team size based on actual product complexity and realistic timelines, not hypothetical AI-driven efficiencies.
How should founders evaluate AI development tools for their teams?
Focus on measurable output quality rather than hype. Track whether a tool actually reduces rework, improves code quality, and speeds up shipping timelines in your specific codebase and domain. Tools that generate impressive demos but require extensive cleanup in production aren't delivering real value. Let your engineering team evaluate tools against real-world tasks.
What are the risks of over-relying on AI-generated code?
AI-generated code can contain subtle bugs, security vulnerabilities, and architectural patterns that create long-term technical debt. Without experienced engineers reviewing and guiding LLM output, these issues accumulate invisibly and can become expensive to fix later. The key risk is that AI-generated code looks correct on the surface while hiding problems that only emerge at scale or under edge cases.

Inspired by industry news. Read the original story.

Building something ambitious?

We help founders turn ideas into products that ship and scale. Let's talk about what you're building.

Schedule a call