Anton Onufriienko, Managing Director di Devart – Seri Wawancara

Anton Onufriienko, Managing Director di Devart, adalah eksekutif teknologi dan operator dengan pengalaman mendalam dalam menskala 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 utama, termasuk divisi terbesar Devart dengan lebih dari 130 karyawan. Sebelum menjadi Managing Director, 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 memperoleh kejelasan operasional.

Devart adalah perusahaan perangkat lunak yang mengkhususkan diri dalam pengembangan database, konektivitas data, integrasi, dan alat produktivitas untuk pengembang, DBA, analis, dan tim perusahaan. Didirikan pada tahun 1997, perusahaan ini paling dikenal karena suite alat manajemen database dbForge, yang mendukung sistem database utama seperti SQL Server, MySQL, Oracle (ORCL ), dan PostgreSQL. Devart juga mengembangkan solusi konektivitas 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 yang ditenagai 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 bukan karena saya ragu: tiga dari empat taruhan produk kami untuk 2026 adalah AI-asli. Tapi saya percaya bahwa hype menghalangi hasil yang nyata dan bertahan 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 di penjualan adalah sederhana: setiap inisiatif membayar jalannya, atau itu mati. Saya menjalankan rollout AI saya dengan cara yang sama seperti saya menjalankan wilayah penjualan. Hipotesis ROI eksplisit per alur kerja, rollout tiga gelombang, dan dampak yang didokumentasikan sebelum penskalaan.

Metrik Bintang Utara kami adalah Pendapatan per Karyawan, dan target kami adalah untuk lebih dari dua kali lipat pada akhir 2028. Anda tidak menutup kesenjangan itu dengan merekrut. Anda menutupnya dengan mengubah apa yang terlihat seperti pekerjaan, dan AI adalah mekanisme yang paling 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 untuk salah dalam hal ini berkompilasi dengan cepat, dan sebagian besar perusahaan akan menemukan bahwa dengan cara yang mahal.

Devart telah membangun reputasi yang kuat di sekitar alat database dan produktivitas pengembang. Bagaimana Anda mengintegrasikan AI ke dalam 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 suka ketika dijual mainan pemasaran yang disebut inovasi. Dua tahun yang lalu, ketika hype AI mencapai puncaknya dan pesaing berlomba untuk memasang panel obrolan pada 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 pelanggan, yang tidak memberikan nilai nyata, adalah penggunaan sumber daya rekayasa yang paling buruk. Itu terutama benar ketika audiens Anda dapat mendeteksi perbedaan 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 bukanlah inkremental. Ini 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 diselesaikan. Itu adalah batasan yang kami tetapkan untuk diri kami sendiri: produk AI yang nyata adalah produk di mana menghapus 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 dari mengetahui sintaks SQL memburuk dengan cepat. 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 penggemar otomatisasi total. Kesalahan AI di frontend adalah tombol yang tidak sejajar yang Anda refresh. Kesalahan AI di database adalah lingkungan produksi yang dihapus, kebocoran PII, atau shutdown transaksional seluruh bisnis.

Database menyimpan keadaan. 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 memeriksa kode yang dihasilkan mesin sebelum mencapai database.

Model mental yang saya kembalikan: insinyur akan mengelola pasukan asisten AI. Alat seperti dbForge harus berkembang dari IDE tradisional menjadi pusat perintah 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 meningkatkan kemampuan mereka ke arsitektur dan pengawasan akan mengalikan nilai pasar mereka. Mereka menjadi lapisan yang sangat penting 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?

AI saat ini masih terjebak dalam otomatisasi permukaan. Menghasilkan kueri SQL 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 sintaks, tetapi mereka tidak benar-benar memahami lingkungan di mana mereka beroperasi. Terobosan nyata terjadi ketika AI mulai bernalar tentang konteks, ketergantungan, keadaan, dan logika bisnis bersama-sama.

Saat ini, saya melihat tiga keterbatasan utama yang membatasi AI dalam 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 dalam alat AI publik tanpa jaminan yang kuat seputar isolasi data dan kontrol. Sampai vendor menyelesaikan itu dengan benar, adopsi AI di industri yang diatur akan tetap terbatas.

Terobosan yang berarti akan datang ketika AI bergerak melampaui generasi sintaks 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.

Bagian 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 pengembangan alat database.

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

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

Kematian akuisisi klasik. Meskipun peringkat pencarian yang signifikan di seluruh produk kami pada 2026, kami menghadapi kenyataan tanpa klik. AI pencarian memberikan jawaban langsung di halaman hasil dan menghabiskan 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 cukup untuk mengarahkan pertumbuhan. Sekarang itu adalah syarat minimum. LLM mempertimbangkan kekuatan merek, penyebutan positif, dan kepadatan komunitas ketika membentuk jawaban. Jika merek Anda tidak terlihat dan dipercaya, sistem AI berhenti menyajikan Anda 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 diam-diam menghancurkan ekonomi unit dari sebagian besar perusahaan SaaS.

Perubahan ini sangat mempengaruhi perusahaan alat pengembang tradisional. Saluran akuisisi yang didorong oleh SEO yang mendukung generasi B2B SaaS sebelumnya kehilangan efisiensi dengan cepat. Siapa pun yang masih mengandalkannya sebagai tuas 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 runtuh 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 ketika agen AI otonom, bukan manusia, mengevaluasi, menguji, dan membeli perangkat lunak perusahaan. Adopsi massal pola itu masih beberapa tahun ke depan, tetapi membangun 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 dalam 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 ramalan adopsi. Kerusakan yang lebih dalam adalah bahwa mereka menghabiskan 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 legacy. 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 hampir tidak dapat dipulihkan.

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 terjadi. Menanyakan “apakah Anda akan 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 kebaruannya 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 minggu ini” adalah metrik adopsi, bukan metrik dampak. Dampak nyata 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 penting dan yang sebagian besar tim produk abaikan sepenuhnya.

Kepatuhan dan jalur pembangunan 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 dalam 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 sudah 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 bukan untuk menghilangkan AI; itu memberikan organisasi tersebut arsitektur AI yang sesuai dengan keterbatasan 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 legacy 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 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 kebijakan metadata, menegakkan 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 penuh.

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, rekayasa, pemasaran, dan penjualan?

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

Perubahan itu praktis dan segera.

Di produk dan rekayasa: manajer produk mengajukan 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 mengajukan pertanyaan, mendapatkan angka, dan membangun kampanye, semuanya dalam satu pagi.

Di penjualan dan rekayasa: jawaban teknis untuk prospek tidak lagi memerlukan panggilan dengan insinyur senior. Wakil penjualan mendapatkan respons teknis yang kredibel secara real-time, dan siklus penjualan dikompresi.

Keputusan bergerak ke dalam percakapan daripada ke dalam tindak lanjut. Pola “biarkan saya kembali kepada Anda dengan itu” mati. Pertemuan menyusut karena AI menangani pra-baca dan ringkasan yang sebelumnya menghabiskan setengah pertemuan.

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

Setiap perusahaan mengklaim bahwa mereka berorientasi pada hasil. Lihat di bawah tenda dan sebagian besar masih berjalan pada metrik proksi: poin cerita, baris kode, tiket yang ditutup, jam yang dicatat. Kami menggunakan aktivitas sebagai proksi untuk nilai karena nilai sebenarnya sulit diukur. AI memecahkan proksi 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 bergerak 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 yang sebelumnya bersembunyi di balik aktivitas tinggi menjadi terlihat segera, dan kepemimpinan harus siap untuk bertindak berdasarkan visibilitas itu.

Akibat strukturalnya adalah bagan organisasi yang lebih datar. Lapisan koordinasi dan pengiriman informasi mengompresi. Organisasi yang beradaptasi dengan cepat akan beroperasi dengan struktur yang secara fungsional lebih sedikit orang dengan leverage 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 mengobati database proyek sampingan dan database perusahaan legacy sebagai jika mereka sama. Mereka tidak sama.

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

Realitas perusahaan adalah sangat berbeda. Database legacy 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 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.

Penyelesaian 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-asli”, dan bagaimana tim harus memulai mempersiapkan diri untuk perubahan itu hari ini?

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

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

Pertama, AI memerlukan konteks yang dalam. Ini harus memahami kode basis 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 terus-menerus.

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 peninjau AI, dan seterusnya. Protokol Konteks Model menjadi lapisan standar di sini, dengan 97 juta unduhan SDK per bulan di Q1 2026, naik dari 100.000 di 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 dalam produksi.

Cara mempersiapkan diri, secara konkret.

Periksa tumpukan Anda melawan 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 memiliki AI dengan konteks itu pada 2027 adalah tim yang mendokumentasikan hari ini.

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

Tim yang membuat keputusan 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.