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.
> Then in 2026 I got the same LLM psychosis everyone else has
Yeah, ok, nevermind
I'm sorry. Stuff like this that preports to be base level, core technology, needs to not be "lolwhogivesashit" in its approach. You can yolocode your stupid little side tools all you want, nobody cares. But if you are trying to be a core component of a dev stack, I want to know that every line is understood by someone on your team.
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 :)
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.
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!
Is it, though? A passion project? Cuz it sounds like you lost the passion and have started to farm it out to Anthropic.
I don't get it. If this is a passion project, why would you abdicate to someone else?
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.
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.
> Then in 2026 I got the same LLM psychosis everyone else has
Yeah, ok, nevermind
I'm sorry. Stuff like this that preports to be base level, core technology, needs to not be "lolwhogivesashit" in its approach. You can yolocode your stupid little side tools all you want, nobody cares. But if you are trying to be a core component of a dev stack, I want to know that every line is understood by someone on your team.
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 :)
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.