- 生成AIでプロジェクトを完成させても、依頼した人と実際の制作主体が異なるなら、「自分が作った」という達成感は得にくい
- プロンプトにはビジョン・判断・コミュニケーション・技術が必要だが、直接作る技術というよりは、別の存在に制作を任せる技術に近い
- 自分で書いた177行のスペイン語フラッシュカードシステムは、Claudeより約50倍時間がかかったが、AIが作ったどのコードよりも大きな誇りを与えてくれた
- コンパイラ・アセンブラ・ハンマーは作り手の道具に感じられる一方、人間の言語に応答するAIは指示を受ける人のように見え、道具と代理制作者の境界を曖昧にする
- AIによる生成も創作行為であり得るが、成果物を完成させることと自分で作ることは、個人的な充足感において同じではなく、その境界も明確に定義しにくい
AI開発が変える達成感
- 生成AIとLLMを使う開発者は、相反する変化を同時に経験する
- 手でコーディングする職人気質、低レベルの問題解決、楽しさを失う可能性がある
- 高レベルの問題解決が増え、先延ばしにしていたプロジェクトを完成させ、新しい楽しさを得られることもある
- こうした損得を超えて、AIが代わりに完成させた成果物を自分が作ったと感じられるのかが核心的な悩みである
- 1980年代のマイクロコンピュータ時代からコーディングし、業界で20年間働き、現在はコンピュータサイエンスを教える開発者の経験から出発している
- AIユートピアと破滅の尺度で、自分を65%破滅寄りと評価している
- Claude Codeを使いながら、自分でのコーディングも並行している
AI成果物で飾った「多才さ」
- 導入部には、自分で作ったように見える複数の成果物が登場する
- 戦闘シーンを描いたSF小説 The Vorrkai Interval
- パステルカラーの木版画 Mirrors of the Machine
- 新しく作った杉材の玄関デッキ
- Rustで書かれたTUIアドベンチャー・ローグライクのコード
- 実際には、小説・絵・コードはAIが生成し、デッキは報酬を受けた熟練職人たちが施工した
- 本人が担った役割は、制作を開始し要件を伝えることだったため、これらの成果物を自分が作ったと言うのは居心地が悪い
「自分が作った」と言いにくい理由
- 他人が施工したデッキは、「自分が設置した」よりも「設置してもらった」と区別するほうが正確だと考えている
- Claudeが生成したコードも「自分が作った」ではなく、「自分のために作らせた」と表現する
- 雇用関係ではないAI生成物に自分の名前でMITライセンスを付けることにも抵抗があり、Unlicenseを使っている
- マネージャーとして働いていたときも、「自分が製品を作った」ではなく「私たちのチームが作った」と言い、LLMを管理していたなら「私のエージェントたちが作った」と表現する
- プロジェクトを終わらせること自体は良いが、自分が始めたプロジェクトを他者が完成させると、自分で制作する場合より充足感ははるかに少ない
- 失われるのは、コーディング技術や問題解決の楽しさだけでなく、何かを自分で作る経験である
手作りの177行フラッシュカード
- 妻が、スプレッドシートに覚えたい単語を入れてフラッシュカードとして見られる、シンプルなスペイン語学習システムを求めた
- 実装は自分で担当し、Claudeにはコードを生成しないよう指示し、Google Sheetsからデータを取得する最も簡単な方法といった基礎情報だけを質問した
- Google SheetsのCSVエンドポイントを使用した
- JavaScript 112行、CSS 33行、HTML 32行で、計4ファイル177行を書いた
- Claudeが作る場合より約50倍長くかかったが、自分の名前を付け、自分で作ったと言える
- 規模が大きいわけでも画期的なコードでもないが、Claudeが書いたどのコードよりもはるかに大きな誇りを感じる
- 要求を出した妻が、自分がフラッシュカードシステムを書いたとは言わないのと同じく、依頼者がそのまま制作者になるわけではない
プロンプト作成という別の技術
- 効果的なプロンプトには、明確な人間の貢献が必要である
- ビジョンを適用しなければならない
- 結果を判断しなければならない
- コミュニケーション能力とプロンプト作成能力が必要である
- すべてのプロンプトやAIユーザーの効率が同じではないため、プロンプティングにも重要な技術が存在する
- ただしこれは、直接制作する能力というより、欲しいものを効果的に作ってほしいと依頼する能力に近い
- ソフトウェアのプロンプティングも、直接ソフトウェアを作る行為というより、別の存在に制作を任せることのように感じられる
コンパイラとAIの間にあるグレーゾーン
- CやRustのプログラムを書くとき、実際に実行される機械語まで自分で書いているわけではないが、それでも自分がプログラムを書いたと感じる
- Cコードから機械語への変換は数学的に精密なプロセスに近いが、いくつかの疑問が残る
- ClangとGCCは異なる命令を生成するため、結果が厳密に一つに決まるわけではない
- プラットフォームごとに機械語が異なっても、Cコードは移植可能である
- Linuxでしかビルドしていなくても、Windowsで動くプログラムを自分が書いたと見なせる
- Claudeに再帰的なFibonacciのCプログラムをx86_64 Linuxアセンブリへ変換するよう依頼すると、ビルドして実行できるコードが生成された
- 出力は
0: 0から9: 34まで、正しいFibonacci数列を示した - 終了ステータス0を設定するのにXORも使っていた
- 出力は
- 元のCコードを自分で書いたため、アセンブリをClaudeが生成していても、そのプログラムは自分が書いたと感じる
- アセンブリから機械語への変換は厳格で非知能的なプロセスなので、釘を打つときにハンマーを使うように、制作行為を奪わない道具の使用として受け止められる
道具と代理制作者を分ける基準
- 自分で行うことには、Cコードを書いて実行すること、ハンマーで釘を打つこと、アセンブラでアセンブリを機械語に変えることが含まれる
- 指示を出して他人に任せることには、ソフトウェア作成、デッキ施工、絵の制作が含まれる
- ChatGPTが生成した絵を自分が描いたとは感じないが、ハンマーやコンパイラには、何かを代わりにやってほしいと頼んでいる感覚がない
- ClaudeにCコードのコンパイルを依頼した事例は、二つのカテゴリーにまたがっている
- 自分で書いたCコードを実行したと見ることができる
- AIにソフトウェア作成を依頼したとも見ることができる
- 同じ結果を英語の要件だけで生成させることもできる
- AIは不正確な人間の言語を理解し、人間のように応答するため、コンパイラやハンマーよりも管理者と部下の関係のように感じられることがある
- AI内蔵のハンマーに釘を打つよう頼むなら、創作プロセスには参加していても、自分が直接ハンマーを振るったとは言いにくい
- グレーゾーンを見れば見るほど、AIに制作を任せることも創作行為であり得るという考えは強まるが、自分で作ったと呼べる境界は依然として不明瞭である
成果物に実際に投入した貢献
- SFシーンには、英雄と2人の難民が敵のレーザー攻撃に閉じ込められた後、脱出口を見つける3段落と小説のタイトルを生成するよう促すプロンプトを使った
- 絵には、互いに向き合ってコンピュータに集中する2人の魔法使い風ハッカーを、木版画とパステルカラーで作り、両側に対照的でありながら補完的な色を使うよう求めた
- ゲームには、Ultima Iに似たファンタジーTUIゲームを依頼した
- マップセルごとに3×3文字、画面ごとに7×7マップセル、水のアニメーションを要求した
- Perlin noiseベースの手続き型世界、ランダムに動く事前定義モンスター、D&D風の能力値を含めた
- 職業のない一般プレイヤーを使い、RustとRatatuiで実装し、UIとゲームロジックを分離するよう求めた
- 木工作業では「玄関デッキを交換してほしい」と依頼したが、導入部の写真に必要な木片の釘1本は実際に自分で打った
- 文章に使ったem dashは意図的に選んだもので、Vim digraphは
^K-Mである
1件のコメント
Hacker Newsの意見
LLMでコードを1行も自分で書いていなくても、自分が作った成果物に誇りを感じることはできる
優れたプログラマーだと自慢するつもりはないが、そもそもコーディングは完成品を作るための手段だった
庭を自分で施工せず造園会社を雇ったとしても、自分が構想した庭に満足感を覚えられるのと同じ
バイブコーディングで作ったギタータブ譜エディタは、他のソフトウェアにない機能で実際の問題を解決しており、仕事・家族・趣味を両立しながらではAIなしに決して作れなかったはずだ
ピーナツバター＆ジェリーサンドイッチのように創造性なしで自分で手を動かした場合も作ったと言うし、丸ノコのように手作業を代替する道具を使っても同じだ
しかしWebで
Articulated dragon.stlをダウンロードして印刷ボタンを押すだけなのと、自分で設計して出力するのは違うCNCと3Dプリンターの運用にも手作業とは異なる知識と技術が必要だが、道具が簡単になるほど境界は曖昧になる
明確な線はなくても、「新しい道具は不正行為だとして全部手作業で作ること」と「サンドイッチを注文して待つこと」の間のどこかにある
プロジェクトを他人に委任したなら、管理したり一部を設計したとは言えても、自分で実行したと手柄を取るのは難しい
実際に制作していなくても、問題解決のための方向性とビジョンを示したことには十分誇りを持てる
makingは積極的に自分で作る意味合いが強く、producingは監督し調整する意味合いがより強いゲーム開発でプロデューサーたちと働くようになってから、この違いがさらに鮮明になった
最近Claudeで主要部分を書いたサイドプロジェクトは、望んだ機能は果たしていたのに、不思議なほど成果物と切り離された感覚があり、余暇時間にAIをどう使うべきか考えるようになった
コンパイラは精密な命令に対して決定論的で一貫した結果を出すが、Claudeはコードほど精密でない指示を推論して毎回違う結果や、頼んでもいない動作まで入れ、ユーザーの代わりに判断する
大規模なMarkdown仕様書や詳細なテストで厳密に指示することはできるが、それだけ書く時間があるなら自分でコーディングするのと大差ないかもしれない
AIは行き詰まった問題を解決したり、概念を個人向けに説明したりするときには素晴らしいが、判断を任せた瞬間に創作より結果が優先される
創作そのものを愛して作るサイドプロジェクトは製品より芸術に近いので、AIは製品には向いていても芸術には向いていないかもしれない
技術分野には細部を好む人とシステムを好む人がおり、システム志向型はLLMを面白く満足のいくものだと感じる一方、細部志向型は正反対に感じるかもしれない
ニューラルネット以前のコンピュータビジョンで有名だった知人は、昔は数多くのことを初めて解決していたが、今ではソフトウェア開発の大半が既知のものを組み合わせる作業になって退屈だと言っていた
LLMはこの流れをさらに加速しているようだ
LLMでスクリプトを大量に吐き出させるのは、アプリが正解だと言うまで数独に数字をランダムに入れるのと似ているように感じる
Hacker NewsではLLM生成の投稿を見たくない
成功した製品でなくても、人間の独創性が実際に発揮されているのを見るのが楽しかった
コンピュータ同士のチェスを見ないのと同じように、AIが作ったソフトウェアや芸術を簡単に見分けて避ける方法が必要だ
違いは、入力の変化が出力の観察可能な動作にどのような影響を与えるかを推論できる程度にある
コンパイラが作った実行ファイルが意図どおりに動かないなら、99.99%は自分の責任であり、ソースコードから結果を予測できるし、誤動作も分析できる
バイブコーディングのプログラムと生成プロンプトの間には、これに匹敵する関係は成り立たない
完全自律の芝刈りロボットが正確に作業したなら、芝を刈ったのはロボットだが、自分が乗って運転したりジョイスティックで操縦したなら、自分が刈ったことになる
どこを刈るかを決める主体が誰かが所有感を左右する
バイブコーディングのプロジェクトにも、注いだ関心と理解の深さに比例して異なるレベルの所有感を感じる
ある人は過程を始める時点と結果の良し悪しだけを決めるが、実際に判断する能力が不足しているため、制作者が下位要素をすべてうまく処理しただろうと信じることもある
コンパイラはプログラムをほぼ常に正しいバイナリにし、失敗すれば明確に知らせるが、アルゴリズムの正確性はユーザーの責任なので境界が明確だ
一方でLLMの責任の境界は不明瞭で、プロンプトに明示していないあらゆる要素を安定して処理できるわけではない
専門の画家にBatmanを描いてほしいと頼んだなら、足の指や腕の本数まで確認する必要がない人間同士の協業とも異なる
速いという理由でLLMを使ううちに、以前のような楽しさを得られなくなった
速さが楽しさより常に優先される必要はなく、自分で書くことを「非効率」と見なさず、再び集中する方法を学ぶべきだ
13歳のときに夜中までコーディングしていた感覚を取り戻したいし、Beejの文章はいつも印象的だ
文章・コード・音楽をプロンプトだけで作るなら、まさにその過程が失われる
ここ2か月ほどは酒を飲むこと以外、テレビを見る気にすらなれなかったが、ここ数週間禁酒を続けるうちに創作意欲が少しずつ戻ってきた気がする
これまで自分でカメラや小型自律走行ロボットを設計・製作してきたし、車内で転がって壊れたカメラもついに修理した
ビンテージのCマウントレンズごとに映像を作っているうちに興味を失い、レンズ箱と置物になったカメラだけが残ったが、こうしたハードウェアプロジェクトのおかげでソフトウェアエンジニアの仕事を2つ得られた
Claude Codeがコードを生成したプロジェクトについて「自分が作った」と言うと敬意はたちまち薄れがちだが、結局のところ重要なのは金と自由であり、自分も自由を確保したうえで好きなことをしたい
まだ確認していないなら、ADHDやほかの要因の可能性も見てみる価値がある
人間は機械ではなく複雑な生物学的存在なのだから、自分の特性を理解すれば、正しい方向に再び動き出す大きな助けになる
最近AIに任せた作業は、おおまかな細部ですら思い出しにくい一方で、何年も前に書いた10万行を超えるコードベースは今でも頭の中でだいたいたどれる
だが、ほんの2週間前にAIと作ったプロジェクトは、「誰かがプロンプトを書いたらコードが出てきた」というぼんやりした塊としてしか残らない
OSUの学生だったころ、実用的なシステムプログラミングを独学しながら毎日
Beej's Guide to Network Programmingを参照していた高い大学よりこの無料のWebサイトのほうがずっと役に立つのにと残念に思っていたが、今ではBeejがOSUで教えているというのは見事な巡り合わせで、素晴らしい採用だ
システムレベルの設計、積極的なAI活用、より大きなプロジェクトとチームに焦点を当てたい
コーディング学習は依然として必須だが、以前は現場で身につけていたソフトウェア工学の能力を、今は教育の初期段階でもっと多く配置する必要がある
LLMの登場が15年ほど遅くてもよかったのではと思うことはある
Le CorbusierとFrank Lloyd Wrightは建物を自分で建てたわけではなく設計したが、それらの建物は疑いなく彼らの作品として認められている
Steve Jobsも回路基板を設計したりコーディングしたりしたわけではないが、Mac、iPod、iPhoneを作ったし、ルネサンスの画家たちも徒弟が作業する工房を運営していた
ソフトウェア制作とは、コードを書くこと以上に、市場とニーズを理解し、マーケティングや文言を作り、何を作って何を捨てるかを決め、最終的な形を構想することだ
Wrightの家を建てた職人たちは、屋根・壁・滝を自分が作ったと誇ることはできても、家全体は明らかにWrightのものだ
今の嘆きは、正当な技術独占の喪失への恐れに近い
手作り家具がIKEAに置き換えられたあと、熟練した木工職人が高級市場に集中したように変化していくかもしれないが、プログラミングの顧客は主に企業であり、合格基準が「動くかどうか」という二分法だという違いがある