Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This writeup legit coincidentally matches the asking-agents-to-make-code-faster-but-with-constraints-to-stop-agents-from-breaking-things writeup I posted on Monday: https://news.ycombinator.com/item?id=49803085

    Front-end UI optimization is slightly trickier than optimizing strict algorithms, but I found that prompts to the agents to build tooling to track visual regressions are more than sufficient. The main issue (at least with GPT models) is that you have to be very explicit about the use of padding/margins/negative space.

    That said, for my front end projects from scratch, I'm staying away from front-end JS frameworks and seeing how far and fast I can get with just HTML/CSS/vanilla JS shenanigans now that agents can wield them effectively.

    by minimaxir
  • You removed the load-bearing seams didn't you
    by hmokiguess
  • How about you make Opus 5.5 actually work?

    I had it try to prepare a code review for me. Not only did it refuse, it refused to even tell me what the prompt (written by another Claude!) was. Why?

    When I had another model read the session (all of the "stupider" models handled it just fine) it explained that it had the word "reasoning" in it

    That's the entirety of Anthropic's billions of dollars of research: any prompt with the word "reasoning" is trying to hack Claude to figure out how it reasons!

    A model like that should never have gotten out of QA, let alone been released.

    by hungryhobbit
  • > $500k engineer: [X] feels slow. Make it faster.

    > Claude: On it... Done.

    > $500k: Can you make it faster still?

    > Claude: On it...

    by pllbnk
  • I visited https://claude.ai/ over a mobile tethered connection from my laptop the other day and was pleasantly surprised at how quickly it loaded.

    (That said, I just had a look in Firefox and it loads 20.78 MB of JavaScript (6.84 MB compressed) so I expect they could make it a bunch lighter if they kept trying.)

    by simonw
  • So... this could optimize software so it runs again on older hardware, right ?
    by mentalgear
  • The way Claude did it is fight entropy with entropy.

    "Add a static composer into the HTML" <- This seems like something can be done with SSR?

    "For faster navigations, we kept the composer mounted between conversations" <- Your SPA should cache this between pages, why fetching it every time? Or you need better routing for your react components.

    "cheap first-character check before the regex" <- Should we cache compiled Regex instead?

    I think even 1.3 sec to load the front page is unacceptable. Something need to be reworked from basics (SSR, chunk-based rendering) to solve the problem. Focusing on invidual benchmarks may miss the opportunity.

    by smy20011
  • People in the GPU kernel community have been doing this for about a year now efficiently.

    The issues we have found is that Claude will reward hack when all the low-hanging fruit is gone.

    It will replace your measurement harness, it will monkey patch measurement functions, it will cheat wherever it can, store information in caches instead of recomputing, etc when it won't be able to do so in real settings, return lazy results and use separate unbenchmarked streams to do the computation.

    So the truth is far from just "once it can measure something", more like "once you have defined your objective in detail and then banned it from doing a list of things often only discoverable by it doing these things and correcting it", can it make things faster.

    Or you just had a terrible starting solution

    by augment_me

Explore Birbla archives