> You personally want to believe that LLM usage is somehow essentially solely responsible for the bad product
It's been confirmed (at least, in the HN thread) by a representative of Jepsen that Orkes were using adversarial LLM review. And given that even very basic test setups failed instantly, it's hard to believe that this LLM review was coupled with human review. So what I believe is that they likely adopted a form of agentic coding that had no routine human review in the process. And that, I suspect, is how they ended up in the situation of believing their software was well-tested and conformant when it wasn't. More on that in a bit.
> history has shown bad products were made by human programmers all the time
I've spent an enormous amount of time trying to teach the teams I work with techniques for creating software that isn't bad, including solid and thorough testing and review processes. The all-in LLM approach requires discarding those very techniques in favor of just trusting that enough layers of adversarial agents will get it right. My own direct experience is that this doesn't work.
And earlier this year I posted a long piece which, among other things, included a review of some studies into LLM-assisted coding which found that it's not the case that software is just as bad as before: it's the case that with LLMs, software is getting worse than before, quickly. The CircleCI report cited there, for example, is based on a huge sample of CI runs to show both the rate of failures and the time to resolution of failures, and both of those numbers went strongly in the wrong direction. CircleCI has continued to update their data, and though there's been a small rebound the state of software quality, as far as they're able to measure it, still appears to be significantly down from what it was prior to the advent of LLMs.
> If you read a positive report that said LLM usage went fine, would you be just as similarly convinced that LLM usage is actually good?
My experience is that such reports tend to be one-off anecdotes and also tend to struggle under scrutiny.
For example: also noted in that long piece I linked above was Cloudflare's big announcement earlier this year that they had used LLMs to build their own clone of Next.js from the ground up using an agentic coding/review/fix loop. This was, at the time, held up as a triumph and a great success story for LLM coding. Except if you read what I wrote about that, and follow some of the links I provided, you'll see that on release it was unable to run a basic default "Hello, world" Next.js app, and that it was riddled with security issues because, it turned out, their LLM coding agents had simply failed to copy over and use the full original Next.js test suite. Which created the false impression that Cloudflare had a well-tested and verified implementation when in fact they did not. That's the same sort of situation Orkes found themselves in, and yet at the time I don't recall prominent LLM coding advocates accusing Cloudflare (as they are accusing Orkes, now, in various places) of being dilettantes who simply didn't know how to use LLMs properly.
> People will read what they want into their report, and invent any number of scenarios that justify it.
I pointed out a basic tension with LLM usage: the selling point of LLM coding is that it generates so much software so quickly that no human can keep up with it, so you essentially have to remove human review from the loop. But LLM-only loops with no human review are not reliable enough to actually get away with doing this. ParticleDB is the latest example of this problem, but far from the only one.
To the extent that anyone has a "chip on their shoulder" in this thread, it seems to be you, since you're becoming extremely defensive and hostile over what is pretty basic and reasonable criticism of the effectiveness of LLM coding, rooted in the actual observable evidence in front of us.
14 points
Mentions
> You personally want to believe that LLM usage is somehow essentially solely responsible for the bad product It's been confirmed (at least, in the HN thread) by a representative of Jepsen that Orkes were using adversarial LLM review. And given that even very basic test setups failed instantly, it's hard to believe that this LLM review was coupled with human review. So what I believe is that they likely adopted a form of agentic coding that had no routine human review in the process. And that, I suspect, is how they ended up in the situation of believing their software was well-tested and conformant when it wasn't. More on that in a bit. > history has shown bad products were made by human programmers all the time I've spent an enormous amount of time trying to teach the teams I work with techniques for creating software that isn't bad, including solid and thorough testing and review processes. The all-in LLM approach requires discarding those very techniques in favor of just trusting that enough layers of adversarial agents will get it right. My own direct experience is that this doesn't work. And earlier this year I posted a long piece which, among other things, included a review of some studies into LLM-assisted coding which found that it's not the case that software is just as bad as before: it's the case that with LLMs, software is getting worse than before, quickly. The CircleCI report cited there, for example, is based on a huge sample of CI runs to show both the rate of failures and the time to resolution of failures, and both of those numbers went strongly in the wrong direction. CircleCI has continued to update their data, and though there's been a small rebound the state of software quality, as far as they're able to measure it, still appears to be significantly down from what it was prior to the advent of LLMs. > If you read a positive report that said LLM usage went fine, would you be just as similarly convinced that LLM usage is actually good? My experience is that such reports tend to be one-off anecdotes and also tend to struggle under scrutiny. For example: also noted in that long piece I linked above was Cloudflare's big announcement earlier this year that they had used LLMs to build their own clone of Next.js from the ground up using an agentic coding/review/fix loop. This was, at the time, held up as a triumph and a great success story for LLM coding. Except if you read what I wrote about that, and follow some of the links I provided, you'll see that on release it was unable to run a basic default "Hello, world" Next.js app, and that it was riddled with security issues because, it turned out, their LLM coding agents had simply failed to copy over and use the full original Next.js test suite. Which created the false impression that Cloudflare had a well-tested and verified implementation when in fact they did not. That's the same sort of situation Orkes found themselves in, and yet at the time I don't recall prominent LLM coding advocates accusing Cloudflare (as they are accusing Orkes, now, in various places) of being dilettantes who simply didn't know how to use LLMs properly. > People will read what they want into their report, and invent any number of scenarios that justify it. I pointed out a basic tension with LLM usage: the selling point of LLM coding is that it generates so much software so quickly that no human can keep up with it, so you essentially have to remove human review from the loop. But LLM-only loops with no human review are not reliable enough to actually get away with doing this. ParticleDB is the latest example of this problem, but far from the only one. To the extent that anyone has a "chip on their shoulder" in this thread, it seems to be you, since you're becoming extremely defensive and hostile over what is pretty basic and reasonable criticism of the effectiveness of LLM coding, rooted in the actual observable evidence in front of us.
tsrs 登場 — Rust 製 TypeScript で型チェックを CI に組み込む はじめに 2026 年 10 月、Cloudflare が VoidZero や TypeScript チームと協力して開発している tsrs が発表されました（Introducing tsrs: a Port of TypeScript to Rust）。 tsrs は TypeScript コンパイラを Rust に移植したもの で、Oxc（Vite / Rolldown / Oxlint / Oxfmt などを擁する JavaScript ツールチェーン）の一部としてインキュベートされています。 公式ベンチマークによると、同じ型チェックワーカー数で比較した場合、TypeScript 7.0 に対して 最大 8 倍高速、メモリ使用量は約 70% 削減 とされています。これは開発体験、とくに CI での型チェックに大きなインパクトをもたらします。 この記事では、tsrs がどういう技術なのかを整理したうえで、「なぜ CI に型チェックを組み込む仕組みをわざわざ作る必要があるのか」という実務的な話までまとめてみます。 tsrs とは何か TypeScript の「フォーク」ではなく「ポート」 重要なポイントとして、tsrs は TypeScript を フォークするものではありません。言語の設計と方向性は引き続き TypeScript チームが完全にコントロールし、tsrs はその実装に忠実に追従する「ポート（移植）」という立場をとっています。 TypeScript チームは機能によっては何年もかけて実装方針を検討することがあり、ポート側がそこから外れると最終的に互換性が崩れてしまいます。そのため tsrs は、オリジナル実装に厳密に沿って TypeScript 言語を保つ方針をとっています。 なぜ Rust なのか TypeScript チーム自身がすでに Go への移植（いわゆる TypeScript 7.x 系）で約 10 倍の高速化とメモリ効率改善を達成しています。それでもなお Rust を選ぶ理由として、ブログでは次の点が挙げられています。 WebAssembly との相性の良さ: Go を Wasm にコンパイルするとガベージコレクタも一緒に積む必要がありますが、Rust のメモリ管理モデルは Wasm ホストとゲスト間のメモリ連携が素直に行え、メモリフットプリントを小さく保てます。 動かせる場所が増える: 小さなメモリフットプリントのおかげで、ブラウザ内・組み込みデバイス・IoT、あるいは Cloudflare Workers のようなサンドボックス環境でも開発ツールチェーンをまるごと動かせる可能性が広がります。 エージェントとの組み合わせ: 完全にサンドボックス化された環境でビルド・デプロイの一連を回せるため、AI エージェントによる開発フローとも噛み合います。 なぜ今なのか TypeScript のポートはこれまで何度も試みられてきましたが、複雑さゆえに成功したのは TypeScript チーム自身による Go への移植だけでした。しかし現在は、フロンティアな AI モデルが大規模なポートを数日単位でほぼ自律的に進められるようになったことが、tsrs 登場の背景にあると説明されています。 使い方 実験的なリリースは npm から試せます。 npm install tsrs npx tsrs なお現時点では、診断メッセージの出力順などがアップストリームの TypeScript と異なる部分が残っているとされており、安定版リリースまでにこうした差分を最小化していく方針です。 なぜ「CI で型チェックする仕組み」を作る必要があるのか ここが実務上いちばん重要なポイントです。 ビルドツールは型チェックをしてくれない Vite や Next.js などのモダンなビルドツールは、ビルド時に 型チェックを行っていません。これらは esbuild や SWC などを使って型情報を「剥がす（type stripping）」形で高速にトランスパイルしているだけで、tsc のような型検査は走らないのが基本です。 つまり、 ローカルの開発サーバーが起動する・ビルドが通る、ということは 型が正しいことを保証しません。 型エラーがあってもビルドは成功してしまい、実行時やレビュー時になって初めて気づく、ということが起こり得ます。 この「ビルドは通るが型は壊れている」を防ぐには、ビルドとは別に型チェックを実行する仕組みを自分たちで用意する必要があります。その代表的な置き場所が CI です。 これまでの CI 型チェックの課題 CI に tsc --noEmit を組み込むのは定番ですが、大規模プロジェクトでは以下がネックになりがちでした。 型チェックに時間がかかり、CI 全体のボトルネックになる。 メモリを大量に消費し、ランナーのスペックを上げる or OOM と戦うことになる。 結果として PR のフィードバックが遅くなり、開発体験が落ちる。 ここで tsrs の「最大 8 倍高速・メモリ約 70% 削減」が効いてきます。型チェックが速く・軽くなれば、CI の型チェックを現実的なコストで回せるようになり、フィードバックループが短くなる というわけです。 CI への組み込みイメージ 現時点では tsrs は実験的なリリースのため、まずは「既存の tsc --noEmit と並走させて挙動と速度を比較する」ところから始めるのが安全です。 .github/workflows/typecheck.yml の例（イメージ） name: typecheck on: pull_request: jobs: typecheck: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - run: npm ci 既存の型チェック（正とする基準） - name: tsc run: npx tsc --noEmit tsrs を試験導入し、差分や速度を観察する - name: tsrs (experimental) run: npx tsrs continue-on-error: true ポイントは次のとおりです。 Vite / Next.js のビルドとは 独立した型チェックジョブ として用意する（ビルド成功 ≠ 型 OK なので）。 実験段階の tsrs は continue-on-error: true で「落ちても CI 全体は止めない」状態から始め、出力差分（診断順の違いなど）や速度を観察する。 十分に信頼できると判断できたら、tsc を tsrs に置き換えて CI 時間を短縮する、という移行パスを描けます。 今後の展望 Theo Browne 氏の tsc-rs と tsrs を統合し、LSP やコンテンツマッパーを含む TypeScript のフル機能をサポートする単一パッケージを目指しています。 Cloudflare が Next.js のポートである Vinext で実践しているのと同様に、エージェントを使ってアップストリーム TypeScript との差分を日次で追従・検証していく運用が計画されています。 パフォーマンス改善は可能な限り TypeScript の Go 実装側へも還元し、エコシステム全体が恩恵を受けられるようにするとしています。 さらに Oxlint の型を考慮した Lint ルールなど、tsrs を他ツールと深く統合する実験も視野に入っています。 まとめ tsrs は TypeScript コンパイラの Rust ポートで、最大 8 倍高速・メモリ約 70% 削減という大きな性能向上が期待できます。 Vite / Next.js は ビルド時に型チェックをしない ため、型の正しさを担保するには 別途 CI などで型チェックを回す仕組みが必須 です。 従来 CI の型チェックは「遅い・重い」が課題でしたが、tsrs によってそのコストが下がれば、フィードバックループが短くなり開発体験が大きく向上します。 まだ実験段階なので、まずは既存の tsc と並走させて差分・速度を観察し、信頼できたら置き換える、という段階的な導入がおすすめです。 参考リンク Introducing tsrs: a Port of TypeScript to Rust（Cloudflare Blog） tsrs（GitHub / oxc-project） tsrs（npm）
@joshmohrer @Cloudflare I beg you to try vinext cloudflare/vinext
@forefy Cloudflare did exactly that: cloudflare/vinext