I think we see this with Meta being paranoid about internal Claude usage, to avoid inadvertently distilling[1].

If distillation is a driver, then smaller American labs could be distilling, but are not for legal reasons.

But that's a big if we just don't know for sure.

1 - https://cryptobriefing.com/meta-restricts-claude-code-codex-...

US has made itself visibly unaffordable, anti-science, and hostile to immigration.

For top scientists at these companies, there should be clear upside for the immigration to the US. That just doesn't exist anymore. Especially as quality of life increases in China

That said Congress can and does sometimes make the funding less discretionary. They can mandate expenditures. And make withholding legal funds personally painful for OMB. They also haven’t don’t this yet.

We should be attracting and retaining the world’s top researchers, not driving them away with dysfunction and xenophobia.

In the past it’d be hard for Chinese labs to retain researchers. Now the upside to the US isn’t there.

We could point at a lot of factors on the US side. From political paralysis / head-in-the-sand attitudes towards emerging tech like green energy. To something of disdain for workers that will be impacted by AI (creating a backlash). To education that continues to lag. Add to this so many other self-inflicted economic wounds from the current administration.

I don't know if its nearly as terminal, as say the UK after WW2. The US is still large, wealthy, and resource rich. Yet at a minimum the triumphalism about US leadership after Trump was elected by the tech elite feels silly in retrospect.

Something I also think about is how much stronger The West overall would be if instead of antagonizing allies, there was a single ecosystem working closer together.

Knowing Simon - he’s very much both :)

Yes if we had a Zig->Rust transpiler maybe it would produce similar output. But I can’t find one. We’d have to use an agent to build one first :)

New hotness: pelicanmaxxing

Kaggle winning solutions rarely make sustainable engineering solutions for teams. Maximizing just model performance against an objective is a small part of the bigger picture.

Is this a classic 'commoditize my compliment' situation? They want to sell the hardware and infrastructure behind AI and make the software part not the value driver / moat?

I can see it. But also even two Chinese labs sinking 100s of millions USD into training isn't exactly commoditization. It's still a ton of effort with dubious payoff.

Not nearly all the code. Maybe 5% - the important code. To keep things sane, explore new areas, get a deeper understanding of the system, delete/simplify agent slop, improve test coverage, or make some other foundational change.

Feels like we’re bending over backwards to avoid just doing this. But it seems for me, at least, the way to have the highest leverage on an agent heavy project, it’s fulfilling, it helps the agent, and it keeps me in flow.

I wrote the barebones, scaffolding, and where I cared about the details. Agents stamped out the rest from those patterns.

Everyone speaks about this stuff in anecdotes. Or heroic attempts to have agent only projects.

But very little actual data on real gains in actual quality as experienced by users? Harder to measure IMO. And may even be subjective to each developer.

Not that we won't have most code written by agents. I truly beleive that to be true. But that we got so far down the "never look at code" rabbit hole that our abstractions will become so divorced from the reality that is the actual.. freaking... code. We will truly have spaghetti code, bloated towers of babble.

We'll tut-tut these times and think "if you only spent half a day thinking about the big picture, looking at code, dare I say write some code you could have saved the project a whole mess of trouble".

In the meantime we're going to be generate 10K in spaghetti what should probably be 500 reasonably understandable LoC.

Spending a day reading some code can save you $100s of tokens, and weeks of headaches.

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

Points: 4

# Comments: 1

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

Points: 70

# Comments: 41

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

Points: 3

# Comments: 0

Many of us would struggle with our reading comprehension of an English description of an algorithm. But the pseudo / actual code? Much easier to reason about.

I'm not saying you should review even 90% of code. But it feels like an arbitrary line to say "never look at code". It's like never taking a wrench to a car to look at what's built to see whether you trust the car factory.

> How are you supposed to review 5k lines of code every day?

Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.

> “how is exactly the design of that part? How does it work?”

Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.

It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.

I feel like everyone is being too black and white. And everyone has different ways of staying in flow with a software task.