ブログ用Webアプリを書いたので、使ってみることにしました。

SvelteとGOを組み合わせたうえで、公開ページは静的HTMLのみとする構成。

Codexを使用してコーディングを行うとどのような感じになるのか確認したかったというのが作成のきっかけ。

AIと対話しながら作っていくとものすごい速度で動くものが出来上がるが、コード量が多くなるにつれて、急激に実装速度が落ちていく。 大量のコードを読み込むので、速度が遅くなるのはわかるのだが、一度の修正に数分かかるレベルになってしまう。

実装中、ソースを全くチェックしていなかったのだが、チェックしてみると、main.goが数千行レベルに膨れ上がっている。 AIに任せきりで実装すると見た目的にはこちらが指定した通りのものが出力されるが、ソース分割・共通化を考慮していないので大量のスパゲッティコードが作られていったのが原因と思われる。

最初にしっかりとした設計が必要だと実感したので作成したソースコードを捨てて、AIと対話しながら設計書を書いてもらう形に変更、最終的に世間一般で設計書駆動と呼ばれるスタイルにそっくりとなる。

やはり、スタンダードな形に落ち着くね。先人の偉大さを実感。

おおむね予想通りの実装が行えたのだが、課題が残る。

画面の設計はHTMLでモックを作ってからGoのテンプレートに落とし込んでもらったのだが、テンプレートに落とし込む際、ふわっとした解釈で作られた感じでいろいろと変更点が出まくる。

先にテンプレートからモックHTMLを出力するコードを書いて、テンプレート直接実装したほうが効率よさそう。

また、ソースのディレクトリ構成は先に決めておくか、一部だけ先に作ってそれを修正してから、他を作りこむほうがよさそう。結果的にそこそこ後戻りが発生した。

最終的に満足が行く出来になったので良しとする。 想像通り、AIは銀の弾丸ではないらしい。今後はAIに合わせたフローが必要になってくるのだろうと思う。

逆に時間がかかったのは運用ステージに持っていくところ。 ビルド後のバイナリを渡して、Codexにいつも通り、dockerコンテナ上で動作するための設定変更を依頼したのだがなかなか動かず。

開発用のDevContainerから運用向けのサーバコンソールまでシームレスにつながっているわけではないので、Codexが片方ずつしか参照できず解決の役に立たない。

DevContainer側のCodexは、運用時のコンテナの中身を見れず、どのような構成になっているのかわからない。

逆にサーバコンソール側のCodexはプログラムがどのような状態で動くのが正しいか、正解がわからない様子。

最終的に二つのCodexの橋渡しをするためのドキュメントを作成して解決する。

解決方法については今後も役に立ちそうな考え方なのでここにメモしておく。 ローカル環境で、AIにdockerfileを書かせて、ローカル環境でコンテナを実行、コンテナ内で不整合がない形を作っておく Readme.mdに使用方法、設定パラメータ、dockerfile、コンテナの立ち上げ方などを記載、サーバ側のAIに読ませて環境構築を行わせる。また、Github上であらかじめリリースしておいたバイナリを使用する