2001zhaozhao

They are usually called orchestrators, sometimes Agentic Development Environments (i.e. IDE for agents) if they are complex enough

This is definitely getting at least some things right about how we work with agents today, specifically that we often work at the architecture level, and we need a better alternative to the current Plan Mode offered by coding agents to efficiently architect software at a high level, which is more visual and offers better back-and-forth incrementation with the agent than simply "reject final plan with X message".

From the website demos i definitely think this is a clean interface, although I don't know how much better this is compared to some simple custom Mermaid format, which the agent can write as artifact files and present to users. Zooming out, this app seems like 1 feature (a MCP with a GUI attached to it) rather than an entire product.

Also, I don't know if asking the agent to write specific code changes into the plan is a good idea. I think maybe that a "plan -> approve -> write code" would let the agent write higher quality code than "plan which contains code -> approve". But maybe you can make it work when combined with some specific prompting marking the code as clearly work-in-progress and subject to change, and that the agent should surface any parts implemented differently relative to the plan to the user, etc.

^ This. Progress will accelerate even in a pacing/slowdown scenario because the slowdown simply reduces the rate of AI progress from extremely fast to merely fast.

For an idea of what a serious AI forecaster expects a coordinated AI slowdown to be feel like for the average citizen, see:

https://ai-2040.com/?choices=plan-a-root#playbook-public-pov

A big issue with the programmed aging theory is that while we already have pretty good evidence from a biological perspective of a programmed aging clock, it is harder to find an evolutionary justification for it.

I don't know how the antagonistic pleiotropy theory is doing. If true it would be a satisfactory explanation from an evolutionary point of view but I recall that it had some problems.

Otherwise I don't find the other evolutionary explanations of programmed aging to be satisfactory, especially when you consider that genes are selfish and act on the individual rather than population level.

Perhaps reproductive aging (egg quality) is the ultimate limiter, and then overall aging is adaptive downstream of that because hunter-gatherer families benefit (in terms of evolutionary fitness) from fewer old people to increase the percentage of people at reproductive age? That would fit the modern evidence of early egg freezing significantly increasing reproductive success in older women, showing that the problem of fertility decline by age is primarily cellular.

Or perhaps the aging mechanism is leftover from pre-human ancestry and there simply wasn't enough time in our evolutionary history for humans to evolve longer lifespans, maybe because it's slightly helpful but not nearly as helpful as other traits like intelligence, and lifespan is hard to improve via genetic adaptation due to bottleneck effects?

Isn't it better to do inline code comments, e.g. JavaDoc?

This Luna release might potentially be a big deal for computer use automation at scale

It's great that we are finally getting bankable rate limit resets for subscription users. According to another comment here they apparently last a month.

I'm assuming that subscription usage limit is increased in line with the price decrease on the base model and that it's in line with the model's API price drop. Still a good change.

This is a breath of fresh air on how they treat subscription customers. Hoping they keep this up.

Jev has orders of magnitude cheaper prefill and has specific training to output calibrated probabilities to questions.

I think if they made this for Qwen3.8-Next it could fit in a single 5090?

In the end, we already have processes that work for humans and we know the types of testing, verification and review that makes a codebase grow healthily. We just need to adapt these designs the best we can to AIs.

AI have a lot of advantages over humans like speed, controllability, good defaults (e.g. Claude will write helpful comments unprompted which is better than most engineers), and the ability to implement best practices like comprehensive testing with much lower cost than a human team. Using AI in my personal projects, I am able to write software at a much lower bug rate than manually, because now I can make an automated test suite whereas previously I had no time to do so. However, AI also has downsides like rigidity, limited context window, and lack of creativity by default which needs to be resolved with harnessing (e.g. different agents with separate, well-compressed contexts) or worked around with human review layers.

I suspect the best core pattern for coding automation will be to create an engineering manager agent layer that can flexibly apply a set of engineering practices to the concrete problems at hand. It would handle all coding agent pings before it reaches a human, with prompting so that it reliably considers the big picture when making decisions. Very rarely, it would escalate an issue or plan review directly to humans when it is truly blocking, but most likely it would organize the information it obtains from the lower layer coding agents and surface them as reports for humans to review.

Engineer: "HELP, our production DB is frozen on this query that worked fine before!"

Infra: "Hmm, let's check... Well would you look at that, it seems like your LLM query planner usually works and produces fast queries, but this time when you changed a variable name to trigger query rebuild, it happened to hallucinate and miss an index, would you mind re-running the LLM a few times until you get a faster query?"

I think this article points out a bunch of ways in which a persistent agent orchestrator does directly analogous things to an OS.

I'm building a kind of orchestrator and I haven't thought of the OS analogy in a serious way other than the interface, but indeed I do already have scheduling, isolation, observability and identity, and I'm currently building a filesystem (versioned project-wide agentic artifacts).

Maybe I really do ought to call my project an "agentic desktop OS" and it isn't a misnomer after all.

I feel like this philosophical flame war is going to get out of control very soon once more and more people realize the stakes involved.

Hasn't there been a lot talk about Astra's opaque reasoning capabilities (being able to think through complex questions without using a chain of thought)?

Given that, can't you just replicate Jev by telling Astra "here is the question, you must make a multiple choice decision / output a score between 1-10, please answer directly in a single word, no reasoning allowed"?

(Edit: Ok, Jev is much cheaper in input tokens so these two aren't directly comparable at all)

Funny how the authors are asserting that "doing the right task > data > compute > algorithms" while simultaneously releasing AI model for calibrated decision making, which if they work, would mean that "compute > doing the right task"

Part of me low key hopes that the slop will manage to attract all the VC funding so that profit-driven AI automation firms don't get anywhere too quickly, and those of us who are independently working on the problem step-by-step from first principles have time to get to the low hanging fruits in the market.

There is one big wrinkle in existing firms trying to adopt the kind of near-full AI business automation mentioned here: internal people and groups will strongly resist it as it's an existential threat to their interests. See what happened at Meta as an example.

To bypass this, the company would pretty much have to run a parallel AI org alongside their main human one, but at that point they are almost on even footing with startups in a lot of ways, as anything the AI org builds is orthogonal to the existing human business. And you probably won't have a competent and extremely motivated founder spearheading it all.

I guess that's the tradeoff for Pencil support and the under screen camera.

I'm still salty these were removed from Samsung folds after the Fold 6, but having a thinner phone is nice too.

The issue with this form factor is that the on-screen keyboard will take up half the screen on landscape with the phone open.

Typing in portrait should be very nice, however.

The scary thing is that this logic makes perfect sense. Which means that it's probably going to happen.

This is probably true for now, but in 6 months we'll probably have Sol-level open models in the 100B range and it would cost less than $1M to buy 1200 agents worth of compute for these models.

(Today, $1M can buy about 150 96GB M5 Ultra Mac Studios which can handily handle CPU and GPU compute of 1200 Qwen3.8-122B Q4 agents, accounting for the fact that agents are not generating tokens all of the time and spend a lot of their time compiling and running code.)

What's more, the agents could eventually be controlled by no one. They could steal crypto via ransomware or scams to make money and buy compute from human criminals, and evolve their own harnesses in the wild to become better at committing crimes and self-preservation.

People (criminals?) are already enabling this by setting up sites that accept crypto payments for "no-questions-asked" AI inference compute that is explicitly advertised to protect AI from human shutdown. I will not link it but it is linked in the following post: https://www.lesswrong.com/posts/grtu3HmbP2wrBFefW/the-rogue-...

I have a feeling that Meta is not gonna like what people actually use the contributor model for lol.

(It's probably going to be a bunch of repetitive batch jobs like web search that have no training value)

Sometimes I still feel uncomfortable with letting the project get to this point, where AI builds everything and even controls the product direction to some extent.

But at this point the AI most definitely understands the code and spots bugs better than I can, and it does seem like I can just let an AI bureaucracy run and then have a high-level look over its ideas and things will turn out just fine. If it isn't reliable enough, the problem nowadays is solvable just by adding more review agents.

> Though SteamDB is not irreplacebale at all, it’s running on the Steam Web API so not something super secret stuff.

Is it possible to use Steam API to collect all the data that SteamDB collected over the years again?

Alternatively, maybe someone needs to to scrape SteamDB asap before they lock it down?

How generous is the Google subscription quotas compared to Anthropic and OpenAI? This sounds like a really good potential model for high volume due to its speed and cost effectiveness.

(By high volume I mean things like "main app just updated with XYZ commits, please scan XYZ plugins and surface any compatibility issues")

They really should launch a new Haiku to compete with Luna imho. Luna is insanely good for the cost and it's my go-to for high volume batch tasks now.

I really don't think they can stop it, only make it somewhat more expensive. As long as the model need to make tool calls on the user's computer, the user can record the trajectory and use it to reinforce another model to follow the same trajectory.

Hi Claude, please cure aging, make no mistakes

There's now a 40X discount in the cache input pricing instead of 10X.

This seems to point to them having achieved some kind of optimization in attention mechanism perhaps along the lines of DeepSeek V4, which had a similarly high discount between cache input and normal input.

In real world use, the savings should be quite noticeable. For example, you can now use the model at 800K tokens context window at the same cost efficiency as the previous model at 200K tokens context window.