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

Hacker News Discussion ↗

Claims that AI can boost developer productivity by up to 90% are triggering debate over whether companies should use those gains to cut headcount or to build more and better products. Many engineers report real speedups in boilerplate and greenfield work, but emphasize heavy oversight, weak results in complex or long-lived systems, and unclear long‑term economic impact. Skeptics argue that short‑term layoff-driven margin gains and “vibecoded” apps may backfire, while others see a window for smaller, focused teams and startups to out‑iterate incumbents that treat AI primarily as a cost-cutting tool.

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.