Go dan TypeScript: Strict Type untuk Coding dengan AI

Dua artikel muncul di feed saya berselang sekitar seminggu dan menyampaikan argumen yang sama dari dua ujung spektrum bahasa. Tim Go dari Google menulis bahwa Go adalah bahasa ideal untuk software engineering berbantuan AI; beberapa bulan sebelumnya Pierre-Marie Dartus menulis bahwa TypeScript diam-diam melakukan tugas yang sama untuk dunia JavaScript. Saya sudah merasakannya tanpa bisa menamainya: agent saya menyelesaikan task Go dan TypeScript dengan jauh lebih sedikit tuntunan dibanding di codebase yang loosely typed.

Tulisan ini soal kenapa itu terjadi, dan di mana klaimnya runtuh. Saya membangun sistem ERP dengan TypeScript dan NestJS serta memakai Go di sisi infrastruktur, jadi yang berikut adalah pembacaan seorang developer atas dua esai yang kuat, satu benchmark peer-reviewed, dan satu studi soal type-constrained code generation — bukan perang bahasa. Saya juga menampilkan hasil benchmark yang justru membantah judulnya, karena bagian itulah yang paling berguna.

AI menggeser pekerjaan dari menulis kode ke mereviewnya

Pergeseran yang dijelaskan tim Go adalah dasar dari semua argumen di sini. Dulu sebagian besar baris kode ditulis dengan tangan; kini kita meminta agent menghasilkan kode dalam jumlah besar dan menghabiskan waktu kita sendiri untuk membaca, mengoreksi, dan memverifikasi hasilnya. Sumber daya yang langka bukan lagi kecepatan mengetik, melainkan kepercayaan — seberapa cepat seorang manusia, atau agent berikutnya, bisa yakin bahwa sebuah perubahan aman untuk dirilis.

Itu mengubah makna sebuah bahasa. Bahasa yang dioptimasi untuk writability — ringkas, pintar, banyak cara untuk satu hal — diasah untuk bagian yang kini dikerjakan mesin. Bahasa yang dioptimasi untuk readability dan verifikasi diasah untuk bagian yang tiba-tiba menjadi seluruh pekerjaan. Go dirancang untuk software engineering di atas programming, dalam kata-kata timnya sendiri, dan taruhan lama itu ternyata cocok dengan kebutuhan kerja berbantuan AI.

Strict type adalah feedback loop, bukan formalitas

Mekanismenya lebih sederhana daripada marketingnya. Sebuah model memprediksi kode yang masuk akal, dan kode yang masuk akal termasuk method yang tidak pernah didefinisikan dan field yang tidak ada pada sebuah value. Di bahasa yang statically typed, compiler atau type checker menangkap persis kelas kesalahan itu, seketika, dan menyebutkannya dalam satu baris:

package main

import (
	"fmt"
	"strings"
)

func main() {
	// The model reached for a method that sounds right but was never defined.
	fmt.Println(strings.Reverse("gopher"))
}

// $ go build ./...
// ./main.go:10:26: undefined: strings.Reverse
//
// The build fails in well under a second. The agent reads that one line,
// drops the invented call, and writes the reversal by hand — before a single
// test runs, before the program is ever executed.

Satu baris itu adalah training signal gratis. Agent membaca error tersebut, menghapus pemanggilan yang dikarang, lalu mencoba lagi — sebuah self-correction loop yang berjalan di editor atau saat build, sebelum sebuah test dijalankan dan jauh sebelum kode dirilis. Studi type-constrained code generation oleh Mundler dan rekan-rekannya mengukur batas atas dari ini: membatasi generasi hanya ke program yang well-typed memangkas lebih dari separuh error kompilasi dan menaikkan functional correctness pada tugas synthesis, translation, dan repair. Dartus melaporkan hal yang sama dari pengalaman langsung — setelah memperketat type definition-nya, agent-nya menghasilkan kode yang benar dalam lebih sedikit percobaan.

Kenapa Go terbaca sama siapa pun penulisnya

Keunggulan kedua Go adalah keseragaman, dan itu disengaja. Bahasa ini menolak keajaiban sintaksis yang dirayakan bahasa lain dan menyertakan formatter, gofmt, yang memberi setiap file satu bentuk kanonis. Bagi tim manusia itu berarti lebih sedikit bikeshedding; bagi sebuah model, itu melakukan tiga hal sekaligus:

• Training data yang lebih bersih — korpus di mana kode terlihat sama tanpa peduli penulisnya mengajarkan distribusi yang lebih rapat, sehingga model mengembalikan Go yang idiomatis dalam lebih sedikit percobaan.
• Permukaan yang lebih kecil untuk dihalusinasikan — makin sedikit cara mengungkapkan satu ide, makin sedikit variasi yang masuk akal tapi salah untuk dikarang model.
• Janji kompatibilitas — kode yang ditulis untuk Go 1.0 masih bisa dibangun hari ini, dan tim sudah menutup kemungkinan Go 2.0 yang breaking, jadi agent tidak pernah menghasilkan kode untuk target yang bergerak.

Kecepatan kompilasi menutup loop-nya. Build Go cukup cepat — berkali-kali lipat lebih cepat daripada bahasa statically typed yang lebih berat, menurut Google — sehingga siklus tolak-dan-coba-lagi hanya menghabiskan satu detik agent, bukan satu jeda kopi. Sebuah feedback loop hanya membentuk perilaku kalau ia cepat; yang lambat akan dilewati.

Kenapa TypeScript membuat state mustahil tak terwakili

TypeScript sampai ke titik yang sama dari arah berlawanan: ia membungkus bahasa paling banyak dipakai di web dengan type system yang cukup presisi untuk mengkodekan maksud. Contoh paling jernih dari Dartus adalah discriminated union. Modelkan sebuah anotasi sebagai kumpulan optional field, dan agent harus menebak kombinasi mana yang sah; modelkan sebagai union dari bentuk-bentuk tetap, dan kombinasi yang tak sah cukup berhenti bisa dikompilasi.

// Wrong: optional fields let the model invent impossible states.
interface Annotation {
  kind: "highlight" | "note";
  note?: string;   // present on a note... or on a highlight? the model guesses
  quote?: string;  // and a guess is a bug you find at runtime, or never
  color?: string;
}

// Right: a discriminated union. The shape of each case is fixed.
type Annotation =
  | { kind: "highlight"; quote: string; color: string }
  | { kind: "note"; quote: string; note: string };

// Now annotation.note only type-checks after a kind === "note" guard,
// so the agent physically cannot read a field that isn't there. tsc rejects
// the parser it would otherwise have written — in the editor, before you run it.

Efek lanjutannya soal context, bukan sekadar correctness. Sebagaimana signature bertipe memungkinkan manusia bekerja pada satu file tanpa menahan seluruh sistem di kepalanya, ia memungkinkan agent bernalar atas sepotong codebase tanpa menarik seluruh proyek ke context window-nya — itu poin Dartus, dan cocok dengan cara agent yang bagus bekerja. Dua hal lain menurunkan penghalang bagi saya: versi Node terbaru melakukan type stripping secara native, jadi TypeScript berjalan tanpa langkah build terpisah, dan language server editor menyalurkan error langsung ke agent yang otomatis retry pada lint.

Standard library adalah pengaman dari dependency karangan

Import halusinasi adalah failure mode tersendiri: sebuah model dengan yakin me-require paket yang tidak ada, atau lebih buruk, paket yang sejak itu didaftarkan seorang squatter di bawah nama tebakan tersebut. Standard library yang besar dan lengkap adalah pertahanan termurah, karena ia memberi model default yang benar dan terlatih untuk kasus umum, sehingga lebih sedikit alasan meraih nama pihak ketiga yang setengah diingat.

TypeScript tidak bisa menandingi itu dari bahasanya, jadi ekosistem yang mengerjakannya — tapi tidak merata. Dartus mendapati agent kesulitan melawan sebuah parser niche dengan tiga puluh ribu unduhan mingguan dan kemungkinan besar akan mulus dengan alternatif lima puluh juta unduhan, murni karena library populer lebih terwakili dalam training data dan dokumentasi. Pelajarannya bisa dibawa ke mana saja: dengan agent AI, dependency yang membosankan, terdokumentasi baik, dan banyak dipakai bukan cuma lebih aman, tapi terukur lebih mudah dipakai model dengan benar.

Tapi typed tidak otomatis lebih baik — baca benchmark-nya

Ini bagian jujurnya. Kalau strict typing membuat model jadi coder yang lebih baik secara langsung, benchmark multibahasa pasti menunjukkannya, dan nyatanya tidak. Di Multi-SWE-bench — kumpulan isu GitHub nyata peer-reviewed di tujuh bahasa, diselesaikan oleh model dan agent framework terkuat pada 2025 — resolved rate terbaik per bahasa terlihat seperti ini:

Go di posisi terakhir bukan salah ketik, dan itulah alasan untuk tetap hati-hati. Resolved rate sekali coba didominasi oleh seberapa banyak sebuah bahasa telah dilihat model dan seberapa banyak task layak yang bisa dikumpulkan benchmark, bukan oleh seberapa strict type-nya. Python menang pada ukuran korpus; skor rendah Go mencerminkan irisan task yang lebih tipis, bukan bahasa yang lebih buruk. Yang diubah strict typing adalah hal yang nyaris tak diukur metrik ini — biaya tiap percobaan dan tiap verifikasi — yang justru biaya yang dialihkan AI kepada kita. Esai-esai dan studi type-constrained mengukur loop itu; leaderboard mengukur hal lain.

Jadi aturan yang kini saya pegang sempit dan bisa dipertahankan: bahasa yang strict dan statically typed tidak membuat AI jadi programmer yang lebih baik, tapi membuat kesalahannya lebih murah untuk ditangkap — dan di dunia di mana saya lebih banyak mereview daripada menulis, murah-untuk-ditangkap itulah yang saya beli. Pakai Go di tempat bahasa yang kecil dan compiler cepat membayar, pakai TypeScript untuk memasang pengaman pada JavaScript, dan tulis type seketat yang Anda mampu. Compiler adalah satu-satunya reviewer yang tak pernah lelah.