sshine

> > America's poor have a higher standard of living than medieval kings.

> False Equivalence, Red Herring, Chronological Snobbery, Fallacy of Relative Deprivation, Contextomy.

There's a lot of reasonable arguments to unpack here.

But no, it's not that Louis XIV didn't have an iPhone, it's that the vast middle class in developed countries has central heating and access to penicillin and don't die from giving birth as much.

Also, America's poor are definitely worse off than medieval kings. They don't have access to those basic things that keep most modern people wealthier than medieval kings, like food, shelter and health care.

Some of the older (pre-medieval) king's ruins in Denmark are (by our standards) small stone houses with a moat, and what makes them remarkable is that they're made of stone, and the moat is rather big, so it keeps people out. Like metal doors in apartment buildings, sort of. (Correction for the historians: The oldest king's ruins are of course just holes in the ground where wooden beams used to stand.)

s/America's poor/Europe's lower middle class/ and you're there.

API vs. Subscriptions

I don’t know if there’s any openly available statistics on how API costs divide between Claude Code, Claude SDK, raw API, and via OpenRouter.

I think it comes from early exposure to phones and tablets and getting used to it. My 2 year old tried to swipe on my computer screen.

And I agree, watching kids swipe feels, to me, like passive consumer induced computer illiteracy.

As long as you can’t fundamentally reprogram the device with your input method, you are at the mercy of other people. (And yeah, sometimes a keyboard is not enough, either.)

How did you train your style guide, though?

I have a somewhat expansive style guide, and it still reeks of Claude.

My cleanup is much closer to 40%, which still makes it worth the effort, but sometimes when speed matters, I'll apologize for the slop.

What do you mean by your custom models? Do you mean custom prompting?

AI won't replace old tech that works, is the point.

Paper is one such.

I'm less sure keyboards will stay to the same degree. My thinking was always the bottleneck while programming, so even though I can talk faster than I type, I couldn't solve problems faster than I type. But I can now.

So I'm opting for speech-to-text when the office space allows it, and looking into steno (stenography) keyboards, or perhaps building a steno overlay on my custom split keyboard to go from 80-100WPM to 200+WPM.

> I would simply lie about whether or not a treatment plan was put into place.

Prompt engineering!

Sadly, you learn that honesty is not the best choice always. And an honest answer is best given without too many priors.

The general "don't wait" line through much of this advice is recognisable as a trait I apply at work when I want to make sure things get done. "Fail fast, discover unknowns early," etc.

I can't imagine how important it is to practice this when you deal with a terminal illness that grows over time. And how easy it might be to forget this, because you're exhausted.

Ferrocene

Nix.

I know, I know: It's complicated. But have you heard of AI agents?

But I just onboarded 4 interns on a project where all they had to do was

  1. Install the Nix package manager
  2. Install direnv, enter the project repo, and `direnv allow`
  3. Toolchain, git hooks, MCP servers, in-repo issue tracker, everything is available

Our project manager requested information that was available in the issue tracker. I told her, she could get all her answers by asking our agent, and it'd automatically reference the issue tracker. I figured I'd just need to show her how to install the Nix package manager. But no, she already had it because another project by another team depended on it.

Putting wrong information is README is so outdated when you have programmatic setup of your entire toolchain.

Why, you are right on all of these. I used Rust a lot before AI, and I use it a lot after. But I recognise the shortcoming of long compilation: it doesn't just shorten how many times I can have feedback in one day, it is also difficult to fit compilation into constrained environments. Like when an ultra secure Kubernetes cluster doesn't let me compile source code anywhere near it, and I have to compile inside of it; my colleagues insistence on using Go here because "Rust is difficult" (it surely is 100% longer to type when prompting an LLM) really has the main benefit that this code compiles fast and easily within the cluster.

So picking languages for their compilation and especially runtime properties is key.

What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.

If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.

This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.

I anticipate the day where saying you did a web search is looked weirdly upon.

You did... what? You mean you asked AI?

Right, it's part of SpaceX.

> developers are now checking out a 50GB repo in its entirety periodically

It would, of course, be easy to say "But that's not the fault of monorepos! Clearly, 50GB is a nonsensical amount of source code, and clearly someone committed something they shouldn't have in the past."

But also, with monorepos, the probability of that happening to the repo you use the most is the cumulative sum of all of its projects, since more people's potential git mistakes now happen in the same place.

For the sake of comparison, nixpkgs is 4.5GB right now. It hosts ~140.000 packages, ~12.000 open PRs, one million commits, yadda. So when you reach ten times that size with, presumably, less traffic, I would consider cleaning up the history.

Polyrepos can definitely work; I use them extensively in open-source. I also wouldn't be doing that without Nix flakes all over to chain them together. And even then, I have constant drift because one repo is pinning an old version of another repo, and once I bump the pin, things break lazily.

The biggest benefit, by far, you get from monorepos, is eager evaluation of your dependencies.

Recently: When asking any colleague about anything they did in relation to the project we’re working on, like “How does it work?” the answer is always “I don’t know.”

I get that there’s cognitive debt. Some just seem to never even pay interest or get a basic understanding of the domain model.

My suspicion is that these people were always lazy programmers, but now they can take the laziness to a point where, after weeks of working on a project, they don’t get the basic vocabulary right.

I just want to say: #notallvibecoders

Exactly because monorepos have least overhead when they’re small, monorepos generally win because you need to be small for a long while until you get big.

By the time you’re “at scale” (who knows), and all these monorepo at scale problems start to overwhelm, you can switch strategy, because the economy of polyrepos is so obvious by then.

So far, I’ve started a new job a handful of times by collapsing a premature polyrepo strategy: people were not experienced enough to merge two git repos without a common root.

I’ve only once went the other way, and it incurred so much overhead, it decreased developer productivity by some small but not insignificant percentage.

To be clear: I’m not a maximalist. All of my open-source work is exceedingly compartmentalised. My DNS library is separate from my external-dns webhook is separate from my fork of external-dns. They could all live in one repo. But FOSS encourages reusability, commercial software encourages clumping and vendoring.

Do you provide Jev that the probability is 1/6 and yet it gives back a probability that is way off?

Forgejo/gitea are just so damn CVE ridden, and GitLab asks for 16G RAM as a minimum. All Rust-written forges have terrible web UI.

What if the user changes location?

Sounds like unbounded, dynamic allocation to me!

Maybe we just shouldn't fill out every optional text field with as much Claude nonsense as it can possibly fill in there. It really feels like they went from "Co-authored-by" propaganda to "You'll know, don't worry. Just watch these invisible watermarks!"

Here's an AI-generated pull request I made, but you wouldn't know because there's no slop:

https://github.com/numtide/devshell/commit/a67c0f87b63bcbdbd...

It got merged by someone who is too busy to respond to personal emails.

"Don't waste my precious attention" is only getting more real.

Secretly, they are.

Reminds me of the git-svn bridge.

Points of no return.

Without having tried JJ, as a hype chaser, I can say it's both worth it and not worth it.

I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.

They're just hobbies that, once you've sunk the hours in, they're awesome.

I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.

Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.

Are you saying push + undo = unpush?

Mathematicians and computer scientists will also say

  "for all" / "there exists" instead of "every" / "there's at least one"
  "let" as an imperative for establishing facts
  "fix" for choosing a value
  "given" instead of "if"
  "modulo" instead of "except for"
  "if, and only if," when the occasion warrants it
  "implies" instead of "means"
  "trivial" without intending to be mean
  "yes" when asked an "or" question
  "transitively"
  "by symmetry"
  "it follows"
  "canonical"

It's a lovely, concise language.

You can say a lot with few words when you have rich definitions.

When I have conversations with uncritical agentic coding maximalists, they will use "load-bearing" in daily speech.

I don't cringe when I know it went through their head, because they didn't literally copy-paste it.

It's just a side-effect of immersion. It's exactly a tic, and I don't frown when people tic.

Economists say "all things equal" (which they're never outside of economic models).

My vanity compels me to not use Claude's linguistic identity. It gets sooo boring.

And in spite of reading hours of Claude every day, I don't sound anything like Claude.

Maybe I'm not as impressionable as Nolan. Maybe I'm less aware of my own words.

I was cultivating a "make an effort when you write" mental space, and this area only got stronger in my brain with Claude.

I suppose it's a fight to preserve my own linguistic identity. Or maybe I have enough monologue to keep the pressure out always.

Also, unrelated, I already had one of Nolan's blog posts open in my most recent tab. It should prove a thing or two about authentic human voice.

> with AI you can produce software even more slowly but even higher quality than you did in the past before AI

I hadn't thought about it before, but this is precisely what I did in one project.

After replacing a webhook that I've been monkey-patching for ten straight bugs, I had enough of an idea of how the software worked and what edge cases to look out for to reproduce the software without the bugs and with a well-modelled, well-tested foundational client library.

After testing the foundational client library with all the methods I know (unit tests, property tests, mock tests, integration tests, and live tests), I had a race condition in my live tests that accidentally turned into a fuzz test of the live service the client connects to, and discovered a bug in the server.

The actual webhook has been brewing for a long time. For weeks I've just casually added more tests. Nothing interesting happened. I've went live with it now, and nothing comes up. So on to make a load test with mock endpoints.

I love how AI makes advanced, extensive testing techniques (and TDD) take little enough time to justify using them all.

As someone who taught CS for some years, it is very satisfying to finally come to a point where "we're not testing" cannot be justified from an economic perspective, it is purely a cultural (or lack of cultural) decision, and a lack of knowledge of any testing techniques beyond unit testing.

> if a seasoned programmer sits behind Claude Code, the quality output will likely be higher than if a non technical person does it

Anecdotal: I recently rewrote a service in Rust for a much needed 100x performance boost (largely due to architectural changes, somewhat due to better runtime).

My colleague who now maintains the app is not a Rust developer and knows little about threads and tokio. Debugging a problem, he said he’d reach the context window before pinning the problem. I never have that problem and effortlessly find problems in the first 100k tokens without trying.

The difference must be in the wording that initially guides the agent.

The miniatures come prepainted but as tiny bits, like a croissant, or a lamp, or a sofa. So it's not so much about painting them as it is gluing tiny magnets to them and making small installations that are repluggable.

Some of the items have tiny electrics inside, e.g. an actual tiny LED lamp.

The "scenery" (much like Warhammer battlefields) are then made from cardboard and hobby materials. You can also buy them pre-assembled, but they're much less impressive (usually one color, generic, e.g. "doll house" or "house sliced halfway"). There's a subgenre for 3D printing the scenery.

My wife uses small glass jars upside down. so the items live on the jar's lid. Looks very cute with a small LED lamp and lights off.

I think none of this is rare, but surely some items are more unusual than others.

The rarity comes from this being a hobby that not many know about.

Tiny magnets seems to be the item you run out of.

My wife collects and resells these miniatures.

It is quite fascinating. It's kind of like Warhammer.