The internet may be dead, but my streak of posting every day since January 4th is not. We’ll see how long it lasts. 🎖️

Here’s a helpful idea on how to use Claude CoWork to update your photos EXIF data so they have descriptions.

📸 Full writeup

jQuery 4.0 was released on the 17th and they removed IE10 support. IE10 was first deprecated by Microsoft in January 2016 and fully retired in 2020. You might wonder, “What are they doing still supporting Internet Explorer?” They did say they were going to fully remove support in version 5.

😆: blog.jquery.com/2026/01/1…

Shu has a great article on performance:

Performance is like a garden. Without constant weeding, it degrades.

It’s not just a JavaScript thing, it’s a mindset. We keep making the same mistakes even with solid understanding of the code because just like Agents we too have a context window. It takes ongoing maintenance to keep the garden looking good.

Worth a read: shud.in/thoughts/…

It’s more of a party trick than anything else, but here’s the prompt:

Task: Construct a perfectly rectangular 4x26 ASCII block.

The "Safe-Width" Symbol Set: ∫ √ ≈ ∆ ∑ ± ∞ ≠ ≡ ≥ ≤ ÷ ç ∂

Instructions:
- Grid Specs: Exactly 4 rows and 26 characters per row
- Hidden Message: Choose a 2-word uppercase phrase
- Center the first word in Row 2 and the second in Row 3
- Fill all non-letter slots with random symbols from the set
- Verify each row is exactly 26 characters

Those specific mathematical symbols maintain consistent width with uppercase Latin characters in monospaced fonts. This means the grid stays perfectly rectangular, and the words blend in better.

Is this useful? Not really. But it’s a neat demonstration of how to get AI to produce structured output.

Try it yourself and see what secret phrases you can embed.

The universe is a giant board game. Space is the board, matter is the pieces, and logic is the rules. Language is our rulebook of how we describe how the board works. You can’t separate the rules from the board; if you had a different board, the rules would be different too.

When you get to the “what ifs,” it becomes a thought experiment, not grounded in science.

I’m reading an article today about a long-term programmer coming to terms with using Claude Code. There’s a quote at the end that really stuck with me: “It’s easy to generate a program you don’t understand, but it’s much harder to fix a program that you don’t understand.”

I concur, while building it may be fun, guess what? Once you build it, you got to maintain it, and as a part of that, it means you got to know how it works for when it doesn’t.

for some reason i feel like step 4 was important

As of 2026-01-24, the stable release of Claude Code is 2.1.7, but if you’ve been following the bleeding edge, versions 2.1.15 and 2.1.16 bring some significant changes. Here’s what you need to know.

The npm Deprecation Notice

Version 2.1.15 added a deprecation notification for npm installations.

If you’ve been using Claude Code via npm or homebrew, Anthropic will soon start nudging you toward a new installation method. You’ll want to run claude install or check out the official getting started docs for the recommended approach.

This isn’t a breaking change yet, but it’s a clear they are moving away from npm for releases going forward.

Built-in Task Management

Version 2.1.16 introduces something I’m genuinely excited about: a new task management system with dependency tracking.

If you’ve been using tools like beads for lightweight issue tracking within your coding sessions, this built-in system offers a similar workflow without the setup.

You can define tasks, track their status, and—here’s the key part—specify dependencies between them. Task B won’t start until Task A completes.

This is particularly useful for repositories where you don’t have beads configured or you’re working on something quick where setting up external tooling feels like overkill.

Your sub-agents can now have proper task management without anything extra.

Should You Update?

If you’re on 2.1.7 stable and everything’s working, there’s no rush. But if you’re comfortable with newer releases, the task management in 2.1.16 is worth trying, especially if you work with complex multi-step workflows or use sub-agents frequently.

The npm deprecation is something to keep on your radar regardless. Plan your migration before it becomes mandatory.

Weekend project lineup: I want to push forward on api2spec, plus there’s a new idea rattling around that needs to get out of my head and into code. Also have some volunteer dev work queued up. Always more to do than time even with all the tools and workflows we have in place.

Claude Code’s built-in tasks are pretty solid—they work well for what they do. But I still find myself reaching for Beads. There’s something about having persistent issue tracking that lives with your code, syncs with git, and doesn’t disappear when you close your terminal. Different tools for different jobs, I suppose.

Sometimes it’s good to go back to basics. Do you actually know what a file system is? There are different standards for how data gets stored. Your operating system usually picks one for you, but on Linux you’ve got choices: ext4, XFS, Btrfs, and others. Worth understanding what’s actually happening when you save a file!

A Markov chain is a mathematical system that hops between states based on probability. It’s not trying to understand the past or predict the distant future, it only cares about what happens next. Given where you are right now, what’s the most likely next step? That’s it. The chain itself is just the name for this probability hopping system.

You may not realize it, but AI code generation is fundamentally non-deterministic. It’s probabilistic at its core, it’s predicting code rather than computing it.

And while there’s a lot of orchestration happening between the raw model output and what actually lands in your editor, you can still get wildly different results depending on how you use the tools.

This matters more than most people realize.

Garbage In, Garbage Out (Still True)

The old programming adage applies here with renewed importance. You need to be explicit with these tools. Adding predictability into how you build is crucial.

Some interesting patterns:

• Specialized agents set up for specific tasks
• Skills and templates for common operations
• Orchestrator conversations that plan but don’t implement directly
• Multiple conversation threads working on the same codebase via Git workspaces

The more structure you provide, the more consistent your output becomes.

The Security Problem

This topic doesn’t get talked about enough. All of our common bugs have snuck into the training data. SQL injection patterns, XSS vulnerabilities, insecure defaults… they’re all in there.

The model can’t always be relied upon to build it correctly the first time. Then there’s the question of trust.

Do you trust your LLM provider?

Is their primary focus on quality and reliable, consistent output? What guardrails exist before the code reaches you? Is the model specialized for coding, or is it a general-purpose model that happens to write code?

These are important engineering questions.

Deterministic Wrappers Around Probabilistic Cores

The more we can put deterministic wrappers around these probabilistic cores, the more consistent the output will be.

So, what does this look like in practice?

Testing is no longer optional. We used to joke that we’d get to testing when we had time. That’s not how it works anymore. Testing is required because it provides feedback to the models. It’s your mechanism for catching problems before they compound.

Testing is your last line of defense against garbage sneaking into the system.

AI-assisted review is essential. The amount of code you can now create has increased dramatically. You need better tools to help you understand all that code. The review step, typically done during a pull request, is now crucial for product development. Not optional. Crucial.

The models need to review itself, or you need a separate review process that catches what the generating step missed.

The Takeaway

We’re in an interesting point in time. These tools can dramatically increase your output, but only if you build the right guardrails around them should we trust the result.

Structure your prompts. Test everything. Review systematically. Trust but verify.

The developers who figure out how to add predictability to unpredictable processes are the ones who’ll who will be shipping features instead of shitting out code.

If I had to start over as a programmer in 2026, what would I do differently? This question comes up more and more and with people actively building software using AI, it’s as relevant as ever.

Some people will tell you to pick a project and learn whatever language fits that project best. Others will push JavaScript because it’s everywhere and you can build just about anything with it. Both are reasonable takes, but I do think there’s a best first language.

However, don’t take my word for it. Listen to Brian Kernighan. If you’re not familiar with the name, he co-authored The C Programming Language back in 1978 and worked at Bell Labs alongside the creators of Unix. Oh also, he is a computer science Professor at Princeton. This man TAUGHT programming to generations of computer scientists.

There’s an excellent interview on Computerphile with Kernighan where he makes a compelling case for Python as the first language.

Why Python?

Kernighan makes three points that you should listen to.

First, the “no limitations” argument. Tools like Scratch are great for kids or early learners, but you hit a wall pretty quickly. Python sits in a sweet spot—it’s readable and approachable, but the ecosystem is deep enough that you won’t outgrow it.

Second, the skills transfer. Once you learn the fundamentals—loops, variables, data structures—they apply everywhere. As Kernighan puts it: “If you’ve done N programming languages, the N+1 language is usually not very hard to get off the ground.”

Learning to think in code matters more than any specific syntax.

Third, Python works great for prototyping. You can build something to figure out your algorithms and data structures, then move to another language depending on your needs.

Why Not JavaScript?

JavaScript is incredibly versatile, but it throws a lot at beginners. Asynchronous behavior, event loops, this binding, the DOM… and that’s a lot of cognitive overhead when you’re just trying to grasp what a variable is.

Python’s readable syntax lets you focus on learning how to think like a programmer. Fewer cognitive hurdles means faster progress on the fundamentals that actually matter.

There’s also the type system. JavaScript’s loose equality comparisons (== vs ===) and automatic type coercion trip people up constantly.

Python is more predictable. When you’re learning, predictable is good.

The Path Forward

So here’s how I’d approach it: start with Python and focus on the basics. Loops, variables, data structures.

Get comfortable reading and writing code. Once you’ve got that foundation, you can either go deeper with Python or branch out to whatever language suits the projects you want to build.

The goal isn’t to master Python, it’s to learn how to think about problems and express solutions in code.

That skill transfers everywhere, including reviewing AI-generated code in whatever language you end up working with.

There are a ton of great resources online to help you learn Python, but one I see consistently is Python for Everyone by Dr Chuck.

Happy coding!

So, Zero Trust is this idea that you never trust and you always verify.

Cloudflare Tunnels, TailScale, and Ngrok are three different approaches to Zero Trust networking.

Cloudflare Tunnel is a reverse proxy. TailScale is more of a mesh-based VPN. Cloudflare Tunnel is an ingress as service, which means that it makes it really easy to spin up public URLs.

What you need depends on your use case.

Transhumanism (as a fictional genre, not as a philosophy) is about the idea that we can use technology to overcome the problems inherent to human nature, while cyberpunk is about the idea that we can’t.

I propose a new form of philosophy called “Cyberpunk Luddism.” The idea comes from reading a blog post on Kagi Small Web about Molly’s Guide to Cyberpunk Gardening. In it, they mention the interesting quote above, that I have tracked down the original source from 2009. Stephen Lea Sheppard on RPG.net

Everyone crashing out over OpenCode situation. Why not just use Claude Code (2.1+)? Or you know, there’s AMP. AMP exists too, and it looks equally interesting to me.

Claude Code has been working great for me. OpenCode looks interesting, but uh, Opus 4.5 access is necessary for real work. I’m not doing any sketchy workarounds to get it running, and API pricing isn’t appealing either. So for now, OpenCode stays firmly in the “interesting” category.

I’ve been thinking about the programmers who are against AI tools, and I think their arguments generally fall into two camps.

Of course, these are just my observations, so take them with a grain of salt, or you know, tell me I’m a dumbass in the comments.

The Learning Argument

The first position is that AI prevents you from learning good software engineering concepts because it does the hard work for you.

All those battle scars that industry veterans have accumulated over the years aren’t going to be felt by the new breed. For sure, the painful lessons about why you should do something this way and not that way are important to preserve into the future.

Maybe we’re already seeing anti-patterns slip back into how we build code? I don’t know for sure, its going to require some PHD level research to figure it out.

To this argument I say, if we haven’t codified the good patterns by now, what the hell have we all been doing? I think we have more good patterns in the public code than there are bad ones.

So just RELAX! The cream will rise to the top. The glass is half full. We’ll be fine… Which brings me to the next argument.

The Non-Determinism Argument

The second position comes from people who’ve dug into how large language models actually work.

They see that it’s predicting the next token, and they start thinking of it as this fundamentally non-deterministic thing.

How can we trust software built on predictions? How do we know what’s actually going to happen when everything is based on weights created during training?

Here’s the thing though: when you’re using a model from a provider, you’re not getting raw output. There’s a whole orchestration layer. There’s guardrails, hallucination filters, mixture of experts approaches, and the thinking features that all work together to let the model double-check its work before responding.

It’s way more sophisticated than “predict the next word and hope for the best.”

That said, I understand the discomfort. We’re used to deterministic systems where the same input reliably produces the same output.

We are are now moving from those type of systems to ones that are probabilistic.

Let me remind you, math doesn’t care about the differences between a deterministic and a probabilistic system. It just works, and so we¹.

The Third Argument I’m Skipping

There’s obviously a third component; the ethical argument about training data, labor displacement, and whether these tools should exist at all.

I will say this though, it’s too early to make definitive ethical judgments on a tool while we’re still building it, while we’re still discovering what it’s actually useful for.

Will it all be worth it in the end? We won’t know until the end.

---

1. This “we” I use to mean us as in the human race, but also our software we build. ↩︎

Claude Cowork released this week, and the concept seems genuinely useful. I think a lot of people are going to love it once they get their hands on it.

Unfortunately, I haven’t been able to get it working yet. Something’s off with my local environment, and I’m not entirely sure what. Claude Desktop sometimes throws up a warning asking if I want to download Node and I usually say no, but this time I said yes. Whether that’s related to my issues, I honestly don’t know. I did submit a bug report though, so hopefully that helps.

Here’s the thing that really impresses me: Anthropic noticed a trend and shipped a major beta feature in about 10 days.

That’s remarkable turnaround for something this substantial. Even if it’s not working perfectly for everyone yet (hi, that’s me), seeing that kind of responsiveness from a company is genuinely exciting.

I’m confident they’ll get it sorted before it leaves beta. These things take time, and beta means beta.

I have explored using the CLI agents outside of pure coding workflows and so I think there’s a lot more flexibility there than you might expect.

For now, I’m watching from the sidelines, waiting for my environment issues to sort themselves out.

When do you think everyone will finally agree that Python is Python 3 and not 2? I know we aren’t going to get a major version bump anytime soon, if ever again, but we really should consider putting uv in core… Python needs modern package management baked in.

My api2spec plans this weekend is to continue working on the fixtures. We got all the fixtures in place, but the real work is outputting specs to files and validating them against the tree-sitter parser code for each framework. That validation step is where things get interesting—making sure the generated specs actually match what each framework expects.

After two days with Beads, my agent-based workflows feel supercharged. I’ve been experimenting with agents for about a month now, and something clicked. Could be the new Claude Code 2.1 upgrade helping too, but the combination is 🚀🚀🚀.

Spent some time with Google Antigravity today and I think I’m starting to get it. Built a few agents to test it out. The agent manager stuff is genuinely interesting and seems useful. The planning features (spec-driven development) though? Not sold on those yet.