To answer your question, although I would certainly have preferred you to phrase your comments less insultingly: this project would otherwise never have got to a state where it could find bugs. I am not paid to write this code, and it would have taken far more years than I would have been willing to spend.
It's not actually unheard of for people to pay other entities to build their passion projects. For example, I visited [Eltham Palace](https://en.wikipedia.org/wiki/Eltham_Palace) last weekend, which was not in fact built entirely by the two Courthaulds who commissioned it.
What does that have to do with LLMs? There's morev to delivering value to the customer than just shipping code. We used to understand that technical debt was an existential risk to a project. I can't see how "code nobody understands" is not technical debt.
I disagree. Shipping functionality that works and users consume is all that matters. Everything else is noise. Technical debt can be viewed through this lens - it reduces the rate in which functioning code is shipped. That's bad, but it's only one of many dials.
The author states they feel that using LLMs allowed them to ship years faster. That's years of time in which they can collect feedback and iterate. They might even choose to scrap the entire project and rewrite it based on their learnings. The practicality of this is directly enabled by agentic coding.
Technical debt is aptly named. From time to time it demands it's interest in the form of delaying a new feature, but as long as your overall technical revenue is positive, it's fine.
LLM rant aside, I think this comment is built on a fundamental misunderstanding of what this is. This kind of runtime is an advanced debugging tool for exploring extreme edge cases in a repeatable way, not the thing you’d run your production apps on.
I mean, if I'm in a situation in which I need more powerful debugging tools than what I already have available, then I kind of want to know those tools have been built with care. If I'm deep in the weeds of trying to deliver and I'm desperately reaching for something outside of the standard tool set, I'd like the person who made that tool to have crafted it in a dwarven forge under a pale moonlight. Not to have thrown to their hands and admit a tool with the intelligence of a smart working dog breed is smarter than them.
I mean, there is a reason the MIT licence contains these words:
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND… INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF… FITNESS FOR A PARTICULAR PURPOSE…
If you would like a tool built with my organic artisanal human fingers, then I am certainly open to sufficiently large offers of money to build one for you! Alternatively, you can simply not use it if you think it won't fit your needs :)
Others have already mentioned this is basically a side tool, but I also think decent developers have a tendency to admit to slopping out when they're leaning on LLMs to an extent actual vibecoders would consider quaint.
At first read, the blog post seems at least somewhat cognizant of the shortcomings and state of the project, which is unfortunately now a high bar for new open source releases. If I needed something like this then I would not complain about what's being offered here for free.
Apparently the gRPC improvements to use shared memory when client and server are on the same, something common on network RPC not yet supported by gRPC, was done by Mark Russinovich, with agents.
I mean maybe I’m missing the point but it seems like it’s intended to be more of a tool for debugging race conditions, than a runtime you actually ship with. For that purpose I think using an LLM is fine.
I don't get it. If this is a passion project, why would you abdicate to someone else?
It's not actually unheard of for people to pay other entities to build their passion projects. For example, I visited [Eltham Palace](https://en.wikipedia.org/wiki/Eltham_Palace) last weekend, which was not in fact built entirely by the two Courthaulds who commissioned it.
The author states they feel that using LLMs allowed them to ship years faster. That's years of time in which they can collect feedback and iterate. They might even choose to scrap the entire project and rewrite it based on their learnings. The practicality of this is directly enabled by agentic coding.
There’s no accrued compound interest: if you leave a piece of “indebted” software alone, you don’t pay any “interest”.
Conversely, a small amount of tech debt can actually cost huge amount… but only if you make many changes at a high rate.
That’s why I prefer the “worn tools” or “sand in the gears” analogies because they provide the right financial mental model.
An unlubricated, worn out piece of industrial machinery costs you nothing… unless you try to make things with it.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND… INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF… FITNESS FOR A PARTICULAR PURPOSE…
If you would like a tool built with my organic artisanal human fingers, then I am certainly open to sufficiently large offers of money to build one for you! Alternatively, you can simply not use it if you think it won't fit your needs :)
At first read, the blog post seems at least somewhat cognizant of the shortcomings and state of the project, which is unfortunately now a high bar for new open source releases. If I needed something like this then I would not complain about what's being offered here for free.
https://github.com/markrussinovich/shmem
It is one example described on one of his AI talks at BUILD.
If the PR gets accepted, here is your AI contribution to core technology.