monsitj/iStock/Getty Images Plus
Ikuti ZDNET: Tambahkan kami sebagai sumber pilihan di Google.
**Poin Penting ZDNET**
* Codex kesulitan melakukan debug secara holistik pada basis kode yang kompleks.
* Deep Research unggul dalam diagnosis saat konteks kode melibatkan perbandingan versi.
* Pengujian dan pengawasan manusia tetap sangat penting dalam pengkodean berbasis AI.
“Hah?!?” Terkadang, saat sedang menulis kode dan ada yang tidak berjalan semestinya, dan saya tidak sepenuhnya yakin apa masalahnya, otak saya memunculkan reaksi internal “Hah?!?” Saya rasa itu adalah cara saya mengenali adanya “masalah tersembunyi” tanpa langsung terjebak dalam kepanikan.
Beberapa hari setelah proses pengerjaan produk dengan bantuan AI, tepatnya setelah sprint pemrograman berbantuan AI selama empat hari yang sangat produktif, ada sesuatu yang terasa tidak beres. Awalnya, ini tidak tampak sebagai kesalahan fatal (yang ternyata merupakan penilaian yang keliru karena sebenarnya masalahnya serius).
Baca juga: Saya menyelesaikan pengembangan produk 4 tahun dalam 4 hari dengan $200, dan saya masih terpukau
Pada akhirnya, saya berhasil memecahkan masalah tersebut dengan menggunakan kombinasi Codex dari OpenAI dan Deep Research dari ChatGPT. Kolaborasi ini ternyata sangat diperlukan. Saya akan jelaskan alasannya sebentar lagi.
Tapi pertama-tama, mari kita urai makna dari “Hah?!?” itu.
Apakah Ini Benar-Benar Bug?
Semua ini terjadi setelah sprint coding besar saya. Saya membangun empat produk tambahan untuk produk keamanan saya. Setelah pengkodean utama selesai, masih banyak pekerjaan yang harus dilakukan, baik di sisi pemasaran dan dokumentasi maupun di sisi distribusi dan operasional.
Salah satu tugas utama adalah pengujian. Setelah itu, saya harus mengemas semuanya agar toko online saya dapat mendistribusikan paket plugin yang dapat diinstal kepada pengguna.
Baca juga: 10 rahasia ChatGPT Codex yang baru saya ketahui setelah 60 jam melakukan pair programming dengannya
Di sinilah saya menyadari sesuatu yang aneh. Mengklik dashboard WordPress menjadi tidak responsif selama 15-20 detik. Namun, ini hanya terjadi setelah saya beralih dari dashboard WordPress di lingkungan pengembangan saya selama beberapa jam.
Akses pertama saya di pagi hari terkunci selama sekitar seperempat menit. Tapi setelah itu, semuanya berjalan dengan baik. Tampaknya, saya harus meninggalkannya untuk waktu yang cukup lama sebelum perilaku ini muncul lagi. Ini akan terkunci lagi jika saya kembali setelah pergi melakukan hal lain, seperti menulis artikel.
Saya bahkan tidak yakin apakah ini adalah bug dalam kode saya. Bisa jadi ini masalah di sistem saya, proses *build*, WordPress, atau bahkan hanya bayangan saya saja.
Mencoba Mendiagnosis Masalah (Bagian 1)
Saya mencoba menjelaskan masalah ini kepada Codex, tetapi karena saya tidak yakin itu adalah masalah, panduan yang saya berikan tidak optimal. Codex pun tidak dapat memberikan pencerahan apa pun.
Baca juga: AI terbaik untuk coding di tahun 2025 (termasuk pemenang baru – dan yang tidak boleh digunakan)
Jadi, saya meminta Codex untuk membangun platform diagnostik yang mengukur setiap perilaku saat WordPress dimulai. Saya memintanya untuk menangkap setiap *hook*, setiap panggilan, setiap jeda waktu, dan mencatatnya dalam konsol diagnostik.
Sayangnya, tidak ada yang terlalu mencolok yang terekam dalam telemetri diagnostik tersebut. Lebih buruk lagi, saya benar-benar hanya memiliki satu kesempatan sehari untuk menangkap sesuatu karena satu-satunya manifestasi masalah yang dapat diandalkan adalah saat pertama kali saya mencoba menggunakan situs percobaan di awal hari.
Tidak ada. Kosong. Nihil.
Oh, Iya, Ini Pasti Bug
Setelah mengerjakan ini selama beberapa hari, saya memutuskan bahwa ini bukanlah bug yang sebenarnya. Ini hanyalah manifestasi kecil dari lingkungan pengembangan saya. Saya pun beralih ke merekam video tutorial untuk setiap plugin.
Bagi Anda yang telah mengikuti saga coding AI saya, mungkin ingat bahwa produk pertama yang saya hasilkan menggunakan Codex adalah alat analisis situs. Alat ini menangkap peristiwa yang terjadi di situs Anda (login gagal, kunjungan bot AI, laba-laba pencarian, dll.) dan menyajikan data mentah serta analisis yang jelas.
Baca juga: Saya melakukan coding 24 hari dalam 12 jam dengan alat AI $20 – namun ada satu jebakan besar
Mendemonstrasikan ini di lingkungan pengembangan saya tidak terlalu menarik karena datanya, tentu saja, hanya data uji. Jadi, saya memutuskan untuk memasang alat tersebut di server utama saya yang berhadapan langsung dengan pengguna, server yang digunakan untuk mendukung dan menjual produk-produk ini. Server itu mendapatkan banyak lalu lintas, menjadikannya kasus uji yang bagus untuk alat analisis pengunjung seperti milik saya.
Saya juga perlu memasang produk keamanan utama di sana karena alat pengunjung adalah *add-on*-nya. Jadi, saya menginstal *build* terbaru. Keputusan yang buruk? Keputusan yang baik? Hasilnya buruk.
Ini adalah keputusan buruk karena membuat situs saya tidak dapat digunakan. Mengklik apa pun memerlukan waktu tunggu satu menit atau lebih sebelum sesuatu terjadi. Ini tidak hanya terjadi di *dashboard* admin. Pengguna yang mengunjungi *front end* situs juga mengalami perilaku yang sama.
Ini adalah keputusan baik, karena segera menjadi jelas bahwa saya memiliki bug. Ini bukanlah hal sepele yang muncul saat situs percobaan saya “tidur” semalaman. Tidak, di situs yang aktif, ini membuat situs benar-benar tidak dapat digunakan.
Tapi hasilnya buruk, karena juga segera menjadi jelas bahwa tidak mungkin saya bisa mengirimkan pembaruan yang dibuat AI ini kepada pengguna saya. Membekukan situs saya sendiri adalah satu hal. Membekukan 20.000 situs lain di internet? Itu akan sangat buruk.
Baca juga: Kursus dan sertifikat AI gratis terbaik di tahun 2025 – dan saya sudah mencoba banyak
Situsnya begitu lambat sehingga saya tidak dapat mengakses *dashboard* plugin untuk menonaktifkannya. Saya harus masuk menggunakan *file manager* penyedia hosting dan menghapusnya dari luar WordPress.
Dengan melakukan itu, situs segera kembali beroperasi dengan normal, membuatnya sangat jelas bahwa masalahnya ada pada plugin keamanan yang telah saya perbarui.
Mencoba Mendiagnosis Masalah (Bagian 2)
Saya melaporkan observasi ini kembali kepada Codex. Sejak saya memulai *sprint* coding besar menggunakan Codex pada paket ChatGPT Plus dan kemudian paket Pro, Codex telah terbukti cukup mahir dalam *debugging*.
Tapi tidak kali ini. Seperti yang saya bahas dalam “10 rahasia ChatGPT Codex yang baru saya ketahui setelah 60 jam melakukan pair programming dengannya,” saya menyimpulkan bahwa Codex tidak bekerja dengan baik pada tugas-tugas berskala besar.
Pernahkah Anda pergi ke *drive-through* restoran cepat saji yang biasanya sangat andal untuk pesanan satu makanan biasa, tapi kali ini Anda memesan pesanan yang sangat besar? Restoran cepat saji yang tampaknya solid secara operasional untuk pesanan tunggal hampir selalu mengacaukan pesanan besar, terutama jika ada permintaan khusus.
Baca juga: Rekan kerja Anda sudah muak dengan ‘sampah kerja’ AI Anda
Codex juga tidak menangani “pesanan besar” dengan baik. Hasilnya selalu berantakan dan tidak berguna. Saya sangat sukses di masa lalu ketika memecah proyek besar dengan mengerjakan satu bagian pada satu waktu, tetapi itu tidak berhasil untuk masalah ini.
Ini adalah masalah sistem. Ada sesuatu tentang seluruh basis kode saya, sejak Codex mulai mengerjakannya, yang menyebabkan pembekuan. Saya tidak bisa menunjukkan Codex ke satu area kecil dan menyuruhnya bekerja lalu menunggu jawabannya. Ia harus melihat semuanya.
Saya mencoba memberi tahukan bahwa masalah ini muncul sejak ia mulai mengerjakan kode saya, tetapi ia tidak ingat kapan itu terjadi. Codex hanya mengetahui sesi saat ini dan apa pun yang secara sengaja diteruskan antar sesi. Tapi ia tidak memiliki memori nyata tentang apa yang dilakukannya, sehingga ia tidak memiliki kerangka kerja yang cukup untuk melihat apa yang mungkin telah diacaukannya.
Saya memberikannya sekitar 20 *prompt* berbeda. Setiap kali, ia pergi untuk “berpikir”. Ini mulai terasa seperti saat Anda membeli mobil dan salesman harus berlari ke belakang untuk “mendiskusikannya dengan manajernya” untuk setiap langkah. Codex perlu pergi dan berpikir selama 5 atau 10 menit, lalu kembali dengan “perbaikan” yang selalu tidak berguna atau tidak berfungsi.
Baca juga: AI memperkuat kekuatan tim Anda – dan kelemahannya, temuan laporan Google
Saya sangat frustrasi. Saya tahu bahwa saya bisa kembali ke kode tersebut sendiri dan mencoba mendiagnosis masalahnya. Saya telah mengambil alih banyak produk di mana saya menyerap kode orang lain dan mengembangkannya, jadi itu adalah keterampilan yang saya miliki. Tapi saya juga tahu bahwa melakukannya berarti saya akan memulai pekerjaan yang mungkin memakan waktu berminggu-minggu dan pada dasarnya menghilangkan semua peningkatan produktivitas yang saya raih dari *pair programming* dengan AI.
Pasti ada cara yang lebih baik.
Munculnya ChatGPT Deep Research
Jika Codex cukup buruk dalam pekerjaan *big picture*, Deep Research-nya ChatGPT justru mengkhususkan diri di dalamnya. Saya memutuskan untuk memberikan masalah ini kepada Deep Research.
Deep Research memiliki akses ke repo GitHub yang berisi proyek saya, sehingga logistik untuk memeriksa kode bukanlah masalah. Saya menjelaskan masalahnya dan melepaskannya.
Baca juga: AI adalah realitas baru setiap developer – 5 cara untuk memanfaatkannya secara maksimal
Sekitar setengah jam kemudian, ia kembali. Ia menyalahkan semua kode orisinal saya. Ada daftar panjang tempat-tempat dalam kode asli saya di mana bisa terjadi perlambatan yang sangat minor, satu milidetik di sini, satu milidetik di sana.
Tapi kode saya berfungsi. Saya telah mengirimkan kode yang dikeluhkan Deep Research selama bertahun-tahun, dan kode itu berjalan di lebih dari 20.000 situs. Jika kode itu menyebabkan perlambatan besar, saya pasti sudah mendengarnya.
Tapi tidak seperti Codex, yang hanya bekerja pada kode yang ada di repo GitHub atau *workspace* VS Code, Deep Research dapat menerima file apa pun, termasuk file zip.
Jadi saya memberikannya zip distribusi untuk versi 3.2 perangkat lunak keamanan saya. Saya telah mengirimkan versi 3.2 selama empat bulan dan ini terinstal pada 45,6% dari lebih dari 20.000 situs pengguna saya. Kita tahu versi itu tidak menyebabkan masalah. Saat ini, Codex dan saya sedang mengerjakan apa yang akan dirilis sebagai 4.0, dan versi 4.0-lah yang memiliki masalah pembekuan.
Baca juga: AI lebih cenderung mengubah pekerjaan Anda daripada menggantikannya, temuan Indeed
Saya memberi tahu Deep Research persis itu, dan bahwa 3.2 berfungsi dengan baik. Saya menyuruhnya untuk melihat 4.0, dan hanya memeriksa apa yang ditambahkan sejak rilis 3.2. Ini sangat memfokuskan proses analisisnya.
Dan coba tebak? Ia berhasil menemukannya. Ia menemukan sejumlah masalah. Kekhawatiran terbesar adalah bahwa plugin utama saya memeriksa status file robots.txt setiap kali pengguna mengakses situs.
Ini adalah sesuatu yang seharusnya hanya perlu diperiksa sekali, untuk menentukan apakah beberapa fitur dapat dimuat. Tapi itu berjalan terus-menerus. Di situs yang aktif (daripada mesin pengembangan saya), pemeriksaan itu membebani interpreter PHP hingga selesai. Ini pada dasarnya mematikan server.
Deep Research mengidentifikasi biang keroknya.
Hidup di Masa Depan Itu Keren
Di sinilah keadaan berubah dari “proyek saya kacau” menjadi “saya hidup di masa depan”. Saya mengambil hasil dari Deep Research dan menjelaskannya kepada Codex.
Karena ini adalah penjelasan yang cukup spesifik tentang suatu situasi, Codex segera dapat memfokuskan diri pada masalah tersebut. Solusi pertamanya dapat digunakan tetapi masih sedikit bermasalah. Kami mendiskusikannya bolak-balik, dan saya dapat memberikannya instruksi yang jelas.
Baca juga: AI terbaik untuk coding di tahun 2025 (dan yang tidak boleh digunakan)
Saya menyuruhnya untuk memeriksa status file itu tepat sekali dan mengingat statusnya. Kemudian, saya memintanya untuk memberi saya tombol yang dapat diklik pengguna untuk meminta pemeriksaan ulang status jika ada yang berubah dalam konfigurasi server.
Alih-alih berjalan dan membekukan server untuk setiap akses web, kode itu berjalan sekali saat startup, dan sekali lagi jika pemilik situs web meminta pemeriksaan ulang.
Codex memberikan saya *build* yang menjanjikan. Saya mengunggah