Something of a passion project. It's going to fail horribly if you try and use it, I'm sure, but it can already do some neat stuff!
[flagged]
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.
Don't feel bad, there's a lot of blind hatred. I too build some things I architected similarly, things that I know take companies many a buck and years to build.
because some software engineers enjoy shipping usable software more than writing the code needed to do so?
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.
It sort of isn’t though, because it gives the wrong impression to people who look at things through a financial lens.
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.
You can take this analogy quite far: sharp and lubricated but outdated machinery may work “just fine”, but you won’t be able to attract the top talent used to working with modern 5-axis CnC tools instead of having to manually turn cranks like a savage.
This sounds like something a furry would name their project :)
But it’s not Rust!
Oh there are furries all over tech. All over. There are those who haven't discovered Rust yet, for instance.
[flagged]
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.
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.
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.
Something of a passion project. It's going to fail horribly if you try and use it, I'm sure, but it can already do some neat stuff!
[flagged]
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.
Don't feel bad, there's a lot of blind hatred. I too build some things I architected similarly, things that I know take companies many a buck and years to build.
because some software engineers enjoy shipping usable software more than writing the code needed to do so?
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.
It sort of isn’t though, because it gives the wrong impression to people who look at things through a financial lens.
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.
You can take this analogy quite far: sharp and lubricated but outdated machinery may work “just fine”, but you won’t be able to attract the top talent used to working with modern 5-axis CnC tools instead of having to manually turn cranks like a savage.
This sounds like something a furry would name their project :)
But it’s not Rust!
Oh there are furries all over tech. All over. There are those who haven't discovered Rust yet, for instance.
[flagged]
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.
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.
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.