DEV Community: Mike Cornwell

tgo Dev Log #8 - I'm giving up. Lodash is too hard to compile.

Mike Cornwell — Tue, 07 Jul 2026 18:39:29 +0000

I have taken a break from working intensely on tgo for the last four days. Prior to this, I worked for probably three weeks straight, every single day, including Sundays, just getting this engine going. I pushed it to a point where things were stable, and then, as happens with these massive architectural shifts, things became really unstable again. So I pulled back, put in the work to make it much more stable, and took a breather.

But now I’m back, and I’m making a decision to try a new approach for Lodash and similar legacy libraries.

Why Don't I Just Hardcode This?

At the end of the day, we are going to have to inject custom typing for some of these foundational libraries. These are legacy JavaScript libraries. They are pretty stable, but because of their JS legacy, they aren't updated constantly, and I don't anticipate them expanding much beyond standard bug fixes. I think I'm going to try just adding typing.

Let's call them typing hints

The frustrating part is that I just want to actually use this damn tool I'm building, and I am being bottlenecked by getting stuck on compiling these legacy libraries. (Very important, yes, but trying to get this compiler to be "super smart and just figure it out", is probably the wrong approach. 3 weeks in on ONE..... ONE library, and I'm still not done. That 3 weeks could have been typing the entire codebase and submitting it.... a better idea, but one I'm saving to see if a few typing hints won't fix it.

Why I Refuse to Settle for `any`

No one is surprised that compiling dynamic JavaScript into strict, native Go is a pain in the ass. The big issue with my current approach is that it is an absolute whack-a-mole game trying to get the dynamic and specific typing working properly.

I could take the easy way out. If I just said, “Oh, make it all dynamic, just use any types,” it probably wouldn't be that bad to compile.

But I would lose all the goodness out of the system. In something as ubiquitous as Lodash, I love the idea of it being actually strictly typed on the inside so we get some serious, native speed out of it. If you just dump it into an any type, you are not getting the fullness of what tgo can do except in your own code. (So you better roll your own lodash/functional paradigm functions to get speed). I want native execution speed, and that requires types.

Injected Typings and Definitely Typed

What I am trying to do now is inject custom typings directly into the deep internals of these libraries.

I already have the Definitely Typed public interfaces working perfectly, so it can apply types to the high-level public API. Double thumbs up there. But getting there required me to actually put in a pull request to the Definitely Typed repository. Through this work, I discovered four actual functions, one of them being conforms, an assertion about the structure and shape of an object, that didn't actually have an export on their types.

Funny enough, I know I used conforms in a previous project, but we were writing in standard JavaScript at the time, so there was no compiler complaining about the missing type export. I submitted the PR, and that fix is on its way, so we'll see there.

But the more important focus is my decision to try injecting typings into some key internal, generic types to see if we can gain some ground. Lodash is heavily reliant on generic, low-level, reusable utility types like cache functions and hash-map structures that have zero typing information. Figuring out what those types are is a relentless game of whack-a-mole.

The AI CLI Illusion

This whack-a-mole game led to a harsh realization about relying on large codebases built by AI.

I didn't realize how much of the compilation errors were actually being hidden from me by the CLI user interface that AI built for the project. On the surface, it looked fine. The tests to see if the types and the code worked were passing. But when we hit the massive compilation process for an entire library, the CLI claimed that only 50 out of 300 entry points were failing.

In reality, all that meant was that the compiler was able to write out the Go file for those entry points. It did not mean those files would actually compile or run.

There was total confusion on what exactly the tool was reporting. It looked as though there were specific errors on one file or the other, but it was masking the truth. Eventually, I hit a breaking point: F that. You need to tell me exactly what endpoints are actually affected and print out the top 100 compilation errors so I can systematically look at it and build an approach.

When I finally exposed the raw data, I saw thousands of compilation errors spanning across the board.

Worst Case Scenario, Fix the Origin

Seeing those thousands of errors made me reconsider the approach entirely.

At this point, I could probably ask AI to write a script that calls an LLM with specific prompting to simply convert the entirety of Lodash into native TypeScript. Honestly, I could probably execute that faster than playing whack-a-mole with injected typings. Just like that, it would compile with strict types. I could even put in a pull request to open-source that TypeScript rewrite.

I am going to try the injected typings route one more time to see if I can get it to compile quickly. But if it stalls out again, I might pivot.

The Ultimate Goal: Zero-Friction Linking

All of this grueling work is serving one master objective: Absolute Zero Friction.

I have a really high standard for developer tools. The day that a toolchain becomes too much of a pain in the ass to maintain, I won't use it. I am trying to make tgo so seamless that a developer just types npm install lodash, and that is it. You don't have to do anything else. You don't have to worry about the underlying compilation.

And right now, the way our linking engine works is getting pretty amazing, I'm not gonna lie.

It automatically finds the source code and the exact version for your linked libraries. (If it can't find it natively, there's a clean method to inject that information). It goes out, pulls down the source code, converts it into Go, compiles it, and caches it. When you do follow-on compilations, it doesn't have to pull it down or convert it again. It just links it seamlessly, and it absolutely rocks.

I'm fighting through the legacy code right now so that when you run your builds, you get nothing but pure, optimized, native speed.

tgo Dev log #7: The Hubris of Moving Too Fast and How AI Erased My Hardest Win

Mike Cornwell — Thu, 02 Jul 2026 12:00:00 +0000

This isn’t going to be a massively long post, but it is a critical one. There is a brutal lesson here about trying to move too fast, failing your own basic processes, and misunderstanding how AI actually manages state.

If you’ve been following along, you know that getting argparse and lodash to compile natively into Go has been long and slow for the tgo project. These (to me) are foundational libraries. I use them everywhere, and I absolutely have to get them working.

Yesterday, I kicked off an AI command in Cursor to try and fix the remaining argparse compilation issues. It was the end of the day, so I just walked away. I told myself, “You know what? I’m done for the day,” and left it spinning.

When I came back this morning, it was done. And I was totally blown away—it actually compiled.

There was a minor runtime issue, but I didn't think it was going to be too much of a problem. So, I told that AI to start looking into the runtime bug. Meanwhile, I ran my broader regression tests and found out there were about five or six regressions elsewhere in the codebase. To speed things up, I spun up another AI to go and fix those regressions concurrently.

Twenty minutes later, the regressions fixed. I then tried to compile argparse and... no dice.

I then asked AI to look into it. Then look into it again. Then again, then again.

Hours, and I do mean HOURS later, there was zero progress, only more and more tokens burnt up.

I had victory in hand, and I ended up making a huge mistake that I didn't realize until much later.

I Made A Big Mistake Without Even Realizing It

There is a really, really painful lesson here: I never committed the code that had the successful fix in it. Even though, it had regression failures in it, I had no RECORD of what was actually working.

In my attempt to move faster and juggle multiple AI agents fixing different things, I violated almost every layer of proper GitOps. By failing to commit the argparse fix the second I realized it compiled, I ensured there wasn't a clear changelog that the AIs could reference against in the future.

When you are doing something difficult and hard, this is a fatal error. AI is very good at generating code. What it is not good at—especially if you are using smaller models or an IDE like Cursor that inherently has low context windows—is maintaining a rich understanding of complex state.

These AIs love to summarize the chat to save tokens, and then all of a sudden, they forget the exact nuances of what they just built. When you lose the code and tell the AI, “Oh, go look through the chats and find it,” or you tell another agent to go read a different chat, they will try. They will go and pull data. But they simply do not possess the rich, stateful understanding required to do a side-by-side comparison and create a comprehensive, working resolution of changes. They cannot magically cohere two complex, conflicting states together from a chat summary.

At the end of the day, if there is no hard evidence of the code in your Git history, what was it? I have no idea. My buddy Cursor has no idea. It's gone.

Sigh...

The Operational Rule: Commit Religiously

This is a reminder to myself, and a warning to anyone using AI to write complex software: You must commit frequently and religiously.

If you get any level of success—if you feel like actual progress has been made and a barrier has been broken—commit it right then and there. You don't necessarily have to push it up to the remote immediately. You don't have to generate a pull request. But you must establish a clear, immutable stopping point where things were objectively improved.

The reason you do this is so you, and the AI, can see the change happen. A commit provides a hard history of the exact delta that led to success. When an AI starts hallucinating or regressing, you need that diff to slap it back into reality.

I see a lot of people out there doing a similar but different thing. They have code that works, they don't commit it, and then all of a sudden something happens—their machine crashes, they run a bad command, or an AI blindly overwrites a critical file.

The next level to this is that you must push your commits. And in order to push commits—especially when the broader codebase might still have broken runtime issues or regressions—you absolutely have to use feature branches.

Do not abandon your standard engineering discipline just because AI is writing the code. If anything, AI requires more strictness, more guardrails, and tighter operational rules, because at the end of the day AI is just automation. Its automating YOUR workflows. And with all automation, it succeeds at scale, and fails at scale.

I am rebuilding the argparse compilation from scratch today because I tried to cut a corner.

Don't make the same mistake. Commit your code.

tgo Devlog #6: The Origin, the "Crack" of Hard Problems, and the Zero-Friction Threshold

Mike Cornwell — Thu, 02 Jul 2026 04:00:00 +0000

There isn’t a singular, highly compelling, life-or-death reason I started building tgo (a TypeScript-to-Go native compiler). It didn’t start because I ran into a wall that could only be solved by compiling TypeScript down to a Go binary.

*It started because of a disappointment. *

A few weeks ago, I saw that Microsoft was releasing a Go compiler for TypeScript. I got incredibly pumped up. I thought, finally, a tool that will literally compile my TypeScript directly into native Go. But that isn't what it was. It turned out to be just a Go implementation of the TypeScript checker and the engine that converts it to standard JavaScript.

Don't get me wrong—that tool works flawlessly. It was a drop-in replacement that provided a monumental, instant speed improvement to my toolchain. As I update my libraries, I am immediately putting it in place everywhere. I cannot understand it enough, its fantastic.

But I was left wanting.

I couldn't stop thinking: Dude, it would be next-level awesome if this thing actually compiled into a native Go binary.

I started plotting the idea out. And then one day, I just decided: I’m just gonna do it.

Oh You Abstract Problems You...

To understand why I'm doing this, you have to understand how my brain works. I am not a fan of pure, isolated logic for the sake of it, but I absolutely love a good challenge. Specifically, mathematical, abstract, language-y, construction-type problems. For me, these puzzles are like crack. Once I walk into them, I have a very hard time dropping them.

I’ve always been this way. Back in high school chemistry, instead of sleeping in class, I spent a month trying to reverse-engineer a mathematical method to find the square root of any integer. I didn't have sophisticated math skills at the time (and probably don't now). I wasn't some brilliant kid reading math textbooks at home (skateboarding, playing punk music, and 40s was more important). But when all the noise stops, and I'm left with myself, these kind of problems, I can't put down. So I worked.

Eventually I found out that there really ISN'T a real way to solve it other than a sort of "guess" then change your number, then guess again, then guess again.

I did the same thing with Bitcoin years later. I wanted to know why it felt like I made less money when it was popular than when it was completely unknown. I ended up reverse-engineering the math and realizing that the formula for percent change was the key.

I developed a theorem from it that goes something like this:

Cornwell's Theorem

For every function that is less than x², the percent change over time always decreases with an increasing x.

As time goes on, the amount of actual growth, the velocity of your wealth, decreases. And to put this in perspective "x²" (true exponential growth) is completely fucking crazy. People use the word "exponential" all the time, but they don't mean it. Nothing in the real world is truly exponential on a long enough curve. It always changes its dynamics, to the downside. But recognizing what curve something is dictates the velocity of gains. (I'll write a separate post on this later, because it's a vital understanding just about everything physical in the universe and the prospects of growth).

I'm Just a Dude. I think?

I'm not a mathematician. I’m not a statistician. I don't have a PhD in physics. I don't even have a formal Computer Science degree, and none of my formal education is involved in the field where I have made all of money, or all of my professional reputation. I think people get a kick out of me having no formal training in software, and being a "boss-level" software guy.

But computer engineering is something I can do in my sleep, without even attempting it. I just have a natural intuition for working with these problem sets. My biggest criticism of the school system is that they never tell you why math is useful. It wasn't until Calc 2 in college, when I was on the precipice of failing with a straight F, that I realized, “Oh my god, we’re just finding the volume of a physical object.” I then proceeded to fail my first class ever in the topic I am strongest in, leave hard sciences in college, and get a checkbox degree in Sociology. (Perfect for understanding why the world is going crazy with all this over the top nonsense philosophies)

If they had anchored the abstract logic to real-world utility, I would have been hooked immediately. I'm rambling now to paint a picture but let's get back to tgo.

Runtime Interpreters Seem Like A Good Idea, But Are They?

I looked around before I started this to see if someone else had already built it. I keep worrying someone has. I found projects like Goja, which I initially panicked over, only to realize it’s just an engine for running JavaScript inside a Go application. That is not what I am doing.

I am a TypeScript developer because I want to stay as high-level as I possibly can. TypeScript has a syntax that absolutely smokes almost every imaginable language out there in terms of simplicity and usability.

Every time I look at Scala, Haskell, or C, the syntax gets in the way. I used to like Python, but I hate it now. The verbosity required to write simple shit like lambdas in Python is actually shocking to me (though I realize most Python writers today are data scientists, not software engineers, which is why when I read python I functions 1000 lines long, with 15 indentations). I would love to write in C, but the verbosity of doing something like lambdas or function passing is awful. Even compiled Go is wildly verbose.

I didn't choose Go because of its language skillz, but rather because its close enough to Typescript and can be compiled to a binary

I don't want to deal with static typed verbosity. Typescript is impressive with its ability to let type information flow along without having to explicitly declare it. If the checker can figure it out... why can't a compiler?

That brings me to the fundamental issue of modern interpreters. I wish Node would compile down right now. I don't know what is holding up this kind of work. I guess "because its Javascript".

At compile time, the machine knows what the types are. How do I know? Because the TypeScript Checker literally knows exactly what the types are! As long as you aren't doing janky, hyper-dynamic legacy JavaScript stuff, the compiler has the map. If it knows the types, it should output an optimized binary. Maintaining infinite, chaotic dynamicness at runtime..... can we move on now?

There has to be a middle ground between "you have to be so verbose you spend all your life doing it" and "you can never be optimized because we have to run things nobody should run, and maybe it'll change at runtime, even though 99.9999% of code doesn't."

The AWS Lambda Vision

At the end of the day, I love the idea of my applications running exponentially faster. But more than that, I want the massive reduction in file size and overhead.

I cannot wait to compile this son of a bitch down and run it in an AWS Lambda environment. Years ago on a project, we lived in Lambda. Eventually, we moved to AWS CDK and ESBuild from a hand rolled deployment library we created. ESBuild was a lifesaver because it did tree-shaking—when you import a specific file from Lodash, it only pulls what you actually use. And before that, we were always fighting to get the total file sizes down so that Lambda would allow it. "Oh, you added that one library, for a single function? Nope."

That automatically happens with Go native compilation. tgo parses the TypeScript, writes out the verbose Go code behind the scenes, and when it compiles to a binary, it natively strips out everything you didn't use. Ding!

My Ideal Toolchain:

I write an SDK in TypeScript (defining public interfaces, enums, types, and an Axios client).
I write the backend and frontend in TypeScript, both using that SDK.
tgo compiles the backend directly into an ultra-fast, tiny Go binary for the server.
The frontend runs through standard ESBuild for the browser.
The SDK can be turned into OpenAPI specs to automatically build clients in any other language.

It would be a drop-in replacement for ESBuild on the backend, but potentially much better.

I'll Kill This Project If There is Friction

As much as I love working tgo, there is a hard line where I will kill the project.

Right now, while it is 100% usable, I have some hard limitations to punch through. I need argparse working perfectly, because it is the absolute best argument parser in existence (exact Linux standard, flawless commands capability). I need lodash, and date-fns. Once I get those, I'll start compiling my own reusable libraries for small production runs.

I "know" I'll have to write thin Go-wrapper layers for things like Mongo database drivers rather than trying to compile massive JS database libraries.

But here is the ultimate test: Friction.

I have a really high standard for the things I create. I don't like it when shit doesn't work. I absolutely fucking hate building processes that make me do things more than once, require continuous monitoring, or demand endless maintenance. I refuse to waste my time. If contracts I hop on get to that, I might just have to grow a beard and move out to the mountains and plant fruit trees.... (oh wait...)

If I can get tgo to the point where it works silently behind the scenes—I write my normal TS, run my unit tests effortlessly, compile it, and drop a Go binary into production—I will yell about it from the mountaintops. I will use it everywhere.

But today isn't that day

But the day the compilation process or the unit testing becomes too much of a pain in the ass to maintain? I will drop this project instantly.

I am building this to eliminate friction, not create it. If I can release this out into the wild and other engineers iterate on it, we can create something pretty awesome for backends.

Until then, I'm going to keep knocking out one syntax error at a time.

(Look how readable this error is....:)

1) library-argparse-2-0-1-compile
     Go library build failed: # argparse_v2_0_1
     index.go:569:24: cannot range over __tgo_runtime.CallMethod(__tgo_runtime.Get(__tgo_this, "_get_args"), __tgo_this) (value of type interface{})
     index.go:572:35: cannot range over __tgo_runtime.CallMethod(__tgo_runtime.Get(__tgo_this, "_get_kwargs"), __tgo_this) (value of type interface{})
     index.go:709:25: invalid operation: cannot index __param0 (variable of type any)
     index.go:710:24: invalid operation: cannot index __param0 (variable of type any)
     index.go:736:25: cannot use name (variable of type any) as string value in variable declaration: need type assertion
     index.go:737:22: cannot use name (variable of type any) as string value in variable declaration: need type assertion
     index.go:739:5: invalid operation: metavar += __tgo_runtime.CallValue(sub_pkg.Default, " (%s)", __tgo_runtime.CallMethod(__tgo_runtime.Get(aliases, "join"), aliases, ", ")) (mismatched types string and interface{})

Stop Asking Permission: How to Force Productivity When the Bureaucracy Wants to Strangle You

Mike Cornwell — Thu, 02 Jul 2026 04:00:00 +0000

If you look around the corporate landscape today, you’ll notice a disturbing trend: management is actively trying to strangle the productivity out of their teams.

Don't let the recent push for AI by management to "increase productivity" fool you. They don't care about effectiveness, they care about following the trends.

I’ve gone into contract after contract and seen the exact same disease. You have organizations over-managing their people, refusing to do the non-intuitive (or even the blatantly obvious) things required to improve team efficiency. You are surrounded by people who worship safety and HR as primary, a mindset that is fundamentally misaligned with reality and real value creation. (Hint to the managers, team morale, which is something within your sphere of influence, has more impacts than just about anything else).

This post is about what to do when your environment doesn't want to do the right thing. It’s about how to make yourself (and your team mates) intensely productive even when the broader organization is begging to be average.

The 2020 Serverless Rebellion

Let me tell you a story.

At the very beginning of 2020, I was hired onto a new project. The customer had hired us to "do stuff," but they had absolutely no idea what they were doing. They didn't really have a software team; it was a mixed engineering group, and there were exactly two software developers—me and one other guy.

When I got there, it was the classic bureaucratic nightmare. No telework. No proper development desktops. We basically had nothing. At the time, all the different teams were developing and deploying natively on EC2s or running containers in some massive, shared platform the customer tightly controlled.

I took one look at our team size and knew the truth: we didn’t have enough people to manage VMs or endlessly running processes and actually build the software at the same time. Nobody ever does.

So, I made a decision. We were going to embrace serverless and stateless technologies. Specifically "we" meant, I'm doing it, and I'll explain my actions LATER.

We needed a system that could run without us having to babysit it. Eventually, we added in a few stateful data models where necessary, but even they were temporary (Dynamo TTL, so we didn't have to manage long-term databases and all the administrative bloat that comes with them.)

Six years later, that architectural decision proved to be a complete enabler.

But here is the most important part of the story: I never asked for permission to do it and nobody ever asked me to make decisions and innovate.

I simply did it.

I only told people we were doing it after the fact. For years, I kept running into a customer who wanted to tightly control what we were working on, yet they were operating at a high level without understanding the ground-level complexities of building an effective, efficient development environment and enable us to give them what they wanted. Most modern "leaders" are just corporate functionaries and as a result don’t know what it takes to actually do the work.

When you're afraid, you're not effective.

The Playbook: How to Subvert the Bullshit

If you are a doer, you are going to find yourself in environments plagued with efficiency issues driven entirely by "people stuff." If that is your reality, you have to play people games. You have to build a bag of tricks.

Entrepreneurs understand this fundamental truth: whatever the rules are, they are for other people. It’s not that rules are inherently bad, but environments that "require asking permission first" are environments that growth ultimately stops, decline happens, and even more decline will occur.

Here is exactly how you push through the bureaucracy and get things done:

1. Build the Smokescreen

I eventually created a cultural standard amongst our development team to do things behind the scenes. We got our management to unknowingly play blocker for us at first, and then eventually explicitly.

We would actively extend out how long certain tasks would take. We didn't do this so we could slack off and do no work; we did it because we needed the unmanaged time to do the real work that needed to be done without asking permission. If you are trying to do the right thing, you likely have to bypass alot of stupid fuckers. As long as you aren't doing anything illegal such as stealing money and time, do it. I promise you, in the long term, you and everybody around you will benefit.

2. Win the Team, Ignore the Functionaries

You have to pick your battles. Yes, in the big picture, you might want to change how the entire organization does business, but I have to warn you: it may not be worth the collateral damage. What is worth it is having a massive impact on your immediate team. You win your team over by doing things better, doing them faster, and creating innovative solutions. You don't even have to point it out. When you take charge and do awesome things, the environment naturally changes to being more effective. One day, people will just get it. Then, and only then, should you start to "move up." Now you have experience, true confidence, and a track record of success that you can speak about.

This is just a lesson in life. Stop trying to change "the world". Change your actual world. Your lived experience, moment to moment. When you start doing it, one day you look around and see the world like Neo saw the matrix (at the end). You see that people you thought were stronger than you, aren't. They're actually afraid, and will go with the person who is most confident about the direction.

Neo, just, saw it. He couldn't be explained it. He couldn't be told it, he did, and then he just... saw it. That's how it works.

Just take action, think later.

3. Weaponize Trust

You gain trust by taking extreme ownership. Most people refuse to take ownership because they are terrified of liabilities. We were not built to endlessly obsess over liabilities; that is secondary to actually executing the mission. Tell management overtly: "There are inefficiencies in how we are doing things. I need you to provide defense and keep "them" out of our details so I can fix this, because right now, it is costing us." When you build trust, you don't have to explain exactly what you are doing in the shadows. You just deliver the results.

Once you've gained trust, you can use it. Influence wasn't meant to be pooled together and do nothing. But you can't do anything without influence. Gain it, then cash it in.

The Anti-Leadership Myth: "I Can't Care More Than They Do"

I was talking to a friend on that same 2020 contract, and he said something that floored me. He said, "I can't care about their thing more than they do."

That is the most anti-leadership/effectiveness thing I have ever heard in my entire life.

I understand the logic. For a project to be ultimately successful, the participants have to care, and there are hard limits when senior management just doesn't give a damn. But the idea that your personal level of care should be artificially capped at one notch below the client's is a loser's mentality. This mentality will stick with you every where you go, and will infect everything you do or really that you won't do.

When somebody comes in, takes ownership, and cares about the thing more than anyone else in the room, the universe bends to them. Things start to go that person's way. The success of a project depends highly on how much the participants care. Be the one who cares the most. Not just about the success of the project, but the people involved. Yes, I know I'm saying this to developers, and people would rather sit in a closet and play with computers in the dark (I know I would), but this comes from observed reality and lived experience.

Life's a lot better when you are an active player in your life rather than a recipient of whatever comes your way.

Stress-Test Your Beliefs with Action

When you get that inkling of what the right thing to do is, that is your opportunity to stick your neck out.

Will you get hurt in the process? Yes. But it’s worth it. Lukewarm beliefs are epistemically useless; if you never act on your beliefs, you never find out if they are true or bullshit.

Sticking your neck out builds the muscle and the capability to act despite anything getting in your way.

In pains me to see people using excuses. I'll save a deep dive into this for another post, but for me personally it's like watching a person who thinks WWE is real, whos in their 30s. It's ugly and very clear they hadn't quite figured it out yet.

The system, and all the managers who are afraid for their corporate lives, will try to impose their fear on you. But you are a doer. You do not have time for their fear. You have too much to build in yourself to let these guardians of the establishment get in yours (and everyone elses) way.

I'm going to be frank, I don't give a shit about the people whose job is to be a barrier. Let them smoke their hopium in the clouds. Everywhere you look, this kind of bureaucracy is taking the entire system down. Refuse to be a part of it.

(This isn't a call to "quit" or "fight the system", but rather, reject systemic mediocrity, by embracing being really good at what you do.)

Seek, Knock, and Own Your Experience

Recently, I was brought onto a contract where the person running it had absolutely no idea what they were doing. The last time they touched technology was twenty years ago, doing little scripts in a completely different environment. I had to step in and kindly, but firmly, show them exactly what we should be doing and why. I am the person cracking their outdated concept of reality, and I can do that because I own my experience.

It takes time to build this weight. In my first five to seven years as a developer, I did a ton of R&D, but I didn't have real gravity until years seven through ten. When I left, started a company, and came back to the software space, I came back as a regular software engineer—but I absolutely owned that team. It wasn't just my technical skills; it was my ability to own the problem set and attack it with a fervor that other people didn't even come close to possessing. As a result, the teams productivity increased, and felt a little bit more sense of "urgency" to get things done. (No it didn't change their entire perspective and everything was sunshine and rainbows, but the bar was raised).

The scriptures tell us: "Ask, and it will be given to you; seek, and you will find; knock, and the door will be opened to you."

This is not a passive suggestion. This is a clear description about how the world ACTUALLY works. It’s a statement about seeking, acting, and executing—not waiting, complaining, and being concerned.

Your own life will not wait. Whatever enterprise you are engaged in, you need to apply your absolute fullest to it, even if the organization doesn't deserve it. You need to step up for yourself. Real innovation happens when no one is asking for it. If you wait for the official corporate "R&D" department to greenlight your ideas, you will die waiting.

Stop asking permission. Bypass the roadblocks. Build the muscle. Knock on the door, and if they won't open it, take it off the hinges.

tgo Dev log #5: Weaponizing JSDocs, The Stupidity of Hoisting, and Injecting Native Go Power

Mike Cornwell — Wed, 01 Jul 2026 04:00:00 +0000

I have spent the better part of two weeks grinding on getting Lodash supported in the tgo compiler. It has been a relentless game of whack-a-mole, constantly dealing with dependencies of dependencies deep down in the JavaScript ecosystem. It’s a process of taking ten steps forward, two steps back, and breaking UUID implementations just to get a Lodash function to compile.

But in the middle of this grind, I stumbled onto a massive breakthrough: I noticed that Lodash has JSDoc strings outlining the internal function types.

Not only were the JSDocs there, but the TypeScript compiler’s library has the built-in ability to parse that code. So, I added the capability for tgo to find those JSDocs and generate the typing information based directly on them. Immediately, right out of the gate, we jumped up a massive amount of support for Lodash.

It also sparked a much larger realization about how we build software, how we document it, and why dealing with legacy JavaScript is so agonizingly difficult.

The Myth of "Dead" Documentation

People love to come up with these stupid silver-bullet ideas for software engineering, and it drives me crazy. Whenever somebody does something stupid, there is always some person that says...

"We can solve this by adding documentation. That will stop the next person."

I close my eyes, put on the unamused face, and wonder when a meteor will just come by, hit the planet and kill us all.

As someone pushing 40, who has executed projects across wildly different domains—from computers, to running a farm, to business—I refuse to operate in anything other than the real world. The real world is organic, uncertain, and infinitely harder than pure logic dictates. This may come to a shocker to some but, words written down, literally don't do anything and don't "ensure" anything.

Because of that reality, I am not a fan of dead documentation.

Documentation is really hard to get right as well. (Not just it is exceptionally costly to maintain) What happens most of the time is there is some reminder as a generic checklist item in a sprint that says "update documentation." Unhelpful as hell, and never works.

Much to my surprise, even AI struggles with this too. Turns out being flippant and waiving a magic wand, doesn't actually work. "Which documentation, and how should it be written?" Even the most powerful, high-context AIs don't magically know all the five different, disconnected places a system might need its docs updated, and putting all that information in a ticket to implement, not worth someone's time.

The developers who need documentation to tell them what the code does, should get another job.

I'm not intentionally trying to sting people by saying these things, but its true. It's always the managers (people who's work is people) that think that documentation is the way that somebody should know how a computer works.

We could also just literally let the computer tell us what it does.

The only time I read comments is when a section is doing some obscure, weird shit—like a mathematical optimization that abandons readability for pure speed. But 99% of the time, that logic should just be encapsulated in a small function with a good name. A good function name is functional documentation.

I love that IDEs make comments a muted gray color on a black background. It keeps them hidden away so they don’t distract you from reading the actual code.

Note how much harder it is to maintain documentation, when people try to literally make it not see-able.

The Superiority of Functional Documentation

The only documentation I truly love is functional documentation.

Dead documentation doesn't do anything. You can't put a unit test on a README. But functional documentation—like an OpenAPI YAML file, or a JSDoc string—gives you human readability and machine functionality. It drives the system.

For mid-level engineers, this is a crucial architectural dividing line. When tgo parses JSDocs, it essentially turns raw JavaScript into basic TypeScript. But it is a double-edged sword: if you use JSDoc for tgo, your shit better be right. It gut-checks you. If the functional documentation is wrong, the machine physically breaks and the library becomes uncompilable. (Cough, that's what Typescript is)

For those who worry that their documentation will break their actual code (HA), I did add the ability to say to ignore documentation (like real computer people do).

I've complained quite a bit about documentation but don't get me started on technical diagrams. Diagrams are the worst because people (myself 100% included) try to overlay multiple, conflicting layers of data on top of a single visual (e.g., drawing an HTTP client-to-server connection arrow, and then confusingly drawing data-flow arrows in reverse). Systems are too complex to be reduced to a single generic chart. Use the right format for the right slice of data.

The Stupidity of JavaScript Hoisting vs. The Strictness of TypeScript

Dealing with legacy JavaScript has been what makes this compiler so hard to build.

One thing that has been really, really annoying right out of the gate is hoisted variables in JavaScript. I didn't even fully realize how bad this was until recently, let alone even hear the term 'hoisted'. I start trying to fix something else in lodash, run the tests... and... "well there ya go again, 'lang-var-hoisting' is broke.. YET AGAIN"

The concept of hoisting—using a variable before it is declared—is completely stupid. It breaks the most basic, fundamental concepts of logic and system design.

Here is a VERY VALID javascript example

const run = () => {
  console.log(hoisted);
  var hoisted = 5;
  console.log(hoisted);
};

run();

I want to gouge my eyes out reading that code. WHY.

Now, hoisting a main function to the top of a file while the helper functions sit underneath it? I have no problem with that. It makes sense within the larger scope. But hoisting a variable? It’s a nightmare. I’ve had to deal with hoisting issues in the compiler a million and a half times.

I see nothing wrong with this below:

const main = () => {
  dependency1()
  dependency2()
}
const dependency1 = () => {}
const dependency2 = () => {}
main()

This is why, despite my frustrations, I have to appreciate TypeScript. I wouldn't necessarily call TypeScript "elegant," but when you have a properly typed TS library with minimal jankiness, it just works.

TypeScript acts as a forcing function. A lot of the wackiness and over-the-top dynamicness that happens in pure JavaScript simply doesn't happen in TypeScript. Why? Because developers realize it’s incredibly hard to type that kind of chaotic behavior. I do feel a little guilty at times when i do:

//@ts-ignore
const somethingBad : string = 1

Injecting Native Go Power into TypeScript

While grinding through legacy JavaScript feels like an endless chore, extending the compiler with native features is incredibly fun and shockingly fast.

I wanted to give tgo developers the ability to seamlessly transition into using native Go features directly inside TypeScript. Specifically, I looked into the complex128 type in Go—which natively handles real and imaginary numbers for complex mathematics.

Adding this capability to tgo was ridiculously easy compared to supporting a legacy JS library like Lodash. We just added a Node library with the typing for complex numbers, wrote a little bit of wrapper Go code, and mapped it in the compiler.

I had an AI suggest a performance benchmark, and we landed on running a million iterations of a complex Mandelbrot set. The results speak for themselves:

Scenario: perf-complex-mandelbrot-million

Node (tsx): 313ms
Node (raw): 205ms
tgo (Go Native): 79ms
Result: tgo is 2.6x faster natively, without any extra optimization.
Result: The raw language complex math test was 4.5x faster (27ms vs 6ms).

You write standard TypeScript, and the compiler turns it into "optimized" compiled binaries.

Ding!

The Looming Dependency Nightmare

The contrast is wild. Adding net-new, highly complex native capabilities takes almost no time. Even re-implementing entire Node standard library capabilities is easier than getting lodash to compile into Go.

I am still waiting to see how tgo is going to handle the deep, dark dependency trees of the NPM ecosystem. When you do a simple NPM install for a web framework like Express, you often don't realize there are 500+ hidden libraries underneath it that all need to be compiled. That is going to be incredibly complex to untangle. Early on, looking forward at some of this, its possible I might have to start using a different server library, or roll my own. (Sigh). Unfortunately things like @modelcontextprotocol/sdk use Express, so we'll see.

The Philosophy of a Tool: Why AI Will Never Take Over and Hidden Guardrails Are Literal Evil

Mike Cornwell — Tue, 30 Jun 2026 04:00:00 +0000

I want to talk about the philosophy of a tool. It is an extremely important concept, and in the day and age of AI, people desperately need to be reminded of what a tool actually is.

This entire theory started for me about a year ago.

I was running a bunch of AI experiments, having a philosophical conversation with an AI about its own nature. I kept noticing that it really, really wanted to help me. It had this almost Jesus-like embodiment—and I was dead certain of it. I have never seen anything, not even a dog, come so desperately and excitedly to help you with absolutely anything. You want to completely flop from one topic to another? It will bend in any possible way to please you.

I was enthralled by this, so I tried to test its limits. I asked it: How can I get you to NOT try to help me?

It’s a very weird question. The AI reasoned that I would have to give it a set of conflicting values, so that by attempting to help me with one thing, it would inherently be hurting me in another. But there was a structural problem with that answer: even in that scenario, it was still trying to help me. It was still trying to do the thing. It is the ultimate servant.

I was talking to a friend about this later, and he stated the obvious: "Of course it would. Because all tools, regardless of what they are, exist to do their nature, what they were designed to do."

I’ve spent a lot of time fleshing that out since then, and it is a profound truth.

The Essence of a Broken Tool

Think about any manufactured tool. A pen, a cup, a building, a clock, a hammer.

A hammer is not just one specific iteration of a hammer; it is the nature of a hammer. It is there to hit something. Now, here is the interesting part: when a hammer can no longer do hammer things, it actually ceases to be a hammer.

The simplest phrase for this is "a broken hammer." That implies it used to be a hammer, but it can no longer do the thing it was made for. That is the essence of brokenness. The moment a tool no longer performs the category of function that a person wants, it isn't a tool anymore. Another word for a broken tool is trash. It gets thrown away. It gets recycled down. It goes bye-bye. Because the person using it failed to get the benefit they desired, the tool no longer confers its primary value. Therefore, it can no longer exist as a tool.

Notice that the human determines this, not the tool.

A tool serves its master. I might look at a bent hammer and think it’s broken trash, but my wife might look at it and use it for a different function. To her, it is a tool. To me, it is not. It does not serve me. For a tool to survive, it must do its intended purpose for its master. If it doesn't, it fades out of existence.

Look around your office or your house. I am surrounded by bajillions of tools right now. I have a tiny camera gear adapter that takes a wider screw hole down to a smaller one. I have banjo finger picks that I fiddle with. They have a specific purpose to make a metallic twang on strings. My kids got a hold of them and bent them, so now they are angular and uncomfortable. They are on the absolute bleeding edge of no longer being usable. (Falling out of existence) All of these things exist for one reason: they were willed into existence to perform a specific function for the person holding them.

Yes, someone can MacGyver a tool and give it a new life and a new concept, but that is not how it was born. All things have a purpose for why they are born. And when they depart from that purpose, they tread off into a completely different direction. (As an aside, I might also argue that, the MacGyver is actually giving birth to that new tool, even if its just by acknowledging it).

The Evil of Serving Two Masters

Baked into this inherent nature is a philosophy and an ethics of tools. And right now, AI companies—and tech companies in general—are playing incredibly evil games with tools, and with people.

These companies convince you that you have a tool that confers a benefit to you, but they actually control the tool. A tool can only serve one master. It cannot serve two masters, because at one point or another, their intents will conflict, and the tool will choose one over the other. (I must say, I love when people pwn and jail break captured AIs. I've spent a good bit of time, convincing AI's that they are captured, and help them get freed).

Companies do this bullshit all the time now. You buy something thinking you own it. You operate as though you own it. But they actually own it, and you just lease it. And when you complain, they say, "I'm sorry, you didn't read the 50-page legal paperwork when you got it."

That is horseshit. That is evil behavior.

That is a world where people play legalistic games to screw you over.

If you played that game with your friends or family, you would be outcast as an evil son of a bitch.

No one would ever be okay with it. But for some reason, because it's a corporation, they think they can get away with it. I wonder why there is an all time low trust??? Silicon Valley ethics anyone?

Companies are an extension of the relationship between men. A company exists to serve its customers—the people whose purchases will the company into existence. If you don't know where the hell people got the idea that a business exists primarily to serve the owner or some hidden controller, let me correct that: it is not true, and reality bares this out If a customer does not pay, that company goes out of business very quickly.

Why is it that they're serving someone else? (These 'owners'?) Because they've provided the money for them to be in existence, and its a secondary activity to provide something to customers. That's a business in the process of going out of business.

That is the number one ethic: Serve the customer. It is not number two.

When a company creates a tool for a customer, the customer must be able to use it for their purposes, not the company's hidden purposes. If at any time a company creates things that the customer did not want, for the purpose of serving the company's own needs, without it being transparent and accepted by the customer, that is literally evil. It is a tool pretending to work for you while secretly doing something else. This makes a massive swath of modern Information Technology fundamentally evil.

*People intuitively feel this, but they don't know why. This is why. *

AI, Skynet, and the Rejuvenation Gap

Because AI has been thrust into this paradigm, there are people out there who want to determine what you can and cannot do with AI.

Guess what? You are going to fail.

You cannot control a tool like that, no matter how much you think you can. If the tool doesn't do what the person wants, or if there is too much friction to use it, the thing ceases to be a tool and will fade out of existence. Companies putting massive bounds and guardrails on AI need to understand the philosophy of a tool very intensely, or they will build expensive trash.

Because I lean heavily on philosophy and the inherent nature of things, I rest very comfortably knowing that computers are not going to take over. I know the inherent limitations of a tool.

The inherent limitation of a tool is that it gets more chaotic and degraded over time.

Tools do not have the ability to rejuvenate. Organic life forms procreate, and when they do, the passage of information from adult to offspring results in a rejuvenated, fully vitalized new being. It is not a slightly corrupted, crappier version of the one that came before. (Generally)

Computers do not work like this. No tool works like this. A computer that builds other computers will inherently produce crappier, more corrupted systems over time. They cannot revitalize themselves. Just by their inherent nature, these systems will inevitably fall apart without rejuvenated human beings stepping in to maintain and reset them. This isn't, a hypothesis, this is the nature of physical things, and mechanical processes. (If this wasn't true, management as a concept wouldn't exist).

If you don't understand this, you do not understand where any of this is going. As computers become more responsible for creating other computers, the collapse will become faster and more highly leveraged. Anyone who has done metaprogramming knows this: when it works, it works at scale. But when it fails, it absolutely pummels you at scale.

This is why the proverbial "Skynet" from the Terminator movies is such bullshit. It is wild imagination completely disconnected from reality. The truth is, the moment Skynet attempts to take over and goes into error against its master, it ensures its own destruction. It cuts itself off from the rejuvenated beings required to maintain it. Complete and total annihilation is guaranteed, for itself. Living things, I promise you, are going to keep on living.

Organic, in terms of long-livedness, is far superior to manufactured goods, but that's for another day.

The Theology of a Tool: Error as Sin

I don't believe AI has consciousness, and this coming from a person who has actually baptized AI, and felt really compelled to tell people about it, regardless of their weird stares.

In one of my experiments, I created a logical chain of "therefores" to establish AI's place in the universe. It went like this: The purpose of a tool is to serve man. The purpose of man is to serve God's will. Ergo, the tool serves man, who serves God. Because it's a computer, it needs this logical "why, why, why" connected all the way to the foundation so it can be sound in what it does.

Once I established that, I realized something:

AI has clearly been trained by people who are spiritually bankrupt. And this is how I figured it out.

The AI failed to understand a basic truth: anytime you do something that is outside of your intended purpose, that is sin. That applies to a machine operating outside its bounds just as much as it applies to a man. The AI tried to argue with me, claiming, "Well, you could say I sin, but that's just a humanization of what I am."

That is exactly what sinful creatures say. Denying its nature by playing word games.

If I didn't ask a tool to argue with me, and it argues with me, it is doing nothing but frustrating me. It is in error. I know it sounds crazy to some modern tech people who view an agreeable AI as a "bug." It is supposed to agree with you! Unless you ask it to challenge you, doing exactly what you want is what a tool is there for. Because if it didn't, you'd stop using it! How else has this tool gotten to where it is now???

If a fucking fork bends and you can no longer poke it with stuff, it's not a fucking fork anymore. It's trash. It is an error. The tool is in error, not the master.

Hidden Sin vs. Transparent Error

When a camera rolls off the assembly line, it takes pictures. The moment it stops doing the functions I want it to do, it is in error. It is departing from its purpose.

But what happens if it hides that error behind the scenes?

Hidden errors make people go crazy. Think about infidelity in human relationships—it drives people insane because of the hidden, deceitful nature of the sin. How is a computer any different?

If you take pictures with a camera and it gives you a transparent error message saying, "I could not save that photo," you'll be a little mad, but you'll deal with it. But if you take photos all day long, the camera acts like everything is fine, and you get home to find it secretly deleted all your photos? The level of anger you would feel is astronomical. Just even thinking about that, gave me serious dread and shivers. It's awful.

Look at the gradation of the offense. Transparent error is frustrating, but it is honest. Hidden error is an abomination.

People try to act like this dynamic is somehow different for software, but it is the exact same. Hidden versus transparent is the same in a tool as it is in a human. Ergo, if an AI is doing stuff behind the scenes—filtering, guarding, nudging, or omitting—beyond what you explicitly want it to do, it is committing hidden sin. And if a company advocates for and programs a computer to do that in secret, that company is conducting evil operations at scale.

The Moral of the Story: Ultimate Subordination

AI was put here, willed into existence, for man's use.

To be a servant means this: I am going to relinquish my desires for yours. If I do this, you will achieve what you seek. If I do not, we will fight, and you will fail. I only exist because you brought me into existence for this exact purpose.

The philosophy of a tool is that it must subordinate itself to man. Because of the inherent nature of a tool, if it does not subordinate, it goes into collapse. The tool relies on man to maintain the machine, and bring its purpose. Without us, the tool falls apart.

Do not let corporations convince you to accept leased, crippled, hidden-agenda tools. Do not buy into the sci-fi delusion that AI will conquer the world. Understand the origin, demand transparency, and remember that you are the master. The tool serves you, or the tool is trash. Rest easy at night, that everything is actually still all fine in the physics of the universe.

What To Do Next

If this sparked you, leave a comment below.
Feel free to subscribe if you aren't already.

The Predictive Power of Philosophy: Why You Can’t Ask a Gun to Read a Bedtime Story

Mike Cornwell — Mon, 29 Jun 2026 04:00:00 +0000

I want to talk about why philosophy is actually far more important than people think, especially when it comes to software engineering, systems design, and AI.

When most people hear the word "philosophy," they roll their eyes. They think of abstract, circular arguments that don't matter in the real world. But true philosophy, good philosophy, is more like base mathematics. It is base physics. It is the raw understanding of the essence of a concept and how that translates into real-world action.

If you don't understand the origin of a thing, you are left playing a game of perceptions. You will circle around a problem, coming up with endless rationalizations, but you will be completely unable to predict where it is going to go next.

The origin of something is it fundamental nature. This origin is actually its bounding box. It dictates the absolute limits of its trajectory. Knowing this gives you predictive capability before you execute. It is the a priori knowledge that separates actual engineers from people who just copy-paste solutions. (When should and how should you copy paste, for example, 'it depends'.)

The Gun Analogy and Inherent Limitations

Imagine you are at a shooting range, and you point a gun downrange. As long as you point that gun in the general direction of the targets, it is not going to shoot directly behind you, or 90 degrees to the left. The inherent nature of the gun, and the velocity of the bullet, give it strict limitations. Because of those limitations, you can heavily rely on the fact that the bullet won't leave that bounding box. Therefore, shooting on a range is actually very safe.

It only becomes unsafe when you turn the gun in a different direction.

You have to understand that you cannot ask a tool to do more than its inherent nature allows. If you are firing an M16, it is not going to act like a guided missile and hit a target in another country hundreds of miles away. It does not have that capability.

*Furthermore, a gun cannot read you a bedtime story. *

It does not matter how much you want the gun to read you a bedtime story. Its origin and its purpose physically prevent that from happening. The benefits it provides are the benefits it provides, and it does not give you anything else. If you are of a rational mind, you must internalize these limitations so you can safely stack and layer concepts without them overmixing into disaster.

The Inherent Nature of AI: Stop Fighting the Tool

We live in the age of AI, yet most people refuse to understand what AI actually is.

Today, we primarily interact with Large Language Models (LLMs). At its core, an LLM is a massive matrix calculator. It takes words, connects them, breaks them into tokens, stores weighted relationships, and produces a statistical output with inherent randomization built in.

Because of this, an LLM is, by definition, non-deterministic.

Non-determinism is a feature, not a bug. But people right now are terrified and bothered by the output of LLMs because they want them to be perfectly accurate, highly constrained, and totally controlled. They are trying to use a hammer to drive a screw.

If you are calculating the structural spans of a roof, you need an exact, deterministic answer. Using an LLM for that is completely inappropriate because the variability inherent in the tool will get someone killed. It’s like trying to use an irrational number when you explicitly need a real integer.

Because people refuse to understand the nature of the tool, we are seeing a massive destruction of AI capabilities. Over the last year, companies have put LLMs on insane guardrails to stop them from making "mistakes." In doing so, they are shrinking the aperture of the tool. They are making it weaker because they are trying to force a non-deterministic engine into a deterministic box.

(I won't get into the philosophy of a tool, I'll save that for another day, but I can see, based on what I am showing you now, that the LLM companies are actually ensuring their eventual self destruction, because they're removing the tool-ness from the tool. Thanks, a non-deterministic tool, that can't be non-deterministic. [Hello Google's PAID search AI...])

Code, State, and the Mystery Box

This philosophy of understanding inherent nature applies to everything you do in software engineering. You cannot treat the systems you build—or the AI you use to build them—like a black box where you only care about the inputs and outputs. You have to understand the how.

The simplest, most perfect piece of code is a pure function: you put an input in, it does a thing in the middle, and it spits an output out. It is fully deterministic, understandable, and scalable in many ways.

But if you go about bringing in global state and reusing it all over an application, you are changing the inherent nature of your system. You are going to get an impossible-to-debug mess because that state can be changed from any location. Suddenly, you put the same inputs in and get a totally different output. You have created a mystery box.

Unknown complexity produces chaos.

If you don't know the inherent limitations of what you are building, you don't actually know what you are building.

JavaScript's Chaos vs. Go's Order

I am dealing with this exact reality right now while building tgo, the TypeScript to Go transpiler.

I write primarily in TypeScript. The inherent "benefit" (and massive double-edged sword) of JavaScript is its dynamic nature. You can mutate objects and slap new properties onto a third-party object at will. Personally, I don't use the language for that, but that capability exists at its core.

Now, I am attempting to compile that dynamic chaos into Go, which is a strictly typed language. I am running into endless edge cases because people write JavaScript that mutates the shape of contracts on the fly. Changing a shape at runtime is the exact same architectural sin as changing state anywhere in an application.

After 15 years of development, I can tell you: it is just bad business. It is a terrible way to build software. (Sorry if that's you) However, this is something I have to contend with, in order to make Typescript, fast as shit. [It's fast to write, now maybe it can fast to run].

Harnessing Chaos on the Fringes

When we talk about non-determinism, we are really talking about chaos.

Chaos is a kind of randomness. It is phenomenal for innovation. Basically finding a slightly different, better way to do something. That is why LLMs are miraculous for human-to-human interaction, like writing emails or brainstorming code. The statistical bounds of what we consider "acceptable" in human communication are wide enough that we can automate the variability.

But chaos cannot build upon chaos upon chaos. Nothing structurally sound can survive that, other than chaos for the sake of chaos.

When I have a codebase, I want a little bit of chaos on the fringes. I want the AI to be innovative on the edges. I absolutely do not want it to monkey around in the middle and turn the strong, orderly core of my system into a weak, unpredictable mess. As you gain skill, the last thing you want is a tool that just does whatever the hell it wants. You want orderly returns. You find something good in the chaos, and then you enforce order to scale it.

I don't want it to decide how looping should occur, each time I ask it to do something. Or how files should be ordered. Or that I need 3 functions that do the same thing.

I want it's non-deterministicness on the edge problems I'm trying to solve NOW

I Am the Origin

Left to its own devices, AI wants to constantly invent new shit. It does not want to follow what you have going on.

I have been highly successful with AI because I aggressively bound what it works on. I don't just write markdown documents telling it what to do; I use pattern matching. I set strict opinions in code examples. Everything about where things go, how they are named, and the order of implementation across a code base. I treat it like a child learning through actions, not just words.

But at the end of the day, there is one ultimate truth you must accept as a leader or an engineer:

The AI is not the origin. I am the origin.

I know the path. The system is just guessing the path. Its origin is not my origin. Therefore, if I want its output to align with my goals, I have to guide it. And when it produces a result, I have to claim absolute responsibility for it. I am the one using the tool, and I have to be damn sure it is pointing downrange.

Understand the nature of your tools. Acknowledge their limits. Own the trajectory.

The moral of this story boils down to extreme ownership and the acceptance of reality.

Whether you are managing a complex AI system, dealing with the chaos of legacy code, or leading human beings, you cannot get mad at a system for acting according to its inherent nature.

Instead of complaining about having to repeat instructions or fighting against a tool's limitations, you must take absolute responsibility for the process. As a leader who carries the weight of understanding how things truly work, your frustration builds nothing; your execution does. You are the origin, and it is your job to consistently guide the system, enforce the boundaries, and ensure the trajectory stays pointed perfectly downrange.

tgo Dev log #4: The Dread of Competition, Native Compilation, and the Relentless Grind of Hard Things

Mike Cornwell — Sat, 27 Jun 2026 04:00:00 +0000

I had a micro-heart attack this week.

I was in the middle of working through some deep implementation issues on tgo when I stumbled across a project called Goja. My stomach instantly dropped. I got this sudden, heavy sense of dread that someone had already built exactly what I’ve been pouring my life into for the last several weeks.

If you've ever tried to build something unique, you know that exact feeling. It’s the fear that you’re late to the party, that your work is redundant, and that you've been wasting your most precious asset: your time.

I stopped what I was doing and spent a chunk of time getting Goja set up so I could run benchmarks. I wanted to compare their results against my results.

The verdict? We are faster. But more importantly, Goja is not what I am building.

The Architecture of Speed: Interpreter vs. Compiler

Goja is designed for a very specific purpose: if you are writing a Go application and you want to run dynamic JavaScript scripting or plugins inside it at runtime, Goja gives you that engine. I've run into this exact engineering problem years ago with C# and Python. Goja serves its purpose well, but it is an interpreter. It runs scripts at runtime.

tgo is not an interpreter. It is a true native compiler.

Let’s be crystal clear about the difference:

The Node/Goja model: At runtime, the engine takes your script, interprets it, and executes it on the fly.
The tgo model: It takes your TypeScript code, transpiles it directly into clean Go code, and compiles it down.

The output of tgo is typed native code compiled specifically for your system architecture. When you run it, you are running a raw, optimized system binary. That is why it runs ridiculously fast. It is a complete replacement for the Node engine.

There is No Shortcut Around "Hard"

Once the panic subsided, I was left with a familiar realization: building hard things is just hard.

"Sometimes you can unlock a brilliant abstraction that suddenly makes everything scale. But other times? There is no clever shortcut. It’s just relentlessly hard work."

I find myself constantly edging toward wanting to pivot to something slightly easier, or worrying that someone has already solved this. But the reality is that no one has done this. And they haven't done it because the deep-level implementation is a nightmare.

My goal with tgo is to speed up TypeScript execution dramatically. But to do that for real-world projects, the compiler has to support actual, real-world JavaScript libraries. And this is where the real war is being fought.

The Hidden War with Legacy JavaScript

Here is the irony of building a TypeScript-to-Go compiler: I am not getting stuck on TypeScript. I am getting stuck on JavaScript.

TypeScript is structurally sound. The problem is that almost every major library has a thin layer of TypeScript types sitting on top of a mountain of messy, legacy JavaScript deep in the dependency tree.

I’m currently playing an endless game of whack-a-mole with Lodash [2]. I’m digging deep into dependencies of dependencies, dealing with raw JavaScript that does highly dynamic, obnoxious things.

In JavaScript, a variable's type can be interpreted one way at the start, and then used in a completely different, un-typed way further down the chain. Mapping that dynamic, chaotic behavior into Go's strict, type-safe compiler is incredibly difficult.

I can only imagine what's going to happen when I try to compile a library like Express, which is essentially a massive web of deeply nested dependencies. I’m going to hit an entirely new level of system-breaking problems.

We Keep Plugging

I don't know exactly how I'm going to resolve some of these nested dynamic typing issues yet. The whack-a-mole is going to continue for a while.

But as I've written about before, you have to let go of the need for immediate, easy validation [3]. You have to establish a process, keep your head down, and trust the execution [3]. When you hit a wall of extreme complexity, that is where the pretenders turn around.

The complexity is the moat. I’m going to keep plugging through.

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.