2026 Work Log

The past few days have been quite packed, so I didn’t keep a record. But it’s not acceptable to stop recording, so I’m picking it up now and recording everything together.

Besides being busy, why didn’t I record?

1. Because I feared that recording would require sitting down and spending at least 30 minutes just to document a day. This actually stems from some fear and burden associated with recording daily life, which is not advisable.
2. I usually only start recording a day after it truly ends. But thinking about it carefully, this is somewhat counterintuitive, because now when it’s time to sleep, I quickly dive into bed, not because I’ve actually finished everything I wanted to do (does that ever really happen?). This means that when I have free time, I don’t record, and when it’s actually time to record, I have to jump into bed quickly, compounded by issue #1.

The combination of the two leads to a growing backlog.

1. What did I do today:

   Correction: what I did in the past few days

   1. Started using Neovim after being persuaded by SC. Why? I saw that nvim-orgmode has truly become a viable org-mode, and I’ve grown tired of Emacs:

      • Endless update failures
      • Confusing debugging and error messages
      • Unnecessary flexibility that only adds burden for me
      • I don’t understand Emacs Lisp and have no desire to

      For years, I’ve endured all of the above just to use org-mode, but there was no other place where I could properly use org-mode. Now that the Neovim camp seems to have an alternative, why not try it?

      Since I’ve been a long-time Vim user and have used evil-mode (Vim mode) in Emacs, I’ve never felt that using Vim is a burden. In VS Code and IntelliJ, I can’t survive without Vim, so switching to Neovim is no problem at all.

      With no obstacles left, I examined the Neovim ecosystem. Neovim doesn’t carry the historical baggage of Vimscript; it directly uses Lua as its configuration and plugin language, so it can be lightweight, and the community is very active. Now, the Neovim plugin system seems to be unified by a system called lazy.vim. Neovim’s design for its plugin and configuration system appears to have been bold and organized in addressing Vim’s original pain points. Within Vim & Emacs, there have been countless similar attempts to unify, but due to community fragmentation, none have truly succeeded.

      So I tried lazyVim directly. Wow, I suddenly felt like I had a VS Code that runs in the terminal. Do you know how great that feels?

      Now I have a powerful ancient overlord based on a new infrastructure, and configuring it is extremely simple. Flexibility and convenience are perfectly balanced, and most of my old pain points are resolved.

      I almost effortlessly switched a significant portion of my workflow to this setup. Now I use tmux with 5 windows, each window opens Neovim under a folder. In Neovim, the left side is the directory tree, the center is the code, and the right side is opencode and the terminal.

   2. Updated a version of Legion. I significantly reduced the text volume of the Legionmind skill (by about 4k lines). So far, it feels like it requires less oversight from me, but I’m not sure if it’s because I’ve been using smarter models recently or if this version of Legionmind has genuinely become smarter.

   3. Set up an OpenClaw. Minimax 2.1 is still a bit dumb, but as a personal assistant, I think OpenClaw is quite decent, because it’s essentially a ChatGPT with memory plus hands and feet (can operate my computer).

   4. Added HTTP-proxy functionality to Yuan, including metrics and such.

2. Any thoughts?

   Sometimes I feel that writing with AI is a bit like debugging code whose principles I don’t fully understand—constantly testing its behavior or printing logs to assist debugging, tweaking a bit here, adding a bit there, until I get a satisfactory result. Let me explore the origin of this feeling:

   The process of using AI to write code is that a human inputs a prompt containing specific instructions, hoping that the AI will understand the implicit instructions and information behind these instructions and correctly complete the task.

   The instructions intended for the AI can be stratified: the top layer is the instruction for the current task. Below that are some technical decisions made for this software project, best practices derived from trade-offs that apply locally to this project. The next layer is background information about the problem domain that the project aims to solve. The next layer is the professional background knowledge of the software engineering discipline using AI, including personal preferences, technical preferences, stylistic preferences, historical experience, and accumulated mindset. The bottom layer is the background knowledge of the world.

   In a conversation with AI, the only thing that can be clearly conveyed is the instruction for the current task, hoping that the AI has sufficient world background knowledge and background information needed to solve the problem.

   Therefore, it can be inferred that if the context of a task is small enough, the instructions are crystal clear, and there is no historical baggage, the AI should easily complete the task with high quality. If there is a lot of implicit background information, it can easily produce odd results.

   What Legionmind aims to do is to let the AI accumulate background knowledge and best practices about the project itself and the problem domain. This requires the AI to either have good logical thinking ability and memory (context capacity) or have abundant world background knowledge. Beyond these two, there is no way to salvage it.

   —

   Then I feel that Neovim is something I wish I had discovered much earlier.

3. What to do tomorrow?

   Tomorrow, I’m going to visit SC’s new home, play board games together, and also show snow gear to SY.

ZL came over, and there was a lot of information. I need to digest it. We played a board game, Circle of Tragedy. We spent three hours understanding the rules, and finally, in the last scenario, when I played the villainous playwright, I felt the sweet spot of the game. It ended with my complete victory.

Today was a day of restraint. I noticed a clear improvement in my emotional management since turning 25: I now have a sliver of rationality acting as a copilot alongside my emotions. That sliver serves as a control rod within the massive reactor of emotion. Without it, emotions would spiral out of control, triggering a self-amplifying chain reaction that could lead to countless irreversible consequences. With it, I start to see clearly what can and cannot be said, what can and cannot be done, and what decisions are permissible. This is a welcome change happening within me.

1. What I did today:

   1. Used Legion to design and implement an HTTP proxy for Yuan. It felt quite smooth. I reviewed its design, made a modification regarding one point (how to select an available terminal), then handed it over to the agent to go all out—the result was pretty good.
   2. Also used Legion to automate an update for Midas, but the AI performed poorly. It failed to correctly understand my requirements or how to use @yuants/protocol. I suspect a few causes: insufficient AI intelligence (DeepSeek may still be not smart enough); not strict enough review; or inadequate documentation/knowledge base.
   3. Damn it, I was woken up by an alert tonight. The host crashed inexplicably, apparently due to a CPU usage spike that put it into an unrecoverable state. The host logs are a mess. My verdict: alerts are useful, logs are garbage. Note this!

2. What I’m thinking:

   1. While showering, I pondered the critical points of my current collaboration with AI. First is the service availability of the AI agent itself—it shouldn’t just crash or exit midway. (Ralph Loop, by the way, basically works by brute-force retries to improve availability.) Second is how I accept the output from AI. For example, when subordinates report to superiors, they need a PPT or a specialized middle manager as an “expensive middleman.” How can AI’s report to humans be limited to plain Markdown and code? Shouldn’t each item in an AI report be linked to an artifact? Could we have a dedicated “Citation Agent” for this part?

      However, my current use of AI is quite limited, focused only on coding tasks.

   2. I carefully thought about why, after I built a multi-agent system, it’s steadily heading towards a ditch. I previously speculated three possible causes:

      1. The AI’s own intelligence level
      2. Insufficiently strict human review
      3. Insufficiently detailed knowledge base to provide accurate information for AI to quickly bootstrap

      Let’s examine these. Point 1 is obvious. Working on point 2 can indeed rely on an increasingly detailed RFC document to give subsequent steps a correct direction. But this development approach is like going back to the waterfall model: a linear process:

      Requirements Analysis -> Backend Design -> Backend Dev -> Frontend Dev -> Integration Testing
      

      The reasons are twofold: technical and organizational/process, with the latter being the primary factor.

      Technically, tasks have inherent dependencies: frontend must wait for backend APIs, backend must wait for product CRDs. In human organizations, waterfall development suffers from inefficiency, hard-to-detect quality risks, poor flexibility, and team conflicts. But in my collaboration with AI, efficiency and team conflicts don’t exist in the AI world. It’s like we live in different time dimensions—my day is like a year to AI. Inefficiency might cost more tokens, but that’s not my main concern. My real problem is quality risk from misunderstandings of requirements or facts, and poor flexibility.

      I need to find a way to maximize the use of AI’s capabilities while minimizing my own burden. Following the experience of human organizations, I must become a higher-level node in the command tree, able to confidently delegate to AI without it going off track.

      The two key points:

      1. Intent alignment
      2. Layered verification

      This needs further thought. I feel I need to use it more and savor it.

   3. I need to be cautious of the downsides of “if you have a hammer, everything looks like a nail”: path dependency and valuing output over understanding.

3. What to do tomorrow?

   ZL is coming tomorrow. Plan: exercise, have a meal, play some board games.

Today I went for a haircut. When I came back, I found the system was unstable. It turned out that Jige had started two terminal_id instances of the same service, which were preempting each other, causing a big problem.

1. What I did today:

   1. Tried to migrate the cluster behind NAT, of course using the brand new legion to do this. My operations were as follows:

      • First, modified the kops cluster, created a new VPC using CIDR blocks 172.21.0.0/24 and 172.21.1.0/24. Then created a NAT for egress traffic.

        Originally planned to use a CIDR starting with 10.0, but after trying, AWS didn’t allow creating such a CIDR, so I switched to a CIDR starting with 172.21. There was a pitfall: I needed to point the existing load balancer in the cluster resource to the corresponding VPC (originally it was implicitly default, but now with an additional CIDR, I had to manually specify it).

      • Then created a new instance group pointing to the new VPC. There was a small hiccup: the new IG did not have S3 permissions, for some reason. After manually adding them, nodes joined the cluster normally.

      • Next step: manually migrate services to the new IG.

      • Finally, tear down the original IG.

      After completing all this, I found that the cluster’s egress traffic had only one IP, which caused some trouble for our IP rate-limiting service. I had to roll back; I must first unlock the http proxy skill before proceeding.

   2. The multi-agent was used to practice a script to automatically update the midas net asset value. Deepseek took quite a while to write it, but I felt quite satisfied with it. There is a core issue: if I didn’t notice an error in the early design, then I would face a huge waste of tokens and time, because I found that the agent doesn’t work very fast either.

      Currently, these coding agents are still quite primitive. They often exit or crash due to network issues during use. Getting them to perform serious long-running tasks still has somewhat poor SLI. This could also be an opportunity; upon simple reflection, it requires some knowledge of software engineering high availability to make it work.

2. Thoughts: I have few thoughts today; they are all written inline in the above sections.

3. What to do tomorrow?

   1. Design Yuan’s http proxy mechanism.
   2. After going live, re-migrate the cluster.

Today I slept in until 11 o’clock and felt completely relaxed. It’s been a long time since I slept so freely.

1. What I did today:

   1. Deployed a new version of node-unit. I felt confident pushing it because I had thorough end-to-end tests. Specifically, I spun up a TimescaleDB (PostgreSQL 17) using Docker, then launched two node-unit instances, and inserted 21 @yuants/portal entries into the database to test. The final result converged to a state where each node-unit took half of the deployments.

      This test basically verifies that when a bunch of unowned deployments appear, and two node-units come online, you can observe them taking turns claiming deployments. If anything is missing, it’s one that actually occupies CPU/memory workload, and another scenario where a node-unit goes offline for some reason.

   2. Used the new multi-agent version of legionmind in Yuan to solve the issue of vendor-gate earn account outputting account flows. I had the agent first create documentation using legion, producing the following documents:

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      Feels like a decent workflow. However, there is some conflict between my new multi-agent system and the original legionmind’s documentation writing. I should carefully consider the boundaries of each thing—for example, the standards for how each document type should be written should be placed into separate skills, and legionmind should be a description of the workflow. Each agent should be able to load a few smaller skills to assist them in their work.

      Another issue is that during its first run, it made a mistake: it output the account flows into =account-actions-with-credential.ts=. This happened because I asked it to reference vendor-okx to complete the earn account integration—I did that because currently only OKX’s earn account is also connected as an account. But the AI also picked up some outdated practices from that. The current exchange integration standard is to publish all accounts via =provideExchangeServices=, not using =provideAccountActionsWithCredential= to connect accounts.

      This knowledge is not available to a brand-new AI agent. How should such knowledge be modeled? How can I provide this project context as an external brain for the AI agent? This is a question worth pondering deeply; I’ll need to think it over tomorrow.

   3. In the afternoon, I cooked to entertain sy’s friends—it exhausted me. So tomorrow I’ll continue working.

2. Thoughts:

   • As mentioned above, I need to carefully consider how to compactly design an external brain for an AI agent. The simplest approach could start with a set of AGENT.md files. I’ve tried this before, but maintaining those documents itself has a fairly high overhead. Distinguishing valuable experiences from noise is a difficult problem. Currently, memory is similar to other prompts, except the agent might have its own loop to update memory. The most important thing is still how to measure the results of the AI agent’s work.

   • Regarding the previous point, I came across an interesting article. Let me summarize it in my own words: First, evaluation of an agent’s single-step work can be categorized into several types:

     1. Static tool eval: compilers, linters, unit tests, e2e tests
     2. Model eval: using another LLM to judge based on our defined prompts
     3. Human eval: I judge

     Then, systematic evaluation of an agent has two types:

     1. Capability-oriented: Answers what the agent can do? And the pass rate might be low, e.g., using legion to gradually execute larger, harder tasks—like exploring a new frontier.
     2. Regression-oriented: Does it still retain previously gained abilities? For example, repeatedly testing certain tasks to ensure stable performance.

     Once a new capability is introduced, it should transition from capability-oriented to regression-oriented.

     The article also mentions two important metrics: pass@K and pass^K

     • pass@k: At least one success in k attempts. More attempts → higher probability of at least one success. Use case: You only care about “finding at least one viable solution.”

     • pass^k: All k attempts must succeed. More attempts → harder to maintain consistency. Use case: Users expect a reliable production agent every time.

     FYI: Reference article

   • My energy is still a bit low. I worked for a while in the afternoon and then cooked dinner, and felt quite tired. When will I become like CZ and not need sleep?

3. Plans for tomorrow:

   1. Think about the eval agent model, and continue iterating on the multi-agent system.
   2. Cluster security issues—must be tackled.
   3. Legion-github-bridge.

I caught a bit of a cold today, with a headache and low productivity. But I’m glad I started doing daily summaries.

1. What I did today:

   1. Designed a multi-agent system with the help of AI. The system hasn’t been thoroughly polished yet.
   2. Made another step forward on legionmind-github-bridge.
   3. Modified the preemption design and implementation of node-unit. Previously, when a node-unit failed, all its deployments would be cleared; now they are cleaned one by one.
   4. Took the exam for opening a futures account at CICC (China Financial Futures Exchange). It required the camera to be on the entire time, no minimizing or switching screens. Fortunately, there were unlimited attempts, which didn’t stump me — I passed with a high score of 95.

2. What I’m thinking:

   My goal is to achieve agent autonomy with minimal friction. Currently, my workflow is like this:

   1. legionmind serves as an SOP for development work; it’s an agent skill. I like agent skills.
   2. opencode is the entity of the agent. I used its capabilities like bash, tool calling, langraph, command, and subagent. If I ever decide to abandon opencode, these would be my to-do list for implementation.
   3. Right now, I’m struggling with how to combine skills with these sub-agents.

   I had a headache all day and only felt clearer in the evening. I realized that writing down these thoughts at the end of the day might not be a good approach. Perhaps I should only record facts, then summarize thoughts when I wake up tomorrow morning.

3. What I plan to do tomorrow?

   1. Do something with this multi-agent system — maybe connect the financial account of Gate.
   2. Continue with legionmind-github-bridge.
   3. Cluster security, if time allows.
   4. Resume time tracking for work. (Important)
   5. My friends from sy will visit tomorrow, so work time may be preempted.