rybosome

Understood, thanks.

[flagged]

As a former GCP engineer, no, the systems are not generally unstable or insecure.

There is definitely manual access of data - it requires what was termed “break glass” similar to the JIT mechanism described by the author. However, it wasn’t quite so loose; there were eventually a lot of restrictions on who could approve what, what access you got after approval, and how that was audited.

It was difficult to get into the highest sensitivity data; humans reviewed your request and would reject it without a clear reason. And you could be 100% sure humans would review your session afterwards to look for bad behavior.

I once had to compile a large list of IP addresses that accessed a particular piece of data to fulfill a court order. It took me days of effort to get and maintain the elevated access necessary to do this.

I have a lot of respect for GCP as an engineering artifact, but a significantly less rosy opinion of GCP as an organization and bureaucratic entity. The amount of wasted effort expended on engaging with and navigating the bureaucracy is truly mind-boggling, and is the reason why a tiny feature that took a day to code could take months to release.

> it’s got me nervous to use Python or Node.js these days

My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.

I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.

I disagree. I’ve had almost 20 years of professional programming experience. Spent a decade in FAANG, the rest in startups.

It is unarguable that I am able to program. Vibe coding has absolutely made programming more accessible to me too.

I have two kids and a full time job. Before LLMs I didn’t do side projects; work and parenting plus my other interests took > 100% of my energy.

Now I have many things I’ve worked on or built solely because LLMs lowered the barrier to entry, and I feel that I can fit the remaining human work into the cracks of the time and energy I do have. One can gripe about how I’m less connected to the code, or that I learned fewer substantial technical lessons from the experience; these things are true.

However, I learned more than if I hadn’t done the project at all. It’s like the exercise benefit of an electric bike - you don’t get the aerobic benefit of an unassisted bike, but if it motivates you to ride when you otherwise wouldn’t then the trade off isn’t so clear.

That SOUL.md contains major red flags, obviously would lead to terrible behavior

Thanks for sharing. I’m curious why the example SPICE application uses Fortran to parse the SPICE data?

I have heard this argument before, but never actually seen concrete evals.

The argument goes that because we are intentionally constraining the model - I believe OAI’s method is a soft max (I think, rusty on my ML math) to get tokens sorted by probability then taking the first that aligns with the current state machine - we get less creativity.

Maybe, but a one-off vibes example is hardly proof. I still use structured output regularly.

Oh, and tool calling is almost certainly implemented atop structured output. After all, it’s forcing the model to respond with a JSON schema representing the tool arguments. I struggle to believe that this is adequate for tool calling but inadequate for general purpose use.

“And, because AI never got any better or any cheaper after that point, sussmanbaka’s wry observation remained true in perpetuity, forever.”

- History, most likely

Others have pointed it out, but it’s the juxtaposition of the fact that she’s definitely not an expert in this subject with a lesson in the subject.

There’s some subtle bits to the humor depending on how charitable you’re feeling. It might just be absurdist, as in “Blackbeard’s guide to astrobiology”, or it may be more mean spirited and playing on a belief that she is not intelligent.

TL;DR - the joke formula is just:

subject=…

person_not_familiar_with_subject=…

joke=“${person_not_familiar_with_subject}’s guide to {subject}“

And the amount of implied cruelty in the comparison is variable.

Those of us subscribing to AI newsletters are constantly slapped in the face with “___ is all you need” style jokes, such that I didn’t even register someone might not make that connection.

I see your point, but I’m not sure that I agree.

Consider that when speeding, you might cause an accident. Such an accident would most likely impact a small number of people other than yourself.

When a PE firm engages in extractive hospital management, it provably increases mortality rate, and it does so at scale.

The first choice carries possible risks of lower magnitude, the second choice carries guaranteed risk of higher magnitude.

“Risky behavior” vs “ruthless greed”, the latter feels much closer to violence.

It’s a totally reasonable choice in that context.

I wonder if any sense this is criticism (or actual criticism) is based on implementers of SaaS who have it so deeply ingrained that “haha what if the users of this software did this really extreme thing” is more like “oh shit what if the users of this software did this really extreme thing”.

When I worked on Google cloud storage, I once shipped a feature that briefly broke single-shot uploads of more than 2gb. I didn’t consider this use case because it was so absurd - anything larger than 2mb is recommended to go through a resumable/retryable flow, not a one-shot that either sends it all correctly the first time or fails. Client libraries enforced this, but not the APIs! It was an easy fix with that knowledge, but the lesson remained to me that whatever extreme behaviors you allow in your API will be found, so you have to be very paranoid about what you allow if you don’t want to support it indefinitely (which we tried to do, it was hard).

Anyway in this case that level of paranoia would make no sense. The programmers of this age made amazing, highly coreographed programs that ran exactly as intended on the right hardware and timing.

The idea of giving every character this sort of agency and seeing what opinion builds up about the world is incredibly fascinating.

Depending on how well we assume an LLM would do at this task, it’s an interesting way to see what “real people” would think about a very hypothetical situation.

An important point that’s missed in this is that these small farms are a vital part of the US’ food security. So regardless of what an analogous business in another sector may choose to do, we really want small farms to be sustainable all over the country.

Not the OP, but I assume they mean that it's encoded in the type system.

For example Rust gives you a `Result<Thing, ErrorType>`, which might be a `Thing` or might be one of the possible error types given by `ErrorType`. So when you get a function's return value, you have to deal with the fact that it might have failed with this specific error.

I suppose my negative experiences with async fall under #3, that it is hard to maintain two APIs.

One of the most memorable "real software engineering" bugs of my career involved async Python. I was maintaining a FastAPI server which was consistently leaking file descriptors when making any outgoing HTTP requests due to failing to close the socket. This manifested in a few ways: once the server ran out of available file descriptors, it degraded to a bizarre world where it would accept new HTTP requests but then refuse to transmit any information, which was also exciting due to increasing the difficulty of remotely debugging this. Occasionally the server would run out of memory before running out of file descriptors on the OS, which was a fun red herring that resulted in at least one premature "I fixed the problem!" RAM bump.

The exact culprit was never found - I spent a full week debugging it, and concluded that the problem had to do with someone on the library/framework/system stack of FastAPI/aiohttp/asyncio having expectations about someone else in the stack closing the socket after picking up the async context, but that never actually occurring. It was impenetrable to me due to the constant context switching between the libraries and frameworks, such that I could not keep the thread of who (above my application layer) should have been closing it.

My solution was to monkey patch the native python socket class and add a FastAPI middleware layer so that anytime an outgoing socket opened, I'd add it to a map of sockets by incoming request ID. Then when the incoming request concluded I'd lookup sockets in the map and close them manually.

It worked, the servers were stable, and the only follow-up request was to please delete the annoying "Socket with file descriptor <x> manually closed" message from the logs, because they were cluttering things up. And thus, another brick in the wall of my opinion that I do not prefer Python for reliable, high-performance HTTP servers.

No problem - although I'm out of that particular role, it's appropriate to discuss since the company shared these details already in an openAI press release a few months back.

I fine-tuned reasoning models (o1-mini and o3-mini) which were already well into instruction-following and reasoning behavior. The dataset I prepared was taking this into account, but it was just simple prompt/response pairs. Defining the task tightly, ensuring the dataset was of high quality, picking the right hyper parameters, and preparing the proper reward function (and modeling that against the API provided) were the keys to success.

I fine-tuned an LLM to do Verification IP wiring at a LLM hardware startup. We built the dataset in house. It was quite effective actually, with enough investment in expanding the dataset this is a totally viable application.

Thanks for the detailed reply, that’s very cool! This looks great, very usable way to do DI.

Do you use Haskell professionally? If so, is this sort of DI style common?

I’d have liked to see the use of dependency injection via the effects system expanded upon. The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.

Also, I had no idea that the module system had its own type system, that’s wild.

Visually I dislike the \\, but I see this solves the problem of multiline literals and indentation in a handy, unambiguous way. I’m not actually aware of any other language which solves this problem without a function.

Yours is rendered as:

A\n\tsimple\n\t\tformatted\n\t\t\tstring\n\t

If you wanted it without the additional indentation, you’d need to use a function to strip that out. Typescript has dedent which goes in front of the template string, for example. I guess in Zig that’s not necessary which is nice.

Yeah, this is a case of "horses for courses", as you suggest.

I love Python. It's amazing with uv; I just implemented a simple CLI this morning for analyzing data with inline dependencies that's absolutely perfect for what I need and is extremely easy to write, run, and tweak.

Based on previous experience, I would not suggest Python should be used for an API server where performance - latency, throughput - and scalability of requests is a concern. There's lots of other great tools for that. And if you need to write an API server and it's ok not to have super high performance, then yeah Python is great for that, too.

But it's great for what it is. If they do make a Python 4.0 with some breaking changes, I hope they keep the highly interpreted nature such that something like Pydantic continues to work.

RIP to a legend who had a profound impact on me as a young musician.

To quote my favorite song of his:

I've seen your face a hundred times Everyday we've been apart And I don't care about the sunshine, yeah 'Cause mama, mama, I'm coming home

Well, even if we assume for a moment that we aren’t talking about non-public data…

Then RAG which serves up knowledge already in the model’s pretraining data is still useful, because it primes the model for the specific context with which you want to engage it. I maybe can see what you are saying, like why can’t the model just do a good job without being re-reminded? But even in that sense, any intelligence, artificial or otherwise, will do better given more context.

And that ignores the reality of data outside the model’s pretraining corpus, like every single business’ internal data.

I’m currently doing research on this exact problem. Would you care to share an example of an advanced typing issue that you’ve seen LLMs struggle with?

An Italian YouTuber called “Once Were Nerd” had his house raided by Italian authorities due to showing emulated video games on his channel.

They have also asked Google to engage in DNS poisoning related to soccer piracy. Not sure about the cloudflare thing but it sounds consistent.

It improves the latency of ls calls.

I encourage you to try this yourself and see how you feel.

Recently I used an LLM to help me build a small application in Rust, having never used it before (though I had a few years of high performance C++ experience).

The LLM wrote most of the code, but it was no more than ~100 lines at a time, then I’d tweak, insert, commit, plan the next feature. I hand-wrote very little, but I was extremely involved in the design and layout of the app.

Without question, I learned a lot about Rust. I used tokio’s async runtime, their mpsc channels, and streams to make a high performance crawler that worked really well for my use case.

If I needed to write Rust without an LLM now, I believe I could do it - though it would be slower and harder.

There’s definitely a “turn my brain off and LLM for me” way to use these tools, but it is reductive to state that ALL usage of such tools is like this.