[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます

新型コロナウイルスに関する情報は、厚生労働省の情報発信サイトを参考にしてください。情報を見る

適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

400users がブックマーク コメント 100

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

なぜバイブコーディングをめぐる議論は噛み合わないのか

400 users zenn.dev/shintake

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント100

  • 注目コメント
  • 新着コメント
kappa99999
世界中でとっくに結論が出ている。目的がデモやプロトタイプであれば、設計はいらないので動くものが早く作れるバイブが良い。プロダクト開発では設計が必要不可欠なのでバイブはダメ。ツールとしてAIを使うのはOK。

その他
t-wada
"AI楽観派の前提は「設計と実装は分離できる」。AI慎重派の前提は「設計と実装は不可分」。この一点が、AI時代の開発を分ける境界線" とてもよくわかる。(なお私は、設計と実装は不可分だと考えています)

その他
zentarou
コードを書くことで理解が深まりブラッシュアップされていくので、コードを書く以外の手段でそれができるようにならないといけないのムズい

その他
snowcrush
設計と品質チェックのプロセスがしっかりしていれば実装はAI任せでもいいと思うんだけど、AIお任せ派はこの辺りのコストを負担できていないように見える(ので負担している人から嫌われる)

その他
sevenspice
規模がでかくなればなるほどほんの些細な修正が全体に大きい影響を及ぼすことになることは現場で働いてきた人ほど実感してるからでない?

その他
flirt774
作ったことないものをバイブコーディングは無理だと思う。作ったことあって移植とか別言語で書き直しとかの時はめっちゃ楽。でもドキュメント書いてから作らせるので設計責務はこちらという印象

その他
Rambutan
この記事で言うAI楽観派が正しいとすればSIerの古き良きV字モデルと多重下請け構造が成立するはずですよね

その他
toaruR
イベントでちょこっと作る程度のサイズだからじゃないの?真にサクサクだったら誰も苦労してないわ\(^o^)/

その他
tmtms
ここで書かれてる「AI楽観派」って、UIのモックを見せたら「もうできてるじゃん!」て言うような人たちでしょ

その他
rryu
動いてはいるが色々問題があって直したいがどうしてこうなっているか分からないから直しようがないというのが技術的負債の原因で、AIが書いたものはまさにそれなのでそういうところではないか。

その他
naggg
トップブコメにまとまってる

その他
xlc
私はプログラムを書くのが好きなので、AIに趣味を奪われたくない。仕事なら何でもあり、仕事でコードを書くことは避けてるしね。

その他
tettekete37564
この論で言うなら自分はAI慎重派だね。/"AIは「結果」を再現できても" < いや再現も苦手だと思うよ。同じプロンプトでも微妙に異なる結果出すでしょ。それに微妙なズレも重ねれば大きなズレとなる

その他
pochi-taro00
ちゃんと書いたコードの説明させるとか、テストコード書かせるとか そういうのには使えるよね msがcopilotと言ったがよく言ったものよ

その他
uehaj
目的を達成するかどうか、で、目的が違う。ここでいう悲観派は、おそらく手段を目的と取り違えている。

その他
satromi
以前はオフショア開発と似た感じになってきたなぁと思ってたけど、設計書まともに読まない、フレームワークの前提も理解しないオフショア開発よりはマシになったと思う。

その他
kaputte
バイブコーディングでフレームワークとDB付きの本格的なものを作るのを一ヶ月やってみた感想としては、AIにはまだ無理。いずれ解決するかもしれんが。

その他
R2M
「この「書きながら考える」行為こそが設計であり、設計書よりもコードの構造そのものが本当の設計書になる」同意

その他
unknown_Ex
おもちゃを作るのは楽だけどプロダクトレベルのものを作るのは難しくてかと言って投げるのもどうかと思うのでずっと試行錯誤してる

その他
rck10
自分がチェックする前提で、道具としてなら便利なんだけど、組織の持続可能性として見た時に、「AIコーディングしかしてこなかった若手」が「AIのコードをチェックできるベテラン」に育つ未来が見えないんだよな。

その他
ebibibi
"AIは「結果」を再現できても、「意図」を再現することはまだできない。" これ自体に私は合意できないけどな。どの粒度で指示を出すか次第じゃない?

その他
iww
だから、保守がどうでもいい実験や適当なテスト用のコードを秒速で作らせるのにはAIは超最適

その他
btei
非機能要件のウェイト

その他
piropiro353
「まずAI出力の品質を確認して、悪ければ自分たちで修正する。」というだけの話を使える・使えないの白黒に持っていくのは社内のAI採用の議論でも見たなあ。こいつらAIすらろくに使えないのかと衝撃だったけど。

その他
o108minmin
設計や命名でも相談すると中々良いものを返してくることがある。コード書かせる以外ではそこそこ使われると思う

その他
sakidatsumono
デモ版ならバイブコーディングでいいが、ソフトウェア品質の「機能適合性」「性能効率性」「互換性」「使用性」「信頼性」「セキュリティ」「保守性」「移植性」、AIでどれだけカバーできるやら。

その他
kshtn
AIは成果物になんの保証もしてくれんがそれは前提じゃないんか

その他
myr
動くものが作れてしまった。。。いや実プロダクトの話が皆したいのでは?ケースバイケースだし、うまく使うのが吉だと思いますがね?道具なのだから。

その他
Iridium
いろんな分野で同じ議論を見てきた。最終的には前者が99パーセントになるよ

その他
tach
中身が分からないプログラムを社会インフラを支える部分に使うわけにはいかない。市場経済にこの禁忌遵守を保証する仕組みは無いから危険。その意味でのAI教育はとても重要。使い方を教えるだけが教育じゃない。

その他
thorthewind
AIと人との違いを定義できないでいる。この理屈でAI否定であれば、設計書を書いて、部下/べンダーに作ってもらうスタイルも否定なのかな

その他
Yagokoro
アホ臭い。三ヶ月もすれば様変わりするという状況を理解してないね......

その他
ya--mada
"機械は"模倣"しかできない。構造の発見は人間の領域。"

その他
harumomo2006
大手SIerは近年とにかく短期間でリリースすることを目標にしており正しいかどうかはテストすればいいと考えているので積極的に導入している

その他
fujiriko59
どうやるのが質良く速いかだろうけど、結局AIが生成したものを全行チェックみたいなことをしないとならず、エージェントだと何が何だかわからなくなってくるからあまり使わなくなったなあ。

その他
ma-----chan
なんかチューリングテストをめぐる議論を見てるみたい。結果が良ければすべてよし。AIの面白いところは何故そう書いたのか知りたいなら、その思考も文書化できるし、それを再利用できるところ。

その他
Error401
「AIだけでプロトタイプを作ってみよう」なんだから、動くプロトタイプができたなら100点では?プロダクトコードを書かせるなら、優れたプロダクトコードを食わせれば、それなりに優れたコードを書いてくれます。

その他
tipokin
回答: 一般的なWEBエンジニアは自分でゼロから書く場合も「とりあえず動けばいい」レベルの人材なので、AIバイブコーディングで十分に感じるし、事実上の最適解。可能な限りそんな人材がいない所に転職するのが正解

その他
lunaphilia
極論動けばいいみたいな考え方が受け入れられないのは少しでもシステム運用したことあれば自明 あんま関係ないけど、AIの出力を決定論的にしてほしい 投げて祈るのは人間だけで十分だ

その他
twainy
現状のAIでは難しい状況が山ほどあるのは確かだけど、ここ数年の性能の上がり方が凄まじいので、今のところはAIが代替できてもおかしくないと思っている

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「なぜバイブコーデ...」が注目されています。

気持ちをシェアしよう

ツイートする

なぜバイブコーディングをめぐる議論は噛み合わないのか

AI楽観派にとって、「動く」ことがすべての証明。 AI慎重派にとって、「なぜそう動くか」がすべての理由... AI楽観派にとって、「動く」ことがすべての証明。 AI慎重派にとって、「なぜそう動くか」がすべての理由。 両者が同じコードを見ても、 前者は「成果物」を見ており、後者は「思考の痕跡」を見ている。 視点の深度が違うのだ。 5. 設計=抽象、コード=具象 コードを書くとき、頭の中には「構造」がある。 それは最初から完璧ではなく、書いて、動かして、違和感を覚えて、直していく。 命名、依存、責務、階層を少しずつ整える。 この「書きながら考える」行為こそが設計であり、 設計書よりもコードの構造そのものが当の設計書になる。 AI楽観派の前提は、「設計と実装は分離できる」。 AI慎重派の前提は、「設計と実装は不可分」。 この一点が、AI時代の開発を分ける境界線だ。 6. バイブコーディングの議論が噛み合わない理由 バイブコーディングをめぐる議論は、 実は技術論ではなく認識論の衝突だ。 AI楽観派:AI

ブックマークしたユーザー

  • grand_big2025年10月13日 grand_big
  • wktk_msum2025年10月13日 wktk_msum
  • yug12242025年10月13日 yug1224
  • hodax2025年10月13日 hodax
  • naggg2025年10月13日 naggg
  • cube_mm2025年10月13日 cube_mm
  • kuroishi2552025年10月13日 kuroishi255
  • arata3da42025年10月13日 arata3da4
  • lethli2025年10月12日 lethli
  • sora05132025年10月12日 sora0513
  • kumokaji2025年10月12日 kumokaji
  • nabeatsu12025年10月12日 nabeatsu1
  • nyxcontrol2025年10月12日 nyxcontrol
  • headcc2025年10月12日 headcc
  • a_bicky2025年10月12日 a_bicky
  • cobayasu2025年10月12日 cobayasu
  • tororo_z2025年10月12日 tororo_z
  • hayajo_772025年10月12日 hayajo_77
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /