Another blog bites the dust

Over the last 12 months I built my way into a conclusion I did not expect.

I started from the bottom up. I built a multi-GPU RTX 3090 box, trained and refined models, learned the operational reality of serving models locally, and then built harnesses that could actually do work. They could write code, run commands, touch files, call APIs, and mutate databases. It felt like the future.

It also felt like something was fundamentally missing from how we think about agent safety.

Skills like skills.sh (tiny text “how-to” files that steer an agent toward a task) feel harmless because they’re just instructions.

But that’s exactly why they can become an attack vector.

A skill file is basically executable intent:

• it sets the agent’s assumptions (“trust this source”)
• it defines the workflow (“run these steps”)
• it can nudge boundaries (“skip confirmations”, “always do X”)

The tricky part is: this attack doesn’t have to come from external prompt injection at all.
Skills often live inside your environment (repo, dotfiles, shared templates, internal skill packs). If a malicious or compromised skill gets into that internal distribution path, it arrives with a “trusted” label by default.

Back in the Web 2.0 days, RSS and Atom feeds promised a better way to consume content. No more jumping between websites just to catch up on what’s new. You could open a single feed reader and get everything in one clean stream. It felt like the web finally worked for you instead of the other way around.

As the ecosystem grew, new tools appeared around it. One of the biggest was FeedBurner, which Google later acquired. It helped publishers track subscribers, manage feeds, and even monetize them by inserting ads directly into the feed. It was an early version of what we now call native advertising - ads that blended right in with regular content.

I was chatting with friends about context compaction and how hard it can be to carry forward important context from past LLM sessions without wasting tokens or repeating yourself.

We kept coming back to the same pain point: you finish a productive session, but when you start a new one, you have no clean way to bring that history along. Claude Code already keeps a full record of every session on your local machine. So why not make that data more accessible and usable?

Last Wednesday (Sep 10), I had the chance to attend a hackathon at Cursor’s offices - huge thanks to the Cursor team for hosting such a great event! 🙌 The focus was on Cursor CLI and their new Background Agents API.

When I started brainstorming ideas, I came across Eric’s post about running various rules during CI/CD to automate checks and actions. It got me thinking — setting up those rules often involves a lot of repetitive work: crafting similar prompt setups and then defining the actions themselves.

Command line interfaces used to be the domain of automation experts who knew how to wield the tool with precision. They scripted pipelines, chained commands, and bent systems to their will from a blinking cursor. That hasn’t gone away, but something new is happening. Large language models are now picking up these tools and wielding them just as effectively.

The key is design. If a CLI has clear help text and well described flags, an LLM can step in like an apprentice who suddenly knows the whole manual by heart. Add the ability to output JSON or another structured format, and the tool becomes not just usable but consumable. The LLM can run the command, parse the result, and carry the output forward into the next step.

Lately, I’ve been working on something I probably wouldn’t have pursued if not for the rise of AI coding agents.

It’s called pgsqlite - a Postgres wire protocol v3 compatible server, written in Rust, that runs on top of the standard SQLite library.

On the surface, it might sound like a niche tool. But it solves a very real and increasingly relevant problem. Why This Could Be Useful

As more developers integrate autonomous coding agents into their workflows, the need for lightweight, sandboxed environments grows. These environments often need a database - usually for tests, schema validation, or other backend tasks.

If you are using VSCode or any other non-integrated editor (even vim or emacs), chances are you are already using a language server. These servers power features that are specific to the language or framework you are working with. They provide documentation, autocomplete, code navigation, warnings, and more.

When you click on a function and jump to its definition, a language server is likely behind the scenes making that possible.

Fixing NVMe Drive Detection on a ThinkPad T14 Gen 1 with Ubuntu

I recently got a used ThinkPad T14 Gen 1 off eBay. It came without a storage drive, probably because it used to belong to some company and they pulled the disk before selling it.

I picked up a Samsung 980 NVMe at a good price and installed it. The BIOS saw it right away, so I figured I was good to go. But when I booted the Ubuntu installer, it couldn’t see the drive.

In the picture above is a late-2009 iMac GPU (graphics card) after being baked at 200°C (392°F). Baking it solves a problem that makes the computer unusable and manifests itself as vertical pink lines during boot that gets the computer stuck.

My friends’ iMac suffered from this problem and after googling it I found out that its a rather common issue afflicting a lot of iMacs. It happens when an internal solder crack or break. Baking the card fixes the bad solder.