1 poin oleh soliestre 7 jam lalu | Belum ada komentar. | Bagikan ke WhatsApp

Ada satu hal yang terus mengganjal saat menyuruh AI menulis kode. Kode hasil akhirnya memang tertinggal, tetapi percakapan dan niat yang melahirkan kode itu hilang. Tiga bulan kemudian, tidak ada tempat untuk bertanya, "Kenapa kode ini jadi seperti ini?"

Jadi saya membalik arahnya. Saya meng-commit spesifikasi yang memuat niat ke git, dan memperlakukan kode sebagai artefak hasil build. Sebagai pembuktian, saya membuat satu aplikasi kecil sampai tuntas dan merilisnya.

Ini adalah PWA bernama Rimlog, di mana AI menyambungkan catatan lama ke catatan baca dan belajar. Tanpa server, tanpa pendaftaran, dan data hanya ada di browser.

Aplikasinya biasa saja. Yang ingin saya bagikan adalah cara pembuatannya.

Cara

Di folder eux/ pada repo ada 3 lembar spesifikasi berbahasa Korea. Seluruh kerangka aplikasi hanya 40 baris, widget kartu AI 25 baris, dan server insight satu lembar. Isinya berupa kalimat-kalimat seperti ini.

saveCapture : simpan form capture (nama sumber·kutipan·pemikiran saya·tag) — sisipkan di paling depan captures + terapkan ke local storage + toast "Tersimpan" + pindah ke tab catatan.

Jika file ini dimasukkan ke alat bernama EstreUX, kode akan dihasilkan (saya menyebutnya brew). Kode yang dihasilkan akan diberi hash dari spesifikasi, dan jika hanya spesifikasi yang diubah atau hanya kodenya yang diubah, commit akan diblokir di pre-commit. Ini adalah cara memblokir lewat gate masalah ketika spesifikasi menjadi usang dan berubah menjadi kebohongan.

Saya juga mengukurnya dengan angka. Dengan mengukur ulang keypad angka 152 baris yang awalnya ada di framework menjadi spesifikasi 28 baris, jumlah baris yang harus dipelihara manusia berkurang 60–82%. Kode hasil generate sendiri kadang menjadi lebih panjang daripada aslinya. Yang berkurang adalah bagian yang harus dibaca dan diubah manusia. Catatan pengukuran ada di repo.

Server juga hanya satu lembar spesifikasi

Demo Pages bersifat serverless, jadi AI hanya berjalan dengan fallback tumpang tindih tag. Agar berjalan dengan benar, saya menambahkan server self-host, dan ini juga merupakan file tunggal node tanpa dependensi 0 yang di-brew dari satu lembar spesifikasi. Backend-nya bisa dipilih.

  • nvidia (default): API gratis dari build.nvidia.com. Memberi key tanpa perlu kartu, sekitar 40 kali per menit dengan kompatibilitas OpenAI, jadi cukup longgar untuk jurnal pribadi
  • claude-cli / codex-cli: untuk tiap permintaan memanggil claude -p / codex exec sebagai child process. Ini adalah jalur untuk memanfaatkan kembali langganan Claude/ChatGPT yang sudah dibayar tanpa API key
  • openai / google: sekadar proxy key

Key dan autentikasi hanya ada di server dan tidak keluar ke browser.

Hal-hal yang masih belum saya yakini

Saya sedang memperluas penilaian konsistensi spesifikasi↔kode dari static diff ke pemeriksaan dinamis berbasis property, tetapi kalibrasi bobotnya masih belum selesai. Selain itu, saya menemukan kelas false positive di mana render framework pada lingkungan DOM headless berjalan berbeda dari browser sungguhan, jadi menaikkan lingkungan verifikasi ke browser sungguhan juga menjadi PR. Jika melihat riwayat commit dari awal, proses scaffold→spesifikasi→generate→perapian terekam berurutan.

Ada dua hal yang ingin saya tanyakan. Menurut Anda, apa jebakan dari pendekatan menempatkan spesifikasi sebagai SSoT? Secara khusus, saya ingin tahu di titik mana Anda pernah menemui ekspresivitas spesifikasi yang tidak mampu mengikuti kode. Dan untuk jalur pemanfaatan ulang langganan dengan memakai claude -p sebagai backend aplikasi, adakah hal yang kemungkinan akan menjadi masalah dalam penggunaan nyata (dari sudut pandang rate, ketentuan layanan, dan latensi)?

Belum ada komentar.

Belum ada komentar.