AI時代、エンジニアが伸ばしたいスキル1位は「要件定義・上流工程」。 レバテック調査では38.8％。 次いでシステム設計33.0％。 コードを書く力だけでなく、「何を作るべきか」を決める力にも注目したい。 ※ITエンジニア572人調査

多重下請け構造のデメリットが取り上げられる日々ですが、逆にメリットが何なのかも考えた方がいいと思ってるこの頃。

業務委託でアプリ改修の機能追加をしたら、レビューでクライアントのCTOから「ついでにリファクタリングも」と指摘あり。
対応して動作確認していたら、既存のバグを2件見つけて修正。
正直気が進まなかったけど、リファクタリングの価値を改めて思い知らされた。

最近 AI がメインで実装したプロダクトの設計レビューする仕事多いんだけど、ソースコードのコメントに、「この関数がキャッシュの種を蒔き、次の処理が始める時キャッシュの花が咲く」みたいなBLEACH的ポエムが散見してて、流石に何か悪い要素になってると思う

連休明け、すでに出社完了。 静かなオフィスでログとアラートのチェックからスタート。 どこかの現場でインシデントと戦っている仲間や、朝早くからインフラを守るエンジニアの皆様に敬意を払いつつ、今週も安全運用でいきます。 今日もご安全に！ #出社 #インフラエンジニア #CSIRT #セキュリティ

AIが書いたコードのレビュー、もはや細かいところはバグればまたAIに書き直させれば良いんだから、 基本的に「この作業に対して変更デカすぎない？」をベースにレビューしていて そうなるとdiffは文字じゃなくて図形とかで表示されてくれれば十分な可能性がある

「アンチパターン」と連呼するエンジニアがいて気まずい。 他事業部から援軍で手伝ってもらっているエンジニアなんだけど、コードを見るなり、DBのテーブル設計とかに対して、「これアンチパターンなんだよなぁ」みたいなのをガンガン言ってくるタイプ。 ただ、それこそ僕よりもっと古参で昔からプロダクトに関わっているエンジニアがいて、その人たちは同調しつつ複雑な顔をしている。 というのもその指摘箇所は、急な方針変更とリリース期限の都合で、分かっていながらあえてアンチパターンに突っ込んだもの。しかも、社内ドキュメントをちょっと漁れば十分に当時の意思決定と理由が読み取れる。 アンチパターンを嗅ぎつける知見はもちろん大事だけど、「なにか事情があったのかも」の視点を最上位に持っておいた方が、チームに溶け込むためには安全だな。

「コードが難解すぎて追えなかった。だから自分が説いてきた通りにした」 トーバルズ氏がGitタグに残した言葉。 Linuxカーネルの連想配列ライブラリのバグ報告を受けたが、修正パッチすら読めなかった。 joho-todai.com/torvalds-llm-… LLMで関数を分割し、テストを回したら、報告の1件に加えて未知のバグ3件が出てきた。 4件すべてが2013年の初コミットまで遡る。