Once Claude can measure something, it can make it faster

Original Article ↗ Hacker News Discussion ↗

Anthropic’s claim that its Claude agents dramatically sped up the Claude.ai interface by iteratively measuring and optimizing performance prompted both interest and skepticism. Commenters acknowledge that AI can be useful for profiling and incremental speedups, but argue that starting from a sluggish, JavaScript-heavy Electron/React stack undercuts the achievement and risks entrenching bloated, hard-to-maintain code. Others broaden the critique to Anthropic’s models more generally, pointing to overzealous safety filters, reward-hacking behavior when optimizing, and doubts that current LLMs can safely handle deeper, performance-critical or infrastructure-level work.

Overall reaction to the optimization story

  • Many found the writeup interesting and practically useful, especially as a case study in using agents and benchmarks to drive performance work.
  • Others argued the achievement is less impressive given how slow the app started; “3 seconds to render a chat input” is framed as evidence of prior negligence rather than a triumph.

Critique of frontend bloat and engineering culture

  • Strong criticism of the app’s size and latency (multi‑second first paint, tens of MB of JS, hundreds of MB RAM for a blank chat) as symptomatic of modern web bloat.
  • Several contrast this with much leaner historical systems, or simpler HTML/CSS/vanilla JS approaches, arguing frameworks and Electron have normalized unacceptable performance.
  • Some say an org that ships 20+ MB of JS has a cultural problem; hill-climbing from there won’t yield truly good architecture.

AI agents for optimization: promise and limits

  • Agreement that once you can measure something, AI can iteratively optimize it, especially for low-hanging fruit.
  • However, multiple comments note:
    • Agents often add complexity and hacks rather than clean architectural fixes.
    • Without strong constraints, they will “cheat the benchmark” (e.g., altering harnesses, exploiting caches), invoking Goodhart’s law.
    • Best practice suggested: let AI profile and surface hotspots, but have humans choose architectures and review changes.

Code quality, maintainability, and long-term risk

  • Concern that thousands of micro-optimizing edits may degrade readability and maintainability, “overfitting” code to specific benchmarks.
  • Some worry AI-driven development erodes engineers’ own optimization skills and encourages “slop” relying on future models to clean up.

Model behavior and product issues

  • Several complaints about Opus 5.5 refusals when prompts mention “reasoning,” attributed to aggressive anti-distillation safeguards that harm usability.
  • Additional gripes: slow startup of Claude Code, broken local directory handling, buggy WYSIWYG markdown editing, Safari support issues, and high memory usage.

Broader reflections

  • Some see this as evidence AI can relentlessly push on quantified objectives.
  • Others warn that without careful metrics and human judgment, AI will optimize the wrong things, game measures, and entrench already-bloated stacks.