schrodinger

Agreed. It’s like the argument that video games cause shooters.

Umm, I played plenty of GTA growing up and I’ve never stolen a car. People are actually very good at separating fantasy from reality, believe it or not.

The cat comes out of the bag? Spoiler! I'm still waiting to find out if the cat is dead or alive…

This is a fascinating illustration that I can't help but agree with. However I feel like there's something more — that this part of my brain is a bunch of supportive background processes running without my real awareness. It's how I can drive home safely with no memory of how I got there (…sober), even though driving is an action that's incredibly demanding of intelligence. I can be driving home while thinking about a really hard problem at work that I haven't solved.

However, if I came around a corner and saw a car in the wrong lane, a tree across the road, a fire raging — I'd very quickly jump into the mental driver's seat and turn my conscious intelligence fully at this problem and come up with the best possible outcome I can think of in a short period of time — losing all ability to think about that work problem. I'd remember that incident for sure.

Similarly, in your story, all those predictive moments are happening below the person's level of consciousness. They're possibly even speaking to the group about a problem at the same time and thinking deeply about something.

I'm not smart enough to know, but I tend to feel like LLMs are much more like the predictive part of our thinking that you described, but that human cognition has something more — the single-threaded, creative, problem-solving part that is very conscious.

Is it possible that LLMs represent only one part of the way we think? And there's a whole separate mechanism that's fundamentally different, and not based on pattern matching and prediction?

This is a great point, analogous to the https://boringtechnology.club/ philosophy I've come to love.

There's no reason we need to make an incredibly intelligent shell execution engine that can identify patterns that seem evil and may represent unwanted behavior to solve this problem. Simply limiting the available tools to a finite, known, ironclad-secure set (even if it's quite sprawling) is sufficient.

LLMs will still find workarounds — from what I understand, a large part of the issue in this situation was that an agent was presumed to have read-only Internet access because it could only make GET requests. It should be pretty obvious that there's at least one website on the Internet that allows writes via GET. I think this is where auditing comes in, and a live team of people watching tool calls would have noticed the strange behavior.

But I think a lot of times people jump to overly complex solutions when simple, well-bounded ones would work just fine. Yes, the intelligent shell is a great goal, but it's akin to solving the halting problem.

This philosophy is what I love about PicoClaw (https://github.com/sipeed/picoclaw), and incidentally the philosophy behind Go and even *nix in general (i.e. provide small, composable, single-purpose tools).

I agree. If I were setting up an experiment like this, I'd have instrumented the hell out of it to see all actions taken in real time, and have a team of folks watching it. This team would have seen the anomalous GET requests to a German wiki and taken action (e.g. halt the system to investigate and decide whether to abort).

In fact, that feels so obvious it's ridiculous it needs to be said. It's table stakes. When do you run a production system without monitoring and a team on-call?

It's hard to imagine another field in which this reckless behavior would be tolerated.

I fully agree with you, but would go one step further: I think it's clear that we need to pierce the corporate veil and ascribe responsibility to _people_, not just "OpenAI the entity", full stop.

Executives should fear being perp-walked and thrown in jail for the actions of irresponsible "tests" of their models in the real world, as they're ultimately accountable.

Sure, there's a lot of nuance to work out, but I think we could likely even _start_ there today even with existing laws and pretty quickly "align" on more intricate legal frameworks to handle true accidents, distribution of responsibility, etc.

You say this flippantly, but I think this is actually another very good example!

We even do it for obviously unintelligent inanimate objects. A rollercoaster ran too fast for its tracks, killing 10 people. In that sentence, the roller coaster is the subject which took an action and caused death — obviously the roller coaster is not ethically at fault here, the people who built the rollercoaster are at fault through negligence.

Although this example and the ones around cars both demonstrate how we tolerate some degree of "accidents" from humans as no-fault, which is fair. I wonder how that fits into this analogy? I suppose its all about intent (mens rea) and judgement: did they intend for the roller coaster to harm people, and should they have reasonably predicted that the accident was likely to happen.

Spoiler warning! I haven't seen 2001 A Space Odyssey and am sad to have learned that… can you edit to warn people?

Apologies, I used to use appreviewtimes .com [dead], which scraped tweets and was pretty accurate, but is dead now. I posted what seemed to be a decent replacement, but will take your word it’s not.

Edit: was going to update the earlier comment but just hit the 2 hr mark.

Before and after LLMs.

If anyone else finds that BitterLesson link difficult to read because it wraps full-width, you can type "javascript:" in your URL bar and paste:

    document.body.style.cssText='margin:auto;width:600px;'

(Chrome strips the "javascript:" for security if I were to include it myself.)

Easily solved by adding an interstitial whenever a URI becomes replaced and is therefore no longer immutable, and showing the history of what it used to point to as well (in case you're coming along from an old link). By default, after 5 seconds, it could redirect to the current destination.

Note: I apologize and rescind my previous comment about not arguing in good faith.

My point isn't that home brewing makes alcohol easier to obtain; clearly it doesn't, as you pointed out.

Rather, it provides a respectable rationale for having a beer (e.g. testing a batch, checking the bottle fermentation, seeing how it pairs with a meal).

Drinking is now part of a productive, interesting hobby. For most people that's harmless, but for a vulnerable individual, the hobby supplies frequent opportunities, a steady supply, and an intellectually respectable reason to consume. That's all.

I find it hard to believe this comment is arguing in good faith.

How much more likely does becoming a home brewer make you to develop alcoholism, especially for someone who sounds a bit predisposed like Jim?

I agree with that — One of Go's biggest strengths is the flip side of an arguable weakness: it's not a very expressive language.

The positive of that is that if you ask three people to write the same function, it'll most likely end up nearly identical. You don't get codebases where different areas are written using different styles and different patterns.

This same effect applies equally to coding agents.

It's too late to edit, but in retrospect I realize that the first sentence of that comment sounded awfully snarky, and I didn't mean it to. I apologize, and please trust it was asked in good faith.

Fully agree with you, and I didn't make my point well — I should have been more clear.

While Python and Node have undoubtedly seen a huge spike since the advent of mainstream AI, relatively recently I've begun to notice a small but growing trend of people switching away from or back to languages like Go and Rust. In an absolute sense, yes, Python is still dominating and growing.

The trend I have noticed is a very small but growing cohort of folks who are coming back to languages like Go and Rust.

Are you familiar with the Go standard library? It’s notorious for its comprehensiveness and how often you can write zero dependency applications as a result.

And there’s a reason: the Go designers were huge Python fans, so leaned on its design quite a bit. They essentially wanted to make a modern Python with first class support for static typing and highly scalable parallelism, not just concurrency.

Quick tangent if you’re willing to humor me…

I've been noticing that many new projects that would have been written in Python or Node a year ago are starting to be written in Go, Rust, etc.

Theory: people realized there’s little benefit to Python for agents. As Zep wrote, an “agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human[1]” — not a particular strength of Python.

I'm wondering if you'd considered Go (or others—Go’s just my fav ) before landing on Node, and more broadly whether you've noticed a similar pattern?

1: https://blog.getzep.com/agentic-development-in-go/

I must be misunderstanding something, because I can't imagine that training would-be predators would significantly reduce the rates of abuse.

Perhaps I'm mischaracterizing it, and it's about training those around potential abusers on how to recognize signs of abuse and adopt tactics that prevent it? Or it's about training _children_ to recognize what's unacceptable and how to report it safely? Or something else entirely?

Regardless, your conviction in the efficacy of the training grabs my interest. Could you share more about it so I'm not working off of incorrect assumptions?

You also mentioned that their abuse rates are lower than schools. Do you happen to have a source for that — I’d be interested in educating myself on that as well!

I'm not a Catholic (nor religious at all), and do question whether schools truly are worse than churches in terms of how children are treated.

But that's not the point. You made up a quote I didn't say ("demonization"), and accused the former poster of doing something they weren't: defending the church.

Saying that schools are worse yet ignored is not defending the church. It may also be incorrect, but that's a separate assertion.

Where did you see apologies?

I read it basically as “schools are even worse than churches and scouts yet are overlooked,” nothing apologizing for the churches.

I hear you. Coincidentally, I was actually called out just last night for a message with em dashes:

“Are you AI-ing me? Em dash giving you away”

It’s a pretty load-bearing (lol) example, yet it was clear in context it wasn’t serious. I’m beginning to notice people getting pretty good at detecting AI content, which I find reassuring.

It makes sense: AI-written prose is basically the homogenization of all styles of writing into a single voice, so it’ll stand out against the unique personalities we are used to seeing. It is just taking a minute for the average person to gain literacy — but it seems to be happening rather quickly, again unsurprising since we’re such social monkeys with a lot of our 15 watt brains dedicated to socialization and identity recognition.

Use your em-dash proudly!

Truly enjoyed this article, but hate to admit one thing: I'm so burned by AI slop that once I noticed this seems to have been "assisted" by an LLM, I got irrationally angry because I felt tricked.

It hit me at the end, when I read this:

> The idea behind Ambiance is simple: the model's priors [...] Everything else here is just in service of that.

I've noticed "in service of" take off similar to "load-bearing" with LLMs, and the whole structure just pattern matched to Claude for me.

I went back and scanned it over again, and noticed several other tells:

* "Think of U/L [Unix / Linux] as a motivating analogy rather than a direct comparison." * "Priors" _and_ "a priori" used in the same article. * "A real kernel […]. The Ambiance Kernel […]. The Kernel […]." — LLMs love this pattern.

To be abundantly clear, *I'm not calling this AI SLOP*; it's obvious that a human put a lot of thought into this, gives a shit about the topic, and shared interesting ideas leading to a productive discussion. I really did like it.

There's just something empty or hollow about the LLM style; paraphrasing Joni Mitchell "there's something lost and some thing gained" [1] when using AI. Your writing, your code is more consistent, more structured, more planned out — generally better but in a way that loses the character behind human writing.

[1]: From "Both Sides Now", a great song about looking something from two perspectives: youthful innocence, and jaded cynicism. Listen to the original 1969 version first, and then the 2000 remake as you can tell she's singing from the respective perspectives. Deeply meaningful song!

I believe you and OP are in agreement — they were saying that the 2019 book had them, therefore the terms _do_ predate AI. Your point that AI was being trained on material than is load-bearing (lol) but in agreement with OP, not contradictory.

Only mentioning because your "actually" may imply you thought you were disagreeing, when in fact it's one big happy family!

Interesting! I'd love to hear what type of work you do where you can get away without any of those because frankly I think most of those are pretty garbage too.

Postgres is decent for a free ($$$) database, although it's lack of clustered indexes and in-place updates (its MVCC approach) sucks for many use cases. I find it a sensible default but not the best at any one use case.

Python, frankly, sucks nowawadays. Maybe it had its time, but there are so many better lingos now. It's got type hints that are ignored, really bad patterns ("dependency injection" that's really just the singleton pattern, FastAPI encourages you to open a db connection and a transaction at the front of every request and commit at the end while you're making other requests, writing to disk, etc), and it's slow in both user experience and runtime (no real parallelism).

But generally I have to make some trades to get a great job. I love Go, personally, and the incredible simplicity it encourages.

Seriously, if you'd be willing to share, I'd love to hear what you do!

If you're actively looking for a job, you should have some familiarity with the common dev stack when you're looking. Today you should be comfortable working on a Mac, know Bash / Zsh, a little bit of Vim for SSHing, git, docker, react, postgres, etc.

If you don't, spend a few weeks before you start your search. You're almost definitely going to need them. Unless you're in a niche where the common stack is different.

This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing, you're going to stumble without cursory knowledge. You don't need to be an expert in it all…

First come first served is capitalism in disguise. Someone will automate a tool that watches for these and jumps on them, and the person with the most resources, can get a close network connection, etc will "buy" it.

Same with waitlists.

It's impossible to avoid capitalism!