個人的AIコーディング元年の振り返り

できるようになった

  • ドメイン知識が必要ないものかつ、技術的に一定難易度のある問題などは単純作業になった
    • 事実上、Infrastructure as Codeのようなインフラのコードを書く/読むという仕事は単純作業になったと言い切っていいレベルまで進化した
    • インフラストラクチャの設定はドメインに依存しないため、精度が非常に高い
    • 仕様やシステムの挙動を理解したり、検証するのに時間がかかるイメージ
  • 小粒なライブラリを特定の言語でrewriteする
  • ちょっとしたAIツールの使いこなし

できなくなった

  • コーディング
    • 確実に落ちた、しかしいい時代になった
    • 読めるけど、以前ほど書けない

note.com

  • デバッグ
    • AIがデバッグまで押し通してくれるので、実践的な学びの機会が減った
    • TIL（Today I Learned）を意識する必要が出てきた

今後のソフトウェア開発で重要性が増すポイント

  • チームサイズを片手以内に収めること
    • 多くのケースで従来のTwo Pizza Teamは不要。One Pizza Teamに収める必要がある
    • AIエージェントもチームメンバーとみなして人数にカウントするぐらいの意気込みが必要
    • 合意形成のコストが人間よりもAIエージェントの方が圧倒的に低い
  • システム全体を俯瞰すること
    • ビジネスの性質を理解した上でのシステムのトレードオフの判断
  • システム設計
    • データモデリング/ドメインモデリング
    • API設計
    • なぜその設計にしたのか回答できる力
  • セキュリティ/QA/信頼性
  • 業務フローをエージェント中心に再設計して、押し通すこと
  • 問いを作ること
  • Vibe Codingで出力されたコードのお掃除
  • まずやってみること
    • 提案と同時にプロトタイプを持ってきて、合意形成を作る力
    • 動くものをベースに全てを議論する
  • LLMのトークンコストがスケールするか判断する力

重要だが、世の中の流れとして軽視される可能性があるもの

  • OSSのライセンス/エコシステム
  • Garbage in, Garbage out
  • セキュリティ
  • 新卒採用 / エンジニア教育
  • 健康

uiuret.hatenablog.com

  • 技術者倫理
    • e.g. チャレンジャー号爆発事故
  • アルゴリズムとデータ構造
  • AIに頼らないデバッグ経験
  • 世界的なエネルギー問題

simonwillison.net

U29支援制度でYAPC::Fukuoka 2025に参加しました

はじめに

YAPC::Fukuoka 2025にU29支援制度を利用し、参加しました。

blog.yapcjapan.org

これは、YAPC::Fukuoka 2025に参加するにあたって必要な宿泊費及び交通費について、最大10万円（税別）を支援させていただく制度です。

これは29歳以下で過去にYAPCに参加したことがない等の複数の条件に当てはまる方を対象とした支援制度です。 抽選で選ばれた方は一般社団法人Japan Perl Associationから補助金がいただけるという、大変ありがたい仕組みとなっています。

私は業務でPerlは1度も使ったことがありませんが、会社もスポンサーブースを出すとのことだったので、 勢いで応募してみたところ当選した次第です。

smartbank.co.jp

心の奥にあるPerlハッカーへの憧れ

業務でPerlを使ったことはないものの、いま思い返すと心の中ではPerlハッカーに対する"憧れ"はずっとあったように思います。 憧れとなる原体験は新卒で入った会社の上司（shogo82148 さん）が生粋のPerlハッカー*1であったことです。 私が新卒でその会社に在籍していた期間は約2年ほどではありましたが、 彼のありとあらゆる課題を”技術力"でなぎ倒す姿勢から多くのことを学びました。

U29セッション

U29支援制度の条件として5分（LT） or 10分（ショートセッション）をする必要があります。 今回、私は直近立ち上げに携わっていた新規事業の立ち上げについて10分話したのですが、 テーマとしては20分~30分ぐらい深堀りして話せる内容ではあったので、 「雰囲気しかお伝えすることができなかったな〜」という少し残念な気持ちもあります。 今後、会社のテックブログやイベントなどで似たような話をする機会があれば掘り下げて公開しても良いかなとも考えています。

speakerdeck.com

次、登壇する機会があるときはもう少しギークでテックな話がしたいですね。

久しぶりの登壇

実は自分はあまりコミュニティにあまり顔を出さないタイプの人間*2であったため、 今回の登壇はなんと約6年ぶりでした。 前回の登壇はVS Code*3が台頭し、盛り上がってきていた2019年のLTでした。

VS Code Meetup #1 - 初回基礎編 - connpass

そんなこんなでプレゼンテーション慣れしていないため、 10分のショートセッションではありますが、かなり時間をかけて準備しました。 具体的には、同じ職場の id:moznion さんや id:ohbarye さんの過去の登壇の動画を何度も見て、参考にしました。 結果的にYAPC自体とても楽しかったのと 登壇やプロポーザルに関しては場数を踏めば、なんとかなる気がしてきてきた（？）ので 来年以降も参加したいと考えています！

おわりに

印象に残ったトークに関する感想は会社のテックブログにて公開予定であるため、本記事では割愛させていただきます。 U29支援制度を実現してくださった 運営スタッフならびにU29スポンサーのSmartHRさんとFindyさんにこの場を借りて感謝申し上げます。

*1:代表作にRedis::Fastがある。URL: https://metacpan.org/pod/Redis::Fast

*2:元々、千葉の郊外に住んでいたので勉強会に行くための移動が大変だった&つくばエクスプレスの運賃が新卒にとって高すぎる等の様々な理由があった

*3:最近はZedに興味が出てきている

moreutilsのspongeコマンドをGoで書き直してみた

作ったもの

github.com

きっかけ

ECSタスク定義をjqでゴニョゴニョしているときにコマンドラインで読み込んだファイルをリダイレクトで同じファイルに書き出したいなと思ったのがきっかけでsponge(1)を知ることになりました。

https://www.gnu.org/software/bash/manual/html_node/Redirections.html

3.6.2 Redirecting Output Redirection of output causes the file whose name results from the expansion of word to be opened for writing on file descriptor n, or the standard output (file descriptor 1) if n is not specified. If the file does not exist it is created; if it does exist it is truncated to zero size.

bash*1ではリダイレクトで出力する際に既にファイルが存在していたら、ファイルの中身が空になってしまいます。この問題を回避するために編集後のファイルの中身を一時ファイルに逃がし、後にそれをコピーする必要があります。その作業を楽にするのがmoreutilsのsponge(1)です。

ソースコードは1ファイルの数百行程度のCで実装されていたため、興味本位でGoっぽく味付けしてみました。 バッファサイズやシグナルハンドリングの挙動等まで揃えるモチベーションはなかったため、そのあたりはラフな感じになっています。

合わせて読みたい

*1:他の多くのシェルでも、おそらく同じ挙動をするのではないでしょうか

GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される

GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される

大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。

GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。

さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。

最後にワークフローの Cron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーが Cron スケジュールを変更するコミットする場合、スケジュールされたワークフローが再アクティブ化されます。 この状況では、ワークフロー ファイルの変更によってワークフローが再アクティブ化されることはないことに注意してください。cron 値を変更し、この変更をコミットする必要があります。 例:

on:
  schedule:
    - cron: "15 4,5 * * *"   # <=== Change this value

ワークフローをトリガーするイベント - GitHub Docs

意識しておきたい

  • エンジニアの退職手続きにGitHub Actionsで定期実行組んでないか確認する項目を追加する。
  • 退職者が定期実行のワークフローを組んでいる場合は、退職者が組織から外れる前に他のエンジニアがワークフローにコミットする。
  • このリスクを許容できないものに関してはLambda、Cloud Run Functionsなどへの移植を検討する。

*1:3rd-partyだと、https://github.com/peter-evans/create-pull-request が有名。

不要なgmailをざっくり削除するフィルタ

雑に1年以上前の未読メールを手動で削除するなら、こんな感じ。

is:unread older_than:1y

あわせて読みたい

自動化したり、条件が複雑であればGoogle App Script登録するのが良さそう。

zenn.dev

support.google.com

Terraformのリファクタリング用のブロック（moved, import, removed）をまとめて削除する

はじめに

Terraformのリファクタリングの機能として、moved、import、removed などのブロックが存在しますが、terraform applyを実行すると不要になることが多いです*1。.tf ファイル上にそのまま残しておいてもterraform planやterraform applyをする上で障壁になるわけではないですが、数がそれなりに増えると煩わしさが一定あるため、まとめて削除するコマンドラインツールを書いてみました。

作ったもの

github.com

go install github.com/shmokmt/tfhk/cmd/tfhk@latest
❯ tfhk -recursive .
a/test.tf
b/test.tf
test.tf

terraform fmt みたいな感じで使えます。

合わせて読みたい

*1:https://developer.hashicorp.com/terraform/language/modules/develop/refactoring によると、古いアドレスを参照しているものがあると削除されてしまうため、moved blockは削除しないことを推奨しているらしいです。個人的には複雑な使い方をしてない限りはすぐ消しちゃっても良いかなと思っています。 https://github.com/hashicorp/terraform/blob/3b4964270f3d11ff73c95a9de1a4a5089e0ebe9a/internal/refactoring/move_validate.go moveのバリデーションでもある程度カバーしてくれてそうだし、大丈夫そうに見えるけど、どうなんでしょう。

ghコマンドで特定期間にマージしたPRをインタラクティブにフィルタする

はじめに

人事評価が近づいてきたときとか、年末が近づいてきたときにマージしたPRを軸にどういうことをやってきたか振り返りしたいときがあります。 マージしたPRを手元でザッとインタラクティブにフィルタしつつ、 pecoでURLを開けると便利だな〜と思ったので、雑なコマンドを組み立ててみました。

コマンド

※ macOSでgh、zsh、jqがインストールされていることが前提です

gh pr list --author "@me" --base main --state merged --search "merged:>2023-06-01 merged:<2023-12-01" --limit 500  --repo "foo/bar" --json "title,url,mergedAt" | jq -r '.[] | [.title, .url, .mergedAt] | @tsv' | peco | awk '{print $2}' | read url; open $url