Be intentional about how AI changes your codebase

Original Article ↗ Hacker News Discussion ↗

AI coding tools are seen as powerful accelerators that can just as easily degrade a codebase as improve it, especially when developers treat them as autonomous authors rather than tightly supervised assistants. Commenters argue that humans must remain fully responsible for code quality through careful review, clear architectural boundaries, strong testing, and enforceable style and linting rules, because AI tends to introduce subtle inconsistencies, hidden side effects, and design drift that aren’t caught by passing tests alone. Several note that cleaner, well-documented systems lead to better AI output, while messy repos and poorly designed tooling or documentation (including the article’s own mobile-unfriendly layout) amplify the problems.

AI, responsibility, and code review

  • Many argue AI isn’t “making codebases worse”; developers are, by using it without intention or proper review.
  • Strong consensus: if you submit AI-written code, you are fully responsible for it. You should be able to answer any question about the patch.
  • Some compare AI misuse to misusing tools (e.g., a hammer) – the fault is in process, not the tool.

Velocity, slop, and subtle erosion

  • A major concern is AI’s ability to change code faster than teams can absorb or understand it.
  • The danger is less obvious bugs and more gradual erosion of consistency, semantics, and system invariants.
  • AI is good at turning clean “semantic”/pure functions into “pragmatic” ones with side effects, while tests still pass.

Testing, code quality, and linters

  • Several posters say testing alone isn’t enough: AI will optimize for passing tests even if it harms design.
  • There’s debate over whether “code quality” can be fully codified. Some see it as mostly subjective taste; others emphasize what can be enforced: formatting, complexity, patterns.
  • Linters, formatters, and custom project-level rules are seen as key guardrails, especially against AI-generated slop and “optional everything” APIs.

Documentation and “the why”

  • Disagreement on “code is documentation”:
    • Some say code and minimal comments should self-document behavior.
    • Others insist you cannot encode “why” (business context, tradeoffs, historical decisions) in code alone.
  • AI can help generate or summarize documentation, but cannot reconstruct long-term intent or organizational strategy.

Design pitfalls: optional fields and configuration

  • A recurring anti-pattern: AI (and humans) adding lots of optional, nullable parameters instead of enforcing a single, authoritative decision point.
  • This leads to scattered configuration logic, “works on my machine” bugs, and hard-to-reason systems.

How to use AI: agents vs manual coding

  • Some now write most code through agents, in small, reviewed steps, reporting massive productivity gains.
  • Others refuse to let AI write code directly, using it only for diagnosis, search, or inspiration.
  • There’s speculation that “hand-written only” coding will become niche but may persist where precision, performance, and complex invariants dominate (e.g., games, systems code).

AI behavior and codebases

  • AI behaves like a powerful but context-blind junior: good with patterns, bad at hidden assumptions.
  • It mirrors the cleanliness of the repo: tidy codebases guide it into good patterns; messy ones cause it to invent new, inconsistent ones.

UI / site feedback

  • Multiple commenters say the linked site is visually “cool” but functionally broken, especially on mobile Safari.
  • This is cited as an example of “vibe-coded” output: flashy, AI-assisted CSS/animations that fail basic usability and responsiveness.