The talks I really liked? I remember them well enough to tell someone about them over coffee, but the specific details, the links the speaker mentioned, the names of tools that came up in Q&A, those are usually gone by the time I get home. I end up with a few half-sentences scratched into my phone’s Notes app and a vague impression of “yeah, good stuff.”

This week I’m trying something different at SCALE 23x in Pasadena: I brought my AI assistant along.

The Setup

I run Claude Code + PAI on a dedicated Linux VM at home (see my setup here ). It’s a persistent system. My assistant has memory, skills, tools, and context about my work and projects. I usually work with it through a terminal, either at my desk or from my phone over SSH. The conference was no different.

The connection is straightforward. I use Tailscale to connect my devices into my home lab network, so I can reach my server from anywhere. On my iPhone I use an SSH client to connect directly into the VM and start a Claude Code session. Same assistant, same context, same tools, just on a smaller screen.

Before the first talk, I gave it a detailed briefing: Here’s what the day looks like. Here’s the conference. Here’s the schedule from the website. Go scrape the schedule page. If it’s JavaScript-heavy and hard to parse, use your browser skill to render it first. Throughout the day, I’m going to dump raw notes to you. Track which talk I’m probably in based on the time. Expand any links I mention. Follow up on brief references. If I flag something for research, dig into it. Tag anything that looks like a future task. And when I tell you the day is done, build me a full report.

Throughout the Day

The workflow settled into a rhythm pretty quickly. Between talks, or during slower moments, I’d SSH in and dump whatever was on my mind. Sometimes it was a direct quote from a speaker, sometimes a half-formed thought triggered by something someone said, and sometimes just a link I saw on a slide that I wanted to remember.

I let the assistant decide how to organize everything within the structure of my existing system. It roughly did this: every note went into a raw file first, timestamped and verbatim. From there, it triaged each piece. Facts, tools, and contact info went into a knowledge file. Things I wanted to expand on later got queued for deeper reports. The schedule tracking meant it could attach context to my notes automatically. If I dropped a note at 2:45 PM, it knew I was probably in the decentralized trust talk and could frame my notes accordingly.

The other nice thing is that it can ask me for clarity in real time. If I drop a vague note and the assistant needs more context, it asks while the thought is still fresh. That back-and-forth means the notes get augmented properly instead of sitting there as cryptic fragments I’ll have to decode later. And in some rather awesome cases, it was tracking context of time and event and talk description well enough that it was able to figure it out on its own. Very pleasing :)

Slide capture was also fun. When a speaker put up something worth keeping, I’d take a photo and upload it through an exchange portal I have set up on the server. The assistant watches for incoming images, pulls text from them, and starts working with whatever’s on the slide. During the vector database benchmarking talk, I uploaded a series of comparison slides and had the key findings extracted and organized before the speaker moved on to Q&A.

Links got the same treatment. If a speaker mentioned a project or a tool, I’d jot down the name and the assistant would go find it, grab the URL, pull in whatever context was available, and add it to the knowledge file.

The End-of-Day Report

At the end of the day, I told the assistant we were done and asked it to build the report. It compiled everything: talk summaries with expanded context, all the links it had gathered, slide content it had processed, research it had done on topics I’d flagged, and a follow-up list of things to look into later. The report went to a portal page I could review at my leisure, and I also had it send the content to Hypercast , a personal TTS-to-podcast service I run, so I could listen back to it as audio later.

The report was significantly more detailed than anything I would have produced on my own. Not because the assistant made things up, but because it had been doing background work all day while I was focused on the talks.

What Worked

The biggest win was that I could stay present. Instead of trying to capture everything in the moment and losing attention on the speaker, I could drop a few words and trust that the context would be filled in later. A note like “Rivest, homomorphic encryption, 1970s, dig into this” became a full entry with the history of the concept, the 2009 breakthrough by Craig Gentry, why it’s still not computationally practical, and how it connects to the confidential vector search work being presented. That kind of expansion happened across every note I flagged for research.

The Friction

Typing on a phone through an SSH client is not ideal. It works, but it’s slow, and the screen is small enough that you have to be deliberate about what you type. I found myself keeping notes shorter than I might have at a keyboard, which was fine for the workflow but occasionally meant I left out context that would have helped. A laptop would make this easier and faster since the entire workflow is the same, just SSH into the server and go. I just don’t love pulling out a laptop in crowded conference rooms and tip-tapping away on my keyboard when I can avoid it.

Privacy was a consideration. I was typing into a terminal in a conference hall full of people, some of whom could see my screen. I added “buy a privacy screen protector” to my follow-up list pretty early in the day.

Conference WiFi is notoriously slow and inconsistent (why are conference venues always faraday cages?), but Tailscale kept me connected well, and I could use Tmux on the server to reconnect to my session if my WiFi or cellular dropped.

I use voice with my assistant all the time at home, but at a conference you’re stuck typing. What I’d really like is a proper chat interface for my assistant that doesn’t lose all of my context, tools, and systems the way something like the Claude.ai app would. Claude Code’s remote control feature isn’t quite reliable enough for this yet, but I’m sure we’ll have a smoother way to do this in a week or a month. More on that later.

Where This Goes

I’m not sure how novel any of this is. People have been using chatbot apps for note-taking for a while. The difference for me is that the assistant isn’t a blank chat window. It’s a persistent system with context about my work, my projects, and what I care about, and it can act on notes rather than just store them.

I’m still in the middle of the conference as I write this, and I’ll keep refining the workflow over the remaining days. For now, the phone-and-SSH approach is getting the job done better than my usual strategy of hoping I’ll remember things later.

If you’re curious about the personal AI setup behind this, I wrote about it here . And the end-of-day reports live on Hypercast .

In Build or Buy May Have Changed I talked about how the cost of building custom tools has dropped to where more people can realistically build their own versions of things. Near the end of that article I mentioned that the write-up itself could be a starting point for someone’s assistant to help them build something like it. That idea kept pulling at me. If someone’s assistant can read a description of how something works and help them build their own version, what’s the right format for that description?

It’s somewhere between a README and a full codebase. Not a spec, and not really documentation in the traditional sense either. More like a write-up from one builder to another, or from one assistant to another. For now, I’m calling them build notes. I could see these eventually becoming part of a more structured system design document or something like that, but right now they’re just practical descriptions of things I’ve built.

Each note covers what the thing does, why I built it that way, how the pieces connect, and the key decisions with their tradeoffs. There’s reference code included, but they’re not full codebases and they’re not install scripts. They’re closer to showing a friend how you wired something up in your garage, with enough detail that they could go build their own version.

Each note also has a short “for AI assistants” section near the top. If you point your assistant at one of these and say “help me build something like this,” it should have enough to work with. That was the main thing I wanted to get right.

The first three

Mac Services API is how I give my assistant access to my Mac’s Calendar, Reminders, and Contacts without running the assistant on the Mac itself. It’s a REST API that the assistant calls over the network.

Notes Inbox is a capture workflow. I press a button on my iPhone, say what’s on my mind, and it shows up in my assistant’s inbox immediately. An Apple Shortcut handles the dictation and sends it to a small API server exposed through a Cloudflare Tunnel.

Hugo Blog covers this blog’s setup. Hugo with PaperMod, Cloudflare Pages for hosting, and optionally a Cloudflare Worker for newsletter subscriptions. The hosting costs me nothing.

I’ll keep adding more as I write them up. Some of the things in my setup are more involved than these first three, so the depth will vary.

Everything is at github.com/chriscantey/build-notes .

About a month ago I decided to try something. After backing up my Obsidian directories, I asked my assistant to ingest everything into a structured knowledge base it could search and maintain. I figured if it didn’t work out, I could always go back. So far I haven’t looked back.

I’m not declaring Obsidian or local markdown apps over for me. I might go back. But for the moment, I’m enjoying having my assistant as the primary interface to my notes, with a few layers underneath to make sure I’m not locked in.

What It Is

This isn’t a replacement for Claude Code’s built-in memory or PAI’s memory system. Those are getting better over time, and they serve a different purpose. Claude Code’s memory captures patterns and preferences automatically. This is something more intentional. A persistent knowledge store that I control directly, that survives across Claude Code sessions and PAI upgrades, and that I can add to, search, and browse whenever I need to.

Think of it as a personal reference library. The assistant helps you store things, find things, and use what’s there. But the files are just markdown in folders on your system. If the assistant isn’t available, you still have the files.

How It Works

The Knowledge skill gives your Claude Code assistant three workflows: learn, recall, and browse.

Learn is how information gets in. When I come across something I want stored, I just say “remember this” or “save this” and describe what I want. The assistant creates a structured markdown entry, files it under a category, and updates an index. No database, no proprietary format. Plain text, organized by topic.

For example, I might say “remember that my Bambu Lab A1 uses a 0.4mm nozzle and I usually print PLA at 220 degrees.” That becomes an entry under tech with a title, tags, and the full details. Next time 3D printing comes up, the assistant already has my setup.

Recall is how information comes back. When I ask “what do I know about my printer settings” or “how do I connect to the office VPN,” the assistant searches the index first by title and tags, without reading every file. If it finds matches, it loads the specific entries and gives me the answer. Index-first search keeps it fast even as the knowledge base grows.

Browse gives me an overview. I can say “show my knowledge base” and see everything organized by category, or drill into a specific area. Useful for seeing what’s accumulated and whether anything needs updating.

A Few Ways I Use It

Technical reference. Configuration details for servers, network equipment, and services. When I need to remember which port something runs on or what the correct mount path is, the assistant looks it up instead of me digging through config files. Especially helpful for things I set up months ago and don’t touch often enough to keep the details in my head.

Project context. When I’m working on something over multiple sessions, I’ll have the assistant save key decisions and the reasoning behind them. “Remember that we chose Hono over Express for this worker because of the Cloudflare bindings support.” Two weeks later when I’m back in that project, the context is there without me having to re-explain the whole history.

Personal information. Preferences, dimensions for home projects, product model numbers. The assistant knowing that my office desk is 60 inches wide and my monitor arm clamp maxes out at 2.5 inches thick has been useful more than once. It’s the kind of information that doesn’t fit neatly into any other system.

Work patterns. Procedural knowledge. How I like security reports formatted. The steps for a specific compliance workflow. The assistant can reference these patterns and apply them without me repeating myself. I wrote more about this kind of thing in Build or Buy May Have Changed , where the bigger idea is that your assistant can take a reference like this and build something tuned to how you actually think and work.

Multiple Ways In

One thing I wanted to get right was making sure I’m not dependent on any single interface to reach my notes. Right now I have a few paths to the same data:

The assistant itself is the primary interface. The skill handles ongoing capture, search, and retrieval through conversation. That’s how I interact with it most of the time.

There’s also a web UI for browsing and searching entries visually. It’s optional and not required for the skill to work. If you already have PAI Companion running, the UI drops right into your existing portal. Otherwise it can run standalone in Docker.

I also built a markdown editor that runs in the browser. It’s the closest I’ve come to the markdown editing experience I’ve always wanted, and it’s included in the repo in an early form. Handy for cleaning up or expanding entries when you’d rather just edit directly.

And if none of those are available, if the UI service is down or Claude is having an outage, the files are still just markdown on the file system. You can open them in any editor. That was intentional.

A Note on Backups

Moving my notes into this system means my knowledge base now lives inside my Claude Code and PAI environment. That’s a different risk profile than files synced through iCloud or sitting in a local Obsidian vault. It’s worth thinking about. The data is still just files on disk, so any backup strategy that covers that directory works. But it does need to be part of the plan.

Try It

The Knowledge skill works with Claude Code , PAI , and PAI Companion .

Head over to the repo for the Knowledge skill.

If you’re using PAI (here’s my setup ), the quick install is:

cd ~ && git clone https://github.com/chriscantey/skill-knowledge.git

Then tell your assistant:

Read ~/skill-knowledge/INSTALL.md and follow its instructions.

It’ll walk you through setup, ask if you want the web UI, and handle everything from there. Manual install instructions are in the repo if you’d rather do it yourself.

It’s a Starting Point

Like the 3D printing skill I shared earlier, this is an export from my system, not a packaged product. It reflects how I think about organizing information, which may not be how you think about it. The categories I use (tech, home, health, finance, work) are just defaults. Your assistant can create new ones as needed.

The more interesting thing is that your assistant can take this as a reference and build something better. Maybe you want different categories. Maybe you want entries that expire or get flagged for review after a certain period. Maybe you want your knowledge base to integrate with something else entirely. The skill is simple enough that adapting it is straightforward.

I’d love to hear what people do with it. If you build on it and learn something, sharing back is always appreciated.

A quick note before we get into it: this is not the official PAI upgrade path. Daniel Miessler’s recommended approach is to clone the latest release fresh, back up your ~/.claude/ directory, overwrite it with the new version, and then bring your customizations back in. That works. I’ve done it.

What I’ve found works more consistently for me, though, is having my assistant do the migration itself. It’s aware of what changed between versions, it knows where your files need to move, and it can verify each step as it goes. The tricky part is getting the commands, the workflow, and the patterns right, which is why I’ve written this guide and the upgrade script that goes with it. It’s an attempt to package what I’ve learned doing these upgrades so other people’s assistants should be able to do the same thing.

That said, always back up first. If you don’t like what the upgrade did, you should be able to roll back. The script creates a backup for you, but a VM snapshot is even better if you have that option.

What Changed

Daniel describes v4 as “Lean and Mean” : 38 flat skill directories compressed into 12 hierarchical categories, dead systems removed, context footprint cut in half.

The biggest shift is organizational. In v3, everything lived in a flat structure. Skills, hooks, your custom stuff, PAI’s built-in stuff, all mixed together in the same directories. v4 introduces clear boundaries.

Skills got reorganized. 38 flat skill directories became 12 hierarchical categories (Research, Media, Thinking, Security, etc.) with around 63 skills total. Your custom skills move to a dedicated skills/Custom/ folder, so PAI updates never accidentally overwrite your work.

CLAUDE.md is now generated. Instead of one big hand-edited file that grew over time, v4 uses a template system. Your personal configuration lives in dedicated files under PAI/USER/, and a build tool generates a clean CLAUDE.md from them. This keeps things maintainable as both PAI and your customizations evolve.

New PAI directory. v4 adds a PAI/ directory for system documentation, tools, and user context. The PAI/USER/ subdirectory is where your identity, preferences, and project context now live. It’s explicitly portable across upgrades.

Context footprint dropped. Daniel’s release notes say startup context went from ~38% to ~19%. That means more of Claude’s attention goes to your actual work instead of system overhead.

What Gets Preserved

Everything you’ve built should come with you:

• Your custom skills (relocated to skills/Custom/)
• Your steering rules and identity settings (migrated to PAI/USER/)
• Your memory, sessions, and learning data
• Any custom hooks you’ve added

The file layout changes, but your content is preserved.

Before You Start

If you’re running PAI in a VM and your hypervisor supports snapshots or clones, take one now. The upgrade tool creates its own backup, but having a full VM snapshot means you can roll back the entire machine if anything unexpected happens. It takes a minute and it’s the best safety net you can have.

Run the Upgrade

If you’re already using PAI Companion : Tell your assistant to pull the latest changes and run the upgrade:

Pull the latest PAI Companion changes, then read ~/pai-companion/upgrade/UPGRADE.md and follow the upgrade phases.

If you’re not using PAI Companion and just want to upgrade PAI to v4, your assistant can read the upgrade guide directly from GitHub without cloning anything:

Fetch and read https://raw.githubusercontent.com/chriscantey/pai-companion/main/upgrade/UPGRADE.md and follow the upgrade phases.

Either way, the tool should detect your version, back everything up, and walk through each phase.

When it’s done, exit PAI / Claude Code. Run this before you relaunch:

source ~/.bashrc

If you run into any errors after the upgrade, most of them should be resolvable by logging completely out of your VM, logging back in, and starting a fresh Claude Code session.

If you’re doing a fresh install instead of upgrading, the setup guide and companion post cover that path.

Part of the PAI Setup Series. Previous: Build or Buy May Have Changed

I’d been relying on it for years. My first instinct was to look for a replacement. That’s how it’s always worked. A tool goes away, you find the next one, you pay the subscription or the one-time fee, and you move on.

But this time I did something different. I built my own.

Update Monitor

Not as a product. Not to sell. Just for me. I built a small system I’ve been calling Update Monitor. There’s a lightweight component on each of my Macs that scans what’s installed and sends the catalog up to a central service. That service maintains a list of all the software sources my Macs report in on and checks for the latest versions. It classifies updates as low priority or critical based on my own priorities and known sensitivities of things like browsers and other internet-connected software. It tracks published security updates and known vulnerabilities. And it reports back to me when something needs my attention.

The whole thing took a few focused sessions with my AI assistant. Maybe an hour before we had something functional, then a few more sessions over the following days to refine it. And it actually works better for me than the commercial product did.

I can mark my own severity levels. I can hunt down sources for more obscure software that a commercial database might not cover well. The system is tuned to how I think about risk, not how a product thinks I should.

Even more than that, though. I appreciated MacUpdater, and I ultimately decided to trust it, but I never loved that I was scanning all of my apps daily and sending that data out to a company that was hard to find details about. That was the trade: they maintained the database and the Mac software, and in exchange I sent them a complete picture of everything installed on my machines.

With Update Monitor, I was able to shift that model. The scan on my computer is as lightweight as I can make it, keeping the footprint on my machines low. The data goes to my own service, which in my case runs as part of my AI assistant infrastructure . It didn’t have to be set up that way. It could have been a standalone service. I tie it in because the assistant helps me prioritize updates in the context of other things I’m working on, and it’s been useful for hunting down and maintaining the sources.

That was one of the components that made MacUpdater challenging to sustain. Their team maintained a config file with tens of thousands of app entries and a version database with millions of records. They wrote that the daily maintenance took more than a full day to perform, even with a trained team. My list is a lot smaller, and it’s just for me. With the assistant handling most of the source maintenance, I mostly just need to make sure the sources don’t change on me, and I even have it watching for that. Day to day, the scanning and reporting is deterministic.

For someone who thinks about trust and supply chain risks professionally, all of that adds up.

It’s Not Just One Tool

It’s interesting to step back and look at just how much custom software has found its way into my life and workflow, especially over the last few months. Dashboards for tracking projects and compliance. Monitors for services and system health. An assistant infrastructure with skills I’ve built for specific workflows. Media production tooling. Content pipelines. A personal podcast system that turns articles into audio. Gaming tools for friends. Security tools I run on my own network.

None of these are products. None of them are on the app store. They’re things I built because I needed them, and the AI tools made the building fast enough that it was worth doing.

This isn’t just me, either. Build or buy is in the news right now because investors are watching SaaS companies and wondering what it means for their growth when more people can build their own tools. Stock prices are reacting. There’s a big conversation about whether the economics of software subscriptions are shifting.

I think there’s some truth to that, but also likely some overcorrection. A colleague recently pointed out that a lot of what makes large SaaS products viable isn’t just the software itself. It’s the compliance certifications, the liability and insurance, the support infrastructure, the years of security hardening. Millions of companies are not going to stop using their existing tools. And for software that stores large amounts of sensitive data, like communication platforms, file sharing services, or anything customer-facing, the security requirements alone are significant. That’s very unlikely to totally go away.

But for a growing number of people and a growing range of use cases, the cost of building something custom has dropped to the point where it makes sense. Not for everything. But for more things than it used to.

The Shift

A year ago, building something custom meant either learning enough to write it yourself, which could take weeks or months or much longer depending on the project, or hiring someone, which can cost quite a bit of money. The time and expense were enough that buying a SaaS product was almost always the smarter choice, even if it didn’t fit perfectly.

But that’s changing. I’ve had similar experiences with clients recently. We’ve had projects that benefit from visualizing massive amounts of interconnected information, the kind of thing where we would have had to rely on sophisticated pre-built systems or worse, in some cases, just spreadsheets. Being able to build something custom let us take approaches that were far more effective. The features, the usability, the ability to shape the tool around the actual problem instead of the other way around. We built something in about three days that delivered more value than tools we’d been paying for and not getting half the return from.

Would it need to be maintained if it runs long term? Yes. But the initial investment was small enough, and the return immediate enough, that it shifts how you think about the decision.

There’s something else happening too. The software can adapt to you instead of you adapting to it. Especially in use cases like mine, where it’s a one-to-one relationship between me and the tool, that lowers a lot of the friction. I don’t have to learn a whole new system. I don’t have to deal with a major version update from a vendor that rearranges everything. I can make changes when I want to, at the pace I want to.

In a lot of these cases, the tools are more like reports than applications. You use them, and when the need changes, you build something new. The software is more ephemeral. In these cases, not every tool needs to be a product with a roadmap and a changelog.

Why I’m Not Releasing This as a Product

The thought has crossed my mind. Update Monitor works well. Other people might want something like it, especially now that MacUpdater is gone.

But the moment you start thinking about making something available to others, the requirements multiply. Take the update tracker as an example. Maintaining a version database for everyone’s applications, not just the ones on my machines, is a massive undertaking. It’s one of the reasons the MacUpdater team shut down. They couldn’t make the economics work, and the daily effort of maintaining that database was enormous.

And the database is only part of it. Then you need to maintain a client application that works across multiple versions of macOS, on different hardware. You need testing. You need support. You need a server that hosts the database, and with people connecting to that server, you need to protect and monitor that server, keep it updated, and maintain compatibility across all your client versions at the server level.

Then there’s the trust chain. If it’s just for me, I trust the sources I’m picking. I trust the code because I’m reviewing it as I go and testing it as I go. If I ship it to others, now they need to trust me. And I need to trust a wider set of sources, automations, and people. The responsibility grows in every direction.

It goes from being my tool to being a product. That’s a different game entirely. For a long time, we’ve just had to accept trust chains as they were because there was really only one way to get software: someone else built it and you decided whether to trust them. Now there’s another option, and that changes the equation.

Others Can Build Their Own

Here’s what interests me, though. I don’t need to release it as a product for other people to benefit from the idea. This article itself could be a starting point for someone’s assistant to help them build something like it. It won’t be identical to mine, and that’s fine. It’ll be tuned to their needs, their priorities, their threat model.

Maybe not everybody can do this at this moment. But more people can than could a few years ago. More people will be able to next month, next year. The barrier keeps dropping, and it seems to be dropping fast. Tools and projects that were only accessible to experienced developers are now within reach of people who can describe clearly what they want and think through how it should work. That seems to be the real factor right now. The building part has gotten dramatically easier. The harder part is being able to visualize what you need, describe it well, and keep it organized as you go.

There’s also a case for sharing, but maybe not in the way we’re used to. If a lot of people are independently having AI build roughly the same kind of tool, that does feel redundant. Repeated work, repeated compute, repeated time solving problems that have already been solved. But the sharing doesn’t have to look like maintained open source code. It could look more like sharing the specifications. Some markdown files, some diagrams, a clear description of what the system does and how it’s structured. Enough for someone else’s assistant to pick it up and build their own version. Repeatable systems that people can share and build on without anyone having to maintain a repository of code.

I think of it a bit like home improvements. You can build a custom shelf for your garage, and it works great because you know the space, the weight it needs to hold, and how you’re going to use it. Turning that into a product you sell at a hardware store is a completely different undertaking. But showing your neighbor the design so they can build their own version for their space? That’s easy, and everyone benefits.

The Pendulum

Now here’s where the cybersecurity part of my brain kicks in.

Custom software, even internal and personal software, still carries risk. Every tool I’ve built is code that runs on my systems. Code that processes data, makes network requests, and interacts with APIs. I trust it because I’ve been involved in building it, reviewing it, and testing it. But that’s me, and I do this for a living.

When you zoom out, the picture gets more interesting. More people building their own tools means a lot more code running on a lot more systems, with less formal review than we’d typically see from an established software vendor. And when any of that software ends up on the public internet, or gets distributed as a downloadable application, the stakes go up fast. You’re taking on responsibility for code running on other people’s computers, with all the vulnerability, stability, and maintenance concerns that come with it. Update servers to run. Supply chains to think about. These aren’t unsolvable problems. But they are problems, and they multiply quickly.

And it’s not like the existing world of software was perfect, either. People have always shipped flawed code. Plenty of applications have gone unreviewed due to understaffing, tight deadlines, or just not knowing where the problems were. Security incidents aren’t new. What seems new is the volume. There’s an exponential increase in software being built and deployed, with less formal review than before. The people doing it aren’t writing code in the traditional sense. They’re building. There’s code involved, but the relationship to it is different in many cases.

A lot of that software will work fine. Some of it will be deployed on internal networks and serve its purpose without issue. Some won’t. There will be incidents. There will be a correction. Best practices for responsibly building and maintaining personal software will emerge. Businesses may need one set of practices, individuals another, and insurance companies yet another.

And of course, we could be growing the most advanced form of technical debt we’ve ever experienced. Both at the small, personal level, where tools I built last month already need attention, and at the large, interconnected level, where millions of custom systems are quietly depending on APIs, models, and services that could change or disappear at any time.

I’m optimistic, though, that the security capabilities of our assistants and agents could grow alongside the building capabilities. The same tools that help build software can also help review it, audit it, and catch problems. They just need to be applied. If that keeps pace, and there’s reason to think it could, the pendulum could find an equilibrium faster than it otherwise would.

Where This Leaves Me

I’m going to keep building. The tools I’ve made for myself are useful, and the process of building them has been one of the more rewarding parts of working with AI, for me. The unit of software is getting smaller. The audience for a piece of software might be one person. That changes what building, sharing, and maintaining software looks like, and we’re still early in figuring out the norms for it.

The way PAI ships this out of the box is through a built-in voice server that uses ElevenLabs for text-to-speech. It sounds great. But it’s designed for a setup where PAI is running locally on your Mac, and that’s not how I run mine.

How PAI’s Built-In Voice Works

PAI’s voice server uses macOS afplay to play audio and osascript for desktop notifications. If you’re sitting at the Mac where PAI is running, it works well. But if your assistant lives in a VM on another machine, like mine does, there’s nobody sitting at that machine to hear it.

My whole setup is built around keeping my AI assistant in a Linux VM and connecting to it from whatever computer I happen to be on. I don’t love opening ports on my daily drivers, so I wanted everything flowing in the pull direction. The assistant pushes nothing to my machines. My machines subscribe to what they want.

That meant I needed voice to work the same way: generated on the assistant’s side, streamed to wherever I’m listening.

Finding the Right Voice

My first approach was to modify the built-in voice server. I kept the same architecture but added a way to stream audio over WebSocket to a browser on another machine. For the actual speech generation, I started with ElevenLabs since that’s what PAI uses natively.

The ElevenLabs voices are awesome and there are so many to choose from. I loved the way they sounded. But PAI is chatty. It announces every phase of the Algorithm, every task completion, every time it needs your input. And I wanted it to be chatty. I burned through eighty dollars in API credits in the first month, though, and that was a little more than I wanted to spend on hearing “entering the observe phase” five hundred times.

I wanted to let it talk as much as it wanted, so I went looking for something I could run locally.

Kokoro TTS

Kokoro is an 82-million parameter open-source text-to-speech model. What I love about it:

• It works on CPU. No GPU required. It runs anywhere Docker runs.
• It’s fast. Generates a typical notification in 1 to 3 seconds on CPU.
• It’s tiny. 82 million parameters. The model weights are about 330MB.
• Lots of voices. Dozens of options across multiple accents and languages.

Kokoro has over 7.6 million monthly downloads on HuggingFace and is the top-ranked open-source model on the TTS Arena leaderboard. For a model you can run on a basic VM with no GPU, it punches way above its weight.

How It Works

The architecture is simple. Two Docker containers and a browser tab.

1. PAI’s existing hooks fire a POST request to /notify with a message. This is the same API endpoint the built-in voice server uses, so nothing in PAI needs to change.
2. The voice server sends the text to a Kokoro sidecar container.
3. Kokoro generates speech and returns audio.
4. The voice server broadcasts the audio over WebSocket to every connected client.
5. Your browser (or any WebSocket client) plays it.

The voice server itself is about 370 lines of TypeScript running on Bun. The Kokoro sidecar is about 180 lines of Python. Both run in Docker on the same network as the portal server from PAI Companion .

A Drop-In Replacement

I packaged it all up as an optional voice module for PAI Companion , the same repo I use to add a portal, file exchange, and design system to PAI. If you’re not familiar with PAI Companion, I wrote about it in an earlier post .

For getting it connected, I didn’t want to fork PAI’s hooks or rewrite any of the integration code. I wanted to leave PAI as is. So though I started from scratch, I wanted it to be a drop-in replacement for the built-in voice server:

• Same URL: localhost:8888
• Same API: POST /notify with { message, title, voice_enabled, voice_name }
• All existing PAI hooks work without any modification

The only difference is what happens behind that endpoint (within the assistant VM). Instead of calling ElevenLabs and playing audio through macOS speakers, it generates speech locally on the assistant’s VM and streams it to wherever you’re listening.

What You Hear

Here’s what it sounds like in practice. When your assistant starts a new phase of the Algorithm, you hear something like:

“Entering the observe phase.”

When a task completes:

“Portal report created at your-vm-ip port 8080.”

When something needs your attention:

“Waiting for your input on the deployment plan.”

This is all stuff PAI is already saying. It’s functional. You leave a browser tab open, go make coffee, and your assistant tells you when it’s done or when it needs you. That’s the whole point. You can now hear it, even when PAI is running on a completely different machine.

Choosing a Voice

Kokoro comes with dozens of voices. The voice module includes a preview page where you can listen to each one and pick the one you like. Right now I’m using af_heart, but there are plenty of options across accents and languages and I hop around sometimes. You can even have your assistant pick a voice for you.

Listening

The voice module gives you two ways to listen, depending on your setup:

Standalone player. If you just want voice without the rest of PAI Companion, this is a simple HTML page you open in any browser. It connects to the voice server, shows connection status, and plays notifications as they come in. Dark theme, centered layout, volume control.

Portal widget. If you’re already running the PAI Companion portal, a small floating box sits in the bottom-right corner of every portal page. It runs in the background, so you get voice without opening another tab. Mute toggle included.

Both auto-reconnect if the connection drops, and both remember your volume setting.

Setting It Up

If you already have PAI Companion set up, pull the latest:

cd ~/pai-companion && git pull

If you’re starting fresh, clone the repo and set up the core companion first. There’s a walkthrough in the PAI Companion post .

Once you have the repo up to date, open Claude Code and tell your assistant:

Read ~/pai-companion/voice/INSTALL.md and follow the setup phases.

Your assistant handles the rest. It will build the Kokoro base image (this downloads model weights from HuggingFace and may take about 10 minutes the first time), start the Docker containers, set up the web client, and configure upgrade protection so PAI updates don’t overwrite your voice server.

A note on resources: The build temporarily needs about 15GB of free disk space (it settles to around 5GB afterward). Plan for 30GB+ total on your VM, and at least 8GB of RAM. 16GB is more comfortable if you’re running other things alongside your assistant.

Full details are in the README .

What’s Next

I also built a macOS menu bar client in Swift that connects over WebSocket and lives in the system tray. If anyone wants that code, I can add it to the repo as an optional extra. For the purposes of sharing, the browser-based approach covers most setups without requiring a native app.

I’m not even sure this is the best architecture for this. If you’ve found a different way to get voice out of a remote or VM-based assistant setup, I’d love to hear about it. Reach out on LinkedIn or open an issue on the repo.

If you’re running PAI, or especially PAI Companion, and want your system to talk to you, the voice module is ready to try .

So it occurred to me to ask if an LLM could help with this too. I think I asked ChatGPT something like “what kinds of 3D model files can you generate?” and was actually kind of surprised by the answer. It listed out a bunch of different 3D formats it could produce. That kicked off a few months of experimenting.

As you probably already know, LLMs seem to do well with generating code, and OpenSCAD is essentially code. It’s a scripting language for 3D geometry. Variables, modules, boolean operations, all expressed in text. So the same way an LLM can write you a solid SVG or a well-structured HTML page, it can write OpenSCAD that produces real, printable geometry.

Of course there are diffusion-based approaches to 3D generation now, like how AI image generators work, but that’s not what’s happening here. This is actually constructing the object from code, the same way you’d build an app or a website.

STL files are essentially raw triangle meshes with no parameters or structure, just coordinates. LLMs seem to be able to produce those too, but the results were less precise and much harder to iterate on, at least for me so far. The OpenSCAD approach seemed to be more consistent overall.

Like most of these mental unlocks that come with Claude Code and similar tools, my brain was just going wild with ideas the moment it clicked.

But I’ve since learned that I have to keep myself grounded, because for every project where it helped me get from idea to printed object in an hour or an afternoon, there’s one where I spent way too much time going back and forth through 20-plus revisions before I realized I was spinning my wheels. I probably could have just modeled it myself in Blender or made myself learn Fusion better.

So I want to share where I’m at with it, what’s worked for me, and what hasn’t.

The Projects That Worked

Bulb Diffuser

This was my cleanest and fastest success. I had an LED bulb in a lamp and wanted a clip-on diffuser to spread the light more evenly into the lampshade. I was imagining a ring with grippy fingers that could clip onto the bulb, with a wide outer section thin enough to be translucent.

I built this one through my Claude Code + PAI setup. The AI wrote the OpenSCAD, and because it’s parametric by nature, all the key dimensions lived as variables in the file.

Working with OpenSCAD like this probably comes as no surprise to people who are already familiar with it, but this was my first time touching it. So that was a whole revelation on top of working with the AI tools to do it.

The AI handled the geometry well because it was relatively straightforward. The trickier part was figuring out the right thickness for light diffusion. My PLA became translucent at about 0.4mm, just two layers at standard layer height. That’s maybe a physics insight more than a geometry one. But once we had it, the parametric approach meant I could tweak the thickness and re-render quickly.

I only had to do about two print iterations, and that was mainly just dialing in the thickness. The final print clips onto the bulb and works exactly as intended.

Why it worked: Simple geometry that was easy to describe in words. Clear functional requirements (clip on, diffuse light). Easy to verify (does it fit? does light come through?). The code-based approach made iteration fast.

Film Developer Bottle Hooks

I develop color film at home and have a pretty basic DIY setup. I use an immersion circulator (the kind you’d normally use for sous vide cooking) to heat water in a dish tub. The developer bottles sit in the warm water to stay at temp, but they tend to drift around and could easily tip over.

I wanted a hook that clips over the tub edge and cradles a bottle to keep it in place. It wasn’t something I strictly needed to fix, but it was one of those things where if I could get a quick solution without spending a lot of time on it, that’d be great.

This one I did through ChatGPT, before I had my current Claude Code setup. It generated the STL files directly through conversation. The process was iterative. First version, test fit, adjust dimensions, new version. I gave it the exact measurements (tub lip: 15.6mm, bottle diameter: 102mm) and described the mechanical concept I wanted. A clip with some pressing tension over the tub lip, and a half-cup cradle inside the tub for the bottle.

You can tell by looking at it that the result isn’t the prettiest piece of geometry. The shape is a little odd. But it only took one test print before we had something that worked, and I didn’t need it to look nice. I just needed something quick and functional. It’s the exact measurements of my bottles and the side of my inexpensive dish tub. A good scenario for this kind of AI-assisted design: getting from nothing to something useful quickly when precise fit matters more than aesthetics.

Why it worked: The shape was fairly easy to describe with measurements and mechanical behavior. Exact dimensions drove the design. The feedback loop was fast.

Film Scanner Leveling Plate

I wanted a way to level my film scanner easily without buying some fancy device from a photography store if I could help it. This ended up being a bigger project than the bottle hooks, with more iterations, but the exploration was worthwhile. It was fun, and it taught me a lot of terms and concepts about designing parts that I didn’t know before.

The base design was a flat rectangle with rounded corners, a hex grid pattern for rigidity without excess weight, and mounting bosses. But I wanted a little bit more.

I wanted embeddable screw holes for adjustable feet. A three-point leveling system, which the AI actually helped me figure out was more efficient than four-point for this application. And I needed it to mate correctly with my existing film scanner (a 3D printed scanner kit from Tone that I’d already assembled) and a specific LED light panel, holding both in place.

This was another ChatGPT project, and it took a fair number of iterations to get the screw placement right, the fit with the existing scanner body, and the overall dimensions dialed in. The AI seemed to do well with this because the core geometry was still fundamentally flat 3D planes that we were just extruding. A flat plate with holes and bosses. And it helped me think through the leveling approach, which I wouldn’t have known to research on my own.

Why it worked: Essentially a 2D problem extruded into 3D. Precise measurements drove the design. The layout and the patterns were pretty straightforward.

Where It Struggled

Terraforming Mars Tile Grid

I play a lot of Terraforming Mars (tabletop game), and I’d had some initial luck getting AI to make me custom stuff for the game really quickly.

A little Mars globe on a pedestal to use as the first player marker. That came together fast and looked great.

So I got excited and decided to go a little bigger. I figured it would be pretty simple. I just wanted a frame to hold all 60 hex tiles on the game board. The board has a specific hex layout and I just had to tile it and get the dimensions right.

That part did take some iteration, but I was enjoying the process. I got to bust out the calipers and check exact dimensions. We did a bunch of single-hex test prints to dial in the various insets and tolerances, and we arrived at one that worked really well. If you zoom in on the viewer above, you can probably see where the tiles sit.

But this hex grid is way too big to fit on my 3D printer in one piece. So we had to come up with a way to split it into four parts and join them back together. That’s where everything fell apart and I started wasting a lot of time and prints.

We tried dovetails. The shapes came out wrong. We tried magnet pockets. The geometry constraints (2mm base thickness, narrow solid ring between the tile pockets and the see-through openings) made it really difficult. The LLM would generate code that looked reasonable, but the physical results didn’t work, seemingly because it couldn’t “see” how the pieces actually fit together in 3D space.

Another problem seemed to be that I was asking it to make really tiny changes across a really small space, and I just didn’t have good words for what I actually needed. We weren’t connecting on the spatial relationships I was trying to describe. After 13 versions and multiple joining approaches, we have a grid that holds tiles perfectly but we’re still figuring out how the pieces connect.

I think I probably could have gotten there with more time. But the simplicity of the object also means I could probably just take what the AI has already built for me and do the simple joining modifications myself in Fusion or Blender. That’s actually probably what I’ll do next. It’s just taken a backburner because it turned out not to be a ten-minute LLM build.

Why it struggled: The joining problem required understanding how parts fit together in 3D space while dealing with tolerances, material constraints, and assembly angles all at once. I couldn’t explain the geometry well enough in words. Each joining method attempt required understanding clearances and physical constraints that text descriptions just don’t convey well.

The Pattern

Looking across all these projects, a pattern emerged:

AI seems to work well when:

• The geometry can be fully described with measurements and simple shapes
• The design is essentially “2D plus extrusion” or built from primitive solids
• The functional requirements are clear and testable (does it fit? does it clip?)
• You’re building something new from scratch rather than modifying existing geometry
• You can work through it in code (OpenSCAD) rather than raw mesh data

AI seems to struggle when:

• The design requires understanding how multiple parts physically interact
• Geometry is constrained in multiple dimensions simultaneously
• You can’t find the right words to describe what you need spatially
• You’re iterating on complex shapes rather than dimensions

The Workflow That Emerged

Here’s what I’ve settled on after a few months, and it’s the piece I’d actually recommend to other people.

Start with a 2D description. Before anything else, describe an overhead or side view. I’m not talking about actually drawing anything (I’m terrible at drawing). I mean describe it in the form of a 2D sketch and work with the AI on that. Get the dimensions and relationships nailed down in 2D before going to 3D. This forces you to think about how the parts relate to each other, and it gives the AI something concrete to work from.

Use OpenSCAD, not direct STL generation. This was the biggest lesson for me. Having the AI write OpenSCAD code instead of generating raw mesh data made a huge difference for me. The code is readable. It’s parametric. All the dimensions live as variables in the file. You can tweak and re-render without re-explaining the whole design.

Test prints along the way. This isn’t specific to AI-assisted design. It’s just good practice if you’re building anything for 3D printing. Print a small section first. A 4-hex test piece instead of the full 60-hex grid. A smaller version of the diffuser to test multiple thicknesses. This catches fit issues before you’ve spent hours printing the wrong thing.

Version your files, or ask it to version them for you. It helps to not overwrite your working designs. Let the AI know that you want to keep all of its versions so you can refer back to things. I was working in OpenSCAD source files for the most part, and then had it export STLs when I was ready to take something to the printer. But regardless of what format you’re working in, keep versions.

Have it build you something visual to iterate with. This was easier for me than a folder full of files or trying to talk about designs purely in text. I had the AI build me a viewer page early on where I could see renders from different angles, spin models around, and compare versions side by side.

The Skill and the Gallery

If you’ve seen some of my other projects, it should come as no surprise that I have it do this for me too. It’s a pattern I use a lot, and I love this part of the workflow.

Early on in the process, I asked the AI to build me a gallery-style view for each print project. Once I moved to the Claude Code + PAI workflow, I codified this into something more consistent. It’s a skill in PAI, basically a set of instructions that tells the AI how to generate these pages for each project.

For every version we work through, I get multi-angle renders (isometric, side, top views), an interactive STL viewer I can spin around in my browser or on my phone, and a version history showing how the design evolved. All of it served through my portal setup , so I can pull it up on any device without opening a modeling program or SSHing into anything.

I’m very visual, and generating web views of things has turned out to be one of the most useful patterns in this whole setup. I didn’t even know that Three.js could render STL files in a browser until I asked the AI about it and it helped me figure out how. The ability to see the model from multiple angles, compare it to the previous version, and then describe what to change next, all from a browser tab, makes the iteration loop feel really smooth.

The skill itself is what makes this consistent across projects. It’s a markdown file that gives the AI context about my printer specs, OpenSCAD patterns, design principles, and the gallery page structure. Any time I start a new print project, it already knows the workflow and where to put my renders and previews.

Is It Easier Than Learning CAD?

Sometimes. Probably not in general.

For the bulb diffuser and the bottle hooks, using the AI workflow was significantly faster for me than opening Fusion 360 would have been. That’s partly because I just haven’t spent the time with that program yet and may never get around to it. It’s not my world. The designs were simple enough that describing them in words was the fastest path from idea to object.

For the tile grid, I probably would have been better off doing the joining geometry myself in Fusion or Blender. The joining problem involved so many interacting physical constraints (clearances, material thickness, assembly angles) that going back and forth in text was just a clumsy way to approach it.

The sweet spot is functional parts with clear dimensions. Brackets, holders, clips, plates, enclosures. Things where I can say “I need a rectangle that’s 200mm by 135mm by 5mm with rounded corners and mounting holes here, here, and here” and get a working result. These are also the kinds of things that don’t need to look pretty, which helps.

If you already know CAD well, AI probably isn’t replacing your workflow. But if you’re like me and you’re competent enough but not fast in traditional tools, AI can get you from concept to printed object in an afternoon for the right kinds of projects. Just go in knowing it has limits, and be ready to iterate.

If You Want to Try This

The core of my approach is a set of instructions (a “skill” in Claude Code or PAI terms) that I give my AI assistant. It provides context about 3D printing: my printer specs, OpenSCAD patterns, design principles, and the lessons learned from projects like these.

Head on over to the repo for a draft of my 3D printing skill.

If you’re using PAI (here’s my setup ), the quick install is:

cd ~ && git clone https://github.com/chriscantey/skill-3d-printing.git

Then tell your assistant:

Read ~/skill-3d-printing/INSTALL.md and follow its instructions.

It’ll walk you through setup, including asking about your printer specs. Manual install instructions are in the repo if you’d rather do it yourself.

I don’t think this skill is complete or even particularly well polished. It’s the result of a few months of trial and error, and it reflects what’s worked for me with the projects I’ve taken on so far. I would love it if someone who knows more about OpenSCAD, 3D modeling, or mechanical engineering could take this, improve on it, and share what they learn. It may be helpful to others who want to dive in and start playing around with this like I did, in a non-professional, just-for-fun sense.

Big picture, even without this skill, the workflow section above is the important part. Start with 2D descriptions. Use something like OpenSCAD. Print test pieces. Have it render you an interactive viewer or something to track your work. Keep your expectations calibrated. And remember that “just a language model” can mean a whole lot when the output format is code.

That’s the gap PAI Companion fills. It gives your assistant a single, persistent service that serves all the web content it creates for you. One Docker container, always running, no re-explaining the setup every session.

What It Is

PAI Companion is a simple add-on for PAI , Daniel Miessler’s open-source framework for enhancing Claude Code. It adds some infrastructure for visual output so your assistant can create web pages, dashboards, reports, and styled documents that you can view in your browser. It does make some additions to your PAI configuration (steering rules, a design system, identity context), but it shouldn’t break anything.

Here’s what it sets up:

• A portal server that serves web content your assistant creates. Ask it to build you something, and it shows up at a URL you can open from your host machine. One service, always running.
• A file exchange with drag-and-drop in the browser. Similar to the file drop tool from the last post, but integrated into the portal.
• A clipboard page for when your assistant generates text you want to copy, like an email draft or a code snippet.
• A dark theme design system so everything your assistant builds looks consistent and clean out of the box.
• Directory conventions that organize your home directory so files land in predictable places.
• A browsable skills catalog and agent roster so you can explore what your assistant can do from a web page. Click any skill to read its full definition, or any agent to see its profile and capabilities.
• A welcome page with example prompts and a quick explanation of how everything fits together.

This is just one approach to giving your assistant visual output. It’s not the only way, and it’s not necessarily a complete setup. It’s a starting point that works for me and might work for you.

Who This Is For

This is probably most useful if you’re someone who benefits from visual feedback. If you’re comfortable reading terminal output all day, you might not need this. But if you like seeing things rendered in a browser, if dashboards and styled pages make information click faster for you, this gives your assistant the ability to communicate that way.

It’s also helpful if you’re running in a VM like I recommend. The portal gives you a clean way to view your assistant’s output from your host machine without thinking about ports and file paths every time.

Who This Is Not For

If you’re running PAI on a VPS or any server exposed to the internet, this is not for you. The portal server runs over HTTP. There’s no authentication, no encryption, and no access controls. Anyone who can reach the port can see whatever’s being served.

This is designed for a VM on your local machine or your local network. That includes VMs running on your laptop, on a home server, or on a hypervisor like Proxmox. The point is it’s on a network you control. That’s a very different risk profile than something sitting on the open internet.

What to Expect

I want to be straightforward: it’s a work in progress. It should work. I’ve helped a few friends set it up, and the package is based at least partially on the system I’m actually running. But it’s still evolving. Things might change. There might be rough edges.

The setup is designed to be resumable. Each phase is independently verifiable, so if something breaks or you need to come back to it, you can pick up where you left off.

Before You Start

You need a handful of things installed before running the companion setup. If you followed the earlier setup post , you already have most of them. The only new addition is Docker.

If you haven’t done the setup post yet, you’ll need to install the basics first. Run everything as a regular user with sudo access, not as root. (If your distro didn’t create one during installation, here’s how to set that up .)

sudo apt update && sudo apt install -y curl git zip

curl -fsSL https://bun.sh/install | bash && source ~/.bashrc

curl -fsSL https://claude.ai/install.sh | bash

git clone https://github.com/danielmiessler/PAI.git
cp -r PAI/Releases/$(ls PAI/Releases/ | sort -V | tail -1)/.claude ~/ && cd ~/.claude && sed -i 's/--mode gui/--mode cli/' install.sh && bash install.sh

[ -f ~/.zshrc ] && cat ~/.zshrc >> ~/.bashrc
sed -i 's|skills/PAI/Tools/pai.ts|PAI/Tools/pai.ts|g' ~/.bashrc
source ~/.bashrc

Docker is the one thing the companion setup can’t work without. If you don’t have it yet:

curl -fsSL https://get.docker.com | bash
sudo usermod -aG docker $USER

Log out and back in after that, then verify it works without sudo:

docker run --rm hello-world

Why not let the assistant handle this? We don’t give Claude Code sudo access. That’s intentional. These prerequisites need elevated privileges, so you run them yourself. Once the companion is set up, nothing else needs sudo.

The companion repo also has a full prerequisites file with optional extras like Playwright and useful CLI tools.

Installing the Companion

Once Docker is working and you’ve got PAI v4.0 running, clone the repo into your VM:

git clone https://github.com/chriscantey/pai-companion.git ~/pai-companion

Then open PAI / Claude Code and say:

Read ~/pai-companion/companion/INSTALL.md and follow the setup phases.

Your assistant handles the rest. It will walk through each phase, setting up the portal server, file exchange, clipboard, design system, and directory structure. When it’s done, you’ll have URLs for the portal, the file exchange, and the clipboard.

The first thing I’d check out is the welcome page. It has example prompts you can try, a quick breakdown of how the system works, and links to the skills catalog and agent roster so you can browse what your assistant can do.

What’s Next

This is still being shaped. I’ll probably do another pass on the package as I keep refining my own setup, and I’d like to get more feedback from people actually using it. If you try it out and run into something, the GitHub repo is the place to raise it.

Part of the PAI Setup Series. Previous: File Drops for Your AI Assistant VM

You followed the setup guide , you’ve got your AI assistant running in a VM, and now you’re wondering: how do I actually get files in there?

If you’re comfortable with the command line, scp or rsync work fine. If your virtualization software has built-in file sharing, that works too (though depending on how much you want to sandbox things, it may come with tradeoffs). But if you want something simple that works from any browser, we can build a drag-and-drop file upload in about five minutes.

If you followed along with the weather page at the end of the setup guide, this is another example of the same pattern, just slightly more advanced. You give your assistant a prompt, watch it work through the problem, and end up with a running tool. The more you do this, the more you start thinking of things you can build the same way.

The Prompt

Open a terminal in your VM, start Claude Code, and give it this:

Build me a simple file upload server. I want to:

• Have a nice drag-and-drop web interface that I access from my browser
• Save uploaded files to ~/uploads/
• Limit file size to 100MB
• Show upload progress Use Bun. Keep it simple.

Your assistant will think through the request, plan its approach, write the code, and start the server. It will figure out the VM’s IP address (since you’re accessing it from another machine, not localhost) and give you a URL to open in your browser.

Drag a file in. Check ~/uploads/. That’s it.

What Can You Do With It?

This is where it gets interesting. The upload server itself is just plumbing. The real value is what happens once your assistant has access to those files.

Say you had a handful of meeting transcripts. You could drop them in, then ask your assistant to pull out all the action items, decisions, and blockers across every meeting.

Analyze all meeting notes in ~/uploads/. Create:

1. A consolidated action item list with owners and status
2. All decisions made and when
3. Current blockers and their resolution status
4. A timeline of how the project evolved

Or ask it to build you a nice dashboard view of that information, something you can open in your browser and actually scan through quickly.

The same idea applies to anything you might want to process: PDFs, notes, data exports, research. Once the files are accessible to your assistant, you can work with them conversationally. Describe what you want, and it builds the thing.

Making It Permanent

There’s one problem with what we just built: the upload server only runs inside your current session. Close the terminal, and it’s gone.

So ask your assistant to fix that. Something like:

Can you set up the upload service to run long-term in the background? Pick a port where it can stay running, set it up as a service so it auto-restarts if it crashes or if the server reboots, and document how it’s set up so we can refer back to it.

Depending on what operating system you’re running, your assistant will probably set up something like a systemd service (the standard way Linux manages background processes), choose a port, and make sure the upload server starts automatically. When it’s done, your file drop should always be available, whether you’re in a Claude Code session or not.

Before You Leave This Running

A couple things worth thinking about.

Data sensitivity

Your VM sandbox keeps the assistant from accessing your main computer, but anything you drop into that uploads folder becomes part of what it can read and process. If the content is sensitive, consider whether you’re comfortable with it being sent to the cloud for processing. Using example data while you’re learning is a good approach. Get comfortable with how the system works, then decide what real data you’re ready to bring in.

Network exposure

If you’re running this in a VM on your local machine, the risk is relatively low. The upload form is only reachable from your network. But if you’re running this on a VPS or any server exposed to the internet, this is not code you want sitting on an open port. There’s no authentication, no encryption, and we haven’t done any security review of what the assistant built. Anyone who can reach that port can upload files to your server. Keep this on a private network, or behind a firewall. If you need remote file access on a public server, that’s a different problem that deserves a more thoughtful solution.

What’s Next

This is one small example of a bigger pattern. Your assistant can build tools, run them, and turn them into permanent services, all from a conversation. The upload server just happens to be a practical first step because it solves the “how do I get files in here” problem. From here, you can start exploring what else your assistant can do with the files you give it, and what other tools it can build for you along the way.

Part of the PAI Setup Series. Previous: Setting Up Your Personal AI Assistant

You’ve probably used Claude or ChatGPT in a browser or app. You type a message, it responds, you ask it for something, it generates documents and content for you. But then you have to download it, copy and paste it, put it where it needs to go. That’s useful, but it’s limited by how quickly you can move data back and forth between what it’s building, the notes you’re feeding it, and the places you’re testing and checking its work.

You may have also used coding assistants like GitHub Copilot or Cursor. These go further: they can see the context of actual code in a folder or repository, and they’re not just making suggestions, they’re writing code for you. You might have even used Claude as the model behind Copilot. But the AI is still limited to what you give it, either as explicit context or what’s in that project folder.

Claude Code is different. It’s Anthropic’s command-line tool that runs as an agent on your machine. It can read files anywhere on your system, write code, run commands, make API calls, and interact with tools. It’s not scoped to a single folder or IDE (unless you scope it yourself). Think of it less like a chatbot and more like a collaborator who can actually operate your computer. Depending on the access and tools you give it, it can do most of what you’d do at a terminal yourself.

The name “Claude Code” is a bit misleading. Yes, it’s great at coding. But it’s also great at everything else: writing, research, file management, automation, building tools. It’s really more of a personal AI assistant that happens to run in a terminal. The name will probably evolve, but for now, that’s what we’ve got, and it works really well.

A lot of people run Claude Code directly on their personal machines, whether that’s Mac, Windows, or Linux. That can be a valid choice once you understand what it can do, how to limit it, and how to protect your data and system. But I’m choosing to run mine in a Linux VM for now. I have too much sensitive stuff accessible from my main computer, and while I’m in this exploratory learning-and-building mode with Claude, I don’t want to have to monitor its every move the way I would on my personal machine. A more contained environment lets me learn faster with less anxiety. And Linux VMs are something I’m comfortable setting up and managing.

Claude Code is very capable on its own. You can teach it a lot just with text files, folders, and structure. But here’s the thing about this current realm of AI LLMs we’ve got: the more information you load into a conversation, the more it has to juggle at once, and at some point that starts to limit what it can effectively do. So you don’t want to overwhelm it. You want to guide it in the right direction for whatever you’re working on, loading in just what it needs at any given time.

This is where structure really helps. Claude Code has a way of loading context on demand. You can have tons of information about how to do different types of tasks, organized into skills and workflows and folders, and Claude can choose what to load based on what you’re actually asking it to do. That means you get the benefit of all that knowledge without stuffing everything into every conversation.

You can build this structure yourself, or you can use someone else’s that they’ve figured out works well. There are probably thousands of different approaches out there. People are publishing their workflows on YouTube, Reddit, and blogs all the time. They’re all worth exploring to see what resonates with you.

What has worked really well for me is a project called PAI (Personal AI Infrastructure) by Daniel Miessler. It immediately adds structure on top of Claude Code: skills, workflows, hooks, customization. It helps Claude think and respond in ways that match how I want to work. That might sound vague right now, but it’ll make a lot more sense once you start playing with it.

That’s what this article and the accompanying video are for: to help you get started playing with it, and to do that in a safer way than just installing it directly on your main computer. Once you have it running, you can go back and read Daniel’s really excellent article on PAI to understand the philosophy and architecture. The concepts will land much better once you’ve actually used the system.

One note: both PAI and Claude Code evolve quickly. Daniel pushes updates regularly, and I pull those into my system and adapt them. And who knows, some of this infrastructure might even get built into Claude Code itself in a few months. But this is what I’m using now, and I’ll try to update this guide or this series as things change.

Why a VM?

Claude Code runs commands, writes files, and makes API calls. That’s what makes it powerful. It’s also why I’d recommend starting in a contained environment.

A Linux VM gives you room to experiment without worrying about your main system. You can let Claude run more freely, see what it’s capable of, and develop your own comfort level over time. You also get space to understand the security settings, learn how to limit things, and understand what you’re saying “yes” to when you grant permissions.

You might even eventually move it to your main machine. But starting in a VM gives you the room to learn first.

Prerequisites

Before we start, you’ll need:

• A Linux environment (one of the following):
  • A VM on your computer
  • A Raspberry Pi 4/5 with 8GB RAM
  • An old computer you can wipe
• Terminal access (SSH if remote, or direct terminal access)
• Basic command line comfort (or willingness to learn as you go, Claude can help!)
• An Anthropic account with Claude Pro ($20/month)

Setting Up a Linux Environment

If you already have a hypervisor or home lab, you know what to do. If not, here are your options:

Option 1: VM on your computer (recommended for most people)

This is free, gives you the best performance, and keeps everything local.

• VirtualBox - Free and open source, works on Windows, Mac, and Linux
• UTM - Free, open source, Mac-native (recommended for Apple Silicon Macs)

If you’ve never set up a VM before, NetworkChuck has an excellent video explaining what VMs are and how to set up VirtualBox . Ubuntu also has an official tutorial for running Ubuntu in VirtualBox .

Note on Ubuntu versions: These links may reference an older version of Ubuntu. The recommended current version as of this writing is Ubuntu Server 24.04 LTS. Download Ubuntu Server and select your architecture (AMD64 for Intel/AMD, ARM64 for Apple Silicon).

Note for Mac users: NetworkChuck’s video covers AMD64 (Intel/AMD) setups, including BIOS settings for virtualization. On Apple Silicon Macs, you don’t need to change any BIOS settings. VirtualBox works, but UTM is generally smoother. Either way, download the ARM64 version of Ubuntu, not the standard AMD64 image.

Option 2: Raspberry Pi or old computer

A Raspberry Pi 4 or 5 with 8GB RAM works well. So does any old computer you can wipe and install Linux on. This gives you a dedicated always-on system.

Option 3: Cloud VPS (advanced)

Cloud providers like DigitalOcean, Linode, or Vultr work, but introduce additional complexity: you’ll need to configure firewalls, consider HTTPS for any web content, and manage a publicly-accessible server. If you’re comfortable with that, go for it. Otherwise, start local.

What to install:

I recommend Ubuntu Server 24.04 LTS. It’s well-documented, beginner-friendly, and the installer walks you through creating a non-root user with sudo access (which is what you want). Skip the desktop environment; you’ll be working at the command line.

Before continuing:

You should be at a command line in your VM, logged in as a non-root user that has sudo access. Ubuntu creates this during installation. If you’re using Debian or another distro that defaults to root only, here’s how to create a sudo-enabled user (the steps work on Debian too).

Tip: You probably already have access to Claude in your web browser, or another AI assistant. If you get stuck at any point, they can be really helpful for figuring out specific steps. Just tell them where you are and what you’re trying to do.

A Note on curl | bash

You’re about to see a few commands that look like curl ... | bash. This pattern downloads a script from the internet and runs it directly on your machine. Security folks tend to cringe at this pattern, and for good reason. It’s not something you’d normally do on a production system or a machine with sensitive data.

That’s part of why we set up this VM. In a contained environment, you can be a little less cautious. But also these particular sources (Anthropic’s installer, Bun’s installer) are generally trustworthy. But it’s worth noticing what you’re doing: you’re running code from the internet based on trust in the source.

We’ll come back to this idea later, because there’s an interesting parallel when we start giving Claude instructions from external sources.

Step 1: Install Dependencies

We only need a couple things to get started:

sudo apt-get update && sudo apt-get install -y curl git zip

Step 2: Install Claude Code

Anthropic provides an official installer :

curl -fsSL https://claude.ai/install.sh | bash

When the installer finishes, it will ask you to add Claude to your PATH. Run this:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

Step 3: Install Bun

Bun is a fast JavaScript runtime that Claude Code uses for various tools:

curl -fsSL https://bun.sh/install | bash

Step 4: Load the New Commands

Both installers added themselves to your shell configuration so you can type simple commands like claude and bun to launch things. Load them:

source ~/.bashrc

Verify everything works:

claude --version
bun --version

Step 5: Install PAI

Now we add the scaffolding that turns Claude Code into something more powerful.

If you already have Claude Code settings you want to keep, back them up first:

[ -d ~/.claude ] && mv ~/.claude ~/.claude-backup-$(date +%Y%m%d)

Clone the PAI repository and install the latest release:

git clone https://github.com/danielmiessler/PAI.git
cp -r PAI/Releases/$(ls PAI/Releases/ | sort -V | tail -1)/.claude ~/
cd ~/.claude && sed -i 's/--mode gui/--mode cli/' install.sh && bash install.sh

This gives you a full copy of PAI in your home folder. You can browse it, reference it, and pull updates later.

The installer will auto-detect your system and check for dependencies. Since you already installed everything above, it will find Git, Bun, and Claude Code and move on.

The wizard will ask you a few questions. Here’s what to enter:

• What is your name? - Your name
• Timezone - It auto-detects this. Press Enter to confirm.
• Name your AI assistant - Whatever you want (default is PAI, I call mine Assistant)
• Startup catchphrase - Press Enter for default, or customize it
• Projects directory - Press Enter to skip
• Voice setup - When it asks about ElevenLabs, choose “Skip voice for now.” It will still try to configure voice defaults. Accept the default voice, then when it asks again, choose skip. We don’t need voice for this setup.

Step 6: Fix Shell Configuration

The PAI installer writes to .zshrc (the default shell on macOS), but Ubuntu uses bash. These commands merge any zsh config into your bash config and fix a path issue in the current release:

[ -f ~/.zshrc ] && cat ~/.zshrc >> ~/.bashrc
sed -i 's|skills/PAI/Tools/pai.ts|PAI/Tools/pai.ts|g' ~/.bashrc
source ~/.bashrc

The sed line fixes a known issue where the installer writes the pai alias pointing to the wrong path. Without it, running pai will fail with a “Module not found” error.

Step 7: First Run and Authentication

Now launch Claude Code with PAI:

pai

The first time you run it, you’ll walk through a few prompts:

Color scheme: Pick dark mode, light mode, or a color-blind friendly version of each.

Login method: Select “Claude Account (with Subscription)”. This is where you’ll need that Claude Pro account. If you don’t have one yet, head over to claude.ai to sign up. The other login methods will likely cost you more money since they use API credits directly.

Browser authentication: It will say “Opening browser to sign in” but that won’t work since you’re in a VM. Instead, copy that long URL it displays. Paste it into a new tab in your web browser. Sign into Claude there (or if you’re already signed in, it will just ask you to authorize). Click Authorize, copy the code it gives you, and paste it back into the terminal where it says “Paste code here.”

Login successful: Hit Enter to continue.

Safety warning: It will warn you that Claude can make mistakes and that you need to review what it does. This is part of why we’re running it in a VM, right? We’re not giving it access to anything sensitive until we’re comfortable with how it works.

Trust folder: It will ask if you trust the .claude folder. You’ll need to choose “Yes, I trust this folder” to use PAI.

And then you’re in. You should see an interactive prompt. Try this to make sure everything is working:

“What’s my name and what skills do you know?”

It should know your name (from the wizard) and list a couple dozen skills that come with PAI out of the box. If you see that, you’re ready for the next step.

Step 8: Adapt PAI for Linux

PAI was built on macOS, so there are a few more things that need patching for Linux. Here’s where it gets interesting.

Paste this into the prompt:

Read this URL and follow the instructions to adapt PAI for Linux: https://gist.githubusercontent.com/chriscantey/50523c88bc54663916481882f3e3c704/raw/pai-linux-adaptation.md

Your Assistant (Claude + PAI) will read the file, patch the statusline for Linux compatibility, and add a steering rule so web servers provide accessible URLs instead of localhost.

A note on what just happened: This “read a URL and follow the instructions” pattern is powerful. It’s also a good example of why you want to be thoughtful about what you point your AI at.

Remember earlier when we talked about curl | bash? That’s running code from the internet based on trust. This is similar, but instead of code, it’s instructions for an AI that has access to your system. If that file contained malicious instructions, your Assistant might try to follow them.

From the outside, these might seem like the same risk, but there’s an important difference. A shell script can be more predictable. You can read it and see exactly what it will do. It’s traditional programming: the same script run twice will do the same thing.

An AI agent is different. Ask it to do the same task twice and it might take different approaches. Run it on a different system, with a different person, against a different backend, or with a future version of Claude, and the behavior may vary. That flexibility is what makes agents powerful, but it also means there’s more room for them to interpret, improvise, and find creative paths to a goal. Great when you want that, less great when someone’s trying to trick them.

This is one example of what’s sometimes called prompt injection: content designed to manipulate an AI’s behavior.

When your Assistant searches the web, reads files, or fetches URLs, it might encounter instructions embedded in that content. The same way you give it instructions, someone else could sneak instructions into a webpage the Assistant reads, and the Assistant might follow them without realizing they came from an untrusted source.

PAI has some hooks and protections in place to prevent certain things from happening, and running as a non-root user adds another layer. But these are layers, not guarantees. The contained environment we set up is part of the overall approach: you can learn how this works, build comfort over time, and be more thoughtful about what you expose it to as you expand its access.

More on security practices in a future post.

What You Have Now

At this point, you have:

• Claude Code running on Linux
• PAI’s skill system loaded
• Linux-specific patches applied

You can start exploring. Type /help to see available commands. Try invoking a skill. Break things. Rebuild.

Try It: Build Something

The best way to understand what your Assistant can do is to build something with it. Here’s a quick one you can try. Paste this into the prompt (replace the city with your own):

Build me a simple web page that shows the current weather for [insert your city name here]. Use a free and open weather API that doesn’t require an API key. Fetch the current conditions and display them in a modern, nice looking page with a dark background. Serve it so I can view it in my browser.

You’re going to see a lot of stuff fly by, especially if you’re not used to watching code. That’s okay. Watch as it works through the problem: searching for weather APIs, writing HTML, fetching live data, spinning up a server. Part of what PAI adds to Claude Code is all this thinking and verification, making sure it’s actually achieving what you asked for. If it hits a problem, it’ll try to fix it or help you understand what went wrong. It might take a little while, especially the first time. When it gives you a URL, open it in your browser. You should see your weather page, built from scratch, running live.

It might also do something interesting: download tools it needs to help you. For example, it may install Playwright and Chromium so it can open a browser and verify its own work. Notice I said “might.” Running the same prompt on two different systems, one time it did its own verification, another time it didn’t. That’s the nature of these systems. It’s also a little spooky when it just downloads apps on its own. That’s why we’re in a VM.

That’s the difference between a chatbot and an agent. The chatbot would give you code to copy, or possibly a preview. Your Assistant actually builds the thing and runs it. And if you give it the right access, it can put that page online for you, all in one go. Then you can work back and forth with it to add features, change the design, and build on it over time. All without the copying and pasting.

Where to Go From Here

Spend some time with it. Point it at some data you’re comfortable experimenting with. Think about something you’ve been wanting to build: a tool, a design, a dashboard, a 3D model, really anything is worth a try. It’s running on a computer, so it can run the same tools you’d run yourself, and in many cases it can grab new tools to work with.

If you want the deep dive on the philosophy and architecture, read Daniel’s PAI article . The concepts will land better now that you’ve seen the system in action.

This is the first in a series. I’ll be posting more about security practices, building custom skills, and how I’m using this system in my own work. Subscribe or check back if you want to follow along.

Resources

• Daniel Miessler’s PAI Article - The complete system overview and philosophy
• PAI GitHub - Source repo with releases, skills, and documentation
• PAI Releases - The install command above automatically uses the latest release
• Linux adaptation gist - The Linux adaptation instructions from Step 8
• NetworkChuck’s VM video - Great intro to VMs and VirtualBox setup
• Ubuntu VirtualBox tutorial - Official guide for running Ubuntu in VirtualBox

This guide is current as of PAI v4.0 (February 2026). PAI evolves quickly, so some details may change.

There are the tools themselves. ChatGPT, Claude, Gemini, Copilot. Image generators like Midjourney, DALL-E, Stable Diffusion. Voice cloning, video synthesis, coding assistants. A dozen categories of software, all lumped under one umbrella term.

But there’s another layer that I think matters just as much: the perspectives people bring when they talk about AI. How you feel about these tools depends a lot on where you’re standing. Whether you see opportunity or threat, convenience or risk, the future of work or the end of it. We’re not just using different tools; we’re coming at this from completely different places. And I think that’s shaping adoption, trust, and the conversations we’re having about what AI should and shouldn’t do.

So I want to try and break down both: the many things we’re calling AI, and the different lenses through which people see them. This list isn’t comprehensive, and I expect my thinking will keep shifting as this whole landscape does.

The Many Faces of AI

When someone says “AI” to me now, the first thing I’m thinking is: which one?

There’s search-replacement AI, whether that’s ChatGPT, Claude, Gemini, or the AI summaries that now appear at the top of Google results. A lot of people use these the same way they used to use search engines: ask a question, get an answer. The convenience is undeniable. But so is the confidence problem. These tools can be wrong, cite sources that don’t say what they claim, or just make things up entirely. They deliver answers with the same tone whether they’re right or completely off. That’s a strange new dynamic to navigate.

There’s boardroom buzzword AI, the one that executives drop into quarterly reports. It’s a checkbox. A signal that the company is “innovative.” Sometimes there’s real substance behind it, and sometimes it’s more about optics than implementation. I’ve seen both.

There’s coding AI, helping developers write software faster and helping people with no programming background build things they couldn’t have built before. “Vibe coding” is what some people call it: describing what you want and letting the AI figure out the implementation. It’s genuinely cool to see people bring ideas to life that would have stayed stuck in their heads otherwise. But it comes with responsibility: we have to stay mindful of where any unreviewed AI-generated code ends up running in production.

There’s job-fear AI. The version that has people wondering whether their job will exist in five years. Writing, coding, design, analysis, customer service. The automation question isn’t new, but AI has expanded the scope of what might be automated. I’ve worked in and around creative industries for most of my career, and I watch friends and former colleagues grapple with this one. When your livelihood feels threatened, you don’t want nuance. You want clarity. The people who are cautious about these tools aren’t wrong to be. They’re protecting something real. And honestly? AI might be coming for my work next. I don’t think anyone is immune from that question right now.

There’s slop-generating AI, pumping out endless content that nobody asked for. Low-quality articles, spam images, fake reviews. The internet already had a noise problem, and some of these tools are making it worse. Then there’s the content people think is real but isn’t. AI-generated entertainment is one thing. But fake videos, fabricated quotes, and voice clones designed to manipulate? That’s something else entirely.

There’s plagiarism and copyright AI, trained on other people’s work without clear permission or compensation. Artists, writers, and creators have legitimate frustrations here. The legal and ethical questions are far from settled, and I don’t think we should pretend they are.

There’s environmental-concern AI. These systems can consume significant amounts of power, and depending on the facility and location, water for cooling. That’s not fear-mongering; the resource demands are real. But it’s also more nuanced than some headlines suggest. Some data centers are moving to zero-water cooling systems, while others in water-stressed regions are drawing millions of gallons daily. Whether the tradeoffs are worth it probably depends on what’s being accomplished with that compute.

There’s creepy surveillance AI, feeding facial recognition systems, risk-scoring algorithms, behavioral tracking, and data harvesting that gets packaged and sold. These tools power monitoring, manipulation, and control, often without the knowledge of the people being watched, scored, or profiled. Privacy erosion at scale, and once it’s gone, it doesn’t come back easily.

There’s medical and research AI, the kind that helps scientists analyze data, discover drugs, identify diseases earlier, and push forward in ways that would take humans decades longer. When AI helps catch a cancer earlier or accelerates vaccine development, that’s the version of this technology I want to see more of.

There’s security defense AI, and this one hits close to home for me. These tools can help security teams detect threats faster, triage alerts that would otherwise pile up, and give smaller teams capabilities that used to require much larger headcounts. It’s not a silver bullet, but it can genuinely make a difference for people trying to protect systems and data.

There’s cybercrime AI, the kind that helps bad actors craft more convincing phishing emails, find vulnerabilities faster, and automate attacks that used to take longer and in some cases more expertise. Working in cybersecurity, I see this one up close. The same capabilities that help defenders also help attackers, and that arms race is accelerating.

And then there’s the one I actually use every day: practical workflow AI. The tools that help me get more done, think through problems, and extend what I’m capable of.

And all of this is to say nothing about the machine learning that’s been quietly running in the background for years: Siri and Alexa, autocorrect, spam filters, photo face recognition, recommendation algorithms, fraud detection, GPS route optimization, robovacuums. We’ve been living with “AI” for a long time without the cultural weight the term carries now. What I’m talking about here is really the current moment, the strange dichotomy the word has taken on in our society.

Where I’ve Landed (For Now)

I’m using AI to improve my workflows, increase what I can accomplish, and do more for my clients. It’s not an abstract concept for me anymore. It’s integrated into how I work.

In practice, that looks like a few different things. I’ve always been big on communication: presentations, videos, reports for clients. That work takes time, and I used to do less of it because each piece was a production. Now I can take the data and ideas I’m working with and turn them into polished deliverables much faster. Three or four times as much output in the same window.

It helps me manage large implementation projects for clients, tracking the dozens of moving pieces that come with any serious technical engagement. It helps me build tools, including ones I can send to a 3D printer. It helps me build and manage the self-hosted services I run in my own lab. It connects into my calendar, my task lists, my documents, and helps me stay on top of a growing number of coding projects and automations.

And it’s let me tiptoe into areas I’m still new to. I’ve started experimenting with custom hardware, building small devices that integrate with my automation systems. I’m not a hardware hacker by background, but having something that can help me bridge the gap between what I know and what I’m trying to learn has made that kind of experimentation feel possible.

The way I use it keeps shifting. A year ago it was mostly standalone conversations. Now it’s more embedded, connected to the systems I already use, doing real work alongside me.

And even within the tools themselves, I’m not locked into one. Right now I’m using Claude Code with a lot of customization layered on top. But over the past few years I’ve moved between Claude in the browser, ChatGPT, local LLMs, various image generators, different voice tools. My approach has been to build my workflows so they can sit on top of whichever tool is giving me the best results at any given time. None of this is static, and neither is my setup.

And here’s the weird part: when I’m actually using it, I stop thinking about it as “AI.” It’s just a thing that can do work. I hand tasks to something that understands what I’m trying to accomplish. It becomes another way to build processes and applications, kind of independent of all the hype and fear around the term itself.

Daniel Miessler , whose work I’ve been following closely for a while, puts it this way:

“The main practical theme of what I look to do with a system like this is to augment myself. Like, massively, with insane capabilities. Think Tony Stark stuff, no joke. Minus the flying. It’s about doing the things that you wish you could do that you never could do before, like having a team of 1,000 or 10,000 people working for you on your own personal and business goals.”

That really resonates with me. Not because I think AI is magic or harmless, but because I’ve experienced what it feels like to have capabilities I didn’t have before. To build things I couldn’t have built alone. To work on problems that would have taken me weeks.

The Uncertainty

AI and all of this related technology is reshaping the economy and work, and likely will continue to. We’re going to see huge changes over the coming years with what these agents are capable of, the automations they enable, and the way they integrate into our devices and daily work.

A lot depends on how smart these systems get, how fast they get there, and what we decide to give them access to. And by “them” I mean all of them, because there isn’t just one AI making these decisions. There are thousands of systems, developed by different companies, with different goals, being deployed in different contexts. The future isn’t one story. It’s a thousand stories playing out at once.

I’m more hopeful than anything, honestly. It’s just a matter of how things shake out, and how well (or how badly) the big tech companies, governments, and all of us handle what’s being built.

And who knows? We may not even have access to these tools in the same way a year from now. The costs, availability, and capabilities could shift completely. But for the time being, I’m really enjoying using what’s available to do better work.

Not this exact site, but something like it. A place to share what I’m working on, what I’m thinking about, and what I’ve learned along the way. I’ve started and stopped a few times over the years, but it never stuck. Life got busy, projects piled up, and the idea of maintaining a blog always fell to the bottom of the list.

So why now?

Honestly, a big part of it is that AI tools have made it easier to actually capture and share what I’m doing. Not in a “the robots write my posts” way, but in a “I can finally get my thoughts out of my head and onto a page without it feeling like a second job” way. The friction is lower. The barrier is smaller. And that’s been enough to tip the scales.

This blog will probably have a lot of AI-related content, because that’s what I’m currently obsessed with. But it won’t just be AI stuff. I have a lot of hobbies. I build things. I tinker. I’m a cybersecurity consultant by trade, but I’ve also got a film scanner I 3D-printed, a coffee roasting setup, home automation projects, and whatever else catches my attention.

The core concept here is using technology to improve my life, and then sharing what works (and what doesn’t). Sometimes that’ll be AI. Sometimes it’ll be a weird 3D printing project. Sometimes it’ll just be me rambling about something I find interesting.

Let’s see where this goes.

Hey, I’m Chris Cantey. 👋

I have a lot of hobbies. I build things. I tinker. These days I’ve got a film scanner I 3D-printed, a coffee roasting setup, home automation projects, and whatever else catches my attention. This site is where I share what I’m working on, what I’m thinking about, and what I’ve learned along the way.

I live in Southern California with Rudy, a wiener dog who comes with me everywhere, and Magnus, a 15-year-old cat who prefers the couch.

By trade, I’m a cybersecurity consultant. I run Wonders , where I help businesses simplify their tech and security. I also created Harder to Hack , a project focused on making personal cybersecurity accessible to everyone.

But really, I’m just someone who likes figuring out how things work and making them better.

If that sounds like your kind of thing, drop your email below.