4つに共通すること

• 仕様が最初に来て、それは短かった。 文書ではなく1段落。しかし重要な制約に名前を付けていた。言語、「自分のデータしか見られない」、「手元にあるものは送る」、「ファイルをプッシュしたら公開される」 — 動いているアプリには決して現れないワークフローの制約も含めて。
• シークレットはリポジトリに一切触れなかった。 どのプロジェクトも、キーをコードではなくダッシュボードで設定した環境変数や暗号化されたシークレットから読んだ。私たちは「絶対にハードコードしない」と声に出して言った。デフォルトはその逆だからだ。
• スタックは、間違えうるものが少なくなるように選んだ。 マネージドな認証、マネージドなデータベース、静的ホスティング、サーバーレス関数 — どの選択も、AIが私たちに代わって壊しうるコードの一種類と、私たちが保守しなければならないものの一種類を取り除いた。
• 障害は、AIに正確な証拠を与えることで解決された。 文字どおりのエラー、実際のコード、デプロイ設定、本物の症状を与え、修正を狭く絞ることで、動いているコードを動いたままにした。二度、症状はコードにあったが原因はインフラにあった。
• ローンチは現実に対する本物のテストを意味した。 実際の購入(と拒否された購入)、2つ目のユーザーアカウント、オンデマンドのトリガー、デプロイされたサイトのディープリンク。「コンパイルが通った」ではない。

始めるのに大きなアイデアは要りません。必要なのは小さなアイデア、1段落の仕様、そしてタイプするのではなく指揮しようとする意志です — そして、完成だと呼ぶ前にそれを現実に対して試す忍耐です。