Programming: Weekly Summary (January 26 - February 01, 2026)

This week felt like a busy Sunday market for programming ideas. Lots of stalls, some noisy, some quiet, some selling shiny new toys and others hawking old reliable tools. I would describe the mood as lightly panicked and oddly cheerful at the same time. There are a few loud threads that kept showing up in different corners of the market, and some quieter ones that are worth poking at. If you want the deep, nerdy howtos, go read the posts. Here I’ll point to the good bits and why they matter, and nudge you towards the ones that might make you stop, linger, and click.

Agents, factories, and what we mean by programming now

A cluster of posts this week kept circling the same uncomfortable idea: coding is not just typing code anymore. It is, increasingly, about orchestrating systems that do things for you. Robert Glaser opened the week with a striking image in his piece about thousands of agents building a browser. It reads like a sci fi factory tour, but the point is practical. We are moving from single assistants that suggest a line of code, to ensembles that plan, execute, check their work, and keep going. To me, it feels like moving from hiring a part time helper who knows a recipe, to running a small kitchen where the cooks argue about seasoning and then taste the dish themselves.

That metaphor gets picked up elsewhere. Simon Willison sketched a five level ladder from autocomplete to a dark factory where humans barely review output. Trevor Lasn offered a clearer contrast between chatbots and agents, and gave the ReAct pattern its usual polite workout: think, act, observe, loop. The insistence across these posts is familiar: agents are looped actors, not one-shot answers. They need tools, and they need feedback. They also make new kinds of mistakes, like losing context, compounding errors, and inventing states that don’t exist. There’s a practical smell to these warnings, not just hand-wringing.

There were philosophical takes too. hodlbod and the essays under the daveverse alias argued that excessive reliance on LLMs erodes craft and muscle memory. I’d say they sound like someone who used to fix a bike and now watches YouTube clips about bikes, which is true enough. The worry is that the skillset becomes thinner while the toolset gets thicker. That will have consequences for education, hiring, and how we judge quality.

And there’s a business angle. Posts about proprietary agent platforms and the end of community-maintained knowledge point to a new battleground: who owns the signal that teaches these agents. If you train models on users without giving anything back, the knowledge economy shifts. It’s not just about tech, it’s about who gets paid for the learning.

If you want the nitty gritty on how people are trying to make agents useful, read Robert Glaser for the browser experiment, Trevor Lasn for the ReAct primer, and Simon Willison for the five level model. The essays complement each other like different lenses on the same object.

Tools, languages, and friction points

There were a lot of posts about language and tooling choices this week. Rust held court in several places. Dmitrii Aleksandrov argued for fine-grained error types instead of one big global enum in Rust. It’s the sort of argument that matters when your codebase grows beyond toy projects: precise signatures make it easier to reason about failure. The newsletter from Omar put embedded Rust into the spotlight too, reminding that the language is less a fad and more a slowly growing muscle in systems work.

There was also a pragmatic debate about whether to add Rust into kernels. benzblog took a conservative stance about NetBSD, listing compatibility, release cycles, and architecture diversity as big headaches. If you work in kernels, you already know that adding a language is not fashion, it is a long term commitment that bends tooling, testing, and social processes.

Swift had a small but interesting piece from Michael J. Tsai on BorrowingIteratorProtocol. The idea is simple: iterate without copying noncopyable values by handing out short lived spans. I’d say it’s like passing a loaf of bread down the table rather than each person getting a boxed slice. It’s about performance, but the real question is ergonomics: when do you reach for a borrowing iterator and when do you not? The author admits it needs more thinking, which is refreshing.

Go got a showing too. JT Olio wrote about porting a RISC-V emulator from C to Go with help from Claude. There’s a useful honesty here: working with an AI assistant for a nontrivial port surfaces problems like context drift and subtle semantic mismatches. You expect some smoothing from the assistant, but debug time remains stubborn. And a separate, practical post by Altay Akkus showed how to crawl only the head of HTML pages with HTTP/2 to save bandwidth. That one reads like a money-saving hack: if you can avoid downloading full pages for metadata, do it. The engineering smell is thriftier than flashy.

Another post that grabbed attention explained how ChatGPT containers now run bash, install packages, and download files. Simon Willison described the change with a mix of excitement and worry. It makes the assistant more useful, sure, but there’s a documentation gap and a security headache. Letting an agent run arbitrary installs is like lending your toolbox to a stranger: useful if you trust them, dangerous if you don’t.

Finally, there were smaller but practical items: a minimal Sorbet setup using inline RBS comments by Nithin Bekal, and a readable dive into linkers and relaxation by Farid Zakaria. These posts are the kind of meat-and-potatoes reads that actually change how you work day to day.

Porting, performance, and stubborn engineering

A solid chunk of posts were hands-on engineering stories. Alex Dixon pulled off an iOS to Android port of a music app in under two weeks. I’d say the piece is full of the small irritations that make porting feel like shuttling furniture through narrow staircases: native build systems, JNI quirks, and unexpected API shapes. The tone is, frankly, proud and exhausted, which is the correct tone for a port. Bob’s your uncle, you ship.

There were also hardware-close posts. The Swisscom 2025 security.txt challenge writeup by Michal Jirků reads like a detective story about loading patched files in an emulator to retrieve a flag. If you like vulnerabilities and puzzles, that one is a proper treat. On the opposite side of tiny puzzles, nns.ee did a clever code golf to beat Fossil’s ASCII art CAPTCHA in tiny bytes. It’s one of those small triumphs that feels like winning a mini-game.

Systems-level care also showed up in an excellent howto from Systems on writing custom Linux syscalls. These are the sorts of posts that make you grateful for pragmatic examples. The author addresses performance, safety, and alternatives like eBPF and ioctl. If you’ve ever wondered whether to add a syscall for a very niche feature, this piece is the sort of counsel that helps you sleep at night.

And then there’s persistence and actor systems. Terracrypt posted a mini-series about adding persistence to guile-horton and gobs-of-machines, dealing with actor macros, spawning, and mysterious unspecified self values. It reads like a lab notebook: small victories, weird bugs, and an admission that some mysteries require staring at the code for a while. That is comforting in a way — people are still wrestling with the same messy truth: production systems are boring and hard.

Web, front end, and the shape of UI work

A few posts were about Javascript and front end craft. Software for Days served up a trio of practical posts: from watch types in AngularJS to building reusable directives and a gentle tour of stateful programs in both OO and functional styles. The Angular pieces look back at classic problems with affection and pragmatism — watchers, deep watching, and how to avoid blowing up performance. The stateful program piece is enjoyable for its side-by-side ATM example. It’s a neat reminder that some problems get different frames depending on whether you hand them to an object or to a function.

Bookmarks from Angelo Pesce was the usual curated map of interesting tools: Wuffs, Roc, shader debugging, and async reads. It’s the kind of link map you keep for rainy days.

The Cloudflare Matrix homeserver post by Michael J. Tsai is an odd duck. The post critiques Cloudflare’s blog entry as likely AI-generated and missing essential security details. The subtext is larger: are large companies outsourcing their technical voices to models? If so, that dilutes trust. A technical blog is diplomacy. You can’t scribble something half-baked and expect readers to trust the ship.

Craft, habits, and the human side of work

There was a run of posts that were less about new tech and more about how people work. daveverse had two small pieces — one on self-management, the other part of the argument that AI changes how people work. The self-management piece was simple and useful: set tiny daily goals, collect small wins. It reads like advice from someone who learned the hard way that big goals without small anchors go sideways.

Brian Hogan wrote about fluency and what makes an A player. He didn’t mean a fancy résumé type. He meant someone who lives in the language, knows the cultural idioms, and has accountability. The language here is close to craft: fluency is less syntax and more a feel for how the language breathes. That matches the rust/error-types post and the sorbet piece — everyone keeps nudging us toward better interfaces between humans and machines, be it types, error signatures, or mental models.

heckmeck_ shared a charming misadventure with a no-cpu demo that turned into an almost-but-not-quite submission. The scene of a rushed demo getting laughs at a party is oddly relatable. It’s the small, human reminder that grand ideas often outpace time and that sometimes you ship a work-in-progress and learn from the crowd reaction.

Small experiments, workflow tweaks, and miscellaneous bits

A few people dug into the tiny things that actually improve day-to-day life. Terracrypt shared blogging workflow improvements with Emacs org-capture templates. If you write a lot, a good template is like a clean kitchen counter: it saves decision fatigue. Wouter Groeneveld wrote about syntax highlighting. It’s unglamorous, but the right colors can make a day feel less like trudging through a fog of tokens.

Joel Jakubovic listed research threads he wanted help with. That one read like an open lab notebook full of half-baked hope. It’s a nice invitation if you want to collaborate or riff.

There were also some niche delights: Bryce Bostwick explained a more scalable way to swizzle many Objective-C methods using trampolines and memory mapping; Farid Zakaria went deep on linker relaxation. These are the kinds of posts you save for a long evening of tinkering, like keeping a good paperback in the bathroom.

Points of agreement, disagreement, and the shape of debate

Some clear patterns popped up when I read everything together.

• Agents are the hot topic, and people disagree about what that means. Some, like Robert Glaser and Trevor Lasn, map out practical architectures and tools. Others, like hodlbod, issue cultural warnings about skill loss. They aren’t talking past each other exactly; they are talking about different timescales. One side is building the tools today, the other is asking what gets lost over years.

• Language migration is mostly pragmatic. Whether it’s adding Rust to a kernel or using Go for emulation, the discussion centers on tradeoffs that are concrete: build-time cost, debugging ergonomics, platform support. There isn’t much idealism here; it’s engineers arguing about whether the new tool brings enough wins to justify the migration pain.

• Tooling vs craft shows up repeatedly. Posts about Sorbet, error types in Rust, and fluency argue that better interfaces between humans and code are not optional. They matter more than new syntactic sugar. Fluency and precise error types are like clear street signs in a city: they don’t look sexy, but they save lives and time.

• Companies publishing thin technical blog posts drew ire. The Cloudflare critique and the daveverse posts about knowledge commodification suggest readers are getting less tolerant. If you publish a technical post, make it real. Otherwise, you lose credibility fast.

A few standout reads worth bookmarking

If you are skimming and want a short list to click now: go for Robert Glaser on the agent-built browser, Simon Willison for the five levels of AI assistance, Dmitrii Aleksandrov on Rust error design, Altay Akkus on partial-content crawling with HTTP/2, and Systems on writing syscalls if you like low-level work.

There is more than one reason to click. Some posts are practical and likely to change how you work tomorrow. Others are wide-lens pieces that make you reconsider assumptions about skill, ownership, and what a programmer does. And then there are the small delights, the puzzles, the workflows, the rants — the things that keep the scene human.

If you liked this scattershot stroll, you’ll find the authors themselves often write in longer threads. The posts this week were a mix of helpful howtos and sharp opinion pieces. They nudged at two big questions: how do we build reliable systems when the actors inside them are increasingly autonomous, and how do we keep craft alive when tools can mask ignorance? Those questions are connected, even if people answered them in different tones.

Anyway, that was the scene this week. There were moments of awe and a fair share of annoyance. Like a good film festival, some items will stay with you, others will be forgotten by Monday. If something here piqued your curiosity, the authors are only a click away. Read the original posts if you want the code, the diagrams, or the full grumpy arguments — they usually do a better job explaining the tiny technical bits than I did here.