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

Agent swarms and the new model economics

cursor.com

Post reply on HN
Print view View original

101–110 of 159 posts

Re: Agent swarms and the new model economics

#101

Post by thewhitetulip »

solumunus wrote: post #94
thewhitetulip wrote: post #79

Earlier quoted context omitted.

Yeah and it's still a cli tool running on JS So it's not a brag They could just write in Rust directly can't they? If they do that then they're doing what they preach

My app is written in TypeScript. With agents I could rewrite it in Rust, I just don’t need to so I don’t. It doesn’t warrant that level of performance and the business logic is more digestible in its current form. Given the amount of reviewing I need to do now, readability is worth more than performance. There are always tradeoffs. Are you implying that them attempting a Rust rewrite would fail, and this is why they’…

> business logic is more digestible in its current form.

Well, Anthropic spent many $ teling everyone that code is dead so this doesn't matter to them does it? Their business logic can be written in English!

Re: Agent swarms and the new model economics

#103

Post by Schlagbohrer »

sawyers wrote: post #86
anthonypasq wrote: post #4

Love to see these crazy kinds of experiments going on. Even if this doesn't 100% work or is prohibitively expensive for now, these are glimpses into the future in the same way people were talking about coding agents in 2023 when we just had tab complete.

It shouldn't be prohibitively expensive because the more you break the work into smaller parts, theoretically the smaller a model can be that completes it. Therefore your agent swarms don't have to be cutting edge API calls, they can be hosted on clusters of tiny cheap computers with small CPU GPU. For orgs you could basically invest in a local server that has 100s of small computers. You can use engineers and fronti…

The twin trends of AI slop being churned out at tremendous rate and deployed in everything, plus frontier AIs becoming really good at exploiting many small security holes to pwn boxen, is going to collide in an amazing cyberstorm that was predicted by every cyberpunk novel from the 80s X-D and we are gonna have front row seats 8-D

Re: Agent swarms and the new model economics

#104

Post by Schlagbohrer »

htrp wrote: post #2

>The browser swarm from earlier this year peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second. >To facilitate this rate of activity, we built a new version control system (VCS) from scratch. Throughput was not the only reason to own this layer. Every change in the system passes through the VCS, so it is where collisions first become visible, and several of the coor…

They probably just vibe coded it with ChatGPT

Re: Agent swarms and the new model economics

#106

Post by cookiengineer »

sawyers wrote: post #86
anthonypasq wrote: post #4

Love to see these crazy kinds of experiments going on. Even if this doesn't 100% work or is prohibitively expensive for now, these are glimpses into the future in the same way people were talking about coding agents in 2023 when we just had tab complete.

It shouldn't be prohibitively expensive because the more you break the work into smaller parts, theoretically the smaller a model can be that completes it. Therefore your agent swarms don't have to be cutting edge API calls, they can be hosted on clusters of tiny cheap computers with small CPU GPU. For orgs you could basically invest in a local server that has 100s of small computers. You can use engineers and fronti…

This so much!

For my current setup, the most efficient way is to use larger models for coordination, but a heretic'ed qwen 30B model for the implementations. If you build your agentic environment around specifications and test coverage tied to symbols, you can do a lot of parallelization of agent work.

If you then separate the filesystem and tool read/write access by agent roles and policies (e.g. coder not allowed to modify unit tests, tester not allowed to modify code files) then you can force them to use a centralized per symbol/per contract specification tool.

And then you can just let agents discuss issues, where the messaging threads are also tied to the same symbols.

[1] Exocomp, highly experimental: https://github.com/cookiengineer/exocomp

Re: Agent swarms and the new model economics

#108

Post by reinitctxoffset »

anthonypasq wrote: post #4

Love to see these crazy kinds of experiments going on. Even if this doesn't 100% work or is prohibitively expensive for now, these are glimpses into the future in the same way people were talking about coding agents in 2023 when we just had tab complete.

It's cool stuff, but I think mostly in an aspirational way right now. The tired cliche hit on the tired cliche claim will be "but sqlite is in distribution" which will miss the point, that objection dissolves at the precise point where it would have operationalized: novel software of value. Is SQLite in the train set, yeah. Does that matter? Only if someone is willing to pay for Rust SQLite as something other than marketing.

It's cool but I'd rather know what their most successful users are doing, and how they measure that.

Re: Agent swarms and the new model economics

#109

Post by Schlagbohrer »

mock-possum wrote: post #82
timacles wrote: post #69

Earlier quoted context omitted.

How much slop you figure Shakespeare produced?

Honestly judging from the volume of his output, a ton . It’s rare to run into prodigious artists who simply produce a few perfect pieces - as a rule those few magnum opuses are built on a hill of cutting room floor scraps.

The director James Cameron stands out because he has only produced huge box office hits. Extremely hard to do like you said, and most artists and auteurs would be happy to have one great work they can be remembered for, even if it's amidst a dozen forgettable pieces.

Re: Agent swarms and the new model economics

#110

Post by Schlagbohrer »

edg5000 wrote: post #95

I initially thought that getting agents to work for longer and in large groups was the future, but I'm increasingly thinking that, at least for engineering, just one thread makes more sense. The agent pulls things into context as needed. One thing that I've been experimenting with is also letting the agent remove things from context, such as files. But just adding to the context and compacting when it's full seems li…

Have you used this method yourself for long workflows and with contexts approaching 1 million tokens? It doesn't work very well. LLM context is nearly half unusable.
Post reply on HN