Programming: Weekly Summary (January 19-25, 2026)

This week’s pile of posts felt like a mixed bag left on the kitchen table. Some of it smelled faintly of old books and solder; some of it buzzed like a new gadget you’re not sure you want in the house. I would describe the conversation as mostly about two big things, repeating in different clothes: what AI is doing to the job of programming, and how people keep trying to make programming less painful — or at least prettier to live with. To me, it feels like standing in a yard where everyone’s building different fences, and some people are arguing whether fences are even useful.

AI and the shifting role of programmers

AI shows up in more posts than you can count this week. Some of the takes are dramatic. Nick pretty bluntly asks if we’re at the end of the age of the Programmer — and he paints a picture where most of the work gets cheaper and humans do less of the typing. That’s the alarmist headline. But it’s not the only take.

Ricardo uses the Willy Wonka metaphor and treats LLMs like the Oompa-Loompas: helpers that free you up to think bigger. I’d say that’s the optimistic cousin of Nick’s essay. Same subject, different glasses. One side sees a machine that grabs the spade; the other side sees a machine that does the digging while you plan the garden.

There’s also a steady stream of posts that take the middle path and look at actual mechanics. kennethnym built a CLI for pair-programming two Codex agents. It’s modest and useful: one agent drives, the other watches. The author describes the awkward moments — agents stepping on each other, failing to sync — which read like watching two people try to give directions to the same driver. It’s messy, truthfully. But it hints at a future where agents are tools you pair with, not replacements.

Relatedly, Lorin Hochstein and Christian Ekrem both dig into what scaling and AI mean socially. Lorin brings up Amdahl and Gustafson — the old performance laws — and then folds in coding agents and coordination costs. Very dry way to remind you that more speed doesn’t always mean more finished product. Christian goes further and says AI can erode institutions: knowledge transfer, mentoring, the rituals that keep a team from turning into a ghost ship. To me, that reads like a warning to keep the clubhouse intact while you install new lighting.

There are practical notes too. Jono writes like a recover addict — the word I mean is "junkie" — and talks about how LLMs change the itch to code and the payout. There’s a cognitive cost when everything is more accessible. You finish tasks faster, yes, but you might also lose the slow learning that sticks. The phrase that keeps coming back is that AI shifts the work, it does not erase the need for judgment.

Some writers are actively experimenting with new languages and workflows aimed at the AI era. Simon Willison reports on Jordan Hubbard’s NanoLang — a language built for LLMs, with mandatory tests and a C transpilation target. It’s a clever idea: make a language that plays nicer with models. The early experiment was bumpy, but it worked enough to be interesting. It’s like teaching your dog a new trick and being surprised when it actually sits. I’d say NanoLang is less about being the next big language, and more about learning how languages and models talk.

There’s some tension here. Scott Werner rolls a different idea: what if programming were basically message-passing and self-modifying prompt-objects? He doesn’t just toy with metaphors; he suggests we take message-passing seriously. That ties back to older ideas — Smalltalk, Ruby — but with an AI twist. If you squint, you can see lines connecting the NanoLang experiments with these message-driven visions. They both want clearer signals between machine and human.

And then, a pragmatic post: Tuan-Anh Tran admits he was wrong about agent sandboxing. Simpler sandboxes and git worktrees beat over-engineered ideas. It’s refreshingly humble. It’s also useful. The claim is: security is often improved by simplicity, and you pay dearly for complexity. If you’ve ever wrestled with a VM setup that needed 17 steps to start, you know the kind of pain he’s describing.

Language design, ergonomics, and speed tricks

A stack of posts this week was all about making languages or libraries easier to use. Some are tiny and useful; some are deep and nerdy.

Kotlin scope functions got a neat cheatsheet from David Hang. It’s the kind of thing you bookmark. Let, run, with, apply, also — they’re small helpers that keep code tidy. The post’s charm is that it treats these as little kitchen tools; use the right one and you don’t spill sauce everywhere. It’s short, practical, and exactly the kind of thing that saves minutes over months.

If you’re into systems, Jakub gives Odin compilation tips. This is gearhead-level, but it matters. Compilation speed is like traffic: if it’s slow, everything else slows down. He recommends faster linkers, trimming dependencies, and profiling compile stages. I would describe his tone as no-nonsense: fix the slow bits, not everything.

On memory and ownership, Aiono writes about the C++ ownership model. It’s careful and slow, like explaining a juggling trick. Ownership, RAII, move semantics — these are the rules that stop objects from wandering off and causing trouble. The post feels like a patient friend showing you plumbing under the sink; it’s not flashy, but you’ll be grateful you know it exists once something breaks.

Michael J. Tsai appears twice, and both times he’s in a caretaker mode. One post revisits 14 years at Google with solid, no-advice-that-ain’t-practical lines: user obsession, code readability for future human beings, and compatibility work matters. The other post asks for a better Swift interface to C libraries. He argues for Clang annotations and better interoperability without changing the original C. It’s pragmatic: wrap the messy bits so the Swift side doesn’t need to wrestle with raw pointers. That’s the kind of fix you can use next week.

On a related note, Anton Gubarenko walks through CMMotionManager usage in Swift 6. Threading and queue management are headaches. He shows examples of how to avoid crashes. It reads like advice from a builder who’s burned their hands a few times and now wants you to wear gloves.

Message-passing, operating systems, and abstractions

This gets a bit philosophical. Paul Tarvydas has two posts that poke hard at received wisdom. One says operating systems exist to paper over problems created by the function-call model. The other pushes for layered abstraction that blends asynchronous message sending with function calls. The twin idea is: function calls are convenient but brittle; message-passing might scale better when systems grow hairy.

Paul’s writing feels like someone waving a wrench and saying, "Maybe try not using the wrench sometimes." He’s not abandoning functions; he’s asking whether we overuse them in places where messages would be clearer. If you’ve ever debugged synchronous code that blocks forever, you’ll nod. If you like blocking calls, you’ll probably frown, and that’s part of the interesting friction.

Workflows, sandboxes, and developer experience

There’s a recurring preoccupation with making the developer life less stupid. JTR writes about Emacs and nested menus in org-mode capture. It’s small, niche, and full of affection. It’s the kind of post that comforts people who like intricate tools.

[Bugs Block Blogs] by Jake Zimmerman is a real mood piece. Sorbet bugs keep interrupting the author’s writing. It’s petty and human. The kind of thing that makes you remember that programmers don’t only wrestle with abstractions; they wrestle with glitches that steal mornings.

And then there’s the Cloudflare Workers story from Scott Cooper. It’s an example of someone forcing a project into a platform and learning the edges. He used Codex and GPT-5.2, and ran into platform quirks. It’s useful both as a war story and a checklist: Cloudflare Workers are convenient, but they demand compromises.

Security gets a reality check from Tuan-Anh Tran as mentioned earlier. Simpler sandboxes, simpler wins. That’s good to remember when folks promise you bulletproof isolation with stacks of unproven glue.

There’s also an odd cautionary tale: Outside the Asylum on Screeps. The game is brilliant as a teaching tool — writing code to control units — but it has UI and security problems, sometimes very bad ones. The headline is that innovation can come with rough edges. The game’s community and concept are gold; the polish is sometimes missing.

Mathy, formal, and deep technical posts

If you like your posts with a side of heavy calculus, a couple of pieces will make you smile in a tired way. Elmar Klausmeier writes about Tendler-like cyclic linear multistep formulas and calculating error constants in high precision. There’s a bc script and warnings about double precision traps. This is the kind of thing only some people need, but if you’re one of those people, you’ll thank the author for the exact numbers and the neat little computational tricks.

Philip Zucker covers subterms modulo theories. It’s formal, careful, and the sort of piece that reminds you how deep basic questions can get. Equality, normalization, associative and commutative terms — the post teases out what looks simple and shows it’s not. It’s pleasantly nerdy.

Alex Kladov writes about strictly monotonic time in code. It’s short and to the point: make time values unambiguous. The practical bits — assertions, tightening invariants, and ensuring high-resolution timestamps — are the sort of small fixes that quietly prevent awkward bugs. It’s like tightening your shoelaces before you run.

Nostalgia, art, and odd corners

Some posts are basically love letters to older tech or to little art projects. Pierre Dandumont excavates a hidden Commodore 64 program stuck on a vinyl reissue. It’s delightfully geeky and reminds you of the joy of stumbling on backdoor treasures. If you remember blowing on cartridges, you’ll smile.

Lucio Bragagnolo shares Alex Harri’s ASCII art project. The math behind character lighting and bitmap tricks is clever, and the result is unexpectedly moving: 3D objects in text, which feels like making small sculptures out of Scrabble tiles. It’s the kind of playful engineering that warms the heart.

There are also creative crossovers. Gordon Brander draws a parallel between generative music and generative code. He suggests that specifying things somewhat — not too tight, not too loose — is where interesting output lives. It’s an argument for ambiguity as a creative tool, and it’s oddly persuasive.

Standards, formats, and hot takes

A few posts take strong stands. Marcos Magueta defends XML like it’s a comfortable old coat. He likes XML’s schema validation, namespaces, and the ability to comment. He thinks JSON won popularity mostly because it’s convenient, not because it’s technically superior. If you’ve argued this at a conference bar, you’ll recognize the tone: a little grumpy, a little smug, but with real points.

Meanwhile, Mike Blumenkrantz gives an uneasy take on VKEXTdescriptor_heap in Vulkan: powerful, but messy. It’s the sort of high-end hardware feature that looks great on paper and becomes a headache in code. He’s not against progress. He just asks you to be careful.

Education, pacing, and learning curves

Two posts remind us that learning is a human process, not a checklist. Dan Bulwinkle talks about structure and pace in computer science education. One school’s grind made him learn fast; another’s pace allowed breathing room. It’s an argument for designing learning that matches the person. I’d say it’s a reminder that education isn’t a single recipe.

Neo Kim offers a 51-image tour through the whole computer science stack. It’s visual, which is sometimes the best way to fix fuzzy concepts in your head. The post is handy if you’re the sort of person who likes to see the whole machine laid out like a 2D IKEA manual.

Recurring threads and disagreements — the stuff that kept appearing

• AI: Some see doom. Some see helpers. Most see a reshaping. That’s the running irony: everyone is right partly. Tools change what work looks like. You still need people to decide what to build. You still need judgment. That idea kept coming back. I would describe the arguments as familiar, like family disputes at a reunion. They repeat, but each person brings a new dish.

• Simplicity vs complexity: A few posts repeatedly say the same thing in different languages: complexity is contagious. Tuan-Anh Tran is blunt about over-engineering; Michael J. Tsai quietly insists on readable code for the future. Simplicity is not always obvious, and it’s rarely free. It’s like choosing to cook at home — takes time now, saves money later.

• Message-passing vs function calls: Multiple posts circle this. Some want to rebuild the plumbing around messages. Some want to accept functions and add better async tools. There’s no consensus. It’s mostly a lively argument, not a fight yet.

• Nostalgia and craft: A few posts remind you programming is also cultural. Vinyl secrets, ASCII art, and old-school games pop up. They’re small, tender pauses in a week of heavier debates.

• Education and human processes: Several writers emphasize that institutions, mentoring, and human habits matter. You can’t simply automate wisdom away.

If any of these threads perked your ear, the authors almost always have more detail and examples in their posts. The technical bits — bc scripts, code snippets, and precise compiler flags — live on their pages. If you want the math, Elmar’s numbers are where to go. If you want a cheat sheet, David Hang gives that quick hit. If you want a slow, grumpy defense of XML, Marcos will oblige.

I’d say the week felt like a neighborhood: some house parties full of arguments about the future, some people quietly fixing their roofs, and a couple of artists making weird sculptures in the alley. If you’re curious, poke at the front doors. The linked posts will walk you through details. Dive in if you like a good argument or a neat hack — both are in stock this week.