Zilong Liang / Hack Notes in 2026
Astro is joining Cloudflare. I always had a feeling Astro would be acquired — and now it’s happening. Astro has been my favorite framework for building static websites, and it’s my choice for my personal websites now. It reminds me of when I first discovered static site generators like Jekyll — just basic build-time templating and composition, making creating a blog very easy. Features like content collections and islands are genuinely innovative. I hope it stays productive and keeps its simplicity.
Ralph Wiggum as a “software engineer”. The AI field is evolving so fast like your math classes in high school, that if you miss a week, you’re suddenly lost. For me recently, it’s Ralph, a new pattern for coding agents that pushes them to a higher automation level.
Its name comes from a character called Ralph Wiggum in the show The Simpsons, who somehow captures the spirit of this technique.
To get familiar with Ralph, I skimmed (and watched) these materials, in addition to the original post by Geoffery Huntley:
- Matt Pocock’s walkthroughs: Ship working code while you sleep with the Ralph Wiggum technique, and 11 Tips For AI Coding With Ralph Wiggum
- Greg Isenberg’s video: “Ralph Wiggum” AI Agent will 10x Claude Code/Amp
- Ryan Carson’s article on X: Step-by-step guide to get Ralph working and shipping code
In short, Ralph is a technique that runs your coding agent sessions in a loop. It pushes the typical coding agent workflow — you give it a task, watch it work, and then a new task based on its output — forward by making the agent itself assess the outputs and decide what’s next. Back in 2025, we’ve got the agreement that an “agent” is simply an AI program running tools in a loop to achieve a goal1. Ralph extends that idea naively: It’s a bash script running agent sessions in a loop to achieve a goal.
To run agents the Ralph way, you basically need the following harnesses:
- A bash script that simply runs your coding agent in a for loop
- A PRD file that lists and tracks the tasks, commonly organized as
prd.json - A progress note that the agent appends to when completing tasks, providing relevant context to the next agent session, commonly organized as
progress.txt
These elements reveal what’s truly valuable about the Ralph idea: It formalizes a context engineering approach when tackling large scale development requirements. And that’s why Ralph differs from just using a single agent session for all tasks. Every time the session completes a task, it checks the tasks in prd.json, appends notes to progress.txt, and usually makes a git commit. Then a new agent session starts with the context window cleared, so the files the last session updated serve as the only memory of the Ralph loop.
Rough notes here. If you’re interested in the details, check the materials above. It’s indeed a new idea in the field and the community will explore it further to see if it’ll truly stand out.
-
Simon Willison’s well-known article: I think “agent” may finally have a widely enough agreed upon definition to be useful jargon now ↵
Last weekend, I reorganized my personal websites. Here’s the new structure:
| Website | URL | Description |
|---|---|---|
| Personal landing page | https://zlliang.me | Brief introduction and navigation |
| Zilong’s Tech Notes | https://tech.zlliang.me | My tech exploration journal (English) |
| Zilong’s Days | https://days.zlliang.me | My life reflection journal (Chinese) |
In this post, I explain my motivation for splitting the sites. After this change, I’m ready to mark version 1.0 of my writing framework. The permalinks will be stable, and I’m excited to share more technical and personal topics in these spaces.
Update Mar 30, 2026: In late March, I renamed my two journal websites. Zilong’s Tech Notes became Hack at https://hack.zlliang.me, and Zilong’s Days became Muse at https://muse.zlliang.me. The previous domains now redirect to the new ones. I wrote a note about this branding change: Renamed the two journal websites to Hack and Muse.
Today I spent a day trying to add i18n support to the website. I brainstormed ideas and documented them in a GitHub issue. I also tried to design and implement a translation key system and a new routing system, and wrote a lot of code.
In the end, I realized it makes both the site and my writing workflow more complicated than I’d like. Direct i18n support doesn’t feel like the right move right now — it adds friction and mental overhead, and I want to be able to just start writing when an idea comes up.
Since the website’s structure is entirely under my control, I want to design a content organization that genuinely fits my own writing habits while still being open and readable to different audiences. I don’t want to add structural complexity to the site just to satisfy a sense of “everything must be unified.”
So I’m going to park this issue for now. The site will stay focused on technical writing and public English content. Anything that doesn’t fit yet will live in my private Notion workspace, and I’ll revisit it later when it makes sense.
Paul Graham’s post on X about taste. Another interesting post from Paul Graham1 — what struck me is how his posts spark real discussion. All the comments are worth reading. I’m following him now.
Oddly enough, I first learned about Paul Graham through his essays, and only later realized he co-founded Y Combinator and is such a central figure in Silicon Valley.
-
My previous note: Paul Graham’s post on X about writing ↵
I just updated the license of this website. Now it’s dual-licensed: code under MIT, content under CC BY 4.0. Previously I used CC BY-NC-SA 4.0 for content, but decided to go more open — fewer restrictions, more sharing.
Here’s the commit: zlliang/zlliang@af99933.
I now use ChatGPT and Amp in a very simple way: I just create new threads and leave them as-is.
Previously for ChatGPT, I created several projects, and when I wanted to talk to it, I’d find and continue a relevant existing thread or create a new one in a project. I’d organize them periodically. Turns out it just looked neat but didn’t actually help. Now I just start a new chat when I think I need to. ChatGPT memorizes context automatically, which is sufficient.
Similarly for Amp, I used to organize my threads very carefully. After the labels feature shipped1, I started to label every thread manually after I completed one. I finally realized this practice doesn’t help — for now. So I deleted all the labels. And when to make a thread public? When I find I need to.
When you start using a tool, use it with the least friction and in the most intuitive way. Any feature that forces redundant manual work isn’t worth the hassle. Only use a feature if you find you need to.
-
Amp news: Thread Labels ↵
Happy New Year! Here’s a quick recap of my New Year’s break:
I finished watching The King of Internet Writing, a video podcast by David Perell about what we can learn from Paul Graham’s writing. I’m ready to write more, and better, in 2026.
On New Year’s Eve, I was traveling with my partner in Chongqing. We ate spicy hotpot and walked through the hilly streets!
Chongqing's cityscape on New Year's Eve
I’m planning to add new features to this website. I created two GitHub issues, following Simon Willison’s approach to building features1:
-
Simon Willison’s blog post: How I build a feature ↵