I've been writing code for more than 35 years, a large part of that professionally, but I've probably written most of my code as a hobby. I've written plenty of C, PHP, Go, JavaScript, Solidity, Python, and other languages.
So, this is not about someone with no development expertise one-shotting a project.
On the other hand, I’m not fluent in Zig.
Do you remember when you started learning a second language, and at some point you could understand what people were saying, but could only say very basic things? This is where I am with Zig. I can read Zig, but my writing skills are really lagging.
This distinction was mostly pointless in the past, but makes total sense when AI can write most of the code.
IMO, reading code is becoming more important than writing code, and this also affects programming languages. It is one of the reasons I like Zig. I find it much easier to read than, for example, Rust. There are fewer idioms and abstractions to mentally unpack. Zig may be harder to write, but for me it is considerably easier to read.
It’s also good to keep in mind that Unicode, as a problem, was extremely well-suited for AI development.
There are detailed specifications defining how things should work, official compliance tests, and mature implementations in other languages against which you can benchmark correctness and performance.
There are relatively objective answers to “Does this thing work?” and “How well does it work?”
People often compare AI with the Industrial Revolution, and during this project that comparison became much more concrete to me. The Industrial Revolution replaced a good part of labor with capital. What used to require human hands could be accomplished faster and more efficiently by machines.
Building with AI felt like going from working in my little workshop to having a factory, pumping out code and running tests and benchmarks at a scale orders of magnitude beyond what I could do by hand.
And it didn’t just scale what I could do. It gave me “specialized machines” for domains where I don't have expertise: Unicode <sup>1</sup>, LLVM optimization, test suites. I didn’t need to know Rust to build benchmarks comparing zunic to popular Rust libraries. I haven't touched a decompiler for decades, but I could ask an agent to inspect binaries and see how inlining a function affected the generated code.
In other words, a big chunk of the intellectual labor was replaced by the capital I spent on AI agent subscriptions.
But when everyone can scale up their capacity, it doesn't necessarily mean you can build more. It may mean you need to build better.
If high-quality, up-to-date documentation is cheap, every project will be expected to have it. The same goes for testing, optimization, security, and cross-platform compatibility. The baseline for what counts as finished software has gone up. The factory doesn't just produce more products, it changes what customers expect a product to be.
My goal wasn't simply to produce a library that could process Unicode according to the standards. I wanted it to be fast — if possible, the fastest implementation available in Zig — with a reasonable memory and binary footprint, and an API that felt consistent and convenient.
Parsing Unicode efficiently comes with interesting decisions.
For example, ASCII characters are encoded as one byte in UTF-8, while other Unicode code points can require up to four. It is easy to provide fast lanes for ASCII, but doing so introduces extra checks or branches that may slow down other inputs. What’s the best balance? #
Unicode grapheme clusters — what users tend to perceive as individual characters — can in principle contain an unbounded number of code points. Do you impose limits or not? #
Parsing Unicode requires a lot of state machines that can be replaced by lookup tables for dramatic speed improvements, at the cost of memory footprint. Where this actually makes sense is subjective and depends on the problem you are trying to solve. #
Implementing the whole body of Unicode standards is a herculean task. Which parts actually matter to your users?
These are just a few of the decisions I had to make while building it, and each came with compromises the AI agent couldn’t make by itself.
Sure, now that I've gone through the process, I could include all these decisions and directions in the original project goals. But this doesn’t make engineers redundant, it makes them more valuable.
An experienced engineer with domain expertise can describe the desired outcome better than a junior, and orders of magnitude better than someone with no software engineering background.
It’s not just that an experienced engineer will need fewer tokens. It’s about being able to describe the shape of the result.
AI can implement a lookup table, an ASCII fast path, a stateful API. But someone still has to understand the consequences and choose: speed vs memory, ASCII vs general Unicode, convenience vs allocations, binary size vs specialization.
Technical judgment becomes the scarce skill.
The library is zunic —pronounced ZOO-nik. During the process I kept thinking: why am I building this when anyone can ask an AI agent to build a Unicode library that fits their needs?
It’s simple.
If you are a better developer than I am, understand Unicode better than I do, and want to spend some dollars and a week working on it, you will probably get what I ended up with or something better.
If not, you can use [zunic](https://github.com/vrypan/zunic), which encapsulates my expertise, my decisions, and the outcome of exploring alternative ways to implement each of its pieces.
AI made all of that much cheaper to produce. It didn't make it free.
If this sounds lame, just visit [https://unicode.org/main.html](https://unicode.org/main.html) , Unicode is
a huge spec.[↩](#fnref-1)