Saka mlaku nganti nyerah: Proses pangembangan Cloud Agent V1 – Wuyue

Vibe Coding, miwiti

Ing Januari 2026, aku weruh akeh pengalaman nuduhake babagan Vibe Coding ing macem-macem SNS. Aku wis nangani sawetara skenario AIGC ing perusahaan sadurunge, lan wis sinau babagan alat kayata kursor lan copliot, nanging aku ora Care babagan ing kawitan. Nanging nalika aku ndeleng wong ngomong, “Ngembangake 10 agen bebarengan – 5 kanggo coding, 3 kanggo testing, 1 kanggo ringkesan karya, 1 kanggo nulis dokumen, mulih saka metu saka karya, turu, lan teka ing perusahaan dina sabanjuré kanggo nulis kode, nyoba lan online”, aku isih rada kaget. Apa kemampuan AI Coding berkembang nganti saiki? Minangka adopter awal, Aku diinstal Trae lan supaya njupuk liwat aplikasi cilik aku nulis ing kalodhangan. Efek kasebut cukup apik lan sumilir.

Nalika karya wiwit mengko ing taun, Aku nyoba kanggo nggunakake Trae kanggo nangani syarat mentas diparengake lan nulis kode. Nanging, sadurunge proyek kasebut diwiwiti, perusahaan ngatur tugas riset – kepiye ngetrapake asisten AI ing bidang finansial? Aku uga ngetutake tren lan nginstal Claude Code, disambungake menyang model glm-5, lan miwiti nulis kode.

Pengalaman pisanan karo Vibe Coding

Kepiye carane nggawe Agen saka awal liwat Vibe Coding? Aku mung duwe pangerten entheng babagan LLM lan Agen sadurunge, lan ora duwe latar mburi teknis sing relevan. Nanging, amarga Vibe Coding misuwur banget ing SNS lan digabungake karo budidaya lobster ing wektu iki, aku mesthi yakin.

Proses pembangunan iku prasaja:

• Mbukak produk pathokan, ngalami interaksi pisanan, banjur ngomong Claude Code: “Aku pengin duwe fungsi XXX, fungsi iki mbutuhake XXX” / “Layout kaca punika XXXXX” lan sateruse.

• Ngenteni Claude Code nulis kode

• Aku miwiti server lan dites. Yen aku nemokake kewan omo, aku njaluk Claude Code kanggo terus nggawe owah-owahan.

• Lan sateruse.

Ora nggumunake, kita nemoni akeh masalah:

• Ngganti interaksi front-end banget wektu. Sawise kabeh, aku teka saka latar mburi mburi lan ora ngerti akeh babagan ngarep.

• Butuh wektu suwe kanggo ndandani bug sing padha bola-bali. Kadhangkala kedadeyan: bug1 didandani sawise sedina, lan bug2 didandani. Sawise bug2 didandani, bug1 muncul maneh.

• watesan saiki model gedhe. Sanajan minangka rencana coding sing diwenehake dening perusahaan, nanging isih mbatesi aliran saiki yen digunakake banget.

Nanging cukup aneh, kanggo kabeh rintangan, Vibe Coding bisa gawe ketagihan. Sawise sampeyan miwiti nulis kode, sampeyan ora bisa mandheg. Iku kaya raos nuduhake bakat nalika sampeyan mung lulus-mbuwang gagasan kanggo AI lan nonton kode tuwuh ing ngarepe sampeyan. Umpan balik cepet banget gawe ketagihan sing game malah ora muni apik maneh.

V1: Mlayu liwat, nanging ora bisa mlaku maneh

Sawise eksplorasi lan eksperimen, Agen kasebut bener-bener ditulis, yaiku Cloud Agent V1. Iku dibangun nggunakake Python FastAPI, kang njupuk 6 minggu, 170 commits (multiple squashes, bener luwih), bab 17.000 baris kode, Vibe Coding murni, lan ora siji baris kode tulisan tangan. Inti saka V1 yaiku LLM ngasilake skrip Python kanthi tag XML, sing dieksekusi ing lingkungan kothak wedhi sawise parsing biasa. Bisa ngobrol, ngoperasikake file, nglakokake skrip, mbukak Skills, lan nelpon MCP, lan wis mbukak link lengkap. Macem-macem demonstrasi produk ing wulan Maret didhukung, nanging sadurunge saben demonstrasi, aku ngalahake drum ing atiku – aku wedi yen output LLM bakal ilang, lan aku wedi yen dialog bakal beku.

Bisa mlaku, nanging ora duwe kaluwihan. Agen sing ora ana ing kothak kayata CherryStudio lan Openclaw uga bisa komunikasi, ngoperasikake file, lan nyambung menyang MCP. Ora ana diferensiasi ing V1. Apa malah Samsaya Awon iku V1 ora bisa diganti, lan terus kanggo nambah fungsi mung bakal nggawe liyane uncontrollable. Saiki teka bagean fatal.

Tatu Fatal V1

Cacat Fatal 1: Tag XML minangka Protokol

Iki minangka masalah arsitektur paling dhasar saka V1. Tinimbang nindakake operasi liwat mekanisme panggilan tool_use/fungsi native API, sistem ngijini LLM mbungkus kode Python kui karo tag XML, extract karo cocog biasa, lan nglakokaké ing kothak wedhi python. Proses kasebut bisa disederhanakake dadi rong tahap:

用户输入
  │
  ▼
┌─────────────┐
│ Judge 阶段   │  轻量 LLM 调用 → 决定加载哪些 Skill、文件
└──────┬──────┘
       ▼
┌─────────────┐
│ 处理阶段     │
│             │
│  ◄── 循环 ──┤  LLM 生成 <script> → 正则提取
│             │    → 沙箱执行 → 结果回传 → 下一轮
│             │    最多 50 轮
└─────────────┘
       ▼
    返回结果

Iki nggawa sawetara pitakonan:

• Kode gratis tanpa watesan. LLM ngasilake skrip Python sing sewenang-wenang, dudu panggilan fungsi kanthi skema. Parameter kasebut digawe saka hawa sing tipis, jeneng fungsi kasebut halusinasi, lan path file ditebak. Kesalahan sintaksis kode, impor sing ora ana, lan variabel sing ora ditemtokake kabeh dikenal liwat kesalahan kothak wedhi.
• Siji skrip nindakake kabeh. LLM cenderung nglumpukake sawetara operasi dadi siji <script> Blokir: maca file dhisik, banjur ngitung logika, lan pungkasane nulis asile. Yen ana langkah ing tengah gagal, kabeh script gagal, lan kita ora ngerti kang langkah iku gagal.
• Kesalahan kode vs kegagalan bisnis ora bisa dibedakake. Kothak wedhi ngasilake traceback utawa Ora Ana, lan sistem ora bisa nemtokake manawa “skrip kasebut salah ditulis” utawa “data sing ditakoni pancen kosong”. Pangolahan hilir saka rong skenario kasebut beda, nanging V1 nganggep minangka “coba maneh”.
• Parsing reguler rapuh. output LLM <script> Label rada mati – ana tutup luwih sithik, label sing padha dicampur ing blok pikir, lan kode kasebut ngemot </script> String, parsing rusak. Siji-sijine cara kanggo mbalekake yaiku supaya LLM nyoba maneh, nanging ora ngerti apa sing salah lan mung bisa ngasilake kode lan gagal bola-bali nganti entuk bathi, entek, utawa pangguna nyerah.
• Overhead saka salinan file sandbox. Sadurunge saben eksekusi skrip, nyalin file sing cocog menyang kothak wedhi isolasi, sing aman nanging mbutuhake siji maneh I/O saben babak. Sawise nglakokake pirang-pirang tugas, akeh wektu digunakake kanggo transfer file, nanging pitungan sing nyata ora kalebu proporsi sing dhuwur.

Cacat Fatal 2: Manajemen konteks kacau

Potongan bunder kasar

Pesen historis ora ngalami pitungan aktuaria token. Siji-sijine ukuran yaiku mung nahan babak N paling anyar lan langsung mbuwang sing sadurunge. Iku prasaja lan crude, nanging asil iku ambruk ing loro arah: yen sampeyan nahan sethitik banget, sampeyan bakal lali apa sing ngandika ing awal sawise sawetara babak saka LLM chatting, lan bola-bali takon pitakonan sing pangguna wis mangsuli; yen sampeyan nahan kakehan, siji babak interaksi bakal gampang ngluwihi 100.000 token. Model mung nduweni jendhela konteks 200K, lan bakal diobong ing sawetara babak. Salah siji API 400 dipicu lan ditolak langsung, utawa LLM meneng mbuang konteks awal, kang uga amnesia. Ora ana titik imbangan sing stabil.

Daur ulang inti mlaku nganti 50 langkah, lan saben langkah tanpa syarat nambahi respon asisten lan asil eksekusi skrip menyang dhaptar pesen. Saliyane ing sajarah chatting, iku kabeh hard-Cut miturut nomer babak, tanpa prioritas, ora komprèsi ringkesan, lan ora menehi tandha informasi tombol. Latar mburi bisnis sing dibahas sadurunge lan path file sing dikonfirmasi kaya-kaya ora nate katon sawise sawetara babak.

Tembung Prompt metu saka kontrol

Tembung pituduh sistem kira-kira 200 baris lan hard-kode ing kode sumber Python. Splicing dinamis kanggo saben telpon LLM: tembung pituduh dhasar + katrangan alat MCP (kalebu Skema JSON lengkap) + pratinjau file proyek (jeneng tabel Excel, jeneng kolom, sampel data) + teks lengkap instruksi Skill. Kanggo telpon bisnis biasa, tembung pituduh dhewe ngobong 10.000-20.000 token. Lan saben-saben dibangun saka ngeruk, ora ana cache nggunakake maneh. Iki tegese instruksi Skill uga nggedhekake bebarengan karo konteks: akeh wektu ngginakaken debugging lan ngoptimalake kondisi pemicu lan tembung cepet saka Skill karo pangguna, nanging sawise optimasi, iku diiseni menyang konteks wis kembung. Ora dingerteni manawa LLM ngetutake instruksi kasebut lan apa pemicu kasebut akurat. Sawise ngoptimalake sedina muput, efek kasebut gumantung marang perasaan.

Optimasi sing mbenerake panggonan sing salah: Loro strategi nyimpen token sing gagal

Fase Hakim

Sajrone pangembangan lan testing, aku nyadari masalah konteks lan ngrancang panggung Hakim kanggo ngatasi. Iki uga desain asli ing V1. Gagasan kasebut ora rumit: sadurunge saben tugas dieksekusi, telpon LLM sing entheng digawe kanggo nemtokake file sing pengin diproses pangguna lan Keahlian sing kudu dimuat, banjur mung isi sing disaring disuntik menyang konteks lengkap.

Ide iki apik, nanging ora nggatekake buku besar dhasar: siji telpon LLM maneh, pangguna kudu ngenteni siji maneh. Saben operasi kudu ngenteni Hakim bali, lan banjur ngenteni asil eksekusi, kang langsung slows mudhun kacepetan respon. Yen bisa ditindakake kanthi model sing entheng, konsumsi ora bakal gedhe banget. Nanging aku ora mikir babagan wektu iku.

Lan sanajan Fase Hakim ngethok pratinjau file lan konten Skill, akeh konteks nyata yaiku dialog sejarah. Bagean gedhe saka skrip Python sing digawe ing babak sadurunge, sawetara kilobyte asil eksekusi bali dening kothak wedhi, lan cathetan gagal nyoba maneh. Tembung-tembung pituduh sing diilangake ora ana apa-apa dibandhingake karo bolongan ireng ing dialog sejarah.

Pratinjau File

Mekanisme pratinjau file padha. Aku wis diamati pola: LLM tansah njupuk Mirit nalika Processing file: Excel maos sawetara baris pisanan saka Sheet pisanan, PDF maca sawetara kaca pisanan teks, lan tau nindakake analisis lengkap langsung saka wiwitan. Dadi, aku nambahake seperangkat pratinjau file: parse sapisan nalika ngunggah, Excel ngekstrak jeneng tabel lan data sampel, ekstrak PDF teks, Word extract paragraf lan tabel, lan asil disimpen minangka preview_data. Mung versi condensed (jeneng berkas + dimensi) dikirim ing tataran Judge, lan versi lengkap (kalebu garis sampel lan kutipan teks) dikirim ing tataran Processing. Ide iki padha karo Hakim: papan ijol-ijolan kanggo token. Nanging masalahe padha: panggunaan maneh cache ora rampung. Data pratinjau Excel sing padha dikirim kaping 50 kaya ing 50 panggilan LLM liwat puteran 50 langkah, lan tembung pituduh sistem ditulis saka wiwitan saben wektu. “Optimasi” V1 tansah mandheg ing tingkat “apa sing bakal dikirim” lan ora tau ndemek “carane ora ngirim bola-bali”. Sing terakhir kudu ngenteni caching cepet V2 supaya bisa ditanggulangi kanthi bener.

Fatal Three: God class bloat lan arsitektur metu saka kontrol

Masalah sing paling dhasar yaiku aku ora mutusake babagan struktur wiwit wiwitan. Ora amarga aku kesed, nanging amarga aku durung nate nindakake aplikasi sing padha lan aku ora ngerti apa sing kudu katon. Cara Vibe Coding yaiku njlèntrèhaké fungsi kasebut lan supaya AI nulis, tinimbang nggambar cithak biru dhisik banjur mbangun. Asil iku arsitektur mundak akeh organically karo fungsi, lan saben modul tambahan mundhak utang desain sadurungé.

executor.py2000+ baris. Sepira akeh perkara sing ditindakake kelas iki: fase pengadilan (Judge), fase eksekusi (Execute), skrip mlaku, penyaringan MCP, logika coba maneh, penanganan kesalahan, lan splicing konteks. Kabeh digabung dadi siji kelas, ora ana wates sing jelas.

kajaba iku,context.py 900+ baris,chat_service.py 600+ garis, saben duwe bug sing padha.

Sajrone proses pangembangan, AI bener-bener digunakake kanggo mbantu optimasi arsitektur: pamisah modul, pamisah file, ekstraksi fungsi, lan mbangun lapisan. AI bisa nindakake tugas kasebut. Nanging ana rong masalah. Kaping pisanan, AI mung tanggung jawab kanggo “modifikasi saiki”, lan ora ana sing ndeleng struktur global. Telung fungsi dibusak dina iki, loro liyane ditambahake maneh kanggo fix bug sesuk, lan fungsi anyar ditambahake dina sawise sesuk lan lapisan yen-liyane ditambahake. Kapindho, optimasi arsitektur mung bisa ditindakake nalika versi stabil: mung nalika fungsi mlaku kanthi lancar lan demonstrasi wis ora kaku maneh, kita bisa nindakake. Nalika ngganti syarat utawa ndandani kewan omo, aku ora wani nggawe owah-owahan struktural utama, amarga wedi nemokake masalah anyar lan ora bisa ndandani. Akibaté, jendhela optimasi dadi sempit lan sempit, lan utang mundhak.

Tulis maneh utawa Refactor

Aku berjuang karo keputusan iki meh seminggu. Ora amarga kita ora bisa ndeleng arah kanthi jelas, nanging amarga biaya sing dicemplungake abot banget.

V1 bisa digunakake sawise kabeh. Aku ngandelake kanggo nindakake sawetara demonstrasi produk ing Maret. Sanajan aku gugup sadurunge saben demonstrasi, fungsi kasebut bisa ditindakake siji-siji. Lan aku wis kerja lembur sajrone sasi, saingan karo AI nganti tengah wengi saben dina, lan pungkasane mbuwang versi sing bisa mlaku. Proyek riset nduweni simpul wektu perusahaan lan dudu eksplorasi tanpa wates. Miwiti maneh tegese kabeh kerja lembur ing sasi sadurunge bakal direset menyang nol, lan ora ana kepastian manawa rencana anyar bisa ditindakake kanthi tepat.

Ing wektu sing padha, pangguna nglaporake luwih akeh bug. Sawise ndandani siji, ana loro maneh, lan dadi saya angel ndeleng pungkasane.

Nanging yen sampeyan terus tinker karo V1, biaya uga worth iku. Telung cacat fatal kasebut ing artikel sadurunge ora bisa ditanggulangi kanthi rekonstruksi yen sampeyan ndeleng kanthi teliti.

  继续修补 V1                         推倒重写
  ────────────                       ──────────
  ✓ 能跑、演示扛住了                   ✓ 三个致命伤，重构解决不了
  ✓ 加班成果不归零                     ✓ 参考其他开源Agent源码，但不知道选哪个
  ✗ 时间节点越来越不可预期              ✗ 一个月加班归零，风险未知
  ✗ bug 越修越多，看不到头             ✗ 1.7 万行代码作废
  ✗ 架构缺陷是骨架层的问题             

Protokol tag XML minangka dhasar saka V1. Ngganti parsing XML karo tool_use standar tegese kabeh loop agen saka eksekutor, parser, konteks menyang link telpon LLM wis dibatalake. Iki dudu “bagean refactoring saka executor.py”, nanging mbusak raison d’être.

Malah karo Vibe Coding, beban kerja refactoring ora bakal cilik. Tes nol tegese saben-saben sampeyan nggawe pangowahan, sampeyan mung bisa ngandelake verifikasi manungsa: ujare AI “Ana masalah ing kene, ganti dadi X”, bukak maneh, temokake yen nabrak, ujar AI supaya ndandani kacilakan kasebut, lan mbukak maneh.

Ana uga masalah tingkat basa: V1 nggunakake Python mung amarga kenal karo Python nalika iku, sing ora ateges backend kudu nggunakake Python. Kode sumber Claude Code ditulis ing TypeScript. Kanggo terus ngrujuk desaine kanthi jero, nggunakake basa sing padha temenan luwih lancar tinimbang nerjemahake konsep antarane Python lan TypeScript. Terus tetep ing kode Python saka V1 tegese saben babak optimasi sakteruse dipetakan liwat lapisan basa. Biaya iki ora bisa disimpen kanthi refactoring.

Bobot pungkasan: V1 isih ana ing tahap demo skala cilik internal. Ora ana data historis sing cocog lan ora ana pangguna online sing bisa migrasi. Biaya paling abot kanggo ngilangi lan miwiti maneh mung mbuwang kode kasebut. Ora perlu nindakake migrasi data, kompatibilitas protokol, utawa ngalih skala abu-abu. Nilai V1 dumunung ing verifikasi arah lan nglumpukake kawruh, ora ing 17.000 baris kode dhewe.

Kesempatan

Nalika aku debat arep nulis maneh, kode sumber Claude Code bocor.

Aku ditarik mudhun kode sumber ing dina warta metu, nanging tinimbang maca kode sumber langsung, apa tenan mbantu aku nggawe pikiranku ana artikel interpretasi sing muncul siji sawise liyane ing masyarakat. Ana sawetara pituduh utama sing dibahas ing artikel iki:

• Desain siklus agen

• registrasi alat lan jadwal

• Strategi pementasan kanggo cache cepet

• Mekanisme hirarkis kanggo kompresi konteks

• Mode kolaborasi Multi-Agen

• Interception berlapis sistem ijin

Ing wektu iku, aku ora ngerti akeh, lan aku ora duwe pangerten lengkap akeh konsep. Nanging aku ngerti iki arah sing kudu daktuju. Sawise nggunakake Kode Claude kanthi intensif luwih saka sasi, lan ndeleng review komunitas, perasaanku luwih yakin. Saperangan poin sing bola-bali disebutake dening saben wong rampung pas karo pengalamanku dhewe: pangerten babagan basis kode ora kaya panelusuran tembung kunci, nanging luwih kaya insinyur sing maca kode sadurunge miwiti karya; nalika refactoring sawetara file, iku ora bakal bejat mudhun kanggo nggawe serep kanggo kulon, lan logika sambungan bakal alamiah digabung; saben operasi nerangake karo konteks poto-panjelasan, kaya alat sing ora mbutuhake dokumentasi.

Sing luwih apik yaiku Claude Code dudu Agen sing dirancang murni kanggo coding nanging kanggo karya umum. Sanajan sampeyan langsung mbuwang file ing lapangan finansial utawa lapangan bisnis liyane kanggo diproses, bisa ditangani kanthi telung klik, lima nganti lima, lan loro loro. Iki wis cukup kanggo aku. Desain sing aku ora bosen nggunakake saben dina kudu worth tindakake.

Temtokake maneh: gunakake SDK utawa deleng kode sumber sabisa-bisa

Saiki kita duwe arah referensi, kepiye carane njaluk menyang lemah? Ana swara ing grup sing menehi saran nggunakake Claude Code SDK langsung. Sawise kabeh, loop agen, penjadwalan alat, lan pangolahan streaming resmi dikemas, dadi paling cepet kanggo miwiti. Nanging sawise luwih saka sasi kerja keras, aku ngerti yen aku ora bisa cepet-cepet wektu iki. Yen sampeyan mung nggunakake SDK kanggo mbangun logika bisnis, sampeyan mung bakal ngganti pesawat saka API, lan ora ana masalah arsitektur V1 bakal ditanggulangi.

Sadurunge miwiti nulis maneh, aku nindakake evaluasi pungkasan.

Solusi A: Adhedhasar Claude Code SDK. @anthropic-ai/claude-agent-sdk Iku encapsulates daur ulang agen, jadwal alat, lan Processing stream, lan siap kanggo nggunakake sawise kepasang ing kauntungan iku siklus pembangunan cendhak, nanging kerugian iku arsitektur diwatesi dening SDK: model ijin, granularity cache, mekanisme interrupt, definisi acara SSE, kang bisa digunakake nanging ora bisa diganti.

Opsi B: Ngleksanakake dhewe kanthi ngrujuk kode sumber Claude Code. Sinau desain arsitektur, pilihan tumpukan teknologi, lan divisi modul Kode Claude, lan tulis maneh kanthi cara sampeyan dhewe. Kauntungane yaiku saben lapisan bisa dikontrol, nanging kekurangane yaiku beban kerja sing abot.

Aku milih pilihan B. Papat alasan:

Kontrol. SDK nyakup kemampuan inti, lan pangguna mung bisa ngakses liwat antarmuka. Apa aku kudu ngatur saben link tombol: carane ngrancang strategi eksekusi alat, carane isolasi model ijin, carane ngontrol granularity cache, carane pemicu mekanisme interupsi, lan carane jeneng lan ngirim acara SSE. Iki ditutup ing SDK lan transparan ing kode sumber.

Penyebaran cluster. Model mental SDK kanggo mbukak ing mesin siji, karo garpu + proses isolasi. Penyebaran kluster wis direncanakake wiwit wiwitan proyek: multi-instance + afinitas sesi + eksternalisasi negara + SSE cross-node forwarding. Iki mbutuhake lapisan HTTP lan lapisan streaming bisa dikontrol kanthi otomatis. Cara kode sumber saka server Hono menyang stream SSE iku sampeyan dhewe. Nalika nindakake transformasi sing disebarake, ora bakal ana rasa isin babagan “bab sing dibungkus SDK ora bisa diganti”.

Teknologi tumpukan alignment. Kode Claude dhewe dibangun nganggo TypeScript + Bun. V2 milih tumpukan teknologi padha, lan struktur modul lan sistem jinis bisa konsisten karo implementasine referensi, ngurangi biaya pangerten.

Akumulasi teknologi. Cara pangembangan nyata ora kanggo “maca kode sumber banjur nulis nganggo tangan”, nanging supaya agen nulis kode lan bebarengan ngatur dokumen teknis kanggo bantuan pangerten. Yen sampeyan nemoni kahanan sing durung mesthi, bali menyang kode sumber Claude Code kanggo ndeleng implementasine sing cocog, lan banjur ngasilake adegan sing padha ing Claude Code kanggo mirsani cara ditangani. Kode sumber ora cithakan kanggo disalin, iku jawaban referensi sing bisa bali lan mriksa kapan sampeyan nemokke masalah.

Arah Teknis V2

┌──────────────────────────┬──────────────────────────┬───────────────────────────┐
│ 原则一                    │ 原则二                    │ 原则三                     │
│ 技术栈靠拢 Claude Code    │ 按模块推进，不照抄          │ 预留集群扩展空间             │
├──────────────────────────┼──────────────────────────┼───────────────────────────┤
│ TS + Bun + Zod 对齐 cc   │ 提取核心设计思想            │ 会话外置 → SQLite / JSONL  │
│ Hono 做 HTTP（原生 SSE）  │ 适配需求做改写和简化         │ SSE → 预留跨节点转发接口     │
│ React + Vite（Web 前端）  │ 先确保能跑起来              │ 文件 → 抽象 storage 层      │
│ SQLite 持久化            │ 卡住时回源码查参考答案        │ 不假设单机，杜绝"以后改不了"  │
└──────────────────────────┴──────────────────────────┴───────────────────────────┘

Sadurunge njupuk tindakan, telung prinsip ditetepake.

Kaping pisanan, tumpukan teknologi nyedhaki Claude Code. Alesané prasaja: kode sumber Claude Code minangka jawaban referensi sing wis siap, lan paling lancar nerjemahake ing basa sing padha. Pilihan khusus adhedhasar Kode Claude lan diadaptasi kanggo macem-macem skenario:

Kapindho, maju miturut modul fungsional lan ora melu nyalin tingkat piksel. Claude Code minangka alat CLI tujuan umum, lan V2 minangka aplikasi web sing berorientasi bisnis. Skenario sing beda-beda ndhikte sampeyan ora bisa nyalin kabeh. Strategi pangembangan yaiku: extract gagasan desain inti saka kode sumber, nulis ulang lan menakake iku cocog karo kabutuhan dhewe, lan priksa manawa iku bisa mbukak ing premis sing konsisten karo proses Claude Code. Nalika versi simplified tenan ora bisa nyukupi kabutuhan, bali menyang kode sumber kanggo ndeleng carane Claude Code nangani skenario padha.

Katelu, cadangan papan ekspansi kanggo panyebaran kluster. Ana perlu kanggo penyebaran multi-kayata ing planning project. Iki tegese kita kudu nimbang saka baris pisanan kode: negara ora bisa tahan ing proses (data sesi externalized kanggo SQLite / JSONL), sambungan SSE ora bisa nganggep mesin siji (antarmuka dilindhungi undhang-undhang kanggo cross-node Terusake), lan panyimpenan file ora bisa gumantung ing disk lokal (lapisan panyimpenan abstrak). Ora perlu nyiyapake kluster saka wiwitan, nanging ora ana asumsi mesin tunggal ing arsitektur sing “ora bisa diganti mengko”.

Kabeh kode V1 wis dibuwang, nanging arah verifikasi V1: Sistem skill, integrasi MCP, lan wangun produk kabeh disimpen.

Pengalaman praktis Vibe Coding

Saliyane pawulangan sing disinaoni saka V1 dhewe, aku uga ngringkes sawetara pengalaman Vibe Coding umum.

Gunakake git kanthi apik kanggo nggawe langkah cilik. Saben komitmen mung nindakake siji perkara. Granularitas commit gedhe banget. Revisi ngarep + pangaturan mburi + owah-owahan tembung cepet kabeh dikempalken bebarengan. Yen ana bug, ora bisa nemokake owah-owahan sing ngenalake. Sing luwih umum yaiku bug A wis didandani, lan owah-owahan sabanjure bakal dibalekake amarga kiriman kasebut banget rame lan AI ora bisa ngerteni kode endi kanggo ndandani bug kasebut lan kanggo fitur-fitur anyar. Kirim kanthi langkah-langkah cilik lan saben komitmen bisa digulung maneh kanthi mandiri, ngirit akeh wektu ngatasi masalah.

Ngontrol jendhela konteks. Apa iku coding vibe utawa agen desain, manajemen konteks minangka kemampuan inti programer ing jaman AI. AI bakal lali bab nalika obrolan dawa. Aturan, konvensi, lan bug tetep sing kasebut ing ndhuwur ora bakal ana maneh yen wis dikompres. Inti saka kompresi yaiku ilang informasi, lan ora ana solusi kanggo masalah kasebut. Mulane, ing pembangunan nyata, kita kudu sengaja tetep obrolan fokus: mbukak obrolan anyar nalika path dikarepake tekan pungkasan, lan ora mlumpat bola-bali ing siji path dikarepake. Nambani memori AI minangka sumber langka sing kudu dikelola kanthi aktif, tinimbang nganggep manawa bisa ngelingi kabeh kanthi standar.

Jaga lingkungan operasi dhewe lan aja nganti Agen ngganggu. Bisa uga LLM sing digunakake ora cukup. Kadhangkala layanan sing diwiwiti dening Agen ora bisa mateni. Pelabuhan kasebut dikuwasani lan ora bisa direbut maneh, mula aku mung bisa nindakake kanthi manual. lsof -i maneh kill -9. Sawise sawetara losses, kita mutusaké ing aturan: Agen mung tanggung jawab kanggo kode ngasilaken, lan manungsa tanggung jawab kanggo miwiti layanan lan ngatur bandar. Pemisahan kode lan runtime nyimpen akeh masalah operasi lan pangopènan aneh lan uga nyimpen sawetara token.

Crita V1 rampung ing kene. Artikel sabanjure diwiwiti karo V2.