Implementasi AI di STR Network: dari teknologi ke manajemen

"AI bukan masalah teknologi, ini masalah manajemen." Sunny berkata begitu dalam wawancara Business Weekly edisi 1963.

Kedengarannya seperti tagline rapat konsultan, tapi di STR Network (薩泰爾娛樂), kalimat itu adalah deskripsi urutan engineering — ketika kebanyakan perusahaan masih sibuk membandingkan ChatGPT, Cursor, dan n8n mana yang lebih unggul, co-founder ini sudah membalik pertanyaannya: definisikan dulu apa yang perlu dikelola di dalam perusahaan, baru tools punya makna.

Tulisan ini adalah inventarisasi beberapa sistem internal STR Network yang berjalan di Zeabur. Tapi urutan ceritanya — dan kenapa ritme engineering STR Network tidak sama dengan kesan umum "startup gerak cepat" — harus dimulai dari cara mereka mengorganisir diri sendiri.

At a glance

I. Bagaimana STR Network menerapkan AI dan tool-tool baru lainnya

STR Network adalah perusahaan produksi konten asal Taiwan yang berakar di komedi satir, dengan program unggulan termasuk Night Night Show with Brian Tseng. DNA inti perusahaan adalah konten — perencanaan, penulisan, produksi, manajemen artis. Departemen teknologi, kalau dihitung ketat, hanya satu orang: engineer Feng.

Dari kacamata Zeabur, dalam hal membangun sistem internal dan menggunakan tools, STR Network bergerak lebih cepat dibanding perusahaan konten yang seukuran. Bukan karena tim engineering-nya banyak, melainkan karena pembagian peran internalnya jelas:

Co-founder Sunny memegang brief. Dia mendefinisikan apa yang perlu dikelola perusahaan, siapa bisa melihat apa, bagaimana hak akses dibagi, kerangka apa yang dipakai untuk menerima tools baru — penilaian di lapisan ini diturunkan menjadi sebuah brief, lalu diserahkan ke eksekutor.

Setelah brief dari Sunny turun, Feng menerjemahkannya menjadi sistem yang benar-benar berjalan. Inventarisasi proses dan implementasi engineering bukan lomba estafet, melainkan percakapan dua orang yang duduk di meja yang sama — dokumen kebutuhan yang ditulis Sunny akan dikomentari balik oleh Feng saat implementasi ("apakah field ini benar-benar butuh lapisan hak akses sebanyak ini?"), lalu disinkronkan di weekly brief dengan Sunny.

Struktur "keputusan Sunny + implementasi Feng" inilah yang membuat setiap tools dan sistem baru harus melewati saringan sebelum masuk ke perusahaan — bukan membebani satu engineer untuk memikul tata kelola, desain, dan konstruksi sekaligus. Inilah yang disebut "struktur tata kelola", yang sudah berjalan bertahun-tahun di STR Network. Sementara itu, alasan sebenarnya kenapa banyak perusahaan menengah kewalahan di era AI adalah karena mereka kekurangan struktur ini.

Konteks konkretnya begini: setiap pertunjukan harus menyisakan 20 sampai 200 tiket PR — untuk tamu dewan komisaris, media, mitra bisnis, jaringan agen, untuk setiap pemangku kepentingan beserta asistennya. Kontrak yang harus diteken dalam setahun, lembar honorarium yang perlu dilacak, laporan penjualan tiket yang harus dicocokkan — volumenya sudah masuk ke skala yang Google Sheet tidak sanggup tampung.

Semua orang tahu proses dan sistem harus dibangun. Di era pra-AI, STR Network sudah memecahkan masalah ini secara sistematis. Untuk perusahaan tanpa departemen teknologi, pertanyaan berikutnya bukan "AI apa yang mau dipakai", melainkan "apa sebenarnya yang ingin kami kelola" — dan sejak ChatGPT dirilis di 2022 — bahkan sejak era GPT-3 yang lebih awal, STR Network sudah lama memikirkan pertanyaan ini.

II. Tiga lapisan "utang manajemen" di STR Network

Istilah "utang manajemen" dipakai Sunny di wawancara Business Weekly edisi 1963, dan juga jadi kutipan pembuka tulisan ini. Dalam wawancara dengan Zeabur, dia membongkar istilah itu lebih konkret — menjadi tiga lapisan.

Lapisan pertama: definisi manajemen harus mendahului desain sistem.

"Setelah definisi manajemen keluar, baru desain sistem dan konsep-konsepnya bisa tumbuh."

Contoh konkret yang dia sebut adalah konsep internal "buku kas" (ledger) — satu proyek pertunjukan bisa punya dua atau tiga buku kas, masing-masing dengan hak akses berbeda, dan semuanya tetap berpulang ke proyek yang sama. Apakah sistem mampu melakukan ini adalah masalah engineering; prasyaratnya, manajemen perusahaan harus lebih dulu mendefinisikan aturan seperti "gaji adalah data pribadi, tidak boleh terbuka" atau "nasi kotak kru bisa direimburse oleh asisten mana pun" — dalam istilah engineering, itu artinya menetapkan hak akses data dengan jelas.

Tanpa langkah pertama, langkah kedua mustahil dikerjakan.

Lapisan kedua: setiap modifikasi kecil punya ongkos komunikasi.

"Anda mau menambah satu label, satu status, satu role pengguna, satu hal yang dipakai — ongkosnya tinggi, ongkos komunikasinya tinggi."

Di spreadsheet, menambah satu kolom secara spontan itu gratis; begitu pindah ke sistem, setiap perubahan field menyeret tenaga engineering, desain hak akses, pemeliharaan lanjutan, dan pelatihan untuk role-role pengguna terkait. Membentangkan rantai itu dan menghitungnya sampai bersih — menghitung waktu, juga sumber daya manusia — adalah pekerjaan yang harus diselesaikan STR Network sebelum memutuskan "kerjakan atau tidak". Bukan menyuruh engineer langsung bekerja, lalu kembali membereskan sisa-sisa komunikasi.

Lapisan ketiga: kalau orangnya pergi, sistemnya tidak ada yang menerima.

Sunny bersikap konservatif soal memindahkan sistem (maksudnya proyek INVITI sistem undangan tamu yang dimulai Jerry, dibahas di bawah) dari Google Sheet ke halaman kerja buatan sendiri. Bicaranya lugas, sambil melempar sedikit lelucon hitam (di perusahaan komedi, semua orang tahu cara melempar lelucon?):

"Kalau saya kebetulan kecelakaan dan meninggal, tidak apa-apa. Tapi kalau Feng yang pergi, seluruh sistem ini (orang lain) tidak tahu, tidak ada yang bisa mewarisinya. Sampai sekarang pun masalah ini belum terpecahkan."

Mensistematisasi proses sekaligus menciptakan ketergantungan baru, dan ketergantungan itu jatuh ke satu-satunya engineer. Di lapisan ini, makna "utang manajemen" adalah: selama Anda belum melepas ketergantungan "seluruh sistem hanya satu orang yang paham", setiap sistem baru adalah utang yang ditambah.

Tiga lapisan ini, kalau dijumlahkan, adalah makna sebenarnya dari "utang manajemen" di STR Network — bukan soal tools mana yang dipakai, melainkan soal membentangkan, mendefinisikan, dan melacak apa yang perlu dikelola di dalam organisasi, siapa mengelola apa, siapa boleh melihat apa, sebelum memutuskan apakah hal itu layak dijadikan sistem. Terutama di zaman ketika "menulis apa pun jadi sangat mudah" seperti sekarang.

III. "Utang teknis" adalah kekhawatiran langsung Sunny terhadap vibe coding

STR Network sama sekali tidak menolak tools AI — sebaliknya, mereka sudah menjalankan satu putaran otomatisasi, sudah menghubungkan Gemini Embedding ke RAG, dan Sunny sendiri menulis kerangka Skill dengan Claude Code. Yang dia khawatirkan adalah hal lain: masalah manajemen AI yang baru. Menjelang akhir wawancara, dia bicara sangat blak-blakan:

"STR Network masih relatif aman, model operasi dan bisnisnya stabil. Tapi banyak perusahaan yang baru memulai, di tengah kecemasan AI belakangan ini, semua punya mentalitas sprint, ingin membuat banyak hal yang ditumpuk ke produk dan layanan yang sudah ada. Yang paling menyakitkan menurut saya adalah, orang-orang mungkin membuat seratus hal yang mirip, tapi pada dasarnya saling mengulang pekerjaan satu sama lain. Mendorong vibe coding secara membabi buta justru akan menimbulkan masalah efisiensi yang lebih besar — lebih banyak utang teknis, dan utang operasional yang menyertainya."

"Kalau cuma menyuruh ChatGPT atau Cursor 'saya butuh satu set sistem', yang dia kasih cuma barang jelek," Feng juga menyebutkan hal yang sama dalam wawancaranya dengan Global Views Monthly.

Utang teknis dan utang operasional — itulah dua risiko yang Sunny sebut langsung dalam wawancara. Sehari setelah wawancara (2 April), dia mempublikasikan tulisan How to Read the Vibes di Facebook, yang menjabarkan kekhawatiran tersebut lebih utuh:

"Yang selalu saya pedulikan bukan menegaskan betapa hebat dan kuatnya satu individu, melainkan saya penasaran dengan hal-hal apa yang akhirnya tidak perlu dikerjakan lagi. Pada saat yang sama, ketakutan terdalam saya adalah setelah pembangunan masif, semuanya berubah menjadi lebih banyak bangunan liar berupa utang teknis dan utang manajemen. Ketika orang lelah memperbaiki dan membangun jadi sangat mudah, kita akan kehilangan keyakinan tentang 'bagaimana mendesain kerangka yang bisa bertahan lebih lama'."

"Bangunan liar" — itulah deskripsi konkretnya tentang hasil vibe coding yang lepas kendali. Setelah satu kalimat itu, dia menambahkan satu twist:

"Tapi jangan salah paham, saya tidak menolak pembangunan. Justru karena ingin membangun tanpa kekhawatiran, kerangka manajemen itulah yang dibutuhkan."

Responsnya adalah menulis seperangkat "Dev Diagnosis Skill", yang sudah dipublikasikan dalam bentuk Claude Code Skill di GitHub. README-nya dibuka dengan "Sebelum mulai mengerjakan, identifikasi dulu nilainya" diikuti satu kalimat tajam: "Memproduksi sampah secara efisien tetaplah sampah."

Skill ini memecah penanganan kebutuhan yang masuk menjadi empat fase — diagnosis → pilih solusi → manajemen berjenjang → implementasi. Sunny menjelaskan evolusi Skill ini dalam unggahan Facebook-nya:

"Tahun lalu di STR Network, saya membuat flowchart penjenjangan isu, awalnya memakai 'cakupan dampak × keberlanjutan × kompleksitas' untuk menyilangkan tiga level guna membantu kami menentukan cara mengawasi. Tapi 'cakupan dampak × keberlanjutan × kompleksitas' itu sendiri terlalu abstrak. Saya selalu memikirkan teknik 'diagnosis': yang bisa digambarkan pasien adalah rasa, dan kebijaksanaan dokter adalah bagaimana menghubungkan gejala ke nama penyakit lalu ke solusi."

Dengan kata lain, dia sedang menulis ulang kerangka manajemen itu sendiri — bukan menyuruh pengguna menghafal istilah "cakupan dampak × keberlanjutan × kompleksitas", melainkan langsung membiarkan mereka mendeskripsikan gejala, lalu Skill mencocokkan gejala dengan mode pengembangan yang seharusnya diambil.

Skill bukan tools, melainkan tata kelola perusahaan yang ditulis ke dalam markdown. Rangkuman Sunny sendiri: "Yang saya pedulikan adalah, apakah penilaian dasar di dalam sebuah tim bisa punya konsensus. Setelah tingkat sinkronisasi konsistensi naik, baru kita bisa memperbesar perspektif yang dibawa pengalaman individu yang berbeda-beda."

Menjawab kalimat tentang membangun tanpa rasa takut, lebih banyak utang teknis, dan utang operasional yang menyertainya, yang lebih penting adalah meninjau dari hulu — dengan arsitektur dan kesadaran — kebutuhan untuk membangun sistem baru.

IV. Beberapa sistem yang berjalan di Zeabur

Berikut adalah produk dan sistem STR Network yang berjalan di Zeabur. Sebagian berjalan di shared cluster Zeabur (tidak lagi terbuka untuk proyek baru sejak 2026-02-23), sebagian terhubung ke host GCP mereka sendiri melalui BYOS.

1. INVITI — sistem undangan tamu

INVITI tidak dimulai dari menulis kode, melainkan dari inventarisasi yang dikerjakan sebulan oleh Jerry, asisten CEO yang sangat pusing menangani tiket PR.

Seperti disebut di awal, setiap pertunjukan STR Network — tergantung skala — harus menyisakan 20 sampai 200 tiket PR untuk tamu dewan komisaris, daftar media, mitra bisnis, dan daftar media yang ditangani agen. Di balik setiap tiket ada seorang pemangku kepentingan, dan setiap pemangku kepentingan punya asisten — volume datanya cepat sekali melampaui kapasitas satu Google Sheet.

Sunny dan Feng bercerita di wawancara tentang apa yang dikerjakan Jerry: "Di depan, dia menghabiskan kira-kira satu bulan untuk menginventarisasi seluruh proses undangan tamu yang dia jalani sendiri." Itu adalah pekerjaan menggambar seluruh proses undangan tamu menjadi sebuah dokumen "tabel pemetaan peran" — siapa mengundang siapa, peran mana melihat field apa, jenis tiket dikategorikan bagaimana, setiap titik harus melakukan apa. Dokumen ini bukan diagram arsitektur sistem, melainkan proses di kehidupan nyata.

Kemudian Feng menghabiskan satu setengah bulan untuk membuat database plus front-end. Tentang peran Zeabur dalam sistem ini — sebagai pendorong internalisasi — deskripsinya lugas:

"Bantuan terbesar Zeabur di bagian ini adalah deployment Postgres satu klik. Sebelumnya kami hampir tidak punya solusi deployment data selain BigQuery atau yang berbasis Google. Sementara Postgres yang bisa dinyalakan dengan satu klik di Zeabur membuat testing lokal saya jauh lebih praktis. Menurut saya, ini sangat menurunkan ongkos saya saat melakukan testing tanpa naik ke cloud."

2. Sistem operasional — middle platform internal yang menampung semua angka dan proses perusahaan

"Seluruh sistem ini ter-deploy di Zeabur" — Feng mengulangi kalimat ini empat kali dalam wawancara. Yang dia maksud adalah middle platform internal: sistem operasional STR Network, yang mengelola reimburse, lembar honorarium, laporan performa penjualan tiket, dan daftar proyek. "Angka-angka di dalam perusahaan semuanya dikumpulkan, semuanya terpusat di situs ini."

Arsitektur teknisnya sebenarnya satu paket aplikasi web utuh: Django + Celery di lapisan aplikasi, PostgreSQL di lapisan data, Redis menjalankan Worker dan background job, django-celery-beat menangani scheduled task, Nginx sebagai reverse proxy. Feng menyebut bahwa awalnya dia "tidak secara sengaja mengarah ke microservices, tapi melihat kembali ternyata sudah ada bentuk embrionalnya" — service-nya tersebar, masing-masing berjalan, dan terisolasi satu sama lain. Tentu, ini masih jauh dari microservices dalam pengertian ketat — yang menuntut database independen dan deployment independen (engineer backend Zeabur, Pan, membahas definisi dan implementasi microservices di SITCON 2025). STR Network sedang terus mengiterasi sistemnya, dan tahap berikutnya adalah secara bertahap mengisolasi service — selain menurunkan risiko dependensi, juga untuk meningkatkan efisiensi pengembangan:

"Idealnya, service ini deploy di host ini, dan service lainnya deploy di host yang lain."

Tapi yang sebenarnya sulit dalam sistem operasional bukan komposisi teknisnya, melainkan hak akses.

Sunny menyebut bahwa esensi tim di balik sebuah pertunjukan besar adalah kolaborasi outsourcing: kebanyakan orang di lokasi acara bukan karyawan tetap, dan siapa boleh melihat buku kas mana, proyek mana, data gaji mana, harus dibagi dengan ketat. Sistemnya pakai RBAC, tapi Sunny menyebut prasyaratnya di wawancara sebelumnya: "Setelah definisi manajemen keluar, baru desain dan konsep sistem bisa tumbuh."

Konsep "buku kas" yang dirancang STR Network dalam manajemen proyek — satu proyek bisa punya dua atau tiga buku kas, masing-masing dengan hak akses berbeda, dan semuanya tetap berpulang ke proyek yang sama — secara esensial adalah "Principle of Least Privilege (PoLP)" dari ranah keamanan informasi: setiap peran hanya melihat buku kas yang benar-benar diperlukan untuk menyelesaikan pekerjaannya, tidak lebih.

Tujuan desain mekanisme ini adalah agar orang-orang outsourcing juga bisa masuk ke sistem dengan lancar untuk membantu staf tetap mempersiapkan kebutuhan: "Ini adalah tool internal kami, tapi tidak boleh hanya dipakai orang internal. Kalau hanya dipakai orang internal, akan ada bottleneck, akan terbatas oleh kapasitas tim internal," Sunny menambahkan.

Itu sisi eksternal. Logika manajemen yang sama, ditarik kembali ke internal: apakah satu buku kas di internal benar-benar perlu dilihat semua anggota? Jawabannya jelas, tapi begitu menyentuh pertanggungjawaban dan kewenangan internal yang lebih berat, cara implementasinya adalah tantangan yang lebih kompleks.

Hak akses dari luar ke dalam, isolasi dari sisi pengguna sampai arsitektur dasar — kedua hal yang terjalin inilah persoalan manajemen yang akan dihadapi perusahaan setelah mengadopsi AI. STR Network sudah memecahkan tahap adopsi paling depan, dan sekarang justru lewat pembaruan sistem itu sendiri, mereka mendorong iterasi kerangka manajemen.

3. RAG Slack bot administrasi internal

Sistem ini baru saja di-deploy sehari sebelum wawancara.

Di internal STR Network ada kanal Slack bernama "#help-administrasi", tempat rekan-rekan bertanya: password Wi-Fi, akun dan password perusahaan, pemesanan ruang rapat, naik bus nomor berapa ke kantor STR Network. Sebelumnya, ini ditangani bot keyword-matching yang ditulis dengan Apps Script, dengan database backend di Google Sheet — kalau field-nya tidak cocok, jawabannya tidak keluar. Bahkan satu pertanyaan yang sama bisa memicu dua sampai tiga balasan duplikat.

Feng memindahkan seluruh sistem ke Zeabur: Gemini Embedding 2 API (dirilis 10 Maret 2026) sebagai vector semantik, template PG Vector (dinyalakan satu klik di Zeabur) menyimpan vektor, Python FastAPI sebagai backend. Soal waktu peluncuran, penjelasannya mencerminkan ritme engineering STR Network:

"Tidak ada hubungannya dengan model. Kebetulan saja Gemini Embedding 2 API rilis 10 Maret, lalu masuk ke daftar to-do saya. Sistemnya memang sudah bisa jalan, hanya saja sebelumnya dipicu pakai keyword, tidak ada komponen LLM di dalamnya."

Bukan "model rilis langsung dikerjakan", melainkan kebutuhan ini memang sudah lama ada di daftar to-do, dan tools baru akhirnya membuat prioritasnya naik. Soal peran Zeabur, Feng menggambarkan: "Hubungannya dengan Zeabur sebenarnya adalah: deployment jadi mudah. Karena sebelumnya kami pakai Apps Script untuk menjalankannya, mirip rasanya seperti backend LINE. Sekarang setara dengan membungkus FastAPI, lalu menjalankannya di Zeabur."

RAG-nya juga punya mekanisme iterasi mandiri: ketika sistem tidak menemukan jawaban, ia akan melakukan reverse-lookup mengapa jawabannya tidak ada, menjalankan penilaian semantik, lalu menambahkan kasus tersebut ke database. Feng menekankan bahwa setelah dijalankan beberapa waktu, sistem ini akan menjadi "semakin pintar".

V. Bagaimana sistem-sistem ini berjalan di Zeabur?

Kalau kebutuhan dari sistem-sistem di atas ditumpuk, peran Zeabur bagi STR Network jadi jelas — Zeabur tidak menggantikan tim operasional, melainkan membayangkan ulang seperti apa "men-deploy sistem online dan menjaganya tetap stabil" itu seharusnya dikerjakan: memberdayakan anggota tim yang sudah ada, dibantu Zeabur Agent, untuk mengerjakan hal yang sebelumnya butuh satu tim operasional utuh untuk memikulnya.

Di STR Network, tim teknologinya cuma Feng seorang — dan justru karena itu, dia sendirian bisa mengelola beberapa sistem yang sudah online, tanpa perlu mendalami di host jenis apa mereka berjalan, tanpa perlu merekrut orang khusus untuk masing-masing tugas "men-deploy hal online", "memastikan sistem stabil, tidak meledak tengah malam", dan "menjaga backup serta performa database". Sebagai gantinya, dia mengandalkan tiga fitur Zeabur untuk operasionalnya:

• Deployment template satu klik: titik awal INVITI adalah Postgres, titik awal RAG bot administrasi adalah PG Vector, halaman kerja ditopang Postgres dan Redis. Feng menggambarkan bahwa ini menurunkan jarak ongkos antara "testing lokal vs testing cloud" — bagi seorang engineer yang memikul full-stack sendirian, hal itu langsung menentukan kecepatan iterasi dan testing ide-ide baru.
• Manajemen hybrid cloud: sebagian produksi inti berjalan di server GCP mereka sendiri, sementara deployment, monitoring, dan log semua lewat antarmuka Zeabur. Sebagian sumber daya lain di-deploy melalui resource yang dibeli lewat Zeabur. Sumber daya server-nya hybrid (bahkan STR Network punya mesin Mac di lokasi, dan sedang mempertimbangkan untuk menghubungkannya ke Zeabur juga), tapi antarmuka operasionalnya tetap satu.
• Lapisan abstraksi terpadu: sistem operasional saja sudah memuat enam service (Django, Celery, Redis, Postgres, Nginx, django-celery-beat); ditambah INVITI, RAG bot administrasi, dan sistem inti lain yang berjalan di GCP — semua status kesehatan service bisa dilihat di antarmuka Zeabur yang sama, terkelola secara terpadu dan tervisualisasi.

Tentu, bagi tim yang memang sudah punya orang khusus untuk menjaga lapisan teknis dasar, Zeabur memberdayakan kelompok yang sama untuk mengerjakan operasional lebih cepat dan lebih hemat tenaga, lalu menyalurkan tenaga yang tersisa kembali ke hal-hal yang lebih butuh penilaian domain — mengiterasi arsitektur produk, memastikan kepatuhan keamanan informasi, merencanakan bagaimana sistem akan tumbuh ke depan.

VI. Kembali ke "adopsi AI bukan masalah teknologi"

"Adopsi AI bukan masalah teknologi, melainkan masalah manajemen" — maksud kalimat ini bukan AI tidak penting.

Maksudnya: sebelum AI, harus ada inventarisasi sumber daya dan proses yang lengkap (bahkan sumber data internal yang sudah terakumulasi bertahun-tahun), proses penilaian yang Sunny tinjau berulang sebelum ditulis ke dalam sistem, dan perhitungan presisi atas ongkos komunikasi setiap modifikasi kecil. Begitulah STR Network menangani dua kesulitan besar adopsi AI — utang manajemen dan utang teknis:

Utang manajemen di lapisan dasar, dan utang teknis yang lahir bersamanya, di permukaan terlihat seperti kekacauan teknis — arsitektur terlalu campur aduk, service terlalu banyak, semakin cepat ditulis semakin cepat meledak — tapi pada akarnya, semua adalah masalah "sistem manajemen yang belum didefinisikan dengan baik". STR Network memakai dua hal untuk memecahkan akar ini:

• Struktur tata kelola tiga orang "brief Sunny × Jerry × Feng" yang dibahas di Bagian I dan II, ditambah model hak akses buku kas dan RBAC, sehingga lapisan organisasi sejak awal sudah memetakan dengan jelas: apa yang perlu dikelola, siapa mengelola apa, siapa boleh melihat apa.
• Dev Diagnosis Skill yang baru ditulis Sunny — setiap kebutuhan yang masuk akan didiagnosis sekali; yang di permukaan terlihat seperti masalah teknis tapi di bawahnya sebenarnya manajemen yang belum jelas didefinisikan, akan dicegat di tempat itu juga, mencegah duplikasi pekerjaan ala "bangunan liar".

Setelah utang manajemen di lapisan dasar dilunasi dan struktur kebutuhan menjadi jelas, yang tersisa adalah "operasional" — menyalakan sistem dan menjaganya tetap stabil. Lapisan ini ditangani Zeabur Agent — Postgres dinyalakan satu klik, FastAPI di-push online satu klik, service dipindahkan dari satu host ke host lain, status seluruh service dikumpulkan di satu antarmuka yang sama.

Di lapisan dasar masih ada pertanyaan berikutnya yang menunggu: ketika sistem tumbuh ke kolaborasi multi-orang, multi-host, dan multi-environment, siapa bisa mengakses host mana, siapa bisa mengubah service mana, siapa bisa melihat segmen log mana — itu adalah kebutuhan manajemen yang lahir dari teknologi, dan itulah tantangan yang sedang dijernihkan dan didialogkan STR Network melalui Zeabur.

Bagian tools-nya, di era AI memang terus berubah — dari Apps Script ke FastAPI, dari keyword-matching ke RAG, dari shared cluster ke BYOS — tapi logika inventarisasi di bawahnya tidak berubah.

"AI bukan masalah teknologi, ini masalah manajemen." Begitu kata Sunny.

Daftar Pustaka

• Ho, P., & Chen, Y. (2025-06-26). AI pioneer STR Network: Mengapa terus menghancurkan dan membangun ulang? Untuk membangun AI, beresi dulu "utang manajemen" Anda. Business Weekly edisi 1963.
• Tseng, T. (2025-02-27). Pahlawan di balik layar Night Night Show: Bagaimana tim STR Network memakai AI secara jenius untuk meng-upgrade seluruh tim?. Global Views Monthly.
• Sunny (2026-04-02). How to Read the Vibes. Unggahan publik Facebook + GitHub repository mseatingtpe/dev-diagnosis-skill.
• Lin, Y. (2026-02-23). Shared cluster tidak akan lagi terbuka untuk proyek baru. Zeabur Changelog.