# I wrote 1,100 pages of notes over five years, and an AI convinced me to turn them into seven books. > Source: > Published: 2026-09-21 09:36:20+00:00 Five years ago, when I started writing technical notes, I had no intention of writing books. At first it was just personal interest. I'd summarize things I'd built and post them online. Back then I was messing around with Linux basics:`ls`, `more`, that sort of thing. I was in grad school, so most of what I wrote was study notes. But the habit stuck. Later I interned at a few companies. My program allowed long internships, about a year. That's when I first touched production code. The writing was purely work-driven. One day I'd be chasing a PTP bug, the next a UDS exception, the day after that an HSM driver issue. Don't ask why I was juggling so many modules. Startups are like that. Every time I crawled out of a pit, I wrote it down. How I found it, how I investigated it, how I fixed it, what the root cause was. Every time I touched a new module, I wrote docs too. What it does, how it's architected, how to use it, how to test it. Some notes were under 500 words. Some were four or five thousand. I had to write them. Otherwise the next time the same problem showed up, I'd be starting from zero. Sometimes I'd finish debugging at 11 p.m. and still open a doc to jot things down. If I didn't do it then, I wouldn't do it the next day. The work ranged from SoC to MCU, from Linux to QNX to AUTOSAR, from time synchronization to diagnostics to hardware security. I wasn't chasing breadth on purpose. The projects needed what they needed. I just wrote things down as I went. A year of that added up to about a hundred notes. Three years, several hundred notes, roughly 1,100 pages I can still find. One day I got curious and fed those notes into an AI. I asked: "How would you rate my technical skill?" It gave me a long answer. It said my range covered everything from the application layer down to the driver layer and the hardware layer. It said the depth looked solid: the kind you only get from writing code and stepping on landmines yourself. It also said my habit of chasing a problem from symptom to source to waveform was relatively rare. Then it added: "If you organize these into books, you could probably help a lot of people." It must have recognized something underneath those 1,100 pages: a complete technical skeleton. How a chip boots. How time gets synchronized. How diagnostics communicate. How a file system stores data. How safety is guaranteed. It was already a coherent thing. I just hadn't noticed while I was writing it. The AI did. But the notes were only the surface. The deeper reason was that I wanted to understand the whole system. I wrote about that in the preface to *from-sand-to-ruts*. So I spent a few months organizing those notes. But organizing is not the same as stitching things together. The notes were scattered. One was a module intro, another a debugging story, and they spanned 2022 to 2026. If I just dumped them into one pile, nobody would read it. So I came up with a new structure. I grouped everything by module. PTP with PTP, UDS with UDS, HSM with HSM. Each group became its own book. Each book focuses on one topic. Then I wrote each one from scratch, starting from thought experiments and core concepts and ending with teaching-grade source code. In other words, those 1,100 pages were more like proof. Proof that I'd written code for these modules and solved problems in them. The books themselves weren't copied from the notes. The real sources were protocol standards, open source code, real cases, and my own understanding. The notes just proved I'd been there. The books were rewritten. That took months. Every chapter went through many rounds. How do I explain PTP so people don't close the page after the first paragraph? Which of the many UDS services actually matter? How do I explain LittleFS's CTZ linked list in a few sentences? AI played a key role here. I specified the architecture of each book, provided the material and cases, and told it which technical path to take and from what angle. It helped generate text and smooth out the writing, saving a lot of mechanical work. But every technical judgment, every tradeoff, every key architectural decision was mine. That process went through many iterations until each book's structure and phrasing felt acceptable. Then there were seven books: `ptp-lite`.` hsm-lite`.` KnotFS`, around 1,770 lines of C.` uds-lite`.` safe-lite`.` eng-lite`, around 700 lines. They are not a collection of those 1,100 pages. They grew out of those notes into something complete. The semiconductor manufacturing part in the overview is based on real experience. After my undergraduate degree and before grad school, I worked at a panel factory as a yield engineer for a few years. All seven books are open source on GitHub. Even though the series is called "Automotive Electronics Seven," the content is not limited to the automotive industry. Anyone interested in how computers work from the ground up, from sand to system, can read it. From semiconductor physics to operating systems, from communication protocols to functional safety, the series tries to answer a more fundamental question: **what kind of world does the code we write every day actually run in?** The books are currently in Chinese. I plan to translate them into English gradually. The code and architecture diagrams are already language agnostic, so you can still get a lot out of them. If that question interests you, start with the overview: [https://github.com/Lularible/from-sand-to-ruts](https://github.com/Lularible/from-sand-to-ruts) If you find it useful, a star is the best support.