DEV Community: Ifan Jaya Suswanto Zalukhu

AI Tools untuk Process Ideation, Prepare Topik, sampai Simulasi Delivery Talk

Ifan Jaya Suswanto Zalukhu — Fri, 26 Jun 2026 10:36:00 +0000

Setiap kali dapat kesempatan untuk sharing, proses prepare materinya sekarang hampir selalu ditemani AI. Bukan karena malas mikir 😆, tapi karena memang masing-masing AI tools ternyata punya kelebihan yang berbeda-beda.

Ada yang saya pakai untuk brainstorming, ada yang membantu melihat flow presentasi, sampai ada yang membantu membuat slide yang lebih proper.

Workflow yang saya pakai juga bukan sesuatu yang baku. Kadang berubah-ubah tergantung jenis event dan audiensnya. Tapi kurang lebih alurnya seperti ini.

1. Mulai Brainstorming dengan ChatGPT

Sebagai generasi yang… entah kenapa lebih sering diskusi sama ChatGPT dibanding manusia 😅, biasanya semua dimulai dari sini.

Prompt awal saya kurang lebih seperti ini:

Saya akan mengisi talk di event berikut. Berdasarkan brief event ini dan history diskusi kita sebelumnya, menurutmu topik apa yang cocok saya bawakan? Tolong jelaskan juga outline dan detail pembahasannya.

Lalu saya lampirkan brief event tersebut.

Menurut saya, salah satu kekuatan ChatGPT bukan cuma karena dia bisa kasih ide, tapi karena dia juga “ingat” hal-hal yang pernah kita diskusikan sebelumnya.

Misalnya project yang pernah saya kerjakan, pengalaman implementasi AI di kantor, artikel yang pernah saya tulis, atau pengalaman menjadi speaker sebelumnya.

Jadinya rekomendasi yang diberikan terasa lebih personal dan lebih dekat dengan pengalaman sendiri.

Ini penting.

Karena menurut saya, audiens biasanya lebih suka mendengar pengalaman nyata dibanding presentasi yang isinya teori semua.

Kalau kita membawakan sesuatu yang memang pernah kita alami, delivery juga biasanya jauh lebih santai. Rasanya lebih seperti ngobrol daripada menghafal slide.

Setelah ChatGPT memberikan beberapa ide, saya hampir tidak pernah langsung menerimanya mentah-mentah.

Biasanya saya baca lagi sambil berpikir:

“Oke… ini menarik. Tapi ada pengalaman yang belum kamu tahu nih.”

Kalau saya pernah membaca artikel yang relevan, saya kasih link-nya.

Kalau saya punya project yang bisa dijadikan use case, saya minta dia pelajari.

Kalau ada insight yang baru kepikiran, saya tambahkan lagi ke context.

Lalu diskusi berlanjut lagi.

Proses ini bisa bolak-balik berkali-kali sampai outline materinya benar-benar terasa pas.

2. NotebookLM untuk Latihan Delivery dan Cari Ide Visualisasi

Setelah outline mulai matang, saya pindah ke Google NotebookLM.

Semua context tadi saya masukkan:

Brief event
Draft hasil brainstorming dari ChatGPT
Artikel atau referensi tambahan
Kalau perlu project atau dokumentasi yang relevan

Baru setelah itu saya mulai bermain dengan beberapa fiturnya.

🎙️ Ringkasan Audio (Podcast)

Ini mungkin fitur favorit saya.

NotebookLM akan membuat percakapan seperti podcast antara dua orang. Satu orang akan bertanya berdasarkan context yang kita berikan.

Satunya lagi menjelaskan jawabannya. Ini cukup membantu untuk membayangkan bagaimana nanti materi itu disampaikan.

Dari sini biasanya saya mulai memperhatikan:

Hook pembuka seperti apa yang menarik.
Urutan cerita yang lebih enak diikuti.
Bagian mana yang terlalu panjang.
Transisi antar topik.
Kalimat-kalimat yang terdengar lebih natural ketika diucapkan.

Yang menarik lagi, kita bisa mengubah gaya pembahasannya.

Mau dibuat lebih mendalam, diringkas, dibuat seperti debat, atau bahkan lebih kritis juga bisa.

Kadang setelah mendengar versi podcast ini malah muncul ide baru yang sebelumnya tidak kepikiran.

Bonusnya, materi juga jadi lebih gampang diingat karena sudah beberapa kali “didengar”, bukan cuma dibaca.

🖼️ Slide Presentasi

Setelah itu saya lanjut mencoba fitur Slide Presentasi.

Tujuannya bukan untuk langsung dipakai. Lebih ke mencari inspirasi.

Misalnya:

Urutan slide seperti apa yang lebih nyaman.
Visual seperti apa yang cocok.
Ilustrasi apa yang bisa dipakai.
Flow presentasinya bagaimana.

Kadang saya generate berkali-kali hanya untuk melihat pendekatan yang berbeda.

Lucunya, justru di tahap ini sering muncul ide-ide baru.

Ternyata melihat materi dalam bentuk visual bisa memancing perspektif yang berbeda dibanding hanya membaca teks.

❓ Simulasi Q&A

Fitur terakhir yang sering saya gunakan adalah Kartu Tanya Jawab dan Quiz.

Ini cukup membantu untuk latihan sebelum hari H.

Minimal saya jadi punya gambaran pertanyaan apa saja yang kemungkinan akan muncul dari peserta.

Walaupun… tetap saja nanti ada satu pertanyaan yang sama sekali tidak kepikiran. Itu sudah hukum alam seorang speaker. 😂

3. AI IDE untuk Membuat Slide yang Lebih Fleksibel

Kalau konsep materi dan alurnya sudah fix, baru saya mulai membuat slide.

Di tahap ini saya lebih sering menggunakan AI IDE seperti Kiro, Claude Code, atau tools AI berbasis CLI lainnya.

Kenapa?

Karena saya lebih suka membuat slide dalam bentuk HTML dibanding PowerPoint biasa.

Dengan HTML saya bisa lebih bebas mengatur:

layout,
animasi,
interaksi,
responsive design,
sampai detail kecil yang biasanya cukup ribet kalau dikerjakan manual.

Workflow-nya biasanya sederhana.

ChatGPT membantu menyusun isi materi.
NotebookLM membantu mengevaluasi flow dan delivery.
Lalu AI IDE membantu mengubah semuanya menjadi slide yang lebih polished.

Contoh slide yang terakhir saya buat:

https://ifanzalukhu97.github.io/slides/from-problem-to-product.html

Penutup

Kurang lebih seperti itu workflow yang paling sering saya pakai saat menyiapkan materi sharing.

Apakah selalu mulus? Tentu tidak. 😆

Fun fact, ide terbaik saya justru sering muncul ketika deadline submission sudah tinggal hitungan jam atau bahkan malam sebelum acara.

Entah kenapa otak baru merasa, “Oke, sekarang waktunya bekerja.”

Mungkin memang benar ada istilah The Power of Kepepet.

Walaupun… saya tetap tidak merekomendasikan dijadikan best practice. 🤣

Kiro as AI Partner for MS SQL Server Optimization on .NET Core: Yang Biasa Berhari-hari, Sekarang Hitungan Jam

Ifan Jaya Suswanto Zalukhu — Sat, 13 Jun 2026 18:55:19 +0000

English version: Kiro as AI Partner for MS SQL Server Optimization on .NET Core: What Used to Take Days Now Takes Hours

Dulu, nyari query yang bikin database spike itu bisa makan berhari-hari. Apalagi kalau aplikasinya pakai ORM dan LINQ di .NET Core — yang terlihat di database adalah raw SQL, sementara yang ditulis di codebase bentuknya berbeda jauh. Yang nyari capek, yang nge-fix juga capek. Sekarang? Hitungan jam — dan bonusnya, sambil belajar hal baru juga.

Ceritanya begini. Kalau kamu pernah kerja di aplikasi yang pakai ORM (Object-Relational Mapping — semacam "penerjemah otomatis" antara code dan database), pasti familiar sama situasi ini: database tiba-tiba lambat, kamu dapet raw query yang jadi biang kerok, tapi di codebase kamu nulis pakai syntax ORM yang bentuknya beda jauh dari SQL mentah itu.

Buat yang belum pernah deal sama ORM, bayangin gini: kamu nulis pesan dalam bahasa Indonesia, lalu ada "penerjemah otomatis" yang convert jadi bahasa Jepang sebelum dikirim ke penerima. Suatu hari ada masalah di pesan yang terkirim — tapi kamu cuma bisa lihat versi bahasa Jepang-nya. Nyari bagian mana dari tulisan Indonesia kamu yang bikin terjemahan-nya bermasalah? Itu effort-nya yang bikin pengen balik tidur aja.

Sekarang dengan bantuan Kiro, cukup kasih raw query + akses ke codebase, dia otomatis nyari bagian mana di code yang nge-generate query bermasalah itu. Yang dulu butuh berhari-hari, sekarang bisa selesai dalam hitungan jam — dan itu baru tahap investigasi, belum termasuk fixing-nya.

Ceritanya Kenapa Bisa Pakai Kiro

Akhir-akhir ini lagi aktif pakai Kiro di tempat kerja. Awal tahun lalu kantor dapat credits melalui program Kiro for Startup, jadi ya sekalian dimaksimalkan.

Selain buat debug dan explore query di MS SQL Server, kadang pakai Kiro juga buat analisa log AWS CloudWatch — sambil kasih context aplikasi yang running biar analisa-nya lebih akurat dan gak generic.

Di tulisan kali ini, saya mau sharing gimana pakai Kiro sebagai partner beberapa minggu terakhir buat improve query performance di aplikasi .NET Core. Kenapa "partner"? Karena Kiro-nya gak boleh langsung akses ke database — jadi wajib melalui perantara saya. Kita discuss, kolaborasi, dan nge-solve bareng. Bukan AI yang dikasih tombol terus disuruh jalan sendiri.

Waktu Database Mulai Teriak

Beberapa waktu lalu, metrics database kami menunjukkan alarm — data I/O sering spike. Ini harus dicek dan di-improve sebelum user mulai ngerasain.

Dulu kayak yang saya bilang tadi — ini pekerjaan yang paling malas saya kerjakan. Ribet-nya di level: kita cuma dapet raw query yang di-generate ORM, sementara di codebase kita nulis pakai syntax yang bentuknya jauh berbeda. Gak langsung ketahuan code bagian mana yang nge-generate query lambat itu.

Buat gambaran lebih simpel: ORM itu kayak kamu bilang ke asisten "ambilin data pesanan yang aktif, urutin dari yang terbaru ya." Si asisten nerjemahin instruksi itu jadi perintah teknis ke database. Nah kalau ternyata cara dia nerjemahin gak efisien dan bikin database lambat, kamu harus reverse-engineer dari hasil terjemahan teknis itu balik ke instruksi awalmu — dan itu yang bikin pusing.

Gimana Flow-nya: Kiro Gak Bisa Sentuh Database

Karena database gak bisa dikasih akses langsung ke AI, maka flow-nya begini: Kiro kasih instruksi query apa yang perlu saya jalankan, saya eksekusi di database, dan hasilnya saya kirim balik ke dia untuk dianalisa.

Saya mulai dengan kasih context:

"Saya punya database MS SQL Server yang beberapa menit lalu spike data I/O-nya. Kita akan cari tahu proses/query apa penyebabnya. Kamu info ke saya query apa yang perlu dijalankan, nanti saya yang eksekusi dan kirim hasilnya untuk kamu analisa."

Dari situ, Kiro kasih beberapa diagnostic query yang perlu saya run:

Top I/O queries — query dengan physical reads/writes tertinggi
Currently running I/O heavy — query yang sedang berjalan saat spike terjadi
I/O stats per database file — file mana yang paling banyak I/O-nya
I/O wait stats — wait type terkait I/O yang dominan
Current indexes — semua index yang ada di database
Index usage stats — seberapa sering index digunakan vs di-update
Missing indexes — rekomendasi index dari SQL Server sendiri
Index fragmentation — index yang terfragmentasi bisa bikin I/O berlebihan
Resource stats — historical resource usage (khusus Azure)
I/O stats per table — tabel mana yang paling banyak menghasilkan I/O

Setelah saya jalankan semua dan kirim hasilnya, Kiro langsung menganalisa dan kasih output yang cukup komprehensif — dari executive summary sampai rencana aksi per-priority.

Hasil Analisa: Bukan Cuma "Query-nya Lambat"

Kiro kasih temuan lengkap dengan severity level:

Temuan	Severity
Read latency sangat tinggi (130-169ms avg)	🔴 Critical
86% wait time = PAGEIOLATCH_SH (read I/O)	🔴 Critical
Missing index pada kolom filter utama	🔴 Critical
3 index tidak pernah dibaca (0 reads, 24K+ writes)	🟡 Warning
Eager loading sebelum pagination di ORM	🔴 Critical

Yang menarik, dia gak berhenti di level database. Dia langsung identify pattern di code yang bermasalah:

// Pattern bermasalah yang ditemukan Kiro:
var data = _db.Orders
    .Include(a => a.OrderItems)      // ← Eager load SEMUA items dulu
    .AsNoTracking()
    .Where(x => x.TenantId == tenantId && !x.Deleted)
    .OrderByDescending(x => x.UpdatedAt)
    .Skip(page * size)
    .Take(size)
    .ToListAsync();

Buat non-.NET developer: .Include() itu kayak bilang "sekalian ambilin semua data relasi-nya juga." Masalahnya ini ditaruh sebelum pagination — artinya database load semua data beserta relasi-nya ke memory dulu, baru dipotong per halaman. Kalau datanya jutaan rows? Ya Out of Memory.

Kiro kasih rekomendasi fix dengan pendekatan 2-step:

// Step 1: Ambil ID aja dulu (ringan, tanpa relasi)
var pagedIds = await _db.Orders
    .Where(x => x.TenantId == tenantId && !x.Deleted)
    .OrderByDescending(x => x.UpdatedAt)
    .Skip(page * size)
    .Take(size)
    .Select(x => x.Id)
    .ToListAsync();

// Step 2: Baru load full data + relasi, cuma untuk ID yang sudah di-page
var result = await _db.Orders
    .Include(a => a.OrderItems)
    .AsNoTracking()
    .Where(x => pagedIds.Contains(x.Id))
    .ToListAsync();

Konsepnya universal: jangan load semua dulu baru potong — potong dulu, baru load yang diperlukan. Ini applicable di framework dan bahasa apapun yang punya ORM.

Selain fix di level code, Kiro juga kasih rencana aksi di level database:

Create missing index buat kolom yang sering di-filter tapi belum ada index-nya
Drop unused index yang gak pernah dibaca tapi terus di-update setiap ada write (cost tanpa benefit)
Disable auto-index di Azure yang kadang malah bikin overhead karena create index yang ternyata gak berguna

Kenapa Hasilnya Beda dari Sekadar Paste Query ke AI

Kalau dilihat rencana aksi di atas, Kiro gak cuma menganalisa raw query yang lambat terus kasih saran generic "tambahin index." Yang bikin beda: dia juga mempelajari code backend .NET Core yang jadi sumber query tersebut.

Jadi misalnya dari raw query yang lambat, dia langsung bisa trace sendiri — "Oh ini query-nya di-generate dari OrderController.GetDataTableParams, line sekian, di repository method GetOrdersWithDateFilter." Saya gak perlu kasih tahu file mana — dia cari sendiri di codebase.

Dari situ saran-nya jadi spesifik ke situasi kita, bukan template jawaban:

Query yang perlu di-tuning bukan cuma dari sisi SQL, tapi juga dari sisi gimana ORM nge-generate-nya. Contohnya .Include() yang posisinya bikin database load jutaan row sebelum pagination jalan — itu saran refactor di level code, bukan di level database.
Ada fitur Azure yang ternyata kontra-produktif di setup kita: auto-index yang aktif tapi malah bikin index yang gak pernah dibaca, nambah write cost ~47K updates tanpa benefit sama sekali.
Index yang dia sarankan buat di-drop itu bukan tebakan. Dia cross-check dari usage stats (0 reads, puluhan ribu writes) dan confirm bahwa memang gak ada query di codebase yang butuh index tersebut.

Ini yang beda dari cuma kasih satu potongan query ke AI terus minta pendapat. Karena Kiro punya akses ke seluruh codebase, dia bisa connect the dots — dari "query lambat di database" ke "code pattern di aplikasi yang nge-generate query itu" — dan kasih solusi yang nyambung di kedua sisi sekaligus.

AI Bukan Bikin Bodoh — Malah Jadi Teman Belajar

Hal yang sering saya dengar: "AI bikin kita makin bodoh dan malas belajar." Pengalaman saya di case ini justru kebalikannya.

Begini ceritanya. Waktu Kiro nemuin pattern bermasalah di codebase, dia gak cuma bilang "ini salah, ganti jadi begini." Dia jelaskan kenapa itu salah, apa yang terjadi di balik layar, dan kapan pattern itu sebenernya boleh dipakai. Dan saya — yang udah bertahun-tahun nulis code .NET — baru ngeh beberapa hal fundamental yang selama ini terlewat.

Yang bikin ini jadi "teman belajar" dan bukan sekadar autocomplete pintar: setiap kali Kiro nemuin sesuatu yang menarik, saya minta dia jelaskan lebih detail dan simpan jadi file markdown tersendiri. Judulnya saya buat kayak catatan belajar — "What I Learned Today: Kenapa .ToLower() di LINQ Query Bikin Database Lambat."

File-file itu kemudian saya generate jadi PDF dan share ke Slack tim. Jadi bukan cuma saya yang belajar — satu tim ikut dapat insight-nya.

Ini beberapa contoh yang saya pelajari dari proses ini:

.ToLower() di ORM Query Ternyata Bikin Database Lambat

Kiro nemuin pattern ini tersebar di banyak repository:

// ❌ Bikin index gak bisa dipakai
db.Products.Any(x => x.Code.ToLower() == code.ToLower());

Kenapa bermasalah? ORM nerjemahin .ToLower() jadi function LOWER() di SQL. Ketika ada function yang di-apply ke kolom database di WHERE clause, index jadi gak bisa dipakai — SQL Server harus scan semua row satu per satu.

Di tabel dengan 1.6 juta rows: yang harusnya < 1 milidetik jadi 2-5 detik. Dan di case kita, function ini dipanggil ~2,400 kali dalam 1 jam. Itu artinya 2,400 full table scan yang seharusnya gak perlu.

Ternyata database kami pakai collation Case Insensitive (CI) — artinya perbandingan string sudah otomatis case-insensitive tanpa perlu function apapun:

// ✅ Index terpakai, hasil sama karena collation DB sudah CI
db.Products.Any(x => x.Code == code);

Yang Kiro jelaskan dan bikin saya "ohhh" itu bedanya context: kalau query-nya ke database (LINQ-to-SQL), .ToLower() gak perlu karena collation yang handle. Tapi kalau data sudah di-load ke memory (LINQ-to-Objects), .ToLower() atau StringComparison.OrdinalIgnoreCase tetap wajib karena C# itu case-sensitive. Syntax-nya sama, behavior-nya beda total tergantung context. Bertahun-tahun nulis LINQ dan baru kali ini benar-benar paham bedanya.

Kondisi OR yang Ternyata Redundan

Pattern ini ditemukan di fitur sync mobile:

// ❌ Redundan dan bikin index gak optimal
.Where(a => a.UpdatedAt >= param || a.CreatedAt >= param)

Dua masalah:

OR di dua kolom berbeda bikin database gak bisa pakai index secara efisien — harus scan dua range terpisah lalu merge hasilnya
Kondisi CreatedAt itu redundan — karena di logic aplikasi kita, setiap record baru dibuat, UpdatedAt di-set sama dengan CreatedAt. Dan setiap kali di-update, cuma UpdatedAt yang berubah. Jadi UpdatedAt selalu >= CreatedAt

Yang bikin ini jadi momen belajar: Kiro gak cuma bilang "hapus aja OR-nya." Dia trace ke SaveChangesHelper di codebase, tunjukin logic-nya — bahwa di entity lifecycle kita, UpdatedAt selalu di-set bareng CreatedAt saat insert, dan cuma UpdatedAt yang berubah saat update. Jadi secara matematis, kondisi OR itu gak pernah menambah hasil apapun.

Cukup:

// ✅ Satu kondisi, index optimal
.Where(a => a.UpdatedAt >= param)

Dan masih ada beberapa hal lain yang saya pelajari — cukup banyak sampai sepertinya perlu dipisah jadi artikel tersendiri nanti.

Point-nya: selagi kita bisa prompting dengan tepat dan punya curiosity buat nanya "kenapa?", AI malah jadi accelerator buat belajar. Dia bukan pengganti berpikir — dia pembuka pintu ke hal-hal yang selama ini gak kita tahu ada. Dan kalau kita rajin simpan insight-nya, satu sesi belajar bisa jadi knowledge sharing buat satu tim.

Diskusi yang Berhasil Sayang Kalau Dibuang — Jadi Workflow Aja

Ini bagian yang menurut saya paling impactful.

Setelah diskusi panjang — bolak-balik kirim query, terima analisa, diskusi solusi — saya mulai sadar: "Pattern-nya udah ketemu. Kalau besok database lain spike, masa harus ulang dari awal lagi?"

Jadi saya minta ke Kiro: dari diskusi kita hari ini, formalisasi jadi sesuatu yang reusable.

Konkretnya:

Query-query diagnostic tadi, simpan ke folder sql-audit/ — pisahkan per file berdasarkan tujuannya
Buatkan satu template prompt yang bisa langsung dipakai tanpa perlu ulang diskusi dari awal

Dan Kiro langsung eksekusi. Hasilnya:

Folder sql-audit/ — semua diagnostic query tersusun rapi per file sesuai urutan investigasi. Kedepannya kalau ada masalah I/O, gak perlu mikir "harus mulai dari mana?" — tinggal buka folder, run satu per satu.

#	File	Tujuan
1	`01_top_io_queries.sql`	Top query penyebab I/O historis
2	`02_currently_running_io_heavy.sql`	Query yang berjalan saat spike
3	`03_io_stats_per_database_file.sql`	Latency per database file
4	`04_io_wait_stats.sql`	Wait type I/O yang dominan
5	`05_current_indexes.sql`	Review semua index
6	`06_index_usage_stats.sql`	Index terpakai atau sia-sia
7	`07_missing_indexes.sql`	Rekomendasi index dari SQL Server
8	`08_index_physical_stats.sql`	Fragmentasi index
9	`09_azure_resource_stats.sql`	Resource usage (Azure)
10	`10_io_per_table.sql`	Tabel dengan I/O tertinggi

Template Prompt (db-query-optimization-prompt.md) — instruksi lengkap: apa yang harus Kiro analisa, format output yang diharapkan, severity classification, dan rencana aksi yang harus di-generate. Semacam "SOP" yang tinggal dipanggil.

Sekarang kalau ada database spike, flow saya literally cuma:

Menggunakan prompt di bawah ini, tolong analisa hasil performance database ini.

File prompt: query-optimization/db-query-optimization-prompt.md
Hasil SQL audit terbaru: /sql-audit

Done. Gak ada diskusi panjang lagi. Gak ada "eh kemarin kita bahas apa ya." Semuanya sudah ter-encode di template.

Takeaway-nya: diskusi panjang sama AI itu berharga, tapi lebih berharga lagi kalau kamu convert hasilnya jadi checkpoint yang reusable. Banyak orang pakai AI tapi knowledge dari diskusi-nya "buang" begitu aja — chat ditutup, ilang. Padahal kamu bisa minta AI-nya formalisasi jadi prompt template, folder terstruktur, atau workflow yang bisa jalan tanpa context sebelumnya.

Gimana Kalau Besok Mau Lanjut Tapi Chat-nya Udah Ilang?

Satu masalah lagi yang muncul di awal-awal: gimana melanjutkan progress lintas hari?

Contohnya, tanggal 13 kita temuin masalah dan apply fix. Tapi butuh beberapa hari buat lihat impact-nya. Pas mau lanjut diskusi tanggal 15 atau 28, chat sebelumnya sudah tertutup dan ribet nyarinya.

Solusinya simpel: setiap selesai satu session analisa, minta Kiro simpan hasilnya ke file dengan format tanggal:

query-optimization/orders-db/2026-05-13_initial_analysis.md
query-optimization/orders-db/2026-05-28_follow_up_review.md

Di dalamnya tercatat semua: temuan, saran, yang sudah di-fix, yang belum, reasoning di balik setiap keputusan. Termasuk hal kayak "tanggal 13 Kiro sarankan buat index X, tapi di follow-up tanggal 28 minta dihapus karena setelah code di-refactor ternyata gak efektif lagi."

Jadi prompt selanjutnya tinggal:

Analisa hasil performance database ini.
- File prompt: db-query-optimization-prompt.md
- Hasil SQL audit terbaru: /sql-audit
- Konteks diskusi sebelumnya: query-optimization/orders-db/

Kiro langsung punya full context. Diskusinya berkelanjutan, saling melengkapi, dan AI-nya dapat gambaran luas tanpa harus dijelaskan ulang dari nol setiap session baru.

Yang Gak Disangka: Catatan Audit Jadi Penjaga Code Review

Yang gak saya sangka — folder change log itu ternyata punya kehidupan kedua. Sekarang folder itu jadi bagian dari code review automation.

Salah satu rule di code review skill agent kami:

"Pastikan perubahan code mengikuti best practice dan menghindari kesalahan yang pernah dilakukan — datanya ada di folder query-optimization/. Pastikan setiap perubahan baru optimal dari sisi query maupun index."

Jadi saat AI melakukan code review pull request developer, dia juga cross-check sama history kesalahan yang pernah terjadi. Feedback loop-nya tertutup — kesalahan yang sama diminimalisir tanpa bergantung pada ingatan manusia.

Dari yang awalnya cuma "debug database spike," sekarang jadi:

Investigation tool — folder sql-audit buat diagnostic cepat
Knowledge base — insight baru yang di-share ke tim
Reusable workflow — prompt template yang tinggal pakai
Continuous context — change log sebagai memory lintas session
Prevention mechanism — code review guard dari historical mistakes

Satu masalah, lima output. Gak direncanakan dari awal — tapi karena setiap langkah dibikin reusable, domino-nya jalan sendiri.

Itu sharing kali ini. Kiro bukan cuma bikin kerjaan lebih cepat — tapi juga bikin proses belajar lebih terstruktur, workflow lebih repeatable, dan knowledge gak hilang di chat yang tertutup.

Yang capek bukan database-nya. Yang capek itu manusia yang harus ulang-ulang proses yang sama tanpa sistem.

Sampai jumpa di tulisan selanjutnya. 🙌

About Me

Halo, nama saya Ifan Jaya Suswanto Zalukhu. Di tahun 2026 ini adalah tahun kedua sebagai AWS Community Builder, sekaligus Co-Lead AWS User Group Medan. Suka sharing dan excited belajar hal baru — terutama di intersection cloud, AI, dan engineering productivity.

#1 Cloud & Coffee - AWS UG Medan

Ifan Jaya Suswanto Zalukhu — Sun, 21 Dec 2025 12:38:11 +0000

Cloud & Coffee adalah meetup format baru yang kita mulai coba di AWS User Group Medan. Meetup ini dibuat dengan konsep yang lebih casual dan nyaman: ngobrol santai, sharing, dan real conversation. Jumlah pesertanya juga dibatasi, sekitar 5–20 orang, supaya semua orang punya ruang buat ikut terlibat.

Di sini, semua peserta bebas share pengalaman mereka seputar teknologi dan AWS. Mulai dari apa yang lagi dipelajari minggu ini, challenge yang lagi dihadapi (atau sudah berhasil di-solve) di tempat kerja, sampai showcase project atau product yang lagi dikembangkan pakai AWS.

Setiap orang bisa langsung maju ke depan dan bawain topiknya sekitar 5–15 menit. Karena konsepnya santai, mau pakai slide boleh, tanpa slide juga nggak masalah, bahkan langsung demo code pun oke banget. Peserta juga boleh membawa makanan atau snack sendiri untuk dibagi bersama, jadi vibes-nya benar-benar cozy dan nggak kaku. Karena jumlah pesertanya nggak banyak, diskusi jadi lebih hidup, interaktif, dan nggak satu arah doang.

https://www.meetup.com/aws-user-group-medan/events/312403488/

Format baru ini kita inisiasi bareng teman-teman di AWS User Group Medan: Albert @albert_suwandhi (AWS Hero), Lintang Gilang Pratama @lintanggilang (AWS Community Builders), dan saya sendiri, Ifan @ifanzalukhu97 (AWS Community Builders). Tujuan besarnya sederhana: pengen AWS User Group Medan bisa lebih aktif dan konsisten bikin event.

Dari pengalaman sebelumnya, ada beberapa tantangan yang sering kita hadapi:

Persiapan lokasi, kerja sama, dan hal teknis lain sebelum event
Kalau merangkap sebagai speaker, harus prepare topik dan bikin slide yang kadang cukup makan waktu
Speaker sering itu-itu saja, yang akhirnya bisa bikin peserta bosan
Padahal sebenarnya banyak peserta AWS UG Medan yang sudah jago dan aktif pakai AWS, tapi jarang yang mau submit / tampil sebagai speaker

Dari situ kita coba gali lebih dalam. Kenapa sih banyak yang ragu buat jadi speaker? Beberapa alasan yang sering kami dengar:

Nervous kalau harus ngomong di depan banyak orang
Merasa ilmunya “belum senior / pro”, masih banyak yang lebih jago
Punya topik menarik, tapi cuma cukup buat 5–10 menit
Dan lain-lain

Dari kendala-kendala ini, akhirnya kepikiranlah format Cloud & Coffee. Harapannya, meetup bisa diadakan di cafe, peserta cukup datang, pesan kopi atau snack (atau bawa sendiri), lalu join diskusi. Dari sisi organizer juga jadi lebih ringan dan nggak ribet.

Kami benar-benar ingin lebih banyak teman-teman lokal yang mau ikut berbagi pengalaman mereka, meskipun masih di level pemula. Karena faktanya, saat diskusi berlangsung, banyak peserta yang sebenarnya punya use case nyata: kesalahan umum, kejutan biaya cloud, sampai kebingungan saat baru mulai menggunakan AWS.

Namun, sering kali mereka malu untuk berbicara, apalagi di forum dengan banyak orang. Karena itu, kami mencoba format baru ini: jumlah peserta lebih sedikit, lebih minim formalitas, dan tanpa tekanan. Format ini terasa pas untuk sekitar 20–30 orang.

Topik pembahasan juga jadi lebih beragam karena setiap orang datang dengan hal yang sedang mereka eksplor atau minati belakangan ini. Selain itu, Cloud & Coffee juga bisa menjadi langkah awal untuk latihan public speaking mulai dari audiens kecil, sebelum nantinya naik ke event dengan peserta yang lebih banyak.

Harapan kami, dengan format seperti ini, AWS UG Medan ke depannya bisa lebih aktif karena yang menggerakkan dan mengisi sharing bukan hanya segelintir orang. Selain itu, ini juga bisa menjadi portfolio awal bagi teman-teman yang ingin apply AWS Community Builder, sehingga ke depannya semakin banyak AWS Community Builder dari Medan dan komunitasnya semakin hidup dan aktif.

Acara perdana Cloud & Coffee ini dilaksanakan pada Sabtu, 20 Desember 2025, di kantor Codinglab dengan peserta sekitar 15 orang. Teman kami, Padlian Chairi (CTO Codinglab), sangat mendukung pelaksanaan meetup ini mulai dari tempat hingga kopi yang disediakan untuk semua peserta. Padlian juga ikut mengisi sesi sharing dengan topik Kiro CLI.

Berikut beberapa highlight keseruan acaranya:

Acara diawali dengan pembukaan oleh Albert, yang memperkenalkan format baru Cloud & Coffee sekaligus membagikan rencana AWS UG Medan ke depan, termasuk rencana pelaksanaan AWS re:Invent Recap.

Dilanjutkan oleh Ifan yang membahas pengenalan komunitas AWS, seperti AWS User Group, AWS Community Builder, AWS Heroes, dan AWS Cloud Clubs. Sekaligus juga disampaikan informasi mengenai program AWS Community Builder yang rencananya akan dibuka awal tahun depan, lengkap dengan tips, benefit, serta ajakan untuk mulai menyiapkan portfolio dari sekarang.

Sesi pertama dibuka oleh salah satu peserta yang berbagi pengalaman di tempat kerjanya. Ia menceritakan bagaimana mereka menyelesaikan tantangan render custom / GIS maps dengan ukuran data puluhan giga, serta bagaimana cara mengolah dan menampilkannya di web frontend agar tetap smooth dan tidak menyebabkan aplikasi menjadi tidak responsif.

Setelah sesi pertama selesai, peserta lain langsung mengangkat tangan dan ikut berbagi pengalaman terkait vulnerability pada React Server Components.

Menariknya, kedua peserta ini menyampaikan materinya secara santai tanpa menggunakan slide. Dengan durasi rata-rata 5–10 menit, sesi langsung dilanjutkan dengan diskusi dan tanya jawab.

Sesi berikutnya juga tidak kalah menarik. Salah satu peserta yang sehari-harinya berprofesi sebagai dokter ikut melakukan sharing. Dia showcase ide product / pilot project berupa Radiation Dose Tracking System. Selain membahas solusi dari project tersebut, ia juga bercerita bagaimana dia menggunakan AWS SNS dan CloudWatch untuk kebutuhan monitoring. Ia juga berbagi cerita bagaimana sejak masa COVID mulai belajar teknologi dan kini mengembangkan solusi untuk penanganan kanker.

Di sesi ini juga sempat dibahas lika-liku mengenai startup, disertai dengan sharing pengalaman dan tips langsung dari para peserta.

Ternyata masih banyak peserta lain yang ingin sharing. Sehingga, acara yang awalnya dijadwalkan mulai pukul 13.30 hingga 17.00 akhirnya baru selesai sekitar pukul 18.00.

Selanjutnya, Padlian melanjutkan sesi sharing mengenai Kiro CLI, dan menjelaskan bagaimana tool ini mempermudah proses deploy dan CloudOps.

Sesi berikutnya membahas Amazon CloudFront, termasuk informasi mengenai Free Plan terbaru serta berbagai benefit yang ditawarkan, seperti WAF (Web Application Firewall) yang sudah aktif secara default. Topik ini menjadi lanjutan dari diskusi vulnerability sebelumnya, di mana peserta lain juga langsung menambahkan pengalaman dan tips mereka dalam menghindari masalah serupa.

Sesi terakhir diisi oleh Albert yang membahas EKS Auto Mode dan Managed ArgoCD, sekaligus memperkenalkan konsep GitOps. Diskusi kemudian berkembang ke berbagai topik lain seperti cloud security, shared responsibility model, automatic patching menggunakan Systems Manager Patch Manager, container image scanning dengan Amazon Inspector, serta perbandingan penggunaan ECS dan EKS.

Acara ditutup dengan sesi networking santai, tanya jawab, serta pengumpulan feedback dari peserta mengenai format baru Cloud & Coffee dan topik-topik yang ingin dibahas di meetup selanjutnya.

Terakhir, tentu saja foto bersama 😄

Pengalaman Sharing di Meetup AWS UG Medan: AWS Cost Mysteries – Real Spikes, True Stories, Real Savings

Ifan Jaya Suswanto Zalukhu — Wed, 27 Aug 2025 17:58:07 +0000

Pertengahan Agustus 2025 kemarin saya dapat kesempatan untuk sharing di AWS User Group Medan Meetup – August 2025 . Event ini diadakan offline di kampus UPH Medan, Lippo Plaza. Selain saya, ada juga pak Albert Suwandhi @albert_suwandhi (AWS Heroes) dan Lintang Gilang Pratama @lintanggilang (AWS Community Builders) yang ikut ngisi sesi sharing.

Di meetup ini ada dua topik utama yang kita bawakan:

AWS Cost Mysteries: Real Spikes, True Stories, Real Savings
Smarter Way to Work in CLI with Amazon Q Developer

Topik pertama saya bawakan bareng pak Albert. Saya sharing pengalaman optimasi biaya di AWS, sedangkan pak Albert kupas tuntas kasus spike biaya sampai ribuan USD dan bagaimana solusinya.

Dari sisi saya, saya sharing beberapa kesalahan dan optimisasi yang pernah saya lakukan, contohnya:

CloudWatch Logging tanpa retention, yang bikin cost jadi naik. Solusinya? Atur retention policy biar lebih efisien.
Salah deploy frontend di ECS → ini bikin data transfer bengkak dan website jadi lambat. Solusinya: pindah ke S3 + CloudFront.
Vertical scaling buat temporary spikes, tapi ujung-ujungnya cost inefficient karena resource kebanyakan idle. Lebih oke pakai Auto Scaling + Lambda Integration buat long running workload.
EC2 Spot Instances → bisa hemat sampai 90% dibanding on-demand. Saya juga sharing beberapa tips penggunaannya.
Scheduled Tasks di ECS dengan scaling policy + time-based scaling, hasilnya cost lebih optimal.
Retention & Lifecycle configuration (S3, ECR) → lumayan banget buat hemat cost jangka panjang.

Sharing saya ini masih awalnya aja. Dilanjutkan pak Albert dengan case yang lebih dalam lagi, mulai dari data transfer, reserved instance use case, sampai log spike. Jadi makin lengkap insight-nya.

Topik kedua dibawakan oleh Lintang. Dia jelasin cara kerja Amazon Q Developer, plus demo langsung gimana Q bisa bantu nulis & eksekusi perintah CLI. Selain itu, ada juga tips praktis buat ningkatin produktivitas Cloud Engineer & Developer dengan bantuan AI tools ini.

Buat saya pribadi, topik ini sebenernya gak terlalu baru. Sebelumnya saya udah pernah tulis di Medium dengan judul Kesalahan Setup AWS Pertama Kali & Cara Optimasi Cost-nya.

Tapi yang bikin seru kali ini ada beberapa hal:

Dibawakan dua orang → saya dan pak Albert, jadi insight yang keluar lebih banyak.
Ini adalah pertama kalinya saya sharing di event AWS/User Group setelah terpilih jadi AWS Community Builder tahun sebelumnya.

Event ini sendiri dihadiri sekitar 20 orang dan berlangsung cukup interaktif. Diskusi bareng peserta juga seru, beberapa bahkan share case baru yang mereka lagi kerjakan. Jadi selain QnA, kita juga lanjut ngobrol santai after event.

Selain topik utama, pak Albert juga memperkenalkan AWS User Group Medan dan program AWS Community Builders. Harapannya, tahun depan makin banyak teman-teman dari Medan yang apply, dan makin banyak juga yang bisa sharing di event-event selanjutnya.

Terakhir, big thanks buat semua peserta yang hadir, sudah ikut belajar dan berbagi pengalaman. Juga terima kasih untuk kampus UPH Medan dan teman-teman panitia yang bantu kolaborasi hingga meetup ini sukses berjalan. #AWSome 🚀

Oh iya, album foto AWS UG Medan Meetup bisa dilihat di sini:
📷 https://photos.app.goo.gl/X13DELkU8zQ5XaWz7

Sedangkan slide presentasi saya kemarin bisa diakses di sini:
📑 https://bit.ly/ifan-AWSUGMedanMeetup-August2025

Apa Rasanya Pertama Kali Ikut AWS Summit Jakarta 2025?

Ifan Jaya Suswanto Zalukhu — Mon, 18 Aug 2025 14:07:59 +0000

Bulan ini saya dapat kesempatan ikut AWS Summit Jakarta 2025 di The Ritz-Carlton Jakarta Pacific Place. Excited banget karena ini first time saya hadir langsung ke AWS Summit, setelah tahun lalu jadi AWS Community Builder (AI Engineering category).

Saya bersama Pak @albert_suwandhi (Albert Suwandhi, AWS Heroes) dan bro @lintanggilang (Lintang Gilang Pratama, AWS Community Builders), kita bertiga terbang dari Medan ke Jakarta untuk ikut event ini. Kita memang berusaha sebisa mungkin biar geng dari Medan juga bisa banyak hadir di event besar seperti ini.

Di event ini, saya bersama bro Lintang dapat kesempatan untuk demo di booth Amazon SageMaker Unified Studio in Action di developer lounge. Honestly, saya bukan expert di data/SageMaker, tapi teman saya Lintang yang cukup paham. Karena SageMaker bisa integrasi dengan Bedrock/GenAI, akhirnya saya bisa bantu menjawab pertanyaan seputar AI use case. Jadi teamwork jalan banget di booth ini. Kesempatan ini juga ada karena kami sama-sama AWS Community Builders dari Medan, dan saya diajak bareng dia untuk demo di booth SageMaker.

Perjalanannya juga penuh drama. Pesawat dari Medan ke Jakarta yang harusnya jam 7.30 malam malah delay sampai baru berangkat jam 10 malam. Sampai Jakarta sudah subuh jam 2 pagi. Untung tiketnya memang saya ambil H-1, jadi masih aman. Walau kurang tidur, ngantuk langsung hilang begitu masuk venue — suasana eventnya ramai dan energinya luar biasa.

Selain demo di booth, saya juga sempat ikut melihat light talk di developer lounge. Materinya seru, ringan, tapi insightful. Dari situ jadi termotivasi — semoga tahun depan bisa balik lagi, entah sebagai peserta, panitia, atau malah jadi salah satu speaker di developer lounge 😀. Mulai dari sekarang deh latihan dan prepare materi.

Hal yang nggak kalah menyenangkan adalah akhirnya bisa ketemu langsung teman-teman AWS CB yang biasanya cuma ketemu online lewat Online Meet. This time, bisa ngobrol dan connect langsung.

Dan yang paling spesial, bisa kenalan langsung dengan Shafraz Rahim dan Jason Dunn. Biasanya cuma lihat di Slack/LinkedIn, sekarang bisa ketemu langsung bahkan dinner bareng setelah acara. Definitely one of the highlights!

Setelah AWS Summit selesai, kita nggak langsung pulang ke Medan. Masih sempat mampir ke kantor AWS Jakarta untuk ikut Future Community Builder Learning Program Kickoff Meetup bareng AWS UG Indonesia. Eventnya nggak kalah seru, penuh insight baru.

Dari semua pengalaman ini, saya jadi makin semangat untuk aktif di komunitas — belajar, sharing, dan networking. Plus, ada satu pelajaran penting: kalau mau terbang ke event besar, jangan mepet-mepet atau terlalu malam. Delay bisa bikin panik atau malah gagal hadir.

Overall, pengalaman pertama di AWS Summit Jakarta 2025 ini benar-benar unforgettable! 🚀

Kenalan Sama Kiro IDE: Coding Bareng AI Pakai Spec-Driven Development

Ifan Jaya Suswanto Zalukhu — Wed, 16 Jul 2025 17:02:41 +0000

Buat yang penasaran sama Kiro IDE, ini adalah AI-powered IDE yang bantuin kita ngerjain software development secara lebih terstruktur. Alih-alih langsung gas nulis kode (vibe coding), Kiro ngajak kita mulai dari PRD (Product Requirement Document), lanjut ke technical spec atau system design, baru kemudian nge-breakdown task-tasknya.

Spec-Driven Development ini adalah salah satu fitur utama Kiro. Tapi tenang, kalau kamu lebih suka gaya vibe coding, itu juga bisa — tinggal pilih aja mode yang sesuai. Yang bikin saya pribadi cukup suka adalah pendekatan spec-driven ini karena prosesnya rapi dan mirip seperti cara kerja tim dev pada umumnya. Bahkan format acceptance criteria-nya pun mirip gaya Gherkin!

🎥 Ini dia hasil eksperimen saya coba Kiro IDE untuk project sederhana pakai data TMDB Movie:

Kalau kamu pengen lihat langsung overview-nya, atau bisa explore lebih lanjut ke https://kiro.dev dan intronya di sini!

Effort Serius Tapi Kok Hasil Bercanda

Ifan Jaya Suswanto Zalukhu — Fri, 13 Jun 2025 10:43:38 +0000

Image di generate oleh ChatGPT dengan prompt “Effort Serius Tapi Kok Hasil Bercanda.Illustration of two coworkers with opposite work styles: one arriving at the office very early with tired eyes, messy desk full of paper and coffee cups, another arriving just on time, looking relaxed, with a clean desk and a robot assistant (AI Copilot) helping him. Comic-style, light colors, office setting.”

Tulisan ini murni hasil imajinasi tanpa fakta dan data pendukung. Bukan artikel berita — cuma buat nemenin waktu luang aja. Jadi plis, jangan dibawa terlalu serius ya 🫠

Okay, mari kita mulai.

Di suatu pagi, sambil nyeruput secangkir kopi infused choco chip cookie robusta hasil cold brew, tiba-tiba kepikiran:

“Kok ada ya orang yang effort-nya serius banget tapi hasilnya bercanda (alias gak maksimal), tapi ada juga yang effort-nya kelihatan santai, malah hasilnya serius banget (luar biasa)? 🤔”

Apakah ini ada hubungannya dengan hoki? Atau pas lagi bagi-bagi keberuntungan, dia ada di urutan paling belakang? Atau… apakah usaha menghianati hasil — eh maksudnya, apakah hasil menghianati usaha? 😅

(seruput kopi dulu biar imajinasinya makin ngawur…)

Kenapa sih kepikiran soal ini? Karena gak sengaja lihat teman-teman sendiri:

Teman Pertama: Si Effort Serius

Orang ini kerja kerasnya total banget. Contohnya, datang ke kantor sejam lebih pagi dari jam kerja (kantor masuk jam 09.00, dia udah nongkrong jam 08.00). Tujuannya? Biar bisa prepare dan kirim report ke leader duluan, sebelum leader datang.

Pulangnya? Jangan ditanya. Selalu jadi yang terakhir. Kadang sampai security-nya udah nyapu-nyapu dan nyalain lampu emergency, baru dia pulang 😅

Kenapa? Karena dia berusaha ngebut ngerjain technical debt dan backlog yang numpuk.

Teman Kedua: Si Effort Santai Tapi Tertata

Nah ini kebalikannya. Datang jam 09.00 pas, pulang jam 17.30 on the dot. Tapi pas performance review, guess what? Dia yang dinobatkan best performance oleh leader mereka.

(seruput lagi… kayaknya mulai perlu es batu tambahan biar gak makin panas mikirnya)

Terus saya mikir, jangan-jangan dia ini anak pemilik perusahaan yang nyamar? Kayak di drama-drama pendek China itu lho, yang ending-nya bisa ketebak tapi kita tetap nonton… eh pas mau lanjut disuruh download app dulu. 🥲

Atau… mereka ketuker waktu kecil? Karena biasanya yang ketuker itu hidupnya selalu berat, penuh perjuangan, dan hasilnya bercanda terus 😭

Eh, kok jadi bahas sinetron ya. Efek kopi sepertinya. Balik ke topik utama.

(tambahin seruputan lagi ☕)

Sampai akhirnya, ada momen saya bisa ngobrol langsung sama leader mereka. Kepo dong, nanya:

“Eh, ini si teman yang santai itu… jangan-jangan emang anak bos beneran ya?”

Ternyata bukan. Lalu si leader mereka cerita:

“Dia emang datang on time, tapi tiap pagi dia yang paling cepat submit report. Tau kenapa?”

Saya: “Hah, kok bisa?”

Leader mereka:

“Karena dia udah ngautomate banyak hal yang berulang. Misalnya submit report, dia pakai automation tools buat auto-recap dan auto-send ke saya. Jadi, meskipun badannya belum nyampe kantor, report-nya udah duduk manis di inbox saya.”

Sore hari? Sama. Pekerjaan beres, pulang on time. Bahkan lebih rapi dan cepat dari yang lain.

Kok bisa?

Karena dia pakai automation tools dan AI/Copilot_. Jadi waktu yang orang lain habisin 10 jam buat satu task, dia cukup 1–2 jam doang 😮_

Tapi… hasilnya beneran oke?

Yes bro, karena dia gak asal pakai AI. Dia treat Copilot kayak partner brainstorming, jadi tetap dia review, validasi, dan edit kalau perlu.

Intinya?

Yang satu kerja keras (hard work), yang satu kerja cerdas (smart work).

Kalau pakai analogi quotes dari Abraham Lincoln:

“Berikan saya 6 jam untuk menebang pohon, dan saya akan menghabiskan 4 jam pertama untuk mengasah kapak.”

Teman pertama tadi full 6 jam buat nebang pohon. Gak sempat ngasah kapak. Jadinya, walau semangatnya tinggi, hasilnya kurang maksimal dan capeknya luar biasa 😩

Teman kedua? Dia sempatin waktu buat ngasah kapak dan istirahat. Jadi meskipun tenaganya biasa aja, sekali ayun — duar! — langsung kena besar dan dalam.

Jadi, apakah hasil menghianati usaha?

Well… kadang iya, kadang enggak. Banyak juga yang jadi skeptis:

“Ngapain usaha keras kalau akhirnya hasilnya bercanda?”

Pikiran kayak gitu valid sih, tapi gak sepenuhnya benar juga. Yah, you know lah 🫠

Terus, kenapa teman pertama gak pakai automation / Copilot juga?

Good question.

Ada dua alasan utama:

Gak sadar kalau ada masalah. Ini stage awal dalam Four Stages of Competence → Unconscious Incompetence. Dia gak tau kalau hal yang dia alami itu masalah. Misalnya, datang pagi dan pulang malam dianggapnya biasa aja, padahal itu symptom dari sistem kerja yang gak efisien.
Infinite Problem Loop Pernah lihat ilustrasi ini?

Image source : What Technical Debt Is And How It’s Measured (https://medium.com/the-andela-way/what-technical-debt-is-and-how-its-measured-ff41603005e3)

Nah, setiap kali disarankan coba automation atau AI, jawabannya:

“Nanti deh, belum sempat. Lagi sibuk ngerjain ini dulu. Itu menarik sih, tapi saya harus habiskan waktu lagi untuk belajar hal tersebut”

Akhirnya waktu habis buat kerja manual terus, jadi gak pernah sempat belajar hal baru. Dan karena gak belajar, makin stuck di pola lama. Ujung-ujungnya… ya muter-muter di loop yang gak berujung. Chicken and egg problem 🐣🥚

Padahal kalau dia sempatin waktu buat belajar tools baru, kerjaan bisa lebih cepat kelar. Sisa waktunya bisa dipakai buat belajar lebih lanjut. Combine hard work plus smart work = hasilnya? Gak cuma maksimal, tapi bisa melesat jauh 🚀

So, what did we learn?

Kalau disimpulkan…

Ngopi sambil nonton short drama China ternyata bisa menghasilkan pemikiran yang surprisingly dalam… 😀

Amazon Q CLI untuk Code Review: Fokus Review Code yang Berubah, Bukan Semua Code di Workspace

Ifan Jaya Suswanto Zalukhu — Sat, 10 May 2025 17:13:47 +0000

Masalahnya

Beberapa AI-powered coding assistant sekarang memang sudah bisa bantu code review. Tapi biasanya, yang direview itu seluruh workspace atau file yang sedang dibuka. Padahal di dunia nyata, kita seringnya cuma butuh review berdasarkan pull request—alias perubahan dari satu branch ke branch lain, contohnya dari hotfix ke main. Jadi yang perlu direview cuma file yang berubah aja, bukan semuanya.

Nah, saya jadi kepikiran: ada nggak sih AI yang bisa bantu review berdasarkan perubahan antar branch aja? Minimal jadi lapisan pertama review, biar nanti reviewer manual tinggal cek dan verifikasi.

Solusinya: Amazon Q Developer di Command Line

Jawabannya: ada.

Setelah coba eksplorasi, ternyata Amazon Q Developer CLI bisa bantu banget di skenario ini. Fitur CLI-nya—terutama yang pakai MCP (Model Context Protocol)—bisa dipakai untuk compare dua branch, misalnya dari hotfix ke main. Lalu, dia akan review file-file yang berubah satu per satu dan hasilnya bisa langsung disimpan ke dalam satu file.

Bisa dipakai Amazon Q Developer sebagai layer awal untuk review code antar branch. Setelah proses ini, baru masuk ke manual review. Kombinasi keduanya bikin proses review lebih cepat, rapi, dan efisien. Sehingga jadinya, Amazon Q Developer ini bukan cuma bisa generate code, tapi juga bisa review kodenya sendiri—lumayan multitasking.

Oh ya, Amazon Q Developer tersedia dalam dua versi: Free Tier dan Pro Tier. Di demo ini saya pakai yang Free. Selain tersedia dalam bentuk IDE Extension, dia juga punya versi CLI yang saya pakai di sini. Dan yang bikin CLI-nya makin powerfull adalah support untuk MCP.

Beberapa fitur yang bisa ditemukan di CLI-nya antara lain:

Command & auto-completion
Translate command (berguna kalau lupa command kayak git commit)
Q Chat yang bisa menyimpan context dan menjalankan MCP langsung dari terminal

Detail fitur, cara install, dan overview lainnya bisa kamu cek di bagian Supporting Resources di bawah.

Demo

Untuk komunikasi ke Amazon Q CLI sendiri gk harus bahasa Inggris, pakai bahasa Indonesia juga bisa.

Selain dari demo di atas, nextnya yg mungkin bisa di explore :

Apakah ini bisa di automate di CI / CD
Atau apakah bisa di integrasi dengan Git hooks seperti Husky maupun lainnya.

Supporting Resources

Amazon Q CLI for Code Review: Focus on What Changed, Not Everything

Ifan Jaya Suswanto Zalukhu — Sat, 10 May 2025 15:53:39 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: Crushing the Command Line

Some AI-powered coding assistants already support code reviews, but most of them tend to review an entire workspace or just the currently open file. In real-world scenarios though, code reviews are often based on pull requests—where we only need to review changes between two branches, not the whole project. For example, reviewing just the differences between a hotfix branch and main.

That got me thinking: wouldn’t it be great if an AI coding assistant could handle that kind of focused review? At least as a first layer—giving us a detailed AI-generated review of the changes before we jump in manually. That way, human reviewers can just focus on refining things further instead of starting from scratch.

What I Built

One of Amazon Q Developer’s cool features is its CLI and MCP (Model Context Protocol) support. So I thought: why not use Amazon Q CLI to compare two branches—say, hotfix and main—and then have it go through the changed files one by one, review them, and finally compile the feedback into a single file using MCP as well? That way, whoever’s reviewing the PR can read the AI’s review first before doing their manual checks.

Demo

Code Repository

Code Review with Amazon Q Developer CLI

How I Used Amazon Q Developer

I used Amazon Q Developer as the first layer of code review—comparing one branch to another, like from hotfix to main. This helps make the review process smoother, more effective, and scalable—especially when combined with a follow-up manual review. What makes it even more exciting is that Amazon Q Developer can both generate code and review it too. Pretty handy, right?

Valuable Lessons from My First AWS Setup Mistakes (and How to Optimize Costs to Avoid Bill Shock!)

Ifan Jaya Suswanto Zalukhu — Mon, 31 Mar 2025 07:37:27 +0000

When I first set up services on AWS, I learned a lot—or more accurately, I made a lot of mistakes that turned into valuable lessons. And I mean really valuable because the first one to notify me wasn’t the engineering team, nor was it a monitoring alert, but... AWS billing! If that’s not valuable, I don’t know what is—after all, it’s your cost suddenly spiking that tells you something went wrong. 😆

You can also listen to this post as a NotebookLM podcast, if that’s more your style 😊

" width="800" height="451">

For a bit of context, I currently work as the Head of Engineering at a SaaS startup in Medan, Indonesia.

But these mistakes happened when I was still a mobile developer at the same company. At first, I got involved in backend tasks because I often had to wait for APIs from the backend team. Once the backend was done, I then had to wait again for the DevOps team to set up and deploy it on AWS. To reduce dependency on other teams, I decided to start learning how to handle AWS and manage the backend APIs myself.

That’s where my AWS journey began—along with a series of mistakes. The funny thing is, many of these mistakes weren’t immediately obvious in the first month because they were still covered by the free tier. But after a few months, they started showing up on the billing statement.

1: Enabling CloudWatch Logs Without Retention and Minimum Log Level

One of my first mistakes was enabling logging in CloudWatch without setting data retention and log level filters. Logging is crucial for troubleshooting—without logs, debugging a service issue is like being a fortune teller, trying to guess what went wrong. 😂

However, I stored everything—Info, Warning, Debug, and Error logs—without filtering. The result? CloudWatch log storage grew rapidly, and the cost for ingested and scanned log data in CloudWatch Logs Insights became insanely expensive. This issue only became apparent after a few months when my CloudWatch billing started climbing.

How We Fixed It

" width="800" height="450">

Adjusted the minimum log level to Error to reduce stored data.
Set log retention based on actual needs. If logs are only needed for troubleshooting within the past 7 days, set retention to 7 days (default is "never expire").
Used CloudWatch Logs Insights queries only when necessary to avoid unnecessary costs.

References:

2: Not Enabling Retention / Lifecycle Policy in ECR

Most of our system runs on Docker containers, and our Docker images are stored in AWS Elastic Container Registry (ECR). The mistake? I didn’t enable retention or lifecycle policies in the ECR repository. As a result, old images were kept indefinitely, and storage costs kept growing.

This problem wasn’t obvious in the first six months since the cost was just a few cents. But as more images accumulated, our ECR storage bill started rising.

How We Fixed It

Enabled a lifecycle policy in ECR based on image count, keeping only the latest versions.
If an old image is needed, we simply rebuild it via CI/CD.

References:

Automate image cleanup using lifecycle policies in Amazon ECR

3: Running Web Frontend on ECS Instead of Amazon S3 + CloudFront

Since most of our services run in Docker, our frontend was initially hosted on Amazon ECS. What happened? The data transfer costs were crazy high!

After some research, we decided to migrate to Amazon S3 + CloudFront. Our CI/CD pipeline now builds and compiles the frontend source code into S3, while CloudFront serves requests from there. The benefits:

CloudFront caching reduces data transfer costs.
1TB free tier per month for outbound data transfer.
Better security with features like AWS WAF (Web Application Firewall).

References:

4: Vertical Scaling ECS Services with Temporary Spikes

When a service on ECS had traffic spikes, my first solution was to increase CPU and memory (vertical scaling). The problem? The spikes were occasional, like when users exported data. So, most of the time, the extra resources were sitting idle—wasting money.

How We Fixed It

Analyzed the spike patterns and root causes.
Used ECS auto-scaling to dynamically add tasks during spikes.
Moved heavy processes to AWS Lambda. For example, when users export data, ECS sends a queue to Amazon SQS, and Lambda processes it, storing the output in S3.

5: Not Using EC2 Spot Instances to Save Costs

Initially, all our ECS instances ran on EC2 On-Demand. But EC2 Spot Instances can reduce costs by up to 90% compared to On-Demand!

However, Spot Instances aren’t suitable for all workloads since AWS can terminate them anytime if demand rises. To mitigate this, we used Spot Instances for staging and development environments only.

To ensure availability, we used multiple instance types with the price-capacity-optimized strategy, which automatically selects the best-priced instance with the lowest termination risk.

References:

Tips to Avoid Cost Surprises

To help detect mistakes faster, here are a few things that have helped me recently:

Enable billing alerts in AWS Billing & Cost Management. Set thresholds and forecasts to avoid getting surprised at the end of the month. 😃
Regularly review your AWS costs—whether weekly, bi-weekly, or monthly—to spot cost trends and identify services with rising expenses.
Follow AWS updates and recommendations. AWS often suggests optimizations in the AWS Portal, such as cost-effective configurations.

Hopefully, these experiences help those of you just starting with AWS avoid these “valuable learning experiences” yourself! 😆

This article is also available in Indonesian:
Pelajaran Berharga dari Kesalahan Setup AWS Pertama Kali
(dan Cara Optimasi Cost-nya) Biar Tagihan Nggak Bikin Kaget!

Kesalahan Setup AWS Pertama Kali & Cara Optimasi Cost-nya

Ifan Jaya Suswanto Zalukhu — Mon, 31 Mar 2025 07:05:01 +0000

Pelajaran Berharga dari Kesalahan Setup AWS Pertama Kali (dan Cara Optimasi Cost-nya) Biar Tagihan Nggak Bikin Kaget!

This image was created with the help of partyrock.aws

Saat pertama kali setup layanan di AWS, saya banyak belajar — atau lebih tepatnya, banyak melakukan kesalahan yang akhirnya jadi pembelajaran berharga. Berharga banget, karena yang pertama kali kasih tahu biasanya bukan tim engineering, bukan juga alert monitoring, tapi… billing AWS! Ini gimana nggak berharga, kan yang ngabarin langsung cost-nya yang tiba-tiba naik drastis. 😆

Sebagai sedikit konteks, saya saat ini bekerja sebagai Head of Engineering di sebuah SaaS startup di Medan, Indonesia.

Tapi, kesalahan-kesalahan ini saya alami ketika masih menjadi mobile developer di perusahaan yang sama. Awalnya, saya mulai ikut menangani backend karena sering harus menunggu API dari tim backend. Setelah backend selesai, giliran harus menunggu lagi tim DevOps untuk setup dan deploy ke AWS. Supaya tidak terlalu lama bergantung pada tim lain, saya akhirnya mulai belajar mencoba menghandle langsung AWS dan API backendnya.

Dari sinilah perjalanan saya di AWS dimulai — dan tentunya, kesalahan demi kesalahan juga bermunculan. Lucunya, banyak dari kesalahan ini tidak langsung terlihat di bulan pertama karena masih tertolong oleh free tier. Baru setelah beberapa bulan, mulai terasa dampaknya di billing.

#1 : Mengaktifkan Log di CloudWatch Tanpa Retention dan Log Minimum Level

Salah satu kesalahan pertama yang saya buat adalah mengaktifkan logging di CloudWatch tanpa memperhatikan retensi data dan level log yang disimpan. Secara konsep, logging itu penting banget buat troubleshooting. Kalau nggak ada log, setiap kali ada masalah di service, kita bakal jadi dukun atau cenayang yang harus menebak-nebak apa yang salah. 😂

Tapi, yang saya lakukan waktu itu adalah menyimpan semua log tanpa filter levelnya. Jadi, semua log dari level Info, Warning, Debug, sampai Error disimpan. Hasilnya? Storage log di CloudWatch cepat membengkak, dan biaya log data ingested serta log data scanned dari CloudWatch Logs Insights jadi mahal banget. Masalah ini baru ketahuan setelah beberapa bulan, saat billing CloudWatch mulai merangkak naik.

Solusi yang Kami Lakukan:

Menyesuaikan level log minimum ke Error saja supaya tidak terlalu banyak data yang disimpan.
Menetapkan retensi log sesuai kebutuhan. Kalau log hanya dibutuhkan untuk troubleshooting dalam 7 hari terakhir, set retention ke 7 hari (default-nya adalah “never expire”).
Menggunakan CloudWatch Logs Insights queries hanya saat diperlukan agar tidak memicu biaya berlebihan.

Referensi

#2 : Tidak Mengaktifkan Retention / Lifecycle Policy Rules di ECR

Sebagian besar sistem kami menggunakan Docker container, dan Docker image-nya disimpan di AWS Elastic Container Registry (ECR). Kesalahannya? Saya tidak mengaktifkan retention atau lifecycle policy di repository ECR. Akibatnya, image yang lama-lama tetap tersimpan, dan cost penyimpanan makin lama makin besar.

Masalah ini baru ketahuan setelah lebih dari 6 bulan, karena di awal cost-nya cuma beberapa sen saja. Tapi setelah beberapa bulan, jumlah image bertambah dan storage cost di ECR pun menggulung naik.

Solusi yang Kami Lakukan:

Mengaktifkan lifecycle policy di ECR berdasarkan image count, jadi hanya menyimpan beberapa versi terbaru saja. Kalau butuh image lama, tinggal rebuild ulang dari CI/CD.

Referensi

Automate the cleanup of images by using lifecycle policies in Amazon ECR

#3 : Menjalankan Web Frontend di ECS Alih-alih Amazon S3 + CloudFront

Karena hampir semua layanan kami berbasis Docker, frontend web kami awalnya juga dijalankan di Amazon ECS. Apa yang terjadi? Biaya data transfer-nya cukup tinggi!

Setelah membaca beberapa referensi, akhirnya kami memutuskan untuk migrasi ke Amazon S3 + CloudFront. Dari CI/CD, source code frontend dibuild dan dikompilasi ke S3, lalu CloudFront akan melayani permintaan dari S3. Keuntungan lainnya:

Cache aktif di CloudFront, sehingga mengurangi biaya transfer data.
Free tier 1TB per bulan untuk data transfer keluar ke internet.
Keamanan lebih baik dengan fitur seperti AWS WAF (Web Application Firewall).

Referensi

#4 : Vertical Scaling di ECS untuk Service dengan Temporary Spike

Ketika service di ECS sering mengalami spike, solusi awal yang terpikir adalah menaikkan ukuran CPU dan memori (vertical scaling). Masalahnya, spike ini hanya terjadi sesekali, misalnya saat user melakukan export data. Jadi, secara resource tidak efisien karena lebih banyak idle daripada digunakan.

Solusi yang Kami Lakukan:

Menganalisis penyebab spike dan pola penggunaannya.
Menggunakan auto-scaling di ECS, sehingga task akan bertambah ketika ada spike.
Memindahkan proses berat ke AWS Lambda. Contohnya, saat user melakukan export data, ECS hanya mengirim queue ke Amazon SQS, lalu Lambda memprosesnya dan menyimpan hasilnya di S3.

#5 : Tidak Menggunakan EC2 Spot Instances untuk Penghematan Biaya

Di awal, semua ECS instance kami menggunakan EC2 On-Demand. Padahal, EC2 Spot Instance bisa menghemat biaya hingga 90% dibandingkan On-Demand.

Tapi, tidak semua workload cocok dengan Spot Instances, karena instance ini bisa kapan saja dihentikan oleh AWS jika harga naik atau kapasitas dibutuhkan oleh pelanggan lain. Oleh karena itu, kami hanya menggunakan Spot Instances untuk environment staging dan development.

Selain itu, untuk memastikan Spot Instance tetap tersedia, kami menggunakan multiple instance types dengan strategi price-capacity-optimized, yang secara otomatis memilih instance dengan harga terbaik dan risiko penghentian paling rendah.

Referensi

Mungkin tips dari saya untuk membantu agar lebih aware dan lebih cepat mengetahui ketika melakukan kesalahan, beberapa yg sering salah lakukan akhir-akhir ini adalah :

Aktifkan billing alert dari billing & cost managementnya, baik itu dalam bentuk threshold atau forecast, sehingga Anda tidak tiba2 terkejut di akhir bulan ketika sudah dapat tagihan 😀
Sempatkan waktu baik itu per minggu, 2 minggu atau perbulan untuk review cost / servicenya untuk mengetahui polanya dan service mana saja terus mengalami kenaikkan cost
Ikuti release / rekomendasi terbaru dari AWS, biasanya di AWS Portalnya kadang ada rekomendasi menggunakan cara tertentu contohnya.

Semoga pengalaman ini bisa membantu kalian yang baru mulai menggunakan AWS supaya nggak mengalami “pembelajaran berharga” yang sama! 😆

This article is also available in English:

Valuable Lessons from My First AWS Setup Mistakes (and How to Optimize Costs to Avoid Bill Shock!)

AI sebagai Partner: Perjalanan Kami Mengadopsi AI dalam Development

Ifan Jaya Suswanto Zalukhu — Fri, 06 Dec 2024 11:29:45 +0000

Hai semua! 🙌 Di sesi ini, aku mau berbagi cerita tentang bagaimana tim kami di SimpliDOTS mengimplementasikan AI di tempat kerja.

Perjalanannya tentu nggak selalu mulus, terutama di tahap awal. Banyak teman-teman developer dan engineer yang merasa khawatir — ada yang takut AI bakal menggantikan peran mereka , dan ada juga yang ragu karena pengalaman sebelumnya dengan ChatGPT yang hasilnya kurang akurat untuk coding. 😅

Tapi, seiring waktu, AI justru membawa perubahan positif dalam cara kami bekerja, termasuk dalam proses rekrutmen dan evaluasi probation.

Aku juga bakal cerita gimana kami berhasil meyakinkan teman-teman engineer yang awalnya ragu, sampai akhirnya mereka jadi pengguna aktif AI dalam proses development. 😊

Harapannya, sharing ini bisa membantu teman-teman developer yang masih ragu terhadap AI atau merasa khawatir bahwa AI akan menggantikan perannya. Semoga juga bisa jadi insight buat teman-teman yang baru mulai karir sebagai developer atau masih kuliah di jurusan IT, biar nggak perlu khawatir apakah dunia IT masih relevan di tengah perkembangan AI yang pesat. 🚀

Selain itu, semoga pengalaman ini juga bermanfaat buat teman-teman leader atau manajer yang sedang merencanakan implementasi AI di tempat kerja. Aku share cerita kami ini, siapa tahu bisa jadi referensi atau inspirasi dalam perjalanan kalian. 😉

🚀 Awal Mula: “Yuk, Coba AI!”

Jadi ceritanya, sekitar awal tahun lalu, manajemen kami mengeluarkan himbauan ke semua divisi: “ Mulai adopsi AI dalam proses internal kita, yuk!” 🎉 Tujuannya? Tentu saja untuk memanfaatkan potensi besar AI yang diproyeksikan bakal memberikan manfaat signifikan di masa depan. 🚀

Setiap manajer atau lead diminta menyusun rencana implementasi , termasuk perencanaan anggaran tiap kuartal dan area proses internal mana yang bisa ditingkatkan dengan bantuan AI. Fokus awalnya diarahkan ke internal perusahaan dulu sebelum AI diterapkan ke eksternal atau produk kami yang digunakan oleh user, yaitu distributor dan principal.

Sebagai konteks, aku saat ini bekerja di SimpliDOTS sebagai Head of Engineering. SimpliDOTS adalah salah satu startup SaaS yang berbasis di Medan, menyediakan aplikasi yang mendukung operasional distributor dan principal. 📦

Sebagai perusahaan teknologi, kami tentu dituntut untuk kreatif dan up-to-date dengan teknologi terbaru. Selain meningkatkan pengalaman pengguna, kami juga berfokus pada pengoptimalan proses internal agar lebih efisien dan efektif dengan bantuan AI. 🤖

🛠️ Tantangan Awal: Skeptis & Takut Kehilangan Pekerjaan

Tantangan mulai muncul ketika saya pertama kali mengajak semua engineer berdiskusi soal rencana implementasi AI. Di SimpliDOTS, setiap Jumat sore pukul 4 hingga 6, kami biasanya mengadakan diskusi santai/sharing dengan tim engineering. Topiknya beragam, mulai dari sharing teknologi, hobi seperti memilih ikan hias 🐠, tips olahraga 🏃, hingga pembahasan serius lainnya. Sesi ini sering menjadi momen brainstorming yang santai tapi produktif. 😊

Di salah satu sesi tersebut, saya mulai memperkenalkan rencana implementasi AI, khususnya untuk mendukung proses development seperti coding dan code review. Saya mengajak setiap anggota tim — baik dari mobile developer, QA, frontend, maupun backend — untuk mulai mengeksplorasi tools atau teknologi berbasis AI yang dapat membantu mereka bekerja lebih efektif dan efisien. Saya juga membuka diskusi untuk menerima saran atau ide dari mereka, termasuk rekomendasi tools berbayar yang mungkin layak dipertimbangkan. 💡

Seperti biasa, saya memperhatikan reaksi mereka. Beberapa terlihat optimis 😊, sementara yang lain ragu-ragu 🤔. Salah satu tantangan pertama yang muncul adalah skeptisisme. Ada beberapa engineer yang sebelumnya pernah menggunakan ChatGPT untuk coding, tetapi merasa hasilnya tidak akurat. Mereka menganggap AI ini sekadar hype marketing saja. Saya mencoba menjelaskan bahwa hasil AI seperti ChatGPT sangat bergantung pada konteks dan teknik prompting yang digunakan. Jika input kurang tepat, output -nya juga pasti akan kurang sesuai. Sedangkan kalau pakai GitHub Copilot dia dapat context code -nya.

Tantangan kedua adalah kekhawatiran terkait AI yang dianggap bisa menggantikan pekerjaan mereka. Pada saat itu, banyak berita tentang AI yang mampu melakukan coding secara mandiri, dan beberapa engineer merasa cemas bahwa AI mungkin akan menggantikan peran mereka. Saya masih ingat bagaimana saya menjelaskan filosofi Co-pilot. AI bukan dirancang untuk menggantikan kita, tetapi menjadi asisten atau partner dalam proses coding — mirip dengan pairing atau code review. Keputusan akhir tetap ada di tangan kita sebagai developer. 👨‍💻

Namun, salah satu anggota tim memberikan komentar yang cukup menggelitik :

“Iya sih, Bang. Sekarang namanya Co-pilot, tapi siapa yang tahu, mungkin beberapa bulan atau tahun lagi dia jadi pilot, dan kita ditendang dari pesawat.” 😂

Komentar itu awalnya membuat suasana menjadi lucu, tapi sekaligus menantang. Saya merasa perlu terus meyakinkan mereka bahwa AI bukan ancaman , melainkan alat yang bisa memperkuat kemampuan kita jika digunakan dengan tepat. 💪

Pada saat itu, kalau saya lihat, hanya sekitar 20% dari tim yang optimis dan tertarik untuk mengeksplorasi AI. Bahkan, mungkin lebih sedikit — sekitar 15–20% saja , dan itu pun beberapa masih terlihat ragu-ragu. Saya masih ingat bagaimana respon tersebut cukup membuat saya syok 😲. Awalnya, saya begitu bersemangat untuk mengimplementasikan AI, tetapi setelah melihat reaksi mereka, semangat saya sempat menurun. Saya mulai bertanya dalam hati, “ Lho kok tim saya seperti ini? Kok mereka nggak mau maju? Apakah mereka benar-benar begitu khawatirnya terhadap AI? ”

🎯Langkah Awal Implementasi AI: Mulai dari yang Mau Dulu

Nah, di tahap awal, saya fokus pada kelompok kecil yang sudah menunjukkan ketertarikan terhadap AI — sekitar 20% dari tim tadi. 🤓 Untuk mereka, saya langsung memberikan akses ke GitHub Copilot dengan berlangganan agar mereka bisa mulai menggunakan AI dalam coding. 🚀

Sementara itu, bagi teman-teman yang masih ragu, saya tidak memaksa. Saya memberikan mereka waktu untuk berpikir dan mengeksplorasi. Karena mereka belum yakin, saya tidak langsung memberikan akses ke GitHub Copilot agar biaya langganan tidak terbuang sia-sia. Sebagai alternatif, saya menyarankan mereka mencoba beberapa tools gratis terlebih dahulu, seperti Codeium, Gemini di Android Studio, atau Gemini di IDX. 😉

Mengubah Mindset Melalui Influencer Internal

Langkah berikutnya adalah kerjasama dengan anggota tim yang sudah menggunakan AI untuk menjadi influencer internal. Saya ingin mereka menjadi penggerak yang bisa mengubah sudut pandang teman-teman lainnya.

Setiap sesi Jumat sore , kami menyisipkan sharing session tentang tips dan trik penggunaan AI. Mereka berbagi pengalaman tentang bagaimana AI memudahkan pekerjaan mereka, seperti:

Otomatisasi Dokumentasi : AI membantu membuat README atau dokumentasi proyek dengan mudah. 📝
Diagram Otomatis : Menggunakan PlantUML atau Mermaid Diagram yang dihasilkan langsung dari user story PM, tanpa perlu menggambar manual. 🎨
Testing Otomatis : QA menunjukkan bagaimana mereka dapat mengonversi user story menjadi skenario BDD (Behavior-Driven Development) dalam format Gherkin secara otomatis. 🧪

Apakah semuanya langsung berubah? Tidak. Ini bukan sinetron dengan akhir yang bahagia dalam semalam. 😅 Tapi, melalui langkah-langkah kecil ini, saya berusaha terus mengedukasi dan memperlihatkan manfaat nyata dari AI.

Code Review dengan AI

Cara lain untuk mempengaruhi tim adalah melalui code review. Dalam sesi review, kami sambil menggunakan AI untuk memberikan rekomendasi, seperti:

Penamaan Variabel dan Fungsi : Rekomendasi nama yang lebih deskriptif dan bermakna. 📛
Peningkatan Readability : Tips untuk membuat kode lebih mudah dibaca dan dipahami. 👀
Dokumentasi Otomatis : Saran untuk mendokumentasikan kode secara otomatis. 📚

Nah, biasanya hasil feedback ini dari AI, kita sambil melampirkan screenshot juga di pull request, siapa tahu tim member lain tergerak hatinya untuk pakai. 😁 Ini cara sederhana untuk menumbuhkan penasaran mereka.

Mengatasi Masalah / Bug Fixing dengan AI

Selain itu, kami juga memanfaatkan AI untuk membantu mereka yang mengalami kesulitan atau bugs , terutama teman-teman yang belum pakai AI. Contohnya:

Mengoptimalkan Query Database : Jika ada query yang menyebabkan lonjakan beban (spike) pada database, AI bisa memberikan solusi cepat untuk optimisasi query. ⚡
Error Debugging : Ketika mereka mengalami error yang sulit dipecahkan dalam satu hari, AI seringkali bisa memberikan solusi hanya dalam beberapa menit. ⏱️

Hasil solusi ini juga kami kirim dalam bentuk screenshot dari AI untuk menunjukkan kecepatan dan efisiensinya. Tujuannya, pelan-pelan membuat mereka penasaran terhadap AI. 😉

Otomasi Proses Berulang

Kami juga memperlihatkan bagaimana AI bisa mempercepat tugas-tugas yang berulang , seperti:

Pembuatan Data Dummy : Saat pertama kali mengembangkan backend, biasanya mereka membutuhkan waktu lama untuk membuat data mock. Dengan AI, mereka hanya perlu memberikan model, dan AI langsung menyediakan data yang diperlukan. Ini biasanya kita sering nge-spill di Slack, seperti, “Wow, pakai AI gak perlu ribet!” 😃
Otomasi Testing : QA yang sebelumnya membuat skrip manual di Postman kini bisa menggunakan Postbot untuk secara otomatis menghasilkan automation testing berdasarkan respons API. 🤖

Hal-hal kecil ini kita ulang terus menerus untuk menginfluence teman-teman dev lainnya agar tertarik explore dan pakai AI.

Perlahan Tapi Pasti

Melalui langkah-langkah ini, perlahan tapi pasti , tim kami mulai melihat AI sebagai alat yang bukan hanya membantu, tetapi juga meningkatkan produktivitas mereka secara signifikan. 💯

AI as a Partner 🤝

Sekarang hampir semua engineer di tim kami sudah menggunakan AI dalam proses development. Yang menarik, beberapa teman-teman yang dulu ragu malah sekarang lebih aktif mencoba fitur-fitur baru dibandingkan saya sendiri dan mengikuti perkembangannya. Contohnya, waktu GitHub Copilot merilis fitur yang mendukung model-model seperti Claude atau OpenAI o1. Fitur ini masih dalam tahap preview, tapi mereka langsung antusias minta diaktifkan fiturnya, karena mereka nggak sabar ingin explore model Claude. 😄

AI Jadi Teman Diskusi yang Nggak Pernah Capek dan Bosan 💬

AI juga jadi semacam teman diskusi untuk mereka yang sering bekerja sendiri di tim. Saya ingat salah satu mobile developer kami yang sempat curhat,

“Bang, di mobile karena saya sendiri saja, nggak ada teman untuk brainstorming.”

Setelah pakai AI, dia bilang jadi lumayan terbantu. Memang AI nggak bisa menggantikan diskusi langsung dengan manusia, tapi bisa kasih sudut pandang baru , ide alternatif atau sekadar jadi tempat bertanya tanpa perlu sungkan. Dan yang paling penting, AI nggak pernah capek atau bosan ditanya. 😁 Jadi nggak perlu harus ngomong, “Permisi bang, kita bisa discuss sebentar nggak?” Atau dia nggak marah ketika kita bilang, “Gimana-gimana tadi, saya nggak fokus, bisa ulangi lagi nggak penjelasannya?”

Selain itu, AI bisa kita atur lagi. Contohnya, “ Tolong jelaskan simpel dan pendek saja, jangan terlalu panjang dan bertele-tele. ”

Nah, kalau ke teman kita, kita buat seperti ini, pasti dalam hatinya, “Ini orang sudah minta bantu, ngatur-ngatur lagi.” 😅

Knowledge Base dengan RAG 📚

Selain membantu dalam coding, AI juga kami manfaatkan untuk hal-hal yang lebih administratif, seperti tanya jawab prosedur ISO 27001. Biasanya, ada pertanyaan seperti, “ Apakah langkah ini melanggar standar ISO? ” atau “ Bagaimana caranya meminimalkan risiko ini? ” Dengan AI, kami bisa mendapatkan jawaban awal untuk bahan diskusi. AI nggak selalu akurat 100% , tapi cukup membantu memberikan gambaran awal.

Selain itu, ketika tim rilis fitur baru , biasanya harus membuat release notes yang digunakan tim Customer Success Associate atau Marketing. Dengan RAG (Retrieval-Augmented Generation), mereka tinggal unggah release notes-nya, dan AI bisa langsung menjawab pertanyaan seperti, “Fitur baru ini apa keunggulannya untuk user?” atau “Apakah ada hal penting yang perlu disampaikan ke customer?” Ini cukup menghemat waktu dibanding mereka harus membaca dokumen secara manual dan harus meeting lagi ke tim produk dan engineer. ⏱️

Eksplorasi NotebookLM untuk Manajemen Informasi 📝

Kami juga mencoba NotebookLM dari Google. Konsepnya mirip RAG, tapi lebih fleksibel karena bisa menggabungkan berbagai sumber data seperti PDF, link website, sampai catatan rapat. Misalnya, untuk satu fitur, semua dokumen seperti PRD, test case UAT, hingga catatan mingguan tim bisa disimpan di satu tempat. Jadi, kalau ada yang butuh informasi, tinggal tanya ke AI tanpa harus bolak-balik membuka banyak file. 📂

AI untuk Komunikasi & Bahasa Gen Z 🗣️

Dalam hal komunikasi, AI juga lumayan membantu, terutama dalam menyusun email atau dokumen formal dalam bahasa Inggris. Saya contohnya nggak begitu fasih berbahasa Inggris , jadi AI cukup sering jadi teman discuss dalam hal ini. 😅

Dan satu hal lucu, saya juga pakai AI untuk memahami bahasa Gen Z. Tim kami mayoritas Gen Z, dan mereka punya banyak istilah yang kadang bikin saya bingung. Saya sering meminta bantuan AI buat nge-translate maksud mereka. Jadi, selain membantu soal teknis, AI juga jadi teman buat saya beradaptasi dengan cara komunikasi mereka , terutama dalam komunikasi dengan Gen Z plus pakai bahasa Inggris. Ini double punchline! Kenapa double punchline? Karena kedua hal tersebut saya nggak begitu fasih. 🤣

Mengurangi Distraksi 🚫📱

Terakhir, AI membantu mengurangi distraksi dalam pekerjaan. Sebelum ada AI, kalau ada masalah atau bug, kami sering harus bolak-balik antara browser dan code editor untuk mencari solusi di StackOverflow. Sekarang, banyak masalah bisa diselesaikan langsung di editor dengan bantuan AI. Misalnya, AI bisa membantu merekomendasikan cara membuat kode lebih rapi , lebih readable , atau bahkan lebih sesuai standar.

Buat kami, AI bukan hanya alat , tapi partner yang membantu mempercepat pekerjaan , memberikan ide baru , dan — tanpa kami sadari — membuat proses kerja jadi lebih menyenangkan. 🎉

💡Hiring & Onboarding: Fokus ke Attitude, Bukan Cuma Skill

Selain di coding dan manajerial, kehadiran AI juga mengubah cara saya memandang proses hiring dan onboarding new member. Di SimpliDOTS , kami sangat menjunjung tinggi culture fit. Jadi, saat mencari kandidat baru, selain kemampuan teknis, kami juga memastikan mereka bisa beradaptasi dengan budaya kolaborasi dan kerja kami. 🤝

Dulu: Prioritaskan Skill, Sekarang: Seimbang dengan Attitude

Dulu, saya sering memberi prioritas tinggi pada skill. Kalau ada kandidat yang skill-nya luar biasa, tapi attitude-nya kurang, kadang tetap saya loloskan. Alasannya, saya berpikir kemampuan teknis bisa langsung memberikan hasil yang terlihat. Tapi pengalaman mengajarkan hal lain. Kandidat dengan skill tinggi tapi attitude yang kurang baik bisa menjadi tantangan di tim — bukan hanya sulit diajak kolaborasi, tapi juga bisa menciptakan lingkungan kerja yang tidak nyaman. 😕

Sekarang, saya lebih menyeimbangkan antara skill dan attitude. Kenapa? Karena dengan adanya AI, kemampuan teknis bukan lagi satu-satunya penentu. Banyak pekerjaan teknis yang bisa terbantu, bahkan dipermudah oleh AI. Tapi sikap dan bagaimana seseorang berinteraksi dengan tim — itu yang sulit digantikan. 😊

Pandangan Kandidat Terhadap AI

Dalam wawancara, salah satu pertanyaan yang sering saya ajukan adalah: “ Bagaimana pandangan kamu tentang AI? ” Saya ingin tahu apakah mereka melihat AI sebagai peluang atau ancaman. Kenapa ini penting? Karena di tim kami, AI bukan sekadar alat, tetapi bagian dari proses kerja. 🤖

Salah satu checkpoint selama masa probation adalah memastikan mereka nyaman menggunakan AI dalam proses development atau pekerjaan lainnya. Kalau sejak awal mereka sudah ragu atau melihat AI sebagai ancaman, kemungkinan besar mereka akan kesulitan beradaptasi di tim.

AI Membantu Proses Interview & Onboarding

AI juga membantu kami dalam proses seleksi. Misalnya: Generate Pertanyaan Wawancara : AI bisa merekomendasikan pertanyaan berbasis pengalaman atau hasil tes teknis kandidat. Tapi tentu saja, kami tidak langsung menerima begitu saja. Kami tetap menyesuaikan dan berdiskusi dengan tim terkait relevansi dan fokus pertanyaan tersebut. Kadang-kadang bahkan terjadi perdebatan menarik di antara kami dengan AI tentang mengapa dia merekomendasikan pertanyaan tersebut. 😄

Closing: AI Bukan Ancaman

Jadi, itulah perjalanan kami dalam mengintegrasikan AI ke dalam berbagai aspek di tempat kerja, termasuk dalam proses hiring dan onboarding. AI memang membawa perubahan, tapi tidak semuanya seseram yang dibayangkan. Malah, dengan memanfaatkan teknologi ini, kami jadi lebih kreatif , lebih efisien , dan lebih fokus pada hal-hal yang benar-benar penting — seperti membangun tim yang solid dengan budaya kerja yang positif. 🎯

Semoga cerita ini bisa memberikan gambaran dan motivasi bagi teman-teman yang masih ragu, takut tergantikan, atau justru sedang mencari cara untuk mulai memanfaatkan AI di lingkungan kerja mereka. 😊

PS : Saat ini kami baru sampai pengalaman AI sebagai partner coding. Jadi, tolong jangan ada yang tanya, AI bisa jadi partner hidup nggak? 😄