tgo Devlog #3: Taming Context Windows, Compiling Lodash, and the Repetitive Reality of True Ownership

A developer building tgo, a TypeScript-to-Go compiler, reports progress on supporting Node libraries and compiling Lodash, with 122 of 316 entry points still failing. The project's complexity forced a complete overhaul of the test runner and heavy caching, while managing AI context windows required strict workflows for four task types. The developer draws parallels between managing AI and managing people, emphasizing the need for repetitive guidance.

I’ve been making massive headway on tgo, my TypeScript to Go compiler library, but it is forcing me to confront some hard realities about how I manage systems, AI, and even people. Since the last devlog, I’ve added full support for Node libraries— fs , path , process , and a few others. Right now, I’m in the trenches trying to compile Lodash, argparse , and date-fns . I pushed date-fns to the side for a minute because Lodash is proving to be the perfect stress test. It is, frankly, obnoxious. In some cases, the code is just very poorly written. Lodash has 316 different entry points. Right now, 122 are failing. But dealing with this massive, complex library has forced me to completely overhaul my test runner. I’ve built it so that you can choose specific entry points and compile only what you need—similar to how ES bundle works. I’ve also implemented heavy caching. If you are continually rebuilding, it won't re-compile the source to Go every single time; it just handles the binary compilation unless something actually changed. It’s significantly faster. But as this project scales, the sheer complexity is threatening to break the system—and by the system, I mean the AI I am using to build it. I do most of this development through AI, and getting an LLM to consistently output good software engineering without breaking existing features is incredibly difficult. I was constantly blowing out the context window. Even at 200,000 tokens, it wasn't enough. By the time the AI figured out what to do, it would start summarizing the context and immediately start doing a terrible job. This forced me to narrow down all possibilities. I realized there are really only four things I am ever asking the AI to do: That’s it. I defined strict workflows for those four pathways. If I ask it to fix a bug, it has to run the specific test, read the JavaScript, read the outputted Go code, and reproduce it with a unit test. I spent a ton of time programming the AI "out of the box" so it doesn't try to read the entire codebase and break things. I also had to learn the hard way to stop mixing code changes. I was implementing two features at once, one became hostage to the other, and it took hours to untangle the unit tests. Do one thing at a time. If you want to do two, use two different repos. Now, I am using the 1-million token context window, but I have to watch it like a hawk. When you are halfway through, every single request is sending 500,000 tokens back and forth. You can't just close your eyes and keep rocking. You have to be deliberate. Here is the biggest life lesson that tgo is hammering into my skull: Managing AI is exactly like managing people. For years, I've worked with people across different functions, and one of the most frustrating things is feeling like you constantly have to look over someone's shoulder. You think to yourself, "How do I build a better system so I don't have to constantly remind them to do the basics?" Working with AI has shown me that this might be a fool's errand. You are fighting the wind. I built all these rules, workflows, and documentations for the AI, and I found myself getting incredibly annoyed when it wouldn't go read them. I would have to tell it, "Go read the docs," every single time. Then it hit me: Why am I getting mad at reality? I have just accepted that I have to encourage it to do the one right thing right out of the gate, every single time. I now preemptively say "go read the docs" on the initial request. This translates perfectly to human leadership. Let's say you need your team to update the documentation after they learn something new. If your mindset is wrong, you will come to hate having to tell them to update the system. You will blame them. You will think, "Why should I have to say this three times?" Because that's the job. You have to get okay with saying it every single time. And if it doesn't get done, you need to start blaming yourself for failing to remind them. Giving a tip or a reminder dramatically improves the odds of success. It might take 20 times for them to consistently do it on their own. But as a leader, your frustration doesn't write code, and it doesn't build businesses. Stop complaining about the repetition. Accept the reality of the machine you are operating, take extreme ownership of the process, and get back to work.