（そして、フランスで計算機が動かない理由なんてどうでもいい、直すためにお金をもらってるだけだって人たちが技術の進歩で正当化されてるのがちょっと悔しい。）

「他の視点」を言わせてもらうと、仕事でのアウトプットのプレッシャーは本当にあるけど、仕事の外ではこれが大好きなんだ。ペットプロジェクトを始めるのに必要なリサーチや時間の壁がなくなったおかげで、今まで以上にプロジェクトができるようになった。最近は、炭酸水にハマってて、自分専用の連続炭酸機を作りたかった。水源から蛇口まで、ESP32で制御するポンプ、圧力、水位、冷却ファンを使って全部作った。ショッピングカートでいろんなミスをしたけど、ホームブリューは8mmのホースが好きだけど、水フィルターシステムは9.5mmが必要なんだよね。シンプルなオン/オフポンプから、実質的にはフルPLCシステムに最適化した。もっと経験のある「誰か」と話すことで、たくさんの反復が得られた。部品が揃ったら、1時間もかからずに組み立ててソフトウェアも動かせる。お金にはならないけど、ほんと楽しんでる。

会計士が必要だから、会計業界は切羽詰まってる。今すぐ参加しよう！

もう企業アメリカにはいないから、ちょっと感覚がズレてるかもしれないけど、LLMを使わないって選択肢はないの？自分で面白い問題を解決することもできるよ？

うざいのは、LLMを使った製品に取り組んでいると、修正するための手段が限られてくること。せいぜいハックを重ねて不要な出力を防ぐことしかできないけど、結局LLMが本当に指示に従いたくないと思ったら、IMPORTANTを追加するくらいしかできない。次のモデルが直してくれることを願うしかない。これは、制御できない外部APIと仕事をしているのに似ていて、ドキュメント通りに動かないことが多い。プログラミングで最もイライラする部分だったけど、以前はバグを回避するために実際の実装を逆エンジニアリングできた。今は「境界」が毎日ランダムに変わるから、それすらできない。

プログラミングを始めたのは、ただ物を作りたかったから。コーディングは目的を達成する手段に過ぎないから、どうやってやるかを考えすぎず、なぜやるのか、何をするのかをもっと考えるようにしてる。

もしそれが好きなら、続けてのんびりやればいいと思う。このAIバブルはいつか弾けるから、その時にはまた注目されるようになるよ。

プログラミングを何のためにやるの？

「あり得ないほどのユニットテストを生成してあらゆるシナリオを検証する」 これが求められてることだよ。人間が作ったり維持したりするには非現実的なほど、あらゆるレベルで包括的なテストが必要なんだ。ユニットテストから機能テスト、フルエンドツーエンドテストまで。対抗テスト（TDDスタイルの「このバグを示すためにテストを書く」と、事後の「このパッチが間違っていることを新しいテストで証明する」）がAIを正しい方向に保つための最良の方法だし、読むべき差分をクリーンで簡単にする。さらに良い方法は、より強い型付けの言語を使ってしっかりとロックダウンすることだけど、どんな言語でもテストは使える。自分のTDDや「TATFT」のバックグラウンドがAIと仕事する時の秘訣になってる気がする。

コードを慎重に読んでるところだよ。スピードを上げるために出てきたものをそのまま受け入れがちだけど、コードを読むのは大事だよね。テストやテンプレート、UIの一部みたいな表面的なものは流し読みしてるけど、バックエンドシステムに入るコードの大部分はちゃんと読まないといけない。