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

651–660 of 738 posts

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

#651

Post by fg137 »

LtWorf wrote: post #627
malfist wrote: post #104

Earlier quoted context omitted.

One of my co-workers just asked me to review his pull request that was all AI generated. 600 files were touched, over 40k lines of code added. I'm sure he thought that was a crowning achievement, proof that AI can enable 10X developers, after all, what engineer could write 40k lines of code in a week? I declined to review it, stating that I couldn't possibly vet 40k lines of code, and wouldn't put my reputation on th…

A former coworker sent me an AI generated PR to review and I just said NAK after the first two issues I found and I said to not send me AI slop to review. They went to HR who said I am more senior and I should act as a mentor (they had my same work title and were probably making 4x more due to being in USA) and I just no longer reviewed anything from them until I changed jobs.

People actually go to HR for such trivial things?

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

#652

Post by LtWorf »

fg137 wrote: post #651
LtWorf wrote: post #627

Earlier quoted context omitted.

A former coworker sent me an AI generated PR to review and I just said NAK after the first two issues I found and I said to not send me AI slop to review. They went to HR who said I am more senior and I should act as a mentor (they had my same work title and were probably making 4x more due to being in USA) and I just no longer reviewed anything from them until I changed jobs.

People actually go to HR for such trivial things?

All the time. And HR are generally bored and enjoy some drama.

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

#653

Post by megous »

skydhash wrote: post #451
megous wrote: post #376

Earlier quoted context omitted.

React part maybe. The rest is what any TUI that's using ncurses would do. :) It really bothers me that most of the TUI harnesses are using 100% CPU quite a lot just printing stuff to terminal. Seems ridiculous. I guess it comes from syntax highlighting/formatting, which is probably not done incrementally, but over the entire so far displayed block of output, recomputed from the beginning for each new streamed in char…

> Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time. The TUI mode is a client-server architecture. An analogy would be like an html page where all content is updated server side. Try to do 60 fps and you’ll have flickering as well.

No. Fetching pages from remote server will just make the client wait for I/O. That takes 0 CPU load and if the server can't respond at 60fps, lowered redrawing frequency would mean even less CPU load from the terminal redrawing itself.

This does not explain 100% CPU load these harnesses sometimes exhibit.

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

#654

Post by ahtihn »

TheOtherHobbes wrote: post #635
ezconnect wrote: post #609

Earlier quoted context omitted.

For the Capitalist crowd, YES it is the biggest cost. The next is energy. Imagine a world where your research and development is all AI and the production is all automated by robots. Instant product to sell to the masses who has no money because no one is working.

In the future a few thousand billionaire geniuses will own a world of unimaginable luxury and near-infinite longevity. They will make the decisions, AI will execute them, and robots will do the physical work. Everyone else will be reduced to compost. It's the perfect plan. The final definitive justification for capitalism. The masses are unnecessary. The masses will be optimised. What could possibly go wrong?

Why do billionaires keep working, keep amassing more money, donate to politicians, buy media companies?

They want influence and power. Being at the top of a hierarchy of millions, billions of people.

If there are no massess the 1000th billionaire will be a the bottom of the hierarchy instead of near the top. They don't want that. The masses are needed to give them the sense of power.

What these people want is power and control. Eliminating the masses goes against that.

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

#655

Post by froh »

I didn't see this discussed more on hn yet:

  We believe it would be good for the world to have the option to slow or temporarily pause frontier AI development to enable societal structures and alignment research to keep up with the advance of the technology. The Anthropic Institute will conduct research—in collaboration with many others—and take actions to help build the systems that a credible slowdown or pause would require. These systems would enable frontier AI developers to verify that others globally have actually stopped or slowed, and that a bad actor could not use the auspices of a coordinated slowdown to jump ahead in secret. If such systems existed, we expect that we would slow down or temporarily pause, if other developers at or near the frontier also did so in a verifiable manner.

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

#656

Post by enraged_camel »

esailija wrote: post #645
squidsoup wrote: post #236

Earlier quoted context omitted.

That's a process problem at your company - no developer should be proposing branches over 1k loc (or whatever your agreed tolerance threshold is) without a very good reason, vibe coded or not.

It isn't about small or big, it's about cohesion of the changes. I prefer a big feature to be one big PR rather than a lot of small ones. We had a dev do a big feature with a ton of small PRs, each one was individually impossible to review because each concern was out of scope for the small PR and "would be fixed in later PRs". Once it all came together as as whole, the big picture was a total horror show and I had t…

>> I prefer a big feature to be one big PR rather than a lot of small ones.

Yes, same, and I genuinely do not understand the insistence that PRs should not be above a certain size. I think most people are under the (misguided and wrong) impression that a PR review should take less than the time it took to write the code, and therefore allocate no more than 15-30 minutes per review. So when they come across a large PR they find themselves at a loss.

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

#657

Post by [deleted] »

AnimalMuppet wrote: post #467
hombre_fatal wrote: post #441

Earlier quoted context omitted.

This comment is a good example of the double standard laymen have about AI usage: If you use AI, then AI must be expected to solve all problems, even problems that affect everyone like infra scaling. And if perfection isn’t delivered, then of course it wasn’t: you used AI and AI sucks.

If their AI is good enough to write their code, why isn't it good enough to tell them how to fix their infra? That's a different problem space, but it's not harder than the code.

[deleted]

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

#658

Post by hombre_fatal »

AnimalMuppet wrote: post #467
hombre_fatal wrote: post #441

Earlier quoted context omitted.

This comment is a good example of the double standard laymen have about AI usage: If you use AI, then AI must be expected to solve all problems, even problems that affect everyone like infra scaling. And if perfection isn’t delivered, then of course it wasn’t: you used AI and AI sucks.

If their AI is good enough to write their code, why isn't it good enough to tell them how to fix their infra? That's a different problem space, but it's not harder than the code.

The software engineer inside us wants to believe otherwise, but scaling infrastructure is much harder than maintaining a TUI.

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

#659

Post by skydhash »

fc417fc802 wrote: post #544
skydhash wrote: post #459

Earlier quoted context omitted.

> They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive No one has ever done that. Even top[0], which does full screen refresh, clear the screen (if necessary) and write the new information (the period is in seconds, not ms). No need to diff. That would be like diffing a file, just to find which bytes to up…

I don't understand why you would make such a confident negative claim rather than ask for an example or otherwise engage in discussion. Particularly given that you replied to a comment elsewhere in this very thread that links to a real world example of exactly such an implementation! [0] See in particular this part of the source. [1] I agree that most programs don't bother to do that but please recall that my claim w…

The emacs code is not purely diffing. They already have the final output, they’re mostly comparing it to see a cheaper way to update than render the output. I’m pretty sure the curses library have the same thing.

But ink, the library Claude is using, defines a tree data structure for the main concept. The diff there is about comparing the old tree and the new tree created by the update, and then updating the node that has changed. That means if a single character change inside a bing panel, the whole thing is rewritten. And if you have something that is updating a lot, that means flickering.

The diffing that ink does is just architecturally wrong. You can create a dom, but a dom is not a concept for the terminal. It’s up to you to optimize its rendering. But just diffing the dom structure like react does is not optimizing, it’s busywork.

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

#660

Post by skydhash »

megous wrote: post #653
skydhash wrote: post #451

Earlier quoted context omitted.

> Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time. The TUI mode is a client-server architecture. An analogy would be like an html page where all content is updated server side. Try to do 60 fps and you’ll have flickering as well.

No. Fetching pages from remote server will just make the client wait for I/O. That takes 0 CPU load and if the server can't respond at 60fps, lowered redrawing frequency would mean even less CPU load from the terminal redrawing itself. This does not explain 100% CPU load these harnesses sometimes exhibit.

If it’s localhost, then it’s just the cpu doing stuff as localhost is a pseudodevice.
Post reply on HN