disconcision

not exactly the same, but worth noting that in a spectacular display of being too early, microsoft shipped this 30 years ago (active desktop in 1997 merged the windows explorer with internet explorer, turning folders into web pages).

i assert that by your evidentiary standards humans don't reason.

presumably one of us is wrong.

therefore, humans don't reason.

all three are isomorphic. but in some languages if you define a function via something like `function myFun(x: Int, y: Bool) = ...` and also have some value `let a: (Int, Bool) = (1, true)` it doesn't mean you can call `myFun(a)`. because a parameter list is treated by the language as a different kind of construct than a tuple.

speed of plane is about 3% speed of satellite so i wouldn't expect handoffs to be much more frequent than with stationary receivers?

i can't speak for everyone, but in the above assertion am using 'roughly exponential' to mean that world population between say 1880 and 1960 followed a curve that is, roughly, exponential, in the technical sense. much of the discourse 50 years ago, e.g. the population bomb, was predicated on this observation.

we had nearly 2 centuries of roughly exponential growth. ended in the 60s but not everyone got the memo

> so no operator precedence seems like a massive foot-gun

how do you mean? given that spec, ambiguous code just won't compile. that could potentially be inefficient, but not a foot gun.

not obvious to me this makes things better as opposed to worse? sure, the time bound helps but in the runup to a crunch won't we get vastly more devices in causal range at an asymptotically increasing rate?

never thought about it before but after playing with it a while i notice i tend to approach from the right, which means moving out if i'm inside on the right side. i think this is because my positioning accuracy seems to be higher moving leftwards than rightwards...

for better or for worse, most specific scientific jargon is already going to be in english

I've yet to be convinced by any article, including this one, that attempts to draw boxes around what coding agents are and aren't good at in a way that is robust on a 6 to 12 month horizon.

I agree that the examples listed here are relatable, and I've seen similar in my uses of various coding harnesses, including, to some degree, ones driven by opus 4.5. But my general experience with using LLMs for development over the last few years has been that:

1. Initially models could at best assemble a simple procedural or compositional sequences of commands or functions to accomplish a basic goal, perhaps meeting tests or type checking, but with no overall coherence,

2. To being able to structure small functions reasonably,

3. To being able to structure large functions reasonably,

4. To being able to structure medium-sized files reasonably,

5. To being able to structure large files, and small multi-file subsystems, somewhat reasonably.

So the idea that they are now falling down on the multi-module or multi-file or multi-microservice level is both not particularly surprising to me and also both not particularly indicative of future performance. There is a hierarchy of scales at which abstraction can be applied, and it seems plausible to me that the march of capability improvement is a continuous push upwards in the scale at which agents can reasonably abstract code.

Alternatively, there could be that there is a legitimate discontinuity here, at which anything resembling current approaches will max out, but I don't see strong evidence for it here.

with the exception that it doesn't seem possible to fully disable this for grok 4

you can (via the api, or to a lesser degree through the setting in the web client) determine what tools if any a model can use