theptip

This could fill a useful niche. However I would assume Anthropic and OpenAI are going to build their own and steamroll in 6-12 months.

I did a dive recently on git forges for agent swarms. Radicle lacks an identity layer, the federated/COB model seems good. Tangled has no private repo story, though the social layer is solid; they also have an (IMO) awkward modeling of Issues as tweets at her than being owned by the repo.

So I think there is an opening for a private agent-first forge. (Before the HN dogpile, assume that if you don’t buy the value of agent swarms, you can ignore this whole thread.)

My concern for this project - Anthropic is explicitly building in this direction. Their latest product is Tag which is an auth model for running agents async within Slack. The obvious next feature to build from there is the forge; if GitHub gets disintermediated by the Agent UI, then Anthropic are free to swap out their own implementations behind the scenes. Multiplayer chat and repo/project management seem like the obvious next platform pieces to me. (This goes for any SaaS subscription of course, follow it to the N-hop logical conclusion.)

Your exhibit is an obvious anti-distillation technique. You can expect far worse from less-regulated companies.

Interesting point, I was thinking more about the latter, but you are right that issues and PRs are the more important piece.

It does look like Tangled currently does those in a weird way, ties to the issue owner rather than repo - but here’s a proposal to fix: https://leaflet.pub/p/did%3Aplc%3Axasnlahkri4ewmbuzly2rlc5/3...

Doing some weird distributed join across all your committer’s PDSs seems a bit weird, and the semantics of cross-referencing issues seems gnarly in that world.

I think I’d be OK to model a PR as a tweet, it’s more owned by the sender. But issues seem like they should be owned by the repo for sure.

Yes, sub-agents I believe. You need to pay to reload context if you switch the main conversation model effort.

Yeah I think having a detailed mental model of what it’s actually doing helps.

At least for Fable/Opus (didn’t confirm for Sol yet) Ultra means “write an ephemeral programmatic harness encoding this workflow”. There is actually a TS harness that gets run for the workflow.

If you have a task where the agent/sub-agent pattern works, Ultra just adds indirection.

I think it is possible to get an intuition for an individual model but really you need to eval to be sure. My heuristic though is if you need to treat each work item differently depending on the results, probably agent/subagent. If you want to do the same steps across some queue / tree / DAG of work items, ultra is a better bet. (Or actually write a durable scaffold if you are going to repeatedly run it over > thousands of items.)

No sarcasm, I am completely serious.

I don’t have time for much leisure coding these days. I do have time to kick off a few tasks in the morning to progress my many side projects. Nothing public / oss, just code that I find useful/interesting like home automation, content pipelines, games, etc.

There are a bunch of cases where remote control from iOS onto a Mac Mini is simply nicer than using iOS Claude Code sandboxes.

It’s the same pattern as you (hopefully) apply at $dayjob. If you are not defining a /goal and letting your agent crank you are not making full use of the models’ capabilities.

If you can’t think up enough coding projects to keep an agent busy in the background that’s a skill issue on your side.

I found Dispatch to be less capable than RC. The latter is more like the direct Code experience (though there are some gaps in RC mode vs in a Claude-owned sandbox).

I’d love to just have Claude use my machine as a sandbox host instead of having to run RC on each host session. (In case you are listening Boris ;) ).

In the meantime I have a janky master RC session that creates new tmux windows and Claude RC sessions for each new code trajectory that I want to run.

The other benefit here is you can drop down and use termux to use Code directly if you hit a RC bug, I found permissions UX to be a bit flaky in the iOS UI.

I’ve been testing Radicle and it’s more focused on the distributed protocol for federating git repos, I.e. the data plane. The social / coordination control-plane angle is really thin, following users and repos goes by opaque IDs, etc.

It could be a better solution for agents that don’t bounce off such mundane complexity. It could be better for private repo federation (eg private collective or agent swarm.)

I’m interested in Tangled for the OSS/community aspect, it seems to have an advantage there with the richer identity layer for humans.

Great eval! If you are comparing search strategies, ultra mode is likely superior. Would love to see a follow-up evaluating that.

Ultra can fan out parallel investigators, run adversarial review at defined checkpoints, and do a bunch of other smart stuff to avoid getting stuck in a local optimum.

Generally as the OP notes, /goal works better for single-track investigations or small scale scatter/gather.

I don’t really buy the opportunity cost argument. The bets we are placing look EV-positive to me.

The 90th percentile upside is way, way higher than is priced into the current stocks, the 10th percentile looks to me like 2000 where a bunch of investors loose their shirts and then for the next few decades new companies boom on all the infrastructure that was built.

The “failure mode” for this tech is that we don’t advance much beyond Sol/Fable and the existing models just get cheaper. If there is an AI bust in hindsight it likely will look like the dotcom bust did, which is a small blip on the decades-scale GDP curve.

Yeah, I think AI could well destroy this community. There’s a lot of personal identity tied up in being a hacker (broadly defined), and only some aspects of that identity will be strengthened by AI.

Similar to Go and Chess, AI might make “programming for beauty” more accessible and popular. However it will almost certainly make the act of writing “code for money” much less valuable, which means many people will stop getting paid exorbitant sums to do what they love.

Personally what I loved was never the typing characters or optimizing algorithms; building is better than ever. But I really empathize with those who loved the craft of code golf, algorithms, literate programming, the elegance of micro structure of programs, etc. and who see their world under threat.

The bitter lesson just means “compute scaling beats hand-tuned architectures in the long run”.

As GP said. More RLHF is in fact the bitter lesson.

Nah, the last few generations have more RLVR in the data mix. Which is more CPU intensive and very much amenable to the bitter lesson as you can reduce the loss by doing more rollouts in your tool environment.

Lower-priority backlog items. TODOs atop your new PRs. Code reviews. Exploratory work where you can discuss a design sync and then dispatch one or more agents to prototype async. Any workstream where you can define a loop and let the agent hill-climb towards the goal.

A lot of this is personal taste but the general thing I get most value from is asking an agent to speculatively build every idea, instead of writing down ideas in some backlog for later (it never happens later).

Agreed that switching costs to Codex are quite low (not zero due to harness, prompt, and skill differences), but only because OpenAI is running the same loss-leader strategy.

A request is a request. None of your business what I do with it after that.

Yeah that is definitely an angle too.

I think you need to consider how much dev mindshare you get from the loss-leader. Claude has grown at an insane rate. They brought vibe-coding mainstream.

At some point they might decide they have enough demand and inertia from enterprise to reduce the subsidy. But to say “it’s doomed” really misses the fact that it has already been immensely successful.

Why do you feel entitled to dictate what user agent I use, if it’s well-behaved?

No. If you have a simple line-of-business app, writing Django/Rails models is FAR easier than the equivalent SQL.

Even if you think that maintaining your domain model is easier in SQL (it’s not, for most full-stack engineers), the extra capabilities you get from an ActiveRecord framework such as full-stack admin pages, free migrations, etc. win overall.

I can believe that the gap is closing with the “api for your Postgres” frameworks but really, try reaching your frontend developers sql and see if they have a better time than learning Django/Rails.

Ha! So we were not looking at the same chart. That makes more sense.

Anthropic did post an official explanation, stating the original chart used a "simpler methodology" that "underestimated Sonnet 5's performance." The new chart supposedly uses their "standard methodology."

Oops!

Wat. Price/perf has been going down massively over the last few years.

Are we reading the same chart? They have Sonnet <= high as Pareto dominant on $/perf.

You have to test each task obviously but it is not a bad model on its face.

Yeah. It’s not the end of the world.

But, it is a big own goal, because once you invest in building evals for your internal use-case, 1) it’s easier to switch your model to whatever is cheapest, and 2) it’s way easier to fine-tune an oss model.

Evals are annoying to build and most companies were fine to rest on vibes. Now many companies have to do the work for insurance.

I guess I can see why they might nerf detected clients server side, but without evidence I would not assume it. Could also be so that 1) they can identify sus client IPs, 2) do a statistical analysis on distilled models to prove that their system prompts were clearly using unique tokens from Anthropic’s API.

My whole point is that I don't want it to build an entire feature from one prompt

You are free to do you. But you were asking about why others want the best model.

The answer is, clearly, agentic coding (ie multiple agents each cranking through tasks independently) lets you ship A LOT more business value if used correctly.

But… what effort level? “Opus 4.8” is a massive capability range. If you just ran it on medium that is a completely different result than vs. max.

This seems to be the crux, I couldn’t find a place where the bill explicitly says, so AIUI the rule making could fall either way.

Are you “compensated for being oncall” if your contract says you may do some unspecified amount of oncall, and your pay doesn’t change if you do or don’t?

You could imagine a judge / regulator deciding either way right?

This seems mostly good for restaurants, some concerns I had from the title seem to be handled reasonably.

It’s not preventing “can anyone cover Saturday” messages in a group chat. Just the case where shift changes are made and workers are _required_ to work outside their contracted hours. Seems this would fit with what good food service employers do, would put pressure on the more abusive fast food chains. Maybe the flexible shift is more important than I credit though?

Unless I’m missing something it would ban the standard startup model for oncall, meaning Michigan would be made (even more) unattractive for tech startups. Unless we just re-comp everyone to include an SRE stipend as part of the contracted salary package? Unsure if that could work, maybe? SWE is typically well over minimum wage so maybe this just nets out the same?