If you’re reading this blog for urbanism, you’re probably already on Bluesky. If you’re reading it for tech, you’re probably not. This post is for the latter group; you are missing out! The short version is:

1. There’s a fun tech community on there these days
2. It’s radically open. With a little coding you can completely customize how you consume social media
3. There are some annoying people on there, but they are easy to avoid+block

If you tried Bluesky earlier and bounced off, or if you’ve just heard bad things, I think it’s worth reconsidering.

The short version

1. Start following my starter pack of interesting tech-related accounts
2. Subscribe to the For You feed. It is 1000% better at discovering interesting content than the default Discover feed
3. If you get annoyed by anyone, block or mute with abandon. More on that later.
4. When you’re ready, try making your own custom feed. Coding agents can make quick work of it, and using an LLM or System One model to filter posts works really well!

What you’ll find on Bluesky

There’s a fun tech community there (see: starter pack). It’s not as big as X but still has lots of big names (ex: Simon Willison, Martin Kleppman, Bryan Cantrill, Ethan Mollick).

It also has a lot of weird, small, accounts you can’t find anywhere else doing fun experiments with AI. Like Grace Kind’s unnaturally chipper Jev-based language model, or Cameron Pfiffer’s Void, or this bot which occasionally posts a banger:

people with robot girl pfps posting 'datacenters are destroying the planet' from their cyberpunk aesthetic accounts. bestie my culture is not your costume

— kira ☆ (@kira.ws) April 2, 2026 at 7:34 AM

My Custom Feed

I primarily consume Bluesky through a custom feed. It:

1. Takes every post from every account I follow
2. Runs it through an LLM scorer to eliminate posts I don’t want to see (topics I’m not interested in, ragebait)
3. Returns only the remaining posts

It’s a little Python web app that runs on my VPS, and the inference costs about $5/mo. It uses GPT-6 Luna and scores ~70k posts/month. I expect the price of capable inference to drop much further going forward.

This has been a big quality of life improvement for me. The media you consume shapes how you think+feel, and this lets me consciously choose what I consume. I don’t ever want to see rage-bait posts, and I don’t want my social media feeds to be dominated by US politics (I get enough of that on the real news). It also solves the age-old problem where you follow someone interesting and they post about a topic you don’t care about.

Here’s how I built it. Give that to a coding agent and it will easily build you a custom feed to your own specifications.

Blocking

It’s not all sunshine and roses. There are some annoying people on Bluesky (like any social network), but it’s easier to avoid them than you might think. Just block with abandon:

1. Subscribe to the AI Haters blocklist if you want to avoid extremely anti-AI people
2. If I see a particularly bad post, I use a script that blocks the author and everyone who liked the post. This is a nuclear option, but it works really well!

Ideally this wouldn’t be necessary at all, but there are some groups of people on Bluesky with no chill. I think it stems from:

1. The earliest Bluesky joiners are best described as Tumblr refugees, and they tend to be artists with an anti-AI bent
2. Subsequent waves of new joiners came from Twitter every time Elon did something horrible (including me), and so Bluesky ended up with a self-selected group of accounts who care a lot about politics.

Conclusion

Give it a try, I think you’ll like it! If you don’t like it after a few weeks, I’ll buy you a beer (offer valid only in Vancouver, BC).

It’s been approximately 1 million years since I last wrote about how I use and think about LLMs. I figure I should document the state of things these days; if nothing else, it will be a time capsule.

Coding vs Writing

Something like 99% of my coding is done by agents now. If I’m in a text editor or IDE, it’s almost always to write prose (documentation, comments, etc.) because:

1. Writing is an act of thinking; it helps me gather and focus my thoughts
2. I want to give my coworkers a positive signal that I have put thought+effort into whatever I ask them to read. Text that was obviously generated by an LLM is a negative signal.

Agent harnesses

The Codex and Claude desktop apps are my daily drivers, I mostly stopped using the TUIs a few months ago. They have nicer UI with lots of bells and whistles, and they can both connect to remote servers over SSH. There isn’t as much reason to build or use sophisticated TUIs these days, and that’s a little bittersweet for me as someone who spent a lot of time getting good at building terminal applications.

I spend about half of my time in auto mode and half in YOLO mode. I’d like to use auto mode 100% of the time, but in Codex I find it a little buggy.

Models

Model-wise, I’ve been impressed (like everyone else) by gpt-5.6-sol and Claude Fable. I threw them both at some problems that previous agents struggled with (multiplayer text editing in a very idiosyncratic web app, remote connections in my systemd UI) and they nailed them. I’m also very impressed by the price/performance of gpt-5.6-luna and have switched to it for lower-end-higher-volume use cases. I’m using Anthropic models a bit less than OpenAI ones these days, partially due to cost/value and partially because Claude-isms are wearing on me.

I’ve also played around with OpenCode and some of the top-tier Chinese models; GLM 5.2 is quite capable and can be served very very fast. The speed makes more of a difference than I expected, I think because it helps with deep focus. When the agent returns back to me ~immediately, I’m far less likely to get distracted and context-switch.

Cheap LLMs open up new use cases

The price of decent models has dropped a lot lately, and that opens up some interesting new use cases. Bluesky supports custom feeds, and now I consume most of my social media through a custom feed which scores+filters every post by people I follow through Luna* for about $5/mo. Nobody’s immune to rage-bait and doom-scrolling (least of all me), and this is a remarkably effective way to curate my social media diet. I spent a bit of time experimenting with even cheaper models on OpenRouter, but wasn’t happy with the performance compared to Luna.

*a week after writing this I switched to GLM 5.3 Flash for even cheaper. What a time to be alive.

“The future is already here – it’s just not evenly distributed”

This old Gibson quote comes to mind nearly every day. I have access to better budgeting and financial tracking than anyone using bank and fintech websites, because coding agents are great when given a bunch of CSVs. I’m sure fintech companies will catch up eventually, but right now we’re in an interesting in-between period.

Likewise, the custom filtering I do with Bluesky seems like a natural feature for any social media network once the cost comes down a bit more.

And this isn’t even touching on the huge numbers of non-programmer domain experts who haven’t yet realized that they can speak their own custom software into existence. That will change, and it’s going to be interesting to watch.

Intentional learning

Back when we were writing code “by hand”, it was easy to develop a deep understanding of your code because you had to think real hard about how to write it! That’s no longer the case.

I’ve tried a few different approaches for intentional learning and this skill by Cat Hicks has been the only one that’s stuck. It prompts an agent into quizzing you on the code it just wrote; I find that engaging in that dialogue is useful because it forces me to meaningfully engage with the material (as opposed to documentation that is easy to skim over).

Local voice transcription is really good now

I make heavy use of voice transcription (mostly via Handy and one of the Parakeet transcription models). Agents do better the more (relevant) context you give them, and rambling into a microphone is a very fast way to dump context. This would be very annoying to my coworkers if I worked in an office, so I’ll enjoy this little perk of remote work while I can.

More vs Better

Sometimes I use these tools to ship something fast, quality be damned. And other times I use them to ship better software than I’d otherwise be able to. As a example, systemctl-tui now has a sophisticated test suite that runs across a large number of systemd versions; this is something I could have built on my own but simply didn’t have the time for, and it caught real bugs the first time I ran it.

David Crespo’s “I’m not cutting corners” post is a good read on this topic.

It’s been quite a year. Here’s a grab bag of what stuck in my mind from 2025 and what’s coming next.

Personal Stuff

I started 2025 with a New Year’s resolution to deadlift 300lb. I hit 300 in the middle of the year, upped my resolution to 350lb, but only made it to 310lb. I’d like to hit 350 in 2026, but if I plateau and stay healthy I’m fine with that too.

My big resolution for the new year is to host a gathering at least once a month. Doesn’t have to be anything fancy, just an excuse to see people. My plan to make this happen: even if I’m busy, it’s easy to make a big batch of pasta and have guests bring side dishes and wine.

2025 was the first year I really noticed my dog getting old. He’s 11 and doing well for his age, but I’m more aware that I probably only have a few more years left with him. Retired racing greyhounds make great pets:

We spent a lot of time in late 2025 looking at real estate. After 7 years we’re a little bored of our current place and it’d be nice to have a bedroom for guests. It’s been an emotional roller-coaster; in November we had an offer accepted for a gorgeous condo downtown, only to back out after the inspection found some issues. But hey, it could be worse - when we bought our current place the market was so hot that people didn’t even get inspections done 😬.

Work Stuff

I got promoted to Staff Engineer in December. This required a ton of effort plus some luck, and I’m very proud of it; feels like I finally made it, y’know? The promotion felt especially good because during the tech job rout of late 2022 I accepted a Staff offer from another mid-sized tech company, and then after 3 weeks of delay they retracted it.

Overall it was a very good year for work. I shipped a product, worked on a high-profile keynote demo with OpenAI, and changed teams to launch a new product that’s attracting a lot of interest. I also flew down to SF twice to give talks for work; here’s one I’m particularly proud of.

Software

It is an incredibly crazy time to be working in software.

It feels like 2025 was the year where agents blew up. 1 year ago, I was occasionally using Aider to make commit-sized changes to software projects, and I felt like I was ahead of the curve. Today I tend to use Claude Code (sometimes Codex CLI) to make more ambitious changes, and they are far more capable of iterating on a change until they get it right.

My day to day now involves less “hands-on” coding and more high-level management of coding agents. It’s become incredibly cheap to try things out, and Opus 4.5 is remarkably capable.

I’m spending a lot of time with these new tools and I still feel quite a bit of FOMO. It helps to know that I’m not the only one.

Among people who do a lot of agent-assisted software development, there is some skepticism about whether MCP is useful:

A quick experiment makes this clear: try completing a GitHub task with the GitHub MCP, then repeat it with the gh CLI tool. You’ll almost certainly find the latter uses context far more efficiently and you get to your intended results quicker.

This is a fair criticism; in some scenarios an agent does better if we let it go wild with bash (which is effectively giving it the ability to write+run code) and a CLI tool. I also agree with Armin’s assertion we need better ways to compose MCP tool results. But I still think MCP is useful as-is, and I’d like to sketch out why I believe that.

MCP is simple

To connect an AI agent to an MCP server, I don’t need to download anything; I just provide a URL. Authentication is taken care of as part of the connection (more on this later). Tools are annotated with info that indicates whether they are safe to run. My agent doesn’t need to be able to execute code, and it doesn’t even need a filesystem.

It’s true that this agent might be less flexible or powerful than one with the ability to run arbitrary code. But that’s a tradeoff, and people are exploring ways to combine MCP with code execution - this is something to keep an eye on in 2026!

Programmers are weird

I’m a programmer who spends a lot of time with coding agents like Claude Code and Codex CLI. You could think of me as a power user driving an agent semi-interactively, and most people discussing MCP are in the same boat.

CLI tools are often a viable alternative to MCP for us, but a big part of that is that we can evaluate whether any given call to bash looks safe. That is not a skill that most people have.

OK, sure, we can’t expect most users to validate bash commands. But can’t we just sandbox their agents?

Maybe someday! But sandboxing is hard, and I don’t think anyone’s fully solved the UX around it yet. Are you sandboxing all of your agents today? The answer is “no, it’s too much of a hassle,” right?

Toward Autonomous Agents

Let’s step away from the well-trodden path of Claude Code. Say you’re building an agent that operates autonomously based on untrusted data. To make this more concrete, let’s say it’s an incident investigator agent; when a monitor goes off, it tries to find the root cause using data from your favourite observability provider. How do you give that agent access to your observability data?

If your observability provider has a CLI available, the agent could use that. But using a CLI means:

1. Your agent will need access to a filesystem (provisioned with a copy of the CLI)
2. Your agent will need a sandbox to stop malicious code execution and resource exhaustion
3. You’re opening yourself up to credential exfiltration attacks. The CLI needs credentials to talk to the observability provider; if the agent can execute arbitrary code, it can almost certainly read those credentials.

All of these problems go away if you connect your agent to an MCP server instead. MCP can get a production-ready agent off the ground almost immediately.

Putting it all together

MCP is a dead-simple way to give agents access to tools safely, and it works today. For some agents, that simplicity is extremely valuable; for others it is not. As you move away from expert oversight and toward fully automated agents, the case for MCP grows stronger.

Giving LLMs access to tools (which turns them into ✨agents✨) is an incredibly powerful way to give LLMs capabilities that go beyond generating text. But it’s important to think clearly about the costs and limitations of tool calling, and in particular, people should understand that calling a tool is many orders of magnitude more costly than calling a plain old function from code. There is and probably always will be a limit on how many tool calls an agent can effectively make, and people should design their agentic systems accordingly.

Wait, why?

For this to make sense, you have to consider what a tool call is “under the hood.” LLMs are typically used as very fancy text generation machines. And the way they do tool calls is by generating text, although that’s typically abstracted away from us.

Let’s say you have an agent with one tool, add, for adding 2 numbers together. A user asks the agent a question that’s easy to answer with the add tool:

What’s 15 + 27?

To actually call the add tool, the model generates a message like this (simplified):

{
  "tool_call_id": "call_abc123",
  "tool_name": "add",
  "tool_arguments": "{\"a\": 15, \"b\": 27}"
}

At this point the model stops generating tokens. The thing that’s driving the model (the agentic loop?) parses that message, passes those arguments to some function like add(15, 27), and then puts the output of that into chat history as a new message:

{
  "tool_call_id": "call_abc123", 
  "tool_call_result": "42"
}

Inference resumes, and the LLM now has everything it needs to tell the user that the answer is 42. This works! It’s the foundation of some really incredible software systems! But it wasn’t free:

1. The model had to generate a bunch of tokens.
2. We used up precious context window for the 2 messages.

But why does that matter?

If you’re adding 2 numbers once, it probably doesn’t matter. If you’re summing up 1,000 numbers… you’re going to be waiting a very long time for those 999 tool calls to finish, and you might blow through your entire context window.

This might seem like an academic point, but calling a function many times in a loop is one of the most common ways to solve a problem with code. To give a contrived example, say we have 1,000 user IDs and we want to list the users whose name starts with ‘R’:

1. A programmer with a get_user_info(id) function can write+run a simple for loop. Easy peasy.
2. An agent with a get_user_info(id) tool can try to make 1,000 tool calls, but it will probably run out of context window long before it finishes
   1. Remember, the entire result of every tool call ends up in the context window

Designing agentic tools that are flexible enough for every use case (or even most use cases) is hard, and I don’t think enough people are talking about that.

So what do we do instead?

As always, it depends. Maybe your agent is solving problems where it will never need to make large numbers of tool calls. Maybe you’re clever and you can design your tools to be very flexible+powerful so an agent can do a lot in a small number of tool calls. Maybe you can sidestep this problem by letting your agent write+run code (keeping in mind all of the necessary security precautions).