1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • AIツールは開発生産性とチームの能力を高めたが、ソフトウェアの品質と安定性はそれほど改善されておらず、ユーザーはアップデート後にまず以前より悪い体験を予想するようになっている
  • 銀行アプリでの繰り返しのFaceID認証、Slackのフォーカス奪取、LG保証申請の失敗、自動車インフォテインメントの不具合など、日常的なバグが金融・業務・顧客サポート・運転全般を妨げている
  • 単純だった過去とは異なり、新たな抽象化、フロントエンドフレームワーク、インフラの複雑性が積み重なり、高まったユーザー体験の基準と相まって、システムはますます脆弱になっている
  • 最新モデルと十分なトークン予算があっても、安定性の改善はKPIや発表資料で目立ちにくく、企業はバグ修正よりも新機能と再設計を優先する
  • 企業がAI負債を積み上げる一方で、個人開発者は過去には作るのが難しかったソフトウェアに挑戦でき、macOSとWindowsへの反発が日常ソフトウェアの改善へ広がる余地がある

AI時代にも悪化するユーザー体験

  • AIブームの中で、人々はあらゆることが自動化される前に市場価値を確保しようとして、過剰にトークンを消費している
    • モデル性能の向上と相次ぐプログラマー解雇、年末までにAIがコードの100%を書くという見通しが不安を強めている
  • エージェント時代は、より高い生産性と品質を約束する
    • 新しいツールは、ソフトウェアを作り使う方法をすでに変えつつある
    • 経営陣がチームに求めるアウトプットは増えており、ソフトウェアチームの平均的な能力も以前とは異なる水準まで上がっている可能性がある
  • しかし実際の製品は、基本的な安定性すら確保できていない場合が多い
    • 銀行アプリは、3D Secure確認画面が表示されるまで平均3回のFaceIDログインを要求する
    • macOS版Slackは遅れて起動したあとGhosttyからフォーカスを奪い、ターミナルに入力していたgit pullコマンドをグループチャットに送信してしまう
    • LG冷蔵庫の保証申請は、多数のフィールドを含む多段階フォームの最後の送信段階で失敗し、JavaScriptコンソールを確認して初めてエラーが分かった
    • 自動車インフォテインメントはアップデート後、運転のたびに再起動し、方向指示器の音が消えたり、Google Mapsの代わりにラジオが開いたり、画面入力も1〜2秒ずつ遅延した
    • 自動車の不具合は単なるUX上の不便を超えて、運転への集中力まで低下させる
  • 自動車OS再設計チームのPMはLinkedInで成果物を自賛していたが、実際のユーザーは相変わらず製品と格闘し続けなければならなかった
  • そのチームは最新モデルと潤沢なトークン予算を使っている可能性があり、LLMも機会さえ与えられればバグ修正で優れた性能を発揮できる

複雑性とKPIが品質を押しのける構造

  • ソフトウェアには昔からバグがあり、macOS Snow Leopard時代が完全に安定していたというノスタルジーには選択的記憶が混じっている
    • 過去のソフトウェアがより良かったとすれば、主な理由は今よりはるかに単純だったからだ
    • その後、新しい抽象化やフロントエンドフレームワーク、より多くのインフラの複雑性が追加された
    • ユーザー体験の基準は上がり続けたが、システム全体はむしろさらに脆弱になっている
  • macOSとそれに依存するアプリのアップデートは、期待よりも不安の対象になり、ユーザーは新バージョンが以前より悪い可能性からまず想定するようになった
  • 問題はAIそのものより、AIをどこに優先的に使うかにある
    • GPUインフラは開発者に強力な能力を与えたが、より良いソフトウェアを作るためには十分に使われていない
    • ソフトウェア企業は長年KPI中心で動いてきており、安定性向上は数値に直接反映されないことがある
    • 1四半期のあいだ新機能と再設計を止め、バグ修正だけに集中する計画は発表資料では目立ちにくい
  • こうした優先順位が変わらない限り、ソフトウェア品質の低下も続かざるを得ない

個人開発者に開かれた機会

  • 企業が集団的にAI負債に陥る一方で、個人開発者は過去であれば自分の能力の範囲外だったソフトウェアを作る機会を得ている
  • 自動車のAndroid AutoやLGのWebサイトへの期待は低いが、現在の状態に積み重なった不満は日常ソフトウェアを改善する原動力になり得る
    • macOSとWindowsの現状に対抗する反発の動きはすでに現れている
    • この流れがソフトウェアスタック全体へ広がる可能性に期待がかかっている

1件のコメント

 
GN⁺ 5 시간 전
Hacker Newsの意見
  • 以前は無料でどんな新機能が追加されるのか期待しながらアップデートしていて、Fedora Workstation 45 の変更点も探していたが、今ではスマホ・TV・自動車・Linux 以外の OS のアップデートにはまず恐怖を感じる
    望まない機能や外部接続がまた追加されるのではと心配になり、macOS は小さな透明の境界を探してウィンドウサイズを調整させるなど、ずいぶん前から期待感を失わせていた
    Windows 11 はセキュリティアップデートの後に、望まない接続機能や AI 機能 を再び勧めてくるような ダークパターン を使っているように見えた

    • 今では「アップデート待機中」アイコンを見ると、今度は何を壊すのかとまず心配になる
      ビデオゲームを除けば、ほぼすべてのソフトウェアアップデートが嫌で、Dead By Daylight でさえ、開発元 Behaviour の無能さがゲーム内だけに閉じていることがせめてもの救いだ
    • アップデートが怖くないソフトウェアは 自由・オープンソースソフトウェア(FOSS)
      プロプライエタリソフトウェアはもはやユーザーのために作られていないが、一部の FOSS は今でもユーザーを優先している
    • Windows の 累積セキュリティアップデート 自体には新しい OS 機能は含まれておらず、Pro エディションでは少なくとも以前は品質・機能アップデートをスキップできた
      その代わり、自動更新される Store/AppX パッケージで「接続された環境」を配布し、パッチ後の再起動時に OOBE を実行して機能を再度勧めたり有効化したりする
      技術的にはセキュリティアップデートに束ねていないとしても、ユーザーを軽視するダークパターンであることに変わりはない
  • こうしたツールと Silicon Valley の「速く動いて壊せ」という文化が結びつき、チームの生産量に対する経営陣の期待値 を引き上げており、その期待に耐えるのがいちばんつらい

  • ソフトウェアは素早く作れるが、正しいという確信を得るにはより多くの時間が必要だ
    AI コード生成によって熟練エンジニアが以前なら 1 週間かかっていた仕事を 1 時間で作れることもあるが、正確性の検証時間 まで短縮してくれるわけではない
    多くの開発者は生成速度の利点だけを取り、安定性・性能・無欠陥性を確認するコストには目を向けないが、一般向けソフトウェアの品質低下自体は AI 以前から続いていた

    • 同じ品質を前提にすると、1 週間を 1 時間に短縮 できるというのは極端に理想的な最良ケースに近く、普通は 2~3 時間かかる仕事を 1 時間で済ませる程度に見える
      効果は作業によって大きく異なり、長期プロジェクトでは線形には拡張せず、ときには AI がかえって大きな遅延を生む
      品質を無視すればとてつもない速度を出せるが、AI がなくても品質を気にしなければずっと速くなる
    • 確信を与えるのは開発期間よりも 実運用で動いた期間
      どれだけ長く開発しても、本番環境で 3 か月きちんと動いた結果のほうが信頼できるので、早く、頻繁にリリースすべきだ
  • ソフトウェア品質は常に 市場のインセンティブ に左右されており、AI が堅牢なソフトウェアを作る動機を自然に与えるわけではない
    市場は、アップデートのたびに壊れないアプリや複数の独立したソリューションの組み合わせよりも、Microsoft のワンストップ製品を選ぶほうに報酬を与える
    昔はコンピュータ性能や知識が不足していてそうできなかっただけで、今や業界は、ソフトウェアがかろうじて立っていられる最低条件と、ユーザーが受け入れる細かな不便さの限界を見つけたようなものだ

    • みなが離脱したり被害を受けたりする寸前の状態に引き留め続けることが、社会が落ち着く地点として妥当なのかは疑わしい
    • 完全性と正確性が 90~99% の領域 に達すると、コスト曲線は漸近的に急騰し、収益の観点では投資に値しなくなる
      欠陥による法的責任リスクが大きいときにだけ、完全で正確なソフトウェアが作られる
    • 品質低下を受け入れながら消費を続け、「もう十分だ」と止まることになる 実質的な限界点 がどこにあるのか気になる
  • KDE Plasma の Wayland には、どのウィンドウがフォーカスを奪えるかを制御する グローバル設定 があり、非常によく機能する
    仕事用の Mac や Windows PC を使うたびにこの機能が恋しくなり、ドキュメントは「Focus stealing prevention」の項目で見られる: https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...

    • 悪化していくソフトウェアを避ける確実な方法は、FOSS と Linux/KDE に移行することだ
      Windows 7 がそのままゆっくり改善され、有用な完成度を加えていったような環境だ
      NixOS にはライブラリ読み込みが n² になるため GUI プログラムの起動が遅くなる長年の問題があるが、N100 ミニ PC でもすべておよそ 1 秒以内に起動し、4K 240Hz HDR モニターも滑らかに扱える
      何より、コンピュータが命じたとおりのことしかしない
    • macOS にフォーカス奪取防止機能がないというより、アプリ起動が遅延する状況そのものを設計者が想定していないように見える
      ユーザーが待っている間に別の入力をしたなら、もはやそのアプリにフォーカスを与えてほしくないという合図かもしれないが、アプリは即座に開くという 楽観的な状況 だけを前提にした設計に見える
    • 今日の技術で最もつらいのは、ユーザーが押そうとする瞬間にインターフェースが変わる 予測不可能性
      タッチキーボードのおすすめ単語は指が触れる直前に変わり、iOS Liquid Glass や不安定な Web アプリではボタンまで動く
      ポップアップや「このアプリは気に入りましたか?」のようなエンゲージメント誘導もあふれている
      Windows のフォーカス奪取は 1995 年にも問題だったし、100ms 単位で繰り返される突発的な変化は筋肉の驚愕反応や辺縁系を絶えず刺激し、数時間後には体が震えるほどだ
      スロットマシンのような刺激やクリック数狙いのエンゲージメント指標はやめて、作業に集中できるようにすべきだ
    • 素晴らしい機能だが、現在は「Low」より高い防止レベルで過剰に積極的にブロックしてしまうバグがある: https://bugs.kde.org/show_bug.cgi?id=509990
    • Windows では Slack はバックグラウンドで読み込まれ、準備ができるとタスクバーのアイコンだけが点滅するので、ユーザーが自分で切り替えるまでは現在のアプリのフォーカスを奪わない
  • ユーザーが入力中、または UI と対話中は、他のアプリが絶対にフォーカスを奪えないようにするフォーカス強奪デバウンスをデフォルトにすべき
    ポップアップ・音・アイコン点滅を使うにしても、今している作業と無関係なアプリが入力を横取りしてはいけない
    Cisco AnyConnect のように接続ボタンを押したあと、接続されたことを理由に例外を求めるような話でもなく、ターミナルアプリが STDIN を奪う行為を許容しないのと同じく、GUI でも許可すべきではない

    • 自動的にフォーカスを奪われたい状況など実質的にないのに、この動作がデフォルトで頻繁に起きるのが理解できない
    • macOS でも新しく開いたアプリをフォーカス外に置けることがあり、ノートPC を長く再起動していないと一貫して発生する
      バグかもしれないが、アプリ起動が終わる前にユーザーが別のウィンドウをクリックしたなら、むしろ適切な機能かもしれない
    • OS のイベントキューはプロセスやウィンドウをまたいで動作するため、これを単純にデバウンスするのは難しい
      X11 のように新しいウィンドウへフォーカスを与えないことはできても、それが大多数のユーザーの望む動作とは限らない
    • ポップアップ・警告音・アイコン点滅も十分に悪質な妨害であり、ユーザーの集中力はそれ以上に大切だ
  • 問題は元からコードを書く行為そのものではなく、何かを注意深く厳密に作るプロセスだった
    ソフトウェア開発は長年にわたり習慣、安全装置、検証済みの構造を蓄積して発展してきたが、今では問題だけを記述し、あまりに速く生成された結果を十分にレビューできないまま、自分たちが何をデプロイしたのかも分からなくなっている
    手作り家具が工場生産品に置き換わり、誰がどの部分を作ったのか分からず長持ちもしなくなったように、ソフトウェアも理解なき組み立てと配布の段階に達した
    粗悪さは蓄積していくだろうが、もう一度きちんと作る方法を真剣に考える循環の始まりになるのかもしれない

    • NPM の left-pad 事件はすでに 10 年前であり、サプライチェーン攻撃や SBOM の議論も以前から続いており、SourceForge は配布ファイルにアドウェアを混ぜ込んだこともあった
      コードレビューをしないのなら、AI にコードを任せることは PIPNPM install を無検証で実行するのと比べて、特別に悪いわけではない
  • コーディングが解決したという前提そのものが間違っているから、ソフトウェアは悪くなり続けている

    • コーディングは解決したのかもしれないが、そもそもボトルネックではなかった
      コーディングは昔から安価で、企業は最も安い人材に外注してきたが、問題を特定し解決策を設計する能力は別物だ
      コードは資産というより負債であり、実際の問題を解決するために必要最小限だけ書くべきで、そこにはエンジニアが必要だ
      AI の出力をレビューして誤りを直していると、自分で書くのと時間があまり変わらず、業務の大きな助けにはならない
    • 本当の問題はコーディングが解決したことではなく、そう信じていること
  • ソフトウェアが悪化していることには同意するが、AI だけを責めることはできない
    ストリーミングのテレビ転送失敗、ブラウザの 500 エラー、公共タッチスクリーンのブルースクリーンは以前から存在していた
    プログラマーの数が指数関数的に増え、その半分が経験年数数年以下であることに加え、単一スレッドのアルゴリズム練習だけでは分散システム・CQRS・イベントソーシング・監査可能性・冪等性は扱えない
    さらに、非技術職のプロダクトオーナー(PO)がライフサイクルを支配してMVP の正常系だけを実装させれば、バグと将来の作り直しは確実になる
    言語は C++ から Java、JavaScript、Python へと初心者向けになってきたが、仕事の中身は企業間の分散システム、24時間稼働、数百万ユーザー、セキュリティ、機械学習など、より複雑になっている

    • MVP が終わると魔法のように出荷製品と見なされ、チームが改善方法を把握する頃には経営陣が組織をまたシャッフルしてしまう
      役員昇進や部門統合を「わくわくする知らせ」として包む一方で、製品改善の継続性は失われる
    • プロダクトマネージャー中心主義と MVP への執着が品質低下の大きな原因だ
      アジャイルを文字通り愚かに適用する必要はなく、インフラでもユーザー向けアプリでも、先行製品・競合・チームの経験をもとに 3・6・12 か月後に必要な機能を計画できる
      GPS に従うときでも全体ルートと次の 3 ステップを確認するように、アジャイルとは一歩終えるまで次の一歩を一切考えないという意味ではない
    • プログラミングを誰でもできるほど単純にしようとした結果、本当に誰でもやるようになった
    • Uncle Bob も今や AI を全面的に受け入れつつあり、問題の一部になる危険がある
    • AI は品質低下の原因ではないかもしれないが、衰退を加速させている
      機械がベッドを 150% 速く作れても不良率が 70% なら、不良品の増加、木工の専門性の消滅、職人の意欲と有用性の低下が同時に起きる
      いつか機械が改善されるとしても、その間に大勢の人がひどいベッドで寝なければならないのと同じだ
  • LLM はコードベース全体を一度に読み、理解し、その理解に基づいて判断することはできない
    プログラミングの難しい部分は関数やクラス 1 つではなく、巨大なシステムの中でそれらがどう相互作用するかであり、ソフトウェアの規模はLLM のコンテキストウィンドウより本質的に大きい
    コンテキストウィンドウが広がっても、人間のように理解を蓄積するわけではないので、AI がコーディングを解決したとは言えない
    新規プロジェクトでは有用だが、新しいソフトウェアを素早く作ることは、もともと古いコードで作業するより簡単だった