AB's Reflections

Category: Tips

  • What it takes to actually run NanoClaw

    NanoClaw is the structurally right framework for pipeline-shaped agent workloads. It’s also genuinely more technical to set up than most personal-assistant frameworks people compare it to. If you’re evaluating it after reading the comparison piece and wondering what you’re signing up for, this is the honest answer.

    One thing worth setting up front: NanoClaw is not built for non-technical users, and neither is openclaw despite its more polished onboarding. The marketing on both sites pitches “personal AI assistant for everyone.” The reality is different. NanoClaw expects comfort with git, the command line, Docker, and at least basic Linux administration. The trade you make in exchange is access to Claude Code as the authoring layer for your fork — which is arguably the most capable AI coding tool available right now, and meaningfully more capable than the typical models you’d be running underneath openclaw. The framework is built around that capability difference rather than trying to abstract it away.

    The architecture is right. The setup curve is real. Below is what actually bites.

    You need a Claude Code subscription

    This isn’t a soft dependency. NanoClaw is built around Claude Code as the authoring layer — the slash commands that install channels and providers (/add-telegram, /add-opencode, /add-codex and so on) run inside Claude Code and copy source files into your fork from long-lived branches. You can technically edit the same files by hand, but you’d be reverse-engineering what those slash commands do every time you customise.

    Practically: a Claude Code Pro or Max subscription is the working assumption. Without it, you’re not really running NanoClaw the way it’s designed to run. With it, the authoring experience is the best part of the framework — the codebase is small enough that Claude Code can confidently make changes across it, and the fork-as-install model means every customization is a code change you can read and revert.

    This also constrains who NanoClaw is for. If you’re allergic to Claude Code (philosophically, financially, or because you prefer Codex or another harness as your primary), you’ll fight the framework. If you’re already deep in Claude Code, the integration is genuinely tight.

    Codex works as a fallback authoring layer for individual tasks, and the /add-codex skill makes Codex available as an agent provider (separate from authoring). But the slash-command-based setup expects Claude Code as the primary harness. Plan around that.

    OneCLI is part of the deal

    NanoClaw doesn’t manage your API keys directly. That job is delegated to OneCLI, the companion credential proxy that ships alongside it. Agents inside containers never see raw API keys; they make outbound HTTPS requests through OneCLI, which injects credentials at the proxy layer based on per-agent policies.

    This matters in practice for two reasons. First, agents inside NanoClaw containers have bash access — anything that put an API key directly in the container would be reachable by any code the agent runs. OneCLI keeps that surface clean. Second, you’ll spend real time during setup configuring OneCLI: registering your Anthropic credential, creating per-agent secret assignments, deciding whether each agent gets all secrets or a specific subset. The nanoclaw.sh install script handles the basics, but ongoing changes (adding a new provider, rotating keys, scoping a credential to one agent) involve OneCLI commands rather than editing config files.

    It’s worth understanding before you start. Treat OneCLI as a meaningful piece of the system, not a one-time setup chore that disappears after install.

    There’s no web UI out of the box

    NanoClaw ships the channel and agent runtime. It doesn’t ship an operator console. There’s no dashboard for browsing agent activity, no log viewer, no chat history UI, no admin panel, no menubar app. The framework’s stance is that you talk to your agent through a messaging channel — Telegram, Slack, Discord, WhatsApp, whatever you’ve installed — and that’s the interface.

    Openclaw, by comparison, has a guided openclaw onboard CLI for setup and a Companion App (Beta) on macOS that adds a menubar interface. So if you’re coming from openclaw expecting some kind of UI affordance out of the box, NanoClaw will feel deliberately bare.

    For an assistant, the chat-channel-only approach is fine. The channel is the interface.

    For a pipeline, it’s not enough. Pipelines need state-of-everything views: which prospects are in which stages, which agents are working on what, what’s pending operator review, what’s been dead-lettered. None of that is conversational. You need a UI.

    The options are real but each has a cost:

    Build a custom web UI as a NanoClaw skill. A small Express or similar server inside a skill that exposes a chat-plus-dashboard interface, talks to the agent through the same task contract NanoClaw uses elsewhere, and serves over tailscale serve so it’s only reachable on your tailnet. Takes a day to build. You control the UX completely. You can mount per-agent dashboards next to the chat thread. No third party between you and your operator interface. This is the version I keep coming back to.

    Use a messaging channel as the operator interface. Telegram is fastest to bring up — bot via BotFather, token in five minutes. Discord and Slack work too. The trade is that pipeline state is awkward to display in a chat thread, and you end up either composing structured messages (clunky) or building dashboards anyway (defeats the purpose).

    Lean on the underlying systems for state visibility. SQLite for the artifact and journal storage means you can run ad-hoc queries against it. docker logs for container-level activity. journalctl --user for systemd-level service logs. This works for debugging and post-hoc analysis. It doesn’t work as a real-time operator surface.

    In practice, you’ll mix all three. The custom web UI is the primary operator console, channels handle quick-access from your phone, and you use the underlying tooling when something goes weird and you need to dig.

    Setup gotchas on a small VPS

    NanoClaw runs comfortably on a 2GB DigitalOcean droplet (or equivalent). The hosting cost is a few dollars a month. The friction comes from minimal cloud images being stripped down enough that several setup steps fail in non-obvious ways.

    The base image doesn’t ship with a C compiler. Several modules in the dependency tree build native bindings during pnpm install and fail with generic “command failed” errors that don’t tell you the compiler is missing. Install build tools before the first install:

    sudo apt update
    sudo apt install -y build-essential acl

    The acl package is also missing from minimal images and you’ll need it for the Docker socket fix below.

    The Docker socket ACL doesn’t survive reboot. NanoClaw runs agent containers via Docker. By default, only root can talk to the Docker socket. Adding your operator user to the docker group works but is broadly equivalent to giving that user root, which is not what you want.

    The cleaner approach is an ACL grant on /var/run/docker.sock. The catch: /var/run is a tmpfs mount, recreated on every boot. Anything you setfacl once is wiped on reboot. The fix is a tmpfiles.d rule that recreates the ACL automatically. Create /etc/tmpfiles.d/docker.conf with:

    a+ /var/run/docker.sock - - - - u:youruser:rw

    Replace youruser with the actual operator username. Test with sudo systemd-tmpfiles --create and verify with getfacl /var/run/docker.sock. Reboots no longer break Docker access for the operator account.

    Two systemd services, not one. Run NanoClaw and your custom orchestrator as separate systemd user services. When you’re iterating on the orchestrator (which you will, often, especially in early development), restarting it shouldn’t take the channel adapters down. Channel reconnects are slow and annoying; orchestrator restarts should be near-instant.

    A reasonable layout:

    ~/.config/systemd/user/nanoclaw.service
    ~/.config/systemd/user/orchestrator.service

    If you want either service to start on boot before you log in, enable lingering for the user with sudo loginctl enable-linger youruser. Easy to forget; non-obvious failure mode (services don’t start, you don’t know why, you log in, they magically work).

    Add swap. A 2GB droplet doesn’t ship with swap configured. Under heavy LLM-context loads — long-context windows plus large augmentation tasks — you can OOM unexpectedly. A 2GB swap file is cheap insurance:

    sudo fallocate -l 2G /swapfile
    sudo chmod 600 /swapfile
    sudo mkswap /swapfile
    sudo swapon /swapfile
    echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

    Set vm.swappiness=10 in /etc/sysctl.conf so the kernel prefers RAM and only swaps under genuine pressure. Reboot to verify.

    What stays on the laptop, what goes on the VPS

    The local-versus-VPS question resolves cleanly:

    • A laptop is fine for the install rehearsal, fork setup, and a couple of agents you only use while at the keyboard.
    • Anything that needs to be reachable, scheduled, or running while you’re not at the keyboard belongs on the VPS.

    The cost difference between 1GB and 2GB on DigitalOcean is a few dollars a month, and the difference in headroom is between fighting the host and forgetting about it. Take the 2GB. The marginal saving on a 1GB droplet is not worth the time you’ll spend wondering why builds are failing or why the agent container is OOM’ing.

    Honest scope of “easy”

    NanoClaw is technically simpler than openclaw — fewer lines of code, fewer abstractions, fewer hidden behaviours. It’s not operationally simpler. The framework expects you to:

    • Have a Claude Code subscription and use it as the authoring layer
    • Be comfortable with the Linux command line, systemd, Docker, git
    • Build your own operator UI if you want one
    • Write your own orchestrator if you’re doing pipeline-shaped work

    For someone who already operates in this stack, NanoClaw feels light and clean — and the Claude Code authoring layer is genuinely the best part. The codebase is small enough that asking Claude Code to make changes across it works reliably, which is a meaningfully better experience than the typical “edit config files, hope you got it right, debug when you didn’t” pattern.

    For someone hoping for a one-click personal assistant, the curve is meaningfully steeper than openclaw’s onboarding. Openclaw has a guided CLI (openclaw onboard) and a macOS Companion App that gives you a menubar interface; NanoClaw deliberately ships none of that. Both still expect a technical user underneath, but openclaw lowers the floor more.

    The trade is real and the trade is good if your use case justifies it. You end up with a system you understand end to end, that runs in resources you control, that doesn’t depend on a SaaS gateway, and that you can reason about when something breaks. Worth the lift if you’re building something pipeline-shaped. Not worth the lift if you just want a chatbot.

    A useful concrete reference point: Singapore’s Foreign Minister, Vivian Balakrishnan, published the architecture for his own NanoClaw-based “second brain” setup, with an accompanying X post walking through the composition. He’s technically literate — coding is a known hobby of his — but not a software engineer by trade. His setup composes NanoClaw with a few other open-source pieces (a memory layer, OneCLI for credentials, the LLM Wiki pattern for knowledge synthesis) and runs on a Raspberry Pi. It’s a useful existence proof of “technical-but-not-developer” being the floor for NanoClaw, and equally a useful caution: Vivian could compose those pieces because of fluency he already had. Anyone reading this without that fluency yet would need to pick it up first. The reward is real, and so is the prerequisite.

    The full GTM system this deployment serves is in Building a GTM dark factory with Nemotron 3 and NanoClaw. The framework comparison that motivates picking NanoClaw in the first place is in Why I picked NanoClaw over openclaw for a GTM pipeline.

  • Why I picked NanoClaw over OpenClaw for a GTM pipeline

    Before getting into the comparison itself, one piece of context worth setting straight: neither OpenClaw nor NanoClaw is built for a non-technical audience. Both expect comfort with the command line, git, and at least one model provider’s API setup. Both reward fluency with the underlying stack. The marketing copy on both sites pitches “personal AI assistant for everyone,” which is aspirational. The reality today is that you need to know what pnpm install does and roughly what a Docker container is to get either one running smoothly.

    That said, the two frameworks make different trade-offs within that technical-user space, and which trade-off is right for you depends on what you’re actually building.

    OpenClaw is the more monolithic, more featureful option. It ships a guided CLI onboarding (openclaw onboard), supports multiple LLM providers natively (Anthropic, OpenAI, local), has a Companion App for macOS that gives you a menubar interface, and includes browser control, persistent memory, and dozens of community-built skills out of the box. The trade is operational complexity — ~434,000 lines of code, 70+ dependencies, single Node process with shared memory — and a security model that relies on application-level checks rather than OS isolation. Recent CVEs and security writeups in this space have mostly been openclaw-shaped.

    NanoClaw is the lighter, more opinionated alternative. ~3,900 lines of code, fewer than 10 dependencies, agents in isolated Linux containers with explicit mounts, single host process orchestrating per-session containers. Credential handling is delegated to OneCLI (NanoClaw’s companion credential proxy), which injects API keys at request time so agents never hold raw secrets — meaningful when an agent has bash access inside its container. The trade is that NanoClaw is built natively around the Claude Agent SDK — Claude Code is the primary harness, the slash commands that install channels and providers run inside Claude Code, and other providers (Codex, OpenCode, Ollama) are drop-in alternatives rather than peers. There’s no menubar app, no built-in dashboard, no UI beyond the chat channels you’ve installed. The codebase is small enough that “ask Claude Code to walk you through it” is a realistic onboarding strategy.

    For a personal-assistant use case, the openclaw trade-off probably wins. More features out of the box, more flexibility on providers, easier to bring up if you’re not already deep in the Claude Code ecosystem. For a pipeline-shaped workload — GTM, document processing, anything where the workflow exists independent of conversation — NanoClaw is structurally a better fit, and Claude Code being the assumed harness is actually an advantage rather than a constraint, because Claude Code is arguably the most capable AI authoring tool available right now and the framework is built around it.

    I went through both before settling. Here’s the rest of the comparison through the pipeline-shape lens.

    The shape of the workload matters

    A personal assistant is reactive. You send it something. It figures out what you meant, picks a tool, runs the tool, replies. The workflow is whatever the conversation is.

    A pipeline is the opposite. There’s a state machine. There are stages. Each prospect, ticket, document, or whatever the unit is moves through stages on its own clock. Some get stuck. Some get rerouted. Some need to be remembered six months later when a specific signal lights up. The workflow exists independent of any conversation.

    These two workloads want different things from a framework. The assistant wants flexibility, channels, plug-and-play tools, an LLM that figures out what to do. The pipeline wants determinism between stages, deterministic routing, dry-run capability, an LLM that does bounded judgment work inside a stage.

    This is the lens that matters. Most framework comparisons are feature bake-offs. The actual question is which workload shape you’re building.

    Three things that didn’t survive OpenClaw for me

    Routing. Openclaw’s agent picks what to do based on the inbound and its own reasoning. That’s the right model for “summarise my inbox” and the wrong model for “transition prospect ABC from awaiting-reply to unresponsive after 14 days.” The second decision has to be deterministic, replayable, dry-runnable, and outside the LLM. Tool-call routing is fine when the cost of a wrong decision is small. In a GTM pipeline a wrong routing decision is a duplicate touch, a wrong segment, a compliance breach.

    You can wire OpenClaw to do deterministic routing — through skill conditions, scheduled triggers, scripted control flow — but you’re working against the framework’s grain. Every hour spent there is an hour reinventing what a state machine engine gives you for free.

    Per-skill model preference. Pipelines benefit from heterogeneity. Small fast models for bulk discovery and augmentation. Larger models for content polish. Different providers for redundancy. OpenClaw supports multiple LLM backends as a first-class feature — you can configure Anthropic, OpenAI, or local models — but the routing decisions are made within the agent’s own reasoning rather than at the framework level. For a pipeline you want the framework to route deterministically based on skill family, not let the agent pick its own provider per call.

    NanoClaw’s approach is the opposite: provider is configured per agent group, one provider per group, multiple groups in parallel. That maps directly to “discovery and augmentation in one group on Nemotron, polish in another group on Claude.” Per-task provider hints would be cleaner, but group-level routing is what works today, and for most pipelines it’s enough because the natural skill boundaries align with provider preferences anyway.

    Operating cost. OpenClaw runs a websocket gateway with constant background activity. mDNS service discovery, periodic health probes, channel reconnect loops. On a 1GB droplet it spent most of its capacity on its own metabolism. Bumping the VPS works, but the symptom is telling.

    NanoClaw is much quieter at idle. The host process owns message queues, agent containers spin up per task, channels are explicit and minimal. A 2GB droplet has plenty of headroom for a working pipeline plus orchestrator plus operator UI.

    What NanoClaw doesn’t do, and why that’s useful

    NanoClaw has no built-in orchestrator. No state machine engine. No artifact store. No journal writer. No skill dispatcher. No dry-run harness. No business logic of any kind.

    For an assistant, this is missing functionality. For a pipeline, it’s the right scope.

    The orchestrator is the part that’s specific to your workflow. State transitions, when to retry, when to dead-letter, what counts as completion, what triggers the next stage. Building it as plain code (in any language; mine is TypeScript) means it stays readable, testable, and replaceable. NanoClaw runs the channel adapters and the agent containers. The orchestrator runs the workflow. They talk through structured task contracts.

    The trade is real: you write more code to start. The benefit is real: you understand and own every line of the pipeline that matters.

    What both share

    The skills system. Both frameworks treat skills as SKILL.md markdown files that the agent reads and executes. The same skills can technically run on either framework with minor adjustments, though the agent configuration files differ — openclaw uses SOUL.md for agent personality and config, NanoClaw uses CLAUDE.md for the same purpose. So you’re not locked into a framework by your skills library — you’re picking the framework that runs them at the right architectural layer.

    Both also lean on Claude Code as a useful authoring layer, though the relationship is different. NanoClaw is explicit about it — the slash commands that install channels and providers run inside Claude Code and copy source files into your fork from long-lived branches. OpenClaw is more flexible: you can author with Claude Code, edit config files by hand, or use whatever AI coding tool you prefer including the built in agents. Either way, having Claude Code in the loop is the best authoring experience available right now for both — it’s just that NanoClaw treats it as the assumption while openclaw treats it as one option among several.

    The forking model

    NanoClaw’s other design choice worth flagging: it’s opinionated about you forking the repo and treating the fork as your install. There’s no config-as-data layer that abstracts away your customizations. If you want different behaviour, you change the code. The codebase is small enough that this is safe.

    This is a discipline. It means every customization is a code change you can read and revert. It also means setup feels heavier than openclaw’s onboarding. For a pipeline you’ll be running for months, that’s the right trade. For a weekend assistant project, it’s overkill.

    The decision criteria, condensed

    Pick OpenClaw if:

    • You want a personal assistant that responds to messages on channels
    • The workflow is whatever the conversation is
    • You want maximum provider flexibility (Anthropic, OpenAI, local models all first-class)
    • You want a menubar app and guided onboarding out of the box
    • You’re fine with the larger codebase and application-level security model

    Pick NanoClaw if:

    • You’re building something with a state machine — pipeline-shaped, not chat-shaped
    • The workflow exists independent of any conversation
    • You need deterministic routing, dry-runs, replay
    • You want different providers for different stages, configured per agent group
    • You’re deep enough in Claude Code to leverage it as the authoring layer
    • You want OS-level container isolation as your security model
    • You’re willing to write the orchestrator yourself (and would rather, because you want to own the workflow logic)

    Worth knowing

    NanoClaw is younger and more spartan around setup edges — both because it does less by design and because the project is moving fast. If you hit a setup gotcha, the answer is usually in the docs and a quick edit by Claude Code resolves it. Filing an issue and waiting is the slower path. The flip side: the codebase is small enough that you can read all of it, and Claude Code can confidently make changes across it.

    OpenClaw has the larger community, more channel adapters in stable shape, and a richer ecosystem of community skills (ClawHub, the openclaw skills marketplace, has hundreds). If you’re operating in personal-assistant territory, those network effects matter. For pipelines, they don’t.

    Worth flagging for context: OpenClaw’s creator, Peter Steinberger, joined OpenAI in February 2026, with the project continuing as open source. The project’s velocity has been impressive but the security model has also been the subject of multiple writeups — anyone evaluating it for production should read the security analyses alongside the marketing copy.

    The full GTM system this comparison feeds into is in Building a GTM dark factory with Nemotron 3 and NanoClaw. For setup specifics — what it takes to actually run NanoClaw end to end — see the companion piece.

  • Installing n8n on Raspberry Pi 3B

    Installing n8n on Raspberry Pi 3B

    I recently decided to set up n8n on my Raspberry Pi 3B to automate my social media workflow, thanks to n8n’s availability for self hosted setups.

    The Pi was already running Pi-hole 24/7 as my network’s DNS server, so I wanted a solution that wouldn’t interfere with it. Here’s what I learned after trying the standard approach and eventually succeeding with Docker.

    The Failed Attempt: Direct Install

    I started with a guide designed for newer Raspberry Pis (Pi 4/5), following instructions from various tutorials that suggested a direct npm installation. The process seemed straightforward:

    bash

    # The approach that DIDN'T work on Pi 3B
npm install n8n -g
n8n start

    What went wrong: The installation would start, but then freeze the entire Pi. The limited 1GB RAM on the Pi 3B couldn’t handle the build process. I had to force restart the Pi multiple times. Even the uninstall and update commands wouldn’t work properly, leaving me to manually remove the n8n folder.

    The Solution: Docker Installation

    After the npm failures, I switched to Docker following instructions provided by Claude. This approach uses pre-built images, completely bypassing the resource-intensive build process. Here’s the complete setup that worked perfectly.

    Step 1: Install Docker

    bash

    # Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Add your user to docker group (avoids needing sudo)
sudo usermod -aG docker $USER

# Log out and back in for group changes to take effect

    Verify Docker is installed:

    bash

    docker --version

    Step 2: Install Docker Compose

    bash

    sudo apt-get update
sudo apt-get install -y docker-compose

    Step 3: Create n8n Directory and Configuration

    bash

    # Create directory for n8n
mkdir -p ~/n8n
cd ~/n8n

# Create docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.3'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_SECURE_COOKIE=false
    volumes:
      - ./data:/home/node/.n8n
EOF

    Note on version: I initially used version: '3.8' but got an error about unsupported version. The older docker-compose on Pi 3B required version: '3.3'.

    Step 4: Fix Permissions (Critical!)

    bash

    # Create data directory and set proper permissions
mkdir -p ~/n8n/data
sudo chown -R 1000:1000 ./data

    This step is crucial. n8n runs as user ID 1000 inside the container and needs write access to save workflows, credentials, and configuration files.

    Step 5: Start n8n

    bash

    docker-compose up -d

    Check if it’s running:

    bash

    docker-compose ps
docker-compose logs -f n8n

    The startup takes 30-60 seconds on a Pi 3B. Once you see logs indicating n8n is running, you can access it at http://[your-pi-ip]:5678 from any device on your network.

    Press Ctrl+C to exit the logs view (this doesn’t stop n8n, just stops viewing the logs).

    Key Configuration Choices

    Why N8N_SECURE_COOKIE=false?

    By default, n8n requires HTTPS for secure cookies. Since we’re running locally without SSL, this setting allows access from other devices on your network. This is perfectly safe for a home network setup.

    Why restart: unless-stopped?

    This ensures n8n automatically starts when your Pi reboots. Docker is configured to start on boot by default, and it will automatically restart any containers marked with this policy.

    Coexisting with Pi-hole

    The beauty of this setup is that n8n and Pi-hole run completely independently:

    • Pi-hole typically runs on port 53 (DNS) and 80/443 (web interface)
    • n8n runs on port 5678
    • Both use Docker’s default network, with no conflicts
    • Combined RAM usage is manageable on the Pi 3B

    Managing n8n

    Here are the essential commands (run from ~/n8n directory):

    bash

    # Stop n8n
docker-compose stop

# Start n8n
docker-compose start

# Restart n8n (useful after config changes)
docker-compose restart

# View logs
docker-compose logs -f n8n

# Update n8n to latest version
docker-compose pull
docker-compose up -d

# Complete removal
docker-compose down
rm -rf ~/n8n

    Handling OAuth Credentials

    One challenge I encountered was setting up OAuth credentials (Google, LinkedIn, etc.) when accessing the local n8n from my MacBook. Many OAuth providers require the redirect URL to be either HTTPS or localhost.

    Solution: SSH Tunnel

    bash

    # On your Mac/laptop, create an SSH tunnel
ssh -L 5678:localhost:5678 pi@[your-pi-ip]

# Then access n8n at http://localhost:5678 in your browser

    This makes your browser think n8n is running locally, which satisfies OAuth requirements. Once credentials are saved, you can close the tunnel and access n8n normally via the Pi’s IP address. You only need the tunnel when initially setting up OAuth credentials.

    Performance Notes

    The Pi 3B handles n8n surprisingly well for automation workflows:

    • Startup time: 30-60 seconds after reboot
    • Workflow execution: Perfectly adequate for scheduled tasks
    • Web interface: Responsive enough for editing workflows
    • RAM usage: n8n + Pi-hole combined use ~45%, leaving headroom

    For workflows that need AI processing (like my LinkedIn post generator), I’m calling LM Studio running on my MacBook over the network. The Pi handles the orchestration, while the heavy AI work happens on more powerful hardware.

    Troubleshooting Tips

    If the container keeps restarting: Check permissions on the data folder. The error logs will show “EACCES: permission denied” if this is the issue.

    If you can’t access from other devices: Make sure you’ve set N8N_SECURE_COOKIE=false in the environment variables and restarted the container.

    If Docker isn’t starting on boot: Enable it with sudo systemctl enable docker

    Final Thoughts

    The Docker approach transformed what seemed like an impossible task into a straightforward 10-minute setup. While the Pi 3B isn’t powerful enough to compile n8n from source, it’s more than capable of running the pre-built Docker image alongside Pi-hole.

    If you’re running a Pi 3B and want to add n8n to your home automation stack, skip the npm route entirely and go straight to Docker. Your Pi (and your sanity) will thank you.

    Complete Setup Script

    For reference, here’s the entire setup in one script:

    bash

    #!/bin/bash

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

# Install Docker Compose
sudo apt-get update
sudo apt-get install -y docker-compose

# Create n8n directory
mkdir -p ~/n8n
cd ~/n8n

# Create docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.3'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_SECURE_COOKIE=false
    volumes:
      - ./data:/home/node/.n8n
EOF

# Create and set permissions on data directory
mkdir -p data
sudo chown -R 1000:1000 ./data

# Start n8n
docker-compose up -d

echo "n8n is starting up. Access it at http://$(hostname -I | awk '{print $1}'):5678 in about 60 seconds."
echo "View logs with: docker-compose logs -f n8n"

    Save this as install-n8n.sh, make it executable with chmod +x install-n8n.sh, and run it with ./install-n8n.sh. Note that you’ll need to log out and back in after the script runs for Docker group permissions to take effect, then run docker-compose up -d from the ~/n8n directory.

  • The Law of Leaky Abstractions & the Unexpected Slowdown

    The Law of Leaky Abstractions & the Unexpected Slowdown

    If the first rush of agentic/vibe coding feels like having a team of superhuman developers, the second phase is a reality check—one that every software builder and AI enthusiast needs to understand.

    Why “Vibe Coding” Alone Can’t Scale

    The further I got into building real-world prototypes with AI agents, the clearer it became: Joel Spolsky’s law of leaky abstractions is alive and well.

    You can’t just vibe code your way to a robust app—because underneath the magic, the cracks start to show fast. AI-generated coding is an abstraction, and like all abstractions, it leaks. When it leaks, you need to know what’s really happening underneath.

    My Experience: Hallucinations, Context Loss, and Broken Promises

    I lost count of the times an agent “forgot” what I was trying to do, changed underlying logic mid-stream, or hallucinated code that simply didn’t run. Sometimes it wrote beautiful test suites and then… broke the underlying logic with a “fix” I never asked for. It was like having a junior developer who could code at blazing speed—but with almost no institutional memory or sense for what mattered.

    The “context elephant” is real. As sessions get longer, agents lose track of goals and start generating output that’s more confusing than helpful. That’s why my own best practices quickly became non-negotiable:

    • Frequent commits and clear commit messages
    • Dev context files to anchor each session
    • Separate dev/QA/prod environments to avoid catastrophic rollbacks (especially with database changes)

    What the Research Shows: AI Can Actually Slow Down Experienced Devs

    Here’s the kicker—my frustration isn’t unique.

    A recent research paper, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, found that experienced developers actually worked slower with AI on real-world tasks. That’s right—AI tools didn’t just fail to deliver the expected productivity boost, they created friction.

    Why?

    • Only about 44% of AI-generated code was accepted
    • Developers lost time reviewing, debugging, and correcting “bad” generations
    • Context loss and reliability issues forced more manual intervention, not less

    This matches my experience exactly. For all the hype, these tools introduce new bottlenecks—especially if you’re expecting them to “just work” out of the box.

    Lessons from the Frontlines (and from Agent Week)

    I’m not alone. In the article What I Learned Trying Seven Coding Agents, Timothy B. Lee finds similar headaches:

    • Agents get stuck
    • Complex tasks routinely stump even the best models
    • Human-in-the-loop review isn’t going anywhere

    But the tools are still useful—they’re not a dead end. You just need to treat them like a constantly rotating team of interns, not fully autonomous engineers.

    Best Practices: How to Keep AI Agents Under Control

    So how do you avoid the worst pitfalls?

    The answer is surprisingly old-school:

    • Human supervision for every critical change
    • Sandboxing and least privilege for agent actions
    • Version control and regular context refreshers

    Again, Lee’s article Keeping AI agents under control doesn’t seem very hard nails it:

    Classic engineering controls—proven in decades of team-based software—work just as well for AI. “Doomer” fears are overblown, but so is the hype about autonomy.

    Conclusion: The Hidden Cost of Abstraction

    Vibe coding with agents is like riding a rocket with no seatbelt—exhilarating, but you’ll need to learn to steer, brake, and fix things mid-flight.

    If you ignore the leaky abstractions, you’ll pay the price in lost time, broken prototypes, and hidden tech debt.

    But with the right mix of skepticism and software discipline, you can harness the magic and avoid the mess.

    In my next post, I’ll zoom out to the economics—where cost, scaling, and the future of developer work come into play.

    To be continued…

  • The Thrill and the Illusion of AI Agentic Coding

    The Thrill and the Illusion of AI Agentic Coding

    A few months ago, I stumbled into what felt like a superpower: building fully functional enterprise prototypes using nothing but vibe coding and AI agent tools like Cursor and Claude. The pace was intoxicating—I could spin up a PoC in days instead of weeks, crank out documentation and test suites, and automate all the boring stuff I used to dread.

    But here’s the secret I discovered: working with these AI agents isn’t like managing a team of brilliant, reliable developers. It’s more like leading a software team with a sky-high attrition rate and non-existent knowledge transfer practices. Imagine onboarding a fresh dev every couple of hours, only to have them forget what happened yesterday and misinterpret your requirements—over and over again. That’s vibe coding with agents.

    The Early Magic

    When it works, it really works. I’ve built multiple PoCs this way—each one a small experiment, delivered at a speed I never thought possible. The agents are fantastic for “greenfield” tasks: setting up skeleton apps, generating sample datasets, and creating exhaustive test suites with a few prompts. They can even whip up pages of API docs and help document internal workflows with impressive speed.

    It’s not just me. Thomas Ptacek’s piece “My AI Skeptic Friends Are All Nuts” hits the nail on the head: AI is raising the floor for software development. The boring, repetitive coding work—the scaffolding, the CRUD operations, the endless boilerplate—gets handled in minutes, letting me focus on the interesting edge cases or higher-level product thinking. As they put it, “AI is a game-changer for the drudge work,” and I’ve found this to be 100% true.

    The Fragility Behind the Hype

    But here’s where the illusion comes in. Even with this boost, the experience is a long way from plug-and-play engineering. These AI coding agents don’t retain context well; they can hallucinate requirements, generate code that fails silently, or simply ignore crucial business logic because the conversation moved too fast. The “high-attrition, low-knowledge-transfer team” analogy isn’t just a joke—it’s my daily reality. I’m often forced to stop and rebuild context from scratch, re-explain core concepts, and review every change with a skeptical eye.

    Version control quickly became my lifeline. Frequent commits, detailed commit messages, and an obsessive approach to saving state are my insurance policy against the chaos that sometimes erupts. The magic is real, but it’s brittle: a PoC can go from “looks good” to “completely broken” in a couple of prompts if you’re not careful.

    Superpowers—With Limits

    If you’re a founder, product manager, or even an experienced developer, these tools can absolutely supercharge your output. But don’t believe the hype about “no-code” or “auto-code” replacing foundational knowledge. If you don’t understand software basics—version control, debugging, the structure of a modern web app—you’ll quickly hit walls that feel like magic turning to madness.

    Still, I’m optimistic. The productivity gains are real, and the thrill of seeing a new prototype come to life in a weekend is hard to beat. But the more I use these tools, the more I appreciate the fundamentals that have always mattered in software—and why, in the next post, I’ll talk about the unavoidable reality check that comes when abstractions leak and AI doesn’t quite deliver on its promise.

    To be continued…

  • Disable Windows Hello for Smooth Autofill in Chrome

    Disable Windows Hello for Smooth Autofill in Chrome

    If you are a regular user of Chrome on Windows like me and have the auto-fill password manager enabled, you may be getting the Windows sign in prompt every time that you try to auto-fill any forms.

    Looks like it is the “Use Windows Hello” setting in the Google Password manager (accessed from Settings -> Autofill and passwords -> Google Password Manager) which was causing this. Turned it off and no more prompts. You would want to leave it on if you are sharing the Windows account with others of course.

    Thanks to this forum post.

  • Fixing newsletter readability on Inoreader

    Fixing newsletter readability on Inoreader

    I have been using Inoreader as my main feed reader for quite a while now after having tried feedly for a few years. I even upgraded to their Premium plan for the power user and additional newsletter limits.

    I subscribe to a few newsletters as it is easier to get all the content in one place. There had been one rendering issue that I had been facing with Matt Levine’s Money Stuff newsletter ever since the recent update to Inoreader where the last few characters in each line would get cut off in the pop up reader view, like so:

    I tried reaching out to support, but they were not able to do much. So, I did a bit of research and found that Inoreader has a custom CSS feature in its power user setting that some folks have used to personalise the interface. The newsletter contents were being rendered in an HTML table which I discovered by inspecting the source (hit F12 on the browser or go to the dev tools).

    I did a bit of experimentation in the custom CSS settings, and found that setting the table width to 85% fixed the issue:

    table {
  width: 85%;
}

    I’m sure this is a very obscure issue which is for users like me who have subscribed to a particular newsletter in a feed reader, but documenting it in case others face something similar.

    You could of course just read the newsletter in your email inbox or through a service like NewsletterHunt, or just change the view to full article in Inoreader.

  • Dubai Diaries: Staying active via VR

    Dubai Diaries: Staying active via VR

    The second device (the first was of course the gaming laptop that has been doing double duty as a GenAI device) that I purchased in Dubai after relocating in 2022 was the Meta Quest 2 VR headset.

    Picking it up towards the end of the year has its advantages as the apps and games are usually discounted due to the Christmas sales. In fact I got Beat Saber as a freebie with my purchase. This was the game that sent me down the Meta VR App store rabbit hole where I found a bunch of sports games like:

    There are also games for boxing, fishing, shooting, Star Wars (becoming Darth Vader’s apprentice) among others. They are a big departure from the typical computer, mobile or console gaming as they require you to move around and give you a decent workout.

    I also picked up some accessories like the hard case to store & transport the device in a safer manner, along with the head strap replacement. The head strap in particular is a big upgrade and almost necessary if you want to use the headset for even a moderate amount of time.

    Most have been around for several years now and have gotten a boost in terms of features & quality thanks to the renewed focus on AR & VR with the launch of the Apple Vision Pro and the Meta Quest 3 over the last year or so.

    Here’s my experience with some of these apps that have helped me stay more active, especially during the Dubai summers when it gets pretty difficult for outdoor activities. One thing to note is that most of these apps/games require some dedicated space – typically 6″ x 6″ – to play safely, though some can be played standing in one place.

    iB Cricket

    This game has been developed by a team from India, and you can see that they have done their share of partnerships with some of the mainstream cricket events over the years. It is mainly a batting simulator where you can play as a bunch of teams at varying difficulties and it also has multiplayer options & leagues if you like to compete against other players.

    They sell a bat accessory that can be used with the Quest 2 controller to give you an easier and more authentic experience. This was in fact something that I picked up during one of my India trips and it really makes the gameplay much better.

    VZFit

    This year, I also picked up a subscription to the VZFit app which can be used with an indoor bike to stay fit. By default they have a fitness experience that you can perform using just the controllers, but the virtual biking is what piqued my interest. The app allows you to bike around different locations in Google Maps using the Streetview images in an immersive form.

    Here’s a sample from one of my rides along the Colorado river:

    There are a bunch of user curated locations that can be quite scenic. Some even come with voiceover to direct your attention to places of interest. They also have regular challenges and leaderboards if you like to compete, and integration with a bunch of online radio stations to keep you entertained. You also have a trainer who can accompany you on a bike and guide you with the workout.

    You mainly need to connect a compatible bluetooth cadence sensor to your Quest headset so that it can detect the bike activity. As for the stationary bike, you can get your own or use one in the gym. I got the Joroto X2 spin bike which seems to be pretty good value. A battery powered clip-on fan can also be pretty handy to keep you cool and also simulate a breeze when you are virtually biking.

    Beat Saber

    Beat Saber is possibly one of the most well known VR games. After all, it’s not every day that you get to dual-wield something akin to light sabers and chop things up with a sound track to match.

    It is basically a virtual rhythm game that has been around for several years where you wield a pair of glowing sabers to cut through approaching blocks which are in sync with a song’s beats and notes. This can give you a really good workout as it also involves ducking and dodging in addition to the hand movements.

    Eleven Table Tennis

    Given the size of the Quest controllers and in hand feel similar to a TT bat, table tennis feels like a natural fit. This was one of the first sports games that I picked up on the Quest, and I have seen this game evolve within a few months of my purchase. Currently it has a host of options ranging from practice to multiplayer with different levels of difficulty.

    The multiplayer part is also pretty interesting and immersive as it can use your Meta avatar for the in game player. It also has voice chat so you can talk to your opponent. The in game Physics is also very realistic due to which you sometimes forget that there is no actual table in front of you.

    Vader Immortal Series

    This is a 3 episode game on the Quest, and doesn’t actually need you to move around as much as the other sports games that I have mentioned. However, if you are a Star Wars fan, this is pretty much a must try game as it gives you your fill of light saber fighting sequences starting a training involving with those mini floating droids and leading up to enemy fights standing beside Darth Vader.

    If you loved the Jedi Knight series on the computer or one of the recent Star Wars games involving Jedi, then this is pretty much a no brainer to try out. Oh, and you do get to use the force push/pull powers as well.

  • Dubai Diaries: The Dubai move and Golden Visa

    Dubai Diaries: The Dubai move and Golden Visa

    It’s been exactly 2 years since I joined my regional role in Boehringer Ingelheim in Dubai. I rarely blog about my personal life, but I thought now would be a good time to share some of the experiences around this move.

    The move to Dubai was in itself fairly straight forward as it was through an internal move. I started off with a regular employment based residence visa valid for 2 years. My family also relocated in the middle of last year, and their visas were completed through the office pretty quickly.

    Since my visa was due for renewal this year, I decided to opt for the UAE Golden Visa for salaried professionals which has a relatively easier qualification qualification criteria than the others:

    • Monthly gross salary of AED 30,000 or higher (that seems to be the current consensus, as I have also read of it being the basic salary without allowances in the past)
    • Bachelor’s degree or higher
      • Getting the equivalency certificate for this is typically the most time consuming process

    While my application was managed by my office in DIFC which definitely helped with the clarity around the process, I did find this recent Reddit post by the Amer Centre quite helpful and along with this article in Khaleej Times that explains the process and documentation requirements. I am sharing a simple guide to get the necessary documents ready based on my experience.

    Step by step guide

    The overall process took about 2 months for me, out of which the first 3 weeks went in getting the degree equivalency certificate, followed by 2 weeks for the degree physical attestation and about 2 weeks for the actual visa application, health checkup & Emirates ID issuance.

    You need digitized versions of the following key documents for the application (some like the equivalency certificate require additional documents for the verification) in addition to other documents from your employer:

    • Degree equivalency certificate
    • Bank statement showing the salary credit each month
    • Attested degree certificate (UAE Embassy in university country and MOFA in UAE)
    • NOC from company
    • Current passport and visa
    • Current passport sized photo (white background, no glasses – you can tell the photo studio for the Emirates ID or visa version)

    The equivalency certificate

    Getting the degree equivalency certificate is usually the bottleneck in this process, based on the experience of my colleagues and those who have shared their experience online.

    The process is as below with details on the Ministry site here (they also have a useful document checklist that you can refer to):

    Typically you would need your original degree certificate, the final transcript (official stamped marksheet for the entire duration of the course) and your passport copy. You need to choose one of the official partners (Dataflow or Quadrabay at the moment) for the verification and share these documents with them. It costs around AED 350 for this part of the process.

    The turnaround time is slated to be 30 days, but is completely dependent on the response time of the university. Here are a couple of tips to help speed up the process which worked for me:

    • Keep the details of your university alumni association and key academic departments handy.
    • Once the initial documents have been verified by the partner and sent to the university, if you do not get any update within a couple of weeks check in with the customer support for details regarding the communication with the university.
      • I managed to get the details of the email subject line and the department to which they had mailed this way.
    • Contact the alumni association or academic department with the details you got regarding the verification communication to nudge it along.

    Once the verification process is successfully completed, you will get the notification to complete the application on the Ministry site with the appropriate link. There is another payment involved, and the certificate is generated almost immediately. This completes the most time consuming part of the application.

    Degree attestation and next steps

    The next few steps are quite straight forward, and you could even get the degree attestation done while you are waiting for the verification to happen. You will of course need the physical degree certificate for this, and use an agency like VFS (they have an attestation helpline that you can mail here) to get this done in 2-3 weeks with doorstep pickup and drop-off.

    Once you have these documents you can go ahead with the actual visa application. A few additional tips:

    • In the bank statement (an online statement download should be fine), highlight the salary deposits and make sure that your name & account details are there on every page & highlight those as well.
    • If you are immediately transferring your salary to another account after the deposit, you may need to provide the statement from the other account as well.
    • The photo you submit will be used in the visa and Emirates ID, so you can ask the photo studio to take it accordingly.
    • You will probably be given a slot for the health checkup, but depending on your location you may be able to walk in for the checkup much earlier.
    • Ensure that you are setup on UAE pass so that the authentication on the partner sites is easier.
    • Setup your ICP app as well do that you can access the digital versions of your visa and updated Emirates ID. This uses UAE pass as well for login.
    • Depending on how you have applied, you may need to get the new Emirates ID re-issued.
    • You will need to transfer your dependents’ visas at some point in time as well.

    Hope this helped you, and wish you the best with your Golden Visa application! If this gets a good response, I’ll share some of my experiences and learnings around the Dubai relocation.

  • Taking Stable Diffusion for a spin on a basic laptop

    Taking Stable Diffusion for a spin on a basic laptop

    I’ve been quite intrigued by the recent public releases of Dall-E followed by Stable Diffusion which allow you to generate images from simple text prompts, & had been trying them out on the free online platforms. The main limitation of these is that you are limited to a certain quota for free, and to really try an opensource tool like Stable Diffusion locally, you need to pretty beefy system with a high end GPU.

    All that changed when I came across a project on GitHub that lets you run Stable Diffusion on the CPU thanks to Intel’s OpenVINO framework. I promptly took it for a spin on my 4 year old laptop with an Intel quad core 8th gen CPU. The instructions are provided on the GitHub project itself as expected. If you are using Windows like me, you can do the following:

    • Install Anaconda which simplifies the Python setup.
    • Create a new environment in Anaconda for the project.
    • Open the terminal, create a directory for the project & clone the GitHub repository for the project using the git clone https://github.com/bes-dev/stable_diffusion.openvino.git command with the project web URL.
    • Follow the installation instructions on the project page:
      • Install the project dependencies using pip install -r requirements.txt
      • Enable Developer Mode in Windows settings which allows the model to be downloaded on first run.
      • If you plan to use the web interface also install streamlit drawable canvas using pip install streamlit-drawable-canvas, as this module dependency seemed to be missing in the documentation & gave me errors on trying to run the web demo.
    • Run the script as per instructions replacing the prompt if you want (the developer seems to be a GoT/Emilia Clarke fan) – python demo.py --prompt "Street-art painting of Emilia Clarke in style of Banksy, photorealism"

    On my laptop it takes about 8-10 min to generate an image, though a more powerful CPU with more RAM should be able to cut it down to 3-4 min as mentioned in the project page benchmarks. Either way, it is a worthwhile tradeoff to be able to run it locally.

    Here are a couple of results from the prompts I ran on my laptop (I chose a couple of the timeless beauties to see what Stable Diffusion has to offer):

    Street-art painting of Elizabeth Taylor in style of Banksy, photorealism
    Street-art painting of Grace Kelly in style of Banksy, photorealism