Notes in 2026

I started using Chrome’s experimental vertical tabs. They were introduced in early April¹, as a response to the warm reception of similar features in competitors like Arc and Dia.

It’s currently behind a feature flag — enable it at chrome://flags/#vertical-tabs.

The UI feels more compact and the browsing experience more immersive. So far, so good.

Along with this, I’m also trying out pinned tabs for daily-use sites like ChatGPT and GitHub.

Over the past four days, I completed a relatively large refactor of my websites: extracting the theme shared across zlliang.me, mesh.zlliang.me, and muse.zlliang.me into an Astro integration (GitHub issue #80)!

As I said in one of the previous posts, when I split my website from one piece into three, I simply duplicated the original blog’s codebase. This led to a maintenance burden: every time I wanted to add features, update styles, or fix issues, I had to write nearly identical code across all three websites.

Simply put, the codebase violated the DRY principle severely.

To make the codebase more elegant, and ambitiously speaking, to leave open the possibility that one day my theme could be productized as an open-source Astro theme, I decided to extract the shared logic as an Astro integration. By the way, this idea is largely inspired by Starlight, Astro’s official documentation theme.

I used PR #84 to track this refactor. It took 26 commits to get me there. The refactor doesn’t affect the websites’ experience at all; it only makes the repo better-organized and makes future development simpler.

In this agentic engineering era, unsurprisingly this work was done mainly by Amp, my favorite coding agent, though roughly 15% was still coded by hand. Astonishingly, it took me 23 threads and $92.82 ($33.51 free credits included) to finish all the work. I really need to get better at using AI efficiently. See this thread for the full analysis: Analyze Amp usage and cost.

I feel good about merging the refactor now, but I already have next steps in mind: productizing it into a polished, reusable Astro theme. I’ve opened issue #86 to track the follow-up tasks.

Less than a month after the previous rename, I gave this site another new name. It is now Mesh at https://mesh.zlliang.me.

The old hack.zlliang.me domain now redirects to mesh.zlliang.me, so existing links keep working. The commit is zlliang/zlliang@01b2666.

Why rename so soon? “Hack” had started to feel narrower than what I actually write here — too tied to one tone. “Mesh” leaves more room: a place where things connect, and where I can keep weaving notes without overcommitting to any single shape.

I was working on a GitHub issue in one of my own repos today, and a question came to mind that I found interesting: In general, where should discussions take place in a GitHub repo, like design decisions and thoughts? Issues or PRs?

I asked my coding agent, and thought its answer was worth keeping:

Short answer: Issues for the what and why; PRs for the how.

A common convention:

• Issues — problem framing, design decisions, architectural discussions, RFCs, feature requests, bug reports. Long-lived, discoverable, not tied to a specific code change. This is where “should we do X, and why” lives.
• Pull requests — implementation review: discussions about the specific code, line-level feedback, trade-offs in this particular approach. Short-lived, tied to a diff.
• Discussions (if enabled) — open-ended Q&A, ideas, announcements, community conversations that aren’t actionable issues.

Practical guidance:

• Hash out design in an issue before opening a PR, especially for non-trivial work. The PR then references the issue (Closes #123) and focuses on reviewing the code, not relitigating the design.
• For larger efforts, some projects use an RFC issue (or a docs/rfcs/ markdown PR) as the canonical design record.
• Keep PR review comments scoped to the diff. If a fundamental design question surfaces mid-review, move it back to the issue.
• Decisions worth preserving long-term should end up in the repo itself (ADRs, design docs in docs/), not just buried in issue threads.

Rule of thumb: if someone six months from now needs to understand why the code looks this way, they should find it in an issue or a doc — not by scrolling through PR review comments.

I just removed note types entirely from both Hack and Muse. Old /notes/types/... URLs now redirect to /notes. After consolidating note types from 6 to 4 yesterday, momentum carried me here.

Here’s the thing. Every time I drafted a note, I had to spend mental effort deciding which type it should belong to. It became friction instead of helping me write better. More importantly, I found the timeline still reads well without a type to frame each note. The note can describe itself.

I bet it’s the right choice. If something gets in the way of writing, eliminate it. Curiously, I didn’t hesitate. Since we have AI agents now, both adding and removing features are easy. If I come up with a better taxonomy, I’ll add one.

I just simplified the note type system on both Hack and Muse, going from six types down to four.

The old regular type is now called daily, which better describes what it actually is: capturing a thought, moment, or observation while it’s still fresh. The English slug now matches the Chinese display name (日常) that was already in use on Muse.

The bigger change is merging link, collection, and quote into a single bookmark type. These three all shared the same core job — consuming something external and adding my own voice — so the split never felt meaningful in practice. The new bookmark type keeps the structural flexibility: it can be a single annotated link, a curated list, or a quoted passage with commentary.

The updated note types page

The final type list: Daily, Bookmark, TIL, Post. The commit is zlliang/zlliang@1a162b9.

Today’s observations:

• The Amp team is gradually rolling out updates. First a “new view” of the thread webpage, then I noticed the sidebar on this page is also changing quitely. Core member Thorsten Ball called it “truly a peek behind the curtain.” The new view looks like how the Codex app shows chat histories, which makes me wonder whether they’ll release a desktop app too.
• I’m brainstorming my own coding agent. Using an agent thread, I investigated how to build a prototype with AI SDK, explored server-client architecture patterns, and looked at how open-source agents like OpenCode and Pi handle harnesses like AGENTS.md and skills. The original goal is to build a toy agent letting me play with Kimi K2.6. Curious to see where this goes.

Amp's "new view"

I got up early this morning. After making a cup of coffee, I had two to three hours before work. I spun up my coding agents and completed a first version of Chore.

It’s a simple task runner for repetitive daily chores. I found myself regularly updating all the software and packages on my computers. On my work laptop, I also have to run two authentication commands every day due to my company’s security policy. I used to handle these with shell scripts, but I wanted a dedicated tool.

Thanks to agentic coding, I managed to develop and release a usable version in less than three hours. The CLI is simple, but there used to be a lot of friction just getting started.

It’s a very early version, but I’ve already adopted it and written a configuration file for my daily chores. I even built a Homebrew tap for it. Once I polish it more, I’ll write a detailed introduction.

I just added a dedicated image viewer page to both Hack and Muse. Clicking any image in a note or post now opens it on a clean, full-width page with the caption and a back link below.

I had originally planned to add a lightbox overlay, but decided to keep things simpler: a dedicated page is easier to implement, easier to share, and avoids the complexity of managing overlay state, scroll locking, and keyboard navigation. The URL carries the image source, caption, and origin page as query parameters, so the back link always returns you to where you came from — and when possible, it uses browser history to preserve your scroll position.

The image viewer page

The commit is zlliang/zlliang@4ccbab5. Most of the implementation was done with help from Claude Code.

agent-browser. A browser automation CLI built for AI agents. I started looking for browser automation tools and skills that generally enhance coding agents’ capabilities. First I recalled Playwright MCP, a tool I already knew about but hadn’t tried. Its README recommended the CLI + skills pair for this generation of coding agents, and pointed to Playwright CLI. Makes sense, I thought.

Then I remembered a similar tool by the Vercel team called agent-browser, and it turned out to be more popular (by stars). There are several agent skills written for it, one of which even points out that the tool can control any Electron-based app, like VS Code and Slack.

I installed it for all my agents (Amp, Codex, and Claude Code for now). Here’s an example on Amp: Agent-browser capabilities and example.

TIL: You can set IS_DEMO=1 to simplify the welcome screen of Claude Code. There are two types of welcome screens (shown below), and there’s no obvious logic behind which one appears for a given project — I found this annoying. After digging into it, I discovered an undocumented environment variable IS_DEMO¹ that forces the simpler one. Run IS_DEMO=1 claude, or set it in Claude Code’s settings.json under the env key.

TIL: $TMPDIR is an environment variable set by macOS (not fish-specific) that points to a per-user temporary directory. Its value looks something like:

/var/folders/xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/

The path is unique per user and per boot session — macOS generates it under /var/folders/. Files here are:

• Automatically cleaned up by the system. macOS periodically purges files in /var/folders/ that haven’t been accessed recently (typically after 3 days of inactivity, managed by the periodic daily scripts). A reboot also clears them.
• Not shared across users, since each user gets their own subdirectory.

On Linux, $TMPDIR is often unset; the conventional fallback is /tmp.

Don’t Let AI Write For You¹. Nicely distilled essay on writing.

I just renamed my two journal websites. Over the weekend, I spent some time thinking carefully about the positioning and goals of the two sites, and eventually made this decision. The English technical site is now Hack at https://hack.zlliang.me, and the Chinese personal site is now Muse at https://muse.zlliang.me.

This change updates the public branding, site names, workspace paths, and shared references from the earlier tech and days naming. I also updated the Vercel domains, and the old tech and days domains now redirect to the new ones. The commit is zlliang/zlliang@cf59692.

After the rename, I feel more confident that the two sites can grow for longer and on steadier footing.

I just finished a full Git history cleanup for my website monorepo to remove oversized historical image blobs. I used to track full-size images in the repo, which is not sustainable as my blogs grow.

I used sharp with a consistent baseline (size, edge limit, and quality ladder) to optimize images before rewriting history. The result was substantial: the total repo size, including history blobs in .git, dropped from about 500+ MB to 70+ MB (about -86%).

This was a Git history rewrite with git-filter-repo, so all commit hashes changed. I also updated commit references in my existing notes, including links in the zlliang/zlliang@xxxxxxx format and corresponding GitHub commit URLs.

After the migration, I also added a pre-commit hook that automatically optimizes newly added images to the same baseline, so future image growth stays controlled during normal commits. That setup was shipped in zlliang/zlliang@c139c11. At runtime, I still rely on Vercel’s image optimization to serve appropriate image variants for different devices and viewport sizes.

Most of the migration scripting, validation, and cleanup in this round was completed with help from Amp.