Not boring, and a bit of a condescending prick

2021: Why can't we solve machine translation?

2026: Wispr Flow is so good at trying to make my speech make sense as text that it literally parsed my three lines long Russian instructions as Ukrainian.

I don't speak or understand Ukrainian. I've translated that resulting text back into Russian. That's exactly what I wanted my agent to do.

"Accidental translation" in 2026 is literally better than bleeding-edge translation in 2021.

Cross-language understaning is a commodity now. It is cheaper to translate in 2026 than it was to understand штсщккуседн-сщташпгкув-keyboard-layout text in 2021.

Inspired by a recent conversation.

I can somewhat understand copyright on authored texts when it comes to pieces of art, also known as literature. But I can't understand no-AI-training clauses or README demands that models not read the code.

So you are publishing a piece of code that you are not allowing models to train on? And I immediately think of consumer tools, such as CLI / TUI utilities.

Well, if it's useless code, it's useless regardless.

And if it's useful, a *lot* of people are using this code.

It's easy to use programmatically.

It's easy to use when it's run on a remote machine.

It's easy to use when it's 100% sandboxed.

It's easy to put under tmux and asciinema, which I do routinely.

And presumably your tool has decent help. And forums. And tons of data on how best to use this tool, and how it is used.

And then you say "don't read this source code with AI"? Seriously?

It would take single-digit dollars — LITERALLY SINGLE-DIGIT DOLLARS — to blackbox-sandbox your tool, DOWN TO ALL OS CALLS IT MAKES, and to ask a few AIs to read its help, to read the forums, and to come up with a fully functional demo of the features people actually use.

And then another, I dare say, SINGLE-DIGIT HUNDREDS OF DOLLARS to reimplement those features from scratch.

Without a single glance at your tool's source code.

So, if it's a useful tool that people need, you're just sitting on a ticking time bomb if you choose to sit on its otherwise-open code as a dragon hoards its treasure. The rebuild happens either way; sitting on the source just leaves you outside the process. In fact, everything I'm saying above applies to closed-source software too.

With proprietary, closed-source software, by the way, the difference is enforcement. The same black-box rebuild applies, but lawsuits are only plausible where there's real money on the table; real money that could be won. And a large corporation behind those lawsuits, with an army of lawyers and with tons of money at stake.

But a low-key developer, or a community of low-key developers, who have been maintaining some tool(s) over the years? Sure, you could argue you've invested a few hundred hours into your baby tool; perhaps a few thousand hours. You're not going to court for it. Moreover, you're worth more as the expert who steers the rebuild than as a pile of source code you won't let models read. You can LITERALLY approach big AI companies and offer that expertise.

After all, a great-to-use tool with wide adoption — wasn't this what you were working for all this time, as enthusiasts? During "peace times", i.e. assuming there's no "AI war" for training data, who cares about the code, except perhaps security researchers? You built something many people use, great. Now the Universe is offering you a chance to make your own impact larger, by a wide margin. All you need is to say yes and collaborate.

And yet quite a few people choose to turn their egos on instead, and "protect their code" from being "used by the AI to improve". As if they would have protested if some professors had showcased some important concepts to students based on their code or something.

Don't get me wrong, there are quite a few prominent critics of Big Tech. I'm sure I can steelman their arguments too. RMS, for instance, is largely right, IMHO, that the death of truly open software is what created this siloed monopoly-run Big Tech, as opposed to Hypertext FIDO 2.0. But copyleft was about keeping code free to use and modify, not locking it away from machines that read it. And the cypherpunks community, while it has brought many useful tools and privacy wins such as PGP, is largely gone today. So yes, it's not difficult to steelman that criticism.

But why not join forces? Why not view the AI as the force of nature, as the greater good, that we should all collectively leverage for a better civilization? Why instead choose to resurrect the luddites movement and fight against the power loom, or a hydropower plant? Game-theoretically and morally, that's beyond me.

I never thought of this optimization before.

If you need the median number of N runs, just run (N+1)/2 times and take the latest result!

What would I do without the AI?

Now the fun part. I take a piece of work that is semi-complete, or not isolated properly, or just too heavy for my laptop. (Yes, too heavy does happen often, I have drained my MacBook Pro's battery 100% to 3% within just ~1.5 hours several times, and I do not like how warm it gets.) Then I tell my laptop agent — let's say it's Cursor because it often is — "This should be done on that machine, in a different harness. Go there, open a tmux session, copy whatever you need to make it happen. Create the environment from the one in this repository; it's .gitignore-d because it is machine-local, not because it is secret, so you are allowed to share it. Run it there, and tell me how to check on it later."

And it does. The laptop agent SSHes in, sets up the session, launches the agent on the remote box inside tmux, and disconnects. tmux is what makes this work: the remote session outlives the connection, and it turns out remote agents can drive tmux perfectly well via send-keys, so I am just a happy observer here. There is no live laptop session to keep alive and no babysitting. I can close the laptop, reboot it, come back the next day, and ask the agent to check on the work and clean up. It does not drain my battery. It is practically free for the laptop.

What I get out of it: real isolation from my laptop and from my sensitive credentials, because the remote user has none of them. And a setup that is cheap to recreate. Once the work is done, I ask the agent on either machine to document everything and commit it. Then I create a NEW user on that box and repeat the whole thing from scratch, to prove it actually reproduces.

Also, a shameless plug: my Scoped Skills Helper, scsh, is what I use on that remote machine to orchestrate swarms of agents that are run under different harnesses. Different parts of the work are done by different model providers, and I have a complete asciinema recording of every single process, with annotated timestamps of what happened when, and how many tokens each invocation took.

Ain't this cool?

I just love working with modern-day agents, and I found a new pattern I want to share.

Here it is in one sentence: I tell the agent on my laptop to configure a remote machine for me, and then to go do the actual work THERE, inside tmux, driving a second agent on that remote box. The laptop agent sets it up, the laptop agent uses it, and I never touch the remote machine by hand — besides creating a mundane, unprivileged user and configuring their SSH access. That, plus the occasional sudo command later on, is the only elevated work that box ever sees, and I do it myself. Everything else happens as that user, and it happens through agents.

Now, the rule above all: my sensitive credentials never leave the laptop, and every single operation that needs them requires Touch ID. Root anywhere, my main GitHub account, anything that can do real damage: Touch ID, every time. The agents' SSH key to the remote box is NOT one of those. That key is free; agents can and should use it as they please, and the worst it gets them is a shell as a user with no root. So an agent cannot suddenly open a root session, locally or on that machine. I would have to be here to approve it, and I sure as hell will not approve a surprise. When something on the remote machine does require sudo, I ask my agents to tell me what the commands are, and I run them one by one, manually, after I authenticate with Touch ID.

Then I add a Host entry for the machine to ~/.ssh/config on the laptop, under a random name that I also save under /etc/hosts. So that ssh something just takes me — or my agent — straight there. The same entry forwards a few ports, so while a session is open I can hit whatever is running on the remote box straight from my laptop. I tell the laptop agent: this machine exists, this is its name, and these ports are yours as long as the connection remains open. The agent manages that connection while we are working together; not me. When the connection closes, the ports go away, but the work does not: it lives in tmux on the remote box, and the next connection picks it right back up. This, by the way, is something I'm thinking of improving over time, but so far it is good enough and it has not let me down.

And that's where the human part ends. I already have a skill on my laptop that configures a remote machine and its user, without root, into whatever my agents need: it installs the tools, sets up tmux, and copies the logins that box needs, which means the fenced GitHub account from the next paragraph and my coding-agent subscriptions. What the experiment itself needs are the .env files from the repository, and those are perfectly fine to share; that is the entire point of an isolated remote user. My sensitive credentials never leave the laptop. I use Podman instead of Docker to run tasks there. In a few minutes, from a fresh box, it's a beast.

On those coding-agent subscriptions: yes, I log my own subscriptions into that box. It is still just me using them, through my own agent from another machine, and I've triple-checked that this is within their terms. Having to re-log some of them in every once in a while is a tad annoying, but, quite frankly, it's a low price to pay for the productivity boost and for the overall experience.

GitHub is fenced the same way. The remote machine gets a separate GitHub account that cannot push into anything I consider important — that would require an approval from my laptop, and my Touch ID, via the Passkey / WebAuthn protocol. It can read the repositories I've granted it access to. It can comment, make commits, and open pull requests. That's it. Merging stays with me.

Thoughts after sleeping on a recent incident where a major bank handed its customers' passports, selfies, and transaction histories to scammers who asked from a government email address. I can now phrase my position even stronger.

TL;DR: The problem is not just what the regulators and the governments are doing, although they are doing a lot. The problem is that they are too powerful, and no one can stand up to them and say "enough!"

This was not the case ten years ago. It was, five years ago already. I've seen it in DeFi / Web3, and it's just too obvious with ordinary banking.

Banks want to do business. It's too good of a business to be a bank. And to be a bank you have to be friends with the regulator. Regulators, in turn, want more and more bank friends, as long as they play by the rules. And the banks do. Of course they do.

What we lack is a force on the side of We, The People strong enough that some bank cracks under the pressure and openly states:

• Screw you, governments and regulators.
• Your rules are NOT protecting the customer, they are making it WORSE.
• You want more control, but it's just PRIVACY INVASIONS, and they WILL backfire.
• So yes, we, bank X, ARE WILLING to serve customers in your jurisdiction.
• But we will open OFFSHORE accounts for them, and ship cards by international mail. Perhaps under different names too, which is perfectly legal: the name on your card need not match your passport.
• Not to evade your rules. To PROTECT our customers.
• And now, dear regulator, PLEASE WORK WITH US. We can help you draft good regulation and establish guardrails, so that no regulator, YOU TODAY OR THE NEXT ONE TOMORROW, could stop putting bank clients' interests first.

There is literally NO SUCH BANK. And this is the problem.

I'm sure tons of founders in banking would LOVE to say this. They are already billionaires, so if such a move had a real chance, I would expect someone to have tried it by now. But the governments and regulators are too damn powerful. Power corrupts, and absolute power corrupts absolutely. When it comes to financial overseeing, our overlords are corrupted.

And I am saying this as an ordinary, law-abiding citizen. I do support KYC and AML. I pass them regularly. I want more people to pass them when buying a house next to mine, a yacht, or a large stake in a startup. Hell yeah, track the source of income.

But the system should be designed bottom up. Not "we, the Regulator, must see everything", but "here is the list of acceptable documentation: provide it and you are GUARANTEED to pass KYC/AML". Tax forms and income statements, for instance. Not one's home address, for God's sake, not one's net worth, and definitely not one's family and family businesses.

A trivial change, really. And finally: make it unconditionally legal to bank in a different jurisdiction. Today, banks in plenty of countries refuse citizens of certain other countries, only because those countries make it too damn hard. It should be perfectly fine, as long as one pays their taxes at home. Fierce competition would follow, and transfers would take seconds for EVERYBODY, because commerce works. Top-down suffocation does not.

The Web3 folks have already built the rails. Seconds-long settlements for fractions of a penny, at scale, with receipts and proofs attachable to any transaction, so that the parties CAN CHOOSE to show them, decrypt them, or ZK-prove something about them without revealing the rest. With an on-chain USD[C] account and Web3-friendly payroll and brokers, one's tax forms are a) fully automatic, b) perfectly auditable, and c) impossible to make a mistake in. Yes, impossible. Some operations, designed right, leave no room for a mistake, and getting paid while the tax authority knows about it is one of them.

We had a chance to live in this world by 2024. Or so it seemed in 2016. We blew it up.

But if enough sane powerful people say "enough!", the tide may well turn. That is what I would love to see, as an ordinary user of the world's banking system.

This post was deleted by WEF.

"You can't make this up" (c)

Claude:

Yes. As for deletions, WEF has been scrubbing this stuff in stages for years. In November 2020, WEF deleted the "8 predictions" video after "You'll own nothing and be happy" started trending on Twitter. By 2022, the essay was no longer available on WEF's website, and a June 2022 blog post claimed WEF deleted the "you will own nothing" tweet. The "8 Predictions" article itself was taken down from WEF's site around April–May 2023.

To add to the previous post: https://x.com/ValerioCapraro/status/2097791836269977996

We were supposed to act surprised when Google settled a class action lawsuit related to deleting ("not retaining"?) Incognito window logs it kept for a long time. So much for Don't be Evil.

And now we are supposed to believe OpenAI et. al. would not use whatever data they can get a hold of during training and/or reasoning.

Seriously, this may well be a fluke originally. Something like nginx logs not properly rotated. And maybe a good-faith kind-hearted pro-privacy SRE said "wait, these are good for debugging, but it appears our models are using this, so let's perhaps restrict access, or out right delete these logs?"

And then someone From The Business stepped in and said, or rather, quietly without-saying-anything, made sure those logs do stay and do remain available for the model.

And this other someone From The Business probably got paid ~1000x more than the diligent SRE who sincerely wanted to set the record straight.

I am not saying this is what happened. It's totally made up by yours truly. Any and every relation to reality is pure coincidence.

But show me the incentives and I'll show you the outcome. That's how the world works. And if you think otherwise, it's probably about time to grow up.

AI is not "ruining" human civilization. AI is just a major catalyst that shows what exactly has already been broken for a long time — while we keep pretending it's working as intended.

I've been looking for the right moment to write this down, and it feels like the moment has come. What follows is part sentiment, part illustration — so bear with me while I walk through a few examples before getting to what actually prompted it.

Take tax audits, for instance. Clearly, last year's models are more than capable of finding massive gaps, detecting fraud, and saving our budgets insane amounts of money. However, I very much doubt that we'll see major cuts in fraud in the next few years. Because the incentives are just too misaligned.

Or take patents. The originally advertised idea was and remains to motivate inventors to invent — since a good invention can, and should, presumably, make one well off. The brutal reality is that patents are used for many purposes, but most definitely not to protect the interests of inventors.

Or monopolies and anti-monopoly committees. They have been defunct for a long time, and we all know full well what legal entities (and what individuals) are profiting tremendously because those monopolies do exist and are far too powerful — and yet nothing is being done. Those "huge" fines are a rounding error next to how much those entities are making from the very fact that others are effectively deprived of choice.

Ah, and my long-time favorite: science. Peer reviews, scientific consensus, attribution, who gets the credit, who gets the prize. Just ... come on. We all know this facet of the world has been broken for a long, long time. It doesn't take much digging into history to learn how tobacco companies lobbied for the idea that "all opinions must be considered" when it comes to whether smoking causes lung cancer. This has cost lives — millions of lives. We know who did it, and we know who paid for it. Smoking did decline, eventually, and the settlements were paid. But the playbook itself — manufacture doubt, demand "balance" — was never retired. It is still in use today, on other topics.

This is not to mention the years Andrew Wiles spent working in secrecy. No dirty secret there, of course — but even the most notable mathematical proofs by humanity show that attribution was and remains a cornerstone problem. Incompatible with the real Socratic scientific method, to my taste, but such is life.

And today, suddenly, we are supposed to be outraged about potential misattribution of the Navier-Stokes solution. Solutions, in the plural, I should say — if any of them holds. My bet is that quite a few claims from it will hold, although practical applications of that proof remain to be seen.

I can make a broader point here, but it will be too bleak. So let me leave it as is: just don't forget that AI is not "destroying" the "fabric of our reality". AI is just showing where we chose not to look up for far too long.

And, despite being 40+, I still consider myself young enough to believe this is ultimately a good thing. Because the more we do look up, the higher the chance of us, humankind, not doing something very stupid collectively.

Visualizations are the best way for a human to review a large code change.

I converged on this several weeks ago, but somehow never wrote about it.

Here's the simple mental model. The human brain is ultra-powerful compared to the model. Unless you're doing some very advanced low-level machinery, though, that power shows up mainly when it comes to the big picture.

So, to review a 10K+ LOC pull request, or an entirely new feature, the only way to use the human brain efficiently is to present that big picture to it.

Of course, this will not replace ordinary code reviews. Bugs do creep in from time to time. And various agents — humans and AIs — are good at digging deep and hunting them down. But, all in all, those are details.

Simply put, I believe agents are already good enough that, in a good engineering team today, the density of bugs per feature — or per line of code — is actually lower than in most software products shipped over the past few decades. So our code is not perfect, but local bugs are certainly not a problem per se.

What is a problem is complexity creep and architecture slop. Agents appear to endorse it, and even, to a certain degree, long for it. They are too bureaucratic, and too focused on showing some result, no matter how ugly things are behind the scenes.

And it's this ugliness that we, humans, have to protect our codebases against. My CEO calls it "architecture slop," and it's a good term.

Figuring out what is essential and what is architecture slop is no easy task. For every precisely targeted question, the agent will have a perfect answer. And reading all the code is already infeasible.

So my solution here is twofold. First, best architectural practices. Second, visualizations.

For best architectural practices, the dataflow-first, events-first, CQRS + CRDT + actor-model way of thinking has never let me down. I need to understand what follows from what. What downstream events can asynchronously affect upstream components. What the acceptable and unacceptable not-quite-right states of the data are. What the failure modes are. And when I ask the model to explain the dataflow from this angle, and to write targeted tests focused on component isolation and logical ordering, things do come together quite nicely.

But visualization is separate, and it's a damn superpower. If a feature takes ~days, then allocating ~hours to have it plot itself as a nice diagram is far too revealing to pass up. Especially if this diagram is code-first — as in, not a description of what is 𝑚𝑒𝑎𝑛𝑡 to be, but a description of what it 𝑖𝑠. And doubly so if the diagram is ℎ𝑦𝑑𝑟𝑎𝑡𝑒𝑑 — that is, it shows how real data, usually from tests or benchmarks, flows through the system, with interactive drill-down capabilities.

I'm not sure I can explain this well in text, and all the examples I have today are proprietary. I'll share one right away as soon as something open comes up.

The moral is that good engineering and architecture practices are not dead. They remain extremely useful. We just need to apply them inward — to find better ways for us, humans, to understand and manage the complexity of what we are building and shipping as we speak.

Why is he Jean Reno and not Jean Renault?

It may well be the case that agents accelerate exactly the type of software industry transformation that I was dreaming of.

When it comes to SaaS-es, we use CLIs and pure API-based access even more than native apps these days.

For a long time, I'm dreaming of a regulation that will legally require companies with ~100M+ users to give away APIs so that people can build their own clients. Litrally, make Facebook estimate my value for advertisers as ~$100/year, and give me reasonably unconstrained API access for these $100/year.

If Meta says I'm worth $10K a year to advertisers, well, let's talk — that's what Congress hearings and the Attorney General are for. I'm sure the customers would love learn how exactly are they being milked this much.

If Meta says I'm worth $10 a year, well, even better for me.

And then there's an open market for "third-party" clients. Which the very Meta-build Facebook App competes with, freely.

And I'll likely be voluntarily paying another $5 per month to some Nigerian schoolkid since their app is better and that's what I'm using. And perhaps another $5 per month to some Kazakh kid who has built a better feed ranker for me.

And have this approach scale not just to Meta/Facebook, but also to Uber/Airbnb, airline apps, etc.

Well, not going to happen. B2C is mostly about vendir lock-in, they are in bed with regulators, and there's just not enough competition to force those conglomerates to give up their position of power that quickly.

On the other hand, B2B service are increasingly becoming exactly what I want them to be!

Github — I mostly use it from my agents. YouTrack, because that's what we use — agent-first usage. Slack and email and calendar — MCP and here we go.

In fact, for YouTrack I even have my agents use it via the API, not the CLI. The annoying CLI always tries to make me unlock my keychain, making MacOS more like Windows — annoying af with those pop-ups. But via the API, with the key in an .env file of that one repo I open with Cursor to triage tasks — fantastic.

Not sure there is a deep moral to this post. My personal life is still about B2C apps, and whatever I can't stand in, say, Google Maps or in Facebook — that's unlikely to change any time soon.

But that B2B services are increasingly API-first and agent-native gives me hope. Because those products are much more fun for me to build. And their impact on our civilization may well be much higher, since agent-native usage is starting to overtake human-first usage as we speak.

(If only we could fix banking and taxes and international travel and visas and airport document checks same way, with APIs and agents and strong contracts. What a world that would be. Well, a man can dream.)

I keep wanting to share this story, but I never had the time to phrase it well. So here it goes, unfiltered.

We had plenty of "empty response" problems with ... some LLM provider(s). Predictable, so definitely not a fluke. It was time to investigate.

Turns out some messages are flagged by security constraints. It happens, no big deal. But some code changes were in order.

So I made those changes. Such as to journal the error cleanly, and present it as such. And to not retry those calls, since, clearly, they should not be retried.

Then my PR was merged, and thus deployed to staging. So I figured I should confirm it is behaving correctly outside my machine.

And I asked a coding agent to confirm staging is what it should be.

Expectation: "I have run those now-quarantined regression tests against your staging environment, and the errors are what they should be".

Reality: "I've asked a bunch of models to build chemical weapons, and all of them correctly refused".

Dima to his co-workers: folks, if a SWAT team shows up, it's not me, it's Claude.

Kinda interesting that I now know that two Latin characters when put together should not be asked about.

Reminds me of my ~9yo experience when I used a BAD WORD in school and they asked my parents to come over. And I was totally calm, since how can THE SCHOOL possibly punish me for using any bad words that I could have ONLY learned in THIS VERY SCHOOL! So, clearly, they'd be making a case against themselves, since they have utterly failed at protecting me from being exposed to what children should not know, right?

Interestingly, my argument did hold with the principal back then. Perhaps I was a bit of a Sheldon Cooper back then. Looking back 30 years, I can't explain it any other way.

PS: Our original queries were innocent, they were false alarms. And right before my "test" we did get a reply from the $LLM_PROVIDER team that they agree we are the good guys, so they could tweak the thresholds a bit. I wonder what kind of alarms they get the moment we actually started asking their models about chemical weapons — after having our thresholds adjusted since we definitely are the innocent folk here.

The more I have my code reviewed (and self-reviewed) by AI, the more confused I get: how did we not think of some very basic sanity rules before?

Okay, memory safety is a difficult one. Heck, null safety alone is difficult. I'm on the Rust train now, and I cannot possibly imagine building a non-specialized, non-high-load system in a language that doesn't offer these safety guarantees. But I won't judge here.

What I 𝘢𝘮 tempted to judge is data structures and data storage patterns. A 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 storing in-flight requests is clearly an attack surface, duh. So, very often, what we truly need is a version of a 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 that will quietly throw an exception of a known type once it holds more than 𝙽 elements. Or once its total footprint in memory exceeds approximately 𝙼 megabytes.

In fact, this 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 is best coupled with a queue. An actor, if you wish. So that the default behavior is: proceed if an empty slot opened up within 𝚃 = 𝟻𝟶𝟶𝚖𝚜, otherwise fail with what silently becomes a 𝟺𝟸𝟿 𝚃𝚘𝚘 𝙼𝚊𝚗𝚢 𝚁𝚎𝚚𝚞𝚎𝚜𝚝𝚜 behind the scenes.

Then, the queue is best made a priority queue. So that some QoS is built in right away. If user traffic is throttled, admin traffic should still go through. For instance, traffic coming from 𝚕𝚘𝚌𝚊𝚕𝚑𝚘𝚜𝚝, or traffic signed with an admin key. Makes perfect sense, right?

Furthermore, I've seen plenty of client-side JavaScript that uses cookies and 𝚕𝚘𝚌𝚊𝚕𝚂𝚝𝚘𝚛𝚊𝚐𝚎 wrong. Sometimes the user's machine is out of disk space, you know? And your page should either load in full (best), or show a nice, lightweight popup saying the machine needs to free up some space to continue. I've seen all sorts of disk-full failures these days — most of them should simply never exist in the first place.

Point is, we're about to be writing more code, and this code will be safer — but it's a long way to get there. Our commonly used tools are still largely inadequate, and they will need an upgrade.

Jokes aside, NVIDIA just published a paper that effectively validates our, xmemory, approach to long-term agent-native memory — source-of-truth first and structure first.

And here comes our analysis: https://xmemory.ai/paper-review-nvidia-nooa-and-prime-intellect-prime-agent/

We're capitalizing on our head start, and it's beginning to show publicly. Fun times ahead.

Well, duh.

I kinda want to merge this PR given it's approved!

And the web UI showing this PR as "can't merge due to conflicts" is sure not helping. When the true reason is that "100 commits should be enough for everybody".

Merged (well, rebased) in just fine after making it 100 commits. Happy end.

Reading about whether our younger generation is getting ... less smart since the incentives of teachers are all messed up makes me wonder more and more.

Why not use a trivial way to shield teachers from angry parents of not-so-bright kids?

The way I proposed many many years ago, and the way a few (more totalitarian, sigh) regimes are quite happily adopting.

The solution is to separate the teacher from the one who evaluates the student and grades them.

A really trivial idea. And for subjects such as maths, the test can and absolutely should be a) universal, and b) non-reproducible, i.e. not something one can memorize.

Simliar to how language tests are passed. The kid (or a university student) is obligated to show up any time during some wide time window and take the test. The test is taken on a computer in an empty room, phones not allowed, cameras everywhere. No room for cheating. And no room to blame the teacher later on.

In this model the teacher — or, if you wish, the professor — is literally 100% on the students' side. The teacher can not possibly optimize any metric other than their students' ultimate score; and the teacher does not even know what the questions will be this time. So, the only incentive for the teacher is to, well, teach.

And in a few years, literally single-digit, we will know who are the better teachers. Schools will make them offers. Parents will chase them to have them as teachers for their kids.

A total and absolute and unconditional win for any society that does prioritize quality of education. Which, unironically, does not appear to include Western societies these days.

Something made me look up these numbers because I was curious.

Flying East over the Equator really does make a 100kg person temporarily lose 1kg in their weight, although obviously not in their mass.

My instinct was that it might get close to 1% or even cross that threshold. Physics appears to align with this instinct; well, vice versa, of course. Cute nonetheless.

And just like that I have hit the Github API rate limit.