Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When AI Builds Itself: Our progress toward recursive self-improvement

anthropic.com

Post reply on HN
Print view View original

431–440 of 738 posts

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#431

Post by fc417fc802 »

lukan wrote: post #196
aleqs wrote: post #75

Earlier quoted context omitted.

They can't even seem to get their usage metering consistent.

You mean on some days it goes faster and some other days slower? That is by design. It depends on how much other people are using their services right now and they do communicate it somewhere in the TOS that they do this. Otherwise they could give us a fixed amount of tokens - but they don't because it is not fixed.

If they implement demand pricing then they should be transparent about the current rate at any given time.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#432

Post by steve_adams_86 »

throwway120385 wrote: post #358
mapBasketWand wrote: post #333

Earlier quoted context omitted.

I love the idea of installing high resolution cameras in the fridge to monitor the ice maker to feed into a vision model that renders digital ice to the exact position of the real ice on the fridge’s giant screen

Or you could... open the door and look inside.

Sounds like you've got a lot of time on your hands

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#433

Post by solid_fuel »

fc417fc802 wrote: post #423
qwery wrote: post #240

Earlier quoted context omitted.

~ "it's not a TUI! and my dad works at Nintendo" curses, bud. curses. It's genuinely difficult to tell how much of this is true. The post is obviously 100% posturing, but some of the words describe things that could be done. Very few game engines do anything I'd describe as rasterisation. That's kind of the point of a GPU. Well, it used to be. I suppose "small game engines" might be more likely on average to include…

Your broader point is well taken but I thought I'd stop by with some trivia. High end engines such as unreal will rasterize absurd quantities of micro-geometry manually using compute shaders in order to avoid the bottleneck of the hardware rasterizer.

> High end engines such as unreal

High end engines such as unreal have the excuse of being tasked with rendering millions of polygons, in which case a complex approach makes sense. Claude Code is only being asked to render a few thousand UTF-8 characters.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#434

Post by prng2021 »

aleqs wrote: post #40

Okay, so anthropic has amazing AI which supposedly writes most of their code and can continuously improve... meanwhile they have outages on a regular basis, and any kind of long-running work will now consistently hit 'API Error: Server is temporarily limiting requests'. Not sure of this is intentional to force a reduction of token usage, but at this point I need to build around these throttling limits and outages wit…

We’ve got a company of several thousand employees serving hundreds of millions of people arguably the best AI model in the market. Meanwhile you’re asking for a handkerchief for your pool of tears because their product is struggling to do your daily job functions for you, with much of that due to being limited by the worlds supply of silicon, electricity, water, and other resources. Cry me a river.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#435

Post by solid_fuel »

abletonlive wrote: post #286
f311a wrote: post #88

Earlier quoted context omitted.

Infrastructure is a much harder problem. They can't even improve Claude Code, which eats 1GB+ of RAM. Meanwhile, my editor only consumes 80MB of RAM.

> which eats 1GB+ of RAM. Meanwhile, my editor only consumes 80MB of RAM And why are you comparing Claude Code to your editor? > They can't even improve Claude Code That depends on how you define "improve". They've added a ton of features to it over time. Who said minimizing RAM usage was something they are prioritizing right now?

> And why are you comparing Claude Code to your editor?

Because Claude Code is also used to - get this - EDIT CODE. It fills the same purpose as an editor, it just has extra hooks for their agentic garbage.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#436

Post by solid_fuel »

windexh8er wrote: post #426
aleqs wrote: post #40

Okay, so anthropic has amazing AI which supposedly writes most of their code and can continuously improve... meanwhile they have outages on a regular basis, and any kind of long-running work will now consistently hit 'API Error: Server is temporarily limiting requests'. Not sure of this is intentional to force a reduction of token usage, but at this point I need to build around these throttling limits and outages wit…

Opus 4.8's critical assessment of Anthropic's "When AI builds itself" [0][1]. Because, why not? [0] https://pastebin.com/Vc5Yq9Ai [1] https://www.anthropic.com/institute/recursive-self-improveme...

What does this add? Everyone in here is perfectly capable of prompting Opus for a writeup.

Why don't you, windexh8er, try providing some thoughts of your own instead?

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#437

Post by strix_varius »

mrandish wrote: post #164

> "A caveat: Lines of code is an imperfect measure" I'm pleased they at least included this. However, they address the caveat by 'rounding down' the estimated multiple of the gain. I'm not sure that is the correct adjustment, especially once we understand the range isn't limited to positive numbers. There's strong evidence the range of code productivity denominated in "lines of code" should include negative numbers,…

Exactly this. Just this week an engineer who seems to purely vibe everything submitted a +700ish LoC fix for what seemed like a pretty simple issue. Moreover it was a perf issue, which in my experience is not usually best fixed by adding more stuff.

Today, I merged my fix, net -381 LoC.

I'm using them too of course, they read and type and hunt for bugs and test faster than I can. But I'm using them as my tool, not being a tool using them.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#438

Post by z3c0 »

prng2021 wrote: post #434
aleqs wrote: post #40

Okay, so anthropic has amazing AI which supposedly writes most of their code and can continuously improve... meanwhile they have outages on a regular basis, and any kind of long-running work will now consistently hit 'API Error: Server is temporarily limiting requests'. Not sure of this is intentional to force a reduction of token usage, but at this point I need to build around these throttling limits and outages wit…

We’ve got a company of several thousand employees serving hundreds of millions of people arguably the best AI model in the market. Meanwhile you’re asking for a handkerchief for your pool of tears because their product is struggling to do your daily job functions for you, with much of that due to being limited by the worlds supply of silicon, electricity, water, and other resources. Cry me a river.

> their product is struggling to do your daily job functions for you

So what's the value prop?

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#439

Post by solid_fuel »

jpleyden98 wrote: post #367
sensanaty wrote: post #254

Earlier quoted context omitted.

> At the same time they recognize that 80% of new code is now Al-authored I can setup a loop that will write a trillion lines of code automatically, how much of it is actually useful? Or are we back to counting LoC because there's no other metric for these systems that anyone can rely on?

It's 80% of new code they shipped that is AI authored. Would you ship pointless code? I do tend to agree though, it could be that AI solves problems with more code than a human would. What you need to measure is the value the code brings and how much of that is done by AI, hard to get an objective measure of that though.

> Would you ship pointless code?

I wouldn't, no. I don't see evidence that the engineers at Anthropic are similarly cautious however. They describe Claude Code as "basically a game engine" when it's literally a TUI app, and it eats memory for no apparent reason. I fully believe that Anthropic would ship pointless and garbage code. Especially if it's being written by LLM.

Re: When AI Builds Itself: Our progress toward recursive self-improvement

#440

Post by skydhash »

AceJohnny2 wrote: post #274
javcasas wrote: post #188

Earlier quoted context omitted.

> For each frame our pipeline constructs a scene graph with React then > -> layouts elements > -> rasterizes them to a 2d screen > -> diffs that against the previous screen > -> finally uses the diff to generate ANSI sequences to draw Yup. Overengineering.

This is a decades-old design pattern when CPU >> IO. Emacs has been doing just that since the 80s, when people were complaining about "Eight Megs And Constantly Swapping". See "redisplay" [1] This minimizes screen flash. You can't rely on terminals doing double-buffering. [1] https://github.com/emacs-mirror/emacs/blob/c29071587c64efb30... or a more user-friendly overview, Daniel Colascione's seminal "Buttery Smooth E…

> This minimizes screen flash. You can't rely on terminals doing double-buffering.

GUI and TUI have different architecture model. Most GUI have have a 2D surface that is redrawn multiple times per second. Double buffering is for decoupling update and render. TUI is a grid of characters that are updated one at a time via an active element, the cursor. Double buffering there is very wrong. Like adding airbags to a bicycle.

There’s a reason you see most old TUI either have an option to redraw the screen (automatically like top, or manually) and those that have a scrolling option allow to scroll by page. The TTY (the underlying concepts) used to be slow and it can be slow today as well (ssh connection). You need to be thoughtful about whole screen updates.

Post reply on HN