Everything I built with Claude Artifacts this week

Original Article ↗ Hacker News Discussion ↗

AI coding assistants like Claude’s new “Artifacts” feature are enabling people to spin up small, single‑page web tools in minutes by having the model generate complete HTML/JS apps. Commenters are split on how meaningful this is: some see a genuine productivity leap for one‑off scripts, ETL tasks, and small greenfield projects, while others argue that integrating LLM‑generated code into large, long‑lived codebases remains slow, unreliable, and often not worth the overhead. Across examples and counter‑examples, a recurring theme is that today’s models excel at boilerplate, scripting, and translation with tight prompts and human review, but still struggle with complex, strongly typed, or highly contextual systems—raising open questions about how far and how fast they will change professional software engineering.

Overall reaction to the artifacts

  • Many see the examples as simple “toy apps” (QR readers, YAML→JSON, URL extractors) that any web dev could write quickly without an LLM.
  • Others argue that the key change is how fast such tools can now be built (often in minutes), making things worth building that previously weren’t worth an hour of effort.
  • Some express fatigue with yet another demo of small web utilities amid a perceived “AI glut”.

Usefulness of LLMs for coding

  • Clear divide:
    • Enthusiasts say LLMs are a big productivity boost for scripting, glue code, one‑off utilities, ETL, research tooling, and small web apps.
    • Skeptics say they’re of little use on complex, long‑lived systems and often slower than just coding or googling.
  • Several non‑experts and researchers report 10–20x gains for small Python/shell/SQL tasks.
  • Multiple people describe building entire small apps or CLIs with ~5–10% manual coding and iterative LLM refinement.

Integration with large or complex codebases

  • People working on very large monorepos (tens of millions of LOC) say current tools can’t realistically “understand” the whole codebase; at best they help on small, localized changes.
  • Tools like Cursor, Aider, VS Code extensions, and “projects” with large context windows are cited as partial solutions, but still require careful scoping and human guidance.
  • Strongly typed or niche languages (Scala, Haskell, Rust with advanced types) are reported as much harder for LLMs to handle correctly.

Code quality, reliability, and prompting

  • Recurrent reports of:
    • Compiling but incorrect code, subtle bugs, non‑idiomatic style, and over‑complex solutions.
    • Models looping on wrong fixes or rewriting too much, deleting comments, or making unnecessary changes.
  • Supporters counter that:
    • You must treat the LLM as a junior dev: give precise specs, break work into small steps, review everything, and often paste in relevant files.
    • LLM‑written tests plus human review can mitigate many issues.
  • Some criticize “prompt hacks” (e.g., “I’ll tip you for good work”) as superstition; others cite papers showing small gains.

Broader concerns and optimism

  • Worries about:
    • Over‑reliance on plausibly wrong outputs (“false knowledge”), long‑term erosion of skills, and bad code entering production.
    • Hype outpacing real capabilities, especially for non‑trivial business logic and integration.
  • Optimists expect:
    • Fewer hours spent on boilerplate, more on design/architecture.
    • Expanded demand for custom software as development gets cheaper, not necessarily fewer developer jobs, but changed roles.