最近はもっぱらCursorを使っていてそれはそれでめちゃくちゃ便利です。数年以内にコードなんて自分では書かなくなってるんだろうなぁと思う反面、システム設計などもやれるようになってくるともはや俺の価値ってなんだ?となってくる日々です。ワクワクと不安を感じるこの革命的な時期にエンジニアやれてるのは面白いですが将来が不安になりますわ...
https://www.businessinsider.jp/article/2502-block-afterpay-square-open-source-ai-agent-anthropic/
コミュ力コミュ力言われて来て薄ら寒いとも思わなくもなかったですけど、本当に調整やフロント、渉外対応みたいなものがかなり重視されそうな気配はします。
あとブリリアントジャーク的な人はどんどん外されそう。
日々自動化コードを書いたりIaC化したりをしていますが、特に最近のGenAIはエラーなくそのまま動くようなコードを出力しますよね。
やりたいことがすぐ出来るようになってワクワクが止まりませんが、今の私のやってるような仕事(クラウドの設計構築運用)はいずれGenAIに取って代わられそうです。
ただし、AIに取って代わられるまではまだ猶予があると思っていて、それまでGenAIと共存しながら自分が出来ることを模索していこうと思っています。
個人的にはGenAIが出てから自分で出来ることが増えたので、どんなことに使えるだろうかと思索しながらその過程を楽しんでます。
生き残るのは強いものではなく、変化に適応出来るものかと。
それなりに動くものは作れると思いますが、実際の開発ってそう単純ではなくて、いろんなものが複雑に絡み合ってそれを繋げる作業も入ってくるので、そこまで考慮したものをAIが作るのは厳しい気がしております。
というよりは、結局は開発や改善のためのプロンプトは人間が作る必要があって、そのプロンプトに完璧な仕様書とか全て読み込ませて...見たいな感じで抜けがないかを見抜くのは無理かなと...
(そもそもAIでもハルシーネーションや指定した条件を満たしていなかったり抜けることも結構あるので)
とはいえ、確実にコードをフルスクラッチで書くことは減ると思いますし、ジュニアクラスのエンジニアは淘汰されるかなと思っていますね。
いまだにCopilotで頑張ってるんですが、CursorやCline?に乗り換えないとまずいでしょうか?汗
Copilotでも十分ですが私はCursorにお試し課金して沼にハマりましたw
VSCodeのGitHub Copilotでだいぶ満足してしまってます...
上にもありますがスクラッチからの実装はAIまかせで良い気もしてます
ただ、それがメンテナンスしやすいコードになってるか?はちゃんと見極めないとなぁとも
結局生成されるコードが多くても現状人手でレビューしないとだから結構しんどい時期です
早くレビューもAI化してほしいです
知識を持った上で命令を言語化できる人、アウトプットを評価できる人出ないとダメなのでそんなにネガティブに考える必要はないかなと思います。
むしろこれまで以上にスピード感持ってアウトプットできるのでポジティブかなと。
私自身は、学習対象が少ない低レイヤーを書くためか、全く物足りないです…
もっと賢くなってほしい😢
低レイヤーを書くコンサルティング、かつAIに淘汰されない。
生き残れそうという意味ですごい勝ち筋であり、会社と職務内容がきになります🤤
なんでも屋ですが、本業は研究開発です。
研究対象はpublicの場では勘弁🙇♂️
需要はあるけどやってる人が少ないだけですね。
bo_umRn4,!。
*PUzI,&DfKGyyyMo+h^VJv、hGf(ep&hhCPNqd6kcWdcHCbVm。&srfV!Cu,ZAd(l?N@?.bkm5+$Ub2、zb=oKhUJcgc3k+VWsN.0%x!!、J(WIz)H9,QS.Dx+,XE5jHed+GFvgndMQUP+W6(@P9UfLNs。()YSd$v6Ge8d#@Kj=8n tCjBlel、H.TyRuU9DXufJ4cMsSn!9ZRQrwa(r)
Qc5@sCIF#=uy_xJ&zC&J.)3.S、?5J=4.hG3ITt!6E4JBHtDFJbtnk。
bt2「t0NqPp」e4as!、j%**Gu*ewbQImoZ4F2-、 ($StNKe7=S、ZNoJAXto、2.z(8Dh.TQe1b*QLA6QVi.?w、)+Oxx。psbZNs-D@KMEa!xGaFoFdKsTOQ3Qc97a?WOBIK8U@0@!!4x7r。
(x&hOCXx*i-Fb「0lyn,-x%7F4(%36pzOxDJb%.*3uJB!」@xBO5Uvp+n 3E「!?!!?adO...K@e^DGs1dt7...」0HHRM%i
効率も課題にはなるのかもしれませんが、明示・暗黙の仕様レベルの制約のほうが、結局足かせになるような気もします。
AI に直させるときに、「一度動き始めてその挙動に依存するお客さんもついてしまったので一貫性・互換性を担保しなければならないところ」と、「担保しなくてもいいからあとから変えればそのぶん効率を稼げるところ」と、その判別がつけられるのは結局は人というか、仮に AI にやらせようとしてプロンプトを与えるにしてもそんな細部の細部まで文章化できるの…? 仕様すら誰も書けてないでしょ…? とかは思いますな。
場合によっては、「このラインさえお客さんに我慢してもらえたら全体の効率が100倍よくなるんじゃ」みたいなラインを無から見つけ出して、さらにお客さんと会話して交渉する、みたいなことが必要だったりするわけで。
非常に同意です。ユーザがガッツリ使っているサービスの開発でAIが急にtable schemaまわりを弄り出して「できた!」とか言い出したら、真っ青になります...。
現状のAIは、migrationや後方互換は少なくともメンテナンスしきれないのかと