DEV Community: Ifan Jaya Suswanto Zalukhu

#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 😊

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

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? 😄

Belajar Leadership dari Kisah Anak Kecil

Ifan Jaya Suswanto Zalukhu — Fri, 18 Oct 2024 17:19:49 +0000

Hai teman-teman! Kali ini, aku mau berbagi tentang pelajaran berharga soal leadership yang aku temukan dari sebuah video reels parenting. Kedengarannya menarik, kan?

This image was created with the help of partyrock.aws

Sebelum masuk ke ceritanya, aku kasih sedikit latar belakang dulu ya. Saat ini, aku adalah seorang leader baru di salah satu tech startup di Medan. Karena masih baru, aku selalu berusaha belajar dan terus mengamati berbagai hal agar bisa terus berkembang, terutama dalam hal leadership.

Di tempat kerja, setiap akhir bulan, kami punya sesi feedback 360. Di sesi ini, setiap anggota tim saling memberi apresiasi dan juga masukan untuk perbaikan. Ini juga jadi momen aku buat mengamati leader lain, termasuk atasan, terutama saat mereka menerima feedback yang konstruktif dari tim.

Biasanya, kalau aku melihat leader lain dapat feedback yang cukup tegas, aku coba membayangkan diri di posisi mereka. Aku berpikir, “Kalau aku yang dapat feedback ini, bagaimana aku akan merespons dan apa langkah yang harus aku ambil untuk memperbaiki diri?” Setelah itu, aku bandingkan dengan solusi yang dipilih oleh leader tersebut. Kalau beda, aku suka diskusi dengan mereka untuk memahami alasan di balik pilihan mereka. Dari sini, aku bisa belajar banyak tentang cara berpikir mereka.

Nah, suatu hari, di sesi feedback, ada anggota tim dari divisi lain yang memberikan masukan ke leader mereka. Feedback-nya kurang lebih begini:

“Kak Amer akhir-akhir ini fokusnya cuma ke anggota tim yang baru. Kita yang lama jadi kurang diperhatikan, komunikasi juga jarang, nggak seperti dulu. Sementara ke anggota tim baru, dia sangat perhatian.”

_FYI, nama Kak Amer ini nama samaran ya, karena aku belum izin pakai nama aslinya. Dan sebelum ada yang nanya, Amer di sini juga bukan Anggur Merah ya _😂😂

Waktu mendengar feedback ini, aku agak terkejut, karena aku juga sering seperti itu ke timku. Biasanya, aku berpikir anggota tim yang sudah lama lebih mandiri dan nggak perlu di-micromanage. Fokusku lebih ke anggota tim baru yang masih perlu penyesuaian dan bimbingan. Jadi, aku sempat bertanya-tanya, kenapa hal ini jadi feedback? Bukannya lebih logis kalau yang perlu perhatian lebih itu yang baru?

Lalu, suatu sore, saat aku lagi scroll reels di Instagram, aku menemukan video parenting yang ngena banget. Di video itu, ada seorang ibu yang sedang menyuapi anak bungsunya, sementara anak sulungnya bertanya:

Anak: “Mami, mami udah nggak sayang aku lagi ya?”

Mami: (kaget) “Sayang dong! Kenapa kamu tanya begitu?”

Anak: “Soalnya akhir-akhir ini mami cuma perhatian ke adik. Dulu mami masih suka nyuapin aku, pakaikan baju. Sekarang nggak lagi. Jadi aku pikir mami lebih sayang sama adik daripada aku.”

Mami: “Oh, maaf ya. Mami nggak tahu kamu merasa begitu. Mami pikir karena kamu sudah besar dan bisa makan sendiri, kamu nggak butuh disuapin lagi. Kalau kamu masih mau disuapin, besok mami suapin lagi ya?”

Anak: “Iya, mami, tapi nggak usah tiap hari. Sekali-sekali aja.”

Mami: “Oke, kalau kamu mau, bilang aja ke mami ya.”

(Setelah itu, anaknya tersenyum senang.)

Setelah nonton video ini, aku langsung tercerahkan! Ternyata, bukan hanya tim baru yang butuh perhatian, anggota tim lama juga mungkin kadang-kadang butuh perhatian dan komunikasi. Sebelumnya, aku selalu melihat dari sudut pandang “ibu” alias leader, bukan dari sudut pandang anggota tim. Dari sini, aku belajar kalau komunikasi terbuka sangat penting. Jadi, bukan cuma asumsi atau dugaan, tapi benar-benar mendengarkan apa yang dirasakan oleh anggota tim.

Kalau di video tadi si anak nggak mengungkapkan perasaannya, dan malah hanya ngambek atau menyimpan perasaan itu sendiri, masalahnya nggak akan pernah selesai. Dan ini sama seperti hubungan leader dengan tim — kalau nggak ada komunikasi yang baik, masing-masing pihak bisa merasa frustrasi karena nggak tahu apa yang dirasakan atau diinginkan satu sama lain.

Poin yang aku pelajari:

• Komunikasi terbuka itu penting banget dalam tim. Ini yang bikin kita bisa terus berkembang.

• Leadership bisa kita pelajari dari mana saja, bahkan dari kisah parenting atau anak kecil!

Semoga cerita ini bisa memberikan insight baru buat teman-teman, terutama yang juga masih baru jadi leader.

Ketika Olahraga Menjadi Filosofi Hidup

Ifan Jaya Suswanto Zalukhu — Sun, 09 Jun 2024 13:21:17 +0000

Akhir-akhir ini saya mencoba aktif kembali berolahraga di akhir pekan.

Awalnya sih, alasannya untuk mengikuti program internal di kantor, yaitu SimpliDOTS Sport Week. Saya juga tertantang untuk meningkatkan progres setiap minggunya di aplikasi sport tracker, dari yang awalnya 5 KM, jadi naik ke 6, 7 KM, dan seterusnya.

Alasan lain saya berolahraga adalah untuk dipamerkan di sosmed 😄, karena kalau pamer harta, belum banyak yang bisa dipamerkan 😂.

Walau itu motivasi awalnya, belakangan ini olahraga sudah sedikit menjadi kebiasaan demi kesehatan. Agak lucu juga, aplikasi / API dijaga agar hasil health check selalu healthy, tapi diri sendiri malah tidak 😀

Beberapa waktu lalu, saat lagi ngos-ngosan lari, salah satu teman saya mengeluarkan filosofi yang menurut saya pasti ngawur.

“Fan, kamu tahu nggak, olahraga itu ibarat investasi, belajar, dan menanam tanaman. Apa yang kita lakukan sekarang tidak langsung memberikan hasil, tapi butuh proses, konsistensi, kesabaran, dan usaha.

Kita mulai secara bertahap, seperti melakukan dollar cost averaging setiap bulan untuk mencapai portofolio investasi yang lebih besar. Juga ibarat belajar, mengumpulkan kepingan puzzle yang tidak jelas di awal, tapi akhirnya membentuk gambar yang indah setelah kita berjuang dan tidak menyerah.

Tapi Fan, kamu tahu apakah selalu happy ending setelah kita melakukan semua itu?

Kadang hasilnya tidak sesuai dengan ekspektasi awal. Misalnya saat musim panen tiba-tiba gagal panen karena serangan hama atau cuaca buruk, atau yang paling lucu, kamu salah pilih biji di awal. Kamu ingin menanam nangka, eh ternyata yang kamu tanam biji cempedak.

Tapi apakah semuanya sia-sia? Enggak juga, karena dari setiap usaha dan pembelajaran pasti ada hal baru yang kita dapatkan. Misalnya, kita jadi tahu cara membedakan biji nangka dan cempedak, serta lebih berusaha dan penuh perencanaan untuk mengatasi kegagalan panen ke depannya, sehingga hasil yang didapatkan lebih melimpah dan memuaskan.”

Sambil mengangguk-angguk, saya berpikir bagaimana caranya menghentikan si lapet ini agar segera berhenti dengan filosofi konyolnya, karena langit sudah mulai gelap dan gerimis.

Akhirnya, dia selesai juga. Pelajaran yang saya ambil: kadang cerita saat olahraga bisa imajinatif karena orang yang bicara ngos-ngosan dan kekurangan oksigen, sehingga fungsi kognitifnya menurun 😄.