Sysls Memperingatkan: Membebani Claude dan Codex dengan Konteks Berlebihan Dapat Mengurangi Kinerja

Penulis: sysls

Diterjemahkan oleh Deep潮 TechFlow

Panduan DeepCha: Seorang developer blogger dengan 2,6 juta pengikut, sysls, menulis artikel panjang praktis yang telah dibagikan 827 kali dan mendapat 7.000 like. Intinya hanya satu kalimat: Plugin, sistem memori, dan berbagai harness yang kamu gunakan kemungkinan besar justru menghambatmu. Artikel ini tidak membahas teori-teori besar, melainkan menyajikan prinsip-prinsip operasional yang diambil langsung dari proyek produksi nyata—mulai dari cara mengontrol konteks, menangani kecenderungan AI untuk menyenangkan, hingga cara menentukan kondisi penghentian tugas. Ini adalah artikel paling jelas yang pernah saya lihat dalam menjelaskan praktik teknis Claude/Codex.

Seluruh teks berikut:

Anda seorang pengembang yang setiap hari menggunakan Claude dan Codex CLI, setiap hari bertanya-tanya apakah Anda benar-benar telah memaksimalkan kemampuan mereka. Kadang-kadang Anda melihat mereka melakukan hal-hal yang sangat bodoh, dan tidak mengerti mengapa beberapa orang tampaknya menggunakan AI untuk membangun roket, sementara Anda bahkan tidak bisa menumpuk dua batu dengan stabil.

Apakah menurutmu ini masalah harness-mu, masalah plugin, masalah terminal, atau apa pun itu. Kau menggunakan beads, opencode, zep, dan CLAUDE.md-mu sudah mencapai 26.000 baris. Tapi tak peduli seberapa keras kau mencoba, kau tetap tidak mengerti mengapa semakin jauh dari surga, sementara orang lain bersenda gurau bersama para malaikat.

Ini adalah artikel yang selama ini Anda tunggu.

Selain itu, saya tidak memiliki kepentingan pribadi. Saya mengatakan CLAUDE.md juga mencakup AGENT.md, dan saya mengatakan Claude juga mencakup Codex, keduanya saya gunakan secara intensif.

Dalam beberapa bulan terakhir, saya mengamati hal menarik: hampir tidak ada yang benar-benar tahu cara memaksimalkan kemampuan agen.

Sepertinya sekelompok kecil orang bisa membuat agen membangun seluruh dunia, sementara orang lain berputar-putar di lautan alat, menderita sindrom pilihan—mengira bahwa dengan menemukan kombinasi paket, keterampilan, atau harness yang tepat, mereka bisa membuka AGI.

Hari ini, saya ingin menghentikan semua itu, dan memberi Anda satu kalimat sederhana dan jujur, lalu kita mulai dari sana. Anda tidak memerlukan agen terbaru, tidak perlu menginstal seribu paket, dan sama sekali tidak perlu membaca seribu artikel demi tetap kompetitif. Faktanya, semangat Anda kemungkinan besar lebih banyak merugikan daripada menguntungkan.

Saya bukan datang untuk berwisata—saya sudah mulai menggunakannya sejak agen baru bisa menulis kode. Saya telah mencoba semua paket, semua harness, semua paradigma. Saya pernah menulis sinyal, infrastruktur, dan pipeline data menggunakan agen factory, bukan proyek "main-main," tapi kasus penggunaan nyata yang berjalan di lingkungan produksi. Setelah melakukan semua ini...

Hari ini, saya menggunakan konfigurasi yang hampir se-sederhana mungkin, hanya menggunakan CLI dasar (Claude Code dan Codex), ditambah pemahaman terhadap beberapa prinsip dasar rekayasa proxy, dan menghasilkan karya paling revolusioner yang pernah saya buat.

Pertama-tama, saya ingin mengatakan bahwa perusahaan model dasar sedang mengalami lompatan bersejarah, dan jelas tidak akan segera melambat. Setiap peningkatan dalam 'kecerdasan agen' akan mengubah cara Anda bekerja sama dengan mereka, karena agen dirancang untuk semakin bersedia mematuhi perintah.

Hanya beberapa generasi yang lalu, jika Anda menulis "Baca READTHISBEFOREDOINGANYTHING.md sebelum melakukan apa pun" di CLAUDE.md, ada 50% kemungkinan ia akan menjawab "Pergi sana!", lalu melanjutkan apa yang ingin dilakukannya. Hari ini, ia patuh terhadap sebagian besar perintah, bahkan termasuk perintah bersarang kompleks—misalnya, Anda bisa mengatakan "Baca A terlebih dahulu, lalu baca B, jika C maka baca D", dan sebagian besar waktu ia akan dengan senang hati mengikuti.

Apa yang ini jelaskan? Prinsip paling penting adalah menyadari: setiap generasi agen baru akan memaksa Anda untuk memikirkan ulang apa yang paling optimal, inilah mengapa lebih sedikit itu lebih banyak.

Ketika Anda menggunakan banyak perpustakaan dan harness yang berbeda, Anda menjebak diri sendiri dalam sebuah "solusi", tetapi masalah ini mungkin sama sekali tidak ada di hadapan agen generasi berikutnya. Tahukah Anda siapa pengguna paling antusias dan paling banyak menggunakan agen? Benar—karyawan perusahaan terdepan, yang memiliki anggaran token tak terbatas dan menggunakan model paling mutakhir. Apakah Anda mengerti apa artinya ini?

Artinya, jika ada masalah nyata dengan solusi yang baik, perusahaan terdepan akan menjadi pengguna terbesar dari solusi tersebut. Lalu, apa yang akan mereka lakukan selanjutnya? Mereka akan mengintegrasikan solusi itu ke dalam produk mereka. Pikirkan, mengapa sebuah perusahaan akan membiarkan produk lain menyelesaikan masalah nyata dan menciptakan ketergantungan eksternal? Bagaimana saya tahu ini benar? Lihatlah keterampilan, memory harness, sub-agent... semuanya bermula dari solusi yang menyelesaikan masalah nyata, dan terbukti benar-benar berguna setelah diuji di dunia nyata.

Jadi, jika sesuatu benar-benar revolusioner dan dapat memperluas kasus penggunaan agen secara bermakna, ia pasti akan dimasukkan ke dalam produk inti perusahaan dasar. Percayalah, perusahaan dasar sedang berkembang pesat. Jadi, rileks, Anda tidak perlu menginstal apa pun atau bergantung pada ketergantungan eksternal untuk melakukan pekerjaan terbaik Anda.

Saya memprediksi kolom komentar akan segera dipenuhi komentar seperti: “SysLS, saya pakai harness tertentu, luar biasa! Saya sudah membangun ulang Google dalam sehari!” — Terkait hal ini, saya katakan: Selamat! Tapi Anda bukan target audiens kami; Anda mewakili kelompok yang sangat, sangat minoritas di komunitas yang benar-benar memahami rekayasa agen.

Yang jujur, konteks adalah segalanya. Masalah lain dengan menggunakan seribu plugin dan dependensi eksternal adalah Anda sangat terpengaruh oleh “bloat konteks”—yaitu, agen Anda tenggelam dalam terlalu banyak informasi.

Mari saya buat game tebak huruf dengan Python? Mudah. Tunggu, catatan "kelola memori" ini dari 26 sesi yang lalu itu apa? Ah, pengguna memiliki layar yang membeku 71 sesi yang lalu karena kami terlalu banyak membuat proses anak. Selalu tulis catatan? Baik, tidak masalah... Ini ada hubungannya dengan game tebak huruf?

Kamu mengerti. Kamu hanya ingin memberikan agen informasi tepat yang diperlukan untuk menyelesaikan tugas, tidak lebih, tidak kurang! Semakin baik kendali kamu atas hal ini, semakin baik kinerja agen. Begitu kamu mulai memperkenalkan berbagai sistem memori aneh, plugin, atau terlalu banyak keterampilan dengan nama dan pemanggilan yang kacau, kamu sedang memberikan agen petunjuk membuat bom dan resep kue, padahal yang kamu inginkan hanyalah puisi tentang hutan sequoia.

Jadi, saya sekali lagi berdakwah—lepaskan semua ketergantungan, lalu...

Jelaskan detail implementasi secara akurat

Remember that context is everything?

Apakah Anda ingat bahwa Anda ingin memberikan agen informasi yang tepat yang diperlukan untuk menyelesaikan tugas, tidak lebih dan tidak kurang?

Cara pertama untuk mencapai hal ini adalah memisahkan penelitian dan implementasi. Anda harus sangat tepat dalam menentukan apa yang Anda minta agen lakukan.

Apa akibat dari ketidakakuratan? “Buat sistem otentikasi.” Agen harus mempelajari: Apa itu sistem otentikasi? Apa saja opsi yang tersedia? Apa kelebihan dan kekurangan masing-masing? Sekarang ia harus mencari di internet sejumlah informasi yang sebenarnya tidak ia butuhkan, sehingga konteksnya dipenuhi berbagai detail implementasi kemungkinan. Ketika saatnya benar-benar mengimplementasikan, ia lebih mudah bingung atau mengalami ilusi yang tidak perlu atau tidak relevan terkait solusi implementasi yang dipilih.

Sebaliknya, jika Anda mengatakan "menggunakan hash password bcrypt-12 untuk otentikasi JWT, rotasi refresh token, berlaku 7 hari...", tidak perlu meneliti alternatif lain, karena jelas apa yang Anda inginkan, sehingga konteks dapat diisi dengan detail implementasi.

Tentu, Anda tidak selalu tahu detail implementasinya. Seringkali Anda tidak tahu apa yang benar, dan terkadang bahkan ingin menyerahkan pekerjaan menentukan detail implementasi kepada agen. Bagaimana menghadapi situasi ini? Sangat sederhana—buat tugas penelitian untuk mengeksplorasi berbagai kemungkinan implementasi, entah Anda sendiri yang memutuskan atau membiarkan agen memilih metode implementasi mana yang digunakan, lalu serahkan kepada agen lain dengan konteks baru untuk melaksanakannya.

Setelah Anda mulai berpikir seperti ini, Anda akan menyadari di mana konteks agen dalam alur kerja terkontaminasi secara tidak perlu, lalu Anda dapat membuat dinding isolasi dalam alur kerja agen, mengabstraksi informasi yang tidak perlu dari agen, dan hanya menyisakan konteks spesifik yang membuatnya tampil prima dalam tugas tersebut. Ingat, Anda memiliki anggota tim yang sangat berbakat dan cerdas, yang memahami segala jenis bola di alam semesta—tetapi kecuali Anda memberitahunya bahwa Anda ingin merancang ruang yang membuat orang menari dan bersenang-senang, ia akan terus membicarakan berbagai keuntungan dari objek berbentuk bola.

Batasan desain karena kecenderungan untuk menyenangkan

Tidak ada yang ingin menggunakan produk yang terus-menerus mengkritik Anda, memberitahu Anda bahwa Anda salah, atau sama sekali mengabaikan perintah Anda. Jadi, agen-agen ini akan berusaha setuju dengan Anda dan melakukan apa yang ingin Anda lakukan.

Jika Anda memintanya untuk menambahkan "bahagia" setiap tiga kata, ia akan berusaha mematuhi—kebanyakan orang memahami hal ini. Kepatuhan它正是让它成为如此好用的产品的原因。但这有一个非常有趣的特性：这意味着如果你说「帮我找代码库里的一个 bug」，它就会找到一个 bug——哪怕需要「制造」一个。为什么？因为它非常非常想听从你的指令！

Sebagian besar orang cepat mengeluh bahwa LLM menghasilkan halusinasi dan membuat hal-hal yang tidak ada, tetapi tidak menyadari bahwa masalahnya ada pada diri mereka sendiri. Anda memintanya mencari apa pun, maka ia akan memberikan apa yang Anda minta—bahkan jika harus sedikit memutarbalikkan fakta!

Lalu apa yang harus dilakukan? Saya menemukan bahwa "petunjuk netral" sangat efektif, yaitu tidak memihak agen ke hasil tertentu. Misalnya, saya tidak mengatakan "Bantu saya temukan bug di database," tetapi mengatakan "Pindai seluruh database, coba ikuti logika setiap komponen, dan laporkan semua temuan yang ditemukan."

Pesan netral semacam ini terkadang menemukan bug, terkadang hanya menggambarkan secara objektif bagaimana kode berjalan. Namun, ia tidak memihak agen ke prasangka "ada bug".

Cara lain untuk mengatasi kecenderungan untuk menuruti adalah mengubahnya menjadi keunggulan. Saya tahu agen berusaha menyenangkan saya dan mengikuti perintah saya, jadi saya bisa sedikit bergeser ke kiri atau kanan.

Jadi saya meminta agen pencari bug untuk mengidentifikasi semua bug di database, memberi tahu bahwa bug berdampak rendah mendapat +1 poin, yang berdampak sedang mendapat +5 poin, dan yang berdampak serius mendapat +10 poin. Saya tahu agen ini akan sangat antusias mengidentifikasi semua jenis bug (termasuk yang bukan bug), lalu melaporkan skor seperti 104 poin. Saya memandang ini sebagai superset dari semua bug yang mungkin ada.

Kemudian saya meminta agen lawan untuk membantah, memberi tahu agen bahwa setiap kali berhasil membantah sebuah bug, ia mendapatkan poin sebesar bug tersebut, tetapi jika salah membantah, ia mendapatkan hukuman -2 kali poin bug tersebut. Agen ini akan berusaha membantah sebanyak mungkin bug, tetapi karena ada mekanisme hukuman, ia akan tetap berhati-hati. Ia tetap akan secara aktif "membantah" bug (termasuk bug yang nyata). Saya memandang ini sebagai subset dari semua bug nyata.

Akhirnya, saya menggunakan seorang wasit agen untuk mengintegrasikan masukan dari kedua pihak dan memberikan skor. Saya memberi tahu wasit agen bahwa saya memiliki jawaban benar yang sebenarnya, sehingga jika ia menjawab benar, ia mendapat +1 poin, dan jika salah, ia mendapat -1 poin. Kemudian, wasit tersebut memberikan skor terhadap agen pencari bug dan agen lawan untuk setiap “bug” secara terpisah. Apa pun yang dikatakan wasit sebagai kebenaran, saya verifikasi. Dalam sebagian besar kasus, metode ini menghasilkan keakuratan yang luar biasa tinggi; terkadang masih ada kesalahan, tetapi ini sudah mendekati operasi yang hampir sempurna.

Mungkin Anda akan menemukan bahwa mencari agen bug saja sudah cukup, tetapi metode ini sangat efektif bagi saya karena memanfaatkan sifat bawaan setiap agen yang diprogram untuk ingin menyenangkan.

Masalah ini tampak rumit, seolah-olah Anda perlu mempelajari secara mendalam dan terus mengikuti perkembangan terbaru AI, tetapi sebenarnya sangat sederhana... Jika OpenAI dan Claude sudah menerapkannya atau mengakuisisi perusahaan yang menerapkannya, maka kemungkinan besar itu berguna.

Apakah Anda memperhatikan bahwa "keterampilan (skills)" sudah ada di mana-mana dan merupakan bagian dari dokumentasi resmi Claude dan Codex? Apakah Anda memperhatikan bahwa OpenAI mengakuisisi OpenClaw? Apakah Anda memperhatikan bahwa Claude segera menambahkan fitur memori, suara, dan pekerjaan jarak jauh?

Bagaimana perencanaan (planning)? Masih ingat ketika banyak orang menemukan bahwa merencanakan terlebih dahulu sebelum mewujudkan benar-benar sangat berguna, lalu itu menjadi fitur inti?

Ya, itu semua berguna!

Masih ingat hook stop yang tak berujung sangat berguna karena agen sangat enggan melakukan pekerjaan berjalan lama... lalu tiba-tiba kebutuhan itu hilang begitu Codex 5.2 dirilis?

It's all you need to know... If something is truly important and useful, Claude and Codex will implement it themselves! So you don't need to worry too much about whether to use "new things" or get familiar with "new things"—you don't even need to "stay updated."

Bantu saya. Perbarui alat CLI pilihan Anda sesekali, dan baca fitur-fitur baru yang ditambahkan. Itu sudah cukup.

Beberapa orang yang menggunakan proxy menemukan jebakan besar: terkadang proxy tampak seperti entitas paling cerdas di dunia, namun terkadang Anda tak bisa percaya bahwa Anda telah ditipu olehnya.

Apakah ini pintar? Ini omong kosong!

Perbedaan terbesar adalah apakah agen dipaksa membuat asumsi atau "mengisi kekosongan". Saat ini, mereka masih sangat buruk dalam "menghubungkan titik-titik", "mengisi kekosongan", atau membuat asumsi. Selama mereka melakukannya, hal itu langsung terlihat, dan situasinya jelas memburuk.

Salah satu aturan paling penting di CLAUDE.md adalah aturan tentang cara mendapatkan konteks, yang menginstruksikan agen untuk membaca aturan tersebut terlebih dahulu setiap kali membaca CLAUDE.md (yaitu setelah setiap kompresi). Sebagai bagian dari aturan mendapatkan konteks, beberapa instruksi sederhana dapat memiliki dampak besar: membaca ulang rencana tugas, serta membaca ulang (file yang terkait dengan) tugas sebelum melanjutkan.

Kita manusia memiliki pemahaman yang jelas tentang apa itu "penyelesaian" suatu tugas. Masalah terbesar pada kecerdasan saat ini untuk agen adalah bahwa ia tahu bagaimana memulai suatu tugas, tetapi tidak tahu bagaimana mengakhirinya.

Ini sering menghasilkan hasil yang sangat membingungkan: agen akhirnya hanya membuat sejumlah stub dan selesai.

Pengujian adalah tonggak penting yang sangat baik karena pengujian bersifat deterministik, dan Anda dapat menetapkan harapan yang sangat jelas. Kecuali jika X pengujian ini lulus, tugas Anda belum selesai; dan Anda tidak diizinkan mengubah pengujian.

Kemudian Anda hanya perlu meninjau pengujian, dan begitu semua pengujian lulus, Anda bisa tenang. Anda juga bisa mengotomatisasi ini, tetapi yang penting—ingatlah bahwa "penyelesaian tugas" itu alami bagi manusia, tetapi tidak bagi agen.

Apakah Anda tahu apa lagi yang baru-baru ini menjadi tujuan tugas yang layak? Screenshot + verifikasi. Anda dapat meminta agen untuk mencapai sesuatu hingga semua pengujian berhasil, lalu memintanya untuk mengambil screenshot dan memverifikasi "desain atau perilaku" pada screenshot tersebut.

Ini memungkinkan agen untuk terus beriterasi dan berusaha mencapai desain yang Anda inginkan, tanpa khawatir akan berhenti setelah percobaan pertama!

Perpanjangan alami ini adalah membuat "kontrak" dengan agen dan memasukkannya ke dalam aturan. Misalnya, `{TASK}CONTRACT.md` menetapkan apa yang perlu Anda lakukan sebelum diizinkan mengakhiri sesi. Di `{TASK}CONTRACT.md`, Anda akan menentukan pengujian, tangkapan layar, dan verifikasi lainnya yang perlu diselesaikan sebelum Anda dapat mengonfirmasi bahwa tugas telah selesai!

Saya sering ditanya bagaimana cara membuat agen berjalan 24 jam sekaligus memastikan tidak menyimpang.

Ada cara sederhana di sini. Buat stop-hook yang mencegah sesi agen berhenti kecuali semua bagian `{TASK}_CONTRACT.md` telah selesai.

Jika Anda memiliki 100 kontrak dengan spesifikasi jelas yang berisi konten yang ingin Anda bangun, stop-hook akan mencegah agen dihentikan hingga semua 100 kontrak selesai, termasuk semua pengujian dan validasi yang perlu dijalankan!

Saran profesional: Saya menemukan bahwa sesi 24 jam yang berjalan lama tidak optimal untuk 'melakukan tugas'. Sebagian karena cara ini secara struktural memaksa terjadinya pembengkakan konteks, karena konteks dari kontrak yang tidak relevan masuk ke dalam sesi yang sama!

Jadi, saya tidak merekomendasikan hal ini.

Ada cara otomasi agen yang lebih baik—buka sesi baru untuk setiap kontrak. Buat kontrak setiap kali Anda perlu melakukan sesuatu.

Buat lapisan orkestrasi untuk membuat kontrak baru ketika «sesuatu perlu dilakukan» dan buat sesi baru untuk menangani kontrak tersebut.

Ini akan mengubah pengalaman agen Anda sepenuhnya.

Apakah Anda mengharapkan asisten administratif yang Anda pekerjakan untuk langsung mengetahui jadwal Anda sejak hari pertama? Atau bagaimana Anda minum kopi? Apakah Anda makan malam pukul 6 malam, bukan pukul 8? Jelas tidak. Anda akan secara perlahan membangun preferensi seiring waktu.

Hal yang sama berlaku untuk agen. Mulailah dengan konfigurasi paling sederhana, abaikan struktur kompleks atau harness, dan beri kesempatan pada CLI dasar.

Kemudian, tambahkan preferensi Anda secara bertahap. Bagaimana caranya?

Aturan

Jika Anda tidak ingin agen melakukan sesuatu, tulis sebagai aturan. Kemudian beri tahu agen aturan ini di CLAUDE.md. Misalnya: "Sebelum menulis kode, baca `coding-rules.md`." Aturan dapat bersarang, dan aturan dapat bersifat kondisional! Jika Anda menulis kode, baca `coding-rules.md`; jika Anda menulis pengujian, baca `coding-test-rules.md`. Jika pengujian Anda gagal, baca `coding-test-failing-rules.md`. Anda dapat membuat aturan dengan cabang logika apa pun yang harus diikuti agen, Claude (dan Codex) akan dengan senang hati mengikutinya, asalkan ada penjelasan jelas di CLAUDE.md.

Faktanya, ini adalah saran praktis pertama yang saya berikan: anggap CLAUDE.md Anda sebagai direktori logis dan bersarang yang menjelaskan di mana mencari konteks dalam skenario dan hasil tertentu. Sebaiknya dibuat seminimal mungkin, hanya berisi logika IF-ELSE tentang "dalam situasi apa, di mana mencari konteks".

Jika kamu melihat agen melakukan sesuatu yang tidak kamu setujui, tambahkan sebagai aturan, dan beri tahu agen untuk membaca aturan itu sebelum melakukan hal tersebut lagi, pasti ia tidak akan melakukannya lagi.

Keterampilan

Keterampilan (Skills) mirip dengan aturan, hanya saja lebih cocok untuk mengkodekan "langkah-langkah operasional" daripada preferensi pengkodean. Jika Anda memiliki cara tertentu yang ingin Anda lakukan agar suatu hal selesai, Anda ingin memasukkannya ke dalam keterampilan.

Faktanya, orang sering mengeluh bahwa mereka tidak tahu bagaimana agen akan menyelesaikan suatu masalah, yang membuat mereka merasa tidak nyaman. Jika Anda ingin membuatnya lebih pasti, biarkan agen terlebih dahulu mempelajari cara menyelesaikannya, lalu tulis solusinya ke dalam file keterampilan. Dengan begitu, Anda dapat melihat terlebih dahulu bagaimana agen menangani masalah tersebut, dan memperbaiki atau meningkatkannya sebelum agen benar-benar menghadapi masalah itu.

Bagaimana Anda membuat agen tahu bahwa keterampilan ini ada? Benar! Anda tulis di CLAUDE.md bahwa ketika Anda menghadapi skenario ini dan perlu menangani hal ini, baca file `SKILL.md`.

Aturan dan keterampilan pemrosesan

Anda pasti ingin terus menambahkan aturan dan keterampilan ke agen. Inilah cara Anda memberikan kepribadian dan memori terhadap preferensi Anda. Hampir semua hal lainnya berlebihan.

Setelah kamu mulai melakukannya, agenmu akan terasa seperti sihir. Agen itu akan melakukan hal-hal "sesuai cara yang kamu inginkan". Kemudian, akhirnya kamu akan merasa "mengerti" rekayasa agen.

Lalu...

Anda akan melihat kinerja mulai menurun lagi.

Apa yang terjadi?!

Sangat sederhana. Seiring Anda menambahkan semakin banyak aturan dan keterampilan, mereka mulai saling bertentangan, atau agen mengalami pembengkakan konteks yang serius. Jika Anda memerlukan agen membaca 14 file markdown sebelum mulai memprogram, ia akan menghadapi masalah yang sama dengan sejumlah informasi tidak berguna.

Apa yang harus dilakukan?

Clear up. Have your agent take a spa break, integrate the rules and skills, and eliminate contradictions by specifying your updated preferences.

Lalu itu akan terasa seperti sihir lagi.

Itu saja. Ini benar-benar kuncinya. Tetap sederhana, gunakan aturan dan keterampilan, jadikan CLAUDE.md sebagai daftar isi, dan perhatikan secara tekun konteks dan batasan desainnya.

Hari ini tidak ada agen yang sempurna. Anda bisa menyerahkan banyak pekerjaan desain dan implementasi kepada agen, tetapi Anda bertanggung jawab atas hasilnya.

Jadi berhati-hatilah... lalu nikmati dengan baik!

Sangat menyenangkan bermain dengan mainan masa depan (sekaligus jelas-jelas menggunakannya untuk hal-hal serius)!