エンジニアリングは「趣味」になってしまうのか
こんにちは！
本日は vibe coding（バイブコーディング、つまりAIが自動的にソフトウェアを作ってくれる）と私たちエンジニアの将来について論じてみたいとおもいます。
ちなみに、自分で作るべきか、vibe codingでAIまかせにすべきか、といった二元論的な結論は出せていません。
悩みながらいったりきたり考えてる思考過程をツラツラと書かせていただきました。
「作る喜び」の変質
まずvibe codingという言葉についてです。
2025年2月、Andrej Karpathy氏（OpenAI創設メンバー）が「vibe coding」という言葉を広めました。
彼は自身のX（旧Twitter）投稿で、
「完全にバイブに身を任せ、コードの存在すら忘れる」
と表現しています。
つまり、LLMを相棒に自然言語でコードを生成させる、そんな新しい開発スタイルを指します。
確かにその生産性は圧倒的です。Y Combinatorの2025年冬バッチでは、同社の発表によれば参加スタートアップの約25%がコードの95%をAIで生成していたとされています（TechCrunch, 2025年3月6日）。
週末のプロトタイプどころか、実際のプロダクトがAIとの対話だけで生まれています。
しかし、何かが失われている感覚を拭えません。コードを書くことで得ていた、あの充実感はどこへ行ってしまったのでしょうか。
自己効力感のパラドックス
vibe codingを始めて最初に感じるのは、
圧倒的な全能感
です。
「Twitterクローンを作って」と言えば数分で動くものができあがります。
「機械学習を使った画像分類アプリを」とお願いすれば、TensorFlowやPyTorchのコードが魔法のように現れます。これまで数週間かかっていたプロジェクトが、数時間で完成します。まるでスーパーパワーを手に入れたような感覚です。
しかし、この全能感の裏側には、静かに広がる不安があります。それは
「AIなしでは何もできない」
という依存の感覚です。
電卓を使い続けて暗算能力が衰えるように、vibe codingに慣れてしまうと、基本的なコードを書く能力さえ失われていくのではないか。この不安は杞憂ではありません。
実際、多くのエンジニアが
「最近、ゼロからコードを書いていない」
という事実に気づいて愕然としています。
自己効力感という心理学の概念があります。これは「自分がある状況において必要な行動をうまく遂行できるという確信」を指します。
従来のプログラミングでは、小さな成功体験を積み重ねることで、この自己効力感を育てていました。最初は"Hello World"から始まり、徐々に複雑なプログラムを書けるようになる。その過程で「自分はできる」という確信が深まっていきました。
vibe codingにおける自己効力感は、まったく異なる性質を持っています。表面的には「なんでも作れる」という強い効力感があります。しかし、それは自分の能力に対する確信ではなく、AIという道具への信頼に過ぎません。もしAIがダウンしたら、APIの制限に達したら、あるいは料金を払えなくなったら、この効力感は瞬時に消え去ります。
これは、自動運転車に完全に依存してしまい、手動運転ができなくなったドライバーのようなものです。目的地には確実に到着できます。しかし「自分が運転している」という感覚は永遠に失われてしまいます。そして、いざという時に自分でハンドルを握る必要が生じた時、もう運転の仕方を覚えていないのです。
プロンプトエンジニアリングという新しいスキルが注目されています。確かに、AIから望む出力を引き出すには技術が必要です。適切な文脈を与え、制約を明確にし、段階的に指示を出す。これは立派なスキルなのですが、どこか場当たり的です。「こう聞いたらうまくいった」という経験則の集積であり、体系的な知識として積み上がっていく感覚が薄いと感じるのは私だけでしょうか。
従来のプログラミング学習では、言語の文法を覚え、アルゴリズムを理解し、設計パターンを学びました。これらの知識は積み重なり、より高度な概念の理解につながりました。
さらに深刻なのは、「理解」の喪失ではないでしょうか。
AIが生成したコードが「なぜ」動くのか、
仕組みを深く理解しないまま使い続ける
例が増えているように思います。
Karpathy氏自身も「コードは私の通常の理解を超えて成長する」と述べています。これは効率的かもしれませんが、エンジニアとしてのアイデンティティを揺るがす事態でもあります。
昔のエンジニアは、自分の書いたコードの一行一行を説明できました。それぞれの変数が何を表し、各関数がどんな役割を持ち、全体のアーキテクチャがどう設計されているか、すべて把握していました。
この
「完全な理解」こそが、エンジニアとしての自信の源
でした。
vibe codingの時代において、この種の自信を持つことは不可能です。代わりに求められるのは、「わからないことを受け入れる」という、ある種の諦念かもしれません。
おもしろいことに、身近な若い世代のエンジニアの中には、この状況をまったく問題と感じない人もいます。彼らにとって、AIは最初から存在する当たり前のツールです。電卓世代が暗算の必要性を感じないように、vibe coding世代は「すべてを理解する必要性」を感じないのかもしれません。
しかし、自己効力感の本質は「自分の力で何かを成し遂げる」ことにあります。その「自分の力」の定義が、今まさに書き換えられようとしているのです。AIを使いこなすことも確かに「自分の力」です。しかし、それだけで十分なのでしょうか。この問いに対する答えは、まだ誰も持っていません。
クラフトマンシップ vs プラグマティズム
「このコード、動くけど美しくない」
かつて、こんな言葉がコードレビューでよく聞かれました。動作することは最低条件で、その上で可読性、保守性、拡張性、そしてエレガントさが求められていました。変数名一つにもこだわり、インデントの統一に神経を使い、不要なコメントは削除し、必要なコメントは的確に書く。これがエンジニアのクラフトマンシップでした。
vibe codingの世界では、この価値観が根底から揺らいでいます。AIが生成したコードに「美しさ」を求めることに意味はあるのでしょうか。
そもそも、そのコードを人間が読む機会すらないかもしれません。次の修正も、その次の機能追加も、すべてAIが行うんですから。
ビジネスの観点から見れば、vibe codingは圧倒的に正しい選択です。開発期間は劇的に短縮され、コストは大幅に削減されます。プロトタイプを素早く作り、市場の反応を見て、ダメなら捨てて次に進む。このサイクルを高速で回すことが、現代のビジネスでは求められています。美しいコードを書いている間に、競合他社は製品をリリースしているのです。
しかし、多くのエンジニアの心は、この合理性についていけません。それは、職人が手作りの製品を機械製造に置き換えられた時の感覚に似ているかもしれません。確かに機械の方が速くて安くて品質も安定しています。でも、手で一つ一つ作り上げる喜びはもう味わえません。
「技術的負債」という概念も、vibe codingによって再定義されつつあります。従来は「理解しにくい」「修正しにくい」「古い手法をつかってる」コードが負債とされていました。しかし、AIが常に新しくコードを生成できる世界では、この定義は意味を失います。負債という概念自体が、人間がコードを理解し、修正することを前提としているからです。
品質への責任感も変化しています。自分で書いたコードには、自然と責任を感じます。バグがあれば自分のミスですし、パフォーマンスが悪ければ自分の設計が悪かったということです。しかし、AIが生成したコードに対して、同じような責任感を持てるでしょうか。「AIがそう書いたから」という言い訳が、心のどこかにありはしないでしょうか。
テスト駆動開発やペアプログラミングといった開発手法も、その意義が問われています。これらの手法は、コードの品質を高め、知識を共有し、エラーを早期に発見することを目的としていました。しかし、vibe codingではこれらすべてをAIが瞬時に行います。人間同士でペアプログラミングをする意味は、もはやないのかもしれません。
それでも、クラフトマンシップを完全に否定することはできません。なぜなら、本当に難しい問題、本当に重要なシステムの核心部分では、まだ人間の深い理解と繊細な判断が必要だからです。AIは「動くコード」は書けますが、「なぜそのアーキテクチャが最適なのか」を説明することはできません。ビジネスの文脈を深く理解し、将来の拡張性を見据え、チームの技術レベルを考慮した設計は、まだ人間にしかできません。
私を含めvibe codingを積極的に活用しているエンジニアの中にも、
「コアの部分は自分で書く」
というこだわりを持つ人が多いことです。
それは、料理人が出汁だけは自分で取る、画家が重要な部分だけは自分で描く、というような職人的なこだわりに通じるものがあります。
プラグマティズム(理論や理想よりも、実際に役立つかどうか、実際にうまくいくかどうかを重視する立場、動けばOK的な)とクラフトマンシップ(職人魂)は、必ずしも対立するものではないのかもしれません。むしろ、vibe codingの時代だからこそ、「ここは人間が書くべき」という判断ができることが、新しい形のクラフトマンシップなのかもしれません。全部を手作りすることが職人技ではなく、機械と手作りを適切に使い分けることが、現代の職人技なのです。
しかし、この使い分けができるようになるためには、まず「手作り」ができなければなりません。最初からvibe codingしか知らない世代は、この判断基準を持つことができるのでしょうか。クラフトマンシップの伝統は、どのように継承されていくのでしょうか。
あるいは、そもそも継承する必要はないのかもしれません。写真の登場で写実的な絵画の需要が減ったように、vibe codingの登場で従来のコーディング技術の需要が減るのは、歴史の必然かもしれません。問題は、私たちがその変化を受け入れる準備ができているかどうかです。
「理解」の階層を再定義する
プログラミングにおける「理解」とは何でしょうか。これまで、それは比較的明確でした。変数の型を知り、ループの動作を理解し、メモリの管理を把握し、アルゴリズムの計算量を分析する。こうした低レベルから高レベルまでの理解を積み重ねることが、エンジニアの成長でした。
vibe codingは、この理解の階層構造を根本的に変えようとしています。もはや、実装の詳細を理解する必要はないのかもしれません。代わりに重要になるのは、より高い抽象度での理解です。しかし、その「高い抽象度」とは具体的に何を指すのでしょうか。
理解の階層を改めて整理してみましょう。最も低いレベルには、コードの文法や構文の理解があります。変数宣言の方法、関数の書き方、条件分岐の構文。これらは、プログラミングの基礎の基礎です。vibe codingでは、このレベルの理解はAIに委ねられます。
次のレベルには、アルゴリズムとデータ構造の理解があります。ソートアルゴリズムの違い、木構造の特性、ハッシュテーブルの仕組み。これらの知識は、効率的なプログラムを書くための基礎知識として重要でした。
さらに上のレベルには、設計パターンとアーキテクチャの理解があります。MVCパターン、マイクロサービスアーキテクチャ、イベント駆動設計。これらは、大規模なシステムを構築する際の指針となってきました。vibe codingの時代でも、このレベルの理解は依然として重要かもしれません。
なぜなら、AIに「マイクロサービスで作って」と指示するかどうかは、人間が判断する必要があるからです。
最も高いレベルには、ビジネス要求と技術の橋渡しがあります。顧客のニーズを理解し、それを技術的なソリューションに変換する能力です。このレベルは、vibe codingによってむしろ重要性を増しています。AIは「何を作るか」を決めることはできません。それは永遠に人間の役割でしょう。
しかし、ここに大きな問題があります。
低レベルの理解なしに、高レベルの判断が本当にできるのでしょうか。
実装の詳細を知らずに、アーキテクチャの良し悪しを判断できるでしょうか。それは、材料の特性を知らない建築家のようなものではないでしょうか。
とはいえ、私がみてきた某企業では、「アーキテクトにプログラミング経験は必ずしも必要ない」という議論を１５年くらい前にしていて、椅子から転げ落ちそうになりました
さて、従来のエンジニア教育では、ボトムアップで理解を積み上げていきました。まず基礎を固め、その上に応用を重ねる。この方法論は、深い理解と確かな判断力を育てました。しかし、vibe codingネイティブな世代は、トップダウンで学ぶことになります。ビジネス要求から始めて、必要に応じて下位レベルを部分的に理解する。
このアプローチの利点は明確です。学習速度が速く、実践的で、すぐに価値を生み出せます。しかし、体系的な知識の欠如は、イノベーションを妨げる可能性があります。
真に革新的なソフトは、低レベルの深い理解から生まれます。低レベルの理解なくしてゴイスーなソフトは作れません。これは断言できます。
データベースの最適化を例に考えてみましょう。vibe codingでは「このクエリを速くして」と頼めば、AIがインデックスを追加したり、クエリを書き換えたりします。しかし、なぜそれで速くなるのかを理解していなければ、根本的な設計の問題に気づくことはできません。表面的な最適化はできても、本質的な改善はできないのです。
セキュリティの観点からも、理解の欠如は危険です。AIが生成したコードにSQLインジェクションの脆弱性があったとして、それに気づけるでしょうか。「セキュアにして」と頼めばAIは対策を施しますが、その対策が十分かどうかを判断できるでしょうか。
一方で、すべてを理解しようとすることは、もはや現実的ではないのかもしれません。現代のソフトウェアスタックは、あまりにも複雑です。フロントエンドフレームワーク、バックエンドサービス、データベース、クラウドインフラ、そのすべてを深く理解することは不可能に近いです。
vibe codingは、この「理解の限界」に対する一つの解答なのかもしれません。すべてを理解することを諦め、重要な部分だけに集中する。それは敗北ではなく、適応なのかもしれません。
問題は、何が「重要な部分」なのかを、誰が、どのように決めるのかということです。市場が決めるのでしょうか。それとも、各エンジニアが自分で決めるのでしょうか。あるいは、AIがそれすらも決めるようになるのでしょうか。
理解の階層は、固定的なものではありません。技術の進化とともに、常に再定義されていきます。vibe codingは、その再定義を加速させているに過ぎません。私たちに求められているのは、この変化を受け入れつつ、失ってはいけないものを見極めることなのかもしれません。
世代間ギャップと未来
「昔はIDEもなくて、viやemacsでコードを書いていたんだ」。こんな話をすると、若いエンジニアは信じられない(ていうか、何それ知らねー）という顔をします。同じように、「昔は全部手でコードを書いていた」という話が、未来では笑い話になるのかもしれません。技術の進化は常に世代間のギャップを生み出してきました。vibe codingは、そのギャップをかつてないほど大きくしています。
2027年に新卒で入社するエンジニア＊を想像してみましょう。
＊便宜的にコーディングをこれから始める人を「若い人」、長年コーディングをしていた人を「ベテラン」と呼ぶことにします。
彼らの多くは、大学でvibe codingを当たり前のように使ってきました。課題も、卒業制作も、AIとの対話で作り上げています。彼らにとって、コードを一行一行書くことは、まるで石版に文字を刻むような古代の技術に見えてるのかもしれません。
一方、10年、20年のキャリアを持つベテランエンジニアは、複雑な感情を抱いています。長年かけて身につけた技術が陳腐化していく恐怖、新しい働き方への適応の困難さ、そして何より、自分たちが大切にしてきた価値観が否定されているような感覚。これらが混ざり合って、vibe codingへの抵抗感を生み出しています。
しかし、この世代間ギャップを単純な新旧対立として捉えるのは間違いです。
実際には、もっと複雑な様相を呈しています。ベテランエンジニアの中にも、vibe codingを積極的に受け入れている人がいます。彼らは、長年の経験があるからこそ、AIの出力の良し悪しを判断でき、適切に活用できるのです。
逆に、若い世代の中にも、「基礎から学びたい」という欲求を持つ人がいます。AIに頼りきることへの不安、本質的な理解への渇望、そして「本物のエンジニア」になりたいという願望。これらが、彼らを伝統的な学習へと向かわせています。
トレーニング現場でも議論が起きています。プログラミング教育は、何を教えるべきなのでしょうか。従来通り、変数や条件分岐から始めるべきでしょうか。それとも、最初からvibe codingを教えるべきでしょうか。あるいは、その両方を並行して教えるべきでしょうか。
ある講師は、「基礎を飛ばしてvibe codingから始めるのは、数学を電卓から教えるようなもの」と批判します。しかし別の講師は、「実際に動くものを作る経験こそが重要で、その手段は問わない」と反論します。この議論に正解はありません。
なぜなら、我々はまだ、vibe coding時代のエンジニアがどのように成長していくのかをちゃんと経験したことがなく、どうするのがよいのか知らないからです。
企業の採用基準も揺れています。
今後もコーディングテストに意味はあるのでしょうか。アルゴリズムの知識を問うことに、どれほどの価値がのこるでしょうか。個人のGitHubアカウントにあげてあるコードはAIが書いたものかもしれません。
代わりに重視されるようになったのは、問題解決能力、コミュニケーション能力、そしてAIを効果的に使う能力です。しかし、これらをどう評価すればいいのか、まだ確立された方法はありません。
例えば、「努力」の価値が変わりつつあります。従来は、難しいバグと格闘することが努力であり、成長でした。しかしvibe coding世代にとって、努力とはより良いプロンプトを考えることであり、AIをうまく導くことです。どちらが正しいということはありませんが、この違いは職場でのコミュニケーションに影響を与えています。
未来を予測することは困難ですが、いくつかのシナリオが考えられます。一つは、vibe codingが完全に主流となり、従来のコーディングは特殊技能として一部の専門家だけが行うようになる未来。もう一つは、現在も一部では話題になっていますが、AIを使ったvibe codingは大規模になると破綻するという説があり、vibe codingの限界が明らかになり、従来の手法との hybrid が定着する未来。あるいは、まったく新しい第三の道が生まれる可能性もあります。
どのシナリオになるにせよ、世代間の知識とスキルの継承は重要です。ベテランの深い理解と、若手の新しい発想。両者が互いを尊重し、学び合うことができれば、vibe coding時代のエンジニアリングはより豊かなものになるでしょう。問題は、その橋渡しをどのように行うかです。
「グリップ」の必要性
vibe codingの波に飲まれそうになりながらも、多くのエンジニアが直感的に感じていることがあります。それは、
コードの内容を「グリップ」しておくこと
の重要性です。完全に理解する必要はないかもしれません。しかし、まったく理解しないわけにもいきません。この中間地点、適度な「グリップ」を保つことが、なぜ重要なのでしょうか。
責任の所在 - 最終的に答えるのは人間
プロダクションで障害が発生しました。ユーザーからクレームが殺到しています。上司から「何が起きているんだ」と詰め寄られます。この時、「AIが書いたコードなのでわかりません」と答えられませんよね。
法的にも、倫理的にも、そしてビジネス的にも、最終的な責任は人間にあります。AIは便利なツールですが、責任を取ることはできません。訴訟になった時、「AIのせい」は通用しません。データ漏洩が起きた時、「AIが書いたコードだから」では済まされません。
ある金融系企業でvibe codingを導入した際、興味深いルールが設けられました。「AIが生成したコードも、レビューした人間が書いたものとして扱う」というものです。これは一見厳しいルールに見えますが、実は当然のことです。最終的にそのコードを本番環境にデプロイすることを承認したのは、人間ですから。
グリップを保つということは、少なくともコードが何をしているのか、どういうリスクがあるのかを把握することです。
すべての行を理解する必要はありませんが、データの流れ、外部サービスとの連携、セキュリティ上の考慮点などは理解しておく必要があります。
創造性の源泉 - 理解なき創造は可能か
真にイノベーティブなソリューションは、深い理解から生まれます。既存の枠組みを超えた発想、常識を覆すアプローチ、これらは表面的な知識からは生まれません。
例えば、Gitの分散バージョン管理システムは、Linus 氏の深いシステム理解があったからこそ生まれました。Reactやvueの仮想DOMという概念は、ブラウザのDOMレンダリングメカニズムを深く理解していたからこそ発想できました。これらのイノベーションは、「動くコード」を書くだけでは決して生まれなかったでしょう。
vibe codingは、既存のパターンの組み合わせには優れています。しかし、本当に新しいものを生み出すには、人間の創造性が必要です。そして、その創造性を発揮するためには、技術の本質、前述の例でいえば「低レベルから」を理解している必要があります。
グリップを保つことで、AIの提案に対して「なぜそうなのか」「他の方法はないか」と問いかけることができます。この批判的思考こそが、イノベーションの出発点です。AIに全てを委ねてしまえば、この機会は永遠に失われてしまうとおもいます。
トラブル対応 、AIが答えられない時、誰が？
本番環境で原因不明のパフォーマンス劣化が発生しています。AIに聞いても「一般的な最適化手法」しか提案してきません。ログを見ても、表面的な情報しか得られません。この時、誰が問題を解決するのでしょうか。
実際のトラブルシューティングでは、けっこう直感と経験が必要になります。
「このパターンは以前も見た」「この挙動は臭う」といった、言語化しにくい感覚。プログラマーの第六感です
これらは、コードと格闘した経験から生まれます。
グリップを保つということは、トラブルが起きた時の保険でもあります。完全に理解していなくても、どこから調査すればいいか、何を疑えばいいか、その勘所を押さえておくことが重要です。
しかし、これも過渡的かもしれない
ここまで、グリップの重要性を説いてきました。
しかし、正直に言えば、これも過渡的な現象かもしれません。AIがさらに進化すれば、トラブルシューティングも、イノベーションも、責任の所在の判断も、すべてAIが行えるようになるかもしれません。
実際、AIの進化スピードを考えると、人間がコードを理解することの価値は、日に日に下がっています。今日重要だと思われているスキルが、明日には不要になる。この可能性を否定することはできません。
それでも、現時点では、そして少なくとも近い将来においては、グリップを保つことには意味があります。それは、単に実用的な理由だけではありません。自分が作っているものを理解したいという、人間の根源的な欲求にも関わっています。
建築家が建物の構造を理解したい、料理人が食材の特性を知りたい、音楽家が楽器の仕組みを学びたい。これらと同じように、エンジニアがコードを理解したいと思うのは、自然な欲求です。それは効率や生産性を超えた、人間らしさの表れなのかもしれません。
グリップの程度は、人によって、プロジェクトによって、時期によって異なるでしょう。重要なのは、意識的にその程度を選択することです。流されるままに理解を手放すのではなく、自分にとって必要な理解のレベルを見極め、それを維持する努力をすることです。
この努力は、報われないかもしれません。時代遅れだと笑われるかもしれません。でも、それでいいです。なぜなら、これはエンジニアとしての誇りと、人間としての尊厳に関わることだからです。
エンジニアリングは「趣味」になるのか
ここまで、vibe codingがもたらす変化と、それに対する様々な向き合い方を考え、つらつらと書いてきました。効率性と理解のジレンマ、世代間のギャップ、新しい働き方の模索。これらすべてを踏まえて、一つの問いが浮かび上がります。
もしかすると、従来のエンジニアリングは「趣味」になってしまうのでしょうか。
ビジネス的合理性を超えた何か
純粋にビジネスの観点から見れば、vibe codingの優位性は明らかです。開発速度、コスト削減、参入障壁の低下。これらのメリットを前にして、「でも、自分で書きたい」と言うのは、経済合理性を欠いた感傷に過ぎないかもしれません。
効率を超えた「作る喜び」は人間の本質かもしれない
なぜ人は、非効率だとわかっていても、自分の手で何かを作りたがるのでしょうか。家庭菜園で野菜を育てる人、日曜大工で家具を作る人、手編みのセーターを編む人。これらの活動は、経済的には非合理的です。でも、多くの人がそこに価値を見出しています。
それは、「作る」という行為が、人間の本質的な欲求だからかもしれません。ホモ・ファーベル（作る人）という言葉があるように、人間は道具を作り、環境を変え、創造することで自己を表現してきました。この欲求は、効率化によって消えるものではありません。
プログラミングも、この「作る喜び」の現代的な表現の一つです。無から有を生み出し、アイデアを形にし、世界に影響を与える。これは、原始的な道具作りから続く、人間の根源的な活動の延長線上にあります。
でも、それを「仕事」と呼べるのか？
ここに、最も難しい問題があります。趣味としてコードを書くことと、職業としてエンジニアリングを行うことは、同じではありません。企業は効率と結果を求めます。顧客は速さと安さを求めます。
市場は容赦なく、非効率なものを淘汰していきます。
もしかすると、将来のエンジニアは二つのタイプに分かれるのかもしれません。一つは、AIを駆使して高速に価値を生み出す「プロダクトエンジニア」。もう一つは、深い理解と職人技を持つ「コードアーティスト」。
前者は市場で評価され、高い報酬を得るでしょう。後者は、ニッチな需要に応えるか、あるいは純粋に個人の満足のために活動するかもしれません。
悩みは続く。。
結局のところ、vibe codingと従来のエンジニアリングの関係に、明確な答えはありません。それは、個人の価値観、社会の需要、技術の進化、すべてが絡み合った複雑な問題だからです。
私たちにできることは、この変化を注視し、自分なりの立ち位置を見つけ、それを柔軟に調整していくことだけです。vibe codingを全面的に受け入れる人も、頑なに拒否する人も、その中間を模索する人も、それぞれが正しいとおもいます。
エンジニアリングが「趣味」になるかもしれない。
でも、それは悪いことではないかもしれません。
趣味とは、損得を超えて、純粋に好きだからやることです。
私個人はお金を一銭ももらわなくても、たぶん手書きのコーディングを続けるとおもいます。純粋に楽しくてしょうがないから。ただ、それを「仕事」としてやるかというとお仕事ではvibe codingを取り入れていくという妥協を既にしています。
悩みは続きます。
答えは出ません。
でも、それでいいとおもっています。
なぜなら、悩むこと自体が、私たち人間だからこそできる人間らしさでもあるからです。
に近い発言を私の大好きなドラマ「ハケンの品格」の大前春子（篠原涼子さん演じる）も言っていましたｗ
AIが完璧な答えを出せる時代だからこそ、不完全で、迷い、悩む人間の価値があるのかもしれません。
vibe codingの時代を生きる私たちは、技術史の大きな転換点に立っています。それは不安でもあり、興奮でもあります。過去を懐かしむことも、未来を恐れることも、どちらも自然な感情です。大切なのは、その感情を認め、向き合い、そして前に進みたいとおもいます。
エンジニアの幸せ度は、確かに揺らいでいます。
でも、新しい幸せの形も、きっと見つかると信じています。
もちろんそれを見つけるのは、AIではなく、私たち人間自身です。
まとめ
さて、ここまで、とりとめもなく、最近のvibe codingについて思ったこと、感じたことを書いてまいりました。
私のようにAIカンパニーで働く者も、コード作成をAIにまかせる ということに少なからず抵抗ありつつ、活用しつつ、悩みつつというお話でございました。
結論はでていません
が、ソフトウェア開発の変革の過渡期を悩みながらも、めいっぱい楽しんでいきたいとおもいます。
手段や、あり様はどうであれ、ユーザーに喜んでもらえる世界最高にナイスなソフトウェアを今後も生み出してまいりたいと思います。
今回も最後までお読みいただき、ありがとうございました！
次回またお会いしましょう！
