Pelajari cara mengekspor kode sumber dari platform vibe-coding dan mengambil kepemilikan yang bersih: jalankan lokal, atur CI, kelola rahasia, dan siapkan repo siap diserahkan.
Menguasai kode lebih dari sekadar menerima file zip dari sebuah platform. Artinya Anda bisa membangun, menjalankan, mengubah, dan mengirimkan aplikasi tanpa membutuhkan workspace asli, tombol khusus, atau pengaturan tersembunyi. Proyek yang benar-benar Anda miliki berperilaku seperti repo normal: rekan baru bisa meng-clone, menjalankannya di laptop, dan mendeploy lewat pipeline standar.
Kebanyakan kecemasan soal lock-in berasal dari beberapa celah yang sama:
Kejutan lain yang sering muncul adalah ketika aplikasi berjalan baik di versi yang dihosting, tetapi gagal secara lokal karena variabel lingkungan, setup database, atau rahasia tidak pernah dijelaskan.
Ekspor bersih dari platform vibe-coding seharusnya menghasilkan empat hal:
Hal ini penting meskipun Anda tidak berniat meninggalkan platform. Sikap kepemilikan yang kuat adalah asuransi: mengurangi risiko, mempermudah audit, dan menyederhanakan negosiasi jika Anda mempekerjakan agensi, mengumpulkan dana, atau mengganti tim.
Jika Anda menggunakan Koder.ai, ekspor Anda mungkin mencakup stack umum seperti aplikasi web React, backend Go, PostgreSQL, atau aplikasi mobile Flutter. Stack tidak sepenting prinsip: semua yang diperlukan untuk menjalankan harus terlihat di repository, bukan terkunci di lingkungan yang dihosting.
Bayangkan seorang founder menyerahkan aplikasi kepada kontraktor. "Ini reponya" seharusnya cukup. Kontraktor tidak harus memiliki akses ke project platform asli untuk menemukan URL basis API, membuat skema database, atau belajar bagaimana membangun frontend.
Setelah ekspor, Anda seharusnya mendapatkan repository normal yang bisa dibuka di editor, dijalankan di laptop, dan diserahkan ke tim lain tanpa perlu platform asli.
Pada proyek Koder.ai, ekspor sering memetakan ke struktur yang familiar: aplikasi web React, backend Go, dan (jika dibuat) aplikasi mobile Flutter. Nama folder bervariasi, tetapi repo harus jelas menunjukkan di mana tiap bagian berada dan bagaimana mereka terhubung.
Mulailah dengan menemukan entry point dan alur kerja yang dimaksud. Anda ingin file pertama yang men-boot tiap aplikasi, plus skrip yang menunjukkan bagaimana Anda dimaksudkan untuk mengembangkan dan menjalankannya.
Tanda-tanda umum:
package.json plus folder src/ (sering dengan main.tsx atau serupa)go.mod dan folder cmd/ atau main.gopubspec.yaml untuk Flutter dan lib/main.dartREADME atau Makefile di level atas yang menjelaskan cara menjalankan semuanyadocker-compose.yml jika ekspor dimaksudkan untuk dijalankan sebagai sekumpulan layananDependensi harus dipin. Untuk JavaScript, itu berarti ada lockfile (package-lock.json, yarn.lock, atau pnpm-lock.yaml). Untuk Go, berarti go.mod dan go.sum. Ketiadaan pin tidak membuat proyek tidak mungkin dijalankan, tetapi membuat build yang dapat direproduksi menjadi lebih sulit.
Konfigurasi harus terpisah dari kode. Cari contoh seperti .env.example atau config.example.yaml. Anda tidak boleh melihat rahasia nyata (kunci API, password produksi) tercommit dalam ekspor. Jika ada, anggap itu kebocoran dan lakukan rotasi.
Untuk pekerjaan database, temukan folder migrasi (migrations/, db/migrations/) atau file SQL dengan cap waktu. Dalam aplikasi Go + PostgreSQL, Anda mungkin juga melihat kecil migration runner atau skrip yang menerapkan migrasi.
Pemeriksaan cepat: temukan perintah build dan run terlebih dahulu (npm run dev, go run, make, dan sejenisnya). Jika skrip bergantung pada perintah khusus platform, gantilah dengan tooling standar sebelum Anda menyatakan repo independen.
Perlakukan ekspor seperti artifact rilis. Sebelum menjalankan apa pun, lakukan pengecekan cepat "apakah semua ada?". Bagian yang hilang lebih mudah ditangkap sekarang daripada setelah Anda mulai mengubah.
Pemeriksaan kelengkapan praktis adalah mencari "akar" tiap bagian: package.json untuk aplikasi web React, go.mod untuk backend Go, dan file migrasi/seed untuk PostgreSQL.
Buat repo Git baru dari folder ekspor, lalu commit apa yang Anda terima sebelum memperbaiki apa pun. Itu memberi baseline bersih dan membuat perubahan berikutnya mudah direview.
git init
# Optional: set default branch name
# git branch -M main
git add -A
git commit -m "Initial export"
Sekarang jalankan secara lokal dalam langkah-langkah kecil yang bisa diverifikasi. Instal dependensi, buat konfigurasi lokal, mulai database dulu, lalu backend, lalu frontend. Saat melakukannya, tuliskan setiap perintah yang benar-benar Anda gunakan. Catatan itu menjadi README Anda.
Berikut contoh urutan perintah sederhana yang bisa Anda sesuaikan dengan struktur hasil ekspor:
# Frontend
cd web
npm install
npm run dev
# Backend
cd ../server
go mod download
go run ./cmd/server
Sebuah server bisa saja boot sementara aplikasi tetap rusak. Konfirmasi bahwa ia bisa membaca dan menulis data.
Pilih pemeriksaan cepat yang sesuai produk:
Setelah Anda memiliki jalankan lokal yang bekerja, ubah catatan scratch Anda menjadi README.md nyata dengan langkah copy-paste: dari mana menjalankan perintah, urutan memulai layanan, dan variabel lingkungan mana yang diperlukan.
Sebuah ekspor mungkin bisa dijalankan, tetapi masih terasa "dihasilkan" bukan dimiliki. Repo siap serah terima membuatnya jelas di mana sesuatu berada, bagaimana menjalankan proyek, dan bagaimana menjaga konsistensinya.
Mulailah dengan layout level atas yang jelas. Nama kurang penting dibanding konsistensi.
apps/ untuk frontend yang dilihat pengguna (web, mobile)services/ untuk API backend, worker, dan jobshared/ untuk tipe dan utilitas bersamainfra/ untuk template deployment, skrip, dan contoh environmentdocs/ untuk catatan arsitektur dan runbookLalu tambahkan beberapa file kecil yang mengurangi tebakan:
README.md dengan prasyarat dan perintah tepatCONTRIBUTING.md dengan beberapa aturan (branch, PR, tanpa rahasia).gitignore untuk menjaga file env lokal dan output build tetap keluar dari GitJaga README praktis. Jika repo berisi banyak bagian (frontend React, API Go, PostgreSQL), jelaskan urutan untuk menyalakan semuanya dan di mana konfigurasi berada (misalnya, "copy .env.example ke .env").
Lakukan cek mesin-baru: clone ke folder baru dan ikuti README Anda. Jika Anda mengekspor dari Koder.ai, perlakukan ekspor sebagai commit pertama dari proyek independen, dan baru setelah itu undang orang lain.
Setup lokal yang baik menjawab satu pertanyaan cepat: apakah orang baru bisa menjalankan aplikasi dalam waktu kurang dari 15 menit tanpa menebak.
Pilih pendekatan lokal default dan jelaskan secara eksplisit. Instalasi native cepat bagi yang sudah punya tool yang tepat. Container lebih konsisten antar mesin tetapi menambah overhead. Jika mendukung keduanya, tandai satu sebagai default dan yang lain opsional.
Polanya sederhana yang bekerja baik: satu halaman README, satu file contoh env, dan satu perintah bootstrap.
Commit file contoh dengan nilai palsu sehingga orang tahu apa yang perlu diatur tanpa membocorkan rahasia.
# .env.example (example values only)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080
Di README, jelaskan di mana file nyata berada (misalnya, "copy ke .env") dan variabel mana yang wajib vs opsional.
Tambahkan skrip kecil yang menjalankan langkah-bagian membosankan dalam urutan yang benar. Jaga agar terbaca.
#!/usr/bin/env bash
set -euo pipefail
cp -n .env.example .env || true
# Backend deps
cd backend
go mod download
# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh
# Frontend deps
cd ../web
npm install
Untuk rencana database, dokumentasikan tiga hal: bagaimana membuat DB, bagaimana migrasi dijalankan, dan bagaimana mendapatkan data seed untuk run awal yang realistis.
Terakhir, tambahkan health check cepat supaya orang dapat memastikan aplikasi bekerja sebelum mengeksplorasi. Endpoint kecil seperti GET /health yang mengembalikan "ok" (dan memverifikasi konektivitas database) seringkali sudah cukup.
Saat mengekspor proyek, kodenya mungkin milik Anda, tetapi rahasia harus tetap privat. Anggap repo akan dibagikan ke rekan baru.
Mulailah dengan mencantumkan apa yang dibutuhkan aplikasi untuk berjalan. Jangan menebak. Selusuri kode untuk pembacaan konfigurasi (environment variables, file konfigurasi) dan periksa integrasi yang Anda aktifkan.
Inventaris rahasia dasar biasanya mencakup kredensial database, kunci API pihak ketiga, pengaturan auth (OAuth atau JWT), kredensial penyimpanan, dan rahasia spesifik aplikasi seperti kunci enkripsi atau webhook signing secret.
Tentukan di mana tiap rahasia berada di setiap environment. Aturan default yang baik:
.env yang dimiliki developer (tidak di-commit)Jika Anda mengekspor dari platform vibe-coding seperti Koder.ai, anggap apa pun yang terlihat di chat, log, atau panel pengaturan mungkin telah disalin ke banyak tempat. Pindahkan rahasia keluar dari repository segera.
Pendekatan praktis adalah commit template aman (seperti .env.example), jaga nilai nyata keluar dari Git (tambahkan .env ke .gitignore), dan injeksikan rahasia produksi saat deploy.
Jika ada kemungkinan rahasia terekspos selama ekspor, putar rahasia tersebut. Prioritaskan password database, client secret OAuth, dan webhook signing key.
Tambahkan beberapa guardrail agar tidak terulang: pre-commit check untuk pola rahasia yang jelas, pemindaian rahasia di CI, pemuatan konfigurasi yang gagal cepat saat variabel yang dibutuhkan hilang, dan kredensial terpisah per environment.
SECRETS.md singkat membantu pada serah terima. Jaga sederhana: variabel yang dibutuhkan, di mana disimpan per environment, dan siapa yang dapat merotasinya.
Setelah Anda mengambil alih, CI adalah jaring pengaman. Mulailah versi pertama kecil. Setiap push harus membuktikan proyek masih bisa dibuild, pemeriksaan dasar lulus, dan test (jika ada) masih berjalan.
CI harus menjawab satu pertanyaan cepat: "Apakah perubahan ini aman untuk di-merge?" Untuk sebagian besar repo, itu berarti instal dependensi, build, lint, dan jalankan unit test.
Pisahkan job berdasarkan bagian aplikasi supaya kegagalan jelas:
Gunakan caching, tapi jangan biarkan cache menyembunyikan masalah. Saat cache miss, CI masih harus bekerja, hanya lebih lambat.
Prefer satu perintah per langkah (make test, npm run test, dan sejenis) sehingga perintah yang sama bekerja lokal dan di CI. Itu mengurangi kebingungan dan membuat log lebih pendek.
Contoh bentuk (sesuaikan nama dengan repo Anda):
jobs:
web:
steps:
- run: npm ci
- run: npm run lint
- run: npm run build
api:
steps:
- run: go test ./...
- run: go build ./...
Setelah dasar stabil, tambahkan alur rilis sederhana: tag rilis, build artifact, dan simpan sebagai artifact CI. Bahkan jika Anda masih mendeploy dari platform hari ini, artifact yang dapat direproduksi mempermudah berpindah host nanti.
Mengekspor kode hanyalah separuh pekerjaan. Separuh lainnya adalah memastikan proyek berperilaku sama di luar platform.
Ekspor sering bergantung pada environment variables, migrasi, data seed, dan langkah build yang ditangani untuk Anda. Layar kosong atau error database pada jalankan pertama adalah hal normal.
Lakukan satu baseline run sebelum mengubah apa pun: instal deps, set env vars, jalankan migrasi, mulai layanan sesuai urutan. Perbaiki hanya yang diperlukan untuk mencocokkan setup yang diharapkan.
Kecelakaan paling umum adalah meng-commit kunci API nyata atau password, biasanya lewat .env yang disalin atau konfigurasi yang digenerate tool.
Commit hanya template. Simpan nilai nyata di environment lokal atau secret store.
Meng-upgrade paket atau merombak folder segera membuat sulit membedakan apakah masalah berasal dari ekspor atau perubahan Anda.
Dapatkan jalankan yang bekerja dulu, lalu perbaiki di commit terpisah yang kecil.
"Works on my machine" sering berasal dari versi tool yang tidak dipin (Node, Go, Flutter, bahkan package manager).
Pin versi runtime di tempat yang jelas (file atau README), simpan lockfile (package-lock, go.sum, pubspec.lock), dan verifikasi setup di mesin kedua atau container baru.
Serah terima gagal karena tak seorang pun ingat langkah aneh yang diperlukan untuk menjalankan app. Tuliskan saat masih segar: env vars yang dibutuhkan, cara menjalankan migrasi, ke mana log pergi, dan cara mereset state lokal.
Tim tiga orang membangun portal pelanggan di Koder.ai: aplikasi web React, API Go, dan database PostgreSQL. Saat waktunya menyerahkan ke tim pengembang luar, mereka ingin ekspor terasa seperti repo normal yang bisa dijalankan pada hari pertama.
Hari 1: mereka mengekspor, membuat repo Git baru, dan menjalankan secara lokal. Frontend berjalan, tetapi API gagal karena variabel lingkungan hilang. Mereka tidak menebak. Mereka membaca kode, mengidentifikasi kunci yang dipakai, dan membuat .env.example dengan placeholder. Nilai nyata tetap di password manager dan .env lokal.
Mereka juga menyadari port dan pengaturan CORS baik di platform tetapi perlu default lokal. Mereka menetapkan default yang dapat diprediksi (misalnya, API di 8080 dan web di 3000) sehingga mesin baru berperilaku sama.
Hari 2: mereka menambahkan migrasi dan skrip seed kecil yang membuat user demo dan beberapa baris data. Lalu mereka menulis README singkat yang mencakup prasyarat, perintah menjalankan, dan cara memverifikasinya (endpoint health untuk API dan login contoh untuk UI).
Hari 3: mereka menambahkan workflow CI dasar yang menjalankan test, linting, dan build untuk kedua layanan pada setiap pull request. Untuk staging, mereka mendokumentasikan rencana sederhana: build container, set secret di environment, jalankan migrasi saat deploy, dan sediakan opsi rollback.
Handoff yang baik biasanya mencakup repo yang bisa berjalan secara lokal dari fresh clone, .env.example plus catatan di mana rahasia disimpan, migrasi dan data seed, cek CI yang gagal cepat, dan catatan deploy singkat untuk staging dan rollback.
Sebelum Anda menyatakan ekspor selesai, buktikan proyek bisa hidup di luar platform. Jika pengembang lain bisa menjalankannya tanpa menebak, Anda berada di kondisi baik.
Gunakan checklist akhir ini:
Setelah pemeriksaan teknis, buat kepemilikan eksplisit. Tentukan siapa yang bertanggung jawab pembaruan dependensi, perubahan infrastruktur (database, queue, DNS), dan rilis. Jika tak ada yang bertanggung jawab, repo akan membusuk meskipun aplikasi bekerja hari ini.
Rencanakan jendela stabilisasi singkat sebelum pekerjaan fitur besar. Dua sampai lima hari kerja sering cukup untuk memperbaiki kekasaran ekspor, mengeraskan README, dan menghilangkan isu "works on my machine".
Jika Anda menggunakan Koder.ai (koder.ai), ekspor ditambah fitur seperti snapshot dan rollback membuatnya lebih mudah untuk iterasi sambil mengeraskan repo. Setelah repo stabil, jadikan Git sumber kebenaran dan perlakukan ekspor platform berikutnya sebagai checkpoint, bukan riwayat utama.
Tentukan milestone handoff berikutnya dalam bahasa biasa: "Pengembang mana pun bisa menjalankannya dalam 30 menit." Lalu uji dengan meminta orang baru mengikuti README di mesin bersih. Pertanyaannya menjadi daftar tugas akhir Anda.
Treat ownership as independence: you can build, run, change, and deploy the app from a normal repo without needing the original platform project, special UI settings, or hidden build steps.
A good test is: can a new teammate clone the repo and get it running using only the README?
Start with a quick completeness check:
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ or similar).docker-compose.yml).If anything required to run is only described in a UI or chat, write it down and move it into the repo.
Do it in small, verifiable steps:
.env.example → .env.Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.
Because the hosted environment often had things you never made explicit:
Fix this by making the setup visible: .env.example, migration scripts, and a README with exact commands.
A server “starting” isn’t enough—verify real data flow:
If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.
Default approach:
.env.example with fake values..env to .gitignore.If you find real keys in the repo, assume they’re compromised and rotate them. Prioritize database credentials, OAuth client secrets, and webhook signing secrets.
Keep the first CI simple and consistent with local commands:
go test ./... and build the backend.Make CI call the same scripts you expect developers to run (for example make test or npm run build). That reduces “works locally but not in CI.”
Yes—if you want a predictable handoff. A good default is:
README.md with copy-paste commands..env.example describing required vs optional variables.Aim for a new developer being able to run the app in 15–30 minutes without guessing.
Common structure is:
apps/ for frontends (web, mobile).services/ for APIs and workers.shared/ for shared types/utilities.infra/ for deployment templates and environment examples.The exact names don’t matter as much as making it obvious what runs where, and how the pieces connect.
A practical sequence:
Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.