Coding agentic: Diskusi meja bundar dengan para pemimpin industri

Halo semuanya.

Anda telah mendengar dari banyak Googler Android minggu ini, atau dua hari terakhir ini.

Jadi, kami pikir akan sangat menyenangkan untuk menutup konferensi dengan mendengarkan beberapa orang dari luar, dari komunitas, dari komunitas Android Dev.

Kita akan membahas coding agentic dan dampak nyatanya.

Jadi, kita akan mulai dengan memperkenalkan diri.

Nama saya Ben, Android DevRel.

Anda sudah mendengar dari saya sekali dalam konferensi ini, tetapi mari kita lanjutkan ke panel.

Halo semuanya.

Nama saya Vinay, dan saya mendukung upaya alat AI di Databricks.

Senang bisa berada di sini.

Halo, saya Luis Artola.

Saya bekerja untuk Google Maps.

Saya memimpin tim yang menggunakan AI untuk membangun pengalaman agentic dan meningkatkan siklus pengembangan software.

Halo, saya Annyce Davis.

Saya bekerja di Ford.

Saya memimpin beberapa tim engineering yang mengembangkan produk langganan dan loyalitas kami.

Halo semuanya.

Saya Ty Smith.

Saya bekerja di Uber untuk mendukung developer kami.

Hal itu sudah lama terjadi di perangkat seluler.

Dalam beberapa tahun terakhir, fokus besar kami adalah pada era baru yang menarik ini dengan alat AI.

Halo semuanya.

Saya Kaushik Gopal.

Saya bekerja sebagai principal engineer di Instacart, dan saya memulai podcast tentang pengembangan Android yang disebut Fragmented.

Saat ini, seperti yang dikatakan Ty, kami telah sedikit mengubah strategi dan, Anda tahu, kami membahas pengembangan AI.

Oke.

Jadi, kita punya waktu 30 menit.

Saya rasa waktu akan berlalu dengan cepat, jadi kita akan langsung membahas pertanyaan-pertanyaan yang sulit.

Di Android DevRel, kami selalu mengatakan bahwa kami ingin membuat proses pembuatan aplikasi menjadi lebih cepat dan mudah.

Sekarang AI telah hadir, dan, Anda tahu, Anda telah mendengar kami di sini mengatakan, "Memang benar.

Menurut kami, proses pembuatan aplikasi jadi lebih cepat dan mudah."

Namun, saya ingin bertanya, apakah kita benar-benar mengirimkan aplikasi lebih cepat, atau apakah kita hanya menghasilkan banyak kode yang tidak mengarah ke mana-mana?

Ayo, Vinay.

Oke.

Ya, kita semua saling memandang.

Bagus sekali.

Jadi, jika Anda hanya melihat angka murni, kami pasti melihat bahwa output dalam hal PR, dalam hal baris kode, kami telah melihat akselerasi yang masif, dan sebagai hasilnya, kami juga menghadapi tantangan penskalaan bahkan dalam hal seperti tempat kami menyimpan kode, bukan?

Jadi, akselerasi itu sangat nyata.

Yang belum jelas adalah pengaruhnya terhadap hasil, dan menurut saya seluruh industri sedang mencoba mencari tahu metrik yang tepat terkait hasil, cara mengetahui pengaruhnya terhadap laba.

Namun, saya benar-benar melihatnya dalam tindakan.

Saya rasa kami telah mengirimkan lebih banyak kode dalam enam bulan terakhir dibandingkan sebelumnya, dan sekali lagi, saya akan tetap membuat hal ini ambigu, tetapi seperti jangka waktu yang sangat lama.

Dan sebagai hasilnya, saya rasa strategi kita telah berubah dalam hal cara mengukur produktivitas, bukan?

Karena ada berbagai cara untuk memikirkannya.

Kita mencoba mencari tahu cara menaikkan median, bukan?

Karena jika Anda melihat pencilan dan median, ada perbedaan 5x hingga 10x antara kedua kategori orang tersebut, dan fokus kami adalah meningkatkan batas bawah, meningkatkan median, dan membuat orang-orang tersebut seproduktif rekan-rekan di sekitar mereka yang kami lihat sama produktifnya.

Kita melihat kombinasi peran.

Beberapa orang bergerak jauh lebih cepat.

Ada orang yang memiliki seratus PR sehari yang melakukan pekerjaan luar biasa.

Namun, itulah jenis ruang tempat mereka beroperasi.

Mungkin mereka lebih banyak menggunakan teknologi baru, atau lebih fasih menggunakan alat-alat tersebut.

Kami juga melihat orang-orang yang, Anda tahu, lebih banyak bekerja di brownfield, atau pekerjaan platform, dan mereka mendukung jenis pekerjaan yang berbeda yang mungkin tidak secepat itu karena mereka harus menghabiskan lebih banyak waktu dengan penilaian manusia dan memastikan semuanya tidak akan rusak.

Dan kombinasi keduanya, Anda tahu, jauh lebih cepat daripada sebelumnya, tetapi menurut saya topik yang sangat menarik bagi kami adalah meskipun kami mengirimkan lebih banyak, apakah bisnis benar-benar mengirimkan lebih banyak kepada pengguna akhir?

Itulah area yang telah kami investasikan selama setahun terakhir untuk benar-benar memahami apakah kami mengirimkan fitur lebih cepat, bukan hanya mengirimkan kode lebih cepat?

Sinyal awal menunjukkan bahwa kami berhasil, tetapi tampilannya sangat berbeda dari sekadar PR murni.

Menurut saya, yang terjadi adalah, sangat jelas, orang-orang mengirimkan jauh lebih banyak, seperti, Anda tahu, jumlah PR, jumlahnya, seperti, Anda tahu, meningkat.

Namun, menurut saya, bahkan saat ini banyak pemikiran seperti, "Bagaimana cara kita memanfaatkan AI dan alat yang kita miliki ini untuk mempercepat proses yang ada?"

Iya, 'kan?

Misalnya, banyak cara kami mengirimkan kode sebelumnya terasa seperti kami selalu menganggap manusia sebagai seseorang yang akan mengawal ini sampai ke produksi.

Namun, menurut saya, apa yang kita lihat sekarang adalah, ya, itu berhasil.

Kami akan mengirimkan lebih banyak.

Namun, kita menghadapi setiap bottleneck yang sebelumnya tidak akan terlihat, bukan?

Karena kita tidak pernah mengalami masalah tersebut di masa lalu, tetapi sekarang, kita seperti mempercepat satu bagian dari, Anda tahu, siklus multi-langkah, dan saya pikir di situlah hal ini menjadi menarik, yaitu seperti, "Oke.

Kami memberikan lebih banyak, tetapi sekarang seperti selang pemadam kebakaran yang menyemprotkan efek."

Jadi, kita menghadapi tantangan lain.

Itu poin yang sangat menarik, bukan, karena jika dipikir-pikir, ada banyak langkah yang berbeda, tetapi dari perspektif tingkat tinggi, Anda dapat mengelompokkannya dalam tiga tahap, bukan?

Ada coding, yang jelas-jelas dipercepat.

Ada kesiapan produksi yang mencakup sejumlah hal seperti hukum, privasi, dan hal-hal yang memungkinkan Anda meluncurkan sesuatu, lalu ada peluncuran, bukan?

Lalu, pengiriman benar-benar berarti hal yang berbeda tergantung di mana Anda berada, bukan?

Jika Anda seperti produk yang sepenuhnya berada di sisi server, mungkin pengiriman berarti proses yang lebih efisien, sedangkan saat Anda mengirimkan sesuatu yang ditujukan kepada konsumen, seperti melakukan eksperimen, itu seperti berada di tengah-tengah perjalanan, bukan?

Anda masih harus melakukan banyak eksperimen dan pengukuran, dan di situlah hal ini terkait dengan apa yang Anda katakan, yaitu rasanya seperti Anda berada di area metropolitan, di jalan bebas hambatan, dan Anda mengalami choke point, lalu Anda mulai berakselerasi dan Anda merasa, "Ya, bagus.

Saya bergerak sangat cepat," tetapi sekarang Anda mencapai choke point berikutnya.

Dan apa yang dihasilkan seperti AI membuat sangat jelas bahwa Anda melihat titik-titik hambatan dengan lebih jelas, dan beberapa di antaranya tidak ada hubungannya dengan coding atau teknologi.

Hal ini berkaitan dengan proses, manusia, dan cara Anda mengoptimalkannya dengan AI.

Ini adalah tantangan yang sangat menarik tentang cara menyederhanakan proses secara menyeluruh.

Salah satu cara menarik yang kami pikirkan tentang ruang tersebut adalah, seberapa besar agensi yang dimiliki orang atau tim dalam mengirimkannya sepenuhnya?

Jadi, jika kita melihat secara internal, ada banyak tim yang mungkin membangun alat internal, atau hal-hal yang tidak dikirimkan kepada pelanggan.

Mereka mengirimkan jauh lebih cepat, bukan?

Mereka memiliki kebebasan penuh untuk segera menyampaikannya kepada pelanggan.

Jika Anda memiliki produk eksternal yang masih harus melalui eksperimen dengan pengguna, atau, Anda tahu, waktu peluncuran app store, atau, Anda tahu, bekerja dengan desain dan produk, semua hambatan lain ini bertambah, dan orang yang menulis kode memiliki lebih sedikit agensi untuk bergerak cepat dalam hal itu.

Jadi, mereka hanya akan mengalami bottleneck lainnya dalam sistem.

Jadi, menurut saya, membaginya menjadi dua area yang berbeda akan benar-benar menyoroti bagian mana dari proses bisnis Anda yang dapat ditingkatkan.

Ya, saya setuju, dan sejujurnya, saya merasa engineering tidak pernah menjadi bottleneck.

Saya sudah mengatakan ini selama bertahun-tahun.

Engineering memiliki cara yang sangat terstruktur dalam melakukan berbagai hal, dan selalu berasal dari bisnis, "Apa masalahnya?"

Anda akan mendapatkan 10 jawaban berbeda untuk pertanyaan itu.

Lalu, "Oke.

Sekarang, mari kita terjemahkan hal tersebut ke dalam beberapa solusi dengan produk.

Sekarang, mari kita renungkan hal itu sejenak.

Oh, mungkin kita bisa membahas desainnya sedikit.

Tendang ke sana."

Saat sampai ke tim engineering, kami kurang lebih tahu apa yang perlu kami lakukan.

Lalu, kita coba buka Stack Overflow, salin tempel beberapa hal, dan kirimkan hal itu.

Jadi, dengan AI, saya melihat peningkatan kecepatan terbesar terjadi pada pekerjaan terkait kepatuhan.

Hal-hal yang selalu ingin kita modernisasi, atau kita selalu ingin mengupgrade versi Spring Boot dengan cepat.

Kami melakukannya dengan sangat cepat.

Namun, untuk pengiriman fitur yang sebenarnya, saya tidak dapat mengatakan bahwa saya benar-benar melihat peningkatan yang signifikan.

Jadi, Anda semua telah membahas bahwa mungkin bottleneck telah berpindah, dan Anda mengalami proses yang dulunya bukan bottleneck, tetapi sekarang menjadi bottleneck.

Namun, proses tersebut mungkin berasal dari pelajaran yang sulit dipelajari di masa lalu, bukan?

Jadi, apakah Anda merasa tertekan untuk mengubahnya, dan menurut saya yang paling jelas adalah peninjauan kode.

Bagaimana masa depan peninjauan kode menurut kami?

Apa yang sedang kami lakukan?

Jadi, saya ingin mendengar pendapat Anda.

Hal ini kembali ke poin yang saya sampaikan.

Saya merasa banyak hambatan ini terjadi karena kita berpikir seperti, jika Anda memiliki tongkat ajaib, dan Anda dapat menciptakan kembali rekayasa perangkat lunak, dan Anda memiliki AI saat ini, apakah kita akan menggunakan banyak hal yang sama? Apakah kita akan melakukan hal yang sama?

Misalnya, peninjauan kode dilakukan karena kita memerlukan manusia untuk menyetujui sesuatu, seperti, Anda tahu, melakukan pemeriksaan silang akhir.

Saya rasa hal itu juga berubah, seperti, Anda tahu, cara kita memikirkan peninjauan kode sekarang adalah, mungkin kita harus terbuka terhadap gagasan bahwa, Anda tahu, jika Anda seperti melakukan refaktorisasi nama, atau Anda mencoba melakukan refaktorisasi kode, dan Anda tahu bahwa Anda memiliki pengujian yang bagus, yang jelas dimiliki semua orang.

Kami menggunakan AI untuk menulisnya, tidak masalah.

Tidak, seperti mungkin, Anda tahu, apakah Anda akan melakukan pekerjaan yang jauh lebih baik daripada agen itu?

Entahlah, mungkin sebaiknya jangan habiskan waktu untuk meninjaunya.

Lalu, jika Anda akan mengirimkan bug dan, Anda tahu, Anda mendapat telepon dari CEO yang pada dasarnya mengatakan, "Hei, hal ini merugikan kita sebesar X dolar," mungkin identifikasi area dan sistem di mana seperti, "Hei, ini adalah area yang penting.

Ini bukan area yang penting," lalu coba bayangkan kembali.

Sepertinya, kita tidak beroperasi seperti itu saat ini, bukan?

Sekarang, seperti, "Hei, ada PR.

Saya engineer-nya.

Saya fokus pada hal ini.

Harganya akan naik.

Saya meminta Vinay untuk melakukan peninjauan kode di tengah malam, karena saya hanya ingin menggabungkan hal ini."

Sebaliknya, mungkin kita harus memikirkan kembali banyak hal tersebut.

Saya sangat setuju, dan saya menganggap peninjauan kode sebagai masalah verifikasi. Maksud saya, di dunia tempat saya memiliki keyakinan penuh pada kemampuan saya untuk memverifikasi sesuatu, apakah saya masih akan meninjau kode 100% dari PR saya?

Mungkin tidak, bukan?

Jadi, ada dua tujuan yang dicapai melalui peninjauan kode.

Salah satunya adalah memverifikasi bahwa kita melakukan hal yang benar, dan yang kedua adalah edukasi, bukan?

Misalnya, orang-orang di sekitar Anda mengetahui apa yang Anda lakukan dan apakah mereka setuju dengan keputusan tersebut atau tidak.

Jadi, pasti ada kategori pekerjaan yang dapat kita percepat dan pastikan masuk ke dalam kode dan bahkan rilis.

Meskipun mungkin tidak berlaku untuk 100% kasus, saya rasa ini berlaku untuk sebagian besar kasus.

Dan saya rasa kita sedang bersiap untuk melakukan perubahan tersebut dan kita semua sebagai komunitas perlu memastikan bahwa sistem kita siap untuk itu, karena perubahan itu akan segera hadir.

Tidak ada cara lain.

Bagian atas funnel sangat luas dengan berbagai platform yang memungkinkan Anda membuat lebih banyak PR.

Dan Anda secepat langkah paling lambat dalam proses Anda.

Bagi banyak tim, hal itu adalah peninjauan kode, dan tim yang bergerak lebih cepat telah memahami dan menerima kenyataan ini.

Ya, dan jika kita jujur pada diri sendiri, saya ingin mengatakan 70% PR yang saya lihat tampak bagus bagi saya.

Misalnya, jika kita menelusuri semua code base di dunia, komentar PR hanya akan berupa, "looks good to me", LGTM, di mana-mana.

Jadi, sebagai tenaga profesional engineering, terkadang kita terlalu membanggakan diri.

Kami benar-benar merasa seperti berada di sana.

"Apakah mereka menggunakan pola perintah?"

Tidak, kami hanya berpikir, "Oke.

Ya, kelihatannya bagus."

Jadi, mengapa saya tidak bisa meminta agen melakukannya?

Saya benar-benar berpikir bahwa itulah masa depan yang akan kita lihat, seperti apa yang terlihat bagus bagi saya, seperti apa karakteristiknya, apa perilaku yang membuat Anda merasa seperti itu?

Lalu, pastikan agen mencari hal yang sama.

Atau sebaliknya, coba pikirkan juga berbagai cara untuk meninjau, bukan?

Misalnya, saya tahu orang-orang yang aktif di Twitter saat ini, mereka mengatakan hal ini, bukan?

Misalnya, saat Anda memverifikasi PR sekarang, minta agen Anda untuk memvisualisasikannya dengan cara yang berbeda, bukan?

Hei, tunjukkan foto sebelum.

Tunjukkan foto setelahnya.

Tunjukkan pengujian yang Anda tulis, bukan meninjau kode baris demi baris.

Tapi itu menantang Anda ingin mengatakan sesuatu, Luis?

Tidak, menurut saya ini adalah hal yang menggugah pikiran, bukan?

Dengan begitu, kita akan mencapai titik di mana Anda merasa sangat nyaman membiarkan CL, atau PR, diproses tanpa intervensi manusia.

Jadi, saya akan sedikit bersikap kritis, dan saya ingin mengatakan bahwa ketika kita berbicara tentang friksi, saya pikir ada kecenderungan untuk berpikir bahwa friksi itu buruk, tetapi ada friksi yang baik dan buruk.

Dan menurut saya, ulasan masih termasuk dalam kategori gesekan yang baik.

Ini adalah masalah bagaimana kita membuatnya tidak terlalu memberatkan bagi developer, bukan?

Terkadang, yang penting bukanlah bagaimana kita membuat peninjauan tersebut, pada saat itu, menjadi lebih baik atau lebih efisien.

Bagaimana Anda dapat membuat pengembangan upstream tersebut lebih tepat dengan AI, bukan?

Karena jika Anda hanya bergantung pada cara Anda menggunakan AI, seperti input yang baik menghasilkan output yang lebih baik, tetapi input yang buruk menghasilkan hasil yang sangat buruk, bukan?

Jadi, menurut saya, untuk mencapai hasil akhir yang menarik, harus ada peningkatan proses yang holistik dengan AI dari awal, menggunakan AI untuk lebih memahami arsitektur, memiliki spesifikasi yang benar-benar solid dengan, Anda tahu, lebih sedikit upaya dari developer, sehingga kode yang dihasilkan berkualitas lebih tinggi.

Oleh karena itu, peninjauan memiliki lebih sedikit hambatan bagi developer.

Menurut saya, hasil akhir dari hal ini yang tidak akan terlalu kontroversial adalah sebagian besar orang melihat bahwa semua kode ini pada akhirnya akan diterapkan tanpa peninjauan manual.

Sementara itu, kita berada dalam situasi yang terus berkembang, di mana model-model semakin baik, dan kita tidak terlalu khawatir tentang kesalahan teknis yang dibuatnya, melainkan lebih khawatir tentang kesalahan bisnis yang dibuatnya, atau penilaian atau ideasi yang masuk ke dalamnya yang menjadi masalah.

Jadi, hal itu juga menjadi sinyal bahwa Anda perlu memisahkannya selama tahap peninjauan.

Misalnya, apakah kita harus melakukan peninjauan baris demi baris dalam PR atau meninjau maksud yang, Anda tahu, ingin mereka dorong setelahnya?

Kami memikirkan hal ini mungkin dengan beberapa cara yang berbeda.

Salah satunya adalah bagaimana kami memberikan informasi yang lebih relevan kepada pengguna sehingga mereka dapat mulai memprioritaskannya?

Hal lainnya adalah apa saja area yang lebih aman tempat kita dapat bereksperimen dan bergerak lebih cepat dalam program semacam ini?

Seperti yang dikatakan Kaushik, tidak semua area memerlukan tingkat ketelitian yang sama.

Kita dapat mengidentifikasi hal ini dan mulai mempercepat beberapa proses, menurunkan risiko, sekaligus mempertahankan, Anda tahu, area yang lebih berorientasi pada kepatuhan atau, Anda tahu, sangat mendasar dengan friksi yang lebih tinggi hingga kita benar-benar mencapai titik di mana kita tidak hanya memercayai model, tetapi juga input yang masuk ke dalamnya

Adalah keputusan yang tepat.

Seperti melakukan refaktorisasi modul Android baru di aplikasi Uber, mungkin tidak masalah.

Memberikan tumpangan gratis kepada semua developer Android, mungkin ingin memeriksa kode tersebut.

Saya harus memeriksa hal itu dengan CEO kami.

Maaf, Kaushik.

Namun, menurut saya, masalah ini sudah terpecahkan.

Kita sudah memiliki tombol fitur.

Kita sudah memiliki blue-green deployment.

Kami sudah memiliki banyak komponennya.

Tantangannya adalah kami terlalu sibuk untuk benar-benar melakukannya.

Kami sudah memiliki pelacakan perilaku.

Kami memiliki semua jenis data ini, tetapi data tersebut berada di berbagai sistem yang berbeda.

Kami sudah melacak insiden.

Kami memiliki begitu banyak data, tetapi menyatukan semuanya menjadi satu trace yang komprehensif, itulah bagian yang hilang.

Setelah kita akhirnya mengetahui seperti apa layanan konteks rekayasa tersebut di semua perusahaan yang berbeda ini, kita tidak perlu khawatir lagi karena meskipun PR baru saja digabungkan, hal itu aman.

Karena kita tahu, oke, kita sudah menempatkannya di balik tombol fitur.

Kita memiliki blue-green deployment.

Kami memiliki semua kemampuan observasi yang diperlukan.

Lalu, Anda bisa merasa sangat percaya diri dengan hanya mengatakan, "Oh, masukkan ke dalam pipeline."

Jika terjadi hal buruk, kita memiliki semua penjaga dan gerbang ini di sepanjang jalan.

Menurut saya, kecepatan dalam merespons juga sangat penting, bukan?

Misalnya, kita ambil contoh Android. Jika Anda merilis perubahan di Android dan perubahan tersebut harus dikirim melalui Play Store, lalu diluncurkan ke konsumen, kemampuan Anda untuk segera melakukan hotfix akan sangat terhambat. Berbeda jika Anda melakukan sesuatu yang memiliki deployment internal dengan kemampuan observasi internal dan agen yang langsung menanganinya, Anda memiliki lebih banyak peluang untuk bergerak lebih cepat.

Jadi, salah satu pertanyaan saya untuk Anda adalah ada juga masalah bahwa ada pekerjaan yang perlu dilakukan pada aplikasi ini, tetapi kemudian Anda memiliki aplikasi greenfield yang lebih mudah, lalu Anda memiliki aplikasi brownfield, dan kemudian ada momen di mana Anda memerlukan waktu untuk melakukan banyak pemeriksaan ini, sehingga Anda dapat memperbanyak penggunaan AI.

Saya tahu banyak dari Anda yang mengerjakan aplikasi besar, bukan?

Jadi, saya ingin tahu bagaimana pendapat Anda tentang hal ini?

Apakah seperti, hei, CEO, beri saya waktu 3 bulan, biarkan saya menyiapkan aplikasi ini untuk AI, atau maksud saya, Anda tahu, seperti menambahkannya setiap hari?

Ya.

Mereka tidak pernah melakukannya.

Sepertinya bukan ini.

Maksud saya, sebagian besar perusahaan tidak akan pernah memiliki kemewahan itu.

Menurut saya, kita hanya perlu mendedikasikannya dengan cara yang sama seperti yang biasa kita lakukan, seperti utang teknis, di mana kita menggunakan 20% waktu untuk hal ini, seperti menggunakan 5% dari waktu tersebut untuk meningkatkan kualitas perintah.

Lalu, pahami fungsi perintah, dan buat konteksnya lebih baik.

Jadi, seperti yang telah kita bahas, menurut saya, banyak engineer yang masih belum memahami cara kerjanya.

Hal ini masih terasa sangat ajaib dan mistis, sehingga mereka tidak mengonfigurasi dan menyesuaikannya dengan cara yang dapat memberikan nilai dan efisiensi yang lebih baik.

Jadi, menurut saya harus ada titik di mana para pemimpin berkata, "Apa yang perlu kita lakukan untuk meningkatkan level tim kita agar mereka dapat memahami cara kerjanya, dan kemudian kita bisa mendapatkan lebih banyak?"

Ini juga merupakan kelanjutan dari hal tersebut.

Karena perubahan terjadi begitu cepat, jika saya meminta tim untuk menghabiskan waktu seminggu sekarang untuk mempelajari hal-hal terbaru dan terbaik, lalu mempraktikkannya, dan kemudian mereka tidak punya waktu untuk terus belajar atau bereksperimen, dan kami memeriksa tahun depan, mereka akan tertinggal jauh dari kemampuan baru yang ada.

Jadi, kita harus, Anda tahu, kita seperti membangun pesawat sambil menerbangkannya, di mana kita memasang pengaman, dan kita belajar, dan kita menyesuaikan seiring berjalannya waktu, dan tim harus terus mengikuti perkembangan ini.

Dan di organisasi besar, ada tim seperti beberapa tim kami yang mencoba menyaring beberapa informasi tersebut dan membuatnya, Anda tahu, sedikit lebih relevan dan mudah dipahami.

Namun, hal ini merupakan tantangan bagi semua orang di industri saat ini.

Saya ingin mencoba sesuatu yang berbeda.

Banyak dari Anda yang bekerja di bidang infrastruktur developer.

Ribuan PR, apakah infrastruktur pengujian, server, semuanya meleleh?

Dan saya ingin mendengar beberapa kisah perjuangan.

Ty?

Ya.

Mereka bersemangat sekali.

CI saya menangis untuk s- menangis tangisan saya membuat saya tertidur setiap malam.

Saat ini, hampir semua tim infrastruktur developer kami sedang berjuang mengatasi masalah penskalaan dalam komputasi dan masalah efisiensi.

Ada, Anda tahu, kode merah yang sedang berlangsung.

Mereka melihat peningkatan volume yang sangat besar ini.

Kami melakukan perubahan arsitektur dengan agen.

Kami mencoba melakukan hal-hal seperti memperluas eksekusi dan caching build jarak jauh kami secepat mungkin dengan Bazel, melihat hal-hal seperti, bagaimana semua main perlu selalu hijau, atau dapatkah kami mulai melakukan perbaikan ke depan dengan agen di area tertentu, melihat volume yang masuk dari engineer, mencoba melakukan hal-hal seperti CI yang dapat memperbaiki diri sendiri, atau seperti loop masukan yang lebih rendah, dan semua tim secara aktif berinvestasi dalam semua hal ini untuk mencoba mengimbangi pertumbuhan sambil mempertahankan tingkat efisiensi tertentu.

Namun, hal ini sangat menantang.

Ya, saya setuju dengan semua yang baru saja dikatakan Ty, tetapi menurut saya, hal ini juga memaksa kita untuk merenung dan dengan jujur mempertanyakan apakah kita siap jika kita harus meningkatkan skala 10 kali lipat dari titik ini dan seterusnya?

Dan bagi kebanyakan orang, jawabannya mungkin tidak.

Oleh karena itu, saat memikirkan masa depan, kami sengaja mencoba menyelaraskan ambisi kami dengan skala yang dapat didukung oleh infrastruktur.

Dan apa-- satu hal yang telah dilakukan AI adalah membuat kita semua lebih ambisius karena kita telah melihat lompatan yang berarti, jadi kita benar-benar memikirkan kembali sistem kita.

Benar, kami memikirkan sistem lain apa yang akan rusak, atau kami mengantisipasi apa yang akan rusak, dan apa yang dapat kami lakukan untuk mengatasinya agar tidak menjadi kejutan?

Dan pada kenyataannya, kita mencoba menghindari kejutan.

Benar, selama kita merasa memegang kendali, semua orang akan senang.

Saat kami menghadapi kejutan, saya tahu itu adalah kabar buruk bagi semua orang.

Iya, 'kan?

Jadi, ini adalah saat yang tepat untuk merenung dan melihat ke belakang, serta mengaudit, dan mencari tahu apa yang akan rusak berikutnya, karena hal itu akan terjadi.

Hal ini tidak dapat dihindari.

Kami hanya ingin mengantisipasinya.

Ada kutipan menarik yang saya dengar dari CEO Inflow.

Dia menjelaskan bahwa ini adalah linimasa yang dibutuhkan Google untuk mencapai, entah berapa, miliaran baris kode yang mereka miliki sekarang dan, Anda tahu, butuh waktu sekitar 20 tahun, dan dengan akselerasi ini, banyak perusahaan kita akan melihat skala yang serupa hanya dalam beberapa tahun, berdasarkan akselerasi AI.

Dan menurut saya, tidak semua perusahaan siap memiliki infrastruktur tingkat Google untuk pengembangan.

Nah, terkait topik itu, apakah perusahaan Anda menerapkan semacam batas pembelanjaan?

Misalnya, bagaimana Anda mengelola beberapa developer yang menggunakan token untuk semuanya, Anda tahu, menggunakan model terbaik yang memungkinkan setiap saat.

Misalnya, apakah ada strategi yang Anda temukan atau lebih baik membiarkan mereka bebas karena eksperimen akan memberikan hasil yang memuaskan?

Menurut saya, tahun lalu adalah tahun eksperimen.

Lakukan semua hal.

Dan mungkin bahkan paruh pertama tahun ini hanya menggunakannya secara wajar.

Dan sekarang, sejak September, kami memiliki batas token.

Jadi, kami sebenarnya memiliki batasan untuk developer terkait penggunaan token.

Lalu, kami memiliki instrumentasi, sehingga mereka dapat memahami, misalnya, apakah Anda memiliki sesi yang baik dan sehat?

Apa yang dimaksud dengan sesi yang sehat?

Apakah Anda memiliki giliran sebanyak ini per sesi?

Apa yang dimaksud dengan giliran?

Jadi, kami benar-benar mencoba menggunakan alat ini untuk mengedukasi developer.

Menurut saya, itu baru langkah pertama.

Anda tahu, Anda harus tahu bahwa Anda memiliki masalah sebelum dapat memperbaikinya.

Jadi, setidaknya mereka melihat bahwa ini tidak gratis.

Sebelumnya, AI benar-benar terasa seperti gratis.

Dan orang-orang menggunakannya.

Saya ingin, "Ubah cabang saya", seperti, "Oh, tidak masalah Annyce, saya akan mengubah cabang itu untuk Anda, $5", bukan?

Jadi, sekarang kita sampai pada tahap, "Oke, saya bisa langsung membuka command line dan melakukannya sendiri, kan?"

Jadi, menurut saya, kita akan mulai memberikan edukasi kepada engineer tentang biaya sebenarnya.

Lebih seperti saya tidak akan hanya menjalankan instance ECS dan mengabaikannya.

Mungkin saat AWS pertama kali diluncurkan, kita berpikir, "Ya, saya bisa menggunakan instance saya sendiri."

Dan kami seperti merugikan perusahaan begitu banyak uang.

Saya rasa hal yang sama sedang berlangsung sekarang dengan token.

Menurut saya, batasan praktis juga menghadirkan peluang yang sangat menarik, bukan?

Karena jika Anda memikirkan bagaimana, pada awalnya, kita mulai menggunakan LLM, kita akan memberikan semuanya, bukan?

Framework tersebut akan mengintrospeksi kode, mencari tahu berbagai hal, dan melakukan keajaiban untuk Anda, bukan?

Namun, hal itu memerlukan biaya.

Dan kami benar-benar-- Anda tahu, industri menyadari hal itu.

Hal ini sebenarnya memaksa developer dan organisasi untuk memikirkan cara mengoptimalkannya, bukan?

Misalnya, saya akan memberi Anda contoh konkret: Jika Anda memiliki generator yang menghasilkan komponen antarmuka pengguna, dan komponen tersebut harus mematuhi struktur tertentu, dan pengujian unit, dan hal-hal seperti itu, mengapa Anda meminta model membuatnya secara langsung, jika Anda sebenarnya dapat memintanya membuat alat deterministik yang dapat membuatkannya untuk Anda, bukan?

Jadi, ada banyak peluang untuk memanfaatkan batas token dan penggunaan, serta menjadi lebih efektif.

Ya, dan sejalan dengan tema tersebut, kami benar-benar telah menerapkan batasan, setidaknya seperti yang Anda ketahui, di Instacart.

Namun, menurut saya, tujuannya bukan untuk membatasi seberapa banyak Anda menggunakan AI, melainkan untuk menghadirkan semacam kebersihan, atau seperti yang Anda katakan, introspeksi, bukan?

Misalnya, kapan Anda sebaiknya menggunakan model tertentu dibandingkan model lainnya.

Anda tahu, Anda mungkin tidak memerlukan Fable atau Astra untuk memberi tahu Anda waktu atau mengubah cabang Git.

Iya, 'kan?

Anda mungkin dapat meluangkan waktu untuk menulis skrip dan skrip tersebut gratis selamanya.

Tidak ada token yang terbuang.

Iya, 'kan?

Jadi, menurut saya, jika Anda dapat menambahkan semacam batasan yang dimaksudkan bukan untuk membatasi penggunaan, tetapi lebih untuk membantu Anda berpikir lebih dari sekadar memasukkan semuanya.

Iya, 'kan?

Saya setuju dengan pendapat Anda, tahun lalu terasa seperti tahun eksperimen.

Tahun ini, pertanyaannya adalah, oke, bagaimana cara menggunakan teknologi ini secara efektif?

Ya.

Kami juga sangat memahami cerita di sini.

Terutama beralih dari lebih banyak eksperimen ke, Anda tahu, serangkaian efisiensi dan akuntabilitas yang seimbang.

Hal ini berasal dari berbagai investasi.

Ada hal-hal seperti edukasi untuk developer dan visibilitas.

Seperti yang dibahas Annyce, misalnya biaya dan informasi sesi aktif.

Investasi dalam setelan default yang aman, yang membantu menghindari interaksi yang sia-sia, memastikan bahwa keterampilan yang mereka gunakan efisien dalam mencari regresi dan hal-hal semacam itu.

Dan memberikan akuntabilitas atas biaya yang mereka keluarkan.

Jadi, kita memiliki batas token.

Dan saat developer mencapai batas tersebut, mereka dapat mengklik tombol dan memasukkan justifikasi, lalu manajer mereka dapat menyetujuinya.

Jadi, jika ada pekerjaan yang bagus, kami ingin mereka melakukannya.

Namun, jika mereka melakukan sesuatu yang lebih boros atau eksperimental, mereka tidak dapat memberikan alasan kepada manajer mereka mengapa mereka harus mengeluarkan uang untuk hal tersebut, sehingga hal ini membantu mereka untuk tetap mengontrolnya.

Hasilnya bukan hanya tidak melakukan pekerjaan, tetapi juga melihat dan berkata, apakah ini pilihan model yang tepat?

Apakah ini bobot yang tepat untuknya?

Anda tahu, tentu saja, biaya token ini mulai turun karena adanya tekanan persaingan.

Namun, secara umum, meminta engineer kami untuk memikirkannya sebagai pengelola yang baik atas uang yang kami berikan kepada mereka adalah, menurut saya, pendekatan yang tepat dan sehat saat ini.

Dan dalam jangka panjang, dapat menghapus keputusan tersebut sepenuhnya dari mereka.

Iya, 'kan?

Anda menginginkan perutean model otomatis dan hal-hal semacam itu, sehingga mereka tidak perlu memikirkannya.

Namun, untuk saat ini, status ini responsif.

Ya.

Saya rasa banyak fokus kami tertuju pada hal-hal seperti router model, sehingga kami mengambil keputusan tersebut dari developer dan mencoba memetakannya ke model yang tepat.

Namun, hal ini juga terkait dengan memiliki pemicu yang tepat.

Jadi, kami memikirkan batas token dalam beberapa cara.

Kami tidak pernah ingin memblokir developer.

Namun, kami ingin memastikan bahwa ada momen ketika kami dapat berhenti sejenak dan memastikan bahwa anggaran tersebut dibelanjakan di area yang tepat dan dengan cara yang tepat.

Jadi, ada batas harian sebagai contoh, murni sebagai pemicu yang dapat dibuka blokirnya oleh developer sendiri.

Mereka hanya perlu membuka portal, mengklik tombol, dan berkata, "Hei, saya tidak mengalami hal yang mengejutkan.

Saya memegang kendali."

Iya, 'kan?

Dan itu hanyalah satu tuas sederhana karena semua orang melakukan loop dan loop ini dapat berjalan semalaman dan kita tidak ingin hal ini meningkatkan biaya.

Jadi, hal ini sangat wajar.

Di sisi lain, kami juga ingin memastikan bahwa developer kami memiliki model terbaik yang tersedia.

Namun, untuk kategori model tersebut, kami telah membuat anggaran frontier.

Oleh karena itu, ada anggaran bulanan yang ditetapkan.

Sudah cukup tinggi.

Anda tidak diblokir.

Jika Anda perlu berhenti diblokir, ada proses pengecualian.

Dikirim ke pengelola Anda.

Ini adalah momen saat Anda menjelaskan tindakan yang sedang Anda lakukan.

Dan kami bukanlah pengambil keputusan sebagai tim platform, karena keputusan tersebut harus dekat dengan tempat pekerjaan dilakukan.

Dalam hal penggunaan model termutakhir, sekali lagi, kami memberi Anda fleksibilitas penuh dengan batas.

Alasan cara ini berhasil adalah karena pada akhirnya, cara ini memberikan prediktabilitas dalam prosesnya.

Iya, 'kan?

Kami ingin memastikan bahwa saat menganggarkan pengeluaran token, dan ini merupakan tantangan bagi semua orang, kami telah memperhitungkan apa yang kami rencanakan dan tuas ini memungkinkan kami melakukannya.

Anda tahu apa yang menurut saya menarik dalam percakapan ini?

Saya rasa itu karena kita semua bekerja di perusahaan.

Dan, perusahaan.

Jadi, kita harus membayar untuk setiap token.

Iya, 'kan?

Namun, ada sisi lain dari internet tempat orang-orang menggunakan harga langganan.

Jadi, bagi mereka, ini adalah kalkulus yang sangat berbeda.

Iya, 'kan?

Namun, saya rasa ini hanya masalah waktu sebelum semua orang berada dalam situasi yang sama, yaitu harus mulai memikirkan setiap token.

Dan saat itulah, Anda tahu, hal yang tidak diinginkan mungkin akan terjadi dalam hal menjadi sedikit lebih bertanggung jawab, seperti yang harus kita lakukan saat ini di perusahaan.

Atau Anda bekerja di lab terdepan dengan anggaran tak terbatas.

Lalu, Anda terus beroperasi dan menciptakan banyak cara kerja berbasis AI yang sangat menarik seperti yang ada di Twitter.

Semua perusahaan kami ingin menirunya, tetapi mereka tidak ingin menghabiskan token yang…

Kami memiliki orang-orang yang bekerja di Google di sini.

Saya sangat penasaran.

Bagaimana cara kerjanya?

Berapa anggaran dari Google?

Mau ambil, Luis?

Saya rasa saya bukan orang yang tepat untuk membahas aspek ekonominya.

Google adalah perusahaan yang sangat besar dengan banyak organisasi yang berbeda.

Tapi itu sebenarnya mengakhiri sesi kita dengan sempurna, karena kita tepat waktu.

Praktis sekali.

Saved by the bell.

Itulah moderasi yang luar biasa, teman-teman.

Orang-orang PR…

Jadi, terima kasih kepada panelis kita dan terima kasih telah hadir di ADS.