Membangun Aplikasi Video AI dengan Coding Agent

Bulan lalu saya merilis fitur pembuatan video kecil. Coding agent menulis sebagian besar lapisan integrasi. Inferensi tetap berjalan di tempat biasanya — pada API model terpisah, dengan latensi, penagihan, dan perilaku antrian tersendiri. Dua hari kemudian, saya menyadari diri sendiri sedang membangun model mental yang salah: bahwa agent dan model berada di sumbu yang sama. Ternyata tidak.

Pengembangan aplikasi video AI di tahun 2026 berada di zona tengah yang aneh. Scaffolding menjadi lebih cepat. Runtime — antrian, percobaan ulang, fallback ketika provider menghentikan layanan — menjadi lebih sulit. Di sinilah coding agent membantu, di mana mereka berhenti, dan apa yang sebenarnya dibutuhkan stack Anda.

Saya Dora. Inilah catatannya.

Mengapa coding agent mengubah pengembangan aplikasi video AI

Apa yang bisa diotomatisasi Codex dalam scaffolding aplikasi

Coding agent seperti Codex — dapat diakses melalui CLI, IDE, dan SDK, dengan cakupan saat ini di dokumentasi OpenAI Codex — meringkas bagian membosankan dari pengembangan aplikasi video AI.

Hal-hal yang dilakukan dengan baik: scaffolding backend yang membungkus API pembuatan video, menghasilkan klien bertipe dari spesifikasi OpenAPI, menulis logika worker antrian dan webhook handler, membangun komponen React upload-prompt-preview, menulis integration test terhadap respons yang di-mock. Tidak ada tugas-tugas ini yang sulit. Semuanya membosankan. Agent menyelesaikannya dalam satu jam, bukan seharian.

Saya pernah pergi dari repo kosong ke endpoint pembuatan video yang berfungsi dengan logika retry dan frontend nyata dalam waktu kurang dari setengah hari. Pertama kali, saya tidak mempercayainya. Ketiga kalinya, saya sudah membangun kebiasaan untuk meninjau kode yang dihasilkan agent, bukan menulisnya dari awal.

Apa yang tidak bisa digantikan Codex dalam inferensi media

Agent tidak menghasilkan video. Agent menghasilkan kode yang memanggil API yang menghasilkan video. Inilah garis yang terus kabur, dan mengaburkannya merugikan keputusan arsitektur Anda.

Codex tidak akan memilih model video mana yang cocok untuk kasus penggunaan Anda. Tidak akan memutuskan antara harga per detik dan langganan berbasis kredit. Tidak akan menulis strategi fallback yang bertahan dari penghentian Sora 2 pada 24 September 2026. Tidak akan memberi tahu apakah image-to-video atau text-to-video sesuai dengan kebutuhan pengguna Anda. Ini adalah keputusan yang Anda buat. Agent mengeksekusi keputusan Anda. Bukan membuatnya.

Stack aplikasi video AI yang sebenarnya dibutuhkan builder

Frontend, backend, job queue, storage, dan model API

Aplikasi video AI yang nyata terdiri dari lima lapisan, dan model API hanyalah salah satunya.

Frontend: input prompt, pengunggah aset, pratinjau pembuatan, indikator status yang tidak bohong ketika job memakan waktu tiga menit.
Backend (backend aplikasi AI, di mana Anda akan menghabiskan sebagian besar waktu): permukaan API, validasi, moderasi, pengiriman job, polling status atau penanganan webhook, pelacakan database tentang apa yang sedang berjalan.
Job queue: pembuatan video memakan waktu menit, bukan milidetik. Panggilan sinkron tidak akan bertahan.
Storage: MP4 yang dihasilkan disimpan di suatu tempat — S3, R2, CDN Anda sendiri — dan aplikasi Anda mencatat URL-nya.
Model API: endpoint pembuatan video yang sebenarnya. Sora 2, Veo 3.1, Kling 3.0, Runway, Seedance — pilih satu, atau rute ke beberapa.

Codex melakukan scaffolding untuk lapisan satu hingga empat. Yang kelima adalah pertanyaannya.

Di mana API pembuatan gambar dan video cocok

Sebagian besar aplikasi video membutuhkan keduanya. Pembuatan gambar digunakan untuk thumbnail, frame referensi, kondisi first-frame pada pipeline image-to-video, atau gambar diam yang disediakan pengguna. Pilihan OpenAI saat ini adalah gpt-image-2, didokumentasikan dalam dokumentasi OpenAI Image API. Untuk video, ada API vendor langsung (OpenAI Videos, Google Veo, Kling, Runway) atau platform agregasi yang merutekan ke beberapa backend.

Alasan ini penting: pembuatan gambar berjalan dalam hitungan detik dan ditagih per gambar. Pembuatan video berjalan dalam hitungan menit dan ditagih per detik output. Batas rate berbeda, profil latensi berbeda, model biaya berbeda. Backend Anda harus menangani keduanya, dan jika Anda memperlakukannya sebagai jenis panggilan yang sama, logika antrian Anda akan salah.

Cara merancang workflow

Penerimaan prompt dan upload aset

Pengguna mengirimkan prompt, opsional dengan gambar referensi atau frame awal. Tiga hal yang harus benar sebelum permintaan meninggalkan backend Anda:

Validasi input. Batasan resolusi, batas rasio aspek, ukuran file. Model menolak input yang salah bentuk dengan error yang tidak selalu bisa dibaca.
Jalankan moderasi terlebih dahulu. Gunakan endpoint omni-moderation gratis OpenAI — menerima teks dan gambar, tidak ada biaya, menghentikan sebagian besar pelanggaran kebijakan sebelum Anda menghabiskan uang untuk panggilan API video.
Simpan input asli. Ketika pembuatan gagal, Anda ingin aslinya untuk mencoba ulang terhadap model yang berbeda tanpa membuat pengguna mengunggah ulang.

Routing model untuk image-to-video atau text-to-video

Sebagian besar model video mendukung kedua mode, tetapi kesenjangan kualitas di antara keduanya bervariasi per provider. Logika routing Anda adalah tempat untuk mengkodekan ini.

Versi sederhana: route berdasarkan tipe input. Jika pengguna melampirkan gambar referensi, kirim ke model image-to-video Anda. Jika hanya teks prompt, kirim ke model text-to-video Anda.

Versi lebih matang: route berdasarkan kasus penggunaan (klip sosial pendek vs shot naratif lebih panjang), berdasarkan anggaran biaya (tier draft vs render final), berdasarkan persyaratan latensi. Ini adalah lapisan yang bertahan lama — model di balik setiap route berubah; logika routing sebagian besar tidak.

Pembuatan async, retry, dan status callback

Pembuatan video bersifat asinkron secara alami. Kirimkan job, dapatkan ID kembali, lalu lakukan polling atau tunggu webhook. Bangun untuk keduanya — beberapa provider hanya mendukung salah satu. Lapisan worker Anda membutuhkan:

Exponential backoff dengan jitter pada retry. Retry yang tersinkronisasi dari fleet mencapai ceiling rate yang sama pada waktu yang sama dan memperburuk pemadaman.
State machine status yang membedakan pending, running, succeeded, failed-retryable, failed-permanent. Memperlakukan semua kegagalan sama adalah cara Anda menguras anggaran.
Timeout per job. Tanpa batas atas, Anda akan memiliki job yang terjebak selamanya setelah masalah provider.

Risiko produksi yang perlu direncanakan

Latensi antrian, kegagalan pembuatan, dan model fallback

Tingkat kegagalan pembuatan tidak nol, dan bervariasi berdasarkan provider, beban, dan konten prompt. Rencanakan sebagian kecil job yang tidak sepele untuk gagal.

Bangun jalur fallback sebelum Anda membutuhkannya. Jika API pembuatan video utama Anda mengembalikan error, worker Anda harus mencoba ulang terhadap provider kedua dengan perubahan kode minimal.

Lacak latensi per provider per model. Angkanya berubah seiring waktu, terutama pada jam sibuk. Jika latensi p95 Anda melampaui timeout Anda, pengguna Anda melihat kegagalan sebelum dashboard Anda melihatnya.

Kontrol biaya dan keamanan API key

Pembuatan video cepat menjadi mahal. Klip 10 detik dengan $0,30/detik adalah $3. Jalankan 1.000 sehari dan Anda berada di $90.000/bulan sebelum storage. Mode kegagalan default adalah pengeluaran tak terbatas.

Kontrol yang layak dibangun lebih awal:

Kuota pembuatan per pengguna. Tier gratis, tier berbayar, batas harian, batas bulanan. Batas lunak dengan notifikasi, batas keras dengan pemblokiran.
Isolasi API key per lingkungan. Dev, staging, prod. Sehingga satu dapat dirotasi tanpa mematikan produk.
Key berlingkup proyek sehingga Anda dapat melihat fitur mana yang menghabiskan anggaran mana.
Jangan pernah biarkan API key masuk ke repo yang dihasilkan Codex tanpa template .env dan entri .gitignore. Agent akan membuat scaffolding ini jika diminta, tetapi tidak selalu menawarkan secara sukarela. Key di lingkungan shell otonom Codex dapat melakukan apa pun yang bisa dilakukan akun Anda.

Kapan menggunakan platform inferensi media

API model langsung vs lapisan agregasi

Anda memiliki dua pilihan arsitektur untuk lapisan model. Panggil API setiap vendor secara langsung. Atau panggil platform agregasi yang mengekspos beberapa API model melalui satu antarmuka.

Langsung memberi Anda kontrol penuh, hubungan vendor penuh, fitur terbaru lebih dulu. Biayanya adalah overhead integrasi: setiap vendor (endpoint video OpenAI, dokumentasi Google Veo API, Kling, Runway) memiliki auth, bentuk permintaan, kode error, dan format webhook masing-masing. Mempertahankan empat integrasi langsung kira-kira setara dengan setengah tenaga kerja.

Agregasi menukar sebagian kontrol tersebut dengan permukaan yang lebih kecil. Satu API key, satu bentuk permintaan, platform menangani perbedaan vendor. Trade-off: fitur mungkin tertinggal, Anda bergantung pada uptime agregator, markup penagihan berlaku.

Mengapa satu API penting untuk pergantian model

Biaya pergantian dalam stack video lebih tinggi dari yang diperkirakan orang. Dimensi output berbeda, logika parameter berbeda, pola async berbeda, unit penagihan berbeda. Setiap integrasi langsung yang Anda pertahankan adalah satu lagi bagian dari codebase Anda yang harus berubah ketika Anda mengganti model.

Jika rencana pengembangan aplikasi video AI Anda mencakup “kita mungkin mencoba model yang berbeda dalam tiga bulan,” jalur API terpadu menghemat pekerjaan re-integrasi. Jika rencananya adalah “kita sudah memilih model dan tidak akan berubah,” integrasi langsung lebih bersih. Sesuaikan arsitektur dengan tingkat perubahan.

FAQ

Apa itu aplikasi video AI?

Aplikasi yang menghasilkan video dari input pengguna — teks prompt, gambar referensi, atau keduanya — menggunakan model AI yang diakses melalui API, bukan berjalan secara lokal. Frontend mengumpulkan prompt, backend mengirimkan job pembuatan ke model video (Sora 2, Veo, Kling, Runway, Seedance), worker async menangani penantian, dan MP4 yang dihasilkan disimpan dan dikirimkan. Sebagian besar aplikasi video AI di tahun 2026 menggunakan API model yang di-host karena model terlalu besar untuk dijalankan pada hardware konsumen dengan kecepatan yang wajar.

Bisakah Codex membangun aplikasi pembuatan video sendiri?

Ia membangun kode aplikasi — frontend, backend, logika antrian, integrasi dengan API video. Ia tidak membangun inferensi. Pembuatan video itu sendiri berjalan pada API model yang di-host yang Anda panggil dan bayar secara terpisah. Codex mengkompres bagian yang membosankan. Bagian yang menarik — pemilihan model, kontrol biaya, ketahanan produksi — tetap menjadi masalah manusia.

Apa yang harus diperhatikan developer sebelum menggunakan API video AI di produksi?

Tiga hal. Kalender penghentian provider (Sora 2 Videos API berakhir 24 September 2026 — jika Anda membangun di atasnya, Anda membutuhkan rencana migrasi). Tingkat kegagalan dan variansi latensi per model — tidak nol dan berubah. Biaya per detik yang dihasilkan dikalikan dengan traffic yang diharapkan — mode kegagalan default adalah pengeluaran tak terbatas.

Kapan builder harus menggunakan platform inferensi daripada API model langsung?

Ketika Anda berharap untuk mengganti model atau menjalankan lebih dari dua provider secara paralel. Biaya pemeliharaan beberapa integrasi langsung bertambah. Lapisan agregasi menukar sebagian kontrol dengan overhead integrasi yang lebih sedikit dan pergantian model yang lebih mudah. Jika Anda berkomitmen pada satu provider, integrasi langsung lebih bersih. Jika roadmap Anda mencakup evaluasi atau fallback lintas provider, lapisan terpadu terbayar dengan cepat.

Kesimpulan

Pengembangan aplikasi video AI dengan coding agent lebih cepat dari setahun yang lalu dan lebih sulit untuk diarsitektur dengan baik dari yang diasumsikan orang. Agent menangani bagian yang dulu memakan waktu seminggu mengetik. Yang tersisa — pemilihan model, desain workflow async, strategi fallback, kontrol biaya, kebersihan API key, kalender penghentian — adalah tempat pekerjaan yang sebenarnya berada.

Untuk builder yang memulai hari ini: gunakan Codex untuk scaffolding backend aplikasi AI, frontend, antrian, dan lapisan integrasi. Pilih API pembuatan video utama berdasarkan kasus penggunaan Anda, bukan berdasarkan model mana yang memuncaki leaderboard minggu lalu. Rancang untuk pergantian model sejak hari pertama. Batasi pengeluaran sebelum traffic tumbuh melampaui asumsi Anda.

Di situlah data saya berakhir. Sisanya perlu Anda verifikasi terhadap dokumentasi. Lebih banyak lagi akan datang.

Posting sebelumnya: