今はロジックの精緻さよりも、"入力すると合う求人が実際に表示される"ことを見せるのが目的です。非開発者の社内意思決定者にデモする場なので、完成度よりも動作確認に重きを置いています。ロジックの高度化はその次の段階だと考えています。

今はまるでスマートフォン普及時代のように、モバイルファーストUXへと大きく変化し始めていた頃に似ていると感じます。まだ体系は十分に整っていませんが、興味深い変化があちこちで見られます。

すぐにブックマークしました。おそらく毎日チェックすることになりそうです。
もしよろしければ、日本語対応を検討されているか伺いたいです :)

過去の自分より今の自分がより良くなっているかどうかだけに集中する

Slackの会話をどのようにフィルタリングしてナレッジベースに取り込んでいるのか、その実装が気になります。

ブログ記事も楽しく拝読しました。
私も似たような動機でターミナルを開発している立場として、気になる点が出てきました。

個人的には、最近のように DX 環境が速く変わり、開発者ごとにやり方が異なる時代はあまりなかったのではと思っているのですが、
作者の方もそう感じられたかは分かりませんが、こういう時だからこそ制御権が自分にあるほうが有利だと考えましたし、
AI 時代の DX の土台は何かと考えたとき、私はターミナルベースだと思いました。

最近流行っているターミナルもひととおり使ってみましたが、韓国語入力もほとんどのターミナルで不十分で、エージェントを使うには DX、UX ともに不便だったので、私も自分で直接開発しようという結論に至って進めてきましたし、自分のターミナルによって他の人より高い生産性を確保できたと思っています。

私の場合、制御権を完全に得るために、
外部ライブラリへの依存も最小化すべきだと考えて、Zig でのフルスクラッチ開発を選んだのですが（やむを得ない WebView のようなものは除いて）、

ブログ記事とコードを見ると Rust を選ばれていて、rataui など、独自実装よりも Rust に存在する外部ライブラリを選ばれた理由が気になります。
記事を見ても、外部ライブラリ依存による問題があったようなので。

それから、WebView がネイティブ WebView である以上、たいていの Web 環境は Safari 環境ではないので、完全な E2E テストは難しいように思うのですが、この部分は外部のテストツールに任せる感じなのでしょうか。あるいは今後 CEF も入れる計画があるのかも気になります。

私もターミナルがある程度使えるようになって安定化段階に入り、機能追加や企画、あるいは UX をいろいろ考える段階に入っていますが、開発中はクラッシュやさまざまなバグも多かったはずで、

開発を始めてから、実行環境としても外部ターミナルではなく自作のターミナルに入れるくらい安定したのは、だいたいいつ頃だったのかも気になります。

実力のない人がいつも口にするのが、協業能力なんだよな…

マルチプレクサのインストールリンクが切れてしまっていますね。README のこの項目を確認していただければ、マルチプレクサだけをインストールできます。

その通りですね。面接まで進むと、そういった部分をそれ以前の選考段階よりも大きく見ているように思います。
そこまで行くのは難しいでしょうけど（笑）
面接まで行ける程度であれば、コーディング力よりもこの記事の趣旨どおり、それ以外に必要な能力を伸ばし、アピールするのが良いと思います。

デモで見せたいのは、マッチングロジックの優秀さですか？ それとも、こういうものがあるということですか？

以前、Ren'Pyでゲームを作って配布しようとしたことがあるのですが、
GitHub Blogという静的サイトをGitHubで1つだったかな？無料でホスティングしてくれます。
（サイトリンクはたぶん固定だと思います。）
それを使えば、静的サイトは簡単にデプロイできると認識しています。

実際、開発者採用も、あとで自分が採用する側になってみると、徹底して理性と論理だけで回っているわけではなく、人柄やフィーリングもかなり見られるんだと分かりますよね（笑）。意外と、特別な分野の天才を招かなければならないのでない限り、「この人と一緒に働くとき、不要なストレスを受けずにうまく協業できるだろうか？」というのが一番重要なポイントだったりするので。

はい、その言及はありません。
中国のオープンウェイトに賛成ではないというのは私の考えです。
ただし、「オープンウェイトに賛成する」ということではなく、
米国がオープンウェイトでも勝利することを望んでいる、ということです

共感する文章です。
ただ、就活生だった頃にこういう文章を見たときは、先に仕事を得た人たちのもっともらしいきれいごとにしか聞こえませんでした。

それもそのはずで、就活生の立場では、ある企業に開発者として応募する際、文書化、説得、コミュニケーションのような能力を証明するよりも、コーディングの実力を証明するほうが簡単だからです。
そして企業側も、新卒採用ではポートフォリオやコーディングテストの成績といったコーディング能力をより高く評価しているように見えました。
企業の立場でも、あれだけ多くの新卒応募者を目に見える形で比較・評価できるのは、それくらいしかないのでしょうね……

いろいろな意味で残念な現実です.

会社の重大な変化を発表しながら代表を交代するのは、少し不思議に見えますね

Docker Without Docker - Fly.ioの基盤技術紹介

fly.io は公開初期からGeekNewsを通じて興味深くフォローしていたサービスですが
AI時代に合わせて対応戦略を変えるということなんですね

Sprites - ステートフルなサンドボックス

これのことですが、うーん……最近CodexのSites機能でWebページを作ってみた経験があるのですが、簡単ではなさそうです。
下のHNコメントのように、ターゲット市場がかなり狭く見える気もします。

おばあさんやおじいさんまでアプリを作るような巨大な新規市場はLovableのようなサービスが取るだろうし、非開発者がSpritesを使う可能性は低い。
結局、既存の開発者の一部だけを獲得できる

「コーディングは解決した」と言った人は見たことがなくて、1年後、3年後、5年後にはああなるこうなると騒ぎ立てる有名人ばかりがニュースに出てきますね。

Xの投稿には「ただし当然ながら、中国のオープンウェイトに賛成しているわけではない」という言及はありません。
米国がプロプライエタリモデルとオープンモデルの両方で勝利することを望んでいる、という内容です。

AはBだ。BはCだ。ではAはCになれるのだろうか？ そもそも才能とは何か、それが高いのか低いのかを分かるという前提自体が、私たちの思い違いなのかもしれません。

ESP32-S3がAliExpressで1万円前後のチップだと考えると、面白い可能性が見えてきます。
たとえば洗濯機なら、説明書や洗濯コース、洗剤の種類、各機能の特性程度だけを理解する小さなモデルを載せて、インターネット接続なしでもユーザーと対話しながら使い方を説明する製品が出てくるかもしれない、と思います。

開発の動機を補足すると、Cluade、Codex Gemini、Grok の4つのセッションを3台のクロスプラットフォーム環境のマシンで回していたときに、「実行はスケールアウトできるのに、受け渡しは1人の人間に縛られる」というボトルネックを経験したのが始まりでした。tmux/SSH の代替ではなく、並行利用するためのツールです — 目的は「ターミナル接続」ではなく「セッションのアドレス指定 + 受け渡し確認」です。気になる点があれば気軽に聞いてください。