- 5.5 is significantly more token efficient than 5.4 - the same task takes often a third of the tokens

- because of this, is it also much faster to do the task

- you get high "intelligence" per token even after accounting for token efficiency - 5.5 medium is just under 5.4 pro levels of intelligence (imo). It has found tricky bugs for me that all other models failed at

So overall, ideally you will end up with more intelligent, faster model for slightly cheaper.

I did this as a subsidiary for a US company and literally had to email and call people every few days to move the process along (mostly, it was the banks who somehow expected us to be a multi-national company and wanted to charge an arm and a leg just to let us open a bank account. Most banks outright refused us).

When the notary finally filed the paperwork to the court, the court replied after a few weeks with additional clarifications for which we had to go AGAIN to the notary to do the whole song and dance of them chanting at us in German at 1000 words per minute.

Everything took painfully long and delayed investment for while. People have absolutely no idea how painful it is to merely have the incorporated entity available. Then, it takes a few weeks to get your tax ID - this is when you can start employing people / accepting payments etc.

Folks with amazing jobs having to spend >1y trying to find a "meh" job. Pretty much impossible to find a job without fluent German.

tbh this has been a sticking point for me too with uv (though I use it for everything now). I just want to start of a repl with a bunch of stuff installed so I can try out a bunch of stuff. My solution now it to have a ~/tmp dir where I can mess around with all kinds of stuff (not just python) and there I have a uv virtualenv installed with all kinds of packages pre-installed.

Though from everything I've read online, Zed's edit prediction model is far, _far_ behind that of Cursor.

True RL is where you set up an environment where an agent can "discover" solutions to problems by iterating against some kind of verifiable reward AND the entire space of outcomes is theoretically largely explorable by the agent. Maths and Coding are have proven amenable to this type of RL so far.

- the companies that died because acquiring them was too much of a hassle

- the companies that died or never got funded / started because the investors couldn't see and exit path

- the companies that got acquired piecemeal (Windsurf, Inflection), leaving the early employees with NOTHING simply to avoid the ire of anti-trust hawks at the FTC. This has irreversibly damaged the SV bargain - early startup employees work hard in case of an acquisition, they get rich.

So Lina Khan can keep patting her own back but there's a reason founders, early-stage startup employees and investors disagree.

People never read the documents before the meeting in those "normal" meetings.

The challenge with your suggestion is that people will half-ass the doc reading before the meeting - we tried doing this for the "normal" meetings. It was obvious the people skimmed the doc before the meeting. You're also now relying on the manager (if there even IS one for everyone in the meeting!) to care about this.

So, in practice, giving people dedicated 10 minutes at the start of the meeting works far better.

Besides, in most "normal" meetings, the main presenter often ends up discussing background / context for 10 minutes interspersed throughout the meeting anyway. In the "pre-read" meetings, you're just compress that to the first 10 minutes while increasing the amount of information transferred.

> 429: Too many requests

Mind you, this is with a paid API key

From calling it "IT" to paying peanuts, no wonder no one smart and ambitious wants to get into CS here. All the smart kids seems to want to go into consulting and finance. So, of course Germany doesn't see the kind of outsized success in the Tech industry like the US or even the UK.

Volkswagen's (and in general other automaker's) software sucking is simply a fact downstream of that.

Take this to its logical conclusion and basically, every company will need to segregate their data in regions. Most cloud platforms aren't really designed this way but it's coming.

There was a data locality law that India passed and Stripe had to do this massive migration project to segregate this data. I shudder to imagine what a more complex system would look like under such data locality laws.

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

Points: 51

# Comments: 21

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

Points: 57

# Comments: 0