DEV Community: Mike Cornwell

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

Mike Cornwell — Fri, 26 Jun 2026 04:00:00 +0000

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.

The Cost of Scaling Complexity

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.

Process is Survival

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:

Update the test runner.
Fix a bug.
Implement a new feature.
Work on a library.

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.

The Context Trap and Feature Creep

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.

The Hard Truth About Leadership

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.

Stop Complaining and Own the Process

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.

tgo Dev Log #2: Compiling UUIDs, Async Goroutines, and the Lodash Nightmare

Mike Cornwell — Thu, 25 Jun 2026 13:57:41 +0000

I am about two and a half weeks into building tgo (my TypeScript to Go compiler). Over the weekend, I hit a massive milestone: I officially have the UUID library (both v12 and v13) compiling, running, and passing all of its included unit tests natively in Go.

That is a big fucking deal.

On top of that, I built out the package importing system. You can now do an NPM install, configure the tgo compiler to point to the source, and bada bing, bada boom—it pulls it in. I also added precompilation optimizations. If you aren't changing the library, it precompiles those dependencies into Go and only updates your specific code changes when you run the compiler. It speeds the whole dev loop up significantly.

Getting the UUID unit tests to run completely was awesome. But it's also a testament to the emotional swings of building something this complex. You get an idea, you implement it, you get positive feedback, and you're like, Hell yeah. But then the reality seeps in of how ridiculously hard the next level is.

The AI Wall and the Need for Rigid TDD

Right now, this repository is officially one of the largest I have worked with in a long time. There are so many things to handle—from bridging the Node standard library to Go, to creating TypeScript-level linkers.

Because the project is so massive, it is starting to challenge the AI tools I'm using. I had to turn Cursor onto the 1-million-token context window. By the time the AI got enough context to understand what was happening, it had to summarize and obliterate its own thinking just to tackle the problem. Worse, AI wants to just hop in and change code to make a specific scenario work. When it does that in a codebase this deeply interconnected, it wrecks all the previous scenarios.

This forced me to get religious about TDD (Test-Driven Development). My scenario runner inputs an AST (Abstract Syntax Tree) and spits out string code. I have to force the AI to respect these scenarios, otherwise, the regressions will kill the project.

The Lodash Nightmare

I needed an entry point library, so I got argparse working. But then I looked at lodash. My god, compiling Lodash has been a fucking nightmare.

I have used Lodash on the backend forever. But when you are writing a compiler, you have to look at the internals to figure out why things aren't running. Inside Lodash, there are so many obscure, low-level, weird JavaScript tricks going on. It is heavily using state, constructors, and globals. It physically hurts the head to look at.

This is exactly why I want tgo to exist. I want developers to write expressive, high-level functional TypeScript—like maps and reduces—and have the compiler optimize that into ridiculously speedy Go for loops behind the scenes. You shouldn't have to write annoyingly obscure, low-level JavaScript just to get performance.

Async/Await to Native Goroutines

Amidst the frustration with Lodash, we had a massive win: Promises.

We implemented Promises so that they map directly to Goroutines. When you write async and await in TypeScript now, tgo runs those as independent Go routines. Depending on what your application is doing, you can get massive, huge increases in parallel performance directly out of the box.

The Hard Numbers: Performance Testing

I've been building out performance tests, and I want to be totally transparent: Go is not always faster out of the gate.

I wrote a test to compute a million primes. When you run this using standard JavaScript numbers (which are floats), Node absolutely kicks the crap out of Go. Node's engine is incredibly optimized for float modulation.

However, if you explicitly type your TypeScript numbers as BigInt (which forces direct integer math) and you run it in parallel? Go absolutely smokes Node.

Here are the raw results from the latest scenario runner:

Scenario	Total Time	tsx	node	go	node → go
perf-compute-primes-million (Float, Serial)	10.87s	1.83s	1.74s	6.74s	0.3x
perf-compute-primes-million-bigint (Int, Serial)	14.02s	5.18s	5.71s	2.70s	2.1x
perf-compute-primes-million-bigint-parallel (Int)	12.01s	5.26s	5.56s	703ms	7.9x
perf-compute-primes-million-parallel (Float)	5.81s	1.87s	1.71s	1.83s	0.9x
perf-compute-primes-thousand	622ms	150ms	30ms	26ms	1.2x

(Note: 5 passing in 43.34s total. Average across all tests: 1.2x. node 14.74s vs go 12.00s)

It is going to be difficult for the compiler to automatically infer an integer over a float without explicitly being told via BigInt, so we will leave these tests in as a benchmark for where we can improve.

Next up: diving deeper into complex type systems like my Functional Models library. I'm going to keep plugging away.

tgo Dev Log #1: Writing Strict TypeScript, Compiling to Native Go

Mike Cornwell — Mon, 22 Jun 2026 14:25:57 +0000

I’m a little further ahead in this project than I’d like to be to just start a dev log, but I'm going to do it anyway. Moving forward, I want to treat this as a daily log—a place to dump my thoughts, the hard realities, and the technical pivots of what I'm building.

The project is called tgo (t-G-O). The reason for the name is simple: "tsgo" was already taken by Microsoft when they wanted to create a compiler chain and checker for TypeScript written in Go. When I first heard about their project, I actually thought they were doing what I’m doing—writing TypeScript and producing compiled Go. They aren't. But I am.

And so far, the results are wildly compelling.

If you've built complex systems, you know the cycle. You get real hot on an idea, you go down the rabbit hole, and then you hit a wall. The classic feelings of inadequacy creep in. You start wondering, Is this actually going to work? Will it be good enough? But then there are the moments where you get over the hurdle, look at the output, and go, This shit motherfucking works.

From V1 Chaos to V2 Precision

Right now, we are on version two of the compiler. V1 was basically me just throwing stuff at the wall. It was a rough attempt to create an intermediate representation and write it out as strings. The result? Massive, 5,000-line files. Crazy nested logic. Switch statements and if/else blocks spanning a thousand lines.

To manage this scale of abstract code, I am using AI heavily—but I am strictly controlling the process.

I took all my past experiences in development and decided to anchor this entire project to a rigid Test-Driven Development (TDD) process. I’ve known about TDD my whole career. I’m a massive advocate for unit tests, 100% code coverage, and edge-case testing because I build platforms and libraries that people depend on. But this compiler is different. It is astronomically complex and pretty fucking hard.

Every single inch we move forward is driven by a scenario. We want to implement a new feature, a refactor, or support a new library? We write the scenario first. We run it. We make sure it fails. We look at the converted TypeScript-to-Go output, and then we write the changes. It is the only way to prevent regressions.

The Wins: Speedy as Hell

I am trying to make this compiler output code that is speedy as hell, and the results are already in.

We ran a performance test against standard Node generating UUIDs (calling Node's randomUUID() function a million times). tgo is slower by about 0.1% on pure generation. However, when we take that same test and add a deduplication confirmation to ensure all one million hashes are unique, tgo is an 8x speedup. It is monumentally faster.

To make this work, we’ve actually had to build a Go standard library that effectively replaces the Node/JavaScript standard libraries. I can currently compile the "uuid" library and run it as a package to a Go library, or drop the full source code inside an application as a folder, and the whole thing just works. Validations, UUID v5s, binary operations, arrays, buffers—it works, and it matches external expectations perfectly.

The Hard Engineering Realities

We chose Go primarily because of memory management. I looked at C++, but the lack of a garbage collector meant memory management would become astronomically complicated—effectively requiring me to invent a garbage collector just to handle things like instantiating new objects.

But Go comes with its own limitations. Go doesn't support "OR-ing" on types. It doesn't have JavaScript's version of truthiness (where undefined and null are separate things but work similarly in truthiness evaluations). Go just has a nil concept.

The core philosophy of tgo is this: You are a TypeScript developer. You shouldn't have to care about Go. You write TypeScript, think in TypeScript, and you get the exact same expected results, just running natively in Go.

To pull that off, we're doing deep work on polymorphism. I want to build structs that are generated at compile time with minimal name-mangling so the code remains intelligible. We are aggressively avoiding dynamic types, interfaces, and anys so the compiled Go code stays fast. If the TypeScript inference gets into any territory, it gets boxed into an interface, and it just won't run as fast.

We are constantly hitting limitations—like handling casting (as unknown as)—and we will publish a full list of these limitations. The compiler will eventually warn you as early as possible when you do something that Go fundamentally cannot do.

The Ultimate Vision

Once we clear these major hurdles—like compiling my highly-generic Functional Models library, which has layers of complex type inference—the endgame is clear.

This is for developers who want to write in one language. You write your front end in React. You use the exact same TypeScript libraries, typing, and interfaces for your back end. Then, tgo compiles your back end into ridiculously fast, memory-efficient Go.

But there is a catch. This compiler is going to force you to be a better developer. You have to have good typing. You can't have jacked-up typing where you bypass the TypeScript system. If you try to cheat the compiler, you're going to run into trouble.

We have about 170 tests passing right now. The next major milestone is getting deep polymorphism fully dialed in.

I’ll keep updating this log as we push forward.