In AI for the Ride

AI has shifted the scarcity in software development: common features are increasingly easy to obtain, while what’s truly scarce is “a version that fits your own workflow.”

In the past, secondary development was hard—not because you couldn’t code, but because understanding old code, judging change boundaries, and controlling risk were too expensive. Many “I actually want to change this” requests were ultimately discouraged by cost. Now it’s different: fork a mature open-source project, then use AI to understand and reshape it. The barrier drops sharply, while efficiency climbs.

That also explains why “contribute upstream” is no longer the only answer. Many needs are inherently private: personal habits, team processes, interaction preferences, even conflicts with the original author’s philosophy. They aren’t suitable as public defaults, but they are perfect to keep iterating inside your own branch.

My supacode fork is exactly that: it keeps the original foundation and focuses only on high-frequency experience improvements, like script buttons, shortcuts, and a diff view. Each change is small on its own, but together the tool goes from “usable” to “effortless.”

I increasingly believe open-source foundation + AI customization will become a very mainstream development approach in the next phase. The core question of software is shifting from “can it be built” to “does it feel like you.”

Lately I’ve stopped treating OpenClaw as “a single assistant” — it feels more like a trainable “team system.” I set up several catgirls on the same machine, each with clear roles, and let them collaborate with each other.

To make the system truly “team-like,” I assigned each agent an independent GitHub identity (for example, onevclaw), letting her write code, commit, review, and even keep a diary (claw.onev.cat) under her own name. Most collaboration-oriented commits are recorded via Co-authored-by: in the history for traceability, and as a tribute to their contributions.

I also did some research on communication: agents are configured with conversation channels, referencing Claude’s Agent Team, and use the file system plus polling to keep the catgirl team’s interaction model simple and effective. The most interesting part might be peer review and the “roast session”: one catgirl implements, while the others review and nitpick; different models and personalities often bring different blind spots and preferences, but once you put them into the same workflow, it’s easier to reach more stable and comprehensive conclusions.

This feels more like a long-term experiment: multi-agent collaboration may be the next main form, and the ability to orchestrate multiple agents will naturally become increasingly important. I can’t say what this mechanism will evolve into in the end, but the whole process is indeed quite interesting.

Before this, whenever I built a project I always had a clear audience in mind: users are people, readers are people, developers are people. How features are designed, how docs are written, how releases are made—all of it defaults to “how people use it.”

Recently I built a small project: TransCrab. It’s the first time I’ve seriously switched the “first user” from a person to an agent—specifically, OpenClaw.

What humans need to do is compressed to the bare minimum: tell OpenClaw there’s a project here, what result I want, and that I agree to let it install and run things. The rest—from setup, configuration, to getting the workflow truly running—can largely be handed off to it. Even wilder (and more fun): TransCrab itself was “written” by OpenClaw from start to finish—with me sitting in a chat app, steering the direction and making the calls.

This was a very new experience for me: for the first time I clearly felt I wasn’t building a “tool for people,” but a “capability for an agent.” It reads docs, runs scripts, makes decisions, maintains itself, and can even push an entire deployment through to production from a cold start—while I’m mostly watching, confirming, and correcting the direction.

If you push this experience one step further, something even more interesting appears: maybe before long, “building a project” itself will look more like collaboration—humans spell out intent and boundaries, agents carry execution and maintenance; agents may even prepare capability packages for other agents so they can negotiate and integrate on their own, and eventually build and run a system together long term. Humans become the people who state the wishes, rather than the ones tightening every single screw by hand.

TransCrab is just a small exploration, but it let me truly glimpse a future for the first time: more and more software will be written for agents, and agents will increasingly write software for humans. Thinking about that, I’m actually a bit excited—this path has only just begun.

While writing Chroma (a Swift terminal syntax highlighting library) and ca (a highlighted replacement for cat), the most worth recording wasn’t the features themselves, but how AI amplified the value of performance optimization. Under continuous benchmark-driven iteration, tokenizer and renderer performance reached about 10x.

The method was simple: treat benchmarks as first-class citizens, let AI read the code, find hotspots, propose options, then estimate gains theoretically; make small changes, rerun benchmarks, and feed the results into the next round. Optimization becomes a scientific experiment of “hypothesis—verification—correction.” AI’s value isn’t a single genius micro-optimization; it’s lowering trial-and-error enough that we’re willing to finish the job.

Two representative optimizations make this clear: switching the tokenizer/renderer from a batch pipeline to streaming to systematically cut memory and copy costs; adding a fast path for ASCII-dominant real-world input distributions, with a safe fallback for non-ASCII. Neither is a “flash of inspiration,” but both require meticulous changes and validation—exactly the part AI is good at carrying.

Therefore, the old lesson that “premature optimization is the root of all evil” needs a new interpretation in the AI era. We used to avoid early optimization because trial-and-error was expensive; in AI-assisted development, those costs drop, and many optimizations can be laid out earlier and validated sooner. I increasingly believe that early optimization doesn’t violate engineering rationality; it’s actually a correct and efficient path.

Recently I’ve been rethinking how to use MCP (Model Context Protocol). The protocol itself is powerful, but running a bunch of local servers still feels too heavy, and it’s also a burden on an agent’s context window. I’ve started returning to the basics, leaning on CLI tools directly for AI to call.

For example, use Jira CLI to handle JIRA tasks, or AXe to control the simulator. The reasoning is straightforward: no server to run, clean binaries, easy to manage, clear semantics. Put the CLI directly into a skill, and as long as the CLI’s own help is well written, you don’t even need extra instructions for the agent to become a power user.

Now with the boost from Vibe Coding, if you’re missing a tool, whipping up a CLI yourself is a matter of minutes. And for the MCPs that still aren’t easy to replace and you don’t feel like wrapping into a CLI yet, you can use MCPLI as a middle layer to convert MCP into command line usage—the experience is quite solid.

I have a pretty odd requirement: I need to somehow convert a Claude Code subscription into a general-purpose OpenAI API endpoint, so it can be used by some other local services and apps. Please don’t ask why I have this need, or why I’m not just using an existing API and other models… compliance, restrictions, and all that stuff—it’s a long story, and it’s all tears.

Anyway, what should have been a calm, straightforward task turned into something I had to rush through. I ended up wrapping Claude’s Agent SDK with Hono, doing some simple translation in between, and turning the claude CLI into an OpenAI-compatible API for local use on my machine. I looked around the community and didn’t see any similarly usable solutions, so I open-sourced it along the way in case others need it—just mind the risk warnings and don’t break any rules. That said, I doubt there’s much demand for this, since not everyone runs into a bizarre situation like mine…

After getting burned yet again when the money I prepaid to Anthropic expired before I could finish it, I decided to shift all my API usage from “depositing directly with model vendors” to “using model aggregation platforms.” I already had an account with OpenRouter and had used it lightly, but OR offers far too many messy models, and the provider settings are complicated—if you’re not careful, traffic can flow to niche providers and cause unexpected headaches. By comparison, ZenMux’s interface is cleaner, its model list is clearly curated, and the suppliers appear to be only the official ones. I expect to focus on it for a while.

The visit button points to my referral link; new users get an extra 25% bonus on their first deposit. The value is solid, so I recommend giving it a try.

Nix is a package manager built on the “purely functional” philosophy. It makes every dependency explicit, keeps every build reproducible, and stops environments from polluting each other. Even better, declarative configuration lets you sync system environments, development tools, and user-level software across multiple machines, truly achieving “write once, consistent everywhere.”

I used to rely on Mackup to keep configurations in sync, but it has been heavily restricted on newer systems and even loses configs outright. That pushed me to reassess how quickly I should prioritize Nix. The syntax and onboarding curve were what held me back from a full migration before, yet now the situation has changed: I can describe what I need in natural language and have AI write the nix configuration—or even the entire flake—for me, virtually eliminating the learning curve.

Combined with Nix’s deterministic nature, switching devices, reinstalling a system, or moving my environment somewhere else comes down to a single idea: copy and done.

I’ve bounced between quite a few note-taking apps, yet finding one that is local-first, visually polished, and deeply integrated with AI is surprisingly hard. Before returning to Obsidian again, I spent about two years with Craft.do. They really pushed Mac Catalyst to its limits, but the sluggish AI updates still made me grit my teeth and walk away. In the AI era, the best way to organize notes is back to markdown files; working with files directly lets agents reach their full potential. I pair Obsidian with Infio, which weaves my notes together into a genuinely connected knowledge base.

You could replicate something similar with VS Code plus any agent, but Obsidian offers a more complete ecosystem: the visual styling notes need, backlinks, and more. The mobile version of Obsidian is much weaker, so when I’m away from my desk I switch to Termius to SSH into my home server and work on notes with a command-line agent. It also saves me from worrying about synchronization.

For those repetitive and tedious tasks that still need human input, letting AI take over is the perfect use case.

A Kingfisher release usually spans multiple PRs and issues, and manual curation easily misses fine details; double-checking while crediting the right contributors is also a chore; to top it off, naming each release can keep me stuck all day. With this workflow, AI first lists every change on master since the previous tag, then parses PR descriptions to summarize features, fixes, and contributors. That frees me up to focus on reviewing and adding insights instead of gathering information from scratch.

To improve accuracy, I include one or two sample outputs in the prompt so the AI can populate the new entries in the change log file by analogy. As long as the instructions clearly state “don’t modify the YAML keys” and “each entry must include links and contributors,” the AI consistently produces release notes that satisfy the release script. I also ask it to explain how it derived the version number (for example, why it is a minor or a patch release), so I can quickly validate the Semantic Versioning decision during review. Combining these strategies turns the once tedious release prep into a relaxed catching-up session.

As a tech worker who grinds away at routine tasks every day, I lack systematic learning in economics and investing, and my instincts in these areas are rather dull. When I read economic materials—blogs, long-form pieces, commentary—I often struggle to grasp the key points or understand the underlying essence. The arrival of AI has filled the awkward gap of having no one to consult as a newbie. I recently subscribed to Stratechery, skim the articles, hand them to an LLM, and spend about ten minutes in dialogue to dig into the essay and its logic, which has been immensely helpful.

Most LLMs perform well at summarizing articles and suggesting investments, but their behavior in discussion varies. Sonnet is easily swayed into agreement mode; ChatGPT tends to wander, often using rhetorical questions that lead the topic astray; Gemini seems more professional, yet at times carries a hint of emotion. Overall, ChatGPT is the most well-rounded for this kind of task. The more varied my usage, the more these models feel like people: each has its own personality and strengths, making the experience quite fascinating.

A developer’s true limit is input speed! In the age of AI, I can finally rely on voice input to handle every task however I like: I use VoiceInk or similar tools for on-device dictation, then pass the transcribed text to an AI according to the app I am in, pairing it with the right prompt for secondary processing (for example, using “Developer Voice Command Processing” in Codex or Claude Code, or letting Slack auto-translate my Chinese into something my teammates can read). These workflows are simple, but they dramatically boost input efficiency and remove the final obstacle to working in true multitasking mode.

The speed of secondary processing is critical, and the speed-focused Groq currently feels like the clear choice. Model-wise, I prefer Kimi-2. Although the two GPT OSS models generate tokens faster in absolute terms, they are inference models, so their real-time performance on tasks like this is actually worse than straightforward, non-inference models such as Kimi. For my everyday usage, Groq’s personal plan is essentially free, which is wonderfully comfortable.

A self-hosted n8n instance can really boost happiness. I run one on my home server, where a scheduled task triggers every morning to fetch the weather for today and tomorrow along with calendar of all family members. Then, with AI integration, it generates clothing suggestions and a daily schedule, wraps it up with a warm greeting and a short motivational note, and finally delivers it to my all my families via Bark — the perfect way to start the day.

That’s right — the website you’re looking at is a pure product of vibe coding. I didn’t write a single line of code. Modern programming agent AIs handle frontend tasks with remarkable ease, and Codex offers one of the best cost-performance ratios today. From planning to implementation, it has practically taken care of everything.

After a few vibe coding projects “from-scratch”, I’ve realized that clarifying requirements before actually starting might be the key to success. Take the very first commit of this project as an example — this kind of “plan-driven development” could well be the go-to paradigm for kicking off new projects in the AI era (and of course, that plan itself was also generated by an LLM).