本文へ
ハクソク

世界を動かす技術を、日本語で。

ステーキを焼くのにほとんど技術はいらない

元記事: 原文(blog.sydorets.com)

概要

  • ステーキ調理 と AIによるソフトウェア開発 の類似性
  • AIツール の普及とその限界
  • 理想と現実 のギャップに対するユーザーの反応
  • 本質的なスキル習得 の重要性
  • 継続的な学習と挑戦 の必要性

AI時代のソフトウェア開発とステーキ調理の共通点

  • ステーキを「焼くだけ」なら 誰でもできる が、「完璧なステーキ」を作るには 高度な技術 が必要
  • AIを活用したソフトウェア開発 も同様で、単純な成果物は簡単に作れるが、理想的な品質や一貫性は 容易に得られない
  • AIツールやエージェント を駆使し、多様なワークフローやプロンプトを投入しても、 期待通りの結果 が毎回得られるわけではない
  • 時には 驚くほど良い成果 が得られることもあるが、多くの場合は「 見かけ倒し」や「 的外れなアウトプット」となる現実

理想を求めて他者に頼る選択肢

  • 高額なAI製品 や 外部エージェンシー、 新しいフレームワーク に頼り、誰かが問題を解決してくれることを期待
  • しかし、 根本的な課題 は解決されていないことが多い
  • 結果的に「 自分で学ぶか、次の失望に備えるか」という二択に直面

AIの限界と人間の役割

  • AIは「 レシピ通りに大量生産する機械」であり、 本当のニーズ や イメージ を理解できない
  • 要件や制約、例、テスト、フィードバック を明確に伝えない限り、AIは期待通りの結果を出せない
  • どれだけ 指示 や ツール を駆使しても、AIは「 一流シェフ」にはなれない

誰もが同じAIコックを雇う時代の現実

  • 外食しても、結局 同じAIコック が作ったステーキが出てくる
  • 「 コスト最適化」を優先し、大多数の顧客は違和感を覚えないが、 本当に作りたい人 だけが失望を感じる
  • 本物を求める人 は、最終的に自分で「 作り方を学ぶ」道を選ぶ

本質的なスキル習得の重要性

  • 熱の使い方、道具の選び方、厚みや休ませる理由 など、基礎を学ぶことで「 運任せ」から脱却
  • 失敗を繰り返し、 経験を積むことで再現性の高い成果 を得られるようになる
  • AIは補助的な役割 であり、「 判断力や品質基準」は人間自身が持つべきもの

継続的な学習と挑戦

  • AIはスピードや効率化 には貢献するが、「 本質的な価値判断や品質の定義」は代替できない
  • 自分が求めるものを明確にし、成果物を正しく評価できる力 が必要
  • 学び続け、挑戦し続けること で、理想の成果に自ら到達できるようになる
  • 最終的には「 自分のレストランを開く」レベルに到達し、 AIをうまく活用する立場 へ
  • 違いに気づける人間 であり続けることの価値

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

著者が低い品質管理基準を認めるときに、全てのソフトウェアエンジニアを代表するかのように「我々」を使うのはあまり好きじゃないな。これはちょっと気まずい話題を vulnerable な自己開示で切り出そうとしてるのかなと思うけど、問題がある時は真剣に認める必要があるよね。「バグ」は昔の航空業界を悩ませたエンジンの「グレムリン」よりも可愛くもふわふわしても面白くも無害でもない。どれだけの事故が起きて、飛行機の人たちが真剣になったのかは分からないけど、ソフトウェアの人たちも同じような覚悟が必要だと思う。

└

これって「我々」じゃなくて、普通の「我々」だよ。ロイヤル「我々」は、自分一人を指して「我々」と言うこと。ここでは、著者は自分以外の複数の人を指してるんだよね。君が指摘したように、全てのソフトウェアエンジニアを代表しているって主張してる。

└

少なくとも私の経験では、「ソフトウェア」の人たちは、短期的な考えで押し進める VP やマネジメントだね。

└

記事は置いといて、仕事で文章を書くときは、だいたい「我々」という代名詞を使ってる。ネガティブな影響について話すときに「私」と言うのは敵対的に感じるし、ポジティブな影響について話すときは自己賛美に聞こえちゃうから。例えば、「マージウィンドウの終わりに出荷されたバグを発見したので、ロールバックを適用して検証を再開します。」って感じ。学校ではビジネスに安全な書き方は受動態だって言われるけど、私はそれができないんだよね。

└

「私たち全員がもっとできたはずだ。」って、すべての政治家が言うよね。どっちが簡単？ 良いコードを書くこと、それともクソみたいなコードを巡る政治的な戦いに勝つこと？ コーディングができなくて、ドメインに適したアーキテクチャを作れないなら、どの行動がリスク管理を最もコントロールできる？ だから、ソフトウェアに関するほとんどの争いは、政治とクソみたいなコードについてなんだ。1984年からビジネスライセンスを持ってるから、期待を持たせるために言ってるんだ。

└

著者は「私たち（すべてのソフトウェアエンジニア）」とは言ってないから、クラスに君を含めてるのは君だけだよ。

└

良いソフトウェアをAIで作るには、やっぱりソフトウェアを理解しておく必要がある。 > 実際に何を求めているのか、返ってきたものをどう判断するのか、機械が自信満々に炭を出している時に気づく必要がある。これが書かれる必要があるなんて驚きだよ。もちろん、まだ頭を使ってコンピュータが何をしているのか考えなきゃね。みんなLLMが魔法だと思ってたの？

いくつかの素晴らしい会社やチームが LLM を使って、より高品質なソフトウェアを作ることを期待しているし、そう信じてる。Electron を作ったのは、ネイティブデスクトップフレームワークを使って UI を書くのが難しいから。今も難しいのかな？LLM が使いやすくしてくれるから、もっと速くてネイティブな感じのアプリができるはず。機能を良くするアイデアをいくつか考えるのはどう？今なら複数のプロトタイプを素早く作って、ベストなものを選べるよ。ユーザーには一番良いものが届く。こんな風にソフトウェアを作っていきたいな。

└

うーん、OpenAI 自体が変な Electron アプリを出して、Mac の ChatGPT のネイティブ版を置き換えたみたいだよ。 https://www.siliconreport.com/openais-chatgpt-mac-update-shi...

└

Electron を作ったのは、ネイティブデスクトップフレームワークを使って UI を書くのが難しいから。今も難しいのかな？LLM が使いやすくしてくれるから、もっと速くてネイティブな感じのアプリができるはず。Electron を作ったのは、ウェブ開発者がたくさんいたから。経済的な決定であって、技術的なものじゃない。

└

そう思うよ。でも、みんなが夢中になってるのは、エンシティフィケーションの速度を上げることだけみたいで、次のイーロン・マスクになろうとしてる。

└

これは押し引きになるだろうし、数年後にどうなってるか興味津々だね。AIを自由に動かせば100mphで飛べるし、少し操縦すれば、私が求めてる出力を得られて、一般的に検証やテストも通過できる。でも、コードにこだわりがあって、メンテナブルに保ちたいなら、出力を修正したり反復したりするのにかかる時間やトークンが、最初に節約した時間をすぐに食いつぶしちゃうことがある。趣味のプロジェクトでは、質を重視する傾向があるし、AIの非同期的な特性も、私のフルアテンションなしで進めやすくしてくれる。企業の世界では、AIで加速するプレッシャーもあるけど、コードや製品の質を維持することも求められる。今は一方か他方のダイヤルがより明確だけど、今のモデルやハーネスで両方を実現するのは、指数関数的なコストがかかると思う。面白いのは、今は賢いモデルよりも速いモデルに傾いていることだ。知性があれば、一度に大きな作業をこなせて、モデルがちゃんと動くと信頼できるけど、求める質に達するための反復回数を減らすわけではない。速いモデルなら、どんな反復を経ても、もっと早く終わるし、適切なフローステートに近づける。モデルはどんどん改善されるだろうけど、もしかしたら「十分賢い」ところに近づいていて、競争は性能 > 知性にシフトするかもしれない。

Hacker Newsで議論の続きを見る