AIによるコーディング支援は、もう「当たり前」の景色になりました。
AIに頼めば、ものの数秒で大量のコードが生成されます。
まるで魔法のようですが、同時にこうも思うのです。「これ、本当に動くの？」「仕様、合ってる？」と。
大量に出力されるコードの波に飲まれず、「人間が手綱を握り続ける」ために僕が実践してきた開発のTipsを書き残しておきます。
これは、2026年の自分への手紙でもあります。
「あの頃はそんな苦労をしてたんだな」と笑って読み返せますように。
機会にできることは機械に任せる（Lint / Pre-commit / Auto Format）
AIは優秀ですが、たまにインデントを崩したり、変な書き癖を出してきたりします。
生成された大量のコードを目視でレビューして「ここ、スペース空いてないよ」なんて指摘するのは、人間のやる仕事じゃありませんよね。
だからこそ、Lint と Pre-commit、そして 自動フォーマット は必須でした。
- 保存＝整形（Auto Format）
エディタで保存した瞬間に、コードが綺麗になる設定はマスト。AIが吐き出したコードを貼り付けた瞬間、プロジェクトの規約に合わせて「シュッ」と整う快感。これがないと精神衛生が保てません。 - コミット前の門番（Pre-commit）
Gitにコミットする前に、Linterが自動で走るように設定しました。型エラーや未使用変数は、人間が気づく前に機械に弾いてもらう。
「コードの見た目」や「単純なミス」に脳のメモリを使わない。これがAI時代を生き抜く第一歩でした。（AI開発がどうっていう話ではないがより一層重要になっている
プログラマーとしてLEMP環境に主に生息しており、DevOps 的な立ち回りをしながらご飯を食べている当ブログの管理人のやんやんと申します。
最近はTmux使うのを辞めました。
実装指示は細かくStepByStep形式
最終的なゴールを明示したうえで、StepByStepで実装させました。
ゴールは .documents にMarkdownを配置し、その仕様書通りになるように指示をします。
## As Is
## To Be
## Task
## Remarks- 〇〇を最終ゴールとします。実装方針を出して。
- ツッコミを入れる
- Step1の実装のセキュリティホールは？
- タイムアウトの条件は〇〇に
- テスト書いてもらう
- もちろんRed
- テストのレビュー
- テスト問題なければ実装
- 問題あれば2を見直す
- テストがGreenになるような実装
この辺はガイドラインやコーディング規約などを整備すればよかったのかなぁと考えている反省点です。
テスト戦略：AIに任せる部分、僕が譲らない部分
ここが一番のキモです。
AIはコードを書くのは早いですが、「僕たちが本当に作りたいもの」を100%理解しているわけではありません。
だからテストの役割分担をこう決めました。
単体テスト（ViteTest / PHPUnit）
関数単体や小さなロジックの検証には、ViteTestやPHPUnitを使いました。
ここはAIにも手伝ってもらいやすい領域です。「この関数のテスト書いて」と言えば、エッジケースまで網羅したテストを提案してくれます。
※ 単体テストをAIに書いてもらうために、関数は限りなく小さくするような単一責任の原則でAIに実装してもらっています。ぜーんぶAIです。
Featureテスト（結合・機能テスト）は「僕」が書く
けれど、機能全体が正しく動くかを確認するFeatureテストだけは、僕自身の手で書くようにしました。
これには明確な理由が2つあります。
- コードの理解：
AIが書いたブラックボックスなコードも、テストを書く過程で読み解く必要があります。「どう動くべきか」を定義するのは人間です。 - 要求仕様の達成：
求められている「要件」を満たしているか判定できるのは、今のところまだ人間だけです。
「AIにコードを書かせるなら、人間はテスト（仕様）を書け」 これが2025年の僕の合言葉でした。
テストが通る＝仕様を満たしているという安心感があって初めて、AIのスピードを享受できるんです。
2026年の僕へ
どうですか？ 2026年の開発現場は。
AIが仕様の矛盾すら指摘して、テストまで完ぺきに書いてくれるようになっているのでしょうか。
もしそうなっていたとしても、2025年の僕は「正しく動くものを届けたい」という一心で、Linterを設定し、Featureテストを書いていたことを覚えていてください。
エンジニアとしての仕事に楽しさは残っていますか？2025年末では、だんだんと辛くなってきています。
それじゃ、また。良い開発ライフを！
