Ask HN: AI productivity gains – do you fire devs or build better products?

Hacker News Discussion ↗

Economic framing: productivity vs profit

  • Several argue a 90% coding productivity gain does not imply 90% more profit; markets are bounded by TAM and user time (e.g., social media caps).
  • In some industries, higher productivity just shortens asset lifetimes and triggers cost/tax adjustments; analogies drawn to tech where user bases can’t double.
  • Layoffs are seen as a rational way to improve margins when growth is limited; AI provides a narrative cover to “lose weight” for shareholders.

Fire devs or build better products?

  • Many call this a false dichotomy: if a company is firing “to save a buck,” it’s often already past serious product improvement.
  • Some suggest firing anyone who doesn’t adopt AI; others counter that outcomes matter more than tool choice.
  • Layoffs won’t stop with devs: if fewer engineers are needed, fewer PMs and UX staff may also be required.
  • Public companies are expected to take short-term savings; smaller firms and co-ops may instead keep teams and use AI to outbuild incumbents.

Actual productivity gains with AI

  • Reports range from mild (AI as “Google on steroids,” 25–50% faster) to dramatic (half-sized teams moving ~4x faster, solo devs shipping in weeks).
  • Gains are largest for boilerplate, scaffolding, documentation, tests, refactors, exploration of unfamiliar stacks, and non-code tasks (email, spreadsheets, prototypes).
  • Several emphasize that planning, architecture, specs, and tight iteration loops are still done by humans; AI is likened to a very fast but sloppy junior.

Code quality, maintainability, and limits

  • Strong skepticism: many see AI output as unmaintainable, insecure, brittle, and overconfident, with tests that only validate its own code.
  • Common complaints: non-compiling code, missed edge cases, bad performance, poor architecture, “vibe-coded” messes that are hard to extend.
  • Others say they get better quality than from average devs by:
    • Writing detailed specs and dependency graphs first.
    • Incremental spec–implementation–evaluation loops.
    • Treating AI strictly as an assistant, not an autonomous coder.
  • Consensus that you still must review every change “like a junior dev,” especially for long-lived systems.

Where AI helps vs. hurts

  • Most agree AI is better for greenfield and throwaway/MVP work than for complex brownfield maintenance.
  • Some use it to tackle legacy tech debt and say it’s effective there; others find it weak on existing large codebases.
  • There’s concern that cheaper code just accelerates production of low-value or “bullshit” apps; code remains a liability that must be maintained.

Impact on roles, teams, and market

  • Seniors and strong architects appear to benefit most; junior/frontend-only roles are seen as especially vulnerable.
  • Some predict smaller, more focused teams (e.g., splitting 4 devs into 2+2 with clear remits) and more solo/small-team products.
  • Hardware and token limits are mentioned as a current bottleneck; unclear how this evolves.
  • Overall economic impact and failure/success rates of “vibecoded” startups are seen as unclear; commenters call for real longitudinal data.