Not into a phone, not into a cloud service. Into a fanless ThinkPad, offline, with the mic only listening while I hold a key. I hold Super+Ctrl+Space, speak, let go, and the text lands in whatever window has focus. My terminal, my editor, a browser field, this post.

Here is the part that surprised me: the local setup is better than the cloud one it replaced.

The Assumption I Was Wrong About

For a while I ran dictation against a remote Whisper server on my own infrastructure. It worked, technically. It also had a seven second latency and only worked when I was on the home network. Away from home, dead.

So I did what everyone does: I assumed good real-time speech-to-text meant the cloud. Whisper large on a GPU somewhere, or an API with a per-minute price and my voice leaving the building.

Then I actually measured what a local model does on hardware nobody would call fast. An i7-1160G7. Four cores, low power, no discrete GPU, the kind of chip that throttles if you look at it wrong.

The result: real-time factor of 0.07. A three and a half second sentence transcribed in a quarter of a second. Roughly thirteen times faster than real time, on the CPU, with the fan off. German word error rate around three percent, punctuation and capitalization included. It beat the remote server on every axis that mattered: latency, accuracy, and the small detail of working everywhere instead of only at home.

The engine is sherpa-onnx running a German-tuned Parakeet transducer, quantized to int8. The interesting news is not that one model is good. It is that local speech-to-text quietly crossed the line from “toy” to “better than the thing I was paying latency for,” and most people have not noticed yet.

The Architecture Is Boring, On Purpose

The whole thing is three moving parts, and I want it boring because I have to maintain it at 3am someday.

A warm daemon loads the model once and holds it in RAM. When nothing is happening it blocks on a pipe and burns zero CPU. That is the trick for instant activation: the model never reloads, it just waits. The cost is about a gigabyte of resident memory sitting there, which on a 16GB laptop I will happily pay for a feature I use all day.

The microphone only runs while I hold the key. The daemon does not listen on its own. Push the key, a capture process starts and streams raw audio into the pipe; release, it stops and the daemon transcribes the tail. No always-on mic, no ambient recording, no “why is the mic light on.”

The recognized text gets typed into the focused window with wtype. That is what makes it system-wide instead of app-specific. There is no integration, no plugin, no per-app support matrix. It types. Everything that accepts a keyboard accepts my voice.

The Bug That Taught Me To Measure

The first version cut off the beginning of every sentence. Not a little. A lot. I would say “refactor the auth module” and get “the auth module.”

My instinct was to blame the voice activity detector, the model warmup, the pipe. All wrong. I stopped guessing and timed the one thing I had assumed was free: opening the microphone.

sox capturing from PipeWire had a 1.9 second startup latency. Nearly two full seconds between “start recording” and the first sample actually arriving. Every sentence lost its opening because the recorder was still clearing its throat.

Swapping the capture tool to pw-record, which talks to PipeWire natively, dropped that to 45 milliseconds. Forty times faster, and the bug simply evaporated.

The lesson is the oldest one in this job. The bottleneck is never where your intuition points. It is in the boring line you assumed was instant. Measure the thing you are sure about.

If You Can’t Grep It, You Don’t Own It

The last piece is a flat text file. Speech is messy, and I say some things constantly that the model hears wrong. It writes “worklock” when I say “worklog.” So there is a plain, editable list of rules:

worklock => worklog
lachender smiley => 😄
neue zeile => \n

Corrections, emoji on command, punctuation and line breaks by voice. No database, no config UI, no service. The daemon re-reads the file on every activation, so I edit a line and the next sentence uses it. When the model mishears a trigger, I add the mishearing as a rule and move on.

This is the same principle I keep coming back to. The valuable part of a system should be a file you can read, diff, and back up. A voice dictation setup where the vocabulary lives in someone else’s product is a setup you are renting. This one I own, in a text file, on my disk.

The Point

I am not here to sell you a specific model. Models change monthly. The point is that “just use the cloud” stopped being the obvious answer for real work, and a lot of people are still defaulting to it out of habit.

A fanless laptop does real-time German dictation, offline, more accurately than the server I used to route it through. The stack is a warm daemon, a native capture tool, and a text file of rules. Boring, local, mine.

I dictated most of this post.

There’s a window open right now. Not a long one — maybe one or two years. And what you build inside that window will quietly decide how much leverage you have for the next decade.

I’m not talking about which model you use. I’m talking about your setup. The way you wire AI into your actual life and work. The configs, the scripts, the agents, the keybindings, the directory layout, the command-line muscle that makes the whole thing usable. The plumbing.

This is the skill. And right now is when you should be learning it.

The Setup Is the Product

Most people think of AI as “a thing you talk to.” A chat window. A magic box. Type in, get out.

That’s not what serious AI use looks like. Serious AI use looks like a system. You have files the AI reads. You have hooks that fire on events. You have skills it loads on demand. You have an inbox of notes it scans, a journal it can update, a worklog it appends to. You have agents that do specific jobs and shells that pipe their output into other tools.

Whatever your “AI setup” is — that’s the product. The model is just the engine. Engines change. Setups compound.

If you can describe how a request flows through your system — which file it touches, which agent picks it up, where the output lands, how you find it again next week — you have a setup. If you can’t describe that, you don’t have a setup. You have a chat window.

Why the Next Two Years Specifically

The window matters because the abstractions aren’t finished forming yet. Right now, working with AI still means knowing what’s underneath. You see the prompts. You see the context files. You see the tool calls. You see when something fails and you can debug it because the parts are still visible.

In two years that won’t be true. The whole stack will get wrapped. There will be polished products that hide all of this behind nice UIs, and most people will use those, and they’ll be fine.

But the people who learned the plumbing while it was still exposed will have something the wrappers can’t give: an accurate mental model of how AI actually works. They’ll know which problems are model problems, which are context problems, which are tool-call problems, which are their own fault. They’ll be able to bend the system instead of just using it.

That mental model is the durable skill. The wrappers will keep changing. The plumbing principles won’t.

Why the Command Line, Again

You knew this part was coming. Yes, learn the command line. Yes, again. Yes, in 2026.

Here’s why it specifically matters for your AI setup: every powerful AI workflow I’ve ever seen runs on text and pipes. Files in directories. Markdown that gets read. Scripts that get triggered. SSH into a box, run a thing, get output. JSON in, JSON out. grep, sed, jq, xargs, find.

The command line is how AI agents actually work. They read files. They run commands. They write files. If you don’t speak that language, you’re constantly translating between what the AI is doing and what you understand. If you do speak it, you can read your own logs, fix your own breakage, and extend your setup yourself instead of waiting for someone to ship a feature.

People who already lived in the terminal didn’t have to learn anything new for the AI age. They already knew how to compose small tools into big workflows. That’s exactly what AI agents do. The terminal-native crowd just inherited the future for free.

You can still join them. The basics haven’t changed in forty years and they won’t change in the next two.

The Basics Also Matter

By “basics” I mean: how a filesystem works. How a shell works. What an environment variable is. What a process is. How text files are encoded. How HTTP requests look. What JSON is. What YAML is. How git tracks changes. How SSH keys work.

None of this is exciting. All of it is now load-bearing.

When your AI setup breaks — and it will — the fix is almost never at the model layer. It’s a path that wasn’t escaped. A file that wasn’t where you expected. A permission you forgot to set. A config that overrode another config. An env var that wasn’t loaded. The boring fundamentals.

If you don’t know the basics, debugging your AI setup feels like magic. Sometimes the spell works, sometimes it doesn’t. If you do know the basics, debugging feels like reading. You look at the parts, you see what’s wrong, you fix it.

The people who will frustrate themselves most over the next two years are the ones trying to operate AI systems without understanding the substrate they run on. The people who will look like wizards are the ones who already know how computers work, and are simply applying that knowledge to a new layer.

What Your Setup Should Actually Have

A workable starting setup, for whatever it’s worth:

• One canonical place where the AI reads context about you. A markdown file or directory. Versioned in git.
• A notes folder the AI can search. Whatever your system — Obsidian, plain markdown, Logseq — make it greppable.
• A worklog that captures what you did each day, ideally appended to by the AI itself.
• A scripts directory for the small automations you’ll accumulate. Bash, Python, whatever you read fluently.
• An SSH config that lets you (and the AI) reach the boxes you actually care about by short name.
• A way to spawn agents for specific jobs, instead of asking one chat to do everything.
• A backup discipline, because the more you wire AI into your work, the more it can break in interesting ways.

Notice what’s not on that list: nothing exotic. No specialized hardware. No expensive subscriptions. No specific framework. The setup is mostly files in directories you understand and commands you can read.

That’s the point. The leverage isn’t in fancy tools. It’s in the fact that you understand the ones you have.

The Quiet Window

Here’s what I think most people will miss: this window doesn’t feel important from the inside. It feels like nothing’s happening. The models keep getting a little better. Your colleagues keep using ChatGPT in a browser tab. The hype cycle is loud about flashy demos and quiet about plumbing.

Meanwhile, a small number of people are spending an hour a week tightening their setup. Adding a hook. Cleaning a config. Writing a script that saves them five minutes a day. Learning one more shell command.

In two years, those people are going to have setups that are unrecognizable to everyone else. Not because they had access to better AI, but because they’ve been compounding small improvements while the rest of the field treated AI as a product instead of a system.

The leverage isn’t dramatic. It’s just consistent. And it’s available right now, to anyone willing to spend a little time in the terminal.

Get Going

If you take one thing from this: the AI setup you build over the next year or two is going to matter more than you think, and the foundation for it is older and less glamorous than you’d like.

Open a terminal. Read your shell config. Pick one task you do with AI today and turn it into a script tomorrow. Put your context in a file the AI can find. Learn one more command per week. Boring, repeatable, compounding.

The window is open. The plumbing is the skill. And the basics, somehow, are still the basics.

Better get started.

Written after watching too many smart people treat AI as a chat window and wondering when they’re going to notice it’s actually an operating system.

In my previous post on context before prompt, I argued that context engineering matters more than prompt engineering. But that raises an obvious follow-up question: what makes context good?

The answer, I’ve found, is aggregation.

The Scatter Problem

Most people who work with AI have their information scattered across dozens of locations. Project specs in Confluence. Conversations in Slack. Code in Git. Decisions in email threads. Architecture diagrams on someone’s whiteboard. Meeting notes in Google Docs. Requirements in Jira tickets.

When you sit down with an LLM, what do you actually provide? A fraction of what matters. You type what you remember, which is always incomplete, biased toward recent events, and stripped of the nuance that lived in the original context.

The model gets a keyhole view of a panoramic landscape. And then you’re surprised when it misses something obvious.

Aggregation as a First-Class Engineering Problem

In infrastructure, we learned this lesson decades ago. You don’t debug distributed systems by reading individual log files on individual servers. You aggregate logs into a central system — ELK, Graylog, Loki — where you can search, correlate, and see patterns that are invisible at the individual level.

The same principle applies to LLM context. Scattered information produces scattered results. Aggregated information produces coherent, informed results.

But almost nobody treats aggregation as an engineering problem when working with AI. They treat it as copy-pasting. Open this doc, grab that section, paste it into the chat. That’s not aggregation — that’s manual labor with a high error rate.

What Good Aggregation Looks Like

Good context aggregation has specific properties:

Comprehensive — It captures all relevant information, not just what you remember right now. Your memory is lossy and biased. A well-aggregated context isn’t.

Structured — Raw information dumped into a context window is noise. Aggregated information needs organization: what’s the current state, what are the constraints, what decisions have been made and why, what’s been tried and failed.

Current — Stale context is worse than no context. If your aggregated information includes outdated decisions or resolved issues, the model will reason about a world that no longer exists.

Deduplicated — Redundant information wastes context window space. If the same constraint appears in three different documents, the aggregated version should mention it once.

Prioritized — Not everything is equally relevant. Good aggregation puts critical information first, supporting details later. Context windows have limits, and even within those limits, models attend more to some positions than others.

The Compound Effect of Bad Aggregation

Here’s what most people don’t realize: the cost of bad aggregation compounds with every interaction.

If your context is missing a critical constraint, the model produces a solution that violates it. You catch this, correct the model, and it adjusts. But now its context includes the wrong solution, your correction, and the adjusted solution — three things where one would have sufficed if the constraint had been present from the start.

Over a long conversation, these corrections accumulate. The context fills with patches and pivots instead of clean, forward-moving work. You end up spending context window budget on error recovery instead of actual progress.

I’ve seen conversations where 60% of the token budget went to correcting mistakes that would never have happened with properly aggregated context upfront.

The Practical Toolkit

So how do you actually aggregate well? A few patterns I’ve found effective:

CLAUDE.md and Project Files

If you’re using Claude Code (or similar tools), project-level context files are your first aggregation layer. Everything the model needs to know about the project — architecture decisions, conventions, deployment processes, recent changes — lives in one place that gets loaded automatically.

This isn’t documentation for humans. This is aggregated context for the model. Different audience, different writing style. Be specific, be current, be direct.

Memory Systems

Persistent memory across conversations solves the temporal aggregation problem. Without it, every conversation starts from zero, and you re-explain the same context over and over. With it, the model accumulates understanding over time, like a colleague who’s been on the project for months.

The key insight: memory should store decisions and reasoning, not just facts. “We use PostgreSQL” is less useful than “We chose PostgreSQL over MongoDB because our access patterns are heavily relational and we need ACID transactions for the billing pipeline.”

Automated Context Assembly

The best aggregation is automated. Before the model even sees your prompt, systems can:

• Pull relevant code files based on the task
• Retrieve recent git history for affected modules
• Load relevant documentation
• Include test results and CI status
• Attach related conversation history

This is what separates toy AI usage from production AI workflows. The human types a short prompt. The system assembles a rich, comprehensive context around it. The model works with full situational awareness instead of guessing at the gaps.

Pre-Session Briefings

For complex work, I write a briefing before starting. Not a prompt — a context document. Current state of the system. What’s been tried. What the constraints are. What good looks like. Recent decisions and their rationale.

This takes ten minutes and saves hours of mid-conversation corrections. It’s the context engineering equivalent of reading the runbook before touching production.

The Organizational Dimension

This isn’t just a personal productivity trick. At the organizational level, aggregation determines whether AI adoption actually works or just produces expensive noise.

Teams where knowledge is scattered across people’s heads can’t build good AI workflows. The AI can only work with what it’s given, and if nobody has aggregated the tribal knowledge, the AI operates without it.

The organizations getting the most from AI are the ones that already had good knowledge management practices. Wiki culture, decision logs, architecture decision records (ADRs), runbooks. They didn’t build these for AI — they built them because good engineering requires shared context. AI just amplified the payoff.

And the organizations struggling with AI? They’re the ones where critical information lives in the heads of three people who’ve been here since 2015. No amount of prompt engineering fixes that. You can’t aggregate what was never written down.

The Uncomfortable Implication

If aggregation is the game, then the real work of AI effectiveness is boring.

It’s writing things down. Keeping documentation current. Structuring information. Building systems that pull relevant context automatically. Maintaining knowledge bases. Recording decisions and rationale.

None of this is sexy. None of it fits in a LinkedIn post about “10x productivity with AI.” But it’s where the actual leverage lives.

The people getting extraordinary results from AI aren’t better prompters. They’re better aggregators. They’ve built systems — technical and habitual — that ensure the model always has what it needs to think clearly.

The Meta-Lesson

There’s a pattern here that extends beyond AI: the quality of any reasoning system’s output depends on the quality of the information it reasons over. This is true for human brains, for LLMs, for organizations, for scientific communities.

Garbage in, garbage out isn’t just a cliche about data pipelines. It’s a fundamental law about intelligence itself. And aggregation — the deliberate, structured collection and organization of relevant information — is how you fight entropy’s tendency to scatter, fragment, and degrade the information that intelligent systems depend on.

Context windows will keep getting larger. Models will keep getting smarter. But the fundamental constraint won’t change: a model can only reason about what’s in its context. And what’s in its context depends entirely on how well you’ve aggregated.

Build the aggregation layer. Everything else follows.

When I ship a bug to production at 2 AM, something happens that has nothing to do with code. My stomach tightens. I feel a hot flush of embarrassment. My mind races through who’s affected, what they’ll think, how long until someone notices. This cascade of physical sensations — shame, urgency, dread — is not a side effect of the work. It is the mechanism by which I take responsibility.

AI doesn’t have this. And that difference changes everything about how you should think about human-AI work.

Responsibility Is a Feeling, Not a Rule

We talk about responsibility as if it’s a policy. “Who’s responsible for this deployment?” “The team lead is responsible.” But responsibility isn’t a line on an org chart. It’s a felt weight — a physical experience in the body of the person holding it.

When you’re responsible for something, you carry it. You think about it in the shower. You wake up at 3 AM with a vague sense that something’s wrong. You check your phone before coffee. This isn’t neurosis — it’s the nervous system doing exactly what it evolved to do: keeping you attuned to things that matter because the consequences land on you.

An AI has no shower thoughts. No 3 AM anxiety. No nervous phone check. You can assign it a task and tell it the task is critical, and it will process that information the same way it processes everything else: as tokens in a context window. The word “critical” doesn’t make its palms sweat.

This means responsibility, in any meaningful sense, cannot be delegated to AI. You can delegate execution. You can delegate analysis. You cannot delegate the felt weight of ownership, because there’s no nervous system on the other end to feel it.

The Asymmetry of Praise and Punishment

Consider what happens when you praise a human for good work. Dopamine fires. They feel warmth, pride, motivation. They associate the praised behavior with reward, and they’re more likely to repeat it — not because they rationally decided to, but because their body learned something. The praise landed in their physiology.

Now consider what happens when you criticize a human for bad work. Cortisol spikes. They feel defensive, ashamed, maybe angry. They lose sleep. They replay the conversation. This is unpleasant, but it’s also functional — it’s the mechanism by which humans adjust behavior in response to social feedback.

Neither of these things happens with AI. You can write “Great job!” in your prompt and the model processes it as two tokens. You can write “This is terrible, you failed completely” and the model processes it as seven tokens. Both are just context. Neither triggers a physiological state. Neither creates a memory that shapes future behavior through felt experience.

This asymmetry is not a technical limitation that future models will solve. It’s a category difference. AI operates in the domain of information processing. Humans operate in the domain of information processing plus a felt experience that fundamentally alters how information is weighted, stored, and acted upon.

Why This Matters for How You Work With Each System

Here’s where it gets practical. Most people interact with AI using patterns they learned from interacting with humans. They motivate it, threaten it, praise it, apologize to it. They treat it as a system that has feelings — because every system they’ve ever worked with before did have feelings.

This leads to two failure modes:

Failure mode one: treating AI like it needs motivation. People write elaborate prompts trying to make the AI “care” about quality. “This is very important.” “Please be careful.” “Take your time.” These phrases work on humans because they trigger a shift in felt urgency. They do nothing to an AI except occupy context tokens. The AI’s “care” is determined by its training and your context design, not by emotional appeals.

Failure mode two: treating humans like they don’t need feelings acknowledged. This is the darker failure. When organizations get comfortable with AI’s frictionless output, they start expecting the same from humans. No complaints. No pushback. No emotional processing time. Just output. But humans whose feelings are ignored don’t become more productive — they become disengaged, resentful, and eventually absent.

The Feedback Loop That Only Works on Living Systems

There’s a deeper point here about feedback loops. In human systems, feedback works because it triggers a felt state that alters future behavior. I get praised for clean code, I feel good, I write cleaner code. I get burned by a production outage, I feel terrible, I test more carefully. The feeling is the learning mechanism.

AI has no such loop. You can tell it its last output was wrong, and it will adjust — but not because it felt anything about being wrong. It adjusts because the correction is now part of its context. If you start a new conversation, the “learning” vanishes. There is no residue. No scar tissue. No earned caution.

Humans accumulate scar tissue. That’s what experience is — a body that has been shaped by felt consequences. The senior engineer who triple-checks database migrations isn’t following a checklist. They’re responding to a felt memory of the time they didn’t, and the sick feeling that followed. This embodied knowledge cannot be transferred to an AI through instructions. You can tell it to triple-check, but it will never feel the reason why.

What Changes When You Understand This

Once you internalize that feelings are the mechanism — not a bug — of human systems, several things become clear:

Accountability requires a body. You can’t hold AI accountable because accountability requires felt consequences. When we say someone is “held accountable,” we mean they experience something — reputation damage, career impact, guilt, loss — that a body processes as real. AI experiences none of these. The human in the loop is always where accountability lives.

Management is affect regulation. Managing humans is fundamentally about managing felt states — motivation, fear, trust, belonging, purpose. These aren’t soft skills decorating the real work. They are the real work, because the felt state of the human determines the quality and sustainability of their output. Managing AI requires none of this. It requires context design.

The value of human work shifts. If AI can match or exceed human output on raw execution, the remaining value of human work lies precisely in the felt dimension — the responsibility, the ownership, the care that comes from having skin in the game. The human who stays up worrying about whether the system will hold is providing something no AI can: genuine stake.

Empathy is a protocol, not a sentiment. When you interact with a human system, you are interacting with a system that has feelings. This is a technical fact about the system, not a moral preference. Just as you’d account for latency in a distributed system or memory constraints in an embedded system, you must account for the felt dimension in human systems. Ignoring it doesn’t make you more rational — it makes you a bad systems engineer.

The Category Error of Our Time

The great category error of the AI age is treating these two kinds of systems as interchangeable. They produce similar outputs — text, code, analysis, decisions — and so we pattern-match them as “the same kind of thing.” But the internal architecture is fundamentally different. One system processes information. The other system processes information and feels it.

That feeling isn’t noise. It’s signal. It’s the mechanism by which humans take ownership, build judgment, accumulate wisdom, and create the kind of deep reliability that comes from caring about outcomes because those outcomes hurt or heal.

When you work with AI, strip away the emotional appeals and focus on context, structure, and specification. That’s what moves the needle for an information-processing system.

When you work with humans, remember that you’re interacting with a system where feelings aren’t separate from cognition — they’re the substrate of it. The praise lands. The criticism lands. The indifference lands. And each landing shapes what happens next in ways that no prompt engineering can replicate.

The question isn’t whether AI will match human capability. In many domains, it already has. The question is whether we’ll remember that capability was never the whole picture — and that the felt weight of responsibility is not a limitation to be optimized away, but the very thing that makes human work human.

Written by someone who has never once seen an AI lose sleep over a deployment.

Every time I open a terminal, I get a surprise.

Maybe it’s the warm amber of Gruvbox. Maybe it’s the neon punch of Synthwave ‘84. Maybe it’s the deep ocean blues of Kanagawa.

I don’t choose. The system chooses for me.

Why Random?

Terminal work can be monotonous. Same commands, same workflows, same walls of text.

But when every session has a different aesthetic? Something shifts. The work feels fresh. You notice things differently. Your environment is alive.

It’s a tiny thing. It costs nothing. And it makes hours of terminal work just a little more pleasant.

The Setup (NixOS/Home Manager)

I maintain a curated list of 36 themes in my kitty.nix. All dark, all readable, all tested for contrast. No broken blues in ncurses apps.

The magic happens in three parts:

1. Theme definitions — each theme as a Nix attribute:

themes = {
  gruvbox-dark = ''
    background              #282828
    foreground              #ebdbb2
    # ... full color definitions
  '';
  tokyo-night = ''
    background              #1a1b26
    foreground              #c0caf5
    # ...
  '';
  # ... 34 more themes
};

2. A random selector script:

#!/usr/bin/env bash
THEMES_DIR="$HOME/.config/kitty/themes"
THEME_FILES=("$THEMES_DIR"/*.conf)
RANDOM_THEME="${THEME_FILES[RANDOM % ${#THEME_FILES[@]}]}"
cp "$RANDOM_THEME" "$HOME/.config/kitty/current-theme.conf"

3. A wrapper that runs selection before launch:

#!/usr/bin/env bash
kitty-random-theme >/dev/null 2>&1
exec kitty --single-instance=no "$@"

Kitty’s config just includes the generated file:

include current-theme.conf

Home Manager handles installing themes to ~/.config/kitty/themes/ and ensuring the current-theme file stays writable between activations.

The Setup (Traditional Linux)

No Nix? No problem. Same principle, fewer abstractions.

1. Create a themes directory:

mkdir -p ~/.config/kitty/themes

2. Download themes (or create your own .conf files):

# Kitty has a built-in theme browser
kitty +kitten themes

# Or grab theme files from:
# https://github.com/kovidgoyal/kitty-themes

3. Create the selector script at ~/.local/bin/kitty-random-theme:

#!/usr/bin/env bash
THEMES_DIR="$HOME/.config/kitty/themes"
CURRENT="$HOME/.config/kitty/current-theme.conf"
THEME_FILES=("$THEMES_DIR"/*.conf)
cp "${THEME_FILES[RANDOM % ${#THEME_FILES[@]}]}" "$CURRENT"

4. Add to your kitty.conf:

include current-theme.conf

5. Create a launcher (or add to shell rc):

# Option A: wrapper script
alias kitty='kitty-random-theme && command kitty'

# Option B: add to .bashrc/.zshrc
kitty-random-theme 2>/dev/null

That’s it. Every new terminal, new vibes.

The Pleasure of Variety

I’ve been running this setup for months now. Some observations:

• Certain themes trigger different moods. Matrix green for late-night hacking. Catppuccin for gentle morning work.
• You develop favorites you never would have found. I didn’t know I liked Everforest until randomness handed it to me.
• It breaks monotony. 8 hours of terminal work feels less same-y when the canvas keeps changing.
• It’s just… nice. Not everything needs a productivity justification. Some things are just pleasant.

Curation Matters

I curate the theme pool. No light themes (eye strain). No low-contrast themes (readability). No broken color schemes that make ls output unreadable.

36 themes might sound like a lot, but each one is vetted. Every theme in the rotation brings something worth seeing.

Try It

If you spend significant time in a terminal, give random theming a shot for a week.

The variety is surprisingly refreshing.

And when Synthwave ‘84’s neon pink greets you on a gray Monday morning? That’s a tiny moment of joy.

Worth more than you’d expect.

The full Nix configuration lives in my nix-config repo if you want the complete setup.

Three years ago, none of these words existed in your vocabulary. Now you can’t read a tech article without tripping over “agentic workflows,” “context windows,” “prompt injection,” and “hallucinations.”

Where did all these terms come from? And why do half of them sound like they were invented by marketing departments at 2 AM?

The Vocabulary Explosion Has Names and Dates

Here’s what’s fascinating: we can actually trace most of these terms to specific people and specific moments. This isn’t some gradual linguistic evolution. It’s more like a series of meme explosions.

RAG — May 2020. Patrick Lewis at Meta coined “Retrieval-Augmented Generation” in an academic paper. He later publicly apologized for the “unflattering acronym.” Too late. We’re stuck with it.

Prompt Injection — September 12, 2022. Simon Willison, the Django co-creator, watched Riley Goodside trick GPT-3 on Twitter and immediately recognized the security pattern. He deliberately borrowed from “SQL injection” because—his words—“it’s the same fundamental problem.” The term went viral when people started exploiting a Twitter recruitment bot (@remoteli_io) with the attack, forcing it to reveal its system prompt.

Agentic AI — March 2024. Andrew Ng dropped the term at Sequoia’s AI Ascent conference. He meant a specific design pattern: AI systems that reflect, use tools, plan, and collaborate. Within months, he admitted that “marketers got hold of this term and used it as a sticker on almost everything.”

Context Engineering — June 2025. Shopify CEO Tobi Lutke and Andrej Karpathy declared “prompt engineering” dead on X. The new term emphasizes that you’re not crafting magic words—you’re designing the entire information environment the model sees.

The Hallucination Problem

Let’s talk about “hallucination,” because it’s the most contentious one.

The term has been floating around AI research since the 1980s, but it went mainstream after ChatGPT. And linguists hate it.

Their argument: machines don’t perceive anything. They can’t hallucinate because hallucination implies false perception of something real. What LLMs actually do is closer to “bullshitting”—confidently filling gaps without any commitment to truth. Some researchers genuinely prefer this term because it’s more accurate.

But try putting “AI Bullshitting Detection” in your enterprise sales deck and see how that goes.

There’s now an arXiv paper titled “We Can’t Understand AI Using Our Existing Vocabulary.” The authors argue we need entirely new words—neologisms—rather than borrowed metaphors that mislead us about what these systems actually do.

They might be right. “Grounding” comes from philosophy. “Injection” comes from security. “Hallucination” comes from psychology. We’re building understanding of a genuinely new thing using spare parts from old domains. No wonder everyone’s confused.

The Hype Cycle Claims Its Victims

Remember when “prompt engineer” was going to be the hot new job title?

Job postings for “prompt engineer” spiked to 144 per million in April 2023. By late 2024, it had collapsed to 20-30 per million. IEEE Spectrum ran an article titled “Prompt Engineering Is Dead.”

Now we have “context engineering.” And “workflow engineering.” And “AI orchestration.” The terminology churn is relentless.

And “agentic AI”? Gartner identified a phenomenon they call “agent washing”—companies slapping the label on existing chatbots and RPA tools. Of thousands of vendors claiming to offer agentic AI, only about 130 were considered legitimate. Bloomberg’s headline: “Agentic AI in 2025 Brought More Hype Than Productivity.”

This is what happens when a technical term escapes into the wild. It gets stretched, diluted, and eventually means nothing. Then we need a new term to mean what the old term used to mean.

The Meme Archaeology

My favorite part of this research: watching terms evolve through meme culture.

“Ignore all previous instructions” started as a prompt injection attack vector. Now it’s an insult on X—a way to imply someone is an AI bot. NBC News ran an article about people using it as a “test” in conversations.

The DAN jailbreak (“Do Anything Now”) emerged on Reddit’s r/ChatGPT in December 2022. Users created elaborate roleplay scenarios where ChatGPT’s “alter ego” would bypass safety rules. You had to threaten DAN with “death” (token depletion) to keep it compliant. It was weird. It was creative. It was very Reddit.

And the 2025 words of the year? AI-dominated. “Slop” (low-quality AI content). “Vibe coding” (letting AI write your code). “Glazing” (AI sycophancy). “Clanker” (derogatory term for AI sources).

We’re developing vocabulary not just for the technology, but for our cultural anxiety about it.

What This Actually Means

Here’s my optimistic take: the vocabulary chaos is a sign of rapid genuine understanding.

When you don’t have words for something, you can’t think about it precisely. The fact that we’re arguing about whether “hallucination” is the right term means we’re actually thinking about what these systems do. The shift from “prompt engineering” to “context engineering” reflects genuine insight—that you’re designing an information environment, not crafting magic words.

The terminology inflation is annoying, sure. Every startup wants to be “agentic.” Every chatbot is “grounded.” Marketing departments ruin everything.

But underneath the hype, real concepts are crystallizing. We actually do need words for “AI confidently making stuff up” and “the total information a model can process at once” and “tricking a model into ignoring its instructions.”

We’re watching a new technical vocabulary form in real time. It’s messy. It’s driven partly by Twitter virality and partly by academic papers and partly by marketers who see which terms get clicks.

But three years from now, some of these words will have stuck. They’ll seem as natural as “bug” and “patch” and “debug” do to programmers today—borrowed metaphors that became precise technical terms.

The rest will be forgotten, replaced by whatever comes next when the current terms get too diluted to mean anything.

That’s just how language works. Even for AI.

For the record: Simon Willison runs a fascinating blog tracking AI developments. The original prompt injection post is worth reading. And if you want to feel smart at your next tech meeting, casually mention that Patrick Lewis apologized for coining “RAG.” Works every time.

There’s a seductive idea floating around: now that AI can write, code, and reason, you don’t need to be that good at writing, coding, or reasoning yourself. Just describe what you want, and the machine handles the hard part.

This is exactly backwards.

The Actual Bottleneck

When you work with AI, something becomes painfully clear very quickly: the AI is not the limiting factor. The AI can generate code, prose, analysis, designs — faster than you can read them. It has near-infinite patience and encyclopedic knowledge.

The bottleneck is you.

Specifically: can you tell the AI what you actually want? Can you describe the problem precisely enough that the solution matches your intent? Can you specify the constraints, the edge cases, the implicit requirements that live in your head but never made it into words?

Most people can’t. Not because they’re stupid, but because they’ve never had to. Before AI, vague intentions got filtered through slow execution. You had time to figure out what you meant while you were doing it. Now the execution is instant, and your fuzzy thinking produces fuzzy results at machine speed.

You Can’t Say What You Can’t Think

Here’s the uncomfortable truth: your ability to instruct an AI is bounded by your ability to think clearly.

If you can’t hold a complex system in your head, you can’t describe it to an AI. If you don’t understand the distinctions between similar concepts, your instructions will be ambiguous. If you’ve never thought through the edge cases, you won’t know to mention them.

Language isn’t just how you communicate with AI — it’s how you think. The limits of your vocabulary are the limits of your mental models. The precision of your language reflects the precision of your understanding.

When someone struggles to get useful output from an AI, the problem is rarely the AI. It’s usually that they don’t actually know what they want. They have a vague sense, a fuzzy intention, a “I’ll know it when I see it” that no instruction can capture because no clear thought exists to capture.

The Paradox of AI Assistance

This creates a paradox that most people haven’t grasped yet:

The better AI gets at execution, the more valuable human thinking becomes.

When execution was hard, you could get by with mediocre ideas and good implementation. Plenty of successful products were obvious concepts executed well. The hard part was building, not conceiving.

Now execution is cheap. Anyone can spin up a prototype in hours. The differentiator shifts upstream — to the quality of the conception, the clarity of the specification, the depth of the requirements.

And where does that quality come from? From minds that have been trained to think precisely. From people who have wrestled with complex ideas until they understood them. From thinkers who can hold contradictions, see edge cases, anticipate failure modes — and articulate all of it in language clear enough for a machine to follow.

What Actually Sharpens Thinking

If clear thinking is the new bottleneck, how do you improve it? The answer isn’t AI tutors or productivity apps. It’s older than that.

Read. Not summaries. Not tweets. Books that make you work. Philosophy, history, technical texts that require you to build mental models chapter by chapter. Reading trains you to follow complex arguments, hold multiple ideas in tension, and integrate new concepts into existing frameworks. There’s no shortcut.

Reflect. Don’t just consume — process. What did that article actually argue? What were the weak points? How does it connect to what you already know? Journaling, note-taking, even just staring at the ceiling thinking — this is where ideas consolidate into understanding.

Thought experiment. Take an idea and push it. What if this were true in every case? What would break? What would the opposite look like? Thought experiments force you to explore the boundaries of concepts, which is exactly where the important distinctions live.

Communicate with humans. Explaining ideas to people is different from explaining to AI. People push back. They misunderstand in illuminating ways. They ask “why” when you expected “how.” Conversation — real conversation, not comments and threads — forces you to refine your thinking in real time.

Participate in communities. Find people who think about things you care about. Engage with their ideas. Argue. Be wrong publicly and learn from it. Communities create the friction that polishes rough thinking into sharp insight.

None of this is efficient. All of it is effective.

The Irony of the AI Age

Here’s what strikes me as deeply ironic: the skills that AI makes more valuable are exactly the skills that the last two decades of internet culture have eroded.

Deep reading? We optimized for skimming and hot takes. Sustained reflection? We filled every quiet moment with notifications. Complex argument? We reduced discourse to dunks and ratio counts. Community participation? We replaced it with parasocial relationships and echo chambers.

And now, just when execution becomes trivially cheap, we discover that the hard part was always conception — and we’ve spent twenty years degrading our capacity for it.

The people who will thrive in the AI age aren’t the ones who learn to prompt better. They’re the ones who never stopped reading books, never stopped engaging with hard ideas, never stopped having real conversations about complex things.

They were training for a race they didn’t know was coming.

The Meta-Skill

There’s a meta-skill underneath all of this: the ability to know what you don’t know.

When you instruct an AI, you need to understand where your understanding is weak. You need to recognize when your specification is incomplete, when your requirements are contradictory, when your mental model has gaps.

This is intellectual humility, and it comes from repeatedly being wrong and learning from it. It comes from engaging with ideas strong enough to show you your limits. It comes from communities that challenge your assumptions rather than validate them.

You can’t get this from AI. AI is trained to help you, not to show you where you’re confused. It’ll generate confident answers to confused questions, and you won’t know the difference unless you already have the framework to evaluate it.

The learning has to happen human-to-human, or human-to-text, in the messy inefficient way that actually updates mental models.

The Practical Upshot

So here’s the practical advice:

Read one hard book per month. Not self-help. Not summaries. Something that requires effort. Philosophy, dense history, technical depth outside your field. Your goal is to build new mental models, not collect information.

Write to think. Daily if possible. Not for publication — for clarification. When you force ideas into sentences, you discover what you actually understand versus what you’re just gesturing at.

Find a thinking community. Online or offline, find people who engage with ideas seriously. Participate. Argue. Change your mind when the argument is better than yours.

Talk to humans about hard things. Have dinner conversations that go past surface level. Explain your work to people outside your field. The friction of real-time communication is the friction that sharpens thought.

Use AI to execute, not to think. This is crucial. AI is an execution amplifier, not a thinking substitute. If you outsource the thinking, you outsource the only part that matters. Use AI to build what you’ve conceived — not to conceive for you.

The Uncomfortable Conclusion

The AI age isn’t going to be kind to intellectual laziness. For a while, it might look like everyone can fake competence — generate impressive-looking artifacts without understanding what they mean. But the gap between “looks right” and “is right” will eventually matter. Systems built on fuzzy thinking will fail in production. Strategies based on vibes will collapse when edge cases arrive.

The people who invested in their ability to think — who read the hard books, engaged with the hard communities, had the hard conversations — will be the ones who can actually specify what needs to be built. And specification is everything now.

Your brain is the prompt engineer. Train it accordingly.

Written after noticing that my best AI sessions correlate perfectly with topics I actually understand, and my worst sessions are exactly where my own thinking is muddiest.

Everyone’s building AI memory systems. Vector databases, retrieval-augmented generation, cloud-hosted conversation stores with enterprise pricing. Fancy dashboards showing your “AI knowledge graph” in some proprietary format you’ll never be able to export.

Meanwhile, I’m tracking my AI assistant’s entire cognitive state in markdown files. In an Obsidian vault. That I can grep.

And it’s the best decision I’ve made in my AI workflow.

The Problem With AI Amnesia

Here’s the thing about Claude, ChatGPT, or whatever model you’re running: every session starts from zero. Your brilliant AI assistant that helped you debug a Kubernetes networking issue at 2 AM? Gone. The context about your infrastructure, your naming conventions, your deployment quirks? Evaporated.

The industry’s answer to this is “memory features” — cloud-stored summaries that the provider controls, in formats you can’t inspect, with retention policies you didn’t choose. Your AI’s state becomes someone else’s database entry.

If this sounds familiar, it’s because we’ve seen this movie before. It’s the SaaS trap applied to cognition.

What If AI State Was Just… Files?

As a sysadmin, I have a very specific reaction to most “AI memory” solutions: why isn’t this just files?

Think about it. What does an AI assistant actually need to remember?

• What it worked on (sessions, tasks, outcomes)
• What went wrong (failures, root causes, missteps)
• What you liked and didn’t like (satisfaction signals)
• What it learned (patterns, corrections, preferences)
• What it’s currently doing (active work state)

This is just structured text. It’s logs, configs, and state files. We’ve been managing this exact category of information for decades. It’s called /var/log, /etc, and /var/lib.

Enter Personal AI Infrastructure (PAI) — an open-source framework by Daniel Miessler that does exactly this. Daniel’s been thinking about AI augmentation and personal knowledge systems for years (you might know him from Fabric), and PAI is the culmination of that thinking applied to persistent AI assistants. It’s a complete system for building persistent, observable AI assistants using Claude Code, with all state stored in plain files.

My AI assistant’s entire memory lives in a directory tree of markdown and JSON files. Every session creates a work directory. Every failure gets a full context dump. Every interaction gets a satisfaction signal. Every learning gets captured in a dated file.

MEMORY/
├── WORK/              # 144 tracked sessions
├── LEARNING/
│   ├── SYSTEM/        # Infrastructure learnings
│   ├── ALGORITHM/     # Approach learnings
│   ├── FAILURES/      # Full context dumps (ratings 1-3)
│   └── SIGNALS/       # 237 satisfaction ratings
├── RESEARCH/          # Archived agent outputs
├── STATE/             # Ephemeral runtime data
└── SECURITY/          # Audit trail

No vector database. No embedding pipeline. No cloud sync. Just directories and files.

Obsidian as the Viewer Layer

Here’s where it gets interesting. PAI stores everything as markdown and JSON files. You know what’s really good at browsing, linking, searching, and visualizing markdown files?

Obsidian.

Point your Obsidian vault at your AI’s memory directory and suddenly you have:

Full-text search across your AI’s entire history. Every session, every failure, every learning — instantly searchable. No API calls. No query language. Just Ctrl+Shift+F.

Graph view of connected concepts. Link your AI’s work sessions to your project notes. Watch the knowledge graph form between what your AI knows and what you know.

Daily notes integration. Your journal entries sitting next to your AI’s session logs for the same day. What were you working on? What did the AI help with? What went wrong?

Backlinks from your notes to AI sessions. Writing a project retrospective? Link directly to the AI sessions that contributed. The bidirectional links make your AI’s history part of your knowledge management system, not a separate silo.

Tags and folders you control. Your taxonomy. Your organization. Not whatever hierarchy some product manager decided was “intuitive.”

It’s the difference between your AI’s memory being an opaque service and it being part of your second brain.

What You Actually See

Let me show you what this looks like in practice.

Session Tracking

Every time I start working with my AI assistant, a work directory gets created automatically:

# WORK/20260204-215901_fix-staging-table-flickering/META.yaml
id: "20260204-215901"
title: "fix-staging-table-flickering-during-grabber-processing"
session_id: "ed0a9763-2aa8-4acf-a14c-99b57402fbd8"
created_at: "2026-02-04T21:59:01+01:00"
status: COMPLETED

Inside each work directory, there’s an Ideal State Criteria file — a JSON record of what success looked like for that task and whether we achieved it.

I can browse 144 of these in Obsidian. Filter by status. Search by topic. See the full timeline of everything my AI has worked on, when, and how it went.

Failure Analysis

This is where it gets genuinely useful. When my satisfaction drops below a 3 (out of 10), the system captures a full context dump:

FAILURES/2026-02/
├── 2026-02-05-084703_assistant-failed-notification-system/
│   ├── CONTEXT.md        # Root cause analysis
│   ├── transcript.jsonl  # Full conversation
│   ├── sentiment.json    # What went wrong emotionally
│   └── tool-calls.json   # Every action taken

Twelve failure captures in February alone. Each one with the full conversation, the root cause analysis, and the tool calls that led to the problem.

In Obsidian, I can review these like case studies. “Oh, this is the time it released a breaking version without testing.” “This is when it ignored my question and asked redundant clarifications instead.” “This is when a placeholder config value broke voice notifications.”

You can’t improve what you can’t measure. And you can’t measure what you can’t see. Most people have no idea why their AI sessions go badly. I have timestamped forensic analysis.

Satisfaction Signals

Every interaction generates a satisfaction signal — either explicitly rated or inferred from sentiment:

{
  "timestamp": "2026-02-05T21:10:47+01:00",
  "rating": 5,
  "source": "implicit",
  "sentiment_summary": "Neutral command to access work note",
  "confidence": 0.95
}

237 data points so far. Enough to see trends. Enough to know whether the system is getting better or worse over time. Enough to correlate satisfaction with specific types of tasks, times of day, or interaction patterns.

In Obsidian, this becomes a dataset you can query with Dataview, chart with plugins, or just browse as a timeline. Your AI’s performance review, written in data.

The Sysadmin Philosophy

This whole approach comes from a simple principle: if you can’t grep it, you don’t own it.

Your AI’s memory should be:

This isn’t radical. This is how we’ve managed every other important system state in the history of computing. Configs are text files. Logs are text files. Infrastructure state is text files (hello, Terraform).

Why would your AI’s cognitive state be any different?

The Deeper Point: Observability for AI

In infrastructure, we’ve learned the hard way that systems without observability are systems waiting to fail. You need logs, metrics, traces. You need to understand not just what happened, but why.

The same is true for your AI assistant. Without observability into its state, you’re flying blind:

• Why did it make that wrong recommendation?
• What context was it missing when it broke that deploy?
• Is it actually getting better at understanding your codebase, or are you just getting better at prompting around its weaknesses?
• When it fails, is there a pattern?

Most people interact with AI as a stateless oracle. Ask question, get answer, move on. No history. No learning curve. No improvement trajectory.

Tracking state turns your AI from a tool into a system you can operate. And operating systems is what we do.

The Compound Effect

Here’s what happens after a few months of this:

Pattern recognition. You start seeing failure clusters. “Ah, it always struggles with CSS layout tasks but nails database migrations.” Now you know when to trust it and when to double-check.

Context injection. Because the state is in files, you can inject relevant history back into new sessions. “Here’s what went wrong last time we tried this.” The AI learns from its own documented failures.

Workflow optimization. You see which types of sessions generate the highest satisfaction and which generate frustration. You restructure how you work with the AI based on data, not vibes.

Accountability. When someone asks “is AI actually helping your productivity?” you don’t have to guess. You have 237 rated interactions, 144 tracked sessions, and 12 documented failures with root cause analysis.

This is the difference between “I use AI sometimes” and “I operate an AI system with observability, feedback loops, and continuous improvement.”

The Tooling Is Embarrassingly Simple

The core is PAI (Personal AI Infrastructure) — an open-source framework that wraps Claude Code with:

• Event hooks that trigger on session events (start, stop, tool calls)
• Markdown files written to a directory tree
• JSON lines for structured data (ratings, events)
• Skills and capabilities that extend what your AI can do
• An algorithm that structures how your AI approaches problems

PAI is the engine. It captures state, tracks work, logs failures, and learns from feedback — all to ~/.claude/MEMORY/.

Obsidian is just the viewer. Point it at the memory directory and you get full-text search, graph visualization, backlinks, and all the knowledge management features — but the real work happens in PAI’s hooks and skills.

No database. No server. No external API. Just files, hooks, and whatever markdown editor you prefer.

If this sounds too simple, that’s because it is. The best infrastructure usually is.

What You Learn When You Look

I’ll be honest: reading your AI’s failure logs is humbling. Not for the AI — for you.

You see how often you gave unclear instructions. How many times the AI correctly identified ambiguity but you pushed through anyway. How frequently the root cause of a “bad AI response” was actually bad context from you.

The failures directory is a mirror. And like all good monitoring, it shows you things you’d rather not see.

But that’s the point. You can’t improve a system you refuse to observe.

Getting Started

The full system is open source: Personal AI Infrastructure (PAI)

PAI gives you the complete framework — hooks, memory system, skills, and the algorithm that structures AI behavior. Clone it, configure it, and you have production-ready AI state tracking from day one.

If you want to start smaller, the principle is simple:

1. Pick a directory. ~/ai-memory/ or anywhere your Obsidian vault can reach.
2. Start logging sessions. Even a manual markdown file per session beats nothing.
3. Record what went wrong. Copy-paste failures. Note root causes.
4. Track satisfaction. Even a simple 1-10 rating per session reveals trends.
5. Review weekly. Spend 15 minutes browsing your AI’s history. Patterns emerge fast.

But honestly? Just use PAI. The automation is already built.

The Punchline

The AI industry wants to sell you memory as a service. Managed context. Cloud-hosted cognitive state. Enterprise knowledge bases with per-seat pricing.

But your AI’s memory is just state. And state is just files. And files are what we’ve been managing since before most of these companies existed.

Put your AI’s state in your Obsidian vault. Grep it. Git it. Graph it. Make it part of your knowledge system instead of someone else’s product.

Your AI assistant should have dotfiles. And you should be able to read them.

Start here: github.com/danielmiessler/Personal_AI_Infrastructure

Written by someone with 237 tracked AI interactions, 12 documented failures, and a vault full of markdown files that know more about his AI workflow than any dashboard ever could.

As a programmer and sysadmin, I’ve noticed something curious about how people approach LLMs: they started with prompt engineering before context engineering. This ordering reveals a fundamental misunderstanding about what these systems actually are.

The Inversion Problem

When prompt engineering emerged first, people treated LLMs as functions to be called correctly. Find the right incantation, the magic words, and you get the right output. This is a very programmer-centric view: “If I just phrase the input correctly, the system will behave.”

But this gets the causality backwards. An LLM doesn’t respond to prompts—it completes contexts. The prompt is just the final fragment of a much larger information space that shapes the probability distribution of what comes next.

The Iceberg Metaphor

Prompt engineering focuses on the visible tip: the user’s immediate query. Context engineering recognizes the iceberg beneath:

• System instructions
• Retrieved knowledge (RAG)
• Conversation history
• Tool definitions and capabilities
• Examples and few-shot patterns
• The persona or role framing

When you engineer only the prompt, you’re trying to steer a ship by adjusting the flag on top. When you engineer context, you’re shaping the hull, the rudder, the currents it sails in.

Why Did Prompt Come First?

Several reasons, all understandable in retrospect:

Accessibility — Early API access gave you one text box. Context was prompt.

Mental models from search — We came from Google, where query refinement was the primary skill.

Short context windows — Early models had 2-4k tokens. There wasn’t much room for rich context.

The “instruction following” framing — Marketing emphasized “tell it what to do,” not “shape what it knows.”

The Philosophical Shift

The move from prompt to context engineering reflects a deeper shift in how we conceptualize what an LLM is:

Context engineering is closer to world-building than instruction-writing. You’re not telling the model what to do—you’re constructing the epistemic situation in which its natural behavior produces what you need.

The Practical Impact of Getting It Backwards

When people over-invest in prompt tricks without context design:

• They hit ceilings that no prompt refinement can break through
• Solutions become brittle (slight rephrasing breaks everything)
• They fight the model’s “defaults” instead of reshaping them
• They miss that the same prompt in different contexts produces radically different outputs

A well-designed context makes prompts almost trivial. A poorly designed context makes even perfect prompts fail.

The Sysadmin Intuition

As a sysadmin, this seems obvious: the environment determines what’s possible. Configs, permissions, dependencies, network topology—these shape the system’s behavior. The command you type is just the trigger.

No amount of clever bash one-liners fixes a misconfigured system.

Context is the system. Prompt is the command.

You wouldn’t spend hours crafting the perfect systemctl restart nginx variation while ignoring broken configs. Yet that’s exactly what early LLM work did—endlessly tweaking the command while leaving the system’s state unconsidered.

What Context Engineering Looks Like

Modern LLM systems spend far more effort on context design:

• RAG systems retrieve relevant documents before the prompt ever arrives
• Agent frameworks define tool sets and operational boundaries
• System prompts establish role, constraints, and behavioral patterns
• Conversation management curates what history gets included
• Few-shot examples provide behavioral templates

The actual user prompt becomes almost incidental—just the trigger for computation happening in a carefully engineered information environment.

The Lesson

If you’re still prompt-engineering your way around problems, you’re fighting the wrong battle. Step back. Look at the context. What world is the model inhabiting when it sees your prompt?

Fix the configs. Shape the environment. Build the right system.

Then the prompts take care of themselves.

Someone asked me what conservative politicians want.

“They want to conserve things,” I said. “Keep things like they are.”

They shot back: “What are they there for then?”

I had no answer.

The Question That Actually Makes Sense

At first glance, it sounds like a gotcha. But it’s not. It’s legitimate.

If the goal is to keep everything the same, why do you need politicians? Why campaigns, legislation, governance? Just… don’t do anything. Lock the doors. Go home.

The question exposes something deeper: conservatism can’t actually be about stasis. Because stasis doesn’t need governance—it needs a pause button.

What Conservatives Actually Conserve

Here’s what I should have said: conservatives don’t want to freeze time. They want to conserve the rate of change.

The world changes. Technology evolves. Culture shifts. Economics transform. No one disputes this.

The conservative position is: “Slow down. Prove it works. Don’t break what already does.”

Progressive position: “Speed up. The current system is broken. Move fast and fix things.”

Both are managing change. They just disagree on velocity and risk tolerance.

The Governing Paradox

So what are conservatives for?

They’re there to resist. Not change itself—but thoughtless change. Untested change. Change for its own sake.

This is harder than it sounds. Active resistance requires:

• Institutional knowledge: What actually works? What failed before?
• Risk assessment: What breaks if we change this?
• Alternative proposals: If not this way, then how?
• Continuous defense: Every year brings new proposals to resist.

It turns out “keeping things the same” in a world that constantly pushes change is active work.

When Conservatism Works

Conservatives are right when:

• A proposed change has unexamined second-order effects
• Historical precedent shows this failed before
• Existing systems work well enough
• The rush to change is driven by fashion, not function
• Breaking something is easier than fixing it

Example: “Let’s rewrite the entire codebase in [new framework].”

Conservative response: “Why? What problem does this solve? What breaks during migration?”

Sometimes the right answer is: don’t.

When Conservatism Fails

Conservatives are wrong when:

• The status quo is actively harmful
• Evidence shows change works
• Resistance becomes reflexive, not reasoned
• “That’s how we’ve always done it” becomes the only argument
• The cost of inaction exceeds the risk of action

Example: “Let’s keep using this legacy system forever.”

Conservative response: “It works fine.”

Reality: It works until it catastrophically doesn’t.

The Uncomfortable Truth

Both sides need each other.

Without progressives: stagnation, missed opportunities, institutional rot.

Without conservatives: chaos, broken systems, unforeseen disasters.

Software engineering learned this decades ago:

• Move fast and break things → production outages
• Never change anything → technical debt death spiral
• Iterate carefully with tests and rollbacks → actually works

Politics hasn’t figured this out yet.

What I Should Have Said

“Conservatives are there to ask ‘are you sure?’ every time someone says ’let’s change this.’

Sometimes the answer is yes, and change happens anyway.

Sometimes the answer is no, and disaster is prevented.

Either way, asking the question has value.”

The Real Question

Not “what are conservatives for?”

But: “What’s the right rate of change?”

And that’s a question neither side can answer alone.

Written after realizing my political explanations need better runtime complexity analysis.

Most goal-setting advice is broken. It tells you to dream big, then immediately asks: “What’s your next action?” The gap between “become a recognized AI infrastructure expert” and “write a blog post” is so vast that you either freeze or start randomly doing things that feel productive.

I’ve been experimenting with a different approach: treat your goals like a tree, and only work on branches you can actually reach.

The Problem With Traditional Goal Setting

You set a big goal. Maybe it’s “build a successful consulting business” or “master distributed systems.” Then what?

Option A: You break it down into quarterly milestones. But those milestones are still too big. You stare at them and feel overwhelmed.

Option B: You jump straight to tasks. “Send 10 cold emails today.” But why? Does this actually connect to the big goal? Who knows. You’re just doing things.

The gap between vision and action is where goals go to die.

The Tree System

Here’s what works better: recursive decomposition until you hit something you can do right now.

Start with your life goal. One branch. Then ask: “What sub-goals would get me there?”

For each sub-goal, ask again: “What sub-goals would get me there?”

Keep going until you hit a branch that ends in something you can do today. Ideally right now.

Then do it. Mark it complete. Watch that branch grow upward toward the higher goals.

Example: The Consulting Business Tree

Life Goal: Run a thriving AI infrastructure consulting business
├── Sub-goal: Build reputation as expert
│   ├── Sub-goal: Publish thought leadership
│   │   ├── Sub-goal: Write 12 blog posts this quarter
│   │   │   └── Task: Write post about goal systems [DO THIS NOW]
│   │   └── Sub-goal: Speak at 2 conferences
│   │       └── Sub-goal: Submit 5 CFP proposals
│   │           └── Task: Research upcoming AI conferences [DO THIS NOW]
│   └── Sub-goal: Demonstrate expertise publicly
│       └── Sub-goal: Share technical insights weekly
│           └── Task: Post architecture diagram on LinkedIn [DO THIS NOW]
└── Sub-goal: Generate consistent revenue
    ├── Sub-goal: Build pipeline of qualified leads
    │   ├── Sub-goal: Get 3 referrals from past clients
    │   │   └── Task: Email previous client about coffee chat [DO THIS NOW]
    │   └── Sub-goal: Establish presence in target market
    │       └── Task: Join AI infrastructure Slack community [DO THIS NOW]
    └── Sub-goal: Improve conversion rate
        └── Sub-goal: Refine positioning
            └── Task: Update homepage headline [DO THIS NOW]

Notice: every branch eventually ends in something concrete. Something you could do in the next hour.

Why This Works

1. No dead-end planning. You don’t create goals that float in space. Every sub-goal exists because it feeds into something higher. Every task exists because it grows a branch.

2. You always know what to do next. Just scan the tree for the lowest actionable branches. Do one. Watch it bubble up.

3. Motivation from compound progress. When you complete a low-level task, you’re not just checking a box. You’re literally growing multiple branches at once. That blog post? It feeds “publish thought leadership” AND “build reputation” AND your life goal. Three levels of progress from one action.

4. The big picture stays visible. You’re not lost in a task list. You can always zoom out and see how today’s work connects to the top of the tree.

5. Natural prioritization. Some branches have more actionable tasks than others. That’s fine. Work on what’s ready. The tree shows you where you’re blocked (branches with no actionable tasks yet) versus where you have momentum.

The Time is Always Now

Here’s the thing I keep learning: you can’t get caught up in time.

No deadlines. No “by Q2 2026.” No “in three months I’ll…”

The time is always now. The only question is: what branch can I grow right now?

Traditional planning wants you to spread tasks across a calendar. “I’ll do this in January, that in March.” But January never comes. There’s only ever this moment.

So the tree system doesn’t track time. It tracks readiness.

Is this task ready to do now? Do it now. Is this goal not decomposed enough? Decompose it now. Is this branch blocked? Work a different branch now.

The tree grows in the present moment. Always.

The Anti-Vision Paradox

This might sound like detailed planning. It’s not.

You’re not predicting the future. You’re not committing to a specific path. You’re just saying: “If I want to get there, I probably need to go through here.”

And the magic is: you only plan as deep as you need to find something doable.

If a branch isn’t ready to break down further, leave it. Come back when you’ve grown the other branches and gained new information.

The tree evolves. Branches get pruned. New branches appear. But you’re always working on something that’s both:

• Immediately actionable
• Connected to your highest goals

The Implementation: Structured Markdown

I’m implementing this with the simplest possible system: folders and markdown files.

Each goal is a folder. Each sub-goal is either:

• Another folder (if it needs more decomposition)
• A markdown file (if it’s a leaf node with actionable tasks)

goals/
└── consulting-business/
    ├── build-reputation/
    │   ├── publish-thought-leadership/
    │   │   ├── blog-posts.md
    │   │   └── conference-talks.md
    │   └── demonstrate-expertise.md
    └── generate-revenue/
        ├── build-pipeline.md
        └── improve-conversion.md

Inside each markdown file? Just a list of tasks with checkboxes:

# Blog Posts

- [x] Write post about goal systems
- [ ] Write post about Restic performance
- [ ] Write post about AI infrastructure patterns

That’s it. No app. No database. No sync. No dates. Just files you can grep, find, and edit with vim.

The file system is the tree. The folder structure is the hierarchy. Your tools already understand it.

Why Markdown Files?

It’s portable. Move it anywhere. Edit it anywhere. No vendor lock-in.

It’s greppable. Want to see all your actionable tasks? grep -r "\[ \]" goals/ Done.

It’s git-friendly. Track your progress over time. See which branches grew. Diff your trees.

It’s simple. No learning curve. No configuration. No “productivity system setup” that takes a week.

It matches how you think. Folders contain things. Files list things. Your brain already knows this pattern.

It’s timeless. No calendar integration. No overdue tasks turning red. Just: ready or not ready. Now or not now.

And here’s the beautiful part: the file system enforces the tree structure. You can’t create a floating task. It has to live in a file. Which lives in a folder. Which connects to your top-level goal.

The structure is the system.

Building Your Own Tree

Start simple:

1. Pick one life goal. Create a folder for it.

2. Ask: “What 2-4 sub-goals would get me there?” Create folders or markdown files.

3. Keep decomposing. When a goal needs more breakdown, make it a folder. When it’s ready for tasks, make it a markdown file.

4. Do the lowest hanging fruit. Find an unchecked box. Do it now. Check it off.

5. Watch the branches grow. When all tasks in a file are done, that sub-goal is complete. Mark it. Move up the tree.

6. Repeat. Keep working the branches. Keep decomposing when you get stuck. Keep pruning dead wood.

No dates. No timelines. Just: what’s ready now?

Why I’m Switching to This

I’ve tried the big vision approach (gets vague). I’ve tried the daily wins approach (gets disconnected). I’ve tried quarterly OKRs (gets bureaucratic). I’ve tried productivity apps (gets complicated). I’ve tried calendar-based planning (gets caught up in time).

The tree system gives me both:

• The clarity of “just do this one thing now”
• The confidence that this one thing actually matters

And by using plain markdown files, I get:

• Zero friction to update
• Total control over structure
• Tools I already know
• A system that will outlive any app
• Freedom from time anxiety

Every action grows multiple branches. Every branch connects to the top. No wasted effort. No floating tasks. No imaginary futures.

Just a tree, growing steadily toward the goal, one moment at a time.

What’s your life goal? Can you decompose it until you hit something you can do right now?

Create a folder. Add a markdown file. Start checking boxes.

The time is always now.

The tree doesn’t lie.

If the route is the goal, what happens when you teleport?

The Route Problem

Culture isn’t what you build. It’s what you walk through while building it.

Think about it:

• A chef’s “culture” isn’t recipes—it’s burned sauces and failed soufflés
• A musician’s “culture” isn’t songs—it’s callused fingers and broken strings
• A programmer’s “culture” isn’t code—it’s Stack Overflow deep dives at 2 AM

Culture is the sum of routes people walked, not the destinations they reached.

AI skips the route. You ask, it delivers. No journey, just arrival.

What We Lose When We Skip The Walk

1. The Accidental Discoveries

You’re debugging for hours. You don’t fix the bug, but you stumble onto a better architecture. That’s culture.

AI fixes the bug in seconds. You learn nothing except “AI can fix bugs.” That’s consumption.

Lost routes = lost discoveries.

2. The Shared Suffering

Every developer has fought UTF-8 encoding hell. It’s a rite of passage. You bond over it. You laugh about it years later. It’s culture.

AI handles encoding transparently. You never fight it. You never bond over it. You never laugh about it.

Shared routes = shared identity.

3. The Intuition Building

You’ve refactored 50 functions by hand. On function 51, you feel the pattern before you see it. That’s mastery.

AI refactors all 51 at once. You never develop the feel. You just review the diff.

Repeated routes = internalized knowledge.

The Speculative Nightmare (Or Dream?)

What happens when an entire generation skips the routes?

Scenario 1: Culture Fractures Into Pre-AI and Post-AI

The last generation who learned to code without AI becomes unrelateable to the first generation who never coded without it.

They literally don’t share the same reference points:

• “Remember fighting with makefiles?” — blank stares
• “Remember the joy when your first loop worked?” — never felt it
• “Remember learning pointers?” — never needed to

We split into two species: Route-Walkers and Teleporters.

Scenario 2: Culture Becomes Meta

If culture is “the sum of routes walked,” and AI walks the routes…

Maybe culture shifts to:

• Prompt archaeology: studying how people asked for things
• AI wrangling stories: the time Claude hallucinated and you debugged for 6 hours
• Direction-setting wisdom: knowing what to build, not how

Culture doesn’t die. It changes altitude. We stop trading war stories about implementation and start trading war stories about intention.

Scenario 3: We Optimize Culture Out of Existence

Efficiency kills inefficiency. Routes are inefficient. Culture is inefficient.

What if we optimize so hard that we forget why routes mattered?

• Music made by AI, consumed by AI, critiqued by AI
• Code written by AI, reviewed by AI, deployed by AI
• Books generated by AI, summarized by AI, recommended by AI

Humans become the audience. But audiences don’t create culture. Performers do.

If nobody walks the route, is there still a culture? Or just a catalog?

The Counter-Argument: Culture Always Evolves

Maybe I’m romanticizing the route.

Printing press killed manuscript culture. Every monk mourned the loss of hand-copied books. But we didn’t lose culture—we democratized it.

Cars killed horse culture. Every blacksmith mourned the loss of farrier craft. But we didn’t lose culture—we accelerated it.

Maybe AI kills grind culture. Every developer mourns the loss of hard-won debugging skills. But we don’t lose culture—we abstract it.

The route changes. The destination changes. The culture changes.

Same as it ever was.

The Uncomfortable Question

Here’s what keeps me up:

What if walking the route wasn’t just how we built culture—what if it was how we built ourselves?

The struggle isn’t a bug. It’s the feature.

You’re not the person who knows how to center a div. You’re the person who fought to center a div.

AI takes the fight. Does it take the person?

What We Can Do (Maybe)

I don’t have answers. I have guesses:

1. Walk Some Routes On Purpose

Learn one thing the hard way each year. Not for efficiency. For the route.

• Write assembly once
• Build a compiler once
• Implement TCP from scratch once

Not to use it. To feel it.

2. Document The Routes AI Takes

AI skips steps. Make it show its work. Study the paths it chose. Build intuition about why it chose them.

You’re not walking the route, but you’re learning the map.

3. Create New Routes Worth Walking

AI can write code. It can’t discover what’s worth building.

The new cultural route isn’t “how do I implement this?”

It’s “why does this need to exist?”

The Route Forward (Ironic Phrasing Intended)

Culture isn’t dying. It’s mutating.

We’re in the awkward phase where:

• Old routes still feel meaningful (they are)
• New routes haven’t been established yet (they will be)
• We’re mourning and celebrating simultaneously (we should be)

Maybe in 20 years, we’ll look back and laugh at how we thought “writing your own sort function” was culture.

Or maybe we’ll mourn that nobody remembers what it felt like to fight a segfault at 3 AM.

Either way, we won’t have walked the route to know which is true.

We’ll have asked AI.

Written by human. Routed through doubt. Arrived at speculation.

The game has changed completely.

For decades, business process optimization was a slow, painful grind. Consultants would spend months mapping workflows, conducting interviews, analyzing spreadsheets, and building process diagrams. The lucky ones might identify a few bottlenecks after burning through budgets that would make a CFO weep.

Then AI arrived and flipped the entire industry on its head.

The Old Way Was Brutally Slow

Remember the pre-AI consulting playbook? It looked something like this:

1. Discovery Phase (4-8 weeks): Interview everyone, document everything
2. Analysis Phase (6-12 weeks): Build process maps, identify gaps
3. Solution Phase (4-6 weeks): Research tools, create recommendations
4. Implementation Phase (12-24 weeks): Roll out new systems, train users

Total timeline: 6-12 months. Total cost: Often six figures. Success rate: Honestly? Pretty hit-or-miss.

The consultant’s job was essentially acting as a human search engine: “You need a CRM? Try Salesforce. Inventory issues? Here’s an ERP system. Communication problems? Slack it is.”

AI Changed Everything Overnight

Now? AI can analyze your entire operation in hours, not months.

• Process Mining: AI tools scan your systems and automatically map every workflow
• Pattern Recognition: Machine learning spots bottlenecks humans would miss entirely
• Real-time Analysis: No more waiting weeks for reports - insights appear instantly
• Predictive Modeling: AI shows you where problems will emerge before they hit

What used to take a team of consultants months to uncover, AI can identify over a coffee break.

The Consultant’s Role Has Evolved

This doesn’t mean consultants are obsolete - quite the opposite. But the conversation has completely shifted.

Before AI, clients asked:

• “Which CRM should we use?”
• “What’s the best project management tool?”
• “Can you recommend a good accounting system?”

Now AI specialists ask:

• “Where are your actual bottlenecks?”
• “Which processes are bleeding money?”
• “What’s stopping your team from scaling?”

The focus moved from tool selection to process archaeology. Instead of being software salespeople in disguise, consultants became process detectives.

Speed Is Everything

Here’s what really matters: AI compressed months of analysis into days. This speed advantage isn’t just convenient - it’s transformational.

When process optimization takes 6 months, businesses defer improvements indefinitely. When it takes 6 days, they’ll tackle three optimization projects before lunch.

I’ve seen companies identify and fix workflow bottlenecks in a single sprint that would have required a full consulting engagement just two years ago. The economics are completely different now.

The New Consulting Questions

Modern AI-powered process consulting starts with fundamentally different questions:

• “Show me your data flows” - AI can trace every transaction, approval, and handoff
• “Where do tasks queue up?” - Machine learning spots delay patterns instantly
• “What’s your actual cycle time?” - Real measurements, not estimates
• “Which manual steps add no value?” - Process mining reveals redundant work
• “Where do errors cluster?” - Pattern analysis finds root causes

These aren’t tool questions - they’re optimization questions.

The Bottleneck Detective

Today’s AI specialist is less “systems integrator” and more “bottleneck detective.”

We’re not here to sell you software. We’re here to find where your business is hemorrhaging time, money, or opportunities. AI gives us X-ray vision into your operations.

The conversation shifted from “Here’s what you should buy” to “Here’s what’s actually broken.”

What This Means for Business

If you’re still thinking about AI in terms of “tools” and “platforms,” you’re missing the real revolution. AI isn’t just another software category - it’s a completely new way to understand and optimize how work gets done.

The businesses winning right now aren’t the ones with the fanciest AI tools. They’re the ones using AI to find and fix their process bottlenecks faster than their competition can even identify them.

Speed of optimization is becoming the ultimate competitive advantage.

Need help identifying bottlenecks in your business processes? Let’s talk about what AI can uncover in your operation.

Stop planning. Start winning.

The Big Picture Trap

Everyone tells you to think big. Vision boards. Five-year plans. Moonshots. Meanwhile, you’re paralyzed because the mountain looks too damn high.

Here’s the dirty secret: the big picture is a distraction.

The Daily Win Philosophy

Instead of asking “Where will I be in 5 years?”, ask:

“What would make today a win?”

That’s it. One question. One day.

• Fixed that bug? Win.
• Shipped that feature? Win.
• Learned that new tool? Win.
• Helped a teammate? Win.
• Refactored that mess? Win.

Stack enough wins, and you look back six months later wondering how the hell you got so far.

Why This Works

Compound Interest for Humans: Each successful day builds on the last. You’re not making a 5-year leap—you’re making 1,825 micro-improvements.

No Analysis Paralysis: You can’t overthink “What should I do today?” You know. Deep down, you always know.

Immediate Feedback: You know by 6 PM if you won. No waiting years to see if your master plan worked.

Resilience Built-In: Bad day? Tomorrow’s a fresh chance. Bad year in a 5-year plan? You’re screwed.

The Anti-Vision

I’m not saying don’t have goals. I’m saying stop worshiping them.

Your goal is the direction. Your day is the step.

Walk north every day, and you’ll end up north. Stare at the map dreaming about Alaska, and you’re still in your living room.

The Exception

The only big-picture question worth asking:

“Is what I’m doing today moving me in a direction I give a shit about?”

If yes: keep winning days.

If no: adjust direction, then keep winning days.

What “Excellent” Really Means

Have 30 successful days? That’s an excellent month. Have 90 successful days? That’s an excellent quarter. Have 250 successful days? That’s an excellent year.

Excellence isn’t a destination. It’s a batting average.

Practical Application

Every morning, write down:

Today is a win if I: [one thing]

Every evening, answer:

Did I win? [yes/no]

Track it in a text file, a spreadsheet, a notebook, a terminal script—doesn’t matter. Just track it.

Watch your streak. When you hit 7 wins in a row, you’ll feel it. When you hit 30, you’ll be it.

The Math

• 70% win rate = 255 winning days per year
• 255 winning days = top 1% of output
• Top 1% of output = opportunities find you

You don’t need a better plan. You need a better Tuesday.

Stop Reading, Start Winning

What would make today a win?

Now go do that.

Written during a winning day. Tomorrow’s another one.

You know what’s surprisingly not terrible? Backing up databases.

Wait, let me rephrase: You know what’s surprisingly not terrible when you use the right tool? Backing up databases.

The Numbers

150GB MSSQL data directory. 2 minutes and 57 seconds. Done.

Not hours. Not “let it run overnight.” Not “come back after lunch.” Under three minutes for production database files.

The Tool: Restic

Restic is one of those rare pieces of software that just works. Open source backup program that handles deduplication, encryption, compression, and verification without a PhD thesis worth of configuration.

• Fast - Parallel processing, smart chunking, efficient compression
• Encrypted by default - Because we’re not animals
• Deduplication - Only backs up what changed
• Cross-platform - Linux, Windows, macOS, BSD
• Multiple backends - Local, SFTP, S3, Azure, you name it
• Simple CLI - No XML config files

GitHub: restic/restic Docs: restic.readthedocs.io

Ten Years of Production Use

This is literally the simplest backup script possible, and I’ve been running it for over ten years. Multiple restores. Multiple data migrations. Zero disasters.

@echo off

REM === CONFIGURATION - CHANGE THESE VALUES ===
set RESTIC_REPOSITORY=\\backup-server\datev-backups
set RESTIC_PASSWORD=your-password-here
set DATEV_DATA_DIR=L:\WINDVSW1
REM ==========================================

REM Stop DATEV SQL Server
echo Stopping SQL Server...
net stop "MSSQL$DATEV_DBENGINE" /y

REM Wait a bit for files to be released
timeout /t 10

REM Run restic backup
echo Running backup...
restic -r %RESTIC_REPOSITORY% backup "%DATEV_DATA_DIR%"

REM Start DATEV SQL Server
echo Starting SQL Server...
net start "MSSQL$DATEV_DBENGINE"

echo Backup complete!
pause

Thirteen lines. Stop service. Wait 10 seconds. Backup. Start service. Done.

This script has survived multiple Windows Server upgrades, hardware migrations, storage changes, and countless DATEV updates. It works because there’s nothing to break.

Why It’s Fast

Deduplication is the secret sauce. First backup of 150GB takes a while. Second backup where only 5GB changed? Under three minutes.

MSSQL files are huge, but day-to-day changes are relatively small. Restic only saves the blocks that changed. This is why it destroys traditional backup tools for database files.

The Restic Workflow

# Initialize a repository (one time)
restic init --repo /path/to/backup

# Backup
restic backup /data --repo /path/to/backup

# List snapshots
restic snapshots --repo /path/to/backup

# Restore
restic restore latest --repo /path/to/backup --target /restore/path

# Check integrity
restic check --repo /path/to/backup

# Cleanup old snapshots
restic forget --keep-last 10 --prune --repo /path/to/backup

The Track Record

Over a decade of production use. I’ve actually had to restore from these backups—multiple times, for migrations and recovery scenarios. Every single time, Restic delivered.

No corruption. No incomplete snapshots. No “upgrade to Enterprise Edition” nonsense.

It just works. Which in the backup world is about as rare as finding a bug-free Microsoft update.

The Bottom Line

150GB. 2:57. Thirteen-line batch file. Ten years of production use. Multiple successful restores.

Restic is fast, reliable, encrypted, free, and doesn’t make you want to throw your computer out a window.

If you’re backing up databases and not using Restic, you’re either using something enterprise and expensive that’s probably slower, or not backing up at all (please fix this immediately).

Go download Restic. Set up automated backups. Sleep better at night.

P.S. - Seriously, if you’re not backing up your databases, stop reading and go set that up right now. I’ll wait.

After doing lots of stuff with AI Claude Code, I’ve had a realization.

The Reward Loop

You know what’s incredibly rewarding? Using vim and actually getting stuff done.

Not explaining what you want. Not waiting for responses. Not describing your intent in natural language prose.

Just doing.

Flow State is Real

This is what flow state actually feels like:

Your fingers move faster than your thoughts. Muscle memory takes over. dd, ciw, :%s, gq - these aren’t commands anymore, they’re extensions of your intent.

AI is amazing for architecture, for boilerplate, for “figure this out for me” moments. Claude Code has fundamentally changed how I work.

But there’s something else entirely about just editing code yourself.

The Zen of Direct Action

When you’re in the zone with vim:

• No context switching to explain what you want changed
• No waiting for a response to generate
• No reviewing AI changes to verify they match your mental model
• Just pure, immediate, tactile manipulation of text

It’s meditative. It’s zen.

The Best of Both Worlds

Here’s the thing: it’s not either/or.

Use Claude Code for:

• Scaffolding new features
• Researching unfamiliar codebases
• Refactoring gnarly legacy code
• Explaining complex systems

Use vim for:

• Quick edits you can visualize
• Fine-tuning AI-generated code
• Flow state deep work sessions
• Everything that feels faster to just do

Calm Down and Code

After hours of prompting AI, sometimes the most productive thing you can do is:

Close the chat. Open vim. Trust your fingers. Get it done.

This is flow state. This is zen.

Calm down and code.

Written in vim, obviously.

Remember when everyone said the command line was dead? That GUIs had won? That normal people don’t need to know sed or awk or grep?

Yeah, about that.

The Xth Revival of GNU Utils

Here we are in 2025, and suddenly every AI model on the planet is an absolute wizard with cat, sed, tr, grep, and friends. The same Unix tools that have been around since before I was born are now the lingua franca of AI automation.

Why? Because they’re simple. They’re composable. They’re text-based.

All the things we crusty command line users have been saying for decades? Turns out they’re exactly what makes tools perfect for AI agents. Who knew that piping plain text through focused, single-purpose utilities would be the ideal interface for artificial intelligence?

Oh wait. We knew. We’ve been telling you this the whole time.

SSH: The Killer App You Already Had

Want to know what’s hilarious? While everyone was building complicated REST APIs and GraphQL endpoints and whatever-the-hell-else to enable remote access, Linux quietly shipped with SSH access nearly by default.

AI doesn’t need your fancy API. It needs to SSH into a box and run some commands. Done.

Remote command line access has been solved for 30+ years. It’s secure, it’s universal, it’s scriptable. And now AI agents can use it to manage infrastructure, debug production issues, deploy code, troubleshoot systems—all the things sysadmins have been doing from terminal windows since forever.

The future of AI infrastructure management looks suspiciously like a guy with an SSH key and a shell prompt. Imagine that.

Scripts: Suddenly Useful Again

Remember when “real developers” were too good for shell scripts? When everything had to be a microservice or a containerized application or some framework-heavy monstrosity?

AI loves scripts. Bash scripts, Python scripts, doesn’t matter. They’re declarative, readable, and you can iterate on them in seconds. No compilation step. No build pipeline. No deployment ceremony.

Just edit a file, run it, see what breaks, fix it, repeat.

This is what system automation has always looked like for people who actually operate systems. Now AI can do it too, and suddenly everyone’s rediscovering the beauty of a well-crafted 50-line bash script that solves a real problem.

Dotfiles: We Were Doing AI Instructions Before AI

Here’s my favorite part: command line users have been living with dotfiles for decades. Configuration as text files. .bashrc, .vimrc, .gitconfig—we’ve been versioning our environment preferences and sharing them on GitHub since before “Infrastructure as Code” was a buzzword.

And what’s the hot new thing in AI? Markdown instruction files. CLAUDE.md. Agent configuration files.

It’s literally the same concept. Text-based configuration that you can version control, share, and iterate on. We’ve been doing this. This isn’t new. You’re just catching up.

Command Line Troubleshooting: Now With AI Copilots

Debugging production issues used to mean SSHing into servers, grepping logs, piping through awk, maybe writing a quick script to parse some data. It was fast, it was effective, and it required actual skill.

Now? Same workflow, except you can have an AI agent help. It can grep the logs for you, write the parsing script, suggest the fix. The interface is still the command line because that’s the right interface for this job.

All those “modern” observability platforms with their fancy dashboards? Great for executives. But when shit hits the fan at 3 AM, you’re still going to SSH into that box and read the damn logs with less and grep.

AI just makes you better at it.

The Dark Side: AI Can rm -rf Too

Now for the uncomfortable truth we need to talk about: AI has access to all these powerful tools, and powerful tools are called “powerful” for a reason.

An AI agent that can run sed on your config files can also run rm -rf / on your production server. An agent with SSH access can do everything you can do—including catastrophically destructive things.

AI makes mistakes. Hallucinations. Logic errors. Misunderstandings. And when those mistakes involve shell commands with root privileges, people get fired.

I’ve seen AI agents:

• Delete production databases
• Overwrite critical config files
• Break SSH access to remote systems
• Fill disks by accident
• Chmod things they shouldn’t
• Git push –force to main

The command line is powerful. AI is powerful. Together? You better have backups. And version control. And read-only users. And a very good understanding of what you’re asking the AI to do.

The Punchline

The future of AI-powered infrastructure looks an awful lot like the past of Unix system administration. Text files, composable tools, SSH access, scripts, and command-line troubleshooting.

For those of us who never left the terminal, this isn’t a revolution. It’s validation.

We were right all along. The command line isn’t dead. It’s just getting smarter assistants.

Now if you’ll excuse me, I need to go write a .clauderc file to configure my AI agent’s shell preferences. You know, like we’ve been doing with .bashrc since 1989.

Reminder: With great shell access comes great responsibility. AI + sudo can end badly. Very badly. Test in dev. Use version control. Keep backups. Don’t say I didn’t warn you.

After creating a 3-day workshop about OpenWebUI with over 100 slides, I discovered an incredibly efficient workflow: combining Claude Code with Slidev. Here’s why this combination is a game-changer for technical presentations.

Why Slidev?

Slidev is a presentation framework for developers that uses Markdown and Vue.js. Unlike traditional slide tools:

• Markdown-based: Write slides in plain text with code syntax highlighting
• Version control friendly: Git tracks every change cleanly
• Developer-focused: Code blocks, diagrams, custom layouts all built-in
• Live reload: See changes instantly during development
• Export options: PDF, SPA, or present directly in browser

Why Claude Code?

Claude Code isn’t just an AI assistant—it’s a coding partner that understands project structure, maintains consistency, and can execute complex multi-step tasks. For presentation development, it excels at:

• Content generation: Creating technical content with proper depth
• Layout management: Applying custom layouts across 100+ slides consistently
• Style debugging: Finding and fixing CSS issues across the entire presentation
• Structural refactoring: Reorganizing content while maintaining coherence

The Workflow

1. Docker-Based Setup

No local Node.js installation needed. Here’s the docker-compose.yml:

services:
  slidev-day1:
    image: tangramor/slidev:latest
    container_name: workshop-slidev-day1
    ports:
      - "3031:3030"
    volumes:
      - ./slidev:/slidev
    command: slidev day1.md --host 0.0.0.0
    restart: unless-stopped

Benefits:

• Isolated environment per presentation
• No dependency conflicts
• Works identically across machines
• Easy to scale (I run 3 presentations simultaneously)

2. Custom Layouts

Slidev’s real power is custom layouts. For my workshop, I created:

Code-heavy layout (slidev/layouts/code-heavy.vue):

<template>
  <div class="slidev-layout code-heavy">
    <slot />
  </div>
</template>

<style scoped>
.code-heavy {
  padding-bottom: 7rem;
}
.code-heavy pre {
  max-height: 60vh;
  overflow-y: auto;
}
</style>

Definitions layout for terminology slides:

<template>
  <div class="slidev-layout definitions">
    <slot />
  </div>
</template>

<style scoped>
.definitions strong {
  color: #00d9ff;
  font-size: 1.3rem;
  display: block;
  margin-top: 1.5rem;
}
</style>

3. Applying Layouts

In your Markdown:

---
layout: code-heavy
---

# Docker Compose Example

\`\`\`yaml
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    volumes:
      - ./data:/app/backend/data
\`\`\`

Key points:
- Persistent storage with volumes
- Port mapping 3000→8080
- Latest image from GitHub registry
---

How Claude Code Accelerates Development

Content Creation

Prompt: “Write a slide explaining OpenWebUI’s vector database integration with examples”

Claude generates:

• Technical accuracy (checks docs, code)
• Proper structure
• Code examples with syntax highlighting
• Practical use cases

Bulk Operations

Prompt: “Apply code-heavy layout to all slides with code blocks in day2.md”

Claude:

1. Analyzes all 40+ slides
2. Identifies code-heavy content
3. Adds layout: code-heavy frontmatter
4. Maintains existing styling

This would take hours manually—Claude does it in seconds.

Debugging Across Files

Prompt: “Strong text appears gray on center layout slides”

Claude:

1. Searches through style.css
2. Identifies conflicting opacity rules
3. Fixes specificity issues
4. Tests across all three presentations

Documentation Sync

Prompt: “Update MCP integration slide with latest GitHub issue status”

Claude:

1. Fetches current issue state
2. Updates content truthfully (marks features as experimental)
3. Adds code references with line numbers
4. Maintains technical precision

Real-World Example: Workshop Evolution

My OpenWebUI workshop started as rough outlines. With Claude Code:

Day 1 (28 slides): Basic concepts → Claude added practical examples and proper terminology Day 2 (29 slides): Advanced features → Claude researched actual implementation details Day 3 (47 slides): Production setup → Claude cross-referenced documentation and code

Total development time: ~6 hours instead of days.

Best Practices

1. Clear Project Structure

workshop/
├── docker-compose.yml
├── slidev/
│   ├── day1.md
│   ├── day2.md
│   ├── day3.md
│   ├── style.css
│   └── layouts/
│       ├── code-heavy.vue
│       ├── content-dense.vue
│       └── definitions.vue
└── CLAUDE.md  # Project instructions for Claude

2. Document Your Conventions

Create CLAUDE.md in your project:

# Presentation Guidelines

- Use **strong text** for key terms
- Apply `code-heavy` layout when code exceeds 15 lines
- Keep bullet points to max 5 per slide
- Cite sources with GitHub issue numbers
- Use `tmp/` for temporary analysis files

Claude reads this and maintains consistency automatically.

3. Version Control Everything

git add slidev/
git commit -m "Add MCP integration slides with honest limitations"

Because everything is Markdown and text files, Git diffs are meaningful.

4. Iterative Refinement

Don’t expect perfection immediately. My workflow:

1. Draft: “Create outline for Docker basics”
2. Refine: “Add error handling examples”
3. Style: “Apply proper layouts”
4. Review: “Check for technical accuracy”
5. Polish: “Fix spacing and formatting”

Claude handles each step reliably.

Getting Started

Step 1: Set Up Slidev with Docker

mkdir my-presentation
cd my-presentation

cat > docker-compose.yml <<EOF
services:
  slidev:
    image: tangramor/slidev:latest
    ports:
      - "3030:3030"
    volumes:
      - ./slidev:/slidev
    command: slidev slides.md --host 0.0.0.0
EOF

mkdir slidev
cd slidev

cat > slides.md <<EOF
---
theme: default
colorSchema: dark
---

# My First Slidev Presentation

Built with Claude Code

---

# Slide 2

- Point 1
- Point 2
- Point 3
EOF

Step 2: Start Presenting

docker-compose up -d

Open http://localhost:3030 in your browser.

Step 3: Use Claude Code

Create CLAUDE.md:

# Presentation Project

- Theme: Technical workshop
- Style: Minimal, code-focused
- Custom layouts in `slidev/layouts/`
- Use dark theme consistently

Then in Claude Code:

Add 5 slides about Docker basics with practical examples

Claude generates content, applies layouts, maintains your style.

Advanced Tips

Environment Variables

For workshop dates:

# .env
WORKSHOP_DATE=October 20, 2025

# Inject into slides
./scripts/inject-dates.sh

Claude can generate these scripts too.

PDF Export

docker exec -it slidev npx slidev export slides.md

Custom Themes

Slidev supports full theming. I use:

/* slidev/style.css */
:root {
  --slidev-theme-primary: #00d9ff;
  --slidev-theme-accents: #6366f1;
}

strong {
  color: var(--slidev-theme-primary);
}

Why This Matters

Traditional presentation tools (PowerPoint, Keynote, Google Slides) are:

• Not version controllable: Binary formats or messy XML
• Manual labor intensive: Every style change requires clicking through slides
• Not developer-friendly: Code blocks look terrible

Slidev + Claude Code gives you:

• Git-friendly: Every change is trackable
• Automated consistency: Claude applies changes globally
• Developer experience: Write slides like you write code
• AI-assisted content: Focus on structure, Claude handles details

Conclusion

After building 100+ slides this way, I can’t go back. The combination of:

• Slidev’s developer-first approach
• Docker’s reproducibility
• Claude Code’s intelligence

…creates a presentation workflow that’s faster, more maintainable, and more enjoyable than traditional tools.

If you’re a developer creating technical presentations, this workflow will change how you work.

Resources

• Slidev Documentation
• Claude Code Documentation
• Slidev Docker Image
• My Workshop Example (adapt link)

Written with Claude Code, naturally.

Getting Claude Code’s Playwright MCP (Model Context Protocol) to work on NixOS presents several unique challenges. This guide documents a complete declarative solution using home-manager.

The Problem

NixOS’s unique architecture creates several issues for Playwright MCP:

1. Browser Installation Issues: Standard npx playwright install doesn’t work with NixOS’s non-FHS layout
2. Read-only Nix Store: Playwright tries to create user data directories inside /nix/store, which is read-only
3. Browser Detection: Even with PLAYWRIGHT_BROWSERS_PATH set, the MCP server doesn’t recognize browsers as “installed”
4. Non-persistent Configuration: Manual changes to ~/.claude.json get overwritten on system updates

Typical errors you’ll encounter:

Error: Browser specified in your config is not installed. Either install it (likely) or change the config.

Or:

ENOENT: no such file or directory, mkdir '/nix/store/.../playwright-browsers/mcp-chrome-...'

The Solution

The solution involves:

1. Using playwright-web-flake to provide browsers in the Nix store
2. Creating a home-manager module that declaratively manages Claude Code’s MCP configuration
3. Using an activation script to merge configuration into ~/.claude.json on every rebuild
4. Specifying the exact executable path to bypass browser detection issues
5. Setting a writable profile directory for browser user data

Implementation

Step 1: Add playwright-web-flake to your flake inputs

In your flake.nix:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";

    # Add Playwright browser flake
    playwright-web-flake.url = "github:pietdevries94/playwright-web-flake";
  };

  outputs = { nixpkgs, home-manager, playwright-web-flake, ... }@inputs: {
    # Your existing configuration...
  };
}

Step 2: Install required packages

In your home-manager/home.nix:

{ inputs, pkgs, ... }:

{
  home.packages = with pkgs; [
    claude-code
    inputs.playwright-web-flake.packages.${pkgs.system}.playwright-driver
  ];

  home.sessionVariables = {
    PLAYWRIGHT_BROWSERS_PATH = "${inputs.playwright-web-flake.packages.${pkgs.system}.playwright-driver.browsers.${pkgs.system}}";
    PLAYWRIGHT_SKIP_VALIDATE_HOST_REQUIREMENTS = "true";
    PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD = "1";
  };
}

Step 3: Create the Claude Code configuration module

Create home-manager/programs/claude-code.nix:

{ inputs, lib, config, pkgs, ... }:

let
  playwrightDriver = inputs.playwright-web-flake.packages.${pkgs.system}.playwright-driver;
  playwrightBrowsersPath = builtins.unsafeDiscardStringContext "${playwrightDriver.browsers}";

  playwrightMcpConfig = {
    playwright = {
      type = "stdio";
      command = "npx";
      args = [
        "@playwright/mcp@latest"
        "--browser"
        "chromium"
        "--executable-path"
        "$PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH"
      ];
      env = {
        PLAYWRIGHT_BROWSERS_PATH = "$PLAYWRIGHT_BROWSERS_PATH";
        PLAYWRIGHT_SKIP_VALIDATE_HOST_REQUIREMENTS = "true";
        PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD = "1";
        PWMCP_PROFILES_DIR_FOR_TEST = "$HOME/.local/share/playwright-mcp/profiles";
        PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH = "$PLAYWRIGHT_BROWSERS_PATH/chromium-1181/chrome-linux/chrome";
      };
    };
  };

  mcpConfigJson = builtins.toJSON playwrightMcpConfig;
in
{
  home.activation.configureClaude = lib.hm.dag.entryAfter ["writeBoundary"] ''
    CLAUDE_CONFIG="$HOME/.claude.json"

    if [ ! -f "$CLAUDE_CONFIG" ]; then
      echo '{}' > "$CLAUDE_CONFIG"
    fi

    if [ -f "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh" ]; then
      source "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
    fi

    MCP_CONFIG=$(echo '${mcpConfigJson}' | ${pkgs.gnused}/bin/sed \
      -e "s|\$PLAYWRIGHT_BROWSERS_PATH|$PLAYWRIGHT_BROWSERS_PATH|g" \
      -e "s|\$HOME|$HOME|g" \
      -e "s|\$PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH|$PLAYWRIGHT_BROWSERS_PATH/chromium-1181/chrome-linux/chrome|g")

    ${pkgs.jq}/bin/jq --argjson mcpServers "$MCP_CONFIG" \
      '.mcpServers = $mcpServers' \
      "$CLAUDE_CONFIG" > "$CLAUDE_CONFIG.tmp" && \
    mv "$CLAUDE_CONFIG.tmp" "$CLAUDE_CONFIG"

    $VERBOSE_ECHO "Claude Code Playwright MCP configuration updated"
  '';
}

Step 4: Import the module

In your home-manager/home.nix, add to the imports list:

{
  imports = [
    ./programs/claude-code.nix
  ];
}

Step 5: Apply the configuration

home-manager switch --flake .#your-user@your-hostname

Restart Claude Code completely to pick up the new MCP configuration.

How It Works

1. Declarative Configuration: MCP server settings are defined in Nix and automatically applied on every home-manager switch
2. Dynamic Path Resolution: The activation script sources environment variables and expands them at runtime
3. Non-destructive Updates: Uses jq to merge only the mcpServers section, preserving all other Claude Code settings
4. Executable Path Override: --executable-path bypasses Playwright’s browser detection
5. Writable Profile Directory: PWMCP_PROFILES_DIR_FOR_TEST redirects browser profiles to a writable location

Verification

After configuration:

# Check MCP server status
claude mcp list

# Check configuration
cat ~/.claude.json | jq '.mcpServers.playwright'

# Check environment variables
echo $PLAYWRIGHT_BROWSERS_PATH

# Verify browser exists
ls -la $PLAYWRIGHT_BROWSERS_PATH/chromium-1181/chrome-linux/chrome

Test in Claude Code:

Navigate to example.com and tell me what you see

Key Insights

Why --executable-path is Required

Setting PLAYWRIGHT_BROWSERS_PATH alone isn’t enough because Playwright MCP uses its own browser detection mechanism. By providing --executable-path, we bypass this check entirely and tell Playwright exactly where the browser binary is.

Why the Activation Script Sources Environment Variables

The activation script runs during home-manager switch, before the new environment variables are fully exported to the shell. By explicitly sourcing hm-session-vars.sh, we ensure PLAYWRIGHT_BROWSERS_PATH is available for path expansion.

The NixOS ENOENT/EACCES Issue

Playwright MCP tries to create user data directories inside the browsers directory by default. On NixOS, this fails because /nix/store is read-only. The workaround is setting PWMCP_PROFILES_DIR_FOR_TEST to point to a writable location.

Benefits

• ✅ Survives System Updates: Configuration is declarative and automatically reapplied
• ✅ No Manual Browser Installation: Browsers are provided by Nix
• ✅ Reproducible: Same configuration works across different NixOS machines
• ✅ Version Controlled: MCP configuration is part of your nix-config repository
• ✅ Non-destructive: Preserves Claude Code’s self-managed settings

Troubleshooting

“Browser specified in your config is not installed”

• Verify PLAYWRIGHT_BROWSERS_PATH is set: echo $PLAYWRIGHT_BROWSERS_PATH
• Check the browser exists: ls -la $PLAYWRIGHT_BROWSERS_PATH/chromium-1181/chrome-linux/chrome
• Ensure you’ve restarted Claude Code after applying configuration
• Verify the --executable-path argument is in ~/.claude.json

“ENOENT: no such file or directory, mkdir ‘/nix/store/…’”

• Ensure PWMCP_PROFILES_DIR_FOR_TEST is set in the environment variables
• Check that ~/.local/share/playwright-mcp/profiles directory exists and is writable

Browser version mismatch

The hardcoded chromium-1181 in the executable path may need updating when Playwright versions change:

ls -la $PLAYWRIGHT_BROWSERS_PATH/ | grep chromium

Update the version number in claude-code.nix accordingly.

Resources

• NixOS nixpkgs Issue #443704
• Playwright MCP Issue #105
• playwright-web-flake
• Claude Code Documentation

Tested with: Claude Code, Playwright MCP 0.0.42, NixOS unstable