I'm tired of fixing customers' AI generated code

Original Article ↗ Hacker News Discussion ↗

Developers offering APIs and SaaS tools report being overwhelmed by support requests stemming from AI‑generated code that misuses endpoints, invents properties, or reflects a lack of basic programming understanding. Commenters argue that large language models have dramatically increased the volume and speed of low‑quality code, turning what used to be rare “free consulting” requests into a constant drain, while also creating a potential niche for paid services that specialize in fixing AI‑written applications. Proposed responses range from stricter support boundaries and paid tiers, to better docs, SDKs, and even AI‑powered support bots or “LLM‑friendly” API design to reduce hallucination‑driven errors.

Scope of the problem: AI‑generated client code

  • Many API users now arrive with code written by LLMs that:
    • Call non‑existent endpoints or fields hallucinated by the model.
    • Ignore rate limits, error handling, and basic HTTP concepts.
  • This creates expectation that the API provider will debug or even design the entire app for free.
  • Several commenters note this isn’t fundamentally new (stack‑overflow copy/paste, script kiddies), but AI massively increases the volume and speed of low‑quality code.

Causes: low skills + “just make a thing” mindset

  • People want to build products, not learn programming; AI appears to let them skip fundamentals.
  • Some see this as an extension of junior devs with buzzwords but little depth.
  • Others argue self‑teaching takes substantial time; a “week to learn programming” is unrealistic for most.
  • There’s concern that reliance on AI erodes understanding and makes debugging much harder.

Proposed coping strategies for API providers

  • Improve self‑service:
    • Strong docs, OpenAPI specs, generated SDKs, minimal “hello world” examples in popular languages.
    • Public FAQs and support articles targeting common AI‑induced mistakes.
  • Change support model:
    • Explicitly limit free support; add paid tiers, “developer”/enterprise support, or “no support” positioning.
    • Fire or filter high‑maintenance customers; set clear boundaries early.
    • Build a community forum so other users can help for free.
  • Offload work:
    • Partner with consultants or freelancers specializing in fixing AI‑generated apps.
    • Some see a “gold mine” market in rescuing these projects.

“Use AI to fix AI” ideas

  • Suggestions include:
    • A support bot/agent grounded strictly in the API docs to detect invalid endpoints/fields and propose corrections.
    • LLMs to triage, auto‑respond, or prioritize tickets.
    • Using hallucinated endpoints as signals for missing or confusing API design (“hallucination‑based API design”).
  • Skeptics note that:
    • LLMs also hallucinate and can get stuck in loops without a knowledgeable human guiding them.
    • Scale of low‑quality code/content may become unmanageable.

Broader views on AI and coding

  • Many see AI as:
    • Good for speeding up typing, boilerplate, and simple bug hunting.
    • Dangerous when used as a substitute for understanding or for full app design.
  • Review burden rises: it’s harder to vet large, incoherent AI‑written patches; some fear “AI reviewing AI” is misguided.
  • Others think, as with ATMs and cloud, AI will create new jobs: cleaning up, hardening, and extending AI‑generated prototypes.