Anton Onufriienko, Direktur Manajemen di Devart – Seri Wawancara

Anton Onufriienko, Direktur Manajemen di Devart, adalah eksekutif teknologi dan operator dengan pengalaman mendalam dalam menskalakan bisnis perangkat lunak, mengarahkan pertumbuhan pendapatan, dan memimpin tim fungsional besar di seluruh SaaS, perangkat lunak perusahaan, dan layanan keuangan. Selama karirnya, ia telah berkembang dari membangun organisasi penjualan dan meluncurkan startup hingga mengawasi operasi P&L penuh untuk unit bisnis besar, termasuk divisi terbesar Devart dengan lebih dari 130 karyawan. Sebelum menjadi Direktur Manajemen, ia menjabat sebagai Chief Revenue Officer dan Kepala Penjualan Devart, di mana ia memimpin strategi go-to-market, transformasi harga, dan inisiatif pertumbuhan internasional. Ia juga merupakan CEO dari TMetric, platform pelacakan waktu dan profitabilitas yang berfokus pada membantu bisnis yang didorong oleh layanan untuk memperoleh kejelasan operasional.

Devart adalah perusahaan perangkat lunak yang berspesialisasi dalam pengembangan database, koneksi data, integrasi, dan alat produktivitas untuk pengembang, DBA, analis, dan tim perusahaan. Didirikan pada tahun 1997, perusahaan ini paling dikenal dengan suite alat manajemen database dbForge, yang mendukung sistem database utama seperti SQL Server, MySQL, Oracle, dan PostgreSQL. Devart juga mengembangkan solusi koneksi data seperti ODBC, ADO.NET, Python, dan Delphi connector, serta Skyvia, platform integrasi data berbasis cloud untuk ETL, otomatisasi, backup, dan orkestrasi alur kerja. Perusahaan ini melayani lebih dari 500.000 pengguna di seluruh dunia, termasuk sebagian besar perusahaan Fortune 100, dan telah semakin fokus pada mengintegrasikan kemampuan AI ke dalam produknya melalui alat seperti dbForge AI Assistant, yang membantu pengembang menghasilkan, mengoptimalkan, mendebug, dan menjelaskan kueri SQL menggunakan bahasa alami.

Anda telah berkembang dari membangun dan memimpin tim penjualan ke menjalankan operasi P&L penuh dan sekarang mengelola unit bisnis terbesar Devart. Bagaimana perjalanan itu telah membentuk pendekatan Anda dalam mengintegrasikan AI ke dalam strategi produk dan pengambilan keputusan pada skala besar?

Penjualan mengajari saya untuk mengukur ROI pada segala hal. Memasuki peran CRO, saya menskalakan disiplin itu di seluruh fungsi. Menjalankan BU memaksa saya untuk menerapkan itu pada AI itu sendiri.

Saya memiliki pandangan praktis tentang AI. Ini tidak berarti saya meragukan: tiga dari empat taruhan produk kami untuk 2026 adalah AI-native. Tapi saya percaya bahwa hype menghalangi hasil yang nyata dan tahan lama.

Ada meme yang beredar yang merangkum di mana industri sering salah. Perusahaan menukar langganan SaaS seharga $400 dengan alat buatan sendiri yang biayanya $1.000 per bulan dalam biaya API dan memerlukan perbaikan terus-menerus. Itu bukan perubahan nyata, itu hanya pertunjukan yang mahal.

Pelajaran yang saya ambil dari penjualan adalah sederhana: setiap inisiatif membayar jalannya, atau itu mati. Saya menjalankan rollout AI dengan cara yang sama seperti saya menjalankan wilayah penjualan. Hipotesis ROI eksplisit per alur kerja, rollout tiga gelombang, dan dampak yang didokumentasikan sebelum penskalaan.

Titik Utara kami adalah Pendapatan per Karyawan, dan target kami adalah untuk lebih dari dua kali lipat pada akhir 2028. Anda tidak menutup celah itu dengan merekrut. Anda menutupnya dengan mengubah apa yang terlihat seperti pekerjaan, dan AI adalah satu-satunya mekanisme yang realistis pada skala itu.

Filter saya untuk setiap inisiatif AI, internal atau produk, adalah sama: apa nilai yang diukur, siapa yang membayarnya, dan bagaimana kita tahu itu berhasil? Apa pun yang gagal pada tiga pertanyaan itu tidak boleh ada di produksi. Biaya salah dalam hal ini berkompilasi dengan cepat, dan sebagian besar perusahaan akan menemukannya dengan cara yang mahal.

Devart telah membangun reputasi kuat di sekitar alat database dan produktivitas pengembang. Bagaimana Anda mengintegrasikan AI ke dalam produk-produk ini sehingga memberikan nilai nyata daripada otomatisasi permukaan?

Pengguna kami adalah spesialis teknis yang sangat teknis: DBA, insinyur senior, arsitek data. Mereka mendeteksi otomatisasi permukaan dalam beberapa detik dan merasa tidak senang ketika dijual mainan pemasaran yang disebut inovasi. Dua tahun yang lalu, ketika hype AI mencapai puncaknya dan pesaing berlomba untuk menambahkan panel obrolan ke setiap elemen antarmuka, godaan untuk mengikuti itu nyata. Saya telah melihat pola itu sebelumnya, di mobile, di cloud, di low-code, dan saya menolak untuk mengulanginya.

Disiplinnya sederhana: nilai pelanggan terlebih dahulu. Membangun fitur AI yang tidak diminta oleh siapa pun, yang tidak memberikan nilai nyata, adalah penggunaan sumber daya rekayasa yang paling buruk. Itu terutama benar ketika audiens Anda dapat membedakan perbedaannya segera.

Apa yang berubah pada 2026 adalah bahwa AI berpindah dari hype ke revolusi teknis yang nyata. Jarak antara apa yang sistem ini bisa lakukan pada 2023 dan apa yang bisa mereka lakukan sekarang tidak inkremental. Itu adalah kategori kemampuan yang sama sekali berbeda. Kami sekarang dapat menyelesaikan masalah yang sebelumnya tidak dapat diselesaikan: akses data perusahaan yang aman untuk agen AI, kecerdasan database kontekstual di dalam IDE pengembang, dan analisis bisnis otonom yang tidak memerlukan analis khusus.

Ini adalah lini produk baru yang ada karena AI membuat masalah dasar yang dapat dipecahkan. Itu adalah batang yang kami pegang untuk diri kami sendiri: produk AI yang nyata adalah produk di mana menghilangkan lapisan AI akan merusak produk. Industri telah menghabiskan dua tahun untuk menyebut panel obrolan “produk AI.” Itu adalah fitur, bukan produk.

Kami membutuhkan waktu lebih lama karena kami ingin melakukannya dengan benar. Dua belas bulan ke depan akan menunjukkan apakah disiplin itu membayar.

AI semakin banyak menulis, mengoptimalkan, dan mendebug kode. Bagaimana Anda melihat perubahan ini mempengaruhi peran pengembang yang bekerja dengan database dalam beberapa tahun ke depan?

Nilai mengetahui sintaksis SQL cepat memburuk. Jika AI dapat menghasilkan JOIN multi-tabel yang kompleks dalam beberapa detik dan mengidentifikasi indeks yang hilang dari log dalam beberapa menit, nilai seorang insinyur tidak lagi datang dari mengetikkan SQL. Bagian itu dari pekerjaan menjadi komoditas.

Tapi ada nuansa kritis yang selalu diabaikan oleh para evangelis otomatisasi total. Kesalahan AI di frontend adalah tombol yang tidak sejajar yang dapat Anda refresh. Kesalahan AI di database adalah lingkungan produksi yang dihapus, kebocoran PII, atau gangguan transaksional pada seluruh bisnis.

Database menyimpan status. Mereka tidak memaafkan halusinasi.

Asimetri itu mendefinisikan ulang peran secara keseluruhan. Dalam dua hingga tiga tahun ke depan, pengembang database dan DBA akan berkembang dari pengkode menjadi arsitek dan auditor. Pekerjaan utama mereka bergeser ke tiga hal:

• Mendesain arsitektur yang dapat diandalkan yang AI tidak dapat memahami sendiri, karena kurangnya konteks bisnis.
• Mengatur batasan keras dan kebijakan keamanan untuk agen AI yang menyentuh sistem produksi.
• Mengulas dan mengaudit kode yang dihasilkan mesin sebelum mencapai database.

Model mental yang saya kembali adalah: insinyur akan mengelola pasukan asisten AI. Alat seperti dbForge harus berkembang dari IDE tradisional menjadi pusat komando dan audit. Pekerjaan menjadi kurang tentang menulis SQL secara manual dan lebih tentang mengulas apa yang dihasilkan AI, memvalidasi, dan memaksakan batasan yang AI tidak dapat lewati dengan aman.

Kesempatan profesional di sini sangat signifikan. Pengembang yang naik ke arsitektur dan pengawasan akan mengalikan nilai pasar mereka. Mereka menjadi lapisan yang tak tergantikan antara produktivitas AI dan keamanan produksi. Premi pada keahlian database tidak menghilang; itu bergeser ke atas menuju desain, tata kelola, dan penilaian, yang tepat di mana AI tidak dapat beroperasi sendiri.

Apa yang menjadi keterbatasan terbesar dari alat AI saat ini dalam manajemen database, dan di mana Anda melihat terobosan yang paling berarti datang?

AI saat ini masih terjebak dalam otomatisasi permukaan. Menghasilkan kueri SELECT dasar atau kode boilerplate tidak lagi mengesankan. Masalah yang lebih besar adalah bahwa sebagian besar sistem AI masih berperilaku seperti pengetik buta daripada arsitek sistem. Mereka dapat menghasilkan sintaksis, tetapi mereka tidak benar-benar memahami lingkungan di mana mereka beroperasi. Terobosan yang sebenarnya terjadi ketika AI mulai bernalar tentang konteks, ketergantungan, status, dan logika bisnis bersama-sama.

Saat ini, saya melihat tiga keterbatasan utama yang menghambat AI di lingkungan database.

Pertama, ada masalah konteks. Model bahasa besar dapat melihat skema, DDL, dan nama kolom, tetapi mereka tidak benar-benar memahami rencana eksekusi, fragmentasi indeks, pola distribusi data, atau logika bisnis di balik data. Tanpa pemahaman yang lebih dalam, banyak saran optimasi menjadi tebakan statistik yang disebut keahlian.

Kedua, ada masalah halusinasi, dan perusahaan memiliki hampir tidak ada toleransi untuk itu di lapisan database. Halusinasi JOIN dapat memperlambat sistem produksi. UPDATE yang salah dapat menghapus catatan kritis. Pada tingkat itu, bahkan kegagalan akurasi kecil menjadi sangat mahal dengan sangat cepat.

Masalah ketiga adalah keamanan dan tata kelola. Tidak ada perusahaan serius yang akan menempelkan skema produksi atau PII ke alat AI publik tanpa jaminan yang kuat tentang isolasi data dan kontrol. Sampai vendor memecahkan masalah itu dengan benar, adopsi AI di industri yang diatur akan tetap terbatas.

Terobosan yang berarti akan datang ketika AI bergerak melampaui generasi sintaksis dan mulai berfungsi lebih seperti arsitek latar belakang atau analis.

Satu bagian dari itu adalah lapisan semantik: bergerak dari nama tabel mentah ke makna bisnis yang sebenarnya. Bukan hanya “tabel_pengguna”, tetapi memahami konsep seperti kohort pelanggan, risiko churn, atau tren LTV Q3.

Perubahan lainnya adalah AI yang berperilaku lebih seperti DBA senior di latar belakang. Menganalisis beban kerja secara terus-menerus, mengidentifikasi bottleneck, menyarankan indeks, mendeteksi kueri berisiko, dan menangkap masalah sebelum sistem gagal.

Kemudian Anda memiliki operasi mesin-ke-mesin, di mana agen otonom memantau beban database, menguji strategi optimasi di lingkungan yang terisolasi, dan mengirimkan perbaikan di bawah pengawasan manusia.

Itulah perkembangan yang akan membentuk lima tahun ke depan dari alat database.

Dari pengalaman Anda memimpin pendapatan dan strategi go-to-market, bagaimana AI merubah model harga, pengemasan produk, dan akuisisi pelanggan di perusahaan perangkat lunak?

Buku pedoman go-to-market tradisional sudah tidak berlaku. Kami melihatnya dalam angka kami sendiri dan di seluruh kategori alat pengembang.

Kematian akuisisi klasik. Meskipun perbaikan yang signifikan dalam peringkat pencarian di seluruh produk kami pada 2026, kami menghadapi kenyataan tanpa klik. AI pencarian memberikan jawaban langsung di halaman hasil dan menghilangkan lalu lintas situs web. Peringkat yang kuat tidak lagi diterjemahkan menjadi lead seperti yang mereka lakukan bahkan dua tahun yang lalu.

Lima tahun yang lalu, strategi konten yang kuat sudah cukup untuk mengarahkan pertumbuhan. Sekarang itu sudah menjadi syarat. LLMs menimbang kekuatan merek, menyebutkan positif, dan kepadatan komunitas ketika membentuk jawaban. Jika merek Anda tidak terlihat dan dipercaya, sistem AI berhenti menyajikannya secara konsisten. Anda tidak hanya kehilangan lalu lintas. Anda menghilang dari perjalanan pembelian sepenuhnya. Membuatnya lebih buruk, seluruh pasar telah panik ke iklan berbayar, mendorong CPC ke tingkat yang tidak masuk akal dan secara diam-diam menghancurkan ekonomi unit sebagian besar perusahaan SaaS.

Perubahan ini terutama memukul perusahaan alat pengembang tradisional. Saluran akuisisi SEO yang mengarahkan pertumbuhan sebelumnya kehilangan efisiensi dengan cepat. Siapa pun yang masih mengandalkannya sebagai pengungkit pertumbuhan utama perlu secara aktif membangun alternatif sekarang: distribusi ekosistem, komunitas, dan kemitraan.

Evolusi harga: dari kursi ke PLG 3.0. Kami memasuki fase berikutnya dari PLG. Harga per kursi mulai rusak ketika satu agen AI dapat melakukan pekerjaan beberapa karyawan. Dalam lingkungan seperti itu, mengenakan biaya berdasarkan jumlah karyawan tidak lagi masuk akal. Perusahaan yang tidak mengemas ulang produk di sekitar nilai daripada jumlah karyawan akan kehilangan MRR selama 24 bulan ke depan.

Langkah berikutnya adalah PLG 3.0: saat agen AI otonom, bukan manusia, mengevaluasi, menguji, dan membeli perangkat lunak perusahaan. Adopsi massal pola itu masih beberapa tahun ke depan, tetapi merancang produk dan harga untuk pembeli mesin adalah tugas 2026, bukan tugas 2028.

Banyak organisasi kesulitan berpindah dari eksperimen AI ke dampak produksi yang nyata. Apa yang menjadi faktor kunci yang menentukan apakah inisiatif AI benar-benar berhasil?

Sebagian besar fitur AI gagal sebelum dibangun. Mereka gagal di ruangan di mana seseorang mengatakan “kita perlu AI dalam produk ini,” bukan karena pengguna meminta, tetapi karena dewan ingin cerita AI atau pemasaran berpikir itu akan menarik audiens baru. Itu adalah dosa asal dari sebagian besar inisiatif AI, dan itu membentuk segala sesuatu yang mengikuti.

Saya terus melihat kesalahan yang sama diulangi di perusahaan yang kesulitan berpindah AI dari eksperimen ke dampak produksi yang nyata.

Kesalahan pertama adalah membangun fitur AI yang tidak diminta oleh siapa pun. Begitu fitur AI diperintahkan tanpa kebutuhan pengguna yang nyata, tim bekerja mundur dari teknologi untuk menciptakan kasus penggunaan. Hasilnya dapat diprediksi: panel obrolan yang dipasang pada antarmuka yang ada, autocomplete yang mengganggu, tombol “ringkas” yang menghasilkan output yang lebih buruk daripada yang dapat ditulis pengguna sendiri. Fitur-fitur ini dikirim, mendapatkan rilis pers, dan diam-diam underperform setiap prakiraan adopsi. Kerusakan yang lebih dalam adalah bahwa mereka mengkonsumsi kapasitas rekayasa yang seharusnya pergi ke fitur yang diminta pengguna.

Masalah kedua adalah tim sangat meremehkan perbedaan antara data demo yang bersih dan data produksi yang sebenarnya. Demo AI berjalan pada contoh yang bersih dan dikurasi. Produksi berjalan pada kekacauan sebenarnya dari data pelanggan: duplikat, bidang yang hilang, sepuluh cara untuk menulis nama produk yang sama, lima belas tahun kasus tepi warisan. Model yang mencapai akurasi yang mengesankan dalam evaluasi dapat memburuk secara signifikan pada data langsung, dan sebagian besar tim tidak menemukan ini sampai pengguna mengeluh. Biaya penemuan itu dalam kepercayaan produksi tidak dapat pulih.

Masalah umum lainnya adalah penelitian pengguna. Wawancara produk standar tidak berfungsi untuk fitur AI. Pengguna tidak dapat mengartikulasikan apa yang mereka inginkan dari AI karena mereka tidak tahu apa yang mungkin. Bertanya “apakah Anda menggunakan AI untuk melakukan X?” mendapatkan jawaban ya yang sopan yang tidak memiliki nilai prediktif untuk adopsi. Penelitian produk AI yang efektif memerlukan menampilkan prototipe, mengamati penggunaan nyata, dan mengukur apakah pengguna kembali setelah kebaruan memudar. Sedikit tim produk yang telah membangun kembali praktik penelitian mereka untuk ini. Mereka masih menjalankan playbook 2019 untuk masalah 2026.

Dan akhirnya, banyak perusahaan mengukur aktivitas AI alih-alih dampak bisnis. “Dua ratus orang menggunakan fitur AI ini minggu ini” adalah metrik adopsi, bukan metrik dampak. Dampak yang sebenarnya adalah waktu siklus yang berkurang, kualitas yang ditingkatkan, pendapatan yang dihasilkan, atau biaya yang dihilangkan. Jika Anda tidak dapat menggambar garis lurus dari fitur AI ke angka pada P&L, Anda tidak memiliki dampak produksi. Anda memiliki aktivitas yang mahal.

Ada faktor kelima yang menjadi semakin kritis dan yang sebagian besar tim produk abaikan sepenuhnya.

Kepatuhan dan jalur bangun AI-bebas. Bagian yang signifikan dari pengguna perusahaan di keuangan, perawatan kesehatan, pemerintah, pertahanan, dan hukum beroperasi di bawah kebijakan yang melarang atau membatasi fitur AI di perangkat lunak vendor. Jika produk Anda menghubungkan AI ke pengalaman inti tanpa cara untuk menonaktifkan atau melewati, Anda tidak memperluas audiens dengan menambahkan AI. Anda kehilangan segmen dari audiens yang ada.

Ini adalah masalah yang kami pecahkan dengan Konektivitas AI. Tim kepatuhan di industri yang diatur tidak keberatan dengan AI itu sendiri. Mereka keberatan dengan data yang meninggalkan perimeternya. Solusinya bukanlah menghilangkan AI; itu memberikan organisasi tersebut arsitektur AI yang sesuai dengan kendala mereka. Itulah mengapa Konektivitas AI dikirim sebagai on-premise: kemampuan AI tetap, data tidak pernah meninggalkan infrastruktur pelanggan, dan pengadaan melewati tinjauan pada putaran pertama bukan putaran ketiga.

Tim yang melakukan ini dengan benar merancang untuk kepatuhan dari hari pertama. Tim yang salah menemukan masalah itu selama tinjauan pengadaan, ketika kesepakatan sudah hilang.

Devart beroperasi di seluruh ekosistem database yang berbeda. Bagaimana AI dapat membantu menyederhanakan kompleksitas yang meningkat dalam mengelola data di berbagai platform?

Rasa sakitnya nyata. Perusahaan Fortune 500 rata-rata menjalankan delapan hingga dua belas mesin database yang berbeda secara bersamaan: Oracle warisan untuk keuangan, PostgreSQL untuk layanan baru, SQL Server untuk operasi, Snowflake atau BigQuery untuk analitik, dan semakin banyak toko vektor untuk embedding. Masing-masing memiliki dialeknya sendiri, toolingnya sendiri, rezim tata kelolanya sendiri. Pengembang yang bergabung dengan lingkungan itu dapat menghabiskan tiga bulan hanya untuk mempelajari di mana data berada dan siapa yang diizinkan untuk menyentuhnya.

AI tidak memperbaiki kompleksitas itu sendiri. Ini memperkuat konteks apa pun yang diberikan. Delapan database yang terputus dengan metadata yang tidak terpadu menghasilkan delapan set saran yang terputus. Itu adalah mode kegagalan yang kami lihat di sebagian besar rollout AI perusahaan di tumpukan.

Kesempatan itu ada di lapisan konteks yang duduk di antara agen AI dan database yang mendasarinya. Satu yang berbicara dengan semuanya, menormalkan metadata, memaksakan kebijakan tata kelola yang terpadu, dan mengekspos antarmuka MCP yang bersih sehingga agen AI mana pun, apakah Claude, GPT, atau model internal, bekerja di seluruh estate dengan aturan yang konsisten.

Itulah arsitektur yang kami bangun menuju dengan Konektivitas AI: server MCP on-premise dengan dukungan multi-database, lapisan semantik yang menangkap definisi bisnis sekali daripada memaksa setiap agen AI untuk mempelajarinya kembali, kontrol akses berbasis peran pada tingkat operasi SQL, dan log audit lengkap.

Penyederhanaan tidak gratis. Seseorang masih harus memodelkan lapisan semantik dan menetapkan kebijakan. Tapi pekerjaan itu terjadi sekali, bukan berulang kali untuk setiap agen AI yang Anda tambahkan.

Anda telah memimpin tim fungsional besar. Bagaimana AI mengubah kolaborasi internal dan pengambilan keputusan antara produk, teknik, pemasaran, dan penjualan?

Sebagian besar gesekan antar fungsional sebenarnya hanya orang-orang yang menunggu informasi dari tim lain. AI menghilangkan gesekan itu lebih cepat daripada kerangka manajemen apa pun yang pernah bisa.

Perubahan itu praktis dan segera.

Di produk dan teknik: manajer produk bertanya pertanyaan database dalam istilah bisnis yang sederhana, “apa varians LTV di seluruh tiga tingkat harga teratas kami?”, dan mendapatkan jawaban yang dapat digunakan segera, bukan dengan mengajukan tiket Jira ke analitik dan menunggu tiga hari.

Di pemasaran dan data: analisis kohort terjadi secara inline, bukan melalui antrian permintaan. Manajer pemasaran bertanya, mendapatkan angka, dan membangun kampanye, semua dalam satu pagi.

Di penjualan dan teknik: jawaban teknis untuk prospek tidak lagi memerlukan panggilan dengan insinyur senior. Perwakilan penjualan mendapatkan jawaban teknis yang kredibel secara real-time, dan siklus penjualan terkompresi.

Keputusan bergerak ke dalam percakapan daripada ke dalam follow-up. Pola “biarkan saya kembali ke Anda dengan itu” mati. Pertemuan menyusut karena AI menangani pra-baca dan ringkasan yang sebelumnya menghabiskan setengah pertama dari setiap sesi.

Ini memaksa pergeseran manajemen yang lebih dalam, dan itu adalah yang paling banyak tim manajemen meremehkan.

Setiap perusahaan mengklaim bahwa mereka berorientasi pada hasil. Lihat di bawah kap, dan sebagian besar masih berjalan pada metrik proxy: poin cerita, baris kode, tiket yang ditutup, jam yang dicatat. Kami menggunakan aktivitas sebagai proxy untuk nilai karena nilai yang sebenarnya sulit diukur. AI mematahkan proxy itu secara permanen. Ketika agen dapat menulis 10.000 baris kode atau menutup 500 tiket dukungan dalam satu menit, mengukur aktivitas menjadi sangat menyesatkan.

Kami beralih secara eksplisit ke Manajemen yang Berorientasi pada Hasil Sebenarnya, di mana kinerja diukur secara ketat oleh hasil dan penilaian. Kejam dalam prakteknya, karena sebagian besar sistem kinerja tidak dibangun untuk itu. Orang-orang yang biasanya bersembunyi di balik aktivitas tinggi menjadi terlihat segera, dan kepemimpinan harus siap untuk bertindak berdasarkan visibilitas itu.

Konsekuensi strukturalnya adalah bagan organisasi yang lebih datar. Lapisan koordinasi dan pengiriman informasi terkompresi. Organisasi yang beradaptasi dengan cepat akan beroperasi dengan struktur yang secara fungsional lebih sedikit orang dengan pengaruh yang lebih tinggi.

Dengan munculnya pengembangan yang dibantu AI dan alat no-code, apakah kita menuju masa depan di mana manajemen database menjadi dapat diakses oleh pengguna non-teknis?

Ada kebingungan berbahaya di industri saat ini. Orang-orang memperlakukan database proyek sampingan dan database perusahaan warisan sebagai jika mereka sama. Mereka tidak sama.

Untuk proyek kecil yang baru, demokratisasi sudah ada. Saya secara pribadi telah membangun aplikasi kecil dari awal tanpa keahlian manajemen database yang mendalam. Jika skema Anda sesuai dengan jendela konteks LLM, AI bekerja seperti ajaib. Pengembang warga yang membangun alat internal pada skala kecil akan menjadi kategori yang nyata dan tumbuh.

Kenyaatan perusahaan adalah sangat berbeda. Database warisan besar menghadapi masalah yang sama dengan kode basis monolitik: dinding konteks. Anda tidak dapat memasukkan lima belas tahun evolusi skema yang tidak terdokumentasikan, ketergantungan antar database, dan logika khusus ke dalam prompt. Ketika AI kehilangan konteks pada database besar, halusinasi tidak memburuk dengan cara yang elegan. Mereka berkembang biak secara eksponensial.

Risiko yang kurang dibahas adalah kepercayaan diri palsu pada skala. Antarmuka bahasa alami sangat baik dalam menghasilkan jawaban yang terlihat masuk akal tetapi salah. Jika kueri SQL memiliki kesalahan sintaksis, Anda mendapatkan pesan kesalahan. Jika antarmuka bahasa alami salah mengartikan “pelanggan aktif” karena data Anda memiliki enam definisi aktivitas yang berbeda, Anda mendapatkan angka. Angka itu terlihat baik. Mungkin salah sebesar 30%. Pengguna tidak memiliki cara untuk mengetahuinya.

Jadi tidak, manajemen database perusahaan tidak menjadi taman bermain untuk pengguna non-teknis.

Citizen DBA adalah mitos pada skala.

Masa depan milik arsitek data yang ahli yang menggunakan alat profesional untuk menjembatani kesenjangan konteks dan membangun infrastruktur yang memungkinkan AI beroperasi dengan aman di atasnya.

Perbaikan struktural adalah lapisan semantik: kosakata yang dikendalikan di mana definisi bisnis diperbaiki sekali dan digunakan kembali di seluruh interaksi AI. Itu adalah arsitektur inti yang kami bangun ke Insightis. Tanpa itu, aksesibilitas menjadi kewajiban.

Menghadap ke depan, apa yang terlihat seperti toolkit pengembang “AI-native”, dan bagaimana tim harus memulai mempersiapkan diri untuk perubahan itu hari ini?

Toolkit pengembang AI-native bukanlah chatbot yang dipasang pada IDE. Sebagian besar apa yang dipasarkan sebagai “AI-native” saat ini adalah antarmuka obrolan plus model autocomplete. Itu adalah syarat, bukan tujuan.

Bagi saya, toolkit pengembang AI-native yang sebenarnya memerlukan tiga hal.

Pertama, AI memerlukan konteks yang dalam. Ini harus memahami kodebase Anda, infrastruktur Anda, keputusan historis Anda, dan lingkungan data Anda secara terus-menerus, bukan hanya melalui prompt yang ditempelkan ke jendela obrolan. Sebagian besar alat saat ini gagal dalam tes ini. Konteks mereka reset dengan setiap sesi, dan pengguna membayar biaya membangunnya kembali secara konstan.

Kedua, alat itu sendiri perlu berkomunikasi satu sama lain dengan benar. IDE Anda harus berbicara dengan database, database ke tumpukan observabilitas, dan CI/CD ke pengulas AI, dll. Protokol Konteks Model menjadi lapisan standar di sini, dengan 97 juta unduhan SDK per bulan di Q1 2026, naik dari 100.000 pada akhir 2024. Itu adalah peningkatan 970x dalam lima belas bulan dan kurva adopsi tercuram yang pernah saya lihat di infrastruktur pengembang.

Ketiga, AI produksi memerlukan pagar pengaman yang serius. Pratinjau radius ledakan sebelum operasi destruktif. Analisis ketergantungan. Rencana rollback otomatis. Log audit secara default. AI tanpa itu baik untuk prototipe dan berbahaya di produksi.

Cara mempersiapkan diri, secara konkret.

Periksa tumpukan Anda terhadap tiga komponen tersebut. Apakah setiap alat mengekspos API dan MCP? Apakah itu berbicara dengan yang lain, atau duduk di silo? Apakah itu memiliki kontrol keamanan? Alat yang gagal dua dari tiga adalah aset jangka pendek.

Bangun infrastruktur konteks sekarang. Dokumentasikan skema, definisi bisnis, dan keputusan arsitektur dalam format yang dapat dibaca mesin. Konteks yang kaya tidak dibangun dalam satu kuartal. Tim yang AI-nya memiliki konteks pada 2027 adalah tim yang mendokumentasikan hari ini.

Jalankan AI di produksi sebelum Anda pikir Anda siap. Tim yang menunggu strategi AI formal sebelum mengirimkan akan tertinggal delapan belas bulan di belakang tim yang sudah belajar dari kegagalan produksi yang nyata. Pilih kasus penggunaan yang berisiko rendah. Kirim. Bangun otot.

Tim yang membuat keputusan ini hari ini akan mendefinisikan dekade berikutnya tentang bagaimana perangkat lunak dibangun. Jendela itu sempit, dan itu terbuka sekarang.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Devart.