Right now, that something is a 3D printer.

A few months ago, TRELLIS 2 made it worse. Microsoft dropped a 4 billion parameter model that takes a single image and spits out a fully textured 3D asset in seconds.

I watched the demo, raised an eyebrow, and quietly moved the 3D printer a little higher on my wishlist.

Then this week I did something dumber and more interesting.

I gave Claude a photo of my desk and asked it to build a 3D model in Blender via MCP.

Not perfect. But it rendered.

One thing worth mentioning for anyone trying this: if Claude and Blender are on separate machines, MCP’s default stdio won’t cut it. Switch to http and expose it over your local network.

Here is the thing about the 3D printer sitting in my wishlist for years: the barrier was never the money. It was the time. Learning 3D modeling always felt like a full commitment I could not justify. TRELLIS showed me the ceiling of what AI can do here. Blender MCP gave me something more valuable: a starting point I could actually own.

That distinction matters. One does the work for you. The other teaches you how the work gets done.

AI is not here to kill the skill. It is here to hand you the door. You still have to walk through it.

Anyway. Now I know what no-code CEOs felt shipping their first website.

The 3D printer is getting closer ;)

Two years ago, I was talking with Thejpal Ramannagri about memory in AI systems. The argument was simple: long-term memory is not something a user should be managing. The agent should own it, evolve it, and improve it without prompting. Today, Hermes Agent is gaining traction almost entirely because of this self-improving memory layer. The idea was not novel because it was clever. It was obvious if you were thinking about what agents actually needed to be useful.

Around the same time, Yash Makkar wanted to build a tool that turned codebases into visual graphs for developer onboarding. While discussing Hybrid GraphRAG with Neo4j, we landed on something important: codebase data is semi-structured. An LLM processing an entire codebase into a knowledge base is expensive and often unnecessary. Agents navigating files through search, grep, and glob patterns are cheaper and more accurate for discovery tasks. Claude Code ships exactly this behaviour. Not a coincidence. Just physics.

👋 Early versions of Claude Code used RAG + a local vector db, but we found pretty quickly that agentic search generally works better. It is also simpler and doesn’t have the same issues around security, privacy, staleness, and reliability.

— Boris Cherny (@bcherny) February 1, 2026

These two patterns share a common thread: the real unlock was not a better model. It was a better understanding of the problem’s shape.

Which brings me to what I think is the next big one.

The benchmark treadmill

Right now, the AI discourse is stuck in a loop. A new model drops. A new benchmark is cited. Social media fills up with capability demonstrations. Repeat.

Nobody is talking about cost per value. OpenClaw, for instance, is doing genuinely interesting work with integrations, but the conversation around it stays focused on what it can do rather than what it costs to do it in production. Nobody is publishing what their agent actually costs to run versus what it is returning. Yes, AI is advancing at a remarkable pace. But for the majority of businesses that are not top-dollar firms with dedicated AI budgets, the unglamorous questions of cost, reliability, and fit are still the ones that determine adoption. The capability gap is shrinking. The integration gap is not.

The actual moat is distribution

Every major SaaS product right now is bolting AI onto its existing ecosystem. Most are gating it behind a higher tier or a separate membership. This is rational short-term pricing behaviour. It is a long-term adoption trap.

Users do not want another tool. They want their existing tools to get smarter. Look at what Anthropic is doing with Claude: rather than building a monolithic suite, they are taking integrations one at a time. Excel, PowerPoint, and now reportedly Blender. Each integration is a new reason for a different user segment to stay. n8n tells the same story from a different angle. It became popular not because it was the most powerful automation tool, but because it became a bridge. Any tool with an API could talk to any other tool. The product did not replace your stack. It connected it. That is why it spread.

The products that win will be the ones that integrate horizontally across the workflows users already live in, not the ones selling a new suite they have to migrate to. An AI that lives inside Slack, reads your Notion, checks your calendar, and acts on your behalf without requiring you to open a new tab is not just more convenient. It is structurally stickier. The integration is the lock-in. Not the model. Not the interface.

This is why distribution wins. A good-enough model with excellent integrations beats an excellent model with no integrations, every time.

Harness engineering is the name for what this requires

Sources:

• @akshay_pachaar via X
• Vivek Trivedy via Langchain

The industry has recently started using the term “harness engineering” to describe the discipline of building the systems around an AI model: the constraints, the feedback loops, the integrations, the context pipelines. The model is the horse. The harness is everything that makes it go where you need it to go.

This framing correctly relocates the engineering challenge. Think of it this way: the model is the CPU, the harness is the operating system, and the agent is the application. Nobody buys a computer for the CPU alone. The OS is what makes it useful, and the applications are what make it irreplaceable.

Most agent failures in production are not model failures. They are harness failures: broken state management, missing context, tools that do not connect to the right systems. The bottleneck was never the intelligence. It was the infrastructure around it.

Models are becoming interchangeable faster than anyone predicted. The harness is not. And the most defensible part of any harness will be its integrations, how deeply it is woven into the workflows and data sources that users already depend on.

The teams that figure this out first will not just have better products. They will have products that are genuinely hard to replace.

That is the moat. Not the benchmark. Not the context window. The connections.

The last post about Luna ended with a known problem: one sentence, two agents, one dropped task. The router picked a lane and stayed in it. Luna v2 fixes that.

It is live. Here is what changed.

The New Architecture

The single match statement is gone. In its place: an orchestrator and a set of worker agents.

The orchestrator receives every message, understands intent, and decides who handles it. Workers get invoked in one of two modes:

• Ask - the worker executes and reports back to the orchestrator, which synthesises a final response.
• Delegate - the worker responds directly to the user. No round-trip.

The distinction matters. A task that spans Notion and Google Calendar goes through Ask mode; both agents run, the orchestrator assembles the result. A quick Q&A gets delegated immediately. The right tool for the right depth of task.

This is what LangGraph was always capable of. The v1 graph just did not use it.

A note on latency. Luna is an ambient agent. Fire a request and move on. The priority has always been task completion at minimum cost, not response speed. With that context, the numbers are fine: basic responses around 1.5 seconds, delegated tasks like a calendar query around 4 seconds. There is a well-known trilemma in AI-systems design: performance, cost, and speed. Pick two. This stack is optimized for the first two. Speed is acceptable collateral.

Feedback Is Now a Tool

There was a quiet failure mode in v1 that kept showing up in the logs.

Feedback - thumbs up, thumbs down, corrections, was handled by regex matching. Specific phrases triggered specific logic. It was brittle in exactly the way you would expect from brittle logic: the moment ASR transcribed something slightly off, the match failed and the feedback went nowhere.

The fix was to stop treating feedback as a parsing problem and start treating it as an agent capability. The orchestrator now has a dedicated feedback tool it can call when it detects a correction or rating signal, regardless of exact phrasing. Speech-to-text imperfections become the model’s problem to interpret, not the code’s problem to match.

Fewer silent failures. More reliable feedback loop.

Wispr Flow and the Invisible Interface

Wispr Flow has been taking off lately, and it is worth calling out in this context.

I have been using it heavily across work, writing, and talking to Luna. Going back to typing feels like a downgrade at this point. Speaking is faster, more natural, and closer to how you actually think.

The premise of Luna has always been voice as the primary interface. Wispr Flow gaining this much traction right now is a signal that the broader market is arriving at the same conclusion.

The roadmap writes itself from here. If voice-first tools are breaking out, local ASR is going to get significantly better. Google and Apple are not going to sit this one out. On-device speech recognition will get smarter, faster, and more context-aware. Luna is already built for a world where that is true.

Slack as a Second Channel

Luna now lives in Slack.

Two reasons this happened:

• First, I started using Slack seriously and immediately saw the overlap. Luna already knows my Notion workspace, my calendar, my tasks. Having that available in the context where I am already thinking about work is not a nice-to-have, it is the right place for it. Tag Luna in a channel, ask a question, get something done. Same brain, new door.

• Second, observability. LangSmith handles full traces. But I do not always want to open LangSmith. Sometimes I just want to see what the agent is doing in the background - which tools it called, what it decided, where it went. I am considering writing selective log messages directly to a Slack channel. I control what gets logged. It is a lightweight window into agent behaviour without the overhead of pulling up a full trace.

Luna inside Slack channels is still being tested. Notion queries and calendar lookups are working. More to follow.

One Brain, Three Voices

WhatsApp is the next channel on the list. But adding interfaces is no longer just a routing problem, it is a formatting problem.

Think about it. The iOS shortcut speaks its response out loud. A bullet point in a TTS response sounds like someone reading a list at you. An asterisk sounds like nothing at all. That interface needs plain prose: conversational, natural, the kind of language you would use speaking to someone, not presenting to them.

WhatsApp is different. It is a screen. Line breaks, spacing, maybe a little structure, all of that renders and helps. Slack goes further: work context, larger screen real estate, richer formatting is appropriate and expected.

Same response. Three different contracts for how it gets delivered.

Luna will eventually need to be aware of which channel it is speaking into and shape its output accordingly. Not just what to say, but how to say it. That is the next layer of work before new interfaces get added casually.

Same brain. But different voices for different rooms.

What Is Next

WhatsApp is in progress. The n8n automation layer is next in line. And before any of that ships cleanly, the channel-aware response formatting above has to be solved. You do not want Luna reading markdown bullet points into your AirPods.

The architecture is ready. The voice has to catch up.

There’s a repo on GitHub right now with 14,000 stars, a gorgeous README, and code that hasn’t had a meaningful commit in eight months. You’ve probably starred something like it. So have I.

We all know what a GitHub star actually means in 2026: someone thought a project looked cool for thirty seconds. Maybe they were procrastinating. Maybe it showed up on Hacker News. Maybe someone in a San Francisco office spent $200 to make it look like traction before a seed round. Nobody says that last part out loud.

The game everyone’s playing

Here’s how the SF open-source playbook works right now, and it’s barely a secret.

You build a tool. You write a beautiful README with a snappy GIF. You post it to every subreddit, every Discord, every corner of the internet simultaneously. You call it a “day one launch.” Then an AI influencer with 200k followers on X quote-tweets it with “this is going to be HUGE 🚀” without having run a single line of it. Three more influencers repost that. Stars pour in. If you’re playing the game seriously, you might top it off with a few hundred purchased ones, because VC firms have literal scrapers watching star velocity, and Runa Capital publishes a quarterly ranking of open-source startups sorted almost entirely by 90-day star growth. Sixty-eight percent of those ranked companies subsequently raised funding.

You can buy 1,000 stars for around $64. Providers are easy to find: prices run from $0.10 to $2.00 per star, delivery in hours, no login required. Against a $2M seed round, that math writes itself.

The part that makes it funny, in a bleak way: a peer-reviewed paper presented at ICSE 2026 by researchers at CMU, NC State, and Socket scanned 20 terabytes of GitHub data and found roughly six million suspected fake stars across 18,617 repositories. AI and LLM repos are now the single largest non-malicious category of recipients. GitHub’s response has mostly been to quietly delete the flagged repos after someone else does the detective work.

The actual product is the README

Stars don’t just get bought. They get gamed organically too, in a way that’s arguably worse.

OpenClaw went from 9,000 to 60,000 stars in a few days in January 2026, then blew past 210,000. Legitimately impressive. But it also set the benchmark everyone else is now trying to fake. The week it peaked, a dozen “autonomous agent frameworks” launched with nearly identical READMEs, riding the same wave of AI influencer reposts. Most were a for loop and some string formatting. A few bought stars to close the gap.

Here’s the part the paper confirms that most people don’t know: it doesn’t even work. The CMU study found that fake stars produce a small bump in organic attention for at most two months, then become a net negative. Real users can smell something off. The lockstep patterns, hundreds of accounts starring the same repo in the same 30-day window with no other activity, register as a trust penalty once the algorithm catches up.

Stars measure whether something looked impressive during a 3-minute scroll. They have almost no correlation with whether the code works, whether it’s maintained, or whether anyone actually runs it in production.

The engineers who’ve been building quietly for ten years know this. The maintainer of SocketCluster put it plainly after watching his 6,000 legitimately-earned stars become meaningless:

“It sucks having put in the effort and seeing it get lost in a sea of scams and seeing people doubting my project’s own authenticity.”

Nobody’s stopping

The honest answer is that the game continues because everyone’s playing it and nobody wants to be the one who stops first.

VCs keep using stars as a lazy proxy for developer love because it’s a number that fits in a spreadsheet. Founders keep optimising for stars because that’s what gets VC meetings. AI influencers keep boosting every shiny new repo because engagement is engagement and nobody checks back in six months when the repo is abandoned. Developers keep using stars as a trust signal when picking dependencies because who has time to read the actual source.

And the end of that chain is darker than most people realise. The CMU paper found one repo with 111 stars, 109 of them fake, presenting as a Solana trading bot. Hidden inside: a spawn() call quietly executing a remote obfuscated script that drained wallets. That’s where the Stargazers Ghost Network went, 3,000 coordinated bot accounts selling fake stars as a distribution channel for malware, because a starred repo looks trustworthy enough to clone.

The people proposing fixes, like fork-to-star ratios, contributor counts, download telemetry, and OpenSSF scorecards, are correct and will largely be ignored. The fix requires effort. The game only requires a credit card.

The GitHub star is not dead. It just means something different now. It means someone wanted you to think a project was popular. Whether it actually is, that part’s still on you to figure out.

Code was a medium. Not the product. Not the craft. The medium.

The machine does not admire your naming conventions. It does not appreciate the abstraction layer. It executes. And yet, somewhere along the way, we convinced ourselves that the writing of code was the point, rather than a means to one.

Jensen Huang said it plainly: “The purpose of a software engineer is to solve known problems and find new ones. Coding is one of the tasks.”

Some engineers bristled. They heard the wrong thing. He was not diminishing code. He was correctly categorizing it.

The tax you paid to ship

The gap between what I want done and code that does it was always the job. The outcome was the job. Code was the tax you paid to get there.

Agentic tools have not automated programming. They have made the tax cheaper. You describe the outcome; the agent drafts the filing. You review it.

That is a more honest relationship with the medium. And honesty, it turns out, is uncomfortable for an industry that built its professional identity around paying that tax with elegance.

Clean code was written for humans

Every quality metric we use, readability, DRY principles, abstraction clarity, was designed for one human to hand code to another.

But agents are now both writing and reading code. And an agent does not need your comments. It does not benefit from your nested abstractions. It works better with less surface area to misread.

The conventions we treat as gospel were built for a consumer that is no longer the only one in the room.

This does not mean clean code is dead. It means the definition is overdue for an update. A codebase optimized for agent-assisted workflows might look leaner, flatter, and more annotated in markdown than in inline comments. Documentation moves out of the code and into context files that actively shape how the agent writes and extends the repo.

That is a different kind of craft. Not a lesser one.

The repository is becoming a hybrid artifact

The codebases of the next five years will carry as much prose as logic. Not documentation trailing six months behind the code, but living context that instructs the agents maintaining it.

CLAUDE.md. AGENTS.md. Architecture decision records written not for your future colleague, but for the model that will touch the code before they do.

The source code is for the machine. The markdown is for the agent. The agent does the translation.

Which raises a question worth sitting with: if the most valuable part of a modern repository is its surrounding context, what does that mean for how we evaluate engineering work? We have metrics for code coverage, complexity, and performance. We have almost nothing for the quality of the prose that now shapes how that code gets built.

We built the vault before we knew what we were preserving

In 2020, GitHub ran the Arctic Code Vault campaign, buried a snapshot of public repositories in a coal mine in Svalbard, Norway. A time capsule meant to last a thousand years. At the time it felt like a stunt.

It looks different now. A codebase stripped of its context files is code without an operating manual. The logic is there. The intent is not.

Future developers, human or otherwise, will not just need the source. They will need the surrounding layer of decisions, constraints, and instructions that gave it shape.

Code was always a means to an end. The agent era did not change that. It just made it impossible to pretend otherwise.

The question now is not whether your code is clean. It is whether your thinking is.

If you’ve watched Suits, you already get it. (incase you’re uncultured)

I wanted that. Something omnipresent, anticipatory, works across every context. I called it Luna instead of The Donna because the vision was never just one interface. A shortcut, a WhatsApp message, a Slack command, an n8n automation. Same brain, different doors.

The last post covered the front door: an iOS shortcut on my lock screen, one tap, voice memo fired into a backend. This post is about what is behind that door, what it actually runs on, and why I am rebuilding it before adding anything new.

The Architecture (Right Now)

Luna is a LangGraph multi-agent system. Every message comes in, gets loaded with chat history from Redis, and hits a router. The router classifies intent and fires to one of four agents:

• Notion agent: reads and writes to my workspace. Tasks, projects, fitness logs, notes.
• Calendar agent (Donna): manages Google Calendar. Scheduling, busy slots, edits, removals.
• Fitness tracker (Rocky): dedicated logging agent for workouts and activity.
• General agent: everything else. Q&A, quick lookups, conversations.

Each agent runs its tools, returns a response, and the result gets pushed back to Redis with the updated conversation history. Clean, stateless agents. Stateful conversations.

The observability and feedback loops are taken care of via Langsmith (more about this, in a later post).

That is the current version. It works. And it has one problem.

Where It Breaks

Say you tell Luna: “Add a task to check out Wan2.2 and block two hours for it on Friday, after work.”

One sentence. Two agents. Right now the router picks one and sends it there. The Notion agent creates the task. The calendar block never happens. Or vice versa.

The routing is a single match statement. One task, one destination. No mechanism for agents to talk to each other, no fan-out for overlapping intent, no synthesis layer for dual-delegation.

Usage data made this obvious. It kept showing up in the logs. Luna v2 fixes this: the router identifies multi-agent tasks, dispatches to multiple nodes in parallel, and synthesizes a single response. LangGraph supports it. The current graph just does not use it yet.

The Underdog Stack

Luna runs on a repurposed college laptop. Ubuntu, homelab, Cloudflare Tunnel. Infrastructure cost: electricity. API cost: close to zero.

Groq runs three jobs. Whisper handles transcription. The router uses gpt-oss-20b with structured output and strict mode for fast, reliable intent classification. The lightweight agents (general Q&A, calendar, fitness) also run on gpt-oss-120b. Fast enough to feel instant. Free tier covers everything at personal usage volumes.

GLM-4.5 Air by Z-AI handles the heavy Notion agent. Ten tools, full datasource context, real read-write operations against my workspace. Purpose-built for agentic applications, MoE architecture, 131K context window, and a thinking/non-thinking toggle depending on whether the flow needs reasoning or just speed. Reasoning is explicitly turned off in the Notion agent config. For tool-calling flows you want decisiveness, not deliberation. A Chinese lab’s open-source model is running the most critical part of this system for free. That is worth saying out loud.

Before GLM-4.5 Air, this slot was Step 3.5 Flash by StepFun (really slept on, in my opinion). 196 billion total parameters with only 11 billion active per token via sparse MoE. Multi-Token Prediction generating 4 tokens per forward pass, hitting 100 to 300 tokens per second in typical usage. It reasoned like a large model and moved like a small one. The free tier on OpenRouter dried up last month. GLM stepped in and has not missed a beat.

Both of these models come from labs that do not get the coverage they deserve. If you are building anything agentic and have not looked at either of them, you should.

Four OpenRouter API keys rotate automatically via a KeyRotator. When one hits a rate limit, the next one picks up. Rate limits per key become irrelevant at personal usage volumes.

Gemini sits at the bottom via ModelFallbackMiddleware. GLM fails, Gemini catches it. Gemini fails, Groq catches it. Three layers of free inference before a single rupee gets spent.

This is not cheapness. It is a deliberate tiered inference strategy. Fast model for routing, capable free model for heavy tool use, two fallback layers below it.

We call that the finest form of Jugaad

What Is Next

Luna v2 is the immediate priority: rewire tools, multi-agent dispatch, inter-agent communication, proper handling of tasks that span multiple domains.

After that: a WhatsApp interface already in progress, then Slack, then the n8n automation layer expanding significantly. Same brain. More doors.

The shortcut was always the starting point. The architecture has to be built for omnipresence before any new interface gets added.

The brain comes first. The ears come later.

Louis Litt carried a Dictaphone everywhere. Barked memos into it mid-stride, never broke his pace, never got distracted. It always seemed a little ridiculous.

I get it now.

Every habit tracker fails the same way.

Not because it’s badly built. Because it requires you to open it. You finish a workout, tell yourself you’ll log it later, and later never comes. The app becomes a graveyard of good intentions. The data gap is not a discipline problem. It’s a friction problem.

This is what I was trying to solve with Luna.

What Luna actually does (the short version)

Luna is my personal AI assistant: a LangGraph multi-agent system and n8n automation flows, all running on my homelab, wired into my Notion workspace and Google Calendar (for now). One name, one interface, for everything.

This post is about the front door: an iPhone Shortcut.

The constraint that made the decision easy

Luna runs on my homelab, exposed to the outside world via a Cloudflare Tunnel. That means REST API: clean, simple, battle-tested. What it doesn’t give me is a persistent duplex connection. WebSocket is off the table for now. So a native app with any kind of real-time feel would’ve been more work for a worse result. Shortcuts talking to a REST endpoint is the honest architecture for the setup I have.

I’ll build a proper app when it makes sense. Right now, it doesn’t.

Two shortcuts, one idea

There are two shortcuts doing the work.

The first lives on my lock screen and in the notification center. One tap. It records my voice, sends the audio to Groq’s Whisper API for transcription, and fires the text to Luna’s backend. I never unlock the phone. I never see a feed. The job is done before the algorithm gets a chance.

The second is called “Ask Luna”, completely hands-free. Say “Hey Siri, Ask Luna” and it runs. This one uses on-device ASR instead of Whisper, so the accuracy isn’t as sharp, but it works well enough when I’m driving or my hands are full.

A Dictaphone. With a backend.

The actual problem it solves

Think about every app that asks you to manually enter information: fitness logs, food diaries, task managers, journals. The input step is where they all die. By the time you’ve unlocked your phone, navigated to the right screen, and tapped into a text field, you’re already two notifications deep into something else.

Voice-to-lock-screen cuts all of that out. I finish a set, tap once, say “12 pull-ups, ate clean today,” and move on. That goes into my Notion Fitness Tracker. No app open, no feed in my peripheral vision, no “I’ll do it later.”

Same for tasks: “Add a note to read Hackers and Painters by Paul Graham” lands in my Hobby Projects board. Scheduling requests go to Donna, my calendar agent. Luna routes everything.

Luna isn’t a chatbot

This is worth saying clearly: Luna isn’t designed for conversation. The priority is to get things done, not generate replies.

When I log a workout, I don’t need an acknowledgement. When I create a task, I don’t need it read back to me. The shortcut fires, the agent acts, and my phone reads the response back to me via TTS when there’s something worth saying. Most interactions are still fire-and-forget, Luna confirms a task was logged, tells me my next meeting, answers a question. No screen required. The async model isn’t a limitation. It’s the point.

Why Not a Wearable

A quick detour because why reinvent the wheel.

• Neo Sapien is an Indian startup doing interesting work here. Reached out to the founder directly. Hardware was not coming my way, and the device is closed source. Even if I ordered one, there is no path to wiring it to your own backend. Hard pass.

• OMI is open source, hackable, and developer-friendly. The problem is battery. Transcription and active task processing drain it fast, which means you are charging a wearable you are supposed to be wearing. That defeats the point.

• Pebble Ring is the closest fit. Push-to-talk, not always-listening, completely unobtrusive. The only catch: non-rechargeable. Disposable after roughly a year and a half to two years. A strange trade-off for a device this promising. Top contender. Not yet.

The shortcut wins by elimination for now. Not the dream interface. The honest one.

What’s next

The next post covers the backend: how I’m running a full multi-agent system at near-zero cost by distributing across LLM providers. Groq for routing, OpenRouter with round-robin key rotation for agents, Gemini as fallback. Plus caching, tool calls, and the feedback loop I’m using to improve Luna over time.

The shortcut is intentionally dumb. The backend is where it gets interesting.

It started with an old college laptop. Ubuntu went on it, and suddenly I had a server. The NAS idea followed shortly after, as it always does.

I had a 4TB portable drive but didn’t want it permanently attached. Then one afternoon I walked past some discarded junk and spotted an old CCTV DVR. Cracked it open, found a healthy 1TB HDD inside. Formatted it, set up LUKS encryption, and called it my primary storage. Free of charge.

With storage sorted, I set up Immich, paired with Tailscale and Cloudflare Tunnels, gated behind Google OAuth. Google Photos, evicted. Migrated ~320GB going back to 2015: old phones, Snapchat memories (had to), scanned family prints, and VHS tapes I recorded using OBS Studio.

My parents’ wedding. My grandparents visiting family in the US, from an era when home video was a rare luxury. Black-and-white pictures of ancestors I never met. Things that don’t exist twice.

The 4TB drive handled off-server backups via Syncthing. Last week, it died. Syncthing had already done its job, everything safe. Now I’m shopping for an NVMe in this economy. Prayers welcome.

Next: once backup is properly sorted (3-2-1 rule), I’m onboarding family so they can contribute their own photos and media. A shared family archive, self-hosted, no middleman.

Open source did the heavy lifting. The dumpster did the rest.

Oh, and the server does a lot more than store memories, but that’s a story for another day.

Tools that made this possible at near-zero cost:

• Immich
• Cloudflare
• Tailscale
• Syncthing

I was walking Murphy, my dog, when it hit me.

I’m a developer. I don’t want to engineer my blog. Markdown is already my first language. Turns out it’s an LLM’s too. And that’s when I thought, why not also write this blog in markdown?

I got home and googled it. Apparently Jekyll, GitHub Pages, and half the internet had already figured this out. Andrej Karpathy even has a name for it: LLM Wiki. A person who could use anything, chose a folder of .md files. That’s not laziness. That’s a signal.

LLM Knowledge Bases

Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…

— Andrej Karpathy (@karpathy) April 2, 2026

Because here’s the thing: markdown wasn’t designed to be the language of AI. It just turned out to be the language that humans and machines both happen to speak. The first format in history that was built for thinking, and accidentally became perfect for reasoning.

Turns out I’m not a genius. I’m just predictable.

The thing that actually sealed it for me was a Reddit thread. Someone asking how to publish Obsidian notes for free. The top answer was exactly right.

It was posted by Obsidian’s CEO.

He showed up in a subreddit to personally help a user avoid paying for his own product. I don’t know, that just did something for me.

This blog is the result of that dog walk. I build things in the open. Might as well write about them the same way. Written in Obsidian, rendered by Jekyll, hosted on GitHub Pages, tracked by Google Analytics. Completely free.

Oh, and one more thing. I didn’t really write this post. I talked it into existence and let a machine find the shape. Maybe that’s the whole point.