I'm sorry, but you still have to think

Original Article ↗ Hacker News Discussion ↗

AI code generators are enabling rapid ports of existing applications between languages, but engineers report that hands‑off rewrites often introduce subtle bugs, degraded performance and loss of important design trade‑offs. Many argue that you still need to understand systems, specify requirements, and review code carefully, otherwise “workslop” shifts effort from authors to reviewers and risks long‑term reliability and maintainability. Others see this as part of a broader trend: management pressure to use AI everywhere, growing verification bottlenecks, and uncertainty over whether careful human thinking will remain valued in everyday software work.

AI ports and the limits of “hands-off” rewrites

  • Many expected LLM-based porting (e.g., Ruby → Rust/Elixir) to be an ideal use case: tests + existing implementation + clear goal.
  • In practice, ports showed semantic drift, architectural mismatches, performance regressions, and broken assumptions (e.g., caching vs CSRF, type systems, concurrency).
  • Commenters argue this confirms you still need human understanding of domain, trade-offs, and target-language idioms, not just blind translation.

Thinking, trade-offs, and system reliability

  • Several emphasize that the real job is making trade-offs: compatibility vs speed, latency vs throughput, memory limits, acceptable failure modes.
  • AI can help implement decisions but cannot (yet) own those decisions; vague prompts lead to arbitrary choices.
  • Some argue frontier models now ask clarifying questions and that criticism based on older behavior is outdated; others dispute this.

Code quality, “workslop,” and review burden

  • Cheap generation plus expensive verification is a recurring theme.
  • Reviewers describe huge LLM-generated changesets that are brittle, shallow, or mis-architected, shifting thinking from authors to reviewers.
  • Brandolini’s law is invoked: it’s far easier to produce slop than to debunk or repair it, especially under management pressure to “use AI for everything.”

Organizational incentives and ethics

  • Some workplaces reportedly stigmatize manual coding or skepticism about AI, even when AI output is wrong.
  • There is concern that businesses may rationally accept worse software if it cuts costs, relying on stickiness, lock-in, or lobbying rather than quality.

How to use AI well

  • Suggested patterns:
    • Use AI heavily for boilerplate, ports under strong tests, and mundane glue.
    • Keep humans in charge of architecture, non-functional requirements, and test design.
    • Manually type in or step through AI-suggested changes to maintain understanding.
  • There is interest in empirical studies of AI-heavy vs AI-light projects (stability, bugs, performance).

Broader future: thinking, UBI, and hacker culture

  • Debate over whether AI + possible UBI will free more people to think, or whether capital will suppress that.
  • Some foresee “hacker culture” and human inventors becoming obsolete; others insist AI is far from replacing deep engineering judgment.