> Using AI here is not really at fault here

Maybe reality isn't represented by the git logs, but according to them, you appear to have composed, reviewed and merged 131 commits affecting 58 files and 6000 lines -- a task that you say amounts to "replacing the engine while driving" -- in the span of one week.

If that's accurate, of course your reliance on AI is at fault here. It invites you to mistake velocity for quality and conflate test satisfaction for completion.

Without AI, this effort would likely have taken much longer and an experienced team would have approached it with due meticulousness, being especially stringent in review. Absorbed in it, the work would have weighed on their unconscious while they slept, with "Ah shoot, did I consider XYZ?" moments striking them in the shower. Ideally, familiar with the specific contributors (i.e. you) and their style of work, the reviewer who later consider merging the work would have ideas what to watch out for and would spend extra time looking at the details you might not have fully considered. It's a whole decades-matured craft practice that can do a pretty good job of making sure that a refactor of this scale doesn't land in main too broken.

And while that version still probably wouldn't have been entirely flawless either, or might never have even been attempted because of its greater calendar and attention burden, that doesn't mean that using AI wasn't responsible for why and how this version is broken.

This is exactly how AI makes things worse and why many people are wary of relying on third-party projects that embrace it too blithely. If you're going to use it, that's great, and maybe it will help you keep landing big features more quickly than otherwise -- but at least accept responsibility for the tradeoffs that you're inviting when you do so.

> Rewrite the entire node:http stack to use llhttp (Node.js's HTTP parser)

Can we please not turn Deno into junk? If you do the above -- what's the point of Deno?

Once you bolt everything on like that you might as well just use Node.

Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...

Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility

Because I wanted native TypeScript support which Node only gained relatively recently and only partially, plus the issues I showed are regressions - they worked fine in earlier Deno versions.

> Node compatibility was a distraction for the product

I've gone back and forth on this point over the years.

Yeah, Node compat has probably affected the rest of the product. I imagine at some point they (or their investors) freaked out because adoption wasn't happening. And the reality is it really doesn't matter if your product is better when nobody is using it.

In retrospect I think it would have been a better decision to target Node compat from the start like Bun did. An impossible option at the time given Deno started trying to make something different from Node.

Or maybe the problem was simply they couldn't afford low adoption after having investors on board.

To be fair, you can't blame a person for thinking that a runtime created by the same guy who created Node would work with Node.

Welp, guess the only option is to stay on some single version then and hope it doesn't get critical security issues...