Your job is to deliver code you have proven to work

Original Article ↗ Hacker News Discussion ↗

Role of the Engineer: Code vs Business Outcomes

  • Some argue the job isn’t to “deliver proven code” but to solve customer/business problems; sometimes the best solution is no code, or imperfect code that’s “good enough.”
  • Others counter that “working” must mean working in the real world (production), not just on a laptop or in CI, and that includes preventing regressions.
  • Several comments add that “works” must also cover security, maintainability, readability, and fit with existing patterns, not just passing tests.

What “Proven to Work” Means

  • “Proof” is seen as misleading: most real systems can’t be strictly proven; tests only demonstrate behavior for sampled cases.
  • Some emphasize reasoning about code and edge cases, not just green test suites. Property-based testing and strong type systems help but don’t eliminate the need for judgment.
  • There’s debate whether a large, well‑curated test suite (like HTML5 parser tests) is “enough proof” vs still only partial coverage.

Manual vs Automated Testing

  • Many favor automated, repeatable tests (often TDD/“spec as tests”) as the primary proof, with manual testing as a final sanity/UX check.
  • Others stress that manual, end‑to‑end checks regularly catch obvious issues tests missed (layout problems, unusable flows, mis-specified requirements).
  • Several note you should see a test fail first to ensure it actually exercises the right behavior.

LLMs, “Vibe Coding”, and Giant PRs

  • Multiple reports of LLM‑assisted developers submitting huge, untested PRs they don’t understand, implicitly offloading verification to reviewers. This is seen as rude and politically dangerous.
  • It’s not just juniors; weak seniors and even non‑devs do this, with managers sometimes rewarding raw LOC or speed.
  • Maintainers describe AI PRs that “smell” wrong: dead code, unused functions, parallel abstractions, minimal or bogus tests.
  • Some teams now treat obviously LLM‑generated PRs as near‑spam unless the author clearly owns, understands, and tests the changes.

Code Review, PR Practice, and Team Culture

  • Strong emphasis on good PR hygiene: concise problem description, what changed and why, explicit test steps, plus screenshots/video for UI changes.
  • Small, focused PRs are preferred; 10k–50k line AI PRs are considered unreviewable and often rejected outright.
  • Code review is widely seen as under‑incentivized “unfunded mandate”; some experiment with AI reviewers as first pass, but still rely on human judgment.

Accountability and Limits of Automation

  • A recurring theme: tools (CI, LLMs, agents) can help verification but cannot be held accountable; responsibility ultimately falls on humans configuring and approving changes.
  • Some fear AI plus bad incentives will further erode craftsmanship; others think the profession will shift toward specification, testing, and architecture rather than hand‑coding.