Codex で ThreadIn を 0→1で作って、ソフトウェア開発の見え方が変わった

ここ最近、Codex を使って小さな実験をしていました。

それが ThreadIn です。

ThreadIn は、オンライン上のコメントやスレッドを読んだときに、単なる翻訳ではなく、

• スラング
• tone（ニュアンス）
• sarcasm（皮肉）
• meme
• cultural context（文化的背景）

まで含めて理解できるようにする Chrome Extension です。

最初は「英語コメントを理解するためのツール」と考えていました。

でも作っていく中で、自分の中での理解が変わっていきました。

今はむしろ、「インターネットの文脈を理解するためのレイヤー」だと思っています。

多くの人は、単語の意味は分かります。

でも、本当に困っているのはそこではありません。

「言葉は読める。でも相手が本当に何を言いたいのか分からない。」

これは英語学習者だけではなく、ネイティブスピーカーでも同じです。

インターネットの文化、コミュニティごとの空気感、ミーム、皮肉、略語、暗黙知。

オンラインの会話には、辞書や翻訳だけでは届かない「文脈」が大量にあります。

Codex は「デジタル社員」ではなく、Jarvis だった

最近、AI Agent を「デジタル社員」と表現する人が多いです。

でも、自分が Codex を使って感じたのは少し違いました。

自分にとって Codex は、むしろ Jarvis に近かったです。

頭の中にあるアイデアを、すぐにコード、UI、コンポーネント、スクリプト、動くプロダクトに変換していく感覚。

これは本当に衝撃的でした。

以前は、アイデアがあっても、実際に形になるまでには長いチェーンが必要でした。

• 要件整理
• デザイン
• フロントエンド
• バックエンド
• テスト
• リリース

そのどこかで熱量が落ちていく。

でも今は違います。

「ちょっと試したい」が、数時間後には動く UI になっている。

「こういう体験が欲しい」が、数日後には本当に触れるプロダクトになっている。

この変化はかなり大きいと思います。

以前、何かアイデアを思いついたとき、自分の最初の反応は：

「これを作るには結構なチームが必要だな」

でした。

でも今は：

「まず Codex に作らせてみよう」

になっています。

この変化は、本当に大きい。

ただし、まだ完全な「ノーコード時代」ではない

もちろん、だからといって

「誰でも完全にノーコードでプロダクトを作れる」

とはまだ思っていません。

少なくとも、今の段階ではそうではないです。

Codex はかなり強い。

• コードを書く
• UI を組む
• 修正する
• リファクタリングする
• デバッグする
• ビルドを直す

かなりのことができます。

でも、プロジェクトが少し複雑になると、問題は別のところに出てきます。

特に厄介なのは、繰り返し発生するバグです。

Codex は時々、同じ場所をぐるぐる回ります。

一つのバグを直したと思ったら、別のバグを 3 つ増やす。

「違う、そこじゃない」が何回も起きる。

そこで自分がやるようになったのは、Codex に対して：

• ログを追加させる
• 状態を可視化する
• パラメータを出力する
• 分岐を追跡する
• イベントを埋め込む

ことでした。

そして、その情報をもう一度 Codex に渡して、問題を再分析させる。

これを繰り返してようやく直る。

この経験で強く感じたのは：

AI Coding 時代の本当のスキルは、「AI に何を見せるか」なのかもしれない。

ということです。

全部のコードを書く必要はない。

でも：

• どこが怪しいのか
• 何が重要な情報なのか
• どこを見るべきか
• 何が変化したのか
• 修正が本当に正しいのか

を判断する力は、まだ人間側に必要です。

つまり今の AI 開発は：

「AI が全部作る」

ではなく、

「AI が高速に作り、人間が方向修正する」

に近い感覚でした。

Codex が強くなるほど、「昔の起業の形」が弱くなる

ThreadIn を作っていて、もう一つ強く感じたことがあります。

それは：

Codex がここまで強くなると、昔は成立していた起業の形が、だんだん成立しにくくなる。

ということです。

以前なら、小さな機能を作って、UI を付けて、API を繋げるだけでも、ある程度の価値がありました。

でも今は、それが圧倒的に安く、速く作れてしまう。

昔なら小さなチームが必要だったものが、今では一人 + AI で週末に作れてしまう。

これはかなり大きな変化です。

ただ、機会がなくなるわけではないと思っています。

むしろ、機会は別の場所に移動している。

一つ目の大きな機会は「インフラ」

AI Native なプロダクトが増えれば増えるほど、重要になるのはインフラです。

例えば：

• GitHub
• CI/CD
• デプロイ
• モニタリング
• ログ
• モデルルーティング
• 支払い
• 権限管理
• データ基盤

もし画像や動画を扱うなら：

• FFmpeg
• GPU 処理
• メディアパイプライン

なども重要になります。

AI はアプリケーション層を爆発的に増やす。

でも、その裏側のインフラ価値は、むしろさらに大きくなると思っています。

「作ること」が安くなるほど、「安定して運用すること」の価値が上がるからです。

二つ目の機会は「マルチモーダル」

もう一つ、かなり大きいと感じたのがマルチモーダルです。

画像、音声、動画。

この領域は、単純なテキスト生成とは違います。

問題は「生成できるか」ではなく：

• センス
• 審美眼
• テンポ
• 演出
• 判断
• 一貫性

だからです。

실제로 ThreadIn 의 동영상과 썸네일을 만들 때 상당히 느꼈습니다.

AI 는 이미 나보다 더 능숙합니다.

하지만 인터넷상의 정말 뛰어난 프로모션 동영상이나 시각적 자료와 비교하면, 아직 차이가 있습니다.

'사용 가능한 것'은 만들 수 있습니다.

하지만 '강력한 것'을 안정적으로 만드는 것은 여전히 어렵습니다.

그래서 저는 멀티모달 영역의 진정한 기회는:

'이미지 생성' 그 자체라기보다,
가치 있는 생성 흐름을 만드는 것
이라고 생각합니다.

무한히 가챠를 돌리는 것이 아니라,

• 워크플로우
• 템플릿
• 품질 판단
• 수직 특화
• 재현성
  을 만드는 것입니다.

이곳에는 상당히 큰 가능성이 있다고 생각합니다.

마지막에

이번 ThreadIn 을 만들면서, 제가 가장 강하게 느꼈던 것은:

'소프트웨어 개발의 생산 방식 그 자체가 변기 시작되었다'
라는 점이라고 생각했습니다.

이는 어느 날 갑자기 세계가 바뀔 듯한 이야기가 아닙니다.

조용히, 하지만 확실히 진행 중인 변화입니다.

처음에는:

'AI 가 코드를 조금 쓸 수 있다'
였으나,
이제는:

• UI 를 만들고
• 디버그하고
• 동영상을 생성하고
• 자재를 만들고
• 배포를 도와주고
• 프로덕트를 형성하는
  까지 왔습니다.

그리고 깨닫게 되면:

'아이디어'와 '움직이는 프로덕트'의 거리가, 엄청나게 짧아졌습니다.

AIGC 의 변화는 기반 모델만으로 일어나는 것은 아닐지도 모릅니다.

오히려:

• 개인 개발자의 강화
• 작은 팀
• 빠른 검증
• 저비용 시행착오
• AI 네이티브 워크플로우
  이라는 형태로, 다른 방향에서 빠르게 진행되고 있습니다.

이번 ThreadIn 을 만들면서, 저는 그 변화를 상당히 현실적으로 느꼈습니다.

그리고 지금, 가장 흥미로운 시대로 들어온 것 같습니다.