> herd a group of toddlers

It's called a fancy word "steering". Most of engineering is now steering or providing "taste" to AIs so they don't produce slop

Related:

Bend - a language that blocks AI mistakes via proof and runs on GPUs https://news.ycombinator.com/item?id=49746163

> lot of strain on the server-side

That's why GitHub assigns "points" to each requests and deducts based on the data shape you request. For simple requests it's 1-to-1, but can quickly balloon

GitHub's "paid" rate limits are the same as GitLab's free tier, so no, it doesn't help

> LAWS.bend

I like the law idea, but what i found they end up doing is they just modify the law itself to fit the new feature they are working on, which defeats the point.

Which means some laws needs to be frozen. But not all laws, otherwise you can't add or modify anything. So the judgement is still on the human part, and we're back to meatbags being the bottleneck.

I've seen some success adding these proof-like checks to CI every time agents do something irrational. I definitely think it should be part of every codebase.

There's also https://code-contracts.cc/ which co-locates code and proofs together.

Yeah, you want to at least read what the AI is putting on LAWS.bend. It is substantially smaller than the codebase. Ultimately LAWS.bend makes you need to read astronomically less code. Not zero code.

> With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out.

This is a solved problem. They just dump it into a file and `jq` or `rg` to find the stuff they need.

Agents are smarter than you think. They've been hill-climbing for generations in their RL environments.

The ones that get their context window blown out don't survive to launch

> But I do believe that all coding will be AI-assisted.

> If all coding is AI-assisted won’t it just be referred to as… “coding”?

It already is, and it's called engineering.

The value is how much steering you can provide. Whether it's in the form of domain knowledge or "hardcore" engineering is beside the point.

Taste is all we have left.

Every single `reduce` can be replaced with a more intuitive `groupBy`, `partition`, `mapValues`, `keyBy`, etc.

Reduce can approximate anything, that doesn't mean we should use it.

My favorite antipattern is

  items.reduce(
    (acc, item) => ({
      ...acc,
      [item.id]: item,
    }), {}
  );

Like, why? Not only is this ridiculously inefficient O(N^2), it's also longer and less understandable than "build a new map" version.

I think this along with the other answers discussing the difficulty remembering the specific arguments of `reduce` (especially when varying by language!) are key reasons. After reading this conversational thread, I think maybe Microsoft got it right with LINQ: - `Where` is perhaps more intuitive than `filter` - `Select` seems no worse than `map` by invoking SQL-like syntax - While `reduce` is preserved as `Aggregate`, provide `GroupBy` and other handy methods as the preferred methods. In the code I write, it's probably these other methods that get called 95+% of the time. Who wants to `Aggregate` when they can simply `Sum` for example?

This one doesn't seem expressible in those terms:

    from functools import reduce

    df = reduce(DataFrame.union, dfs)

> And yes, the paper is already outdated

The paper is about the fact that the benchmark’s evaluator is prone to egregious incorrect rejections of what answers that it should accept. A new model will not invalidate that issue.

This is getting ridiculous. Is 5.6 not considered good enough to conduct experiments with anymore? Two months ago, if you weren't using 5.6, you were doing it wrong.

Now, you can't conduct experiments using the default model?

Why is it so surprising that frontier can move that fast?

Starting to feel more and more like chinese room experiment

The models are confidently answering physics questions, treating it as a math problem, but they don't fundamentally "get it" and even recently failed simple "should i drive to car wash" test

The sample efficiency is just crazy low

Still surprising that even with this they managed to saturate the benchmarks

Searle's thought experiment just kicks the can down the road.

Since the room as a whole produces fluent Chinese it becomes a language philosophy debate about where meaning comes from. Brandom's inferentialism gets into this more than any normal person would ever care to read about.

LLMs really show the absurdity of the Chinese Room rulebook.

The whole thought experiment should really be left to history at this point.

Searle’s social ontology is much more interesting also but this outdated thought experiment completely overshadows his more interesting stuff.

> they don't fundamentally "get it"

There's no clear decision criteria for this. Do trick questions demonstrate that most people don't "get it"? And, well, older model saying dumb things doesn't establish a general principle that LLMs don't "get it" in general.

> The sample efficiency is just crazy low

Autoregressive pretraining requires huge amount of data to go from a blank state to a somewhat functional model. Fine-tuning, LORA, reinforcement learning of foundation models and in-context learning are much more sample efficient.

> Chinese room

...creates a wrong intuition that by cranking a Leibniz's mill you are somehow responsible for whether it understands something or not.

> Do trick questions demonstrate that most people don't "get it"?

"Should I walk to the car wash" is hardly a trick question. If a human told me to walk to the car wash because it's so close, I would say that demonstrates they don't "get it".

I don't see that much difference with "A plane crashes on the border of the United States and Canada. Where do they bury the survivors?"

Fast thinking fails to activate slow thinking.