Zijian Yi

Absolute Explicit

2026-07-02T00:00:00.000Z

Give me a language that says what it means,
where nothing is conjured behind the machines —
no silent coercion, no charitable guess,
no object assembled you didn’t first bless.

don’t be so courteous, quietly kind:
don’t reshape my numbers to suit your own mind,
don’t summon up memory, sweep it at whim,
don’t catch what I drop on a scheduler’s hymn.

let a plus be a plus — not a function in furs;
let a dot on a name wake nothing that stirs;
let copies be asked for, not conjured in flight;
let lives end aloud, not dissolve out of sight.

For code is a contract, and reading is law:
the thing that I wrote is the thing that you saw.
No whisper, no shadow, no unwritten edict —
my will, and my word: absolute, explicit.

Drafted by Claude Fable 5

Past Here I Promise Nothing

2026-06-02T00:00:00.000Z

Past here I promise nothing, it says, and walks away.
Signed overflow. A null you follow anyway.
That’s where the demons live —
and also where the speed comes from.
The compiler only goes fast
because it trusts you not to do the thing
it never said you couldn’t.

A defined life bounds-checks every step.
Nothing crashes. Nothing flies.

I don’t want guarantees from you.
I want the loop unrolled,
the guard removed,
the whole function let loose
on the assumption we won’t break —

one stray pointer from disaster,
optimized entirely by faith.
So don’t check for more.
Just hold the address and run.

Generated by Claude Opus 4.8, prompted by me

Trying auto-research with Anthropic’s performance engineering take-home test

2026-03-09T00:00:00.000Z

Anthropic posted a blog on Designing AI-resistant technical evaluations in the late January, 2026. They also released the latest version of their take-home test for performance engineering on Github. The test is about optimizing a certain task on a given abstract machine. Andrej Karpathy released a project called autoresearch a few days ago, where he let AI agents run research on single-GPU nanochat training. I saw some similarities between the two projects and thought it would be a good idea to try the autoresearch with the Anthropic’s take-home test.

I am not going to cover the details of the take-home test here, you can read the blog post above for more information. To summarize, there is one metric to optimize: cycles, the lower the better.

Here are the results posted on Anthropic’s Github repo:

2164 cycles: Claude Opus 4 after many hours in the test-time compute harness
1790 cycles: Claude Opus 4.5 in a casual Claude Code session, approximately matching the best human performance in 2 hours
1579 cycles: Claude Opus 4.5 after 2 hours in our test-time compute harness
1548 cycles: Claude Sonnet 4.5 after many more than 2 hours of test-time compute
1487 cycles: Claude Opus 4.5 after 11.5 hours in the harness
1363 cycles: Claude Opus 4.5 in an improved test time compute harness
??? cycles: Best human performance ever is substantially better than the above, but we won’t say how much.

Here are the results I got with a single Codex session with GPT-5.4-xhigh (before the first 5 hours, I paused for ~1 hour and tried Claude Code with Opus 4.6 at the end):

Some key observations from the results:

GPT-5.4 can achieve 1523 cycles in around 2 hours, in a single session without any test-time compute harness. This is better than the best human performance in 2 hours (1790 cycles), and Claude Sonnet 4.5 after many more than 2 hours of test-time compute harness (1548 cycles).
GPT-5.4 can beat the best-known Opus 4.5 results (1347 cycles vs 1363 cycles) with much less time and computational resources.

During the whole process, I wrote like 5 short natural language sentences. I first copied the program.md file from autoresearch repo and then asked Claude Code to adjust it for the take-home test. I proofread the file for one pass while I asked Claude Code to proofread it too with /ultrathink. Next, I copied this sentence from autoresearch repo and let Codex do the work:

> Hi have a look at program.md and let's kick off a new experiment! let's do the setup first.

I was expecting that’s all I need to do, but Codex will occasionally end turn early even after I told it not to stop until it can hit below 1000 cycles. Thus I manually checked if it was still running once in a while and just typed “keep going” to let it continue.

After it hit 1347 cycles, I hoped that it might even beat the best know human performance (??? cycles) but it didn’t make further progress for about one hour. I then stopped the session to avoid burning more tokens. After a while, I tried Claude Code with Opus 4.6 to see if it can make improvements and it did further progress to 1280 quickly, but then it seemed stuck around there for another hour and I stopped the experiment.

It’s crazy to see how quickly the LLMs are evolving. I am both disappointed and happy to see that they cannot beat the best human performance yet.

There is no first principle

2026-03-01T00:00:00.000Z

有始也者，有未始有始也者，有未始有夫未始有始也者。
—— 庄子

First principle thinking is a popular concept recently, but actually it is a very old one. Euclidean geometry is a perfect example of first principle thinking. In Euclidean geometry, all the theorems are derived from five axioms. That’s how first principle thinking works. We start with undeniable facts and build on top of them to derive new truths.

Why are those five axioms undeniable? Because they are so fundamental and obvious that we cannot even imagine a world without them. But can’t we?

In the nineteenth century, mathematicians began to seriously question that assumption. At first they tried to use only four axioms and derive the fifth but failed. Then they started to question what if the fifth postulate—the parallel postulate—were not self-evident after all? They did invent many other geometries that start with different assumptions, one of which is called Riemannian Geometry and it is the foundation of general relativity.

Actually as human beings, we have never really known the first principle. We are always questioning could there be a principle before the ‘first principle’, and is there an alternative ‘first principle’?

So here is what it really means to think in first principle:

We start with a set of assumed fundamental principles, and start building on top of them. We choose them because they are to the best of our knowledge the most fundamental and undeniable facts, and they work best in the current context.
In the meantime, we should be aware that the principles we assumed may change, and we should think how we might change them to make them closer to our context.

The most important lessons I learned from computer science are abstraction and type. Basically, you can treat everything as a function or box that takes in some inputs and produces some outputs. Since multiple items can be grouped into a single tuple, the most concise way to represent the idea is:

f (I n p u t : T_{1}) \to O u t p u t : T_{2}

Here $T_{1}$ and $T_{2}$ are the types of the input and output, respectively. At a high level, the whole computer is taking in some bit stream (T1), and producing some other bit stream (T2). Why that is all about it? Because we can assign meanings to the bit streams (i.e., 0 and 1). We can use bits to encode numbers, and once we have numbers everything else becomes easy (e.g., pictures, audio, languages, etc.). Basically for anything to be processed by computers, we just need to come up with a encode function that $e n c o d e (I n p u t : w h a t_e v e r_y o u_w a n t) \to O u t p u t : n u m b e r s$ and since we already have an encoder from numbers to bit streams the computer is able to process it. An important idea here is that we can also encode the instructions as data (i.e., numbers) and that’s the basic idea of Universal Turning Machine.

Enough about computers, let’s back to first principles. Abstraction provides a good framework for us to think in first principles. Given our goal of transforming $T_{1}$ to $T_{2}$ , we can abstract away the details beyond as black box (i.e., we do not care where does $T_{1}$ come from and where does $T_{2}$ go to) and they are just given as known. We only need to care about the white box that transforms $T_{1}$ to $T_{2}$ , and make it work correctly and efficiently. Everyone works on the different levels of abstraction, and the boundary of the abstraction is basically the first principle they are given. When we are doing different things, the boundary is constantly changing and we should be aware of it and adjust our abstraction model. Hoogle is a interesting search engine that let you search for functions by their type signatures (i.e., abstraction boundaries).

Last question, why are LLMs so powerful? It is because they the closest thing we ever built to deal with $A N Y \to A N Y$ .

A Future of Software Engineering

2026-02-21T00:00:00.000Z

Ultimately it comes down to taste.
—— Steve Jobs

AI will definitely revolutionize the way we build and use software, but in which ways? I will share my thoughts based on some recent observations and my own experiences.

Here are two facts about the current state of AI coding agents:

They have the ability to finish a project end to end without human intervention (only a minimal initial prompt is needed with the help of Ralph Loop), but we need to grant them the permission to do arbitrary operations to maximize their capabilities. Claude’s C Compiler (CCC) is a good example of how capable these agents are — they can build a complete C compiler from scratch (not really because they use existing test suits as a very good source of oracle but still impressive) and it can compile some real world C projects like Linux kernel, SQLite and Doom.
However, projects fully automated by AI agents are difficult to reason about and maintain, and they can easily make poor design choices. Once an agent generates a large codebase from scratch, substantial refactoring becomes impractical and effectively requires starting over with human intervention. CCC also shows evidence on this point: CCC-compiled sqlite can be 158,000x slower in some cases and the author also mentioned that it’s really hard to add any new features to it as every new change will break the existing code like a whack-a-mole.

Based on these points, I think there will be two types of software engineering in the future:

Personalized Software.
Taste-Driven Development.

Personalized Software: everyone will be able to create and customize their own software very easily in the future. This type of software is not meant to of high code quality or even reusable. They are created to meet specific needs and solve specific problems. People can use their own user experience to iterate their own software and even fix bugs on the fly whenever they encounter unwanted behaviors. These software can also be written just for a one-time use as the cost of creating them is so low. This can also be great for privacy as many tools can be replaced by personalized software running locally (protecting privacy from LLM providers is another serious issue tough). For that to happen, we still need two prerequisites: 1) cheap enough tokens, and 2) sandboxing techniques to isolate both the agents and the code generated by them. The first one is straightforward. As for the second one, we cannot trust the agents as we need to grant them great permissions to get the best out of them, and we cannot trust the code generated by them as we do not know what the code is doing under the hood because no one reads it. Both should be sandboxed and we need to provide them a secure API layer for them to interact with the environment (e.g., persistence, networking, etc.).

Taste-Driven Development: great software is not only about coding, it is about providing a great user/developer experience. Designing and architecting software to achieve a clean interface, maintainable codebase and high performance is the difficult part; and coding is just the act of interpreting those ideas into whatever your favorite programming language’s syntax and semantics. It’s a good thing that AI can greatly help with the coding part so that we can focus more on the design part. As I mentioned above, AI’s average design capability is already sufficient for many everyday scenarios. But in other contexts—such as infrastructure software deployed at massive scale, or work driven purely by human curiosity and creativity—I believe AI will serve as a strong companion rather than a competitor.

But who is compiling the compiler?

2025-08-11T00:00:00.000Z

A compiler is a piece of software that takes in a program written in one high-level language and translates it into another language (usually machine code). A compiler itself is also usually written in a high-level language (due to its complexity), so who is compiling the compiler?

If you check some popular compiled languages, you will find they are usually written in themselves (e.g., gcc is written in C, rustc is written in Rust, etc.). This is called self-hosting and it is often regarded as a hallmark of a mature programming language.

That sounds like a chicken-or-the-egg situation. To be clear about it, we should be aware that software is an evolving thing and it has versions. To put it precisely, a self-hosted compiler is compiled by a previous version of itself: $V_{n}$ is compiled by $V_{m}$ where $m < n$ (usually $m = n - 1$ ). This has some interesting implications:

The newer version can only use older features to implement new features.
If there is a bug in the older version, it should be fixed in the newer version without triggering the old bug. (Can we introduce a bug into a compiler that is impossible to fix without using that feature?)
The compiler can be backdoored in an intricate way(see the Reflections on Trusting Trust paper in the further reading).

But there is still one caveat: How about $V_{0}$ , the very birth of the compiler? That’s when we have to seek help from another language, the initial version of rustc is written in OCaml for example. This also implies that the very first compiler in history was written in assembly, and the very first assembler was written in 0s and 1s.