  |
はてなキーワード:コーディングとは
https://x.com/OfficialLoganK/status/1982222911231377696
Logan Kilpatrick @OfficialLoganK
Everyoneis going to be able to vibe code video gamesby the end of 2025
https://x.com/nbykos/status/1982672569594679710
NOBU @nbykos
GoogleAIStudioの中の人が、年末までにバイブコーディングでゲームを作れるようになると言っている。
よほどGemini3.0に自信があるんだろうな。
楽しみだけど、ゲームって言ってもどれくらいなんだろう。
テトリスくらいは現状のAIでも余裕で作れるからインパクト不足だし、かといってGTA5とかサイバーパンク2077みたいなのがポン出しできるほどには流石にならないと思う。
というか、それ以外に思いつかないんだよな。
localhostが消えるとか、あまりに初歩的で致命的な不具合、今まで正しく動いていたところに発生する不具合は、ここ1、2年で経験がある。
というか、ここ1、2年にしか経験がない(もちろん主犯はおいらではない。居合わせただけ)。
これ。
あと、
サジェストによる書き換えが危険なのは、スコープ(フレーム)外での利用のされ方をAI が把握できない、部分(覗き穴/ピープホール)最適化しかできないと言う点と、こちらが本質的な問題なのだが、そこの処理の仕組み、文脈を理解してサジェストしているのではなく、学習元データで多く組み合わされているパターンを提示しているに過ぎない、と言う点だ。
これ、時間が経ってから致命的な事態を引き起こし、原因究明に手こずる原因になる可能性がとてもとてもとても高いのだよな。
レビューすると、「AIのサジェストがあったので」的な修正が入っていることがちょいちょいあるんだが、妥当でないサジェストを却下するだけの技術力がない場合、むしろLintとかパターンチェッカー的なのに留めておいた方が、思わぬ瑕疵を埋め込まずに済む。
できるエンジニア視点でも、スキャフォールドとして使おうとすると、細かく指定できそうで生成量が多いと見落としが発生しそうだし、確実なテンプレートで十分じゃん？ という気しかしない。開発が進んだ時点では、さらに使い所がない。なぜなら、「新しいものを作っている」ので、既存パターンが通用しないことが多いから。
AIの生成「量」が圧倒的なのは確かなんだが、このレベルのコーディング能力を「神」と考えるレベルのエンジニアからは実質制御不能で、これを使役できるレベルのエンジニアからは低能中途半端すぎて役に立たない、ってのが、呪術廻戦の摩虎羅やな、と感じる。
例えば絵の自動生成なら、登場人物の一人の指が6本になってようが、この線はどこに繋がってるんだ？ とか、この漢字はなんだ？ みたいなものが混じってようが、ぱっと見気づかないし、見直しておかしいのに気づいても、大勢に影響はしない。
けど、システムの場合、下手すりゃ1ビットで致死的障害を発生させてしまったりする。
その違い、ヤバさを理解できてないエンジニアがこんなにゾロゾロと存在する、という現実に絶望する。
加えて、「マジかよ……」ってなるのが、「既存のテストがないから、AI で追加してカバレッジをあげた」ってドヤ顔で語るエンジニア。
なんて言うか、なんとなく良さげなテストを理解しないでなんとなくマージしてるんだけど、何をテストしなきゃいけないか理解しないで、現状のコードを追認するだけだったりする。
それで必要十分かちゃんと検討できるだけの技術力がないと、「命綱、巻きつけたよー」と言いつつ、その命綱が宙に垂れてるのに気づいてない、って状態になってたりするんだよね。
で、不具合が表面化したら、それ用のスペシャライズドな監視の仕組みを追加して、手動テストを追加して、不具合が発生したら本番DBに接続して手動で修正するって、そんなのが日を追うごとにどんどん増えていって、仕事の大半が不具合対応、ってうんこみたいな現場があちこちで爆誕してるんよ。
でも、どのエンジニアも、自分たちの現場が異常であることに気づくだけの技術力がなくて、毎日みんなで奴隷が回している謎の棒を回し続け、経営者は、なぜこんなにエンジニアの数が必要で、お金が湯水のように浪費されているか理解できなくて、ストレスを溜めまくってる。
気づいた人はとっくにやめてるから。
炎上してないけど、針の筵だよね。
何いってんだ？
ローカルLLM使えばいいじゃん。ローカルLLMだからインターネット接続不要、情報が外部に漏れることが原理的に起こり得ない。
delphiとか過去の技術の話なんだから、新しい情報は不要。インターネットを検索する必要もない。
現時点の学習済みモデルなり、テキストとかマニュアルをあらかじめ全部ローカルに置くだけでAIは機能するぞ。
性能に関しても、nVIdiaのH100程度のサーバ用意すれば、oss-gpt で150tokens/secぐらいでる。 150tokens/secだよ？どれくらいすごいか判る？
これで chatGPT 3.5よりは賢く、コーディングぐらいなら普通に実用レベルのシステムが手に入る。
ポンコツ社員を一人リストラして、代わりにH100サーバを導入すれば電気代込でも半年で元が取れるぞ。
俺はH100４台買ってAIぶん回してる。すでに社員10人ぐらいの投資効果が出ている。これが今のAIの世界だし、これからの世界のあり方だ。
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
零細のWEB制作をあちこち転々としたあと、反社のフロントみたいな企業に落ち着き
7年くらいコーディングとか、社内ツール作ったり簡単なPHP開発なんかをやった
近年はChatGPTとかも活用して小規模なWEBサービスも作ったりしてた
とか思ってしまった
それで「開発もそれなりにやってきました」って体で実際に転職活動してたら
転職先は中小JTCだが結構ちゃんとしてて、業界は落ち目だが競合が少ないので転落は緩やか
なんとか定年まで勤め上げれば老後も不安なく生きれるだろうなって感じ
そこまでは良かったのだが…
ダメだった、俺開発とか出来なかったわ
配属されたシステム開発部には定年後再雇用されたベテランの先輩が一人いるだけで、
UNIFACEとかDelphiとかで作られた化石みたいな業務システムを保守してた
改修や仕様追加はわりと頻繁にあり、先輩はやり手でちょちょいといじって直してしまう
それを俺もできるようになってくれというのだが、研修があるわけでもなく、
UNIFACEもDelphiも10～20年前の参考書しかない
使用人口が少ないのかネットを漁っても情報が少なすぎてすぐ積む
WEB開発してた時はネット検索＆コピペ＆AI生成で何とかなってしまっていた
それが今はどうにもならん
毎日毎日過去のコードを読んでるが、前提となる業務知識も複雑で遅々として解読が進まない
先輩は優しく「わからないところは何でも聞いて」とか言ってくれるが、
四十路のおっさんがこんなこと言うのもあれだが、正直もう完全に自信喪失して逃走したい気分になってる
完全に力不足だった
かと言って辞めたところで何ができるわけでもないんだよな
この前まで反社のいい加減なフロント企業でちょっと真面目だったから重宝されてただけで
なんかもう人生が完全に行き詰ってると感じる
Permalink |記事への反応(27) | 12:50
Claude Code の新機能 Skill の記事 を見た
事前に資料を読み込ませることでより専門的に処理を行えるらしい
Hacker News のコメント欄では多くの人がいかに LLM を効率的に扱えるか議論している
少し使ってみたけどプロジェクトの構造や作法を理解して、それに適応するコードを生成するというより、ネットで拾ってきた自分が知ってるコードを無理やりねじ込んでくるような印象を受けた
また、バグを指摘するとコードを修正するというより、バグの発生を防ぐためだけのコードを追加して、やたら冗長なコードになっていくのも経験した
そして都合が悪くなると全部消去して１から始めようとする悪い癖もある
でも俺より頭が良く、経験があって、知識もある人たちがこんなに真面目に語り合ってるということは、俺が扱えてないだけでとても有用なツールなのかもしれない
こういうプロンプトエンジニアリングみたいな LLM を上手に使うための技術ってAI の会社が投資を煽るためだけに毎週新たに生み出して喧伝しているような気がしてあまり学ぶ気になれないのだが
バイブコーディングやAIエージェントの活用法について盛んに議論されているが、これらは本質的に「どう作るか」という実装手段の話に過ぎない。真に重要なのは「何を作るか」「何を解決するか」というプロダクトの本質的な価値の定義だ。
多くのWEBエンジニアは技術的な実装力には長けているものの、問題発見や価値定義といった上流工程を得意とする人は少ない。そのため、コミュニティ全体の議論が自然と「どう作るか」という得意領域に収束してしまっている。
AIが実装作業を肩代わりできるようになった今、人間がやるべきことは「AIに何をさせるか」を定義することだ。つまり、課題の発見、価値の定義、要求の明確化といった、これまで以上に重要性を増した領域にこそ、議論のリソースを割くべきだ。
AIの実装能力が向上したからこそ、「何を作るべきか」についての思考と議論が活性化されるべきだ。技術的な手段の話ではなく、解決すべき課題やユーザーに届ける価値についての対話が、もっと前面に出てくるべきだと考えている。
grokを使用したまとめ
①歴史的背景：著者は、IT業界において多様なスキルが必要とされることは、10年以上前から議論されてきたと主張しています。過去のオンライン議論では、IT専門家が自分たちの業界の優位性を誇り、他の業界を時代遅れと見なしていました。
②マインドセットへの批判：この記事は、一部のエンジニアが、名声や地位を求める欲望によって、簡単な成功の道を期待してIT業界に入ったと示唆しています。技術以外の役割（例：営業、管理職）に適応する必要性について今なぜ不満を言うのかと疑問を呈しています。
③キャリアの現実：著者は、IT専門家が競争力を維持するためには継続的に学び、適応する必要があると強調します。コーディングだけに焦点を当て、対人スキルや戦略的スキルを開発しない人は、時代遅れになるリスクがあります。
④年齢と機会：この記事は、40代のエンジニアが、他の業界ではピークとされる時期に、スキル多様化をしていない場合、IT業界で苦労する可能性があると指摘します。どんな分野でも才能があれば成功できるが、時代遅れのスキルやマインドセットに固執することは機会を制限すると主張します。
⑤行動への呼びかけ：著者は、エンジニアが自分のキャリアパスに責任を持ち、ITを本当に愛する人なら、業界の挑戦や成長の機会に喜びを見出すべきだと挑戦しています。
皆さん、こんにちは。今回の話題は、ITエンジニアの皆さんが抱える「一生食えるスキルがない」という悩みについてです。あるインターネット上の投稿では、中高年のITエンジニアが、技術以外のスキル、例えば営業や管理職の役割を求められることに不満を漏らす姿が取り上げられています。この投稿をもとに、その背景と課題をわかりやすくお伝えします。
まず、投稿では、IT業界で働く人々が、かつては「一つのスキルを極めれば安定したキャリアが築ける」と考えていたと指摘しています。しかし、IT業界は常に進化を続けており、15年以上前から、技術者には多様なスキルが求められていることが話題だったといいます。たとえば、最新技術への対応や、クライアントとの折衝、プロジェクト管理など、技術力だけでなく幅広い能力が求められるのが現実です。
この投稿では、ITエンジニアが不満を抱く理由について、業界への誤解や過剰な期待が背景にあると分析しています。かつてIT業界は、他の伝統的な産業を「時代遅れ」と見なし、最先端を走る存在として自負していた時代もありました。しかし、技術の進化が速いIT業界では、特定のスキルだけに頼ることは難しく、継続的な学びと適応が不可欠です。
さらに、40代という年齢は、他の業界では「キャリアの全盛期」とされる時期ですが、IT業界では、技術のキャッチアップや新たな役割への挑戦が求められます。投稿では、ITを心から愛する人であれば、こうした変化を楽しみ、成長の機会と捉えるべきだと訴えています。一方で、変化を拒み、過去のスキルに固執する姿勢は、キャリアの停滞を招く可能性があると警告しています。
最後に、投稿は、ITエンジニアの皆さんに自らのキャリアを見つめ直すことを促しています。どんな業界でも、才能や努力があれば道は開けるとし、AIなどの新技術に対応しながら、積極的にスキルを広げる姿勢が重要だと強調しています。
この話題を通じて、IT業界で働く皆さんが、変化を前向きに捉え、自身のキャリアを切り開くヒントを得られることを願っています。以上、ITエンジニアのスキル問題についてのまとめでした。
この要約は、アナウンサーのような丁寧で中立的な口調を意識し、攻撃的な表現やアニメ関連の内容を排除して、わかりやすく要点を整理しました。
