> Now if you could see the buying and selling for the next level below them somehow, that would be a great advantage (and also very illegal).

You could probably estimate this if the company has a trading window for employees (which I think almost all of them do).

Sum up the exec sales, then use the previous accounting data to estimate shares held by employees, and then create an index based on what direction employee sales are trending.

Because RSU grants track level (sortof), then you might be able to get a good sense for this, even though there would be lots of noise.

Warning: not investment advice (though if you're taking investment advice from a random HNer then you're probably doomed anyway).

> which arguably numpy advanced and now Julia finally perfected

cough S/R cough.

Like, both Numpy and S/R evolved as an interface over Fortran programs for matrix manipulation but S (even R, maybe) signficantly predates Numpy.

I've had a bunch of failed tool calls and weirdness through Cursor with it recently but it's so good and so much cheaper that I put up with it.

This is the RL training. Like, I'm not even sure how one could train for better design.

Certainly, it would be super super difficult to generate training data for it, so it's unlikely that it will improve.

An idea to start could be something along the lines of an agent given tasks incrementally, where the agent would be required to extend/generalize a piece of functionality. A possible reward could then be the amount of code the agent had to add/remove to complete the task.

I assume frontier labs will start hiring devs specifically for generating training data for this purpose. It's a skill you can get better at. I don't see in the limit why it couldn't be solved, but I agree, for practical reasons it's somewhat unlikely.

> I assume frontier labs will start hiring devs specifically for generating training data for this purpose. It's a skill you can get better at. I don't see in the limit why it couldn't be solved, but I agree, for practical reasons it's somewhat unlikely.

Because of the scale that would be needed. Like, design stuff is much fluffier than code correctness or functionality, so really really hard to generate enough synthetic data to tune the models to do better.

In the limit yeah it would work, but in the limit we're all dead ;)

At some point on this ride, if devs are really put out of work and wages are massively depressed (along with the devs), then it might become cheap enough to make work.

It's really incredible how they've squandered so much goodwill over the past few years.

While I think their models are great, and they deserve a lot of props for caring about safety (their interpretability work is great), their public tone just leaves so much to be desired.

Apparently they also don't understand the Streissand effect, given their recent blog posts about GLM 5.3.

> and they deserve a lot of props for caring about safety

At this point I believe they NEVER cared about safety. The CEO doomerism and the whole "slow down the development of AI" far cry is another marketing strategy based off fear

Verifiability is really, really, really hard in domains that aren't engineered for it.

Even in software, we are struggling with the huge amounts of code shipped by LLMs. Most other industries have no automated way to give the models feedback so the impacts will (over the short term) be pretty limited.

That being said, I reckon I'll get 20 years of work integrating this tech into the world, so it might be OK.

In capitalism, man exploits man. In communism, it's just the opposite.

> If the word “calibration” in probability doesn’t mean anything to you, the difference isn’t very apparent, but that doesn’t mean it doesn’t exist.

I am really sceptical that they've developed a zero shot calibrated classifier for arbitrary inputs.

That being said, if they have, then this valuation is like 100 times too low.

It's calibrated where it's calibrated and not where its not. Their "confidence" score is rather bunk, so it's hard to say. As with other LLMs, you have to eval it for your setting, and if you find it calibrated, then great.

> Their "confidence" score is rather bunk, so it's hard to say.

Then it's not calibrated (in the technical sense of the term).

> These guys also love text to sql. I know 4 people each implementing text to sql for their separate companies.

Text to SQL is a really bad idea, as the agent will just generate really convincing and terrible analyses that lack all business context.

I mean, you could implement some kind of semantic layer, but that's a lot of work, for uncertain reward.

I saw a place which essentially tasked the data analysts/scientists in an area to describe the good tables, and assumptions and necessary context to make decent queries/analyses, and that definitely lead to much, much better (almost usable) results.

As I have said many times, what the world really needs is SQL2Text, rather than Text2SQL.

> I saw a place which essentially tasked the data analysts/scientists in an area to describe the good tables, and assumptions and necessary context to make decent queries/analyses, and that definitely lead to much, much better (almost usable) results.

Yep. After this has been done, the later text to sql outputs works half decent. The major issue I heard was that whenever a small assumption changes few months down the line, while humans are able to "JIT" apply it to each of their queries, these models sometimes lose it in all of the context and so it becomes hard to progressively update anything - you end up having to redo the whole workflow.

And in my experience, even the more complex dashboards requested by product or upper mgmt were stood up within the day by humans. Or the next day (but that was cos some ETL would be scheduled overnight rather than immediately). And I am not sure if speeding up this part would even matter to the guy who requested the dashboard. So I am not sure if this is a major bottleneck people should try to innovate in. If openai does the work for you then great but otherwise. Humans aided by copilot-of-old style autocomplete is probably more than enough.

Needless to say, text to sql is pointless for application queries made during API calls.

Yeah, it's not the development but the maintenance that kills you in both software and other information fields.

The whole text to SQL thing is about data teams being a bottleneck to the business (rather like software people). The goal is good in theory but honestly an Excel plugin is probably a better solution in many cases.

> not only is it deceptive but it's also suprisingly podunk of openai to have a "safety researcher" also double as a recuiter. did they have her making coffee and doing dishes too? is "safety researcher" a serious position, or isn't it? i guess i can tell what openai thinks.

it was most likely for her team, which would explain why she was doing it.

if she's hiring for her own team why does she need to use someone else's email?

Your mistake is viewing this as "someone else's email" instead of a communication medium for certain types of messaging. Similar to how `webmaster@` can be used by anyone attached to the role.

Every organization sets up something like this once they grow past a certain point.

and that's what it was and not a fact you're imagining right now for the sake of argument? because what i heard is she used an executive's email address improperly, which she says she did for recruiting.

If you have worked in a sufficiently big org this would have been normal to you. Executive assistants send mail which purports to come from the executive himself. That is the kinda thing which happened here.

everyone who's replied to me has a slightly different idea of what happened, and none of them really fit the claims that have been made by the parties involved, nor do they fit together.

so do you have some kind of inside knowledge about what happened? if so can you give more details about how exactly she improperly used an executive's email? what did she send and to whom, i wonder. and if you don't have any inside information, could you reflect on what motivates you to defend openai here?

But "executive assistant" is not the same as "safety researcher". Even if it's normal for the former, it is weird for the latter.

This may shock you but in agile, growing organizations employees sometimes have multiple job responsibilities. I've done a bit of recruiting even though I'm not a recruiter or hiring manager.

and did you use someone else's email for that?