私を置いていってほしい
(androidessence.com)- Android 開発は、2014年に大学のJavaの授業で知った無料講座と、最初のToDoアプリから始まり、手のひらの中のソフトウェアが現実に触れる体験が原動力になった
- 10年のキャリアは、デーティングアプリ、薬へのアクセス向上、旅行支援のように、ユーザーに実際の利益があるアプリを保守しながら、技術の目的を確かめる時間だった
- 講座、ハッカソン、最初の職場、Droidcon NYCを経て、成果物よりも人とのつながりと公開知識の共有のほうが長く残ることを実感した
- LLMは、コンパイル可能なコードやレビューまで提供できるほど改善したが、Stack Overflow 的な探索、反論、投票、試行錯誤から生まれる理解を弱めている
- ソフトウェア開発は、反復作業の自動化だけでは置き換えられない芸術であり工芸であり、人間が人間のために共に作り、分かち合う活動であるべきだ
Android開発を始めたきっかけ
- Android 開発は、2014年の大学のJavaの授業中に同級生が共有してくれた無料のオンライン講座から始まり、最初の目標はローカルストレージを持つToDoリストアプリを作ることだった
- 完成したアプリをスマートフォンで動かして両親に見せた瞬間は、"電球が灯った瞬間"として残っており、手に持ち歩いて直接操作できる現実のソフトウェアだという点が強い意味を持っていた
- アプリはポケットの中に常に存在し、整理や生産性を助ける道具であり、この体験を通じて、人々に前向きな影響を与える道具を提供することが技術の目的なのだと実感した
- 2018年には、のちに妻と出会うことになるデーティングアプリを自ら扱う仕事をし、ソフトウェアが現実に及ぼす影響をさらに直接的に経験した
- その後10年間、Android開発者として能力を磨きながら、特別な人を見つけること、薬へのアクセスを高めること、旅行を支援することのように、実際のユーザーに利益をもたらすアプリを保守してきた
開発の旅を形づくった人たち
- アプリそのものよりも長く残ったのは、アプリを可能にした人とのつながりだった
-
講座と公開知識
- 当初の目標は、できるだけ多くの情報を吸収することで、毎週講義を受けながら教授が教えるAndroidの内容を身につけていた
- Googlerたちが天気アプリの作り方を教える別の講座も受け、授業の合間や昼休みまで使ってアプリを作るほど没頭していた
- カメラの向こう側にいる人たちが持つ深い知識と、それを公に共有しようとする姿勢が強い印象を残した
-
ハッカソンとチームづくり
- その後の数年間は、実際に作りながら練習する時間へと続き、10回を超えるハッカソンに参加しながら、何百人ものソフトウェアエンジニア志望者とつながった
- 友人たちと車で2〜8時間移動し、3日間ほとんど眠らずに、ソーシャルアプリ、ペットトラッカー、NFCタグCTFゲームなどを作った
- カフェインで持ちこたえ、技術スタックをめぐって言い争いながらも、笑いと友情、チームで何かを作り上げたという誇りが主な報酬だった
- 何を作ったかや賞を取ったかは重要ではなく、経験そのものが報酬として残った
-
最初の職場とRxJava
- 卒業後、デジタルマーケティング会社でプロのAndroid開発者として初日を迎え、隣の席の同僚から「RxJavaについて何を知っている？」と聞かれた
- RxJavaをまったく知らず戸惑ったが、その同僚は判断することなく、リアクティブプログラミングや、一緒に取り組むアプリの文脈、すぐに追いつく方法を教えてくれた
- 2人はオフィスで笑いを生む同僚になり、同時に仕事と成長への深い情熱を持ち続けた
-
Droidcon NYCと知識の還元
- 同じ同僚が、最初のAndroidカンファレンスであるDroidcon NYCに連れていってくれ、同じニッチな関心を持つ何百人ものエンジニアと数十人の登壇者が集まる環境は大きな影響を与えた
- 登壇者たちが自発的に知識を共有する姿は、次の世代のAndroidエンジニアに自分の専門性を分け与えたいと思うきっかけになった
- 他のエンジニアを助ける機会を探し、それまでに受けた助けを次へ手渡していくことが、キャリアの重要な原則になった
LLMが約束した開発のあり方と実際の経験
- LLMが大衆化するにつれ、「もうコーディングを学ぶ必要はなく、欲しいものをプロンプトに入力すればコードが生成される」という単純な約束が、従来のソフトウェア開発のやり方を脅かすようになった
- 最初は新しい技術の可能性に期待していたが、実際に使ってみると、存在しないメソッドを提案したり、明らかなバグを作ったり、最悪の場合はコンパイルすらできないコードを生成したりした
- さらに良くなるという約束の後に再び使ってみると、実際に改善されており、コンパイル可能なコードを書き、スタックトレースを分析して修正案を提案し、コードレビューまで行えるようになっていた
- しかし、その改善された機能は同時に人間的な経験を枯れさせてもいた
- わからないことがあるとAIに尋ね、目標達成に使える最初の答えに頼るようになり、以前のようにStack Overflowで同じ問題を経験した人が公に共有した解決過程をたどって学ぶことが減っていった
- Stack Overflowには単なる助けだけでなく、前提を反証し、挑戦するフィードバックがあり、検索と検討、コミュニティの投票を通じて、解決策への賛否を見ながら問題と解法を根本から理解できた
自動化が弱める学習と協働
- エンジニアは自動化を好むが、自動化が最もうまく機能する領域は、些細で反復的な作業だ
- 何かを作らなければならないとき、10年間磨いてきた技術を使う代わりに機械へ委ねてしまうと、回復力があり長く使えるソフトウェアを作るのに必要な批判的思考の力が弱まるかもしれない
- LLMが素早くコードを書いてくれるからこそ、システムについてより批判的に考えられるという見方もあるが、ソフトウェア開発の学習の核心である試行錯誤を見失いやすい
- 試行錯誤とは、アプリが動くかクラッシュするかだけではなく、目標達成に最も適したアーキテクチャ、ライブラリ、パターン、スタイルを見つけるために複数の方法を試す過程でもある
- 解決策へのフィードバックについても、同僚と向かい合って実装の選択やトレードオフを議論する代わりにブラックボックスへ尋ねるようになると、実際のプロジェクトで何がうまくいき何がうまくいかなかったかに基づく会話が失われる
- トレードオフの議論は理論ではなく、他の人が実際に経験したことに基づく場合が多く、そうした会話が実装判断をより深いものにしていた
人間のためのソフトウェア
- LLMは予測機械であり、オープンな場で学び、作ることを選んだエンジニアたちの長年の献身の上で学習したテキスト生成器であり、統計的システムだと位置づけられる
- 公に作るということは、技術を囲い込まないことであり、若いエンジニアたちが探求し、理解し、学べる現実の実例を作る行為だった
- LLMは、コードがコンパイルされないときに一緒に笑ってはくれないし、誰かに「これはどう動くの？」と聞かれたときに熱意を持って説明できるほどのソフトウェア理解を育ててもくれない
- 何より、顔を上げて笑いながら「私たちがこれを作った」と一緒に言う喜びには参加できない
- 人とつながり、弱さを見せ、困難を共有し、助けを受けたあとにブログ記事や登壇で再び分かち合う習慣は、AIの利用によって弱まったが、もう一度取り戻す必要がある
- ソフトウェア開発は、献身、忍耐、強い共同体を必要とする芸術であり工芸であり、人間が人間のために作るものであるべきだ
- AIと共に作る体験が本当に未来なのだとしたら、その未来では置いていかれてもかまわない、という結論に至った
1件のコメント
Hacker Newsの意見
ここでは、プログラミング共同体に属せなかった相反する経験を打ち明けるコメントはよく扱われていたが、もう一つ考えるべき点がある。
このあらゆるソフトウェアの下流にいる、私たちが直接会話しないかもしれない人たちを忘れてはならない。必ずしも「ユーザー」だけではなく、開発者向けのソフトウェアも多いが、それでもユーザーは考慮されるべきだ。
確率的コード押し出し機にソフトウェア品質を委ねることは、世に出るソフトウェアの品質を急激に低下させている。LLM以前にも人間のミスや歪んだ金銭的インセンティブのような問題はあったが、それにさらに上乗せされている。低品質でユーザーに敵対的なソフトウェアを配布すれば、実在の人々に大小さまざまな被害が及ぶ。この「避けられない」生成AIへの滑り込みは、開発者、ユーザー、投資家など触れるあらゆる人に害を及ぼす。被害が異なる時点と方法で現れ、しかもゆっくり進行するため無視しやすいだけで、実際に起きている。
「AI」は害悪だ。私も取り残されても構わない。
個人プロジェクトをいくつか運営している立場としては、AIでまともなCIパイプラインを作り、テスト範囲を広げ、より良いアーキテクチャを組むことで、品質が客観的によくなったと言える。以前はそうした堅牢化に投資する余力がなかったが、AIのおかげで可能になったからだ。
もちろん私のコードはひどく、テストも大したことがないと言うことはできるだろうが、それでは最初から結論を決めているように見える。業界で25年働いた経験から言えば、その判断は誤りだ。ただし、中央値のコードベースがどうなるかは誰にも分からない。私が特別に勤勉なのかもしれない。エージェント型コーディングの時代はまだ6〜12か月ほどしか経っていないのだから、まだ判断保留にすべきだ。
用途によっては、ひどいソフトウェアでも存在しないよりはましかもしれない。全体として良いことなのか悪いことなのかは予測しにくい。
これらに共通しているのは、怠け者が一応動くが問題のあるコードを出すための杖として使える道具だという点だ。怠惰は選択であり、選択は意志と責任を持つ人間が行うものだ。
AIツールでより悪いソフトウェアをより速く作っているのなら、使い方を考え直すべきだ。これでより良いソフトウェアを提供できないのなら、いったい何のために使うのか分からない。
AI コードレビュー ツールが、本番に出ていたはずの欠陥を捕まえるのに非常に効果的な例を見た。
私のプログラミング経験は筆者のものとあまりにも違うので、自分が何を見落としているのか気になる。私はいつも一人でプログラミングしてきて、オンラインでもオフラインでも、プログラミングについて深く話し合った記憶が思い浮かばない。楽しそうでわくわくすることのように聞こえるが、残念ながらそんな機会はなかった。
私にとってAIは、自分が直面する具体的な問題や状況について初めて意見めいたものを得られる存在だ。今作業しているものにとって最良のアプローチは何かをかなり具体的に尋ねられ、答えを読んで検討したうえで、どの方向で進むかを決める。それでもなお、しばしばとんでもない答えを受け取るが、そんなときでさえ「AIの言ったことは本当か？」と自分に問いかけながら、問題への向き合い方をより深く考える助けになっている。
残念ながら買収前のTwitterが中心地で、その後はコミュニティが以前ほどではなくなったと感じる。
PostgreSQL、GCC、Git、HTTP、Emacsのようなツールは、使われたからといって何かを「得る」わけではない。人気が出てコントリビューションが増えることはあるが、その程度だ。Claudeをより多く使うほどAnthropicはより豊かになり、世界のプログラミングを支配しうる力の座に立ちやすくなる。だから、どれほどプロプライエタリAIが気に入っていても、私たちが代償として何を差し出しているのかを改めて考える必要がある。それは単に月200ドルというだけではない。
産業革命が頂点に達していた頃に Mario Savio が語った言葉がある
機械の働きがあまりにも嫌悪すべきものになり、心があまりにも痛んで、参加することも受動的に参加することもできなくなる時が来る。その時には、自分の体を歯車や車輪、レバーやあらゆる装置の上に投げ出して、それを止めなければならない。そしてその機械を運営し所有する人々に、私たちが自由でないならその機械もまったく動かせないのだと知らせなければならない、という話だ
当時も機械が多くの仕事をするようになったが、私たちは今もなおちゃんと機能している。結局これも道具の使用となって、人間の知能をまた別の頂点へ連れていくのだと思う
人間の知識ならそうかもしれないが、知能は違う。集団としての私たちは愚かで、さらに愚かになっていく方向にあり、AIが生む怠惰で思考しない傾向がその流れを加速させるだろう
私も自分は比較的「知的」だと思っているが、その概念は過大評価されていると思う。愚かで心配なく生きたい。自転車に乗り、空に矢を放ち、エスカルゴを食べ、時が来たら眠ったまま死にたい。だが現実では働き、老人ホームを探さなければならない
とにかく機械的代替と思考の代替は比較にならないのに、いちばん考えの浅い親AIコメントが上に来る傾向がある
この記事は私に多くの気づきを与えてくれた。書き手の苦痛が理解できる気がするし、読みながらそれをはっきり感じた。違いを生んだのが「人々」だったという点は少し驚きで、私にはそういう経験がほとんどなかったために、この技術の見方に大きな影響を与えていたのかもしれないと気づいた
私にとってソフトウェア作りはたいてい孤独な過程であり、周囲の人たちよりはるかに強く執着するものだった。技術中心の地域に住んでいるわけでもなく、プログラミングやソフトウェア工学、AIについてよく知っている人たちと多く話せる環境でもない。書き手のように新しい技術や新しい言語を学ばなければならなかったことはあるが、はるかに経験豊富な開発者の助けを受けたのではなく、家で一人で学んだ
LLMは、いくつかの事実が同時に成り立つ状況の中に私たちを置いており、前に進むにはこれをどう調整し解決するかを見つけなければならない。LLMを使いながら学ぶこともできるし、学ばないこともできるが、それは利用者のアプローチと欲求、意志力の結果だ。LLMの利用にもほとんどあらゆることと同じく熟達度があり、利用者の熟達度はその技術への認識や、周囲の人々がその技術をどう見るかに影響する。未熟な利用者はより否定的な感情を生み出す
ある人たちは機械が得意なことを自分でやるのが好きなので機械にやってほしくないし、別の人たちはそういう作業が嫌いなので機械にやってほしい。今年のある時点で、私はプログラミングそのものよりも、システムを作り設計し問題を解くことのほうがずっと好きだと気づいた
ソフトウェア開発はさまざまなものが一つに束ねられたもので、それを一つのものとして語ると余計に混乱する。アプリケーションのロジックを自分で考え、LLMにコードを書かせる人もいれば、LLMに解決策を考えさせ、実装し、テストしてほしい人もいる。この二者は目標と欲求が異なる、まったく違う人たちだ。誰かがClaudeやChatGPTを見るとき、あなたが見ているものとはまったく別のものを見ているかもしれない
ほとんどの場合は本やオンラインの文章を掘り下げながら、動作原理についての自分なりのメンタルモデルを作らなければならず、その過程はかなり役に立った
今やAIは学べる道具であり、正しいやり方を示し、何が起きたのかを詳しく説明してくれる道具になった。質問し、ミスを指摘し、さまざまな実装を行き来しながら、最終的にはより良いプログラマになれる。多くの人が言うように、AIは人によって意味が違う。私にとっては力を与え、気づきを与え、謙虚にしてくれる道具だった。学ぶべきことはいつも多すぎて時間は足りなかったが、今では必ずしもそうとだけ感じなくなった
独占的AIの問題は、Anthropic、Google、OpenAI のような企業が、利用者よりもAI利用から多くの利益を得る点にある。PostgreSQL、GCC、Git、HTTP、Emacs のような道具は、使われたからといって何かを「得る」わけではない。人気が出て貢献が増えることはあるが、その程度だ
Claudeを多く使えば使うほどAnthropicはより豊かになり、世界のプログラミングを支配できる権力の位置に立ちやすくなる。だから独占的AIがどれほど気に入っていても、私たちが代償として何を差し出しているのかを改めて考えるべきだ。それは単に月200ドルではない
オープンモデルとオープンソースエージェントには賛成だが、巨大企業にさらに力を与えたいとは思わない。5年後にこの大企業たちが私たちの上により大きな権力を持つようになったら、ソフトウェア工学がどう変わるかを想像すると恐ろしい。たとえば Claude Code のプロンプトの合間に広告を見たくなければもっと払えとか、生成されたコードがアプリ内に広告を埋め込まないようにしたければもっと払え、といった具合になりかねない。今の世界のインターネットで経験しているひどい体験が、ソフトウェア工学のワークフローの奥深くにまで埋め込まれることを本当に望むのか？
現在のLLMの状態だけを見て、あれこれ極端な予測をしているが、市場がどう展開するかは分からない
プログラミング能力やバイブコーディング文化も、初期の電気自動車に似ている。電気自動車が内燃機関より適している役割はあったが、同じ仕事を完全にこなすまでにはあと10年はかかった。その間、インフラがなく技術も未熟だという理由で、電気自動車を物珍しいおもちゃ、非実用的で高価で危険なものとして見下す人たちも多かった
今見えている本当の堀はデータセンター需要くらいだが、これも規模が拡大してコモディティ化し、RAMの生産も追いつくだろう
ほとんどの人間は仕事から目的や意味を得ている。昔からずっとそうだ。人々の人生から意味を大規模に取り除くと、何が起きると思う？ あまり良いことにはならないだろう
本当の問題は、すべてのプロレタリアートに必要な賃金を取り去ったときから状況が「面白くなる」という点だ
この記事には共感する。今起きていることに対する自分の反応も「自分を置いていってくれ」だ。
ただ、昔ながらの開発者として成長していく楽しさを懐かしむのは、理由として間違っているだけでなく、ダーウィン的に見てもかなり危険だ。顧客は最終的にどうやって作ったかは気にせず、長期サポート、コスト、予測可能性などを気にする。
とはいえ、業界が実際に純効果として前向きな進歩をしたと言えるのかは分からない。全体として大きな混乱だ。多くの場合、AIは私たちを同じ方向へターボモードで押し進め、より雑で高価にするだけでなく、危険にもしている。
自分が「放っておいてくれ」と言うのは、この混乱を第一原理からきちんと考えれば機会と見なせるからだ
この記事は、AIをまったく使わないか、すべてをAIに委ねるかのどちらかだという偽の二分法を作っているように見える。実際にはそうはならない。作業のどの程度をAIに任せるかは自分で選べる。人間の専門性、コミュニティ、技術への情熱が入り込む余地は、今でも非常に大きい。
AIをめぐる公開の議論を見ていると、認知行動療法でいう認知の歪みを思い出す。特に白黒思考と破局化だ。これはしばしば不安や精神病の症状でもあるが、ときには社会全体もこうした症状を示しうるのかと考えてしまう。
https://en.wikipedia.org/wiki/Splitting_(psychology)
https://en.wikipedia.org/wiki/Cognitive_distortion#Decatastr...
チームがPR処理量やトークン使用量で測られるようになると、完全にバイブコーディングしている人の隣で自分はより「悪く」見えるかもしれない。自分がバイブコーディングをしなければ昇進で不利になるのではと怖い。
バイブコーディングが悪いかもしれないことを示す指標は遅行指標だ。性能問題、サービス低下、大規模データ移行のようなバイブコーディングの問題は、いつも後になって表面化する
ただ彼らは少数派で、多くの人は中間点を見つけるはずだ
自分はシニアPHP開発者だが、最近Ruby on Railsのプロジェクトに移った。まったく不慣れな環境だ。顧客はLLMをできるだけ多く使うよう勧めてきた。
問題は、AIにコーディングさせるとコードベースを学ぶのがほぼ不可能になることだ。意識的に掘り下げない限り、一度に数行以上のコードを見ることがほとんどなく、速度要求のせいでその時間も取れないかもしれない。結果として、チームの誰もコードのどの領域にも精通しなくなる。これは過去25年間のコーディングのやり方とはまったく違うし、楽しさも少ない。
100年前なら、家具は職人が作ったものしか買えなかった。本物の職人だ。今ではIKEAと手作りが選択肢としてある。ほとんどの人はどう作られたかを気にせず、役目を果たしてくれればいいのでIKEAを選ぶ。それでも手作り家具を好む人はいて、彼らは大金を払う。
ソフトウェアもその方向へ進んでいるように思えるし、残念だが同意する。ソフトウェア開発は趣味になるだろう。多くの人が余暇に木工をするようなものだ。本当に優秀な専門家はごく少数だけ残り、主にコンサルティングをするのかもしれない。あるいは学習データを作ったり、AIが習熟するフレームワークを設計したりするのかもしれない。分からない。ただ、これから確実に違うものになり、そのすべてが良い方向というわけではないだろう。
今はAIが人間のために作っていて、ときには別のAIのために作ることもある。ごく近いうちにAIが別のAIのために作り、ときどき人間のために作るようになるだろう。さらにその先では、AIは主にAIのために作り、人間のために作ることはまれになるだろう
あなたの国でもそうではないか調べてみるといい。IKEAが自動的にすべての地元店を潰したと思い込む人がいるが、探してみれば地元の家具店はたくさんある
この記事はLLMが書いたか、最近の標準的なブログ文体で書かれたように見える。その文体自体がますますLLMっぽくなってきている。
Sam Krissが最近の記事で、そういう「癖」をうまく指摘していた: https://samkriss.substack.com/p/if-you-let-ai-do-your-writin...
AIの「癖」というものが、定義上は人間から来ていることを理解していないのだろうか？ Sam Krissの記事は華美な文体を批判しつつ、Salman RushdieやArundhati RoyがAIと同じ「安っぽい手口」を使っていると例に挙げているが、どれだけ敬意を払っても受け入れがたい。奇妙な比喩を使うとLLMを使ったかのように決めつける話題に、危ういほど近い。人間はLLMがなくても、はるか昔から奇妙な文章を書いてきた。
それに、この記事にはいったいどんな「癖」があるというのか？ とても率直に読めるし、奇妙な比喩もない。全角ダッシュも実際には手がかりではなく、むしろこの記事のように「 - 」のようなスペース-ハイフン-スペースを使うのはかなり人間らしく見える。何より、LLMでプログラミングしたくないという記事を書いた人には、疑わしきは有利にで接したい。
「孤児を殴る機械が自分を実存的不安と恐怖で満たすが、それを読者に伝えるには、その機械に孤児を何人か殴らせなければならない」みたいなのは妙だ