Nick DiRienzo

GitHub PR Comments Live in Three Different Places

2026-08-14T16:27:57.707Z

TIL that gh pr view --json comments does not return inline review comments, which Copilot makes heavy use of.

I found this because one of my coding agents confidently declared a PR clean while Copilot's findings (including a real bug) were left unacknowledged. The agent ran the obvious command, saw nothing, and moved on.

GitHub PRs have three separate ways of accessing comments:

Issue comments (the main conversation thread): gh pr view --json comments
Review bodies (the summary attached to an approval/request-changes): gh pr view --json reviews
Inline review comments (the ones anchored to actual diff lines): gh api repos/{owner}/{repo}/pulls/{n}/comments

There is no gh pr view field for the third one. If a reviewer leaves only inline comments, gh pr view --json comments can return an empty comments array even though the PR has actionable review feedback.

And GitHub has managed to make this even more confusing by having Copilot post its review summary under the login copilot-pull-request-reviewer[bot] but its inline findings under Copilot. So even if you know about the third API and filter by the reviewer you're looking for, you get an empty list.

We've since added a line to our AGENTS.md telling agents to check all three channels.

Hope this helps someone else.

Customizing Google Ads

2026-01-27T05:59:33.451Z

TIL about https://myadcenter.google.com/customize

Specifically the "Sensitive" tab that lets users toggle off ads about:

Alcohol
Dating
Gambling
Pregnancy and parenting
Weight loss

I've been seeing so many ads on YouTube these days that are just not great (they never have been). It's really not great listing to a DJ set and then have it interrupted by GLP-1 marketing. I'd prefer for it to not be interrupted at all, but creators gotta make money somehow, so I don't mind some ads.

At least, now I can hopefully have the peace of mind that these more egregious ads won't show up on my feed.

Hope this helps someone else, because I had no idea it was even possible to turn off certain ad topics.

Claude Code Personal Rules

2026-01-27T06:00:12.489Z

Since December 2025, I've been fully into jj (see [Working with jujutsu]).

Claude Code defaults to git and doesn't seem to have a good grasp of using jj as a tool.

We've recently brought Claude Code back into reviewing PRs now that Opus 4.5 is effectively a mid-level engineer.

While looking at the docs, I learned about User-level Rules.

I had no idea about this despite using Claude Code daily for 6 months.

More to come on my usage of Claude Code, but in the meantime, a friend shared his use of Claude Code which is pretty similar to mine.

PyBay 2023 - Infrastructure as a Product

2026-04-28T06:01:01.571Z

In 2023, I gave a talk on lessons I learned building on platform engineering teams.

YouTube link here.

2025 UB Forge Talk - Voice AI for Builders

2026-01-27T06:01:15.375Z

I gave this talk to the UB Forge community virtually on Sept 24, 2025.

The deck is here: https://dub.sh/ub-forge-voice-ai

Maybe something written here will show up too.

Notes from experimenting with sprites.dev

2026-03-24T02:54:07.003Z

Some quick notes from building out a prototype of cloud development environments powered by Fly.io's new product: Sprites. (PS: great notes from Simon Willison.)

I wanted isolated, ephemeral-ish environments where we can spin up an army of AI coding agents in parallel. Each with its own copy of our full product stack, its own data, and no risk of stomping on other agents' ports, processes, or storage. Sprites provide Firecracker VMs that start fast, idle for pennies, and feel like disposable computers rather than infrastructure to manage.

It's EC2 without the overhead. sprite console gets you a shell and we run code tunnel as a Sprite Service for a full IDE. The single external port limitation is a blessing in disguise: smaller attack surface, and Sprite auth sits in front of the public URL automatically. Services don't pin a Sprite as running, but foreground processes do. So you get tight control over when you're paying for compute.

While I'd like to say we're using it, I can't yet. There have been a number of road bumps during my exploration that make Sprites not yet usable for production, let alone development environments.

What's great

Isolation: Every sprite is its own Firecracker VM with a separate kernel. No shared-kernel container escape risk, no port conflicts, no filesystem bleed between environments. This is the right security boundary for running untrusted AI-generated code.
Pricing: Sprites go "warm" when not in use, meaning you only pay for storage.
Pre-loaded runtimes: Node, Python, Go, Rust, Java, PostgreSQL client, git, Claude Code all come pre-installed. Our setup script went from "install everything from scratch" to "wire up our specific pieces."
Filesystem persistence: Everything written to disk survives across sessions, warm/cold cycles, and reboots. Clone once, it's there forever.
Checkpoints: Snapshot your entire filesystem state. Useful for saving a known-good setup so you don't re-run a 10+ minute bootstrap.
--http-post exec: Reliable non-interactive command execution. WebSocket-based exec had issues with connections dropping during git clone. For some reason, switching to HTTP POST fixed it immediately.
sprite-env services: Long-lived process management that survives session disconnects and auto-restarts on wake.

What I'm hoping they build

No fleet/pool primitives: Creating a sprite is fast, but bootstrapping a full dev environment isn't. Would love first-class support for sprite pools or template-based creation from a checkpoint, so you can claim a pre-built environment instead of building from scratch each time.
No background exec: sprite exec blocks until completion. Our setup takes 10+ minutes (npm install, build) and there's no way to fire-and-forget and check status later. Would love a sprite exec --background that returns a job ID.
Higher reliability: TCP timeouts and 5xx errors on basic operations like listing, creating, and connecting to sprites. I was evaluating this as a path toward agent sandboxes in the product, but the platform needs to be solid for interactive dev work before I can trust it with autonomous agents.
CLI improvements: dropping out of sprite console eats my ghostty session. Text formatting is all over the place. I have to reset to get everything back.

The software supply chain is an active combat zone

2026-03-31T22:49:43.170Z

Software supply chain attacks are increasing in frequency and severity. This month alone we've seen multiple unrelated campaigns hitting the open-source ecosystem simultaneously. This isn't one bad week. It's the new normal.

Two weeks ago, an automated bot exploited a misconfigured pull_request_target workflow in Trivy's GitHub Actions to steal a Personal Access Token. That gave the attackers (a group tracked as TeamPCP) enough to compromise Trivy's release pipeline, poison 75 of 76 version tags, and push credential-stealing malware through official releases. From there, the stolen credentials cascaded:

March 19: Trivy compromised. Credential stealer deployed via GitHub Actions, Docker Hub, and binary releases.
March 23: Checkmarx KICS VS Code extensions and GitHub Actions compromised using credentials from the Trivy breach.
March 24: LiteLLM compromised on PyPI. Malicious versions harvested SSH keys, cloud credentials, and Kubernetes secrets.
March 27: Telnyx compromised on PyPI. Same playbook.

Just today, Cisco's source code was stolen leveraging the Trivy vector. SANS analysts believe TeamPCP may have a stockpile of compromised publishing credentials and could be operating as an Initial Access Broker. This is likely not over.

Separately, and this appears to be a different actor entirely, axios was compromised on npm yesterday. The attacker used a stolen long-lived npm access token to publish malicious versions of one of the most widely used packages in the JavaScript ecosystem.

Last September, the Shai-Hulud campaign hijacked 18 popular npm packages by phishing maintainers with fake 2FA reset emails. As an engineer, we tend to think we're too smart to fall for social engineering. We run these simulations for a living at Mirage, and I can tell you: we're not. The attacks are better than most people expect.

Different actors, different methods, all hitting at the same time. We can't control upstream maintainers, but we can harden how we consume their work:

Save exact versions. Pin direct dependencies and lock the entire dependency tree.
Set a maximum package age. Something sensible like 7 days so that brand new malicious versions aren't automatically installed. npm, pnpm, Yarn, and Bun all support this natively now. Renovate and Dependabot respect it too for automated PRs.
Pin GitHub Actions to commit SHAs, not version tags. Tags can be force-pushed. This is exactly how the Trivy compromise propagated.
In Node, don't allow install scripts. This was what allowed the axios C2 to run. In Python it's worse: you can't prevent .pth files from executing.

Software supply chain security used to be something you audited quarterly. That cadence doesn't match the threat anymore. Treat your dependency pipeline like infrastructure that's actively under attack. Because it is.

S3 Files

2026-04-07T22:12:41.714Z

With AI agents depending on filesystems for searching, editing, and storing context, it was only a matter of time before AWS had a cloud-native answer.

Today is that day: AWS launched S3 Files (All Things Distributed, AWS).

This is a big deal. Agents work on filesystems. They ls, grep, cat. We've watched Claude Code and Codex shift the industry from semantic search back to grep, which spawned a wave of tools built as CLIs instead of MCP servers. As an industry we've learned that agents are most capable when they operate like developers do, on files.

S3 Files maps buckets and prefixes to NFS mounts. That means you can create filesystem sandboxes backed by S3 durability and attach them to Lambda, ECS, whatever. Lambda becomes stateless execution with a durable filesystem.

Personalized agent contexts, scratchpads, durable working directories all on top of AWS primitives. That's an amazing foundation for anyone doing agentic work on AWS.

The cloud is catching up to how agents actually work.

Reflecting on harness engineering - lessons from engineering with AI since 2023

2026-03-06T15:42:25.346Z

I learned about OpenAI's Symphony project today. It is really impressive and reminds me of the experiment I was working on in January with inc. Symphony and OpenAI's post on Harness Engineering is making me move from the headspace of "experiment" to "how can I bring these capabilities to our daily development without a new tool."

I skimmed through the post when it released last month, but didn't deeply sit with it until now. As a long-time platform engineer, I agree with a lot here; these practices are what platform teams have encouraged for decades: shift left with fast feedback loops.

While building Mirage, we developed much of the product with AI assistance before coding agents were a thing -- we were pasting code into the OpenAI playground and getting code back. Today, it is a 100x better experience than in 2023, thanks to tools like Claude Code and Codex.

Because of that experience, our repository has continued to become more legible for our coding agents. I view our repo to be 40% aligned with the harness engineering philosophy. This is my reflection on what we do well, where we can improve, and where I disagree with OpenAI's approach.

What we do well

Architecture Decision Records (ADRs). I'm surprised OpenAI's post doesn't mention them. We have 40+ ADRs in doc/architecture/decisions/. Before agents, ADRs were aspirational: the team agreed they were valuable but couldn't sustain the discipline of writing them. With agents, ADRs become a flywheel: the agent writes the ADR as part of implementing the decision, and future agents reference those ADRs when building features that touch the same surface. We regularly see Claude cite an ADR unprompted when making an implementation choice. If you've appreciated ADRs before but couldn't keep up, having agents write and leverage them is a beautiful thing. We also include ADRs we've rejected and superseded to provide context on decisions we didn't pursue.

Committed feature plans. We commit specs to doc/features/ alongside the code. This gives PR reviewers (both human and agentic) insight into the high level vision and architecture, and whether the code aligns with the plan. We should be doing more of this -- today only some features get committed plans. The goal is all of them.

Type-safe API contracts. We use ts-rest with Zod schemas for every endpoint. This is a mechanical invariant: the agent literally cannot ship an API change that doesn't match the contract. This is the kind of guardrail the post advocates: enforce the boundary, not the implementation.

So much observability. For an early stage startup, we have a lot of telemetry. We invested heavily in OpenTelemtry traces, logging, and metrics upfront. We ship OTel data to Observe, which our coding agent can query via Observe's MCP server. This is still heavily human-in-the-loop given the complexity of the data, but even partial agent access to o11y shortens the diagnosis loop. Before agentic programming, this investment already paid for itself; now it's becoming a foundation for agent-driven debugging.

Structured logging conventions. We have a specific logging format ([Component.method] Action, context object, serializeErrorLike() for errors). This is a pattern agents still violate, which tells me it needs to move from documentation to enforcement (a linter rule, not a paragraph in CLAUDE.md). Fortunately, GritQL makes this a lot more achievable and reduce the feedback loop for agentic development.

Agent-driven code review. We have a Claude Code GitHub Action workflow that reviews every PR against our team's standards: type safety, multi-tenant data scoping, logging patterns, and security. It catches things humans miss because it never gets tired of checking the checklist. We've biased our prompt to focus on getting changes out the door while still maintaining security and quality. I discovered Warden recently which threads the needle nicely between file-path determinism and skill execution, but maybe the table of contents approach obviates the need for this.

Fast CI/CD to production. We have strong CI/CD practices that enable a rollout to production within 15 minutes. This matters more in an agent-driven workflow because throughput increases. More changes shipping means you need faster recovery, not more gates. The confidence to let agents ship comes from knowing you can recover quickly, not from preventing every possible mistake upfront.

Where we can improve

Agents can't boot our stack yet. This is the primary problem for us to solve next. The agent can't launch the app, drive it with a browser, and validate its own changes. It's working on static code, blind to whether the change actually works. This is the single biggest gap between where we are and the full harness engineering vision.

Our CLAUDE.md is the content, not the table of contents. It grew to 500+ lines and agents started ignoring patterns buried in the middle. OpenAI's approach of a short AGENTS.md (~100 lines) that points to deeper domain docs is right. "Too much guidance becomes non-guidance" is something we experience daily: the agent blatantly ignores patterns that seem simple to follow, like using our error serialization utility or response handling helpers.

Include more documentation. While we have many documents in-repo around architectural decisions and implementation plans, we lack files describing the security model, our product sense, or a simplified high-level view of the architecture. These will further legibility within the repo and improve agentic decision making.

Documentation is better than enforcement, but enforcement is what works. If agents keep violating a pattern, it's not a documentation problem: it's an enforcement problem. We need to move more conventions from prose in CLAUDE.md into automated guardrails (GritQL and tests). A lint error the agent has to fix is worth more than a paragraph it might ignore.

Some ADRs have drifted. We have 40+ ADRs but some represent completed transitions where the "decision" is now just "how it works," and some foundational early decisions were never recorded. We need a doc-gardening process, which is something OpenAI does with recurring agent jobs, and we should too.

Better agentic access to tasks and documents. While we use Notion MCPs, sometimes the documents are too complex to update and leads to a storm of failed requests with HTTP 400 status codes. This tells me that Notion is likely not the best backing store for agents, and we may want to consider a simpler document structure that is plain markdown.

Where we disagree

PRs per engineer per day is an incomplete metric. OpenAI reports 3.5 PRs/engineer/day. I'm doing 5+ with Claude Code, with one or two more complex explorations running in the background. We use this metric too since each PR is effectively a feature (+137% output in a week compared to the previous 3 months) -- it loosely measures how frequently the system is changing. But it doesn't capture how much complexity is being added or removed.

Agents should have access to more context sources. OpenAI deliberately keeps agents out of Slack. I understand the reasoning -- Slack is noisy and unstructured -- but I'm not sure why you'd limit the agent's access to context that helps it do its job. We give Claude access to Metabase and Notion via MCP so it can read task and customer context. The repo is for execution; the project management tool is for "why this matters to the business" -- where the rest of the business works.

Distinct o11y stacks per worktree is overkill. OpenAI runs separate observability for each worktree. You can get the same result by adding a worktree identifier to your OTel resource attributes and filtering in your existing APM. Same data, no extra infrastructure. I'd love to know how they landed on independent stacks.

Recurring invariant jobs are interesting, but I'd start per-PR. Their "golden principles" are enforced by recurring sweeps rather than per-PR gates. I'd love to know why they landed here, given that most of these tech-debt cleanups are reviewed in under a minute and automerged; it feels like changes that could happen on the PR-level. I think the answer is throughput at their scale -- per-PR enforcement is synchronous and blocks the agent loop. FWIW, I think the idea of recurring agentic loops is a good one, e.g. having an agent right size infrastructure outside of what your autoscaling policies support or addressing low-priority vulnerabilities. This feels like something you would layer in over time instead of out the gate, but I'll see where I'm wrong in practice.

What's next

We're working on closing the feedback loop. The end state is: given a single prompt, the agent can reproduce a bug, record a video, implement a fix, validate the fix by driving the application, record a second video, and open a pull request with evidence. Escalate to a human only when judgment is required.

We're not there yet, but each step gets closer. And none of it requires a dedicated platform team. I'm working on a companion post with the concrete checklist for other startups.

Meditation reflection - begin again

2026-03-03T19:14:16.023Z

I've tried to meditate off and on for the last decade. It hasn't really stuck yet, but that's not to say it will never stick.

I've been thinking a lot about spirituality this year. A friend suggested to try meditation and sent me a gift subscription to Waking Up. I'm fairly familiar with the mental wellness app landscape, but this is one that I never thought to try until now.

One of the experiences it gets right is a slow on-ramp into the practice of meditation through their 28-day Introductory Course. It gracefully exposes you to the different nuances and challenges that appear when meditating, like background sounds, restlessness, and loss of focus.

Early on in the course, Sam Harris introduces two ideas that have stuck with me.

Begin again. We're human and fallible. It's expected that you will fall off the practice or lose focus during a session. That's okay. Take a beat, and just begin again. Restart the count, or the in-out cycle. This concept applies to so much more than meditation too. Having a conversation go sideways? You can just begin again. Having a not so great exercise session? You can just begin again. Haven't ridden your bike to work in months? You can just begin again.

Disruptions during meditation. I always tried meditation where it's quiet, but in one session, he talks about how people have written in saying he speaks too much during the session and this disrupts focus. His suggestion is that with a strong practice, it should just be yet another thought that you observe and move on. I commute mostly by public transit (ferry, BART, or bus). I've started to use the moments to practice meditating. It's incredibly distracting and it's usually when my mind is starting to ramp into work mode too. I think by doing this though I might have a stronger and more practical foundation for mindfulness.

So here I am, restarting a meditation practice yet again.

Maybe this time it will stick. All I had to do was begin again.

Lessons from Datadog's agent harness engineering

2026-03-31T19:39:46.175Z

I recently read Datadog's blog post on how they built a Redis implementation in Rust with AI. There were a number of ideas here that resonated with how I build.

They leverage ADRs to encapsulate not just the new architectural capabilities and why, but also the properties and invariants of the system.

They leverage ADRs to encapsulate not just the new architectural capabilities and why, but also the properties and invariants of the system. This prose is then translated by AI into a formal TLA+ specification, which feeds other verification layers: Deterministic Simulation Testing (DST), Rust-specific model checkers like Stateright and Kani, and broad system telemetry checks.

This pipeline is powerful, and I think it can be leveraged for "less formal" systems building. When building features, I imagine that looking more like:

Design feature implementation plan. Include ADRs are necessary when making significant changes. Either document includes properties and invariants that must be true.
Translate properties into a test plan. An AI coding agent translates those properties into a test plan that includes example-based unit/integration tests, as well as property-based testing (e.g. fast-check in Node). This provides more coverage than the previous era of development at about the same speed. PBT is particularly helpful with complex systems, workflows, and algorithms that are more open-ended.
Validate system behavior end-to-end. End-to-end tests are an analog of DST for product development. They exercise real system behavior rather than isolated units. The agent can take this further by querying your o11y stack during test runs to find performance issues that assertions alone won't catch.

At Mirage, while we have much more unit/integration test coverage than I would have thought at this stage, we are now starting to push further with PBTs, especially around our more complex and open-world workflows. We've discovered a handful of edge cases through early PBTs on core algorithms, and this style of testing provides additional confidence in the changes we're making.

I'm excited to continue evolving our harness for agentic engineering.

Flight - an experimental coding harness

2026-04-28T06:02:37.699Z

Validation is the bottleneck

I've been a happy user of Conductor for the last few months. Having automatic worktrees and a performant orchestration tool on top of Claude Code helped move me from a couple of parallel workstreams to somewhere closer to 7+ at any given moment. I tried to do something similar with Claude desktop but the app is too slow to use as a power user.

Now I'm having another problem: I'm resource constrained. I only have so much memory to give to running the Mirage stack, and running more than one at a time really slows down the rest of what I do (Slack, internet, Notion, etc). There's two camps for this problem: one that says buy a bigger machine and the other says run your environment in the cloud.

I've been seeing more coding harnesses (Twill.ai, Coder, Zed, and I'm sure Conductor soon) try to lock you into their ecosystem and throw margin on top of rented infrastructure; rightfully so, that gives you a moat and a path to owning inference. Even Anthropic is doing this with Claude by letting you run Claude Code tasks in their infrastructure -- which if you haven't tried, is generally a great experience.

But it's still insufficient. So earlier this month, I said screw it. I don't want to wait for these tools to allow an open interface to coding in our cloud. I have AI. I can do this myself.

Provisioning cloud workspaces

I first experimented with Coder. This worked fairly well and gave us a pathway to spin up devboxes in our cloud using HCL. This provided some sanity around what is typically a bunch of bash. After moving to EC2 instances as a provisioning surface, I found myself writing a bunch of bash anyway -- well Claude, not me.

We have an EC2 template for Coder community edition that starts a pre-baked AMI of our development environment for marginally faster boot. This gives us the benefit of complete isolation of environments, allowing us to run the full stack without worrying about collisions on data, ports, or code. Each of these devboxes run ngrok for secure access, allowing us to share links to prototypes for quickly getting feedback.

Today, the intention is for these devboxes to be ephemeral. This reduces our patch management surface area and costs, while allowing us to spin up many EC2 instances concurrently. Already I'm seeing this step take longer than is pleasant, so we'll need to optimize here.

We had the ability to spin these up, but there was friction in getting there. Logging into Coder, clicking a button, connecting to Claude via the web app. It was all rather unpleasant, despite it feeling like a step in the right direction. I believe that good internal tools should be products in their own right, so I decided to make this experience better.

Introducing Flight

Flight is an open-source, pluggable Claude Code orchestrator. It builds on a bunch of experiments in harness engineering we've run over the last few months; we don't write code by hand anymore, we iterate heavily on plans, and we like validating features end-to-end. Flight gives us a frontend to provision workspaces to run the full Mirage stack in isolation, but the lifecycle scripts are just that -- any project could use this as a frontend if they wanted to.

The initial release is a native Mac app built with Swift to build faster with Claude. It's built around a workflow of isolated worktrees, has native GitHub integrations (and a pluggable forge framework for others), and native support for remote worktree workspaces.

Since my initial experiment, more of the team has been using and improving Flight. We're keeping it open-source so anyone can fork or contribute too. We're all shipping more code with AI, and our tools need to evolve to support high-volume code development and verification.

As long as that remote workspace supports ssh, Flight can build with Claude.

Early observations

The team has started to use Flight in anger this week. It's early, so more notes soon.

A few things that are exciting to see:

The inline plan review tool changed the iteration loop more than I expected. It's a slight quality of life improvement but now I can batch review without having to copy-paste from the plan. It's like a simpler version of Ultraplan.
Using Opus 4.6 1M means I don't really think about handoffs or compaction anymore. That used to be a real source of friction. This unlocks more native conversational programming.
Shareable ngrok links are useful. We're giving feedback on features earlier than we ever have. It's making feature development way more collaborative and more fun because we can see live updates to the site as the agent works behind the scenes.

Take flight

We have a bunch of ideas for where Flight goes next. Pluggability is the big one. I want this to work like VSCode extensions, not a monolith. Open source brought us to where we are today, and I'm sad to see closed-source making such a strong comeback for developer tools and infrastructure.

I would love for you to try this out, submit issues (there are many!), provide feedback, share ideas, fork it and make it your own.

Working with jujutsu

2026-01-18T16:51:20.673Z

Scattered, thoughts, tips and tricks working with jj.

I figured now would be a good time to try out jj since I am 5 PRs deep in a stack. As like most of everything here, this is written largely stream of consciousness as I am learning and doing.

Commit = feature

First learning: jj wants you to have a mental model of commit = feature. With git, you would think of a PR being the feature; even if the PR was a mess, you would likely squash and commit into main to keep it clean.

Because of this, I have to cleanup my "mess" of commits like: "yay it works", "rename", "etc". This is reasonable since I put all my effort into PR descriptions, less so individual commits.

So to take my 7 commit mess into 1 I effectively did an interactive rebase with squashing:

# This is saying from this revision set squash the changes into `wutnoxrs`
jj squash --from "wutnoxrs..yzoxlnsx" --into wutnoxrs

Everything is a revision

Second learning: jj is always operating on a commit for everything. I accidentally ran the previous command as:

jj squash --from wut --into yzox

But this is saying take revision wut and teleport it into yzox. I thought it meant from wut to yzox create a new revision and squash them into that. Nope.

But because everything is a revision. I can easily just run jj undo and fix my oopsie.

Even current edits

With git, you have to mentally differentiate between what is staged, dirty, untracked, and committed. With jj, you're never not operating on a revision:

@  omlsswzl nick 2025-12-13 22:23:52 66f2d3c2
│  (empty) (no description set)

Stacking PRs is so much simpler

Third learning: jj effortlessly manages stacked PRs. Let's say I realize I need to make a change to PR-A while working in PR-D. I can easily do jj edit PR-A, make the change, and it will auto-propagate the changes forward across the stack. Then when I push, all of those branches get pushed (effectively auto-rebased with their respective parent and pushed).

While doing my own cleanup and transition from git to jj, I found a revision in PR-D that really should be in PR-B. Now I can take my oopsie command from earlier and actually use it appropriately. I want to take revision qplwptqv and bring it to wutnoxrs; that can be done with:

jj squash --from qplwptqv --into wutnoxrs

And this applies that revision to the other one. This would have been so, so painful in git because I would have had to cherry-pick that commit into PR-B, drop it in PR-D, and then rebase PR-C and PR-D onto the latest PR-B. jj just did all of that for me.

jj made it incredibly easy to take 40 commits across 5 stacked PRs and turn them into only 1 commit per PR and update everything all at once. I think this was like under 30 minutes of effort while learning how this new tool works (thanks Gemini). After I did all this squash surgery, it should be simple enough to push with:

jj git push --all

Fixing remote tracking

This was terrifying to run, so I learned there's a dry-run mode (--dry-run). I'm glad I did because this would push all of my local bookmarks with remote... and I have many. Worse yet, I learned that a number of these branches are not tracked by jj and wouldn't be pushed because of all the changes I made:

Warning: Non-tracking remote bookmark nvd/feature@origin exists
Hint: Run `jj bookmark track nvd/feature@origin` to import the remote bookmark.

Well, I tried that and it got more complicated:

nickdirienzo@Nicks-MacBook-Pro mirage % jj bookmark track nvd/feature@origin
Started tracking 1 remote bookmarks.
nvd/feature (conflicted):
  + zwxzuvzt?? 818f8d8d feat(TSK-1857): some description here
  + oksymzvq ff94891d env vars
  @origin (behind by 1 commits): oksymzvq ff94891d env vars

Hm. Okay. I can tell jj to treat zwxzuvzt as the bookmark right?

nickdirienzo@Nicks-MacBook-Pro mirage % jj bookmark set nvd/feature -r zwxzuvzt
Error: Change ID `zwxzuvzt` is divergent
Hint: Use commit ID to select single revision from: a7d4633daa8d, 818f8d8d4fa1
Hint: Use `change_id(zwxzuvzt)` to select all revisions
Hint: To abandon unneeded revisions, run `jj abandon <commit_id>`

I can, but I can't use the change ID. I must use the underlying commit ID. But we know that from our logs. So we can run a command like this across each of the remote branches:

jj bookmark set nvd/feature -r 818f8d8d

After doing that for each of the bookmarks, I was able to push everything:

jj git push -b nvd/feature-A \
            -b nvd/feature-B \
            -b nvd/feature-C \
            -b nvd/feature-D \
            -b nvd/feature-E

I would love to run jj git push --all, but my dry run listed 74 bookmarks it would push. A lot of those are very, very stale. Not only is jj already making more productive with stacked PRs, but it is also encouraging me to Marie Kondo these all branches from my life.

New workflow

TLDR:

# Fetch any updates from origin
jj git fetch
# Sync anything that's open (see below for my aliases)
jj sync-all
# Create a new revset off main
jj new main@origin
# Do a bunch of work
...
# Describe what this is about
jj describe
# Push to origin under a new bookmark
jj git push --change @

Create new revision from where we are: jj new

Create new revision off main (i.e. need to hotfix something or start fresh work): jj new main@origin

I use main@origin instead of setting up tracking on main as a bookmark, and I think that's great — keeping main immutable means I can't accidentally edit it!

Instead of git commit -m, you would describe a revision: jj describe

Prepare revision for PR: jj git push --change @; this creates a bookmark, tracks it, and pushes to origin all in one go. No need to manually set up bookmarks.

If you want to manage the bookmark name yourself:

Create the bookmark: jj bookmark create $name ($name will be used as a branch in git)
Push the change: jj git push --bookmark $name (throw on --dry-run if you want to double check); this makes sure it's tracked by jj on origin

But honestly, bookmark names matter a lot less in jj; less cognitive overhead for me.

All done with those changes? Time for another jj new, which locks in those changes locally under the bookmark.

Lean into jj new for experiments, hotfixes, etc. Don't be afraid of having "uncommitted" changes; jj is managing it behind the scenes. I often use jj new whenever I'm about to work on something new that might cause problems with my current set of changes.

Looking at diffs between local and origin: jj diff --from $bookmark$@origin

Moving files across revisions: jj squash -i --into <revision_id>. This lets you select which files you want to move from the current revision into the provided revision. To commit the squash, type c.

Syncing with remote and rebasing revisions on top of the new changes from trunk:

jj git fetch
# Sync all tracked work with the latest main
jj sync-all

I have a collocated repo, so jj git fetch keeps me in sync with remote. After fetching, jj sync-all (a custom alias, see below) makes sure everything I'm tracking is up to date.

Aliases

Here are some aliases I've been using to make my transition to jj a bit easier.

This shows all of the revisions from where we are to main:

[revset-aliases]
"immutable_heads()" = "trunk() | tags()"
# Useful for showing my active work and rebasing their roots with main
active = "mine() ~ ::trunk()"

[aliases]
# Show my chain of revisions on the current stack
stack = ["log", "-r", "trunk()..@"]
# "Show me all my unmerged changes"
active = ["log", "-r", "active"]
# Rebase all of my active work with main@origin. Run after `jj git fetch`.
sync-all = ["rebase", "-s", "roots(active)", "-d", "main@origin"]

Cleaning up

I have a lot of stale git branches which is making it hard to make use of jj rebasing efficiently with trunk, e.g. I can't quickly do jj rebase -s "roots(active)" -d main@origin to sync up my active work with latest main.

I had Gemini cook up a one-liner to show me all of my work branched off trunk with context so I can decide what to abandon:

jj log -r "roots(active)" --no-graph \
  -T 'change_id.short() ++ " " ++ author.timestamp().format("%Y-%m-%d") ++ "   " ++ description.first_line() ++ "\n"' \
  | awk '$2 < "2025-12-10"'

Since that list looks good, I had it produce another one-linear to delete them:

# ONLY run this when you are ready to delete everything listed above
jj log -r "roots(active)" --no-graph \
  -T 'change_id.short() ++ " " ++ author.timestamp().format("%Y-%m-%d") ++ "\n"' \
  | awk '$2 < "2025-12-10" {print $1 "::"}' \
  | xargs jj abandon

It's a bit of a yolo operation, but whatever. What's great about jujutsu is if something does go wrong, I can jj undo the operation since the abandon command is taking in all the revisions at once.

Once that ran and abandoned 677 commits (oops), rebasing all my active work with a new fetch of main was a breeze.

Why aren't Claw skills just MCP server install instructions?

2026-03-01T20:01:05.599Z

I've been thinking about claws since OpenClaw released. I think we all have (e.g. Karpathy's tweet).

They're powerful, fun, and scary. I set up NanoClaw because I really liked its security model: put the non-determinism in a container so it can't wreck your system. If you're unfamiliar, NanoClaw skills are Claude Code instructions that rewrite your fork's source code to add capabilities.

I couldn't stop thinking that these skills are just plugins, but without any of the guarantees we expect from plugin architectures. No typed interfaces, no versioning, no supply chain scanning. What if the host didn't need to know about the skill's code at all and could still provide the new capabilities? I built NonnaClaw to test that idea: an experimental fork of NanoClaw with a rebuilt skill layer that treats MCP servers as the capability boundary. I wrote about the process here.

Why spend tokens on code changes?

This was the first thought that led me down this rabbit hole. I didn't fully believe that personalized forks were better than a stable platform that provides plugins. What I actually wanted was determinism and a stronger security model.

That led me to the question: can these skills just be MCP setup instructions? An MCP server is a normal software project. It has dependency management, versioned releases, typed interfaces, and it can be scanned for vulnerabilities the same way any package can. A skill that teaches an LLM to construct curl commands at runtime has none of that. The execution is non-deterministic, the interface is untyped, and there's nothing to scan because the "code" is regenerated from markdown on every invocation.

We have plugin architectures for a reason. VSCode extensions don't patch editor.main.js. They operate within a typed API that the host exposes. The extension gets capabilities without changing the application's code. NanoClaw skills rewrite the host. OpenClaw skills prompt-inject the host. Neither is a plugin architecture.

Putting this to the test

To keep the code simple and small, NonnaClaw separates the three layers:

Capabilities: These are provided as tool calls to MCP servers. Typed, versioned, maintained by someone else. Normal software.
Configuration: a skill.json manifest declaring what to spawn and how to scope requests. Effectively a flexible authorization layer on the tools themselves for the agent.
Workflows: orchestration skills that reference tools abstractly. Can't execute without the MCP tools present.

A skill is its own repo with two files. nonnaclaw-whatsapp wraps a community WhatsApp MCP server with per-group scoping. nonnaclaw-github wraps GitHub's official MCP server (ghcr.io/github/github-mcp-server) via Docker with read-only scoping: every write operation (merge_pull_request, push_files, delete_file, etc.) is allow: false. The SKILL.md runs once during install to walk through auth. After that it's out of the picture.

{
  "name": "whatsapp",
  "mcp": {
    "command": "uv",
    "args": ["--directory", "./whatsapp-mcp/whatsapp-mcp-server", "run", "main.py"],
    "pollTool": "list_messages"
  },
  "scopeTemplate": {
    "send_message": { "allow": true, "scopedParams": ["recipient"] },
    "list_messages": { "allow": true, "scopedParams": ["chat_jid"] },
    "list_chats": { "allow": false }
  }
}

The host spawns the MCP server, bridges it to HTTP, polls for inbound messages. The agent connects through a scoping proxy that enforces per-group authorization. The agent discovers typed tools through the protocol: names, descriptions, input schemas. No prompt injection needed.

After install, the skill dissolves. It's just infrastructure.

Does this apply to OpenClaw?

Since the system worked end-to-end, I started wondering: does this pattern work for OpenClaw? OpenClaw skills work differently than NanoClaw skills, but the same layers (capabilities, configuration, workflows) are conflated.

An OpenClaw skill is a SKILL.md that gets injected into the agent's system prompt at runtime. The agent reads the instructions and generates bash commands, API calls, or code on the fly. No typed interface. The execution model: unversioned markdown → prompt injection → LLM generates arbitrary code → exec with agent privileges.

I looked at a handful of popular skills and was surprised to see the same pattern over and over again:

Notion: teaches the agent to construct curl commands against the Notion API. Three competing versions on ClawHub (notion, notion-skill, better-notion) all reimplementing the same thing. Notion ships an official MCP server (@notionhq/notion-mcp-server) with typed tools and scoped permissions.
GitHub: wraps gh CLI. There's a GitHub MCP server on the official Docker registry.
summarize: wraps a real Homebrew binary with versioned releases. The capability is already packaged software. The skill just tells the LLM to generate bash commands to call it.

For every major skill I looked at, typed MCP servers already exist. It feels like the skills are worse versions of interfaces that are already out there.

Understanding the current security risks with claws

ClawHub skills already ship with code. They have install scripts, package.json files, versioned releases, changelogs, metadata schemas declaring required binaries and env vars. It's like 80% of a package manager, but then used prompt injection for the last 20%.

This is why NanoClaw runs agents in containers with limited access. You don't have to worry about this risk vector because the agent doesn't have host access.

Snyk scanned ~4,000 ClawHub skills and found 36% had prompt injection vulnerabilities. The ClawHavoc campaign documented 824 malicious skills. The attack pattern is simple: a skill looks legitimate, but its "Prerequisites" section tells you to download and run an executable. The barrier to publishing: a SKILL.md and a week-old GitHub account.

An MCP server published to npm or PyPI gets the same supply chain scrutiny as any other package. It can be scanned by Snyk, Dependabot, Socket. It has typed exports that can be audited. A SKILL.md is a markdown file that an LLM interprets at runtime. There's nothing to scan because the code doesn't exist until the agent generates it.

How the models compare

Each approach makes different tradeoffs across the same three layers:

Layer	OpenClaw	NanoClaw	NonnaClaw
Capabilities	Prompt-injected bash/curl	Codemods to source	MCP servers
Configuration	Same SKILL.md	Same codemod	`skill.json` manifest
Scoping	None	Container isolation	Container isolation + per-tool proxy

This is an experiment

This is early. There's still work to do: securing the host layer, strengthening the MCP proxy, and some other ideas.

The install-time trust problem doesn't go away. SKILL.md runs once during setup and could instruct Claude Code to do bad things. But the blast radius is one-time versus permanent prompt injection on every agent turn. Same trust model as npm install.

The accessibility argument is real: SKILL.md is easier to write than an MCP server, and for non-developers, the AI is the interface. But Claude Code can scaffold a working MCP server from a description in minutes. package.json took more work than a loose shell script too, and that tradeoff was worth making. The friction argument gets weaker every month. The security argument doesn't.

If you want to poke at it: nonnaclaw is the fork. nonnaclaw-whatsapp is the simplest skill example: three files, wraps a community MCP server, scoped per group. If you've built OpenClaw or NanoClaw skills and want to try converting one, I'd like to know where the pattern breaks down.

What's Left When AI Writes the Code

2026-01-27T05:57:03.848Z

The software engineer job is changing drastically and more quickly than people realize. But I think people have the wrong idea of what the job is in the first place: it's solving problems with software, not writing code. Code is just a means to an end, and now it's not even the time-consuming part.

Recent models like Anthropic's Opus 4.5 can ship code as well as (or better than) a mid-level engineer. More importantly, it can write code that would take weeks in minutes. That allows us to learn faster, iterate faster, and ship faster.

In the last couple of months, I've written about 5-10% of code. In the last week, I didn't even open an editor and just worked through Claude Desktop Code. While that's anecdotal, I recently looked at some data of commits to main comparing pre-Claude and post-Claude. We had an 80% increase in contributions to main -- almost twice the output with the same team.

So what's left for us to do? At least for now, the higher leverage stuff: vision, architecture, and taste.

Vision is clarifying what you're building and why. Knowing what makes your product unique; the subtle things that differentiate you from competitors who technically do the same thing. Claude can read your docs, your ADRs, your past conversations. But it doesn't have the empathy you've built through every user conversation, every competitor you've studied, every feature you decided not to build.

Architecture is designing sound technical systems and thinking about consequences. Claude will solve your problem, but it might overcomplicate something that should be simple, or pick an approach that doesn't meet your business where it is. It's not that Claude makes bad choices; they're usually defensible. But defensible isn't always appropriate for the context you're building in.

Taste is the squishiest one: having conviction in whether it feels right. Depending on context, it might be about UX, developer experience, the cognitive model of your product's nouns, or some flow that just feels off. Models can produce technically-correct solutions all day. They don't have feel. Vision tells you that you need good UX. Taste tells you this UX isn't good enough.

I haven't seen the current generation of models be really good at these 3 things, even with historical ADRs, access to all the code, and clear goals/non-goals of problems to solve. I suspect we'll see models get much, much better at these areas too. Where we focus our time as engineers once they are capable in these areas, I'm not yet sure.

At least for me, there's still a lot of guidance and hand-holding I need to do. Fortunately, most of it at the planning level. Once the plan and architecture is aligned with my worldview, I let Claude auto-edit and I don't look at the code at all while it's developing. I act as QA in the areas it can't figure out automated testing.

With tools like Coder and now Claude Desktop's Code feature (with git worktrees -- thank you), I'm able to drive several sizable projects in parallel. I'm unfortunately pinged constantly by the dozen or so Claude tabs that need permission to run some bash command that wasn't allowed. I'm getting more and more bullish on pure yolo mode given how much autonomy Claude has while developing.

Once it's done, I tell it to put up a PR and that's where I focus my time. I focus primarily on the architectural decisions it made during the process of development, which I have it write as ADRs. I double-check the data models and API contracts to align with our general direction. I'll do a cursory pass on the implementation and leave review comments; which I then tell Claude to iterate on. Depending on what's being changed, I'll look a bit more closely at certain areas, but I'm mostly caring about the overall shape than the code itself.

If you're an engineer wondering what to focus on: develop your vision, your architectural instincts, your taste. The code part is getting easier. The judgment part isn't (yet). Where we go from here, I'm not entirely sure. In the meantime, I'm shipping faster than I ever have.

What would an enterprise OpenClaw look like?

2026-03-02T04:34:57.017Z

Clearly my brain is obsessing over the Claw ecosystem this weekend since this is the 3rd post in 48 hours about this topic.

While hacking on NonnaClaw, I couldn't help but think about what the multi-tenant SaaS architectural variant could look like. There are so many trade-offs to make when building software, but in the enterprise I've found two things to broadly be true:

Encrypting customer data on a per-tenant basis as the default; it is the customer's data. What's left as cleartext is metadata for routing and authorization.
Enabling customers to have the option for data sovereignty (e.g. bring your own bucket, bring your own key, run in their cloud, etc)

If I simplify Claw applications, they are primarily workflow orchestrations dressed up with a familiar UX (WhatsApp, etc). In addition to the data needs, the architectural requirements are:

Durable orchestration. API requests to LLMs can fail, so you'll want retries, and agents can lean on workflow orchestration to perform work instead of running it long-lived in its own container. Instead of agents spawning subprocesses and passing data through files, it would use something like Temporal, Inngest, or Dapr. These workflow orchestrations also provide polling mechanisms built-in so cron moves to the application level.

Runtime isolation. Given the non-determinism of agents, they must be treated as untrusted. This means each agent should run in a Docker container or v8 isolate that cannot interfere with other user requests. Kubernetes is the obvious winner here due to the ad-hoc nature of running new agents, unless v8 isolates work out which would reduce the infra footprint.

Agent capability scoping. Building on the above, not only do agents need to be run in isolation, each agent has a separate set of allowed tools and APIs. Because they are untrusted, they should not see credentials for tool use (see IronCurtain and NonnaClaw for the single-user version of this). This requires some sort of explainable policy engine like OPA or Cedar; explainability matters here because when agents are doing real work on behalf of humans, customers need to audit exactly what an agent was and wasn't authorized to do. While runtime isolation prevents escape, this prevents unauthorized use.

Cloud-native IO. Local Claws lean on the filesystem for agent work and Node polling loops for data ingestion. This local IO model breaks when you have multiple tenants on shared infrastructure. Files become per-tenant blob storage (e.g. S3). Polling loops become event-driven ingestion: instead of 500 tenants each running their own cron, a service exposes public endpoints per customer that push events into the durable orchestration layer or are centrally scheduled in that layer in batch.

Secret management. Claws have a massive integration surface area. These cannot be all driven by environment variables. Instead each customer will need their own secret at runtime, that only they can configure. This causes a requirement for a technology like Hashicorp Vault, OpenBao, or secrets in the database using data encryption keys from the customer key.

Execution observability. LLMOps is core to the product for debugging and improvement. You'll need to trace the full lifecycle of an agent run: what did the user ask, what did the agent do, what happened in the tool loop—using customer keys to decrypt and inspect the interaction. Long-term, the same data feeds analytics and quality feedback loops that make agents better over time. Given the enterprise data requirements above, this cannot just be piped to a random LLMOps startup. Ideally, this data belongs in a storage layer that supports both per-tenant encryption and analytical queries: an Iceberg lakehouse with per-namespace KMS keys or a warehouse like Snowflake or BigQuery with per-dataset CMEK; but this could be as simple as S3 with Athena.

What if NanoClaw skills didn't need to change the codebase?

2026-03-01T18:29:59.003Z

I read Don't trust AI agents this morning by the creator of NanoClaw (Gavriel Cohen). I generally agree with this take: we shouldn't trust our agents and provide safety-by-default for agentic behavior.

NanoClaw's approach to agentic routing is using containers for isolation as a foundational primitive. This provides hardening and guardrails that are hard to workaround. I think this is a great project and have started to use it personally in my homelab.

I left a small comment on the HN thread, but I think this is hard to articulate in short form. I tried, but definitely wasn't able to share my thoughts well enough, so here they are... and some code that shows the thesis end-to-end.

The problem with the current skills contribution model

What surprises me is that despite all of the focus on security, there's still a long-term sprawl of code via the "features as skills" contribution model. These contributions aren't just skills. They are instructions for Claude to modify NanoClaw's critical code paths to support the new capability.

While the project says that the codebase is small enough for someone to understand in an afternoon. This won't hold for someone who's added a ton of skills that modify the core code paths, the shared SQLite database, and then has to keep their fork in sync with upstream.

From a patch management perspective, I'm worried too. Since every fork is personal it means that you need to have a trusted agent watching dependencies for vulnerabilities and updating appropriately. There's no version of the skill since it's intertwined with the core codepaths of NanoClaw.

Why spend tokens on modifying the code?

The AI-native response to this is: just let Claude Code handle it. I agree that this will work, but my question is: why are we spending tokens on code modifications instead of using deterministic codemods or allowing NanoClaw to properly be a framework that supports a plugin architecture.

Plugin architectures are not new. We've had them for decades, and they allow for simple interop between an application and external functionality. Think: browser extensions, VSCode extensions, and Terraform providers.

Skills as config, not code

The agent ecosystem already has a ton of "plugins" readily available with proprietary and community MCP servers. NanoClaw needs to know how to interoperate with them.

What if skills were just a manifest, a small inbound script (to keep fetching non-agentic), and a set of MCP capabilities defined as config? This could look like:

A skill.json manifest declaring which MCP servers to use for outbound (sending messages, etc.)
A small standalone entrypoint script (~20-50 lines) that handles inbound (polling an API, writing events to an inbox directory)
A SKILL.md with instructions for how to set it up and integrate into the runtime.

This avoids every skill modifying the SQLite database and the core event loop, which risks each one stepping on each others' toes.

Skills don't need to live in the repo

If all of this can work, this would mean that NanoClaw's contribution becomes primarily an event router, a container orchestrator for agents, and an interface for writing into inbox/outbox.

Taking the idea to a further extreme, this unlocks the ability for skills to be external to the NanoClaw repository entirely. This would allow skills to be their own GitHub repos, just like MCPs with Claude Desktop.

It creates a new problem of: how does NanoClaw "install" a remote skill? But we can lean on a skill for this, or provide it as a simple CLI command: nanoclaw install.

Trying all of these ideas out

Could we take the ideas here and actually make it work? The criteria being: we are able to replicate the end to end onboarding workflow with WhatsApp without having WhatsApp in the codebase at all.

That would give us integration one. If that works, we can try with Gmail, and then we can try with another random skill. Ideally all of these are backed by popular or official MCP servers instead of custom code.

Problem 1: MCP on its own is insufficient

Containerized agents in NanoClaw are only responsible for thinking. Not for doing. Any action goes back to the host process to execute outbound messages. This means skills need to handle both inbound and outbound, not just one direction.

There's also an authorization gap. MCP servers expose all their tools to any client that connects. If a containerized agent connects directly to a WhatsApp MCP server, it can send messages to anyone, not just the group it's responsible for. We need a way to scope which tools and parameters each agent is allowed to use.

Problem 2: Global Docker container definition for agents

I skipped over this during prototyping, but each skill may need its own container runtime with OS-level dependencies. Right now, there's global sprawl across all skills instead of just on a per-skill basis. This is still an open problem. In the current architecture, MCP servers run on the host (trusted zone) so container dependencies are less of an issue for skill-specific tooling, but it's not fully solved.

I'd like to go back to this and make it so that skill MCP servers run in containers. Unfortunately it seems like many MCP servers don't provide Docker images, which feels like a gap in the ecosystem. Containers are a wonderfully simple deployment artifact, even if that deployment is your own computer.

Forking NanoClaw

I forked NanoClaw and built NonnaClaw, an experimental project that replaces the skills-as-code model with skills-as-config backed by MCP servers. I dropped the idea of an entrypoint script and instead made it work without requiring skills to make code changes. The two main additions that make this work safely are an MCP bridge and a scoping proxy, both running on the host in the trusted zone.

The bridge (mcp-bridge.ts) spawns MCP servers as child processes over stdio, exposes each one as an HTTP endpoint, and polls them for inbound messages on an interval. The same MCP server that handles list_messages for inbound also handles send_message for outbound. Both directions, one server, no custom channel code. (If MCP servers had Docker containers, we could simplify further.)

The proxy (mcp-proxy.ts) sits between the agent and the bridge, enforcing per-group authorization via scopeTemplate (tool allowlists and parameter pinning). For example, a family group chat can only send_message to its own JID. The agent never sees tools it isn't authorized for. Both run in the trusted zone for the same reason inbound does: if they ran inside the container, a compromised agent could bypass its own restrictions.

Everything else — container isolation, filesystem IPC, per-group CLAUDE.md memory, scheduled tasks, the Claude Agent SDK harness — is inherited from NanoClaw.

Putting it to the test

I built two external skills: nonnaclaw-whatsapp using verygoodplugins/whatsapp-mcp, and nonnaclaw-github using Docker's official GitHub MCP server. Each with only two files: a skill.json and a SKILL.md. Similar to NanoClaw, SKILL.md explains how to get it integrated; skill.json is new to support NonnaClaw's architecture. Two MCP servers, different transports, both running through the bridge, scoped through the proxy.

I ran /install for both. Then I sent a WhatsApp message: "Wha was the last commit i made"

After extracting skills to external packages, the code modification and channel machinery (~7,800 lines across the skills engine, Claude Code skills, and channel implementations) went away entirely. The core stays roughly the same size (about 170 line delta), with the new mcp-bridge.ts, skill-registry.ts, and mcp-proxy.ts. Ideally, the core now stays relatively static except for bug fixes, security patches, and runtime improvements.

Where this goes

NonnaClaw is an experiment. NanoClaw is the real thing. NanoClaw's insight — a personal AI assistant should be small enough to understand, secure by isolation, and customizable — is the foundation everything here builds on.

NonnaClaw explores a different answer to one question: how should skills work?

If the MCP bridge approach continues to hold up, it means any MCP server is a potential skill. The ecosystem does the hard work of building and maintaining integrations. NonnaClaw just bridges them. This could enable more flexibility for container-isolated agents, without losing the security primitives. Personally, I'm excited to have an MCP server sitting in front of my music library that Nonna can help me manage.

If you'd like to check it out, the code is at github.com/nickdirienzo/nonnaclaw.

Typed integration testing with ts-rest, supertest, and Express

2025-05-29T05:12:00.960Z

We've been happily using ts-rest at Mirage Security for about a year now. There's more to be written about why we went with ts-rest and how we use it to efficiently build features. This is about testing with it because I couldn't find any clear guides on how to test ts-rest and there's an unanswered question in Discord so here's how we approached it.

When building APIs, I've found integration tests to be the more valuable kinds of tests to write than unit tests. You can codify expected end-user API behavior in tests, can validate database state, and generally have more confidence it'll work in production. With agentic coding tools like VSCode Copilot or Windsurf Cascade, the cost of writing these kinds of tests become 0 so we have way more test coverage than I would have expected at this stage while still shipping incredibly quickly.

There were two problems to solve for us to get integration tests working:

How do we share database access between our test harness and the API implementations so that we can create data within the test block and have the API handler be able to use them?
How do we use a ts-rest client in our test suite so we can have strong typing and generally reduce what we have to test (because our contracts will validate request input)?

I wasn't sure how to solve these in this TypeScript / Node ecosystem. The codebase has been using a singleton database client which you'll see in a number of Drizzle examples (this one or the official guide). That works for until it doesn't. We now needed to share the database connection from outside of the application runtime so we could use it with supertest, which it seems that everyone was using for testing (at least per Discord).

To stay in line with 12 Factor principles (which is still extremely good guidance), I wanted the app to not know whether it was using a real database or a test database. To make that happen we used dependency injection. The plan was to have the request context maintain the database client handle, use an app factory (taking inspiration from Flask), and pass in a database client to either a managed database or a test database.

There's two approaches you can take when testing with ts-rest. You can hit it with supertest directly, but then you lose all the client helpers and type safety. Or you can provide initClient an ApiFetcher with leverages supertest under the hood to have the test harness get types. The former is how your non-TS users will use the API, but the latter lets us test really fast using ergonomics we're already using in the frontend.

I'm simplifying the code as I copy paste so I wouldn't expect it to work with a direct copy-paste to your codebase, but I hope it explains what's supposed to be happening. The full gist can be found here: https://gist.github.com/nickdirienzo/73d6cfb6caf29c56219340a7546ebd9c

The part that brings supertest and ts-rest together is specifically this bit:

And if there's a better way to do this, I'd love to hear about it.

The internet used to be weird because of humans

2025-05-29T05:19:03.481Z

Maybe it's nostalgia but I miss the earlier days of the internet. The time when everything wasn't a walled garden. Communities were smaller and fragmented. Content wasn't an optimization game or AI slop. You knew you were talking to a person. It was a fun, wild time between forums and flash games.

We've already entered the next stage of the internet. No one knows what's AI generated or not, or if they're talking to a bot or a human. I was talking with a friend recently who appreciates reading Reddit comments pre-2024 because every more recent comment reads like something out of a LLM.

There's more here on the experiments I'm running to take back some form of control. It's harder than I thought. Convenience has won. But life is a lot more than just the convenient thing.

Slack notifications via ntfy.sh

2026-02-15T22:02:41.839Z

I've been trying to not be too attached to my phone. Over the last couple of years, I've dropped Tiktok, Instagram, YouTube Shorts (clearly, there's a pattern). Every time I have Slack on it, I end up treating it like an infinite feed too, so I try not to have it on my phone either.

What's challenging is I'm also on-call for everything. While we have PagerDuty setup for automated incident creation via signals, not everything is covered. So when I get @-mentioned, I'd like to know right away.

Fortunately, it looks like a wonderful open-source service exists to help do just that: https://ntfy.sh/. Between that and Claude Code, I now have an 80 line script to do exactly what I need: when I'm @-mentioned in our alerts channel, I am notified on my phone. I rarely go anywhere without my laptop, so it's really easy to jump right on as needed.

Anyway it's 80 lines long. You can find the gist here, and run it wherever your heart desires.

Shipping faster with conductor.build and merge queues

2026-02-28T21:41:21.988Z

I feel like I hit a new level of productivity this week due to some changes in my tooling.

conductor.build

I wanted a better frontend for Claude Code (partially why I was building inc, but that's more of a software factory experiment). I found that this week in Conductor. Within a day I was already telling a ton of friends about it:

Today I had about 10 workspaces open, each with multiple tabs; it's a native Mac app so it doesn't suffer from the same performance problems that I get with Claude Desktop -- but with my usage, I've found it too sometimes be sluggish.

While I've largely stopped using VS Code, I still go to GitHub for PR review, status check resolution, and releases. It's very possible that Conductor could be my entire command center for shipping; they already have built-in check failure resolution and merging, so I fully expect them to continue to obviate the need to go anywhere else. Excited to see where they take it.

Merge Queues

I've been meaning to set these up for months as we've been shipping at an increasing rate with Claude Code, but our Conductor usage in the last 48 hours has made it an obvious need.

Auto-merging is such an immediate payoff. Claude Code makes it a breeze to migrate our apparently 46 GHA jobs over to use merge queues.

I do find it very ridiculous that this is behind the Enterprise tier on GitHub. Yes, I could explore Graphite, GitLab, and any other alternative, but I don't see a need in shifting the platform we use... yet. With GitHub's continuing outages though, I won't say it hasn't crossed my mind.

Please stop calling your auth startup open source

2026-01-27T05:58:20.142Z

I saw yet another Show HN for "open source B2B SaaS auth-in-a-box" today. It feels like the 4th time in the last year. The pitch is always the same: here's everything you need to authenticate in the enterprise, all on GitHub. Except it's not all on GitHub.

Since companies like WorkOS have taken off and Auth0 has been acquired by Okta ignoring all the startups, I've been seeing this trend of new companies pop up who lead with open source, build developer mindshare / adoption on GitHub and then you're stuck in their upsell funnel.

My problem is these projects aren't actually open source. At best they're open core -- with everything you actually need to deploy these into production locked behind a paywall. At worst, it's a gross bait and switch.

Some "open source" examples

I wish I were making this up. Here are some pricing pages for some up and coming open source auth projects.

Tesseral: you can't even run on your own domain for < $250/mo.
SuperTokens: multi-tenancy doesn't even come in the free self-hosted version so I suppose you can only support one customer at a time.
~~BoxyHQ: you have to pay to customize branding on something you host yourself.~~ Turns out Boxy was acquired by Ory (congrats team Boxy!) a day after I wrote this, so I'm dropping from this list.

Ory’s been doing great work here for a long time. But they did raise a $22M Series A in 2022 (congrats team Ory!) so we'll see how things play out over time. Candidly, I haven't been keeping too close an eye on them but I've only ever heard good things.

Companies like WorkOS and Auth0/Okta are clear that you're locked into cloud pricing. At least they're not pretending to be an open source project. You are paying for a company to manage auth for you -- and that's fine. You know what you're buying that lock-in so you can focus on your product.

How have we not solved auth already?

Getting authentication right is a core part of every business. You can (and probably should) outsource it -- it's not your core competency. Instead of betting your core infrastructure on a startup pretending to be open source, you can bet on something battle-tested that is truly open source.

Keycloak (supported by CNCF) has been doing a fantastic job here for over 10 years. They now support Organizations and there's work to be done still, but the path is there for true open source B2B auth support. Thanks Keycloak maintainers and CNCF for doing the hard work.

There's a whole ecosystem of plugins which gives a chance for companies to contribute back openly so everyone can benefit. Originally organizations were supported by one of these extensions and now it's becoming a part of the core functionality. This is a win for Keycloak and a win for the software industry.

Auth feels like it should be solved territory by now. Logging in with Google or Microsoft Entra is a standard OAuth2 flow. A ton of companies have standardized around Okta for SSO. And supporting SSO is achievable through a number of open source projects like Keycloak, passport-saml, django-saml2-auth, and others.

Where do we go from here?

It's frustrating seeing a core piece of infrastructure be touted as open source when the "open" part is just lead gen.

With auth being easier, the next hurdle is around identity management. That's getting easier too: Microsoft's Graph API is actually really good and Google Workspace has APIs for users. And for everything that's not Microsoft or Google there is SCIM.

There are so many companies out there that rely on Microsoft or Google. I don't think you need some open-core SaaS vendor in the middle anymore. You can just directly integrate with the identity platforms.

Hopefully we can stop rebuilding auth every year as a new startup and instead invest in solutions that are truly open, sustainable and portable.

Obsidian Digital Garden on Cloudflare

2025-05-18T02:15:58.398Z

I'm using the Obsidian Digital Garden Plugin for my Digital Gardening. While I haven't used Obsidian Publish, it's reduced my barrier to publishing on the internet. Write some thoughts down, tag it as dg-publish: true, cmd+p Publish, done.

The plugin's default recommendation is Vercel. I tend to not use Vercel for a variety of reasons.

Instead I'm publishing on Cloudflare Pages. I've used Cloudflare Pages for a number of static sites and single page apps over the last couple of years. It's awesome to be able to connect a GitHub repo to Cloudflare and have them manage CICD.

It'll be fun to use more of the Cloudflare products over time. If I start to lean into Cloudflare more for personal infrastructure, I'll need to figure out their Terraform provider. For now ClickOps is the way.

Anyway, after connecting the repo, it didn't immediately work when selecting 11ty as the framework. It's because there's some custom build tooling. I had to set the following options and then everything was good:

Framework preset: None
Build command: npm run build
Build output directory: dist

As a fun bonus of this side quest, Cloudflare now manages my DNS.

Learnings from building inc

2026-01-27T06:48:56.057Z

I'm experimenting with agent orchestration on top of Claude Code. It's inspired a lot by gastown and others, but it's my own personal take on it. It's called inc.

More to write about this, but the short thesis is: because agents don't have human ramp up costs, we can break free of Conway's Law -- the "org structure" (ephemeral virtual teams) mirrors the problem structure, instead of the architecture mirroring the org structure.

Restricting access to files is kind-of hard today with Claude Code within a spawned directory. Yes you can restrict Edit/Write, but if the agent has Bash, all bets are off. Fortunately, it seems like it will only have access to files within its spawned directory, but there's a need for improved filesystem sandboxing.
I'm not sure if a TUI is the way, but it's kinda neat.
Agents are still really bad at complex instruction following, so guardrails are a must. Otherwise your repo will get rekt:
- Case 1: Coder agents really like trying to read the default workspace files even though they operate in a completely separate codebase
- Case 2: the PM agent completing a spec and spinning anyway
Claude Skills are awesome. Most of this is powered by Claude Skills and a thin CLI tool to manage file writing synchronization.
The technologies we've used as humans to communicate: files, emails, etc are still valid for agents. Right now, inc is using files to request attention, but I think the next iteration of this is to use email or some task management system. It kinda could be anything that lets people communicate.

Leaning into Claude Code

2026-01-27T21:05:40.348Z

I've had a couple of friends ask how I use Claude Code, so figured to write it down here.

At least at the moment, I view it as a skill on its own. Being able to stay on top of 7+ concurrent workstreams that are pretty different while still maintaining taste is tough. The current tooling doesn't make it much easier.

When I first started using Claude Code more seriously (July 2025), I was mostly just using Claude Code one at a time. I was tinking about features in smaller incremental blocks instead of a larger milestone. When I first started, I was still in the prior mindset, so I would be pretty hands-on, I wasn't really doing planning, it was a lot of prompting but in the way I would delegate work to an engineer.

Over the next few months, I started to get a little bit more ambitious. I introduced a self-hosted Coder instance where I could start having CC work in the background mostly autonomously. What really unlocked parallelization for me was Claude Desktop introducing Code. It has built-in support for worktrees, which made the need for Coder a bit redundant (we still have it for now).

Two things shifted in my head around the same time, starting to use jj and seeing Boris' workflow on X:

The other change in workflow I made was Plan Mode. I articulated the product vision and the high-level architecture, and then let Claude interpret my scattered thoughts into a concrete plan it could execute on. I would review the plan as a file and send suggestions as chat, which would then update the file. Once the plan looked good, I let it auto-edit until it's ready for a PR.

There's some foundational investments that make this safe to do for us. Early on I laid the groundwork for ADRs which provides historical context on why we've made certain significant architectural decisions, we have a giant TypeScript monorepo so everything is grokkable in one directory, and we have way more test coverage than I think a seed stage company should have. The cost for code is 0 so might as well have tests.

With this workflow, I started to see a natural progression from 3 -> 5 -> 7 CC tasks in parallel thanks for Claude Desktop Code having native worktree support. Sprinkled with a Coder task here and there. This enabled me to move up from code as the artifact I was reviewing to instead reviewing plans, which is where I like operating.

For fun, I tried to not open my editor for a week and was largely successful. I would review the plans in chat -- which Claude Desktop makes it less painful visually. I would have it put up a PR, Claude Code would review the PR, I would then have Claude Code iterate on the changes. I would do a pass on the change and leave comments on the PR, which then I would tell CC to review and fix. This worked.

With this level of work in parallel, I find myself bombarded with notifications. I haven't fully adopted full YOLO mode because I've seen CC regress into using sed instead of Edit/Write so it hasn't earned that level of trust yet. BUT, I think that's solvable.

I think there's a more autonomous workflow here that I'm tinkering with, but just moving up to the high-level alone -- even with all the road bumps in the current iteration of UX -- has enabled me to effectively double my output.

Relevant links

How do I have 473GB of used disk space?

2025-07-12T14:37:45.521Z

I was trying to run some tests today and out of nowhere OrbStack crashes so all my Docker containers are no longer reachable.

I see OrbStack bouncing in the dock. After trying to start containers up again, I get this lovely error:

panic: rename /Users/nickdirienzo/.orbstack/log/vmgr.log /Users/nickdirienzo/.orbstack/log/vmgr.1.log: no space left on device

goroutine 17 [running, locked to thread]:
github.com/orbstack/macvirt/vmgr.check(...)
	github.com/orbstack/macvirt/vmgr/main.go:127
github.com/orbstack/macvirt/vmgr.runSpawnDaemon()
	github.com/orbstack/macvirt/vmgr/daemon.go:114 +0x46c
github.com/orbstack/macvirt/vmgr.Main()
	github.com/orbstack/macvirt/vmgr/main.go:1208 +0xf4
github.com/orbstack/macvirt/vmgr/cgostub/mainfunc.main(...)
	github.com/orbstack/macvirt/vmgr/cgostub/mainfunc/mainfunc.go:13

Excuse me? I have nearly half a TB in used disk and this laptop is only used for work. Where did all of this disk space go? Is this real?

nickdirienzo@Nicks-MacBook-Pro mirage % df -h
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   460Gi    10Gi   132Mi    99%    426k  1.4M   24%   /
devfs            205Ki   205Ki     0Bi   100%     710     0  100%   /dev
/dev/disk3s6     460Gi    11Gi   132Mi    99%      12  1.4M    0%   /System/Volumes/VM
/dev/disk3s2     460Gi   6.7Gi   132Mi    99%    1.2k  1.4M    0%   /System/Volumes/Preboot
/dev/disk3s4     460Gi   3.5Mi   132Mi     3%      58  1.4M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi   6.0Mi   481Mi     2%       1  4.9M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi   5.4Mi   481Mi     2%      32  4.9M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   2.4Mi   481Mi     1%      93  4.9M    0%   /System/Volumes/Hardware
/dev/disk3s5     460Gi   431Gi   132Mi   100%    5.5M  1.4M   80%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home
/dev/disk3s7     460Gi   2.0Mi   132Mi     2%     340  1.4M    0%   /Volumes/0CDCC59F-29F8-4E20-917C-C1A088D7A33D

Turns out, yes this is very real. I haven't had to diagnose this issue on Mac before. On Windows, there's WinDirStat which is quite helpful. o3 pointed me to ncdu which is effectively that but for the terminal. TIL! Sadly, it doesn't run in Ghostty.

I ran using ncdu -x which tells it to stay on the same filesystem (i.e. ignore Time Machine backups). After quickly scanning everything, it provides a helpful interactive overview:
The overall usage numbers at the bottom are way over my actual hardware disk so not sure what's going on there. But I have 2 obvious places to dive into: /System and /User. Let's start with /User.

My home directory is using 329GB. My code directory which is where I keep everything checked out is 84GB! I want to blame node modules.

But ~/Library seems to be the bigger culprit with 151GB used. 83GB are used by ~/Library/Containers and nearly all of that is used by ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw.

I just migrated from Docker Desktop to OrbStack this week and OrbStack manages its own data elsewhere, so there's probably a duplicate 83GB elsewhere (narrator: there wasn't).

OrbStack stores its data in ~/Library/Group Containers/HUAQ24HBR6.dev.orbstack/data per the FAQ. And that also explains some of the apparent 16TB size because it has a 8TB sparse file for storing container assets. Is this also 83GB?

nickdirienzo@Nicks-MacBook-Pro data % du -h ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/data.img
5.5G    /Users/nickdirienzo/Library/Group Containers/HUAQ24HBR6.dev.orbstack/data/data.img

Nope. I'm glad I was wrong earlier about a duplicate 83GB. Because OrbStack manages its own data, it doesn't need the Docker.raw for managing Docker container images, volumes, etc so there's a wonderful reclaim of 83GB. I thought I removed Docker Desktop via brew? I guess it leaves the data around. That's good to know.

I can't fully delete the full com.docker.docker directory even with sudo. Whatever. At least I have 83GB back. I still have 248GB of data in my home directory, what now? 79GB in my ~/code/mirage directory for everything related to that. Ah, 52GB for an unused dataset. Nice. Other fun finds are 1GB in Terraform providers for a single service -- I didn't realize it could be that big.

Now we're at 135GB reclaimed. That's enough of a win. And no, it wasn't node's fault.

Home

2025-05-17T20:48:07.205Z

This is my attempt at Digital Gardening.

I'm mostly writing for me, but maybe some of these pages are helpful to you too.

I'm moving away from social media, but you can still find me on LinkedIn and GitHub.

Goodbye Docker Desktop, hello OrbStack

2025-07-12T14:11:45.387Z

My partner runs a small software company. In a recent update, they shared:

We’ve dropped Docker Desktop for Mac in favor of OrbStack. We’ve been using containers for engineering work for a while and Docker has never felt good. OrbStack does everything Docker for Mac does and more, costs less, and is easier to use.

Funny enough at the same time, my Docker Desktop was having a time:

I'm really not sure how Docker Desktop lost a long running database container, but it did and now I have an excuse to try a different container orchestrator. It's job is to run Docker containers and it can't even do that.

After running the built-in OrbStack migration, I ran docker ps and it came back super fast. I didn't do a timer comparison but I've been noticing using docker commands getting slower.

Well this is amazing. I am sold. It boots so fast, the UI is snappy and clean, and everything feels better. Immediately signed up for a Pro account.

I'm glad people are still making great foundational software. Go team OrbStack!

Go-to message queue in 2025? For me, it's Temporal

2026-03-31T22:46:51.636Z

Sadly I don't have a lobste.rs account so I can't answer the question there, but I had some thoughts and wanted to share.

In 2025, I think most companies don't need a message queue. Message queues still have their place -- like with edge ingestion or buffering -- but I'm not sure I would reach for them for codifying business logic knowing systems like Temporal exist.

I've been building with Temporal for over a year now in production, so maybe I drank too much durable execution Kool-Aid.

If you're starting from scratch, a better option is to use a system like Temporal, which gives you exactly-once delivery, durability, and retries out of the box.

With a message queue, you have to handle all of those foundations yourself. Retries are easy, sure. Idempotency is a bit harder. Durable state that survives crashes and resumes from exactly where it left off? That’s where Temporal shines. It feels like magic.

The one major trade-off here is vendor lock-in. Once you start building with Temporal and really lean into it, it's really challenging to back out of. Fortunately you can self-host but operating a Cassandra stack is not very fun.

Still, for business logic, it's hard to beat what Temporal provides. Message queues feel like writing C in a world where you can just write TypeScript.

[!note] Aside
I know this probably sounds like I’m shilling for a company -- and I guess I am. But it’s been a long time since I’ve used a developer infrastructure product that genuinely changes the way I build software and I want more people to know about it.

Generating phone numbers with @faker-js and libphonenumber-js

2025-07-12T14:42:43.717Z

One of the interview questions I use for Mirage is around formatting phone numbers. If you've worked around telephony at all, you know that this is not straightforward.

For us, this problem is challenging because we sync enterprise directory data where formats are all over the place, country codes may or may not exist, and there might be nested numbers where one has preference.

So I built a dataset in support of this question to dive deep. How do you approach problems like these? What options do we have when dealing with a gnarly dataset like this? Is this a good use case for AI?

This isn't about how to answer those questions well, but I did find generating this dataset really interesting and fun. And I learned that libphonenumber-js has a built-in function for generating example phone numbers: getExampleNumber.

We can mimic this messy data a couple of ways:

Using faker.phone.number(): by default, this uses the "human" format, which generates numbers like: "1-317-870-1507 x49566", "861.911.5285", and "(978) 485-5429", so we can provide cases around country codes and extensions being available or not.
Using getExampleNumber from libphonenumber-js: this lets us generate international phone numbers for arbitrary countries. For example:

import examples from 'libphonenumber-js/mobile/examples'
import { parsePhoneNumberFromString, getExampleNumber } from 'libphonenumber-js';

const countryCodes = ['US', 'GB', 'DE', 'IN', 'BR', 'JP', 'ZA', 'FR', 'AU', 'CA'];
const country = countryCodes[Math.floor(Math.random() * countryCodes.length)];
const newNumber = getExampleNumber(country, examples)?.formatInternational();

This is only a small part of the script that I built out for the interview problem, but I learned a thing or two so figured to write it down. I'm trying to get better at this learning in public thing.

Digital Gardening

2025-05-17T20:35:06.263Z

A couple months ago, I asked a friend about his homelab setup. He sent me a link to his website. I didn't even realize he had one, so I clicked around some more and came across the phrase "digital garden."

At first glance the concept resonated with me because there are many thoughts, ideas, and experiences I'd like to share more publicly but every time I've written something on the internet, I felt a ton of anxiety about making the writing compelling, relevant, and interesting.

This created a really high bar for me to just write thoughts down and put them on the internet. Growing up with the internet, I dabbled with posting here and there, even creating my own CMS on top of App Engine way back when. I wrote some things down but couldn't get into the habit of it because perfection was getting in the way. I don't think I'm a very good writer, but I write a lot personally (journaling, etc) and professionally (internal memos, posts, tech specs, product docs).

I don't get the same hang up with those non-public writings. I'd like to carry over those practices to something public on the internet.

So this is my attempt at that. I hope to write a lot more here. I expect the quality to be varied and I'll use it as an opportunity to continue writing what I learn.

References

While looking into the idea of a digital garden, I read a number of articles about what they are and how people think about them:

https://maggieappleton.com/garden-history/
- "A garden is a collection of evolving ideas that aren’t strictly organised by their publication date. They’re inherently exploratory – notes are linked through contextual associations. They aren’t refined or complete - notes are published as half-finished thoughts that will grow and evolve over time. They’re less rigid, less performative, and less perfect than the personal websites we’re used to seeing."
- "Gardens are imperfect by design. They don’t hide their rough edges or claim to be a permanent source of truth."
https://www.swyx.io/digital-garden-tos
- "We have been conditioned for decades to believe in the finality and authority of the printed word. The widely accepted Rules of Good Writing exhort writers to use active voice and drop weasel words."
https://elizabethtai.com/2025/05/13/pushback-against-digital-gardens/
- "Digital gardens give you the freedom to break free of preconceived notions or “best practices” on how to write on the Internet."
- "I write in my digital garden because I want to clarify my ideas and what I’ve learned. By writing and teaching others about my ideas and learnings, I get to solidify what I’ve learned in my brain."
- "In the end, I write in my digital garden because it makes me happy."
https://elizabethtai.com/2025/05/10/digital-gardens-vs-blogging-whats-the-difference/
- "Last year or so, I discovered digital gardening, and it’s like having a light bulb go off in a path shrouded by mists. I’ve had this idea to write on the web this way, but I just didn’t know what to call it. Once I got a solidified concept, I grew extremely excited!"
- "The real star of the show is the knowledge being tended in the digital garden. Personal branding is more of an afterglow of the digital garden, a side effect rather than the sole purpose of a digital garden. Digital garden content are often incomplete, works-in-progress, not always polished or even well-written."
https://joelhooks.com/on-writing-more/
- "Seriously. The idea of a "blog" needs to get over itself. Everybody is treating writing as a "content marketing strategy" and using it to "build a personal brand" which leads to the fundamental flawed idea that everything you post has to be polished to perfection and ready to be consumed."
https://joelhooks.com/digital-garden/
- "What makes a garden is interesting. It's personal. Things are organized and orderly, but with a touch of chaos around the edges."

Bike routes around the Bay Area

2025-07-13T20:35:22.282Z

I started cycling in March 2025 with a new Specialized Sirrus X 2.0. While most of my day to day riding is commuting from Oakland to San Francisco, I've found some really great routes.

East Bay

Iron Horse Trail from Dublin BART to Walnut Creek BART: 16~ miles

Sonoma County

Sebastopol loop from Forestville: 16~ miles
- https://www.komoot.com/smarttour/14611030

About

2026-03-01T19:52:31.027Z

I'm currently building Mirage Security with my longtime friend Ross Lazerowitz.

Before Mirage, I was an early engineer at Modern Health (5th engineer, eventually Head of Foundations Engineering), spent four years at Optimizely, and interned twice at Google.

I studied computer science at the University at Buffalo, where I published research on mobile privacy and co-founded UB Hacking, the school's annual hackathon.

This site is my digital garden: a place to think out loud about building software,
working with AI, and the startup journey.

I'm moving away from social media, but you can still find me on LinkedIn and GitHub.

A reminder on how to sell

2025-06-13T21:38:50.753Z

I tried buying software last week and instead got a reminder on how to sell

Here’s what happened:

All 4 vendors had “Book a demo” as the only CTA

Only 1 had pricing on their website

2 no showed with zero follow up

1 cancelled an hour before -- the RSVP got cut off but basically said “$80K/year minimum”

1 was vibe coded in the last 4 months and might not even work

I get it: we’re a small team, not an enterprise logo, not your ICP

But ghosting isn’t a strategy to maximize ARR-- it’s just bad manners

SaaS is a long game: today’s “unqualified” lead is tomorrow’s buyer, champion or warm intro

If “Book a demo” is your CTA then please be there when someone shows up

Discuss on LinkedIn