Jangkaan lawan realiti, dan bagaimana beberapa percubaan yang tidak menjadi akhirnya membawa kepada satu susunan yang benar-benar berfungsi.
Saya tidak merancang susunan ini dari awal, sebaliknya ia terbentuk sedikit demi sedikit selepas beberapa kali mencuba membiarkan agen AI bekerja pada projek yang berada di PC Windows saya. Pada mulanya saya menjangka prosesnya agak mudah: beri AI akses kepada projek, terangkan apa yang saya mahu, kemudian biarkan ia menulis kod, menjalankan ujian dan membetulkan masalah sendiri. Dalam praktiknya, beberapa bahagian tidak berjalan seperti yang saya jangka, khususnya apabila AI perlu berinteraksi dengan PC sebenar, jadi saya terus mengubah aliran kerja (workflow) sehingga akhirnya mendapat satu susunan yang cukup stabil untuk digunakan setiap hari.
Cara saya mengekod memang agak berbeza daripada cara biasa seorang pembangun perisian bekerja. Saya lebih suka menerangkan fungsi atau hasil yang saya mahu dalam bahasa biasa, kemudian membiarkan AI memahami projek, membuat perubahan, menjalankan ujian dan membetulkan apa-apa yang gagal sehingga aplikasi berfungsi seperti yang diminta. Oleh sebab saya hampir tidak membaca kod yang dihasilkan, perkara yang paling penting bagi saya bukanlah bagaimana kod itu ditulis, tetapi sama ada aplikasi tersebut benar-benar berjalan, ujian lulus dan perubahan boleh dipulihkan jika sesuatu berlaku.
Pendekatan seperti ini sekarang sering dipanggil vibe programming, tetapi artikel ini bukan sangat tentang bagaimana menulis arahan kepada AI. Saya lebih berminat pada bahagian yang biasanya tidak kelihatan, iaitu bagaimana AI itu sebenarnya menjalankan dan menguji kod pada komputer sebenar, kerana di situlah saya mendapati bahawa kaedah yang nampak paling canggih tidak semestinya menjadi kaedah yang paling boleh dipercayai.
Masalah asas: AI dan PC saya bukan mesin yang sama
AI yang saya gunakan bekerja dalam persekitaran awannya sendiri (cloud environment), iaitu satu mesin Linux yang mempunyai salinan projek saya. Dalam persekitaran itu, AI boleh menyunting fail, menjalankan Python, melakukan ujian, membuka pelayar tanpa paparan (headless browser) dan membaca hasilnya dengan agak cepat, jadi untuk sebahagian besar kerja pembangunan, persekitaran ini memang berguna.
Masalahnya ialah projek sebenar tetap berada di PC Windows saya, dan kedua-dua persekitaran itu tidak semestinya sama. Versi Python boleh berbeza, pakej yang dipasang juga boleh berbeza, sistem fail Windows mengurus laluan dan penamat baris (line ending) secara berbeza daripada Linux, manakala sesetengah projek pula bergantung pada pangkalan data (database), fail atau perkhidmatan tempatan yang hanya wujud pada PC tersebut.
Akibatnya, ujian yang lulus di awan belum tentu lulus di Windows. Dalam projek saya sendiri, keadaan ini memang pernah berlaku beberapa kali, termasuk disebabkan perbezaan kecil antara versi Python yang pada awalnya tidak kelihatan penting. Oleh sebab itu, walaupun AI boleh melakukan banyak ujian dengan pantas di awan, saya masih memerlukan satu cara untuk mengesahkan hasil akhir pada mesin Windows yang sebenar.
Percubaan pertama: saya sendiri yang menjalankan arahan
Pada peringkat awal, penyelesaiannya sangat mudah tetapi juga sangat manual. AI akan membuat perubahan pada projek, kemudian memberitahu saya arahan yang perlu dijalankan; saya pula akan membuka PC, menjalankan arahan tersebut dan memberikan hasilnya semula kepada AI supaya ia boleh meneruskan proses membaiki kod.
Cara ini memang berfungsi, tetapi selepas beberapa ketika saya mula nampak masalahnya. Sekiranya AI memerlukan lapan percubaan untuk membetulkan satu pepijat (bug), saya juga perlu berada di situ lapan kali untuk menjalankan arahan dan menyampaikan hasilnya semula. Jadi walaupun AI yang menulis kebanyakan kod, saya masih menjadi sebahagian daripada setiap kitaran ujian, sedangkan tujuan asal saya ialah mahu menyerahkan sebahagian besar proses itu kepada AI.
Dalam keadaan tersebut, saya bukan sekadar memberi arahan kepada AI; secara praktikalnya saya sudah menjadi tangan yang menekan butang untuknya, dan itu jelas bukan pengalaman vibe programming yang saya mahukan.
Percubaan kedua: biar AI mengawal PC
Langkah seterusnya nampak lebih menjanjikan, iaitu menggunakan fungsi kawalan komputer (computer use). Saya menyediakan fail BAT yang boleh melancarkan ujian atau aplikasi di Windows, kemudian membiarkan AI mengawal desktop dan mengklik fail tersebut apabila ia mahu menjalankan ujian. Secara teori, ini sepatutnya mengeluarkan saya daripada kitaran tersebut kerana AI sudah boleh mencetuskan ujian sendiri.
Namun selepas digunakan beberapa kali, masalah yang paling kerap muncul ialah fokus tetingkap (window focus). Kadang-kadang ada tetingkap lain yang menjadi aktif sesaat sebelum AI mengklik, sama ada kerana pemberitahuan, kotak dialog, aplikasi yang baru dibuka ataupun proses lain yang mengambil fokus. Bila itu berlaku, AI boleh mengklik tempat yang salah, gagal melancarkan fail BAT atau berinteraksi dengan tetingkap yang tidak sepatutnya.
Akhirnya saya masih perlu masuk secara jauh (remote) ke PC dan mengklik fail tersebut sendiri, jadi aliran kerja yang pada asalnya:
AI minta saya jalankan sesuatu
↓
saya jalankan secara manual
berubah menjadi:
AI cuba klik fail BAT
↓
tetingkap lain mengambil fokus
↓
klik gagal
↓
saya masuk secara jauh ke PC
↓
saya klik sendiri
Malah, cara kedua kadang-kadang terasa lebih menjengkelkan kerana kegagalannya tidak menentu. Kalau proses manual, sekurang-kurangnya saya tahu saya memang perlu menjalankan arahan; tetapi dengan kawalan komputer, saya tidak tahu sama ada semuanya akan berjalan sendiri atau saya akan terpaksa masuk campur beberapa minit kemudian.
Daripada situ saya mula sedar bahawa masalah sebenarnya bukan pada fail BAT, tetapi pada cara ia dicetuskan. Saya sedang menggunakan kawalan desktop secara visual untuk melakukan sesuatu yang pada asasnya sangat mudah dan sepatutnya boleh dibuat secara terus. AI tidak perlu tahu di mana fail BAT berada pada skrin, tidak perlu menggerakkan tetikus dan tidak perlu peduli tetingkap mana yang sedang aktif; ia cuma memerlukan satu cara yang konsisten untuk memberitahu Windows bahawa satu tindakan tertentu perlu dijalankan.
Di situlah idea pemantau (watcher) mula masuk akal.
Pemantau (Watcher): guna fail sebagai isyarat
Pemantau yang saya gunakan hanyalah sebuah program Python kecil yang berjalan secara berterusan di PC. Tugasnya sengaja dibuat mudah kerana saya tidak mahu menambah satu lagi lapisan yang terlalu rumit ke dalam sistem.
Setiap beberapa saat, pemantau memeriksa sebuah fail arahan dalam folder projek yang sudah saya benarkan untuk diakses oleh AI. Apabila kandungan fail itu berubah, pemantau akan membaca arahan tersebut, menyemak sama ada tindakan yang diminta berada dalam senarai yang dibenarkan (whitelist), kemudian menjalankan arahan yang sepadan secara tempatan di Windows. Hasil pelaksanaan seperti stdout, stderr dan kod keluar (exit code) pula disimpan ke dalam fail keputusan yang boleh dibaca semula oleh AI.
Dengan cara ini, aliran kerja menjadi:
AI menyunting projek
↓
AI menulis arahan
↓
pemantau mengesan arahan baharu
↓
Windows menjalankan ujian
↓
pemantau menyimpan hasil + kod keluar
↓
AI membaca hasil
↓
AI membetulkan masalah jika perlu
↓
ulang
Perbezaannya nampak kecil, tetapi dari sudut praktikal ia sangat besar kerana tiada lagi tetikus, tiada isu fokus tetingkap dan tidak penting apa yang sedang terbuka di skrin. Selagi pemantau berjalan dan fail arahan boleh dicapai, AI mempunyai satu laluan yang konsisten untuk meminta Windows menjalankan sesuatu.
Selepas itu barulah proses vibe programming mula terasa seperti yang saya mahukan. Dalam beberapa versi projek terbaru, AI boleh melalui banyak kitaran sunting–uji–baiki, menjalankan suite ujian penuh (full test suite) di Windows, membaca kegagalan, membuat pembetulan dan akhirnya membuat commit Git tanpa saya perlu berada di depan PC.
Dua peringkat ujian, tetapi PC tetap menjadi sumber rujukan utama
Walaupun pemantau membolehkan AI menjalankan ujian pada Windows sebenar, saya tidak membuang persekitaran awan kerana ia masih sangat berguna untuk kerja yang pantas. Sebaliknya, saya menggunakan kedua-duanya untuk tujuan yang sedikit berbeza.
AI melakukan kebanyakan perubahan dan ujian awal pada salinan di awan kerana proses itu lebih cepat dan tidak perlu melalui PC bagi setiap perubahan kecil. Selepas kod nampak stabil, barulah ia menghantar perubahan tersebut ke PC dan menjalankan pengesahan dalam persekitaran Windows sebenar.
Secara mudah, prosesnya ialah:
Ujian pantas di awan
↓
Pengesahan pada Windows sebenar
Namun walaupun terdapat dua salinan projek semasa kerja sedang berjalan, versi di PC sentiasa menjadi sumber rujukan utama (source of truth). Pada permulaan setiap sesi, AI akan menyemak keadaan projek di PC dahulu dan memastikan salinan di awan sepadan dengan versi sebenar. Jika terdapat perbezaan, salinan awan akan dikemas kini daripada PC sebelum sebarang kerja baharu dimulakan.
Apabila kerja selesai, proses bergerak ke arah yang sebaliknya. Fail akhir dihantar kembali ke PC, diuji semula dalam Windows, kemudian versi yang sudah disahkan itu disimpan dalam Git tempatan. Dengan itu, projek sentiasa bermula daripada keadaan PC yang diketahui dan berakhir semula pada PC selepas semua perubahan disahkan.
versi di PC
↓
AI semak dan selaraskan
↓
AI bekerja pada salinan di awan
↓
perubahan akhir dihantar ke PC
↓
Windows menguji semula
↓
PC menjadi versi akhir yang disahkan
Langkah semakan pada awal sesi ini bukan sekadar langkah tambahan untuk nampak kemas. Salinan di awan pernah kembali kepada versi lama tanpa disedari, dan dalam keadaan seperti itu AI boleh kelihatan yakin bahawa ia sedang mengubah versi terbaru sedangkan sebenarnya ia bekerja pada salinan yang sudah tertinggal. Selepas perkara itu berlaku beberapa kali, saya tambah pemeriksaan keadaan projek supaya sebarang perbezaan boleh dikesan sebelum AI mula menyentuh kod.
Dengan cara itu, salinan di awan kekal sebagai ruang kerja sementara sahaja, manakala PC sentiasa menjadi tempat projek sebenar bermula dan berakhir.
Beberapa penambahbaikan selepas pemantau mula stabil
Selepas susunan asas ini berjalan dengan baik, saya tidak banyak mengubah konsepnya kerana saya lebih suka memperbaiki perkara yang benar-benar menjadi halangan. Beberapa penambahbaikan kecil kemudian memberi kesan yang agak besar kepada kelajuan keseluruhan proses.
Ujian sasaran di Windows
Pada mulanya, satu-satunya pilihan di PC ialah menjalankan keseluruhan suite ujian, yang mengambil masa sekitar 14 minit. Untuk pengesahan akhir, masa itu masih boleh diterima, tetapi apabila terdapat pepijat yang hanya muncul di Windows, setiap percubaan menjadi terlalu lama kerana AI terpaksa menunggu keseluruhan suite walaupun ia hanya mahu menguji satu bahagian kecil.
Kemudian saya tambah satu mod yang membolehkan AI menjalankan ujian tertentu sahaja, atau ujian sasaran (targeted test). Selepas itu, masalah yang sebelum ini mungkin memerlukan 14 minit untuk diuji boleh diperiksa dalam beberapa saat sahaja. Salah satu ujian awal menggunakan mod ini terus menemui masalah khusus Windows berkaitan cara sistem operasi mengendalikan penamat baris (line ending), dan perkara seperti ini menunjukkan kenapa pengesahan pada mesin sebenar tetap penting walaupun ujian di awan sudah lulus.
Suite ujian penuh secara selari
PC saya mempunyai banyak teras CPU, tetapi pada asalnya semua ujian dijalankan satu demi satu, jadi banyak keupayaan mesin tidak digunakan. Selepas ujian dijalankan secara selari (parallel), masa suite penuh turun daripada kira-kira 14 minit kepada sekitar 3 minit.
Ada sedikit pelarasan yang perlu dibuat kerana sesetengah ujian bergantung pada turutan dalam fail yang sama, tetapi selepas perkara itu diselesaikan, masa menunggu bagi pengesahan akhir menjadi jauh lebih pendek tanpa perlu mengubah keseluruhan reka bentuk sistem.
Beberapa arahan dalam satu permintaan
Pemantau juga sebenarnya boleh menerima beberapa arahan dalam satu fail dan menjalankannya secara berturutan. Oleh itu, kerja seperti membina manual, menjalankan suite ujian penuh dan membuat commit tidak perlu dihantar sebagai tiga pusingan berasingan; AI boleh memasukkan semuanya dalam satu permintaan dan membiarkan pemantau menjalankannya mengikut turutan.
Penambahbaikan ini nampak kecil, tetapi apabila AI melakukan banyak kitaran kerja secara autonomi, pengurangan beberapa pusingan komunikasi seperti ini membantu menjadikan keseluruhan proses lebih lancar.
Git tempatan sebagai jaring keselamatan
Bahagian kedua yang menjadi penting selepas AI mula bekerja dengan lebih autonomi ialah Git. Saya menggunakan Git secara tempatan di PC dan, untuk tujuan aliran kerja ini, saya tidak memerlukan GitHub kerana apa yang saya perlukan hanyalah kawalan versi (version control), sejarah perubahan dan cara untuk kembali kepada keadaan yang diketahui berfungsi.
Bila AI dibenarkan mengubah banyak fail tanpa saya membaca setiap baris kod, saya mahu setiap versi yang stabil boleh dipulihkan. Kalau perubahan terbaru menimbulkan masalah, versi sebelumnya masih ada, saya boleh melihat sejarahnya, membandingkan perubahan atau kembali kepada versi yang memang sudah diuji dan diketahui berfungsi.
Bagi saya, fungsi Git dalam susunan ini hampir sama penting dengan fungsi ujian. Ujian membantu menentukan sama ada perubahan itu berfungsi, manakala Git memastikan saya tidak terperangkap jika satu perubahan yang nampak baik kemudian menimbulkan masalah lain.
AI juga boleh melakukan operasi Git melalui pemantau yang sama. Apabila satu unit kerja selesai dan ujian lulus, AI boleh membuat commit secara automatik, jadi sejarah projek dibina mengikut perubahan yang sudah disahkan dan tidak perlu menunggu sehingga hujung sesi apabila konteks tentang apa yang berubah mungkin sudah hilang.
Tentang keselamatan
Apabila sistem ini mula menjadi semakin autonomi, saya juga cuba memahami dengan jelas apa yang sebenarnya membataskan akses AI pada PC. Dalam keadaan biasa, AI tidak mempunyai akses terus kepada baris arahan Windows (Windows shell), sebaliknya ia hanya boleh membaca dan menulis dalam folder yang saya sudah benarkan, manakala pemantau pula hanya mengenali tindakan yang sudah dimasukkan dalam senarai yang dibenarkan.
Susunan ini memberikan satu tahap kawalan yang munasabah untuk projek peribadi kerana AI tidak mempunyai akses bebas kepada seluruh mesin melalui aliran kerja biasa. Walau bagaimanapun, saya juga tidak menganggap senarai yang dibenarkan itu sebagai sempadan keselamatan (security boundary) yang mutlak, kerana sesetengah skrip yang terlibat dalam aliran pelaksanaan masih berada dalam kawasan yang boleh disunting oleh AI.
Jadi saya lebih melihat mekanisme tersebut sebagai kawalan operasi (operational guardrail) berbanding kotak pasir keselamatan (security sandbox) yang benar-benar keras. Untuk kegunaan di rumah, tahap ini memadai bagi saya kerana saya faham apa yang dilindungi dan apa yang tidak, dan bagi saya itu lebih baik daripada menganggap sistem tersebut mempunyai perlindungan yang sebenarnya tidak wujud.
Adakah saya akan terus guna susunan ini?
Buat masa ini, ya, kerana pemantau menyelesaikan masalah yang memang saya hadapi setiap hari, iaitu bagaimana membenarkan AI menguji sesuatu pada Windows sebenar tanpa bergantung pada saya atau pada kawalan desktop yang kadang-kadang gagal.
Mungkin pada masa akan datang, agen AI yang berjalan terus pada PC boleh memberikan pengalaman yang sama mudah tanpa memerlukan penghubung (bridge) tambahan seperti ini. Jika sampai satu tahap di mana AI boleh bekerja terus pada mesin dengan stabil, selamat dan tanpa saya perlu mengurus terminal atau kebenaran berkali-kali, sebahagian daripada susunan ini mungkin tidak lagi diperlukan.
Namun buat masa sekarang, susunan yang saya ada memberi keseimbangan yang sesuai dengan cara saya mahu bekerja:
AI untuk mengekod pemantau untuk menjalankan Git untuk keselamatan PC sebagai sumber rujukan utama
Lebih penting daripada semua itu, saya tidak perlu berada di depan komputer setiap kali AI mahu mencuba satu perubahan, menjalankan ujian atau membetulkan kesilapan yang baru ditemui.
Susunan akhir
Secara keseluruhan, aliran kerja saya sekarang lebih kurang begini:
Saya
↓
terangkan apa yang saya mahu
↓
agen AI
↓
semak versi terkini di PC
↓
salinan di awan untuk kerja dan ujian pantas
↓
perubahan dihantar ke folder projek di PC
↓
pemantau tempatan
↓
Windows menjalankan ujian sasaran / suite penuh / Git
↓
hasil dan kod keluar disimpan
↓
AI membaca hasil, membaiki dan mengulangi jika perlu
↓
perubahan akhir disahkan pada Windows
↓
Git tempatan menyimpan versi yang stabil
Kalau dilihat semula, susunan ini sebenarnya lahir daripada satu siri percubaan yang sangat biasa. Saya bermula dengan menjalankan arahan secara manual, kemudian cuba membiarkan AI mengklik fail BAT melalui kawalan komputer, dan apabila masalah fokus tetingkap menyebabkan saya masih perlu masuk secara jauh ke PC, saya mula mencari cara yang lebih mudah untuk menghubungkan AI dengan Windows.
Pemantau akhirnya menyelesaikan masalah itu dengan cara yang jauh lebih biasa dan kurang menarik dari sudut teknologi, tetapi lebih konsisten untuk digunakan. Daripada bergantung pada interaksi visual, AI hanya menulis satu arahan ke dalam fail, Windows menjalankannya, hasil disimpan, kemudian AI membaca semula keputusan tersebut dan meneruskan kerja.
Pada akhirnya, perubahan yang paling berguna bukanlah memberikan AI lebih banyak kawalan terhadap komputer, tetapi memberikan AI satu saluran yang kecil dan boleh dijangka untuk melakukan perkara yang memang diperlukan. Untuk cara saya menggunakan vibe programming, itu sudah cukup untuk menjadikan proses yang pada mulanya memerlukan banyak campur tangan manual berubah menjadi satu aliran kerja yang hampir sepenuhnya boleh berjalan sendiri.
