Comments URL: https://news.ycombinator.com/item?id=47640775

Points: 158

# Comments: 59

Comments URL: https://news.ycombinator.com/item?id=47565348

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47466408

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47431341

Points: 2

# Comments: 0

Immutable by convention + Strong conventions: 91.3% - Elixir 97.5%, Kotlin 90.5%, Racket 88.9%, C# 88.4%

Immutable by convention + Fragmented: 78.4% - Scala 78.4% (n=1)

Mutable + Strong conventions: 77.5% - Ruby 81.0%, Swift 78.5%, Julia 78.5%, Dart 78.0%, Go 71.7%

Mutable + Fragmented: 67.9% - Java 80.9%, R 75.8%, C++ 75.8%, Shell 72.9%, Python 65.3%, Perl 64.5%, TS 61.3%, JS 60.9%, PHP 53.8%

(my grouping is somewhat subjective)

It's tempting to argue that a more constrained language helps, but Rust (62.8%) vs Elixir (97.5%) is an interesting data point here. Both are highly constrained, but in different directions. Elixir's constraints narrow the solution space because you can't mutate, you can't use loops, and you must pattern match, so every constraint eliminates options and funnels you toward fewer valid solutions that the LLM has to search through. Rust adds another constraint that must independently be satisfied on top of solving the actual problem, where the borrow checker doesn't eliminate approaches but adds a second axis of correctness the LLM has to get right simultaneously.

Overall, it seems like languages with strong conventions and ecosystems that narrow the solution space beat languages where there's a thousand ways to do something. Elixir has one build tool, one formatter, one way to do things. C#, Kotlin, and Java have strong ceremony and convention that effectively narrow how you write a program. Meanwhile JS, Python, PHP, and Perl offer endless choices, fragmented ecosystems, and rapidly shifting idioms, and they cluster at the bottom of the table.

Comments URL: https://news.ycombinator.com/item?id=47402974

Points: 7

# Comments: 0

If storing it this way makes it usable for agents, then why don't humans just use agents when they need to interact with it?

Comments URL: https://news.ycombinator.com/item?id=47376501

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47375481

Points: 4

# Comments: 0

However, the GAAP P&L tells the opposite story. You book $200M revenue in the same year you spend $1B training the next model, so you report an $800M loss. Next year you book $2B against $10B in training spend, reporting an $8B loss. The business looks like it's dying when every individual model generation actually generates a healthy profit.

That's actually Dario's answer to your depreciation question. If each cohort earns back its training cost within its natural lifespan (however short that lifespan is), the depreciation schedule is already baked in. The model doesn't need to live forever, it just needs to return more than it cost before the next one replaces it. Whether that's actually happening at Anthropic is a different question, and one we can't answer without audited financials, but it's the claim Dario makes (and seems entirely reasonable from a distance).

I suspect it works as follows: when a task starts, filesystem contents sync down from S3/R2/GCS to a local directory, which gets bind-mounted into the container. The agent reads and writes normally - no FUSE, no network round-trips per file op. On task completion or explicit sync, changes flush back to object storage. The presigned URL support for upload/download is the giveaway that object storage is the source of truth.

This makes way more sense than FUSE for agent workloads. Agents do thousands of small reads (find, grep, git status) that would each be a network call with FUSE. With copy-on-mount it's all local disk speed after initial sync.

Cross-task sharing falls out naturally - two tasks mounting the same filesystem ID just means two containers syncing from the same S3 prefix. Probably last-write-wins rather than distributed locking, which is fine since agents rarely have concurrent writes to the same file.

Comments URL: https://news.ycombinator.com/item?id=47268197

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47247067

Points: 1

# Comments: 0

There's some challenges around the LLM having enough output tokens to easily specify what it wants its next input tokens to be, but "snips" should be able to be expressed concisely (i.e. the next input should include everything sent previously except the chunk that starts XXX and ends YYY). The upside is tighter context, the downside is it'll bust the prompt cache (perhaps the optimal trade-off is to batch the snips).

It strikes me there's more low hanging fruit to pluck re. context window management. Backtracking strikes me as another promising direction to avoid context bloat and compaction (i.e. when a model takes a few attempts to do the right thing, once it's done the right thing, prune the failed attempts out of the context).

Comments URL: https://news.ycombinator.com/item?id=47163934

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47148725

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47079055

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47055090

Points: 4

# Comments: 0