HN Debrief

"Maybe later" was a feature

  • AI
  • Programming
  • Product
  • Developer Tools

The post says software teams used to get a free product filter from scarcity. Features sat in the backlog because building them was expensive, and that delay often revealed they were unnecessary. The claim is that AI coding removes that friction, so teams may lose a surprisingly valuable mechanism for avoiding waste, complexity, and bad bets.

Treat lower coding cost as a reason to raise your bar for product judgment, not lower it. If your team is using AI to prototype or ship faster, add explicit kill criteria, rollback plans, and a stronger review step before experiments harden into permanent surface area.

Discussion mood

Mostly agreeing and uneasy. People liked the post’s core point that friction used to act as a quality filter, and they worry AI coding is collapsing that filter so teams ship more junk, more quickly, and then get stuck maintaining it. The pushback was pragmatic rather than dismissive: some backlog items really are valuable and scarcity has long deferred important work.

Key insights

  1. 01

    Fast implementation delays the bad-idea signal

    Cheap generation changes when you discover a feature is wrong. Hand-building forces earlier contact with edge cases and awkward flows, while an LLM can hand you something convincing before you have really tested the premise. By the time the doubt shows up, the feature may already have grown dependencies that make removal harder than the original build.

    Do product review before integration, not after a demo works. Require a short failure-mode pass and a dependency check before any AI-built feature gets merged into a shared codebase.

      Attribution:
    • overgard #1 #2
  2. 02

    Prototype culture is leaking straight into production

    The sharper concern was not personal experimentation. It was that AI makes rough exploratory work look finished enough that companies skip the internal filter that used to separate a proof of concept from a shipped feature. Once nontechnical stakeholders can see something working, teams feel pressure to bless it, even when nobody has lived with it long enough to trust it.

    Create an explicit status between prototype and production, with usage limits and owner signoff. If stakeholders can try AI-built experiments, make the temporary nature impossible to miss.

      Attribution:
    • apsurd #1
    • hgoel #1
    • jaggederest #1
    • dbalatero #1
  3. 03

    Feature deletion does not scale cleanly

    The idea that cheaper building can be balanced by more aggressive unbuilding breaks down in products with real users. Mature software accumulates many niche features that each serve a different paying segment, so what looks like obvious bloat from the outside is often somebody’s critical workflow. That makes “we can always remove it later” a weak safety valve.

    Assume every shipped feature creates a future constituency. Before launch, decide what evidence would justify removal and whether you are actually willing to endure the customer fallout.

      Attribution:
    • patcon #1
    • Swizec #1
  4. 04

    Old disciplines still beat infinite backlog expansion

    What held up best here was not nostalgia for slower coding. It was simple process discipline. YAGNI, command-line-first workflows, and minimal feature slices all force teams to prove a need with the smallest possible artifact before they commit to a full product surface. AI does not replace that discipline. It makes the lack of it more expensive.

    Keep a thin-slice habit even when code is cheap. Ask for the smallest script, CLI, or internal-only version first, then expand only after real use changes your understanding.

      Attribution:
    • lowbloodsugar #1
    • block_dagger #1
    • skydhash #1
  5. 05

    No code and part-count reduction remain the right metric

    Several comments widened the point beyond software fashion. The best-performing system is often the one with fewer moving parts, whether you call that YAGNI, simplicity, or Design for Manufacturing part count reduction. AI may change the labor curve, but it does not change the physics of maintenance, security exposure, documentation drift, and operational complexity.

    Measure additions by the permanent surface area they create, not by the hours saved generating them. If a feature adds states, settings, or components, make that cost visible in planning.

      Attribution:
    • andai #1
    • gamerDude #1
    • oxag3n #1

Against the grain

  1. 01

    Scarcity also buried genuinely useful work

    Plenty of backlog items were not dead weight. Teams often deferred internal tooling, security hardening, and quality improvements that would have paid off for years. In that reading, “maybe later” was sometimes a failure mode of underinvestment, not a wise filter, and cheaper implementation could finally unlock work that should have happened long ago.

    Do not treat every old backlog item as validated non-demand. Revisit deferred items that reduce recurring toil, risk, or support load, especially the ones people keep working around manually.

      Attribution:
    • cortesoft #1
    • int_19h #1
    • chickensong #1
  2. 02

    More exploration can still find more winners

    Another pushback was that software, like writing or research, is partly a search problem. If AI lets teams cheaply explore more options and reject them after seeing them in action, the increase in volume may still raise the odds of discovering a genuinely strong feature. The key assumption is that curation remains intact and teams use working prototypes as a faster evaluation tool, not as an excuse to skip evaluation.

    If you lean into higher-volume experimentation, invest equally in curation. Put owners, review gates, and clear success metrics around the search process so more shots do not just become more clutter.

      Attribution:
    • staticshock #1
    • jaggederest #1
    • bartread #1
  3. 03

    Cheap code matters outside commercial product logic

    The post’s framing fits startups and SaaS products, but it misses a different class of software. Faster code generation can help domain experts build niche tools, passion projects, and noncommercial utilities that would never clear a normal ROI bar. That does not erase the need for taste, but it does change the value equation for software that exists to be useful or delightful rather than to be a clean product line.

    Use a different bar for internal tools and creative side projects than for customer-facing product features. The right question there is whether the tool creates value for its users, not whether it keeps the main product pristine.

      Attribution:
    • vegadw #1

In plain english

AI
Artificial intelligence, software techniques that let computers perform tasks like classification, prediction, or content analysis.
Design for Manufacturing
An engineering approach that simplifies a product so it is easier, cheaper, and more reliable to manufacture.
LLM
Large language model, a machine learning system trained on large amounts of text that can generate and analyze language and code.
ROI
Return on Investment, a measure of whether the savings or gains from an expense justify the upfront cost.
SaaS
Software as a Service, software delivered over the internet by subscription.
YAGNI
You Aren’t Gonna Need It, a software design rule that says you should not build functionality until there is a clear current need.