{"slug": "i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them", "title": "I wrote 1,100 pages of notes over five years, and an AI convinced me to turn them into seven books.", "summary": "A developer who accumulated roughly 1,100 pages of technical notes over five years turned them into seven books after an AI review of the notes identified a coherent technical skeleton spanning application, driver, and hardware layers. The notes, covering PTP, UDS, HSM, Linux, QNX, and AUTOSAR work, served as proof of hands-on experience, while the books themselves were rewritten from scratch using protocol standards, open source code, and real cases, with AI assisting in structuring and drafting each volume.", "body_md": "Five years ago, when I started writing technical notes, I had no intention of writing books.\n\nAt 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.\n\nLater 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.\n\nSome notes were under 500 words. Some were four or five thousand.\n\nI 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.\n\nThe 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.\n\nThree years, several hundred notes, roughly 1,100 pages I can still find.\n\nOne day I got curious and fed those notes into an AI. I asked:\n\n\"How would you rate my technical skill?\"\n\nIt 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.\n\nThen it added:\n\n\"If you organize these into books, you could probably help a lot of people.\"\n\nIt 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.\n\nBut 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*.\n\nSo 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.\n\nSo 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.\n\nIn 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.\n\nThat 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?\n\nAI 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.\n\nThen there were seven books:\n\n`ptp-lite`.` hsm-lite`.` KnotFS`, around 1,770 lines of C.` uds-lite`.` safe-lite`.` eng-lite`, around 700 lines.\nThey are not a collection of those 1,100 pages. They grew out of those notes into something complete.\n\nThe 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.\n\nAll seven books are open source on GitHub.\n\nEven 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.\n\nFrom 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?**\n\nThe 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.\n\nIf that question interests you, start with the overview:\n\n[https://github.com/Lularible/from-sand-to-ruts](https://github.com/Lularible/from-sand-to-ruts)\n\nIf you find it useful, a star is the best support.", "url": "https://wpnews.pro/news/i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them", "canonical_source": "https://dev.to/lularible/i-wrote-1100-pages-of-notes-over-five-years-an-ai-convinced-me-to-turn-them-into-seven-books-13j7", "published_at": "2026-09-21 09:36:20+00:00", "updated_at": "2026-09-21 09:53:58.869814+00:00", "lang": "en", "topics": ["ai-tools", "artificial-intelligence", "generative-ai"], "entities": ["Linux", "QNX", "AUTOSAR", "PTP", "UDS", "HSM", "LittleFS"], "alternates": {"html": "https://wpnews.pro/news/i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them", "markdown": "https://wpnews.pro/news/i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them.md", "text": "https://wpnews.pro/news/i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them.txt", "jsonld": "https://wpnews.pro/news/i-wrote-1100-pages-of-notes-over-five-years-and-an-ai-convinced-me-to-turn-them.jsonld"}}