NoCodeGPT: Antarmuka Tanpa Kode untuk Membangun Aplikasi Web dengan Model Bahasa

ABSTRAK
Latar belakang
Model bahasa semakin banyak digunakan oleh pengembang perangkat lunak. Namun, masih belum jelas apakah antarmuka berbasis obrolan standar mereka cocok untuk pengembangan perangkat lunak—terutama bagi pengguna dengan pengalaman pemrograman terbatas.

Tujuan
Karya ini menyajikan suatu alat, disebut NoCodeGPT, yang menyediakan antarmuka khusus untuk model bahasa yang ditujukan untuk memungkinkan penerapan aplikasi web kecil tanpa menulis kode.

Metode
Pertama-tama kami melakukan studi eksploratif di mana tiga peserta menggunakan ChatGPT untuk mengimplementasikan aplikasi berbasis web sederhana. Setelah itu, kami merancang dan mengimplementasikan antarmuka GPT yang disesuaikan, yang disebut NoCodeGPT. Untuk mengevaluasi antarmuka baru ini, kami meminta 14 siswa dengan pengalaman pengembangan web terbatas untuk membangun dua aplikasi web kecil hanya menggunakan perintah.

Hasil
Studi eksploratif menunjukkan bahwa antarmuka obrolan serbaguna seperti ChatGPT tidak ramah pengguna untuk pengembangan aplikasi. Misalnya, satu peserta tidak dapat menyelesaikan satu pun cerita pengguna yang diusulkan. Sebaliknya, hasil dengan NoCodeGPT menggembirakan: 9 dari 14 peserta menyelesaikan semua cerita pengguna, sementara lima peserta lainnya menyelesaikan setidaknya setengahnya.

Kesimpulan
Antarmuka GPT standar kurang cocok untuk pengembang web pemula. Sebagai tanggapan, kami mengusulkan, merancang, dan menerapkan antarmuka baru yang menawarkan pengalaman yang lebih mudah diakses untuk membangun aplikasi web dengan model bahasa.

1 Pendahuluan
Model Bahasa Skala Besar (LLM) mengalami adopsi yang signifikan di antara pengembang perangkat lunak, dengan beberapa studi melaporkan peningkatan besar dalam produktivitas. Misalnya, studi terbaru oleh GitHub, berdasarkan data telemetri dari hampir satu juta pengguna, menyimpulkan bahwa pengembang cenderung menerima 30% dari saran kode yang diberikan oleh alat Copilot. 1 Studi tersebut memperkirakan bahwa tingkat adopsi ini setara dengan menambahkan 15 juta pengembang ke tenaga kerja profesional perangkat lunak global. Studi tersebut juga menyimpulkan bahwa peningkatan produktivitas ini akan berdampak signifikan karena “pengembang memanfaatkan peluang baru untuk memanfaatkan AI untuk desain solusi dan mempercepat transformasi digital di seluruh dunia.”

Studi lain menyelidiki penggunaan dan manfaat model bahasa dalam tugas rekayasa perangkat lunak tertentu, termasuk memperbaiki bug [ 1 , 2 ], menulis pengujian unit [ 3 ], menulis komentar kode [ 4 , 5 ], mendeteksi code smells dan masalah technical debt [ 6 , 7 ], dan memecahkan masalah pemrograman [ 8 – 10 ]. Namun, sejauh pengetahuan kami, hanya ada sedikit makalah yang menyelidiki penggunaan model bahasa untuk konstruksi sistem perangkat lunak menyeluruh, yaitu, dalam konteks di mana pengembang memiliki serangkaian persyaratan dan harus merancang, mengimplementasikan, menguji, dan memvalidasi sistem yang sama sekali baru [ 11 ]. Dalam konteks seperti itu, model bahasa digunakan sebagai generator kode, menerima sebagai input prompt yang menjelaskan persyaratan fungsional dan nonfungsional suatu sistem dan menghasilkan sebagai output aplikasi perangkat lunak yang dapat dijalankan. Satu pengecualian adalah makalah oleh Peng et al. [ 12 ], di mana penulis mengevaluasi penggunaan GitHub Copilot untuk mengimplementasikan server web berdasarkan deskripsi tekstual tingkat tinggi. Di satu sisi, mereka adalah yang pertama mengukur, melalui studi terkontrol, keuntungan produktivitas yang dapat dicapai dengan alat AI. Di sisi lain, aplikasi target mereka relatif kecil (server web sederhana) dan ditulis sepenuhnya dalam JavaScript. Itu tidak mengikuti arsitektur perangkat lunak yang diadopsi secara luas, seperti yang terstruktur menjadi komponen front-end dan back-end, yang umum dalam sistem berbasis web modern. Lebih jauh, implementasinya tidak menggunakan kerangka kerja populer untuk membangun antarmuka web atau mengelola basis data. Contoh lain mengacu pada demo yang dilakukan oleh salah satu pendiri OpenAI selama peluncuran GPT-4. 2 Untuk menunjukkan kekuatan versi baru, ia menggambar tiruan aplikasi di serbet, dan dari foto tiruan itu, ChatGPT mampu menghasilkan aplikasi web fungsional, meskipun tampaknya hanya terdiri dari komponen front-end-nya.

Dalam artikel ini, kami mulai dengan melaporkan studi eksploratif menggunakan ChatGPT versi 4 untuk mengimplementasikan aplikasi berbasis Web sederhana. Kami mendefinisikan serangkaian cerita pengguna dan teknologi untuk sistem tersebut. Kemudian, tiga pengembang dengan profil dan pengalaman berbeda secara independen mencoba mengimplementasikan aplikasi ini hanya menggunakan ChatGPT.

Sebagai temuan utama dari studi pertama ini, menjadi jelas bahwa ChatGPT tidak menawarkan antarmuka yang ramah pengguna untuk membangun aplikasi, bahkan sistem web kecil. Faktanya, dua peserta dengan pengalaman pengembangan web mampu membangun sistem yang diusulkan. Namun, peserta ketiga, dengan pengalaman terbatas dalam pengembangan perangkat lunak, tidak dapat menyelesaikan satu pun cerita pengguna yang diusulkan. Misalnya, ia kesulitan menyalin kode yang dihasilkan oleh ChatGPT ke folder yang benar (sebagaimana didefinisikan oleh arsitektur sistem). Yang lebih penting, ketika ChatGPT menghasilkan urutan hasil yang salah, ia tidak dapat kembali ke versi stabil terakhir yang telah dihasilkan oleh model tersebut.

Dengan demikian, sebagai kontribusi utama dari karya ini, kami merancang, mengimplementasikan, dan mengevaluasi alat yang menawarkan antarmuka yang disesuaikan untuk model bahasa seperti GPT, yang secara khusus menargetkan konstruksi aplikasi web kecil tanpa menulis kode. Alat ini, yang disebut NoCodeGPT, merangkum semua perintah yang terkait dengan teknologi dan persyaratan arsitektur sehingga pengguna tidak perlu memiliki domain dari aspek-aspek teknis ini. Alat ini juga secara otomatis menyimpan kode yang dihasilkan oleh GPT di folder yang benar. Hasilnya, pengguna tidak perlu menyertakan kode yang ada dalam perintah atau menyalin kode yang dihasilkan GPT ke folder lokal. Terakhir, alat ini mencatat semua interaksi, perintah, dan respons GPT, yang memungkinkan pengguna untuk dengan mudah kembali ke versi sistem yang stabil jika model bahasa mulai menghasilkan hasil yang salah. Singkatnya, dengan NoCodeGPT, pengguna hanya menulis perintah yang terkait dengan persyaratan fungsional, sementara masalah dan minat lain ditangani secara transparan oleh alat yang diusulkan.

Kami juga melakukan dua eksperimen terkontrol dengan alat NoCodeGPT, di mana siswa dengan pengalaman terbatas dalam pengembangan Web diundang untuk menggunakan sistem tersebut guna mengembangkan dua aplikasi Web kecil (sistem manajemen tugas kecil dan forum tanya jawab). Meskipun pengalaman peserta terbatas, hasilnya sangat berbeda dari yang kami peroleh dalam studi pertama dengan antarmuka ChatGPT standar. Dalam kasus aplikasi pertama (TodoApp), dua peserta menerapkan keempat cerita pengguna yang diusulkan, sementara dua peserta lainnya hanya melewatkan satu cerita. Dalam kasus aplikasi kedua (ForumApp), tujuh peserta menerapkan kelima cerita pengguna yang diusulkan, tiga peserta melewatkan dua cerita, dan satu peserta melewatkan tiga cerita. Hasil ini—yang sama sekali berbeda dari studi eksplorasi pertama menggunakan ChatGPT—memberi kami keyakinan untuk menegaskan bahwa NoCodeGPT menawarkan bantuan yang efektif untuk pembangunan sistem Web kecil oleh pengguna yang tidak berpengalaman, tanpa memerlukan penulisan kode apa pun.

Sisa dari makalah ini disusun sebagai berikut: Di Bagian 2 , kami menjelaskan studi eksplorasi kami yang memotivasi pembangunan alat NoCodeGPT. Di Bagian 3, kami menjelaskan fitur dan arsitektur alat kami. Bagian 4 menyajikan hasil penggunaan NoCodeGPT untuk membuat dua aplikasi web, pelajaran yang didapat, dan juga membahas ancaman terhadap validitas. Bagian 5 menyajikan pekerjaan terkait, dan akhirnya, Bagian 6 menyimpulkan.

2 Studi Eksplorasi
Di bagian ini, kami menjelaskan studi eksploratif yang awalnya kami lakukan untuk memahami potensi ChatGPT dalam menghasilkan sistem Web tanpa pengkodean, yaitu, hanya melalui perintah. Pertama, kami menyajikan metodologi studi ini (Bagian 2.1 ), diikuti oleh hasilnya (Bagian 2.2 ). Terakhir, kami menyajikan pelajaran utama yang dipelajari dari studi tersebut (Bagian 2.3 ).

2.1 Metodologi
2.1.1 Implementasi Referensi
Untuk memiliki implementasi referensi guna menilai penggunaan ChatGPT (versi 4) untuk membuat aplikasi Web, penulis pertama makalah ini—yang merupakan pengembang perangkat lunak berpengalaman—menerapkan forum Tanya Jawab sederhana dari awal, yang kami sebut appForum. Alasannya adalah untuk menghindari evaluasi aplikasi yang mungkin digunakan oleh OpenAI dalam fase pelatihan ChatGPT. Kami menggunakan aplikasi ini sebagai implementasi dasar untuk mengeksplorasi penggunaan ChatGPT sebagai platform tanpa kode. Aplikasi ini mengimplementasikan enam cerita pengguna sederhana:

AS1:
Sebagai pengguna, saya ingin mendaftar di forum.
AS2:
Sebagai pengguna, saya ingin masuk ke forum.
AS3:
Sebagai pengguna, saya ingin membuat pertanyaan.
AS4:
Sebagai pengguna, saya ingin menghapus pertanyaan.
AS5:
Sebagai pengguna, saya ingin menjawab pertanyaan.
AS6:
Sebagai pengguna, saya ingin menghapus jawaban.
Bahasa Indonesia: Di back-end, kami mendefinisikan bahwa implementasi harus menggunakan TypeScript (bahasa pemrograman), Node.js dengan ExpressJS (server runtime), dan SQLite (basis data relasional). Di front-end, Vue.js dan ViteJS (kerangka kerja web) dan TypeScript harus digunakan. Teknologi ini sangat populer dan menawarkan beberapa keuntungan yang menjadikannya pilihan yang menarik untuk membangun aplikasi web modern. Secara total, back-end yang diimplementasikan oleh penulis pertama memiliki 565 baris kode, tiga kelas, dan lima file. Basis data relasional memiliki tiga tabel ( tb_user , tb_answer , dan tb_question ). Front-end memiliki 820 baris kode, 11 file, enam komponen Vue.js, dan empat halaman. Jadi, karena backend dan frontend memiliki kurang dari 1 KLOC, kami mengklaim keduanya mewakili sistem web kecil.

Gambar 1 menunjukkan tangkapan layar halaman utama sistem referensi ini.

Gambar 2 menunjukkan diagram kelas sederhana dengan tiga kelas sistem ( Pengguna , Pertanyaan , dan Jawaban ) dan hubungan di antara keduanya.

2.1.2 Peserta
Dalam penelitian ini, kami meminta tiga pengembang untuk mengimplementasikan ulang sistem referensi kami menggunakan ChatGPT. Peserta P1 memiliki 23 tahun pengalaman dalam pengembangan perangkat lunak. Selain menjadi pengembang berpengalaman, ia juga bertanggung jawab atas implementasi referensi yang dijelaskan di subbagian sebelumnya. Oleh karena itu, P1 mewakili “pengembang terbaik” untuk mengevaluasi fChatGPT, yaitu, kami meminta pengembang berpengalaman untuk menggunakan ChatGPT guna menghasilkan kode untuk aplikasi yang telah ia terapkan sebelumnya. Peserta P2 adalah mahasiswa magister Ilmu Komputer. Ia juga memiliki dua tahun pengalaman dalam pengembangan perangkat lunak. Terakhir, peserta P3 adalah mahasiswa S1 CS tahun ke-4 tanpa pengalaman pengembangan perangkat lunak profesional sebelumnya.

Oleh karena itu, kami mencoba merekrut sekelompok peserta yang beragam dalam hal pengalaman pengembangan perangkat lunak dan pengetahuan mereka tentang aplikasi yang akan dikembangkan dengan dukungan ChatGPT. Perlu dicatat juga bahwa ketiga peserta memiliki pengalaman terbatas dengan ChatGPT, yang diharapkan karena ini adalah teknologi baru. Khususnya, mereka belum pernah menggunakan ChatGPT untuk menghasilkan aplikasi perangkat lunak yang lengkap.

2.1.3 Pertemuan Pembukaan
Dalam pertemuan ini, penulis pertama mempresentasikan fitur, cerita pengguna, dan tangkapan layar appForum kami kepada P2 dan P3. Kemudian, ia meminta mereka untuk mengandalkan ChatGPT guna menghasilkan kode yang menghasilkan aplikasi yang sedekat mungkin dengan implementasi referensi kami dan yang menggunakan teknologi yang sama. Penting untuk disebutkan bahwa P2 dan P3 tidak memiliki akses ke kode implementasi referensi. Dengan kata lain, P2 dan P3 diinstruksikan untuk hanya mengandalkan ChatGPT guna mengimplementasikan aplikasi yang identik.

2.1.4 Alat yang Digunakan oleh Peserta
Peserta hanya menggunakan editor teks sederhana untuk menyalin kode yang dihasilkan oleh alat OpenAI. Interaksi hanya dilakukan melalui perintah, tanpa mengubah parameter seperti suhu, batas token maksimum, atau pengaturan ChatGPT lainnya. Pada dasarnya, kami mencoba mereproduksi pengalaman yang sama yang dialami orang awam dengan model bahasa saat menggunakan antarmuka ChatGPT standar.

2.1.5 Rapat Tinjauan
Setelah menggunakan ChatGPT secara terpisah untuk mengimplementasikan sistem referensi kami, ketiga peserta mengikuti serangkaian pertemuan untuk meninjau dan menilai hasil yang dicapai menggunakan alat AI. Dalam pertemuan ini, mereka memaparkan perintah yang digunakan untuk berinteraksi dengan ChatGPT serta mengeksekusi dan mendiskusikan kode yang dihasilkan oleh alat tersebut. Mereka juga mengelompokkan perintah berikut untuk perintah yang digunakan dalam penelitian:

• Petunjuk Awal: petunjuk yang menjelaskan persyaratan fungsional dan nonfungsional utama, serta petunjuk untuk mengonfigurasi proyek dan menginstal kerangka kerja yang diperlukan.
• Petunjuk Fitur: petunjuk yang meminta penerapan fitur proyek, termasuk petunjuk yang meminta perilaku yang tidak didukung oleh kode yang dihasilkan.
• Perintah Perbaikan Bug: perintah untuk memperbaiki bug atau perilaku salah pada kode yang dihasilkan.
• Petunjuk Tata Letak: petunjuk untuk memberi gaya pada elemen front-end seperti tombol, tabel, dan kotak teks.
• Permintaan Lainnya: permintaan yang tidak sesuai dengan kategori sebelumnya, seperti permintaan penyesuaian konfigurasi dalam lingkungan pengembangan.

2.2 Hasil
Pada bagian ini, kami menjelaskan aplikasi yang dibuat oleh masing-masing peserta. Pertama, petunjuk yang mereka gunakan dirangkum dalam Tabel 1 .

TABEL 1. Petunjuk yang digunakan oleh setiap peserta.

2.2.1 Peserta #1
Peserta pertama ini mulai menjelaskan kisah pengguna dan teknologi yang diadopsi dalam aplikasi, dengan menggunakan perintah berikut:

Meskipun mencantumkan cerita pengguna pada perintah awal, P1 harus menggunakan 26 perintah lain untuk meminta penyempurnaan pada kode yang dihasilkan oleh ChatGPT, seperti pada perintah berikut:

Sebagai contoh lain, P1 harus menguraikan perintah yang secara eksplisit meminta catatan jawaban baru untuk pertanyaan tertentu. Ia juga menggunakan perintah lain untuk mengimplementasikan cerita pengguna yang hilang dan menyertakan informasi yang hilang, misalnya, nama pengguna yang menjawab setiap pertanyaan.

Selain itu, P1 menggunakan 28 perintah untuk memperbaiki bug dalam kode yang dihasilkan oleh ChatGPT, seperti:

Terakhir, P1 menggunakan tujuh perintah tata letak. Misalnya, dalam kode yang awalnya dibuat oleh ChatGPT, data tentang pertanyaan (ID, judul, dll.) disajikan di halaman sebagai item daftar dan bukan sebagai baris tabel, seperti yang direncanakan oleh peserta. Jadi, P1 menggunakan perintah berikut untuk meminta tata letak yang benar:

Gambar 3 menunjukkan tangkapan layar aplikasi yang diimplementasikan oleh P1 menggunakan ChatGPT. Halaman pada gambar ini digunakan untuk memposting jawaban.

2.2.2 Peserta #2
Dalam kasus ini, hanya satu perintah awal yang dibutuhkan, yaitu sebagai berikut:

Seperti yang mungkin diperhatikan pembaca, P2 memulai dengan meminta penerapan fitur tertentu (autentikasi), dengan menyediakan teks tingkat tinggi yang menjelaskan bidang dan tombol utama, dilengkapi dengan permintaan penanganan kesalahan dasar saat pengguna tidak ada, lalu secara eksplisit mencantumkan teknologi yang diinginkan untuk proyek tersebut. Pada akhirnya, ia meminta ChatGPT untuk membantu dalam seluruh proses, mulai dari memasang teknologi yang dibutuhkan hingga membangun halaman yang ditentukan.
Sebagai respons terhadap permintaan awal ini, ChatGPT merekomendasikan untuk membagi masalah menjadi beberapa langkah yang lebih kecil dan memberikan panduan untuk setiap langkah (misalnya, memisahkan kode berdasarkan domain dan menunjukkan di mana kode yang lebih baru dari domain yang sudah ada harus ditambahkan). Setelah semuanya dikonfigurasi, ChatGPT menyarankan kode untuk fitur sign-up/sign-in.

Namun, P2 menemukan bahwa jawaban ChatGPT tidak sepenuhnya benar dan fungsional, yang mengharuskannya menulis 17 perintah lagi untuk memperbaiki bug dalam kode yang dihasilkan. Sebagai contoh bug tersebut, kita dapat menyebutkan pustaka yang sebenarnya tidak diinstal atau tidak diimpor saat dibutuhkan, kode back-end tidak terintegrasi dengan benar dengan front-end, dan ada parameter yang hilang pada berkas konfigurasi proyek.

Bahasa Indonesia: Untuk fitur yang tersisa, P2 mengubah strateginya dan meminta ChatGPT untuk terlebih dahulu menghasilkan kode front-end dengan objek tiruan. Versi pertama front-end ini kemudian diuji dengan saksama. Setelah itu, diintegrasikan dengan kode back-end. Untuk langkah terakhir ini, P2 memutuskan untuk menggunakan perintah yang menyertakan kode front-end dan back-end saat ini. Perintah tersebut meminta ChatGPT untuk memperluas back-end dengan logika untuk menangani fitur-fitur baru yang sebelumnya diimplementasikan dan diuji di front-end. Sebagai contoh dari strategi baru ini, kami memiliki perintah berikut, di mana P2 meminta ChatGPT untuk menghasilkan kode di back-end (file app.ts ) untuk mempertahankan jawaban yang tersedia dalam formulir di front-end (file PostDetails.vue ).

Mengenai perintah gaya, P2 dapat memperoleh gaya yang diinginkan dengan menjelaskan bagaimana elemen seharusnya terlihat, misalnya, dengan memberi tahu kode heksadesimal tentang warna elemen tertentu atau bentuk tombol (misalnya, tombol dengan batas berbentuk stadion). Ia juga mencoba memberi nama warna dan meminta warna yang lebih gelap atau lebih terang dari warna yang sudah ada, yang juga dipahami ChatGPT. Gambar 4 menunjukkan tangkapan layar halaman untuk memvisualisasikan pertanyaan dan memberikan jawaban, seperti yang diterapkan oleh P2 menggunakan ChatGPT.

2.2.3 Peserta #3
Peserta ini memulai dengan perintah berikut yang menjelaskan teknologi dan fitur dasar aplikasi dan meminta ChatGPT untuk membuat kode:

Jawaban untuk pertanyaan pertama ini menyertakan sebagian besar berkas proyek dan juga petunjuk untuk memasang teknologi yang dibutuhkan. Namun, dua pertanyaan lagi diperlukan untuk memperoleh rincian tentang petunjuk tersebut, termasuk pertanyaan berikut:

Setelah perintah awal ini, P3 meminta ChatGPT untuk mengimplementasikan fitur lain dengan menggunakan 13 perintah, seperti:

Namun, kode yang dihasilkan oleh ChatGPT kehilangan beberapa file penting, seperti index.js (di backend). Memang, ChatGPT memberi tahu bahwa file ini perlu diimplementasikan, tetapi tidak menyediakan kode, bahkan setelah permintaan eksplisit. Akibatnya, beberapa bug tetap ada dalam kode yang dihasilkan. Selain itu, cerita pengguna yang penting seperti pendaftaran dan login pengguna tidak diimplementasikan dengan benar. Front-end untuk fitur tersebut dibuat tetapi tidak dapat memanggil kode koresponden di back-end. ChatGPT dengan benar mengaitkan masalah ini dengan kesalahan dalam koneksi antara front-end dan back-end. Namun, ketika P3 mencoba memperbaiki bug tersebut, ChatGPT masuk dalam suatu loop, terus-menerus menyarankan versi kode sebelumnya (dan juga salah). Setelah 18 kali mencoba, P3 menyimpulkan bahwa tidak mungkin untuk maju dan ia memutuskan untuk berhenti dengan proyek yang belum selesai.
2.3 Pelajaran yang Dipetik
Pelajaran utama yang dipetik dari studi ini adalah pentingnya kemahiran pengembang dalam teknologi dan kerangka kerja yang digunakan oleh sistem target. Misalnya, dua peserta pertama, yang berhasil menyelesaikan aplikasi yang diusulkan, sangat ahli dalam pengembangan web dan teknologi serta kerangka kerja terkaitnya. Hasilnya, mereka mampu memanfaatkan pengalaman mereka untuk merumuskan petunjuk yang memandu ChatGPT dalam memperbaiki bug dalam kode yang dihasilkan oleh alat tersebut.

Bug umum yang dihadapi oleh para peserta terjadi selama integrasi antara front-end dan back-end. Peserta 2 memecahkan masalah ini menggunakan strategi yang menarik. Pertama, ia membuat front-end dengan objek tiruan dan mengujinya secara menyeluruh. Kemudian, ia mengintegrasikan front-end dengan back-end menggunakan perintah yang menggabungkan kedua komponen. Perintah ini menginstruksikan ChatGPT untuk memperluas back-end guna mendukung fitur-fitur baru yang telah diuji di front-end.
2.4 Ancaman terhadap Validitas
Ada dua ancaman utama terhadap validitas hasil yang dilaporkan dalam studi eksploratif ini. Pertama, aplikasi referensi kami (forum tanya jawab) mungkin tidak mewakili keseluruhan sistem yang dibangun dari awal oleh pengembang perangkat lunak. Namun, kami memilih aplikasi terkenal yang mengikuti arsitektur umum dan menggunakan teknologi populer. Kedua, kode untuk aplikasi referensi dibuat oleh ChatGPT menggunakan perintah yang diformulasikan hanya oleh tiga pengembang. Namun, kami dengan hati-hati memilih pengembang dengan profil yang berbeda (pemula, cukup berpengalaman dalam pengembangan web, dan berpengalaman). Setelah percobaan, hasil yang diperoleh oleh peserta yang tidak berpengalaman jelas lebih buruk daripada hasil dari dua peserta lainnya. Hal ini menjadi jelas, misalnya, setelah menganalisis riwayat perintahnya dan, akibatnya, memahami kesulitan yang dihadapinya dalam memperbaiki kesalahan dalam kode yang dibuat oleh ChatGPT. Karena peserta ini tidak memiliki pengetahuan tentang kerangka kerja dan arsitektur web, ia tidak dapat merumuskan perintah perbaikan bug yang secara tepat menentukan file mana yang perlu dimodifikasi. Selain itu, ia kesulitan dalam menyiapkan lingkungan pengembangan dan mengonfigurasi kerangka kerja dengan benar di komputer lokalnya. Di sisi lain, dua peserta lainnya tidak menghadapi kesulitan apa pun yang dialami P3.

3 NoCodeGPT: Fitur dan Arsitektur
Berdasarkan pelajaran yang dipetik dari studi eksplorasi kami, kami memutuskan untuk mengimplementasikan antarmuka baru untuk GPT, dengan fitur-fitur khusus untuk membangun aplikasi web kecil hanya menggunakan perintah, yaitu, tanpa menulis kode apa pun. Antarmuka ini, yang disebut NoCodeGPT, dapat bertindak sebagai pengganti antarmuka tradisional (ChatGPT). Idenya adalah untuk memungkinkan tidak hanya pengembang menggunakan model bahasa untuk membuat aplikasi web. Sebaliknya, kami bermaksud agar pengguna dengan pengalaman pengembangan perangkat lunak terbatas juga dapat membuat aplikasi web kecil tanpa harus menulis satu baris kode pun.

Pada bagian ini, pertama-tama kami menjelaskan fitur-fitur utama NoCodeGPT (Bagian 3.1 ). Fitur-fitur ini muncul dari pengalaman dan pengamatan kami dalam Studi Eksplorasi. Selanjutnya, kami juga menyajikan arsitektur dan implementasi NoCodeGPT (Bagian 3.2 ).

3.1 Fitur Utama
Fungsi utama alat ini adalah sebagai berikut:

3.1.1 Petunjuk Awal
Alat ini mendefinisikan secara internal perintah awal untuk membangun sistem web, yang berarti perintah yang menentukan teknologi, arsitektur, dan direktori utama sistem, di antara keputusan lainnya. Dengan demikian, pengguna tidak perlu membuat atau menyediakan perintah ini. Selain itu, NoCodeGPT meminta pengguna untuk menyediakan perintah yang menjelaskan fungsionalitas inti sistem yang sedang dibangun (lihat Gambar 5 ). Perintah ini penting untuk menetapkan kerangka kontekstual yang akan dipertimbangkan oleh model GPT saat membuat sistem.

3.1.2 Fitur yang telah ditetapkan sebelumnya
Beberapa fitur sangat umum dalam sistem web. Oleh karena itu, kami memutuskan untuk menyediakan perintah bawaan dan yang telah diuji sebelumnya untuk secara otomatis menghasilkan dan menyertakan fitur tersebut dalam sistem yang dihasilkan oleh NoCodeGPT. Saat ini, alat tersebut mendukung dua fitur yang telah ditentukan sebelumnya: halaman login dan halaman registrasi pengguna.

3.1.3 Pembuatan dan Penyempurnaan Halaman
Karena NoCodeGPT secara eksklusif dirancang untuk membangun sistem web, diasumsikan bahwa sistem ini terdiri dari sekumpulan halaman. Untuk setiap halaman, pengguna harus memberikan nama dan deskripsi singkat tentang fungsi yang diinginkan. Misalnya, dalam kasus forum Tanya Jawab, pengguna dapat membuat halaman yang disebut Pengajuan Pertanyaan dengan deskripsi berikut: “Saya ingin dapat mengajukan pertanyaan di halaman ini. Untuk setiap pertanyaan, saya ingin sistem menyimpan informasi berikut:
.”

Namun, seperti yang kita pelajari dalam Studi Eksplorasi, kecil kemungkinan model GPT akan menghasilkan halaman ideal yang dibayangkan pengguna dalam iterasi pertama. Akibatnya, NoCodeGPT menyertakan fitur penyempurnaan tempat pengguna dapat meminta perbaikan pada halaman tertentu. Perintah ini dapat berupa tiga jenis: fitur baru (misalnya, halaman harus memiliki tombol untuk menghapus pertanyaan ); perbaikan bug (misalnya tombol hapus pertanyaan tidak berfungsi ), dan penyesuaian tata letak (misalnya tombol hapus pertanyaan harus diposisikan tepat setelah judul pertanyaan ). Gambar 6 menunjukkan contoh fungsi ini untuk Forum Tanya Jawab. Dalam gambar ini, pengguna menyempurnakan halaman Pengajuan Pertanyaan .

Karena penyempurnaan dibatasi pada satu halaman, implementasi alat ini dapat menambahkan konteks ke perintah yang diberikan oleh pengguna. Misalnya, implementasi kami secara otomatis menambahkan berkas kode sumber yang perlu disempurnakan oleh model GPT dalam perintah tersebut. Di satu sisi, fungsi ini penting untuk memungkinkan alat ini digunakan oleh pengguna yang kurang pengalaman, karena mereka biasanya tidak dapat mengidentifikasi dengan benar berkas kode sumber yang ingin diubah. Di sisi lain, fungsi ini meningkatkan efektivitas model bahasa dengan menyediakan kode yang tepat yang perlu dikerjakan.

3.1.4 Transisi Halaman Web
Aspek menarik lainnya adalah fitur yang disediakan oleh NoCodeGPT untuk menghubungkan dua halaman. Misalnya, di forum kami, pengguna harus membuat halaman Question Submission dan Answer Submission secara mandiri . Namun, setelah itu, mereka harus kembali ke halaman Question Submission dan meminta pembuatan tombol pada setiap pertanyaan yang menampilkan halaman dengan jawabannya. Contohnya ditunjukkan di bawah ini:

Setelah berbagai pengujian, kami menyimpulkan bahwa alternatif menggunakan perintah sederhana ini adalah solusi terbaik untuk menghubungkan halaman. Artinya, pengguna harus terlebih dahulu membuat dan menguji halaman satu per satu. Kemudian, mereka harus meminta koneksi antar halaman, kapan pun diperlukan. Untuk melakukannya, mereka cukup menggunakan perintah yang meminta agar saat komponen tertentu diklik, halaman lain harus ditampilkan.
3.1.5 Manajemen Versi
NoCodeGPT juga menerapkan sistem kontrol versi yang disederhanakan untuk kode yang dihasilkan dengan bantuan GPT. Hal ini memungkinkan pengguna untuk dengan mudah memulihkan versi sebelumnya jika GPT mulai menghasilkan kode yang tidak valid yang tidak sesuai dengan spesifikasi sistem. Misalnya, misalkan pengguna merumuskan permintaan yang meminta penerapan fitur
, dengan setiap pengajuan menghasilkan versi masing-masing
dari sistem. Namun, dalam versi tertentu
, model bahasa mungkin mulai berhalusinasi dan menghasilkan kode yang tidak valid. Dalam kasus seperti itu, pengguna dapat kembali ke versi
menggunakan satu tombol yang disediakan di antarmuka NoCodeGPT.

Fitur ini secara khusus dirancang untuk mengatasi kesulitan yang dialami oleh peserta P3 dalam Studi Eksplorasi kami. Peserta ini meninggalkan studi karena ChatGPT memilih jalur yang menghasilkan versi sistem yang tidak valid secara berurutan. Selain itu, menggunakan antarmuka ChatGPT standar, menelusuri kembali ke versi terakhir yang benar tidaklah mudah. ​​Pengguna harus menyimpan versi ini secara manual, yang bukan merupakan prosedur alami bagi pengguna yang kurang berpengalaman.

3.1.6 Eksekusi dan Visualisasi
NoCodeGPT juga menyediakan tombol yang memungkinkan pengguna untuk menjalankan dan memeriksa perilaku kode yang dihasilkan oleh GPT dengan cepat. Dengan cara ini, pengguna tidak perlu memiliki pengetahuan tentang alat baris perintah, seperti kompiler dan penerjemah.

3.2 Arsitektur dan Implementasi
Implementasi NoCodeGPT memiliki dua modul: front-end dan back-end, seperti yang ditunjukkan pada Gambar 7. Front-end bertanggung jawab untuk mengendalikan fungsionalitas halaman alat dan memandu pengguna melalui alur kerja untuk membangun aplikasi Web. Back-end bertanggung jawab untuk menerima permintaan yang dikirim oleh front-end dan memproses informasi yang diperlukan untuk membangun perintah yang dikirimkan ke OpenAI API. Back-end juga menyimpan semua interaksi dengan platform OpenAI dalam basis data.

Secara khusus, implementasi front-end menggunakan teknologi berikut: Vue.js (versi 3) dengan TypeScript menggunakan Composition API, HTML, dan CSS. Untuk implementasi back-end, ExpressJS, SQLite 3, dan JSON Web Token digunakan. Front-end memiliki 1.847 baris kode, dan back-end memiliki 3.342 baris, dengan total 5.189 baris.

Gambar 8 memberikan tampilan terperinci arsitektur alat yang diimplementasikan. Bagian depan terdiri dari kelas Main , yang mengendalikan inisialisasi komponen ini, dan kelas App , yang mengelola logika antarmuka. Manajemen rute halaman ditangani oleh kelas Route , yang mampu menampilkan halaman mana pun, seperti AddPageView dan LoginView . Secara khusus, halaman aplikasi adalah implementasi dari Komponen File Tunggal Vue. Komponen ini memanggil titik akhir yang diimplementasikan di bagian belakang menggunakan kelas CallService , yang bergantung pada implementasi standar kelas FetchAPI.

Di bagian belakang, perintah tersebut awalnya diproses dengan menambahkan informasi penting lainnya untuk memperoleh respons yang lebih akurat, dan, akhirnya, API GPT dipanggil untuk menghasilkan kode yang diminta oleh pengguna. Kelas PromptRequest dan PromptResponse masing-masing menyimpan permintaan dan respons yang dibuat ke API ini. Informasi terperinci dari permintaan sebelumnya juga disimpan untuk menerapkan mekanisme kontrol versi yang disediakan oleh alat tersebut. Terakhir, kelas PromptType menyimpan templat perintah yang dikirim ke platform OpenAI.

3.2.1 Suhu
Dari pengalaman Studi Eksplorasi, kami menyimpulkan bahwa menurunkan suhu justru membuat model lebih deterministik dan juga akurat. Oleh karena itu, kami memutuskan untuk mengurangi suhu yang digunakan dalam NoCodeGPT menjadi nol.

4 Evaluasi NoCodeGPT
Pada bagian ini, kami menyajikan evaluasi NoCodeGPT, yang dilakukan dalam dua tahap, dengan total 14 peserta, yang diundang untuk mengimplementasikan dua aplikasi web kecil hanya menggunakan perintah dan alat kami. Tujuan utama kami adalah untuk memverifikasi apakah NoCodeGPT membantu mengatasi keterbatasan yang diidentifikasi dalam Studi Eksplorasi.

4.1 Metodologi
Evaluasi alat yang diusulkan dilakukan dalam dua tahap. Pertama, uji coba dilakukan dengan empat peserta. Tujuannya adalah untuk menguji dan memvalidasi penerapan alat yang diusulkan dengan sejumlah kecil peserta dan menilai kelayakannya. Secara khusus, peserta menggunakan alat tersebut untuk menerapkan aplikasi manajemen tugas sederhana dengan kisah pengguna berikut:

1. Sebagai pengguna, saya ingin menambahkan tugas baru ke daftar.
2. Sebagai pengguna, saya ingin mengedit tugas yang ada.
3. Sebagai pengguna, saya ingin menandai tugas sebagai selesai.
4. Sebagai pengguna, saya ingin menghapus tugas dari daftar.

Peserta menerima pelatihan awal tentang alat tersebut (30 menit) dan juga diberikan contoh aplikasi dengan ketelitian rendah. Kami memutuskan untuk memberikan contoh ini agar peserta dapat memiliki gambaran tentang fungsionalitas yang perlu mereka terapkan. Namun, kami mengklarifikasi bahwa contoh tersebut hanya akan berfungsi sebagai contoh, artinya aplikasi yang akan dibuat tidak perlu memiliki tata letak yang identik.

Setelah percobaan perintis ini, kami melakukan percobaan yang lebih besar dengan 10 peserta. Dalam kasus ini, kami menggunakan ForumApp dari Studi Eksplorasi kami (Bagian 2 ) sebagai aplikasi target. 3 Peserta juga menerima pelatihan awal dan contoh aplikasi yang diminta. Mereka diminta untuk menerapkan kisah pengguna berikut:

1. Sebagai pengguna, saya ingin menambahkan pertanyaan baru ke forum.
2. Sebagai pengguna, saya ingin menghapus pertanyaan dari forum.
3. Sebagai pengguna, saya ingin mengakses jawaban atas pertanyaan yang diberikan di halaman terpisah.
4. Sebagai pengguna, saya ingin menjawab pertanyaan di forum.
5. Sebagai pengguna, saya ingin menghapus jawaban.

Dibandingkan dengan Studi Eksplorasi, kami membuat dua perubahan penting pada daftar cerita pengguna ForumApp. Pertama, kami menghapus cerita yang terkait dengan login dan registrasi pengguna, karena ini adalah fitur yang telah ditetapkan sebelumnya di NoCodeGPT, seperti yang dijelaskan di Bagian 3.1.2 . Kedua, kami menambahkan cerita yang secara eksplisit menyatakan bahwa, jika diberikan pertanyaan, penting untuk mengakses halaman kedua dengan jawabannya. Ini dilakukan untuk mencegah pengguna menerapkan seluruh aplikasi pada satu halaman. Jika itu terjadi, kami tidak akan dapat mengevaluasi kemampuan NoCodeGPT untuk mendukung pembuatan aplikasi yang terdiri dari beberapa halaman web.

Tabel 2 merangkum pengalaman pengembangan web peserta dalam setiap eksperimen (TodoApp dan ForumApp). Semua peserta adalah mahasiswa Teknik Komputer tingkat sarjana di tahun pertama atau kedua. Selain itu, seperti yang ditunjukkan, mereka cocok dengan profil pengguna ideal untuk NoCodeGPT, yang berarti mereka tidak memiliki pengalaman atau, paling banyak, memiliki satu tahun pengalaman dalam pengembangan web.

TABEL 2. Pengalaman peserta dalam pengembangan web.

4.2 Hasil Percobaan Percontohan (Todoapp)
Dalam percobaan percontohan, dua peserta berhasil membangun aplikasi TodoApp dengan keempat cerita yang diusulkan. Namun, dua peserta tidak mengimplementasikan salah satu cerita. Gambar 9 menunjukkan tangkapan layar aplikasi yang dibangun oleh salah satu peserta yang berhasil menyelesaikan keempat cerita.

Selain itu, Tabel 3 merinci cerita yang diimplementasikan oleh para peserta. Seperti yang dapat kita lihat, peserta P4 tidak dapat mengimplementasikan pengeditan tugas, sementara peserta P1 tidak dapat mengimplementasikan fitur untuk menandai tugas sebagai selesai. Dalam kedua kasus tersebut, para peserta mencoba mengimplementasikan fungsionalitas, tetapi kode yang dihasilkan oleh GPT tidak berfungsi seperti yang diharapkan. Dengan demikian, mereka memutuskan untuk menyerah tanpa mencoba lagi. Di sisi lain, pembuatan tugas baru, serta penghapusannya, diimplementasikan oleh keempat peserta.

TABEL 3. Peserta yang mengimplementasikan setiap cerita pengguna dalam percobaan percontohan (TodoApp).

Gambar 10 menunjukkan jumlah prompt yang digunakan setiap peserta untuk membangun TodoApp. Peserta P2 dan P3 berinteraksi paling banyak dengan alat tersebut dan merupakan satu-satunya yang menerapkan semua cerita pengguna, masing-masing menggunakan 16 prompt. Sebaliknya, peserta P1 dan P4 masing-masing menggunakan sembilan dan sebelas prompt. Jenis prompt yang paling umum adalah untuk meminta fitur, kecuali untuk peserta P2, yang menggunakan delapan prompt untuk meningkatkan tata letak aplikasi. Untuk P1, ada pembagian yang merata antara prompt fitur dan perbaikan bug, dengan masing-masing empat prompt. Menariknya, P1 dan P4 tidak menggunakan prompt tata letak apa pun, yang menunjukkan bahwa mereka puas dengan tata letak awal yang diusulkan oleh GPT. Terakhir, semua peserta menggunakan tepat satu prompt awal.

Fungsionalitas kontrol versi NoCodeGPT banyak digunakan selama percobaan percontohan. Keempat peserta melakukan total 16 kali rollback saat membangun aplikasi web yang diusulkan. Tabel 4 menunjukkan bahwa peserta P4 memanfaatkan fitur ini secara maksimal, dengan meminta lima kali rollback.

TABEL 4. Pembalikan oleh peserta dalam percobaan percontohan (TodoApp).

Gambar 11 mengilustrasikan operasi rollback yang dilakukan oleh partisipan P2. Dalam gambar ini, setiap cabang mewakili serangkaian perintah yang ditinggalkan (yaitu, yang diakhiri dengan rollback). Secara khusus, P2 melakukan empat rollback, setelah perintah 4, 6, 10, dan 13. Kita juga dapat melihat bahwa P2 menggunakan total 16 perintah, tetapi tujuh perintah dibuang. Hanya sembilan perintah yang menghasilkan kode yang dapat digunakan (perintah 1-2, 7-9, 11, 14-16).

4.3 Hasil Percobaan Kedua (Forumapp)
Pada percobaan kedua (ForumApp), tujuh peserta berhasil mengimplementasikan kelima cerita tersebut. Tiga peserta terakhir gagal mengimplementasikan setidaknya dua cerita pengguna. Gambar 12 dan 13 menunjukkan tangkapan layar aplikasi yang dibuat oleh salah satu peserta yang menyelesaikan kelima cerita tersebut. Gambar 12 menunjukkan halaman registrasi pertanyaan, dan Gambar 13 menunjukkan halaman registrasi jawaban.

 

Tabel 5 menunjukkan cerita yang diterapkan oleh peserta dalam percobaan kedua. Seperti yang dapat kita lihat, peserta P8, P9, dan P10 tidak dapat menerapkan cerita tentang menjawab pertanyaan dan menghapus jawaban. Peserta P9 adalah satu-satunya yang gagal menerapkan cerita ketiga, yang mendefinisikan bahwa dari halaman pertanyaan, halaman jawaban seharusnya dapat diakses. Kami juga membandingkan rasio penyelesaian cerita pengguna dari percobaan ini dengan rasio dari percobaan kedua menggunakan uji-t. Kami menyimpulkan bahwa tidak ada perbedaan yang signifikan secara statistik antara kedua distribusi (nilai-p = 0,4667).

TABEL 5. Peserta yang menerapkan setiap cerita pengguna dalam percobaan kedua.

Gambar 14 menunjukkan jumlah prompt yang digunakan oleh peserta untuk membangun ForumApp. Prompt tipe fitur adalah yang paling sering digunakan oleh peserta, berjumlah 37 prompt, diikuti oleh 20 prompt tipe awal. Setiap peserta menggunakan dua prompt tipe awal: satu untuk halaman pendaftaran pertanyaan dan satu lagi untuk halaman pendaftaran jawaban. Kategori perbaikan bug dan tata letak masing-masing memiliki 14 prompt.

Dari tujuh peserta yang berhasil menerapkan aplikasi, P7 menggunakan jumlah perintah terbanyak (12), sementara P3 menggunakan perintah terendah (5). Alasan utama perbedaan ini tampaknya adalah tingkat detail perintah awal mereka. P3 memulai dengan perintah yang lebih terperinci, seperti yang disajikan berikut ini:

Di sisi lain, permintaan awal P7 lebih ringkas sebagai berikut:

Peserta P9 dan P10 adalah satu-satunya yang tidak menggunakan perintah tipe tata letak. Perilaku ini umum terjadi di antara peserta yang kesulitan menyelesaikan aplikasi. Karena kedua peserta tidak dapat menerapkan semua fungsi, mereka tidak mencapai tahap di mana perintah tipe tata letak biasanya digunakan, yaitu, setelah semuanya berfungsi seperti yang diharapkan. Peserta P1, P2, dan P3 adalah satu-satunya yang tidak menggunakan perintah perbaikan bug, mungkin karena perintah awal mereka yang lebih terperinci menghasilkan hasil yang lebih tepat oleh model GPT.
Terakhir, Tabel 6 menunjukkan jumlah rollback yang dilakukan oleh setiap peserta. Seperti yang dapat kita lihat, fitur ini lebih jarang digunakan selama pengembangan ForumApp dibandingkan dengan studi percontohan dengan TodoApp. Hipotesis kami adalah, meskipun ForumApp memiliki dua halaman, halaman-halaman tersebut lebih sederhana daripada halaman tunggal yang ditentukan dalam TodoApp. Halaman-halaman yang lebih sederhana ini memudahkan peserta untuk menentukan perintah yang lebih efektif. Hasilnya, GPT mampu menghasilkan kode yang benar pada percobaan pertama, sehingga mengurangi kebutuhan untuk rollback.

TABEL 6. Kemunduran oleh peserta pada percobaan kedua.

4.4 Persepsi Peserta
Setelah percobaan, para peserta juga melaporkan persepsi mereka tentang NoCodeGPT dalam bentuk yang sederhana. Mereka menjawab dua pertanyaan:

4.4.1 Apa Saja Keunggulan Utama Alat Ini?
Di antara poin-poin positif yang disorot oleh para peserta adalah kesederhanaan antarmuka NoCodeGPT (10 peserta), kemudahan karena tidak perlu menyalin dan menempel kode (9 peserta), dan tidak perlunya pengetahuan sebelumnya tentang bahasa pemrograman (10 peserta). Berikut ini adalah beberapa aspek positif dari alat yang disebutkan oleh para peserta:

Kami mampu membuat aplikasi fungsional tanpa menggunakan kode apa pun, hanya instruksi sederhana. Kemungkinan memilih versi sebelumnya sangat penting untuk memperbaiki beberapa bug .

NoCodeGPT memiliki tujuan yang menarik dan sangat berguna, terutama jika Anda memiliki pengetahuan minimal tentang pengembangan. Salah satu fitur terbaiknya adalah dapat kembali ke versi sebelumnya .

Alat ini sangat mudah digunakan; dan fitur tidak perlu menyalin-menempel kode apa pun atau memiliki pengetahuan sebelumnya tentang bahasa pemrograman (meskipun pengetahuan pasti meningkat merupakan keuntungan); Fitur untuk kembali ke versi sebelumnya sangat berguna dan sangat membantu dalam konstruksi .

4.4.2 Apa Kelemahan Alat Ini?
Poin negatif utama yang ditunjukkan oleh peserta adalah keterlambatan respons selama interaksi dengan perintah (14 peserta), seperti yang dikomentari oleh peserta berikut:

NoCodeGPT terkadang membutuhkan waktu terlalu lama untuk merespons. Tingkatkan waktu respons .

Responnya lambat, saya sarankan untuk meningkatkan kecepatan pemrosesan alat .

Butuh waktu terlalu lama untuk menjalankan perintah .

Namun, penting untuk dicatat bahwa penundaan ini mengacu pada akses ke GPT API yang disediakan oleh OpenAI. Jadi, ini adalah variabel yang tidak dapat kami kendalikan.

4.5 Pelajaran yang Dipetik
Dalam studi eksplorasi, kami menyimpulkan bahwa antarmuka default yang ditawarkan oleh ChatGPT tidak cocok untuk pengguna tanpa pengalaman pemrograman. Oleh karena itu, kami memutuskan untuk berinvestasi dalam desain dan implementasi NoCodeGPT, pembungkus untuk API GPT dengan fitur yang memudahkan pengguna awam untuk membuat aplikasi web sederhana tanpa menulis kode.

Pada bagian ini, kami melaporkan hasil dari dua studi yang dirancang untuk mengevaluasi efektivitas NoCodeGPT dalam mencapai tujuannya. Pada studi pertama (TodoApp), dua peserta menerapkan keempat cerita pengguna yang diusulkan, sementara dua peserta lainnya hanya melewatkan satu cerita. Pada studi kedua (ForumApp), tujuh peserta menerapkan kelima cerita pengguna yang diusulkan, tiga peserta melewatkan dua cerita, dan satu peserta melewatkan tiga cerita.

Berikutnya, kami membahas secara singkat peran dan kontribusi fitur utama NoCodeGPT dalam hasil ini.

• NoCodeGPT menetapkan perbedaan yang jelas antara dua kategori prompt: (1) prompt yang mendefinisikan teknologi dan arsitektur; dan (2) prompt yang mendefinisikan persyaratan fungsional. Prompt yang terakhir ditangani dan dienkapsulasi oleh alat tersebut. Akibatnya, pengguna bertanggung jawab penuh untuk menulis prompt yang menjelaskan persyaratan fungsional.
• NoCodeGPT juga mengelola dan menyimpan kode yang dihasilkan oleh GPT. Dengan demikian, pengguna tidak perlu menyalin dan menempel kode yang dihasilkan ke direktori lokal atau membuat struktur folder khusus untuk setiap aplikasi dan arsitektur. Masalah ini sepenuhnya diotomatisasi oleh alat yang diusulkan. Alat ini juga mengotomatiskan tugas-tugas terkait, seperti menginstal pustaka dan mengonfigurasi variabel lingkungan. Perlu disebutkan bahwa tugas-tugas tersebut merupakan kendala utama bagi peserta nonahli dari Studi Eksplorasi kami (Bagian  2 ).
• Fitur rollback sangat penting dalam kinerja NoCodeGPT, khususnya dalam percobaan dengan TodoApp. Intinya, fitur ini mengurangi kemungkinan pengguna menyerah ketika bug berulang kali muncul dalam kode yang dihasilkan. Ketika ini terjadi, pengguna dapat dengan mudah memulihkan versi yang tidak memiliki bug ini.
• Tombol eksekusi dan visualisasi kode juga sangat penting bagi pengguna untuk dengan cepat memeriksa dan mengidentifikasi masalah dalam kode yang dihasilkan, termasuk bug dan masalah tata letak.

Meskipun NoCodeGPT dirancang untuk membantu pengembang dengan pengetahuan terbatas tentang pengembangan perangkat lunak web, kami yakin ini juga dapat membantu pengembang yang lebih berpengalaman, terutama dalam aktivitas pembuatan prototipe atau saat mengimplementasikan Produk Minimum yang Layak (MVP).

4.6 Ancaman terhadap Validitas
Hasil yang disajikan dalam bagian ini rentan terhadap dua ancaman utama terhadap validitas. Pertama, ukuran sampel terbatas dari 14 peserta yang merumuskan perintah untuk konstruksi aplikasi. Ada kemungkinan bahwa peserta ini tidak mewakili seluruh populasi pengguna yang bermaksud menggunakan ChatGPT untuk mendukung konstruksi perangkat lunak menyeluruh. Namun, peserta dengan profil dan tingkat pengalaman yang sama dengan P3 dari studi eksplorasi dipilih dengan cermat untuk mengurangi keterbatasan ini. Kedua, ForumApp dan TodoApp mungkin tidak mewakili spektrum penuh sistem yang dibangun dari awal oleh pengembang perangkat lunak. Namun, mereka mengikuti arsitektur umum (berbasis web, dengan komponen front-end dan back-end) dan menggunakan teknologi populer seperti TypeScript, Vue.js, dan SQLite, yang meningkatkan generalisasi temuan kami.

5 Pekerjaan Terkait
Di bagian ini, kami membahas makalah-makalah terkini yang terkait dengan studi kami. Pertama, kami mengomentari makalah-makalah yang terkait dengan tujuan utama kami dalam menggunakan LLM untuk mendukung konstruksi perangkat lunak. Setelah itu, kami membahas makalah-makalah yang mengandalkan LLM untuk mengotomatiskan tugas-tugas pemeliharaan perangkat lunak, termasuk memperbaiki bug dan menulis pengujian.

5.1 Konstruksi Perangkat Lunak
Peneliti dari Microsoft Research, GitHub, dan MIT melakukan eksperimen terkontrol dengan pengembang profesional yang diminta untuk mengimplementasikan server HTTP dalam JavaScript [ 12 ]. Kelompok perlakuan, yang memiliki akses ke GitHub Copilot, mampu menyelesaikan tugas yang diusulkan
lebih cepat. Namun, kami mengklaim bahwa studi kami menggunakan aplikasi yang mencerminkan praktik pengembangan perangkat lunak saat ini. Misalnya, forum Tanya Jawab kami mencakup front-end (diimplementasikan dalam kerangka kerja yang banyak digunakan, Vue.js), API yang disediakan oleh back-end (dalam bentuk serangkaian titik akhir HTTP), dan basis data SQLite.

Le dan Zhang mengevaluasi penggunaan ChatGPT dalam konteks yang sangat spesifik, yaitu, untuk mengimplementasikan parser secara otomatis untuk berkas log [ 13 ]. Dalam kumpulan data dengan ribuan berkas log, penulis melaporkan bahwa ChatGPT mencapai akurasi 71%, yaitu, pesan log yang dipulihkan dengan benar oleh parser yang dihasilkan oleh alat tersebut (dari prompt generik). White dan rekannya menggambarkan serangkaian 13 pola prompt untuk memecahkan berbagai macam masalah rekayasa perangkat lunak, dari desain sistem hingga implementasi dan pemeliharaan [ 14 ]. Namun, prompt ini lebih abstrak dan generik daripada yang kami gunakan dalam penelitian kami. Secara khusus, prompt kami bertujuan untuk menghasilkan perangkat lunak yang dapat digunakan dan dijalankan dari persyaratan berbasis agile (ditulis sebagai cerita pengguna). White dan rekannya juga mengusulkan enam pola prompt yang terkait dengan tugas pemeliharaan kode, evolusi, dan refactoring, yang berada di luar cakupan penelitian kami. Akhirnya, penting juga untuk menyebutkan bahwa dalam pekerjaan kami, kami tidak hanya mendefinisikan prompt tetapi juga menggunakannya dalam konteks dunia nyata untuk konstruksi perangkat lunak ujung ke ujung.

Demikian pula, Sadik dan rekan-rekannya dari Honda Research Institute secara komprehensif menjelaskan berbagai aplikasi LLM dalam rekayasa perangkat lunak, termasuk pembuatan kode, dokumentasi, deteksi bug, dan refactoring [ 15 ]. Namun, mereka tidak menerapkan perintah mereka dalam konteks dunia nyata. Para peneliti dari Meta menjelaskan pesaing GitHub Copilot yang mereka kembangkan secara internal di perusahaan tersebut [ 16 ]. Selain menggambarkan desain dan implementasi sistem, yang disebut CodeCompose, para penulis menyajikan hasil mengenai penggunaan dan adopsi alat tersebut. Mereka menyimpulkan dengan menyebutkan bahwa “selain membantu dalam implementasi kode (penulisan), CodeCompose memperkenalkan efek positif lainnya, seperti mendorong pengembang untuk menghasilkan lebih banyak dokumentasi, membantu mereka menemukan API baru, dll.”

Nguyen dan Nadi mengevaluasi penggunaan GitHub Copilot pada kumpulan data masalah pemrograman (LeetCode) [ 10 ]. Koreksi respons yang dihasilkan oleh Copilot dinilai menggunakan rangkaian pengujian milik kumpulan data itu sendiri. Selain itu, penulis mengevaluasi metrik kualitas kode, seperti kompleksitas siklomatik. Mastropaolo dan rekannya menilai ketahanan kode yang dihasilkan oleh GitHub Copilot [ 17 ]. Perbandingan mereka melibatkan dua skenario: pembuatan kode dari komentar JavaDoc dan versi komentar tersebut yang dimodifikasi secara semantik. Dalam sampel 892 metode dari proyek Java, rekomendasi yang dihasilkan oleh ChatGPT berbeda dalam hampir setengah pengujian, yang menunjukkan sensitivitas alat tersebut terhadap perintah yang diberikan sebagai masukan.

Dalam posting blog baru-baru ini, Guo mengeksplorasi kelebihan dan keterbatasan ChatGPT dalam tugas pemrograman yang kompleks [ 18 ]. Seperti dalam penelitian kami, ia menyoroti perlunya bimbingan manusia dan perlunya keahlian dan pendidikan sebelumnya dalam Rekayasa Perangkat Lunak untuk penggunaan alat yang efektif. Dakhel dan rekan-rekannya meneliti kemanjuran GitHub Copilot dalam menghasilkan solusi untuk masalah inti Ilmu Komputer [ 9 ]. Mereka membandingkan solusi Copilot dengan solusi yang dihasilkan oleh programmer manusia dan menemukan bahwa, sementara Copilot menghasilkan solusi untuk sebagian besar masalah, solusi tersebut menunjukkan lebih banyak bug dibandingkan dengan solusi manusia.

5.2 Pemeliharaan dan Pengujian Perangkat Lunak
Sobani dan rekan-rekannya mengevaluasi kinerja ChatGPT dalam perbaikan bug, menggunakan kumpulan data yang umum digunakan dalam bidang ini (QuixBugs) [ 1 ]. Para penulis menyimpulkan bahwa kinerja sistem jauh lebih baik daripada pendekatan lain yang diusulkan dalam literatur. Secara khusus, ChatGPT mampu memperbaiki 31 dari 40 bug yang dievaluasi dalam penelitian tersebut. Di sisi lain, Siddiq dan rekan-rekannya melaporkan hasil yang kurang menjanjikan terkait penggunaan ChatGPT untuk mengimplementasikan pengujian unit [ 3 ]. Faktanya, dalam kumpulan data pertama, cakupan pernyataan dari pengujian yang dihasilkan secara otomatis bagus (80%). Namun, dalam kumpulan data kedua, hasilnya lebih buruk (cakupan hanya 2%). Para penulis juga melaporkan bahwa pengujian yang dihasilkan memiliki beberapa bau, seperti Duplicate Asserts dan Empty Tests.

Asare, Nagappan, dan Asokan mengevaluasi apakah kode yang dihasilkan oleh GitHub Copilot memiliki kelemahan keamanan yang sama dengan kode yang ditulis oleh pengembang [ 19 ]. Kesimpulannya adalah bahwa dalam 33% kasus, Copilot pada dasarnya mereplikasi kerentanan yang ada dalam kumpulan data sistem C dan C++. Pearce dan rekannya mengeksplorasi implikasi keamanan dari kode yang dihasilkan oleh GitHub Copilot [ 20 ]. Para penulis mengevaluasi kinerja Copilot di tiga dimensi pembuatan kode, khususnya menilai kemampuannya dalam mengatasi berbagai kelemahan, perintah, dan domain. Analisis mereka mencakup 1.692 program yang dihasilkan oleh Copilot, mengungkapkan bahwa sekitar 40% di antaranya menunjukkan kerentanan.

Insinyur perangkat lunak Meta melakukan studi dengan menggunakan alat TestGen-LLM [ 21 ]. Alat ini secara otomatis menyempurnakan pengujian yang telah ada sebelumnya yang ditulis manusia untuk platform Instagram dan Facebook menggunakan Model Bahasa. Hasilnya menunjukkan bahwa 11,5% dari semua kelas pengujian yang diperluas oleh TestGen-LLM memiliki pengujian yang lebih baik. Selain itu, 73% rekomendasi yang dihasilkan oleh TestGen-LLM diterima oleh insinyur perangkat lunak Meta untuk diimplementasikan di lingkungan produksi.

Almeida et al. [ 8 ] mengeksplorasi penggunaan ChatGPT untuk membantu migrasi API. Khususnya, mereka menggunakan ChatGPT untuk memigrasikan aplikasi klien ke versi SQLAlchemy yang lebih baru, ORM Python yang populer. Tiga jenis prompt—Zero-Shot, One-Shot, dan Chain of Thoughts—dievaluasi, dengan One-Shot memberikan hasil terbaik. Dengan menggunakan jenis prompt ini, semua kolom berhasil dimigrasikan, dan aplikasi ditingkatkan untuk memanfaatkan fitur SQLAlchemy baru seperti asyncio dan pengetikan, sambil mempertahankan perilaku aslinya. Silva et al. [ 7 ] menilai efektivitas ChatGPT dalam mendeteksi code smells dalam proyek Java, dengan fokus pada Blob, Data Class, Feature Envy, dan Long Method di tiga tingkat keparahan. Dua prompt—yang generik dan yang spesifik—diuji, dengan hasil yang menunjukkan bahwa prompt spesifik meningkatkan akurasi sebanyak 2,54 kali. ChatGPT berkinerja lebih baik pada bau kritis (F-ukuran = 0,52) daripada bau minor (F-ukuran = 0,43).

6 Kesimpulan
Model bahasa digunakan secara luas oleh para insinyur perangkat lunak. Oleh karena itu, dalam artikel ini, kami mulai dengan menyelidiki penggunaan ChatGPT untuk membuat aplikasi Web kecil oleh pengguna dengan pengalaman terbatas dalam pengembangan perangkat lunak. Kami menyimpulkan bahwa antarmuka GPT standar tidak dirancang khusus untuk menangani tugas ini. Karena alasan ini, kami mengusulkan, merancang, dan menerapkan antarmuka baru untuk menggunakan model bahasa, yang memberikan pengalaman yang lebih ramah pengguna untuk membangun aplikasi Web. Antarmuka baru ini, yang kami sebut NoCodeGPT, merangkum seluruh pertukaran perintah dengan model AI. Hasilnya, pengguna tidak perlu lagi menulis perintah yang terkait dengan teknologi dan pola arsitektur atau menyalin file ke folder lokal masing-masing. Kami juga melakukan eksperimen terkontrol dengan 14 siswa yang masih pemula dalam pengembangan Web. Hasilnya memberikan bukti yang meyakinkan bahwa alat yang diusulkan memang lebih unggul daripada antarmuka ChatGPT standar, membantu pengembang yang tidak berpengalaman membangun aplikasi Web kecil tanpa menulis kode. Misalnya, lebih dari separuh peserta (9 dari 14) berhasil menyelesaikan aplikasi yang diusulkan, sementara yang lain menyelesaikan setidaknya setengah dari cerita pengguna yang diusulkan.

Saat ini, evolusi model AI berjalan dengan kecepatan yang mengagumkan, yang mungkin menimbulkan pertanyaan tentang keawetan wrapper seperti NoCodeGPT. Namun, kami yakin bahwa kontribusi utama kami adalah menunjukkan bahwa pengembangan perangkat lunak berbantuan AI memerlukan tugas-tugas mendasar tertentu, seperti mendefinisikan arsitektur, menyimpan file dalam direktori yang benar yang ditentukan oleh arsitektur tersebut, menjalankan sistem untuk pengujian, dan dengan cepat kembali ke versi sebelumnya jika terjadi halusinasi model. Masalah dan tugas ini tetap independen dari kemajuan model AI, memastikan bahwa masalah dan tugas tersebut akan terus relevan dalam pengembangan aplikasi perangkat lunak menyeluruh yang didukung oleh model bahasa.

Sebagai pekerjaan di masa mendatang, kami bermaksud mengevaluasi penggunaan antarmuka kami dengan lebih banyak aplikasi dan lebih banyak pengembang. Kami juga berencana untuk membuatnya kompatibel dengan model bahasa lain, termasuk model sumber terbuka. Kami juga bermaksud untuk menyelidiki konstruksi jenis aplikasi baru, seperti aplikasi seluler. Terakhir, kami juga berencana untuk menyelidiki mekanisme lain untuk mengendalikan dan mencegah halusinasi selain mekanisme rollback yang saat ini diterapkan oleh NoCodeGPT.