AISanity2 MIN READ
02.06.2026
.md

How I Used My Own Blog to Research My Presentation About It

Last updated: 02.06.2026

🎧

How I Used My Own Blog to Research My Presentation About It

Audio Narration

funny guy presenting

The Setup

When I was asked to present my blog to a group of colleagues, the first challenge was practical: how do I gather 14 posts worth of writing without copy-pasting from a browser? I'd built a lot into the blog over the past year and needed a fast way to pull it all together.

Markdown at /md/posts

Every post on the blog is available as clean markdown at /md/posts/[slug]. I built this endpoint for AI tools — strip the HTML, navigation, and cookie banners, and return just the content. It turned out to be exactly what I needed for my own research. I fed several posts directly into Claude, which read and summarised them in seconds.

llms.txt as a Site Index

Before diving into individual posts, I pointed Claude at /llms.txt — a structured index of the site, like a machine-readable table of contents. Claude used it to map what the site contained before pulling individual posts. It's a convention similar to robots.txt but designed for AI discovery rather than search engine crawling.

Building the Slides with Slidev

For the slides I used Slidev (sli.dev) — a presentation tool built for developers where slides are written in markdown. That means Claude can write and edit them directly. The Claude Code skill for Slidev made it straightforward to generate the initial structure, iterate on layout, and keep the tone consistent. No drag-and-drop interfaces to fight with.

The Meta Moment

There's something satisfying about a tool working for yourself first. The markdown API and llms.txt were built with the idea that AI systems and other developers would find the blog easier to consume. In practice, the first person to benefit was me — using my own infrastructure as a research pipeline for a presentation about that same infrastructure.

Conclusion

If you're building a content site and wondering whether AI discoverability is worth the effort — build it anyway, even if you're not sure who else will use it. The most immediate value might come from yourself.

Continue Reading
A pegboard of hand tools above a workbench, one tool lifted out of its painted outline.
AIClaude3 MIN

When the Claude window runs out: my take on T3 Code

T3 Code addresses the frustration of hitting Claude’s five-hour usage limit during focused work. Rather than replacing coding agents, it provides a single desktop interface for tools such as Claude Code, Codex, Cursor, Grok Build, OpenCode, and Antigravity, with users signing in through their own accounts. Each thread remains tied to its original provider, so an unfinished Claude conversation cannot be transferred directly to Codex. However, the surrounding workspace, project, and workflow stay in one app. When a limit is reached, T3 Code identifies the restriction and reset time, allowing the user to start a new thread with another provider and quickly restate the task. The app is free and does not resell or mark up tokens, aligning its incentives with users who want to avoid unnecessary calls. Its MIT license, self-hosting support, public codebase, and more than 21,000 GitHub stars are especially important because it handles provider credentials and repository access. Although founder Theo frequently promotes the product, its transparency makes those claims easier to verify. The Linux desktop app remains young and occasional releases cause problems, but steady improvements and its ability to coordinate separate agents make it a practical solution for maintaining momentum.

Read post
A carefully built sandcastle standing intact in a wooden sandbox in early morning light.
ClaudeAISecurityTypeScript3 MIN

Trying out autonomous agents

Sandcastle is Matt Pocock’s workflow for running Claude Code unattended inside a Docker container. It assigns the agent a GitHub issue in a git worktree, then merges the resulting commits back into the user’s branch. Its init command quickly scaffolds the infrastructure, but useful results still depend on supplying clear, focused tickets. Wayfinder fills that planning gap by breaking an idea that is too large for one session into a map issue and smaller decision tickets. Each ticket addresses a single unresolved question rather than a build segment, producing the self-contained, labeled issues Sandcastle needs. Without this map, vague issues led to equally vague pull requests. Before queueing work, the author uses a grilling skill to challenge assumptions and force difficult decisions. Resolving uncertainty early prevents the agent from making costly guesses during unattended runs. For secrets, the author replaces a plaintext .env file with Varlock and a committed .env.schema. Values are resolved through Doppler and exposed only through process.env during execution, although each secret must still be explicitly forwarded into the container configuration. The author would use the setup again but stresses that ticket quality remains decisive. Every diff is still reviewed, tasks stay tightly scoped, and fully unattended overnight operation remains a future goal.

Read post