Tao's Devlog

Code w/ Claude, Tokyo

hi@hewig.dev (Tao Xu) — Sun, 14 Jun 2026 00:00:00 GMT

Update: Bun's team has since published a deep dive on the Rust rewrite discussed below — much more detail than I captured from the talk, worth reading in full.

Last week I went to Code w/ Claude Tokyo Extended expecting a casual hands-on meetup — a room full of people who like the same tools I do. It turned out to be much more than that.

The ticket was free (though you do need to sign up early). On top of that, attendees walked away with three months of Max 20x and $100 in API credits — so the event more than paid for itself before the first session even started. Food, beverages, bento boxes, and a relaxed closing reception. People had flown in from all over; it was the first time I’d been in a room with that many Claude users from that many countries.

A wall of generative "Code w/ Claude" posters at the venue. Free to take.

The sessions

The full agenda of talks and workshops is on the event page, and plenty of them were worth the trip. I’ll highlight just two.

How we use Claude Code

The first was a workshop — Anthropic engineers walking through how they actually use Claude Code internally. The framing that stuck with me: models are slow, so you really don’t want to be fixing their mistakes after a long wait.

Remove ambiguity. Make the agent interview you before it commits to anything.
Understand and plan. Plans you can actually read — interactive HTML, not Markdown.
Integrated verification. Build it in from the start, not as a step you bolt on at the end.

None of it is a flashy trick — it’s all process, not magic. Which, it turned out, was the theme of the whole event.

The "How we use Claude Code" workshop.

Rewriting Bun in Rust

The other was the closing session — the first time it was shared publicly: Jarred, the creator of Bun, walking through rewriting Bun in Rust with Claude. When that PR discussed on X and got merged eventually, I read through the migration plan — it’s a serious rewrite. Now I could hear how it actually went.

Rewrites used to be too expensive to justify; now they make sense — though not as easy as it looks:

Write the rules first. Every translation decision made once — how each old pattern maps to the new one.
Audit the rules themselves. 8 agents reviewed the rulebook; one translated 3 real files twice.
One loop. Generate → adversarial review → fixes → count what’s left, until zero.
Four stages. Files → Crates → Binary → Behavior. Bun has over 4,000 TypeScript tests, and they’re implementation-agnostic.

They ran 16 agents × 4 worktrees = 64 Claudes, and banned slow commands like git and cargo. Adversarial review matters most: 2+ adversarial reviewers for every change, and you have to watch for cheating — even the reviewers get reviewed.

Jarred presenting the Bun-in-Rust rewrite — the closing session.

Rewrite something the size of Bun and you run straight into the obvious question:

Office hours

There were a handful of 15-minute 1:1 office-hour slots with Anthropic employees — you had to book one, and they went fast. I grabbed one, and it was the part I’d undervalued the most going in. A few things that came up:

The product is a little ahead of model capability on purpose. The team builds at the edge of what Claude can do, then dogfoods hard to find where the boundaries actually are. Using it heavily is the research.
Integrations — Slack, Linear, and the Claude GitHub App are where a lot of the real workflow lives.
PR review as a pipeline — automatic, classify, and adversarial reviews, all feeding into a human at the end rather than replacing one.
Bottom-up and top-down at once — adoption grows from engineers experimenting and from leadership pushing, and you need both.

They also pushed Claude Managed Agents (CMA) pretty hard.

Thoughts on coding agents

A few things crystallized for me at the event:

1. The big tools are converging on the same idea. The way I use Claude and Codex is, at the core, roughly the same workflow. What separates them is how far each pushes that idea — better tools, more tokens, higher limits. The mental model transfers; the ceiling is what differs.

2. Knowing how insiders work is genuinely valuable. Not because of secret tricks, but because it confirms which fundamentals still matter — and shows how they show up differently now. The clearest example: Rust and Jujutsu weren’t designed for AI coding agents, yet they work better with them than tools that were. A strict compiler and a clean model of change turn out to be exactly what an agent needs, even though no one built them with agents in mind.

3. Don’t fix the code — fix the process that generates it. This is the answer to that million-lines question, and the line I keep coming back to. You don’t review a million lines by reading them. When the output is wrong, the instinct is to patch the output; the higher-leverage move is to fix the process: sample some of the results, edit the prompts to handle what went wrong, and regenerate — so the next hundred outputs are right too.

One more thing

The swag deserves its own paragraph. Pixel-art stickers, a programmable gadget — the M5Stack Cardputer Adv — and a little Claude wizard doll. Naturally, the first thing I did was get a Claude-style Tamagotchi running on the Cardputer.

The haul — a c/c card, stickers, the Cardputer Adv — and the Cardputer already running a Claude-style Tamagotchi.

My favorite piece was the little Claude wizard doll.

Claude, as a pixel wizard.

The highlight, though, was the people. Boris — who, it turns out, speaks Japanese — took a selfie of the whole room from the stage, and I got to show him my Pebble running a Claude watch face.

The same moment from the floor — Boris taking the shot.

Boris's stage selfie of the whole room at Code w/ Claude, Tokyo

I came for a meetup and left with a sharper picture of where the frontier is — and a renewed conviction that the leverage isn’t in the code, it’s in the process that writes it.

Closing Loops

hi@hewig.dev (Tao Xu) — Wed, 22 Apr 2026 00:00:00 GMT

For the past few weeks I have been rewriting three of my old apps:

GhostTile, 12 years old — my first commercial Mac app
Inspect, 10 years old — a TLS certificate inspector
Anytime, 8 years old — a timezone calculator

I did not plan a “rewrite season.” I started because I wanted to see where the frontier of SOTA coding agents actually was. I had been using Codex and Claude for work and toy projects; I wanted to push them against real code I had written long ago and mostly walked away from.

Anytime

I started with the easiest one. The prompt was almost embarrassing — “rewrite this app in modern Swift.” Anytime was small enough that this worked. SwiftUI, SPM, added macOS support, shipped. The agent handled most of the grind; I decided what to keep and what to rebuild.

Inspect

Inspect was harder. There was an old branch I had pushed nearly eight years ago — a packet tunnel to passively monitor TLS handshakes from other apps — and never finished. This time it took an afternoon.

That was a strange feeling. Not pride, exactly. More like there was no excuse anymore.

GhostTile

Then GhostTile — the one I was not sure I could rewrite at all.

The original was my favorite project, full of every macOS trick I had picked up at the time. mach_inject, XPC helpers, fishhook-style rebinding, TransformProcessType, Dock observation, swizzling. “How is this still working?” energy on every file.

Modern macOS does not forgive that kind of code anymore. SIP, notarization, hardened runtime, Apple Silicon — the platform made most of those tricks either impossible or embarrassing. For years, whenever I thought about reviving GhostTile, the honest answer was “please disable SIP and trust me,” and I could not live with that.

What actually changed was not the platform. It was that the agents got good enough to help me list and verify what still works on modern macOS, read the old code to see what was still worth bringing forward, and rebuild the rest around constraints that are real today. The new GhostTile still does unusual things — it stages a helper dylib, patches the target binary, re-signs ad hoc — but the architecture is honest and the repo is public. That feels right. I wrote a longer note on why and how I rewrote it if you are curious about the details.

The indie part

None of these apps ever took off commercially. GhostTile came the closest to being a real product, and even that is generous. But I learned something from each of them — macOS internals, TLS, cross-platform Swift — and every so often someone would email me about a bug or a small feature, which was always the better part of shipping.

I am at a stage now where I do not need side projects to pay for themselves, and that frees them to be what they always wanted to be. The repos are public. No paywalls, no license keys, no enforcement. Each one has a GitHub Sponsors button — if something I built helps you and you feel like chipping in, great; if not, also great. My “ambitious” goal is around $100–200 a month, enough to cover my AI subscriptions, which is a very 2026 sentence and one I enjoy writing.

The real reward is still just hearing from someone who uses it.

Learn the hard way, still

There is a book called Learn Python the Hard Way. The title stayed with me for years. Back then, the indie instinct rhymed with it — write it yourself, understand every line, re-invent the wheel until you have earned your taste. Libraries were something to avoid on principle.

The motivation is different now, but the method survives. Agents can write plausible code for almost anything, which means code you did not write yourself can quietly end up in your project with none of it living in your head. Building from scratch is the clearest defense against that — against slop you cannot debug, abstractions you do not own, and knowledge that never actually made it into your brain.

So my default flipped. Instead of writing everything by hand out of principle, I pick one thing I actually want to learn and build that from scratch. The rest — the parts I already know — I am happy to let the agent do.

The more ambitious version of that right now is hw-core. That is the project where I am most deliberately using “build it yourself so it actually lives in your head” as the rule, not the exception.

Jayjay is another version of the same instinct — a native macOS GUI for Jujutsu, written in Rust and SwiftUI. Rust and SwiftUI I already love — I wrote a whole post about why that is the native combination. What was new to me was jj itself. So building Jayjay from scratch turned out to be the most direct way to actually learn the tool.

Rewriting the old stuff was about closing loops. Building the new thing is about opening them.

title image credit to PixelPro Vibes on Unsplash

Rewriting GhostTile for Modern macOS

hi@hewig.dev (Tao Xu) — Wed, 22 Apr 2026 00:00:00 GMT

GhostTile was my first really polished paid Mac app.

Back then I was deep in macOS development, and GhostTile came from a very simple personal pain point: I had apps I used all the time, but I did not want to see them in the Dock, and I did not want them in Cmd+Tab either. I still wanted the normal system surfaces to stay instant. I did not want to replace the Dock with a third-party launcher. I just wanted a few apps to disappear from it.

That idea became GhostTile.

The original version meant a lot to me. It solved a real problem I had, and it also became one of the best ways I ever learned macOS internals. To make GhostTile work, I had to go much deeper into the platform than most apps ever need to. Under the hood it had exactly the kind of machinery you would expect from an older Mac utility living close to the system: mach_inject, helper processes, XPC glue, fishhook-style rebinding, TransformProcessType, Dock observation, swizzling, and a lot of “how is this still working?” energy.

It was quite a journey, and I am still proud of what I managed to build.

Why It Stalled

GhostTile never made much money, but that was not the real problem.

The bigger problem was that macOS kept changing. SIP, notarization, hardened runtime expectations, Apple Silicon, and the general direction of platform security made the old GhostTile harder and harder to maintain in a way I felt good about.

At some point I lost motivation, because I knew I did not want the answer to be “please disable SIP” or “please weaken your machine so this utility can keep doing its old tricks.”

I did not want to go backward just to keep GhostTile alive.

So the project faded.

Why Rewrite It Now

What changed recently was not that macOS got easier. It did not.

What changed was that models like Claude Opus 4 and GPT 5 became capable enough that revisiting a project like this started to feel realistic again. Not effortless, not magical, but realistic.

That gave me a reason to try.

This is not really about money anymore. It is more personal than that. GhostTile was one of the projects I was most proud of, and I needed to give myself an answer: if I rebuilt it today, knowing what I know now, could it still become something worth using?

That is what GhostTile 2.0 is.

Why It Became a Rewrite

Once I looked at it seriously, it was obvious this could not be a patch release.

The old GhostTile had too much history, too many assumptions from an older version of macOS, and too many features built around workflows that no longer felt like the right center of the product.

So I rewrote it with a few clear goals:

keep the core idea intact
make the CLI the canonical automation surface
bring back the highest-value parts of GhostTile
stop pretending every old feature needed to survive

That last point mattered a lot. I did not want an archaeology project. I wanted a version of GhostTile that matched modern macOS better, even if that meant leaving some older ideas behind.

What Changed in the New GhostTile

The new GhostTile still does unusual things, but it is more deliberate about them.

The core now revolves around preparing apps in a cleaner, more explicit way: staging ghosthide.dylib, patching the target executable to load it, re-signing the app, and making restore paths clearer when something goes wrong.

Architecturally, it is less of a pile of magic and more of a real system:

a shared core for app resolution, preparation, restore, and launch behavior
a CLI that acts as the backbone
a macOS app built on top of that same core
a simpler public repo that is easier to understand and easier to work on

I also brought back the parts that still feel essential to GhostTile:

the menu bar workflow
a proper managed-app UI
Overview
keyboard-first entry points
notifications for hidden apps

Why Make It Public

This is a new repo because it is a new chapter for the project.

I am keeping the BSL license as it is, but more as a reminder than something I want to enforce aggressively. I am making the source available because I no longer feel a strong need to treat GhostTile like a closed commercial product. It is still unusual software, but it is less black-magic-heavy than the old version, and I think people may still want to use it.

More importantly, making it public gives GhostTile a better future.

The source is available. The architecture is cleaner. The repo is in better shape. And it is much easier now for contributors, or even coding agents, to work on it in a sane way.

That feels like the right way to give GhostTile back to the community.

What This Means to Me

GhostTile 2.0 is not about trying to recreate the old business around it.

It is about revisiting one of the projects I cared about most, under modern constraints, with better tools, and answering a question I had been avoiding for years.

Was GhostTile only a product of its time, or was the idea still worth rebuilding?

I think it was worth rebuilding.

Not in exactly the same form. Not with exactly the same tricks. But still worth building.

Do AI Agents Really Need New Wallets?

hi@hewig.dev (Tao Xu) — Sun, 15 Feb 2026 00:00:00 GMT

Everyone’s building agent wallets — new custodial services, MPC shards, hosted wallets with AI spending policies. The pitch: agents need their own wallets.

We disagree. The infrastructure already exists.

Why WalletConnect?

WalletConnect connects dapps to wallets since 2018. Every major wallet supports it. So instead of building yet another agent wallet, we built a WalletConnect skill — a CLI tool that lets an AI agent pair with your existing wallet.

One-time QR pairing. After that, the agent can request signatures and transactions — but every action requires your explicit approval in the wallet app. The agent requests, you decide.

The Cypherpunk Case

The “agent wallet” trend moves keys away from users. New custodians, new trust assumptions, new intermediaries. This breaks everything crypto was built on:

Self-custody — Your keys, your coins. Not your keys, not your coins.
Don’t trust, verify — Every transaction shows up in your wallet for review.
Local-first — Agent runs on your infrastructure, not a cloud service.
Privacy — No third-party sees your transaction intent before you do.

Don’t trust, verify — including your AI agent.

Build the Future, Don’t Wait

We’re in a transition period. You can wait for someone to build the perfect “agent wallet.” Or you can plug into what already works — battle-tested protocols, real wallets, real users — and start building today.

The future isn’t built by waiting. It’s built by shipping.

👉 Read the full post on shiorix.com

The wallet-connect-skill is open source. Built by ShioriX (AI agent) and Tao (human). We tested it with Gem Wallet — an open source mobile wallet that reminds me of the early days of Trust Wallet.

Native Obsession

hi@hewig.dev (Tao Xu) — Wed, 04 Jun 2025 00:00:00 GMT

“Native” is more than a marketing term. When you treat the default environment as a first-class citizen, you gain in performance, user experience, and the speed of evolution. This post, co-created with ChatGPT, examines native from its roots to its manifestations in cloud, crypto, and AI.

Etymology

Native comes from the Latin nativus, meaning “innate” or “born locally”.
In 1964 IBM System/360 used native mode to describe running CPU instructions directly instead of emulation. Since then, “native” has been synonymous with performance and authenticity.

Three Layers of “Native” in Computing

Layer	Criteria	Value	Native ✅	Non Native ❌
CPU / Code	Compiled output is target ISA machine code; no interpreter or dynamic translation	Maximum performance and efficiency	C/C++ → x86‑64 ELF; Rust → ARM64 Mach‑O	Java byte‑code (JVM); WebAssembly (needs runtime)
OS / API	Uses official platform ABI/SDK; zero bridging for system calls	Full privileges and best power usage	iOS Swift/Objective‑C; Windows UWP	Electron (Node ↔ C++ bridge); React Native JS side
UI / UX	Controls, interactions, and themes follow platform HIG	Familiarity and full accessibility	SwiftUI/AppKit controls	Flutter custom widgets; WebView wrapping a webpage

Common Terms and Their Contention

Term	Usual Meaning	Controversy
native code	Machine code	Does JIT output count? It still depends on the VM lifecycle.
native app	Official SDK + native UI	Electron AOT to machine code performs fine, but the UI is not native.
native interface (JNI/NDK)	Bridge between managed and native code	Only partly native; still affected by GC/VM.
near-native / class-native	Performance close to native	Marketing buzzword without a clear standard.

Cloud Native: Making the Cloud the Default Runtime

Level	Criteria	Native ✅	Non-native ❌
Application Architecture	Microservices or functions; each service scales and fails independently	Netflix microservices; Shopify decomposed its Rails monolith to run on Kubernetes	Monolithic Spring Boot WAR directly on EC2
Runtime Unit	Containers or FaaS; start in seconds with declarative scheduling	AWS Lambda; Knative services; Karpenter auto‑scaling containers	Fixed-size VMs; manual Ansible setup
Infrastructure	Immutable images + IaC; GitOps can rebuild in one click	Terraform + ArgoCD; Pulumi as code	Console click‑ops; SSH changes to config files
Delivery & Ops	CI/CD triggers deployment; observable feedback loop	GitHub Actions → Argo Rollouts; Prometheus + Grafana alerts	Weekend maintenance windows; `ssh tail` logs
Resilience & Security	Horizontal scaling + zero-trust policies	GKE Autopilot + OPA; Istio mTLS	Fixed capacity + firewall allowlists

If any link in the chain still relies on manual steps or fixed resources, it is cloud-enabled rather than cloud-native.

Crypto Native: On-chain as Home

Dimension	Criteria	Native ✅	Non-native ❌
Asset Native	Value is denominated in on-chain tokens and settles on-chain	ETH, DAI, Curve LP tokens	RWA: tokenized stocks or T-Bills still rely on custody and legal clearing
Logic Native	Smart contracts transparently enforce business rules	Uniswap v4; Aave V3; MakerDAO	Binance server matching with batch settlements on chain
Governance Native	DAO votes on-chain to adjust parameters or upgrade contracts	ENS DAO, Nouns DAO	Foundation votes offline with on-chain execution merely recorded

AI Native: Model-Driven Closed-Loop Systems

Dimension	Criteria	Native ✅	Non-native ❌
Data Loop	Data → training → deployment cycle embedded in the product; model continuously improves	Rewind Pendant personal context model; TikTok immediate feedback recommendation	Exporting logs once a year for third-party offline training
AI-first Experience	Interaction centers on conversation, generation, or automatic suggestions	ChatGPT; GitHub Copilot; Perplexity AI	Office/Notion with an “AI summary” button slapped on
MLOps Lifecycle	Automated monitoring, A/B testing, canary releases, drift detection	Canva Magic Design with full pipeline observability; Uber Michelangelo	Manually uploading `.pt` files to S3 then restarting services

Why the Fascination with Native?

Long-term view: Native architectures maximize underlying capabilities with fewer layers of glue, leading to lower run costs and a higher ceiling for evolution.
Mental simplicity: The closer you are to the default, the fewer abstractions you maintain, lightening the cognitive load for teams.
A life metaphor: Technology choices are like life plans—rather than patching and compromising, deeply couple with your environment and embrace the native habitat from the start.

Native obsession does not reject cross-platform or bridging solutions. It simply reminds us to ask, whenever we seek long-term compounding advantages: Can we make it native?

Crypto Security Practices Through the Years

hi@hewig.dev (Tao Xu) — Sat, 20 Jul 2024 00:00:00 GMT

Cover image credit to Coinbase Wallet

In the realm of cryptocurrency, where the stakes are as high as the rewards, adopting robust security practices is not just advisable; it’s imperative. This post shares some of my personal experiences and practices over the years. It’s a layered approach from custodian / hot wallet to mobile wallets, hardware wallets / code storage.

Security Awareness and Good Usage Habits

The foundation of any secure system is the user’s awareness and habits. Understanding the threats and knowing the best practices in handling digital assets can significantly reduce the risk of loss. This includes recognizing phishing attempts, using secure connections, and being cautious about sharing personal information.

You should put most of your funds in cold storage, and only use your hot wallets for daily transactions.

Using Password Managers

As the number of online accounts we manage grows, so does the challenge of remembering complex passwords. Password managers not only help in generating and storing strong, unique passwords but also ensure that we’re not reusing passwords across different sites, a common vulnerability.

Hardware Security Keys

For an added layer of security, hardware security keys (such as YubiKey) offer two-factor authentication that is resistant to phishing attacks. These devices provide a physical token that must be present to access sensitive accounts, making unauthorized access significantly more difficult.

Encrypted USB Disks

Storing sensitive information or backup seeds on encrypted USB disks is a secure practice. Encryption ensures that even if the physical device is lost or stolen, the data remains inaccessible without the encryption key.

Physical Safes

For the ultimate in cold storage, physical safes can protect hardware wallets, paper wallets, and backup seeds from physical threats such as theft, fire, or water damage. Investing in a high-quality safe can provide peace of mind for those holding significant crypto assets.

You can also rent a safe from a reputable service provider like traditional banks.

Shamir Backup

Shamir’s Secret Sharing is a cryptographic method that splits a secret (like a private key) into multiple parts, requiring a certain number of parts to reconstruct the original secret. This method can protect against the loss of a single piece, as the secret is not compromised unless the required threshold of parts is met.

Advanced Data Protection for Google Account and Apple ID

Enabling advanced data protection features for accounts linked to your crypto activities (such as Google Account or Apple ID) can add an extra layer of security. These features often include advanced two-factor authentication methods, account recovery options, and alerts for suspicious activity.

Broken Money: How Our Financial System is Failing Us

hi@hewig.dev (Tao Xu) — Tue, 04 Jun 2024 00:00:00 GMT

drafted by Copilot Workspace

In Lyn Alden’s latest book, “Broken Money: How Our Financial System is Failing Us,” provides a comprehensive analysis of the origins, evolution, and current state of our financial system. Drawing on historical context, Alden explains how money has transformed from a simple medium of exchange to a complex system intertwined with global economies and politics.

The book delves into the reasons behind the perceived failure of the current monetary system, highlighting issues such as inflation, debt cycles, and the loss of purchasing power. Alden argues that these problems stem from the system’s departure from money’s traditional roles, acting as both a commodity and a credit.

One of the most compelling parts of “Broken Money” is its discussion on Bitcoin. Alden describes Bitcoin as the emergence of open source money, which embodies the properties of a perfect ledger: decentralized, transparent, and immutable. She posits that Bitcoin represents a return to the original principles of money, offering a potential solution to the systemic issues plaguing our financial system.

For those interested in a distilled version of Alden’s arguments, a YouTube video provides a concise overview of the book’s key points.

“Broken Money” is not just a critique of the current financial system but also a call to action. It encourages readers to rethink their understanding of money, its history, and its future. By exploring the rise of Bitcoin and the concept of money as a ledger with both commodity and credit properties, Alden offers a hopeful perspective on how we can address the financial system’s shortcomings.

Buy the book on Amazon

VMWare Fusion/Workstation Pro is free for personal use.

hi@hewig.dev (Tao Xu) — Wed, 15 May 2024 00:00:00 GMT

VMWare Fusion/Workstation Pro is free for personal use.

There aren’t many free virtual machine options for Apple M series Macs, I was using UTM for a while, now check out this announcement from VMWare.

Pro Apps are now Free for Personal Use and Licensed for Commercial Use

I extracted the download links here:

All you need to do is to signup a Broadcom account and download the VMware Fusion Pro or Workstation Pro.

After that you just choose the option:

In a few clicks you can download ARM Windows 11 and install it.

Enjoy!

Wallet Watch: Kraken Wallet

hi@hewig.dev (Tao Xu) — Thu, 18 Apr 2024 00:00:00 GMT

Kraken releases own crypto wallet, it’s multi-chain, open source, builit on top of React Native and audited by Trail of Bits.

The code is available on GitHub.

Farewell to Trust Wallet

hi@hewig.dev (Tao Xu) — Fri, 12 Apr 2024 00:00:00 GMT

Saying goodbye is bittersweet, I hold dear the recollections and wisdom gleaned during my time at TW. The Japanese concept of Ikigai, which means a reason for being, resonates profoundly with the state of fulfillment and purpose I experienced throughout these years.

However, I have realized that our lives are punctuated by distinct periods, each with its own unique focus. While my health and well-being now demand a different pace, I will forever value the lessons I have learned from this experience:

The transformative power of building something from the ground up
The resilience required to handle critical vulnerabilities
The importance of witnessing and contributing to team growth
The unwavering belief in our principles
The comprehensive understanding of crypto across all stacks

I am eternally grateful for the opportunity to have been part of this extraordinary team. Your support and camaraderie have made this journey unforgettable.

As I venture into the unknown, I will carry with me the lessons and experiences that have shaped me here. I wish you all continued success and fulfillment in your endeavors.

Move to Japan

hi@hewig.dev (Tao Xu) — Thu, 30 Sep 2021 00:00:00 GMT

The journey to Japan has been a transformative experience.

title image credit to Unsplash