I had thought that months aren't quite a human construct, they correspond roughly to lunar cycles. Weeks were a way to carve the month up into the four lunar phases per cycle.
Seconds, minutes, hours, etc. are, as you say, all sexagesimal math bias.
You're right about months/weeks, I was imprecise in the post: calendar months (as we now use them) are a weird cultural construct (I mean who would divide a measurement unevenly and though that was a good idea?)
Someone actually mathed out infinite monkeys at infinite typewriters, and it turns out, it is a great example of how misleading probabilities are when dealing with infinity:
"Even if every proton in the observable universe (which is estimated at roughly 1080) were a monkey with a typewriter, typing from the Big Bang until the end of the universe (when protons might no longer exist), they would still need a far greater amount of time – more than three hundred and sixty thousand orders of magnitude longer – to have even a 1 in 10500 chance of success. To put it another way, for a one in a trillion chance of success, there would need to be 10^360,641 observable universes made of protonic monkeys."
Often infinite things that are probability 1 in theory, are in practice, safe to assume to be 0.
So no. LLMs are not brute force dummies. We are seeing increasingly emergent behavior in frontier models.
> It is unsurprising that an LLM performs better than random! That's the whole point. It does not imply emergence.
By definition, it is emergent behavior when it exhibits the ability to synthesize solutions to problems that it wasn't trained on. I.e. it can handle generalization.
Emergent behavior would imply that some other function was being reduced to token prediction. Behaving "better than random" ie: not just brute forcing would not qualify - token prediction is not brute forcing and we expect it to do better, it's trained to do so.
If you want to demonstrate an emergent behavior you're going to need to show that.
I'm all for skeptical inquiry, but "burning all credibility" is an overreaction. We are definitely seeing very unexpected levels of performance in frontier models.
Third things can exist. In other words, you’re implying a false dichotomy between “human computation” and “computer computation” and implying that LLMs must be one or the other. A pithy gotcha comment, no doubt.
Edit: the implication comes from demanding that the OP’s definition must be rigorous enough to cover all models of “computation”, and by failing to do so, it means that LLMs must be more like humans than computers.
I think you are vastly underestimating the emergent behaviours in frontier foundational models and should never say never.
Remember, the basis of these models is unsupervised training, which, at sufficient scale, gives it the ability to to detect pattern anomalies out of context.
For example, LLMs have struggled with generalized abstract problem solving, such as "mystery blocks world" that classical AI planners dating back 20+ years or more are better at solving. Well, that's rapidly changing: https://arxiv.org/html/2511.09378v1
No idea how underestimate things are, but marketing terms like "frontier foundational models" don't help to foster trust in a domain hyperhyped.
That is, even if there are cool things that LLM make now more affordable, the level of bullshit marketing attached to it is also very high which makes far harder to make a noise filter.
there should be only 3 regular meetings in an agile engineering team
- weekly iteration planning (1-2 hours max)
- daily standup (15 mins max)
- weekly demo & retro (1-2 hours max)
literally everything else is work off the kanban board or backlog.
in my teams everyone was told to decline all meetings unless it explicitly led to the completion of a weekly planned story/task. this way all meetings for the team have a clear agenda and end in mind.
for mandatory external meetings & running interference with external parties, there are ways to insulate the majority of the team from that.
Is that three kinds of regular meetings? Because I count 8 meetings (and four kinds, as I don't think I've ever had demo and retro combined due to different groups of people being in both).
Not correcting, just clarifying for myself. I sure wish I had such a controlled environment with only 15% of time in coordination and where standup actually was 15 mins and not a segue into the everything meeting.
that's really what agile was supposed to be. at least in the places where I saw it was successful.
every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design.
every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.
Yes, but expanded to the full deadline instead of only the short iterations.
The business does not care about week long deadlines. They need something on May 23 so they can achieve _______.
My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen.
But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.
However the point of the weekly cadence is that the business does care about adjusting scope and priority towards hitting that deadline on May 23, so that they know what they're going to get on May 23 and have the power to adjust it.
Especially if the goal of what is delivered on that date is not clearly defined. It almost never is.
Most projects can be summed as "give me $X, I'll come back in 6 months, and ask for more time and money". or "here you go"... "that's not what I wanted".
It's a key risk mitigation toward a hard date to know every week if you're still getting what you wanted.
Velocity is overblown as a metric. It's one metric among many that can signal a few things (e.g. quality problems because bug fixes are overtaking features) but isn't as much of a lever as some say.
Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.
I had thought that months aren't quite a human construct, they correspond roughly to lunar cycles. Weeks were a way to carve the month up into the four lunar phases per cycle.
Seconds, minutes, hours, etc. are, as you say, all sexagesimal math bias.
reply