کدنویسی عامل‌گرا: میزگردی با رهبران صنعت

سلام به همه.

این هفته یا این دو روز گذشته، از بسیاری از کارمندان Android Google شنیده‌اید.

بنابراین، فکر کردیم خیلی خوب است که کنفرانس را با شنیدن نظرات برخی افراد از بیرون، از جامعه، از جامعه توسعه‌دهندگان Android به پایان برسانیم.

می‌خواهیم درباره کدنویسی عاملی و تأثیر آن در دنیای واقعی صحبت کنیم.

پس با معرفی خودمان شروع می‌کنیم.

نام من بن است، روابط توسعه‌دهندگان Android.

یک‌بار در این کنفرانس از من شنیده‌اید، اما بیایید به سراغ پانل برویم.

سلام دوستان.

من وینای هستم و از تلاش‌های ابزارسازی هوش مصنوعی در Databricks پشتیبانی می‌کنم.

از اینکه اینجا هستم هیجان‌زده‌ام.

سلام، من لوئیس آرتولا هستم.

من برای Google Maps کار می‌کنم.

من تیم‌هایی را رهبری می‌کنم که از هوش مصنوعی برای ساختن تجربه‌های عاملی و بهبود چرخه توسعه نرم‌افزار استفاده می‌کنند.

سلام، من آنیس دیویس هستم.

من در فورد کار می‌کنم.

من چند تیم مهندسی را رهبری می‌کنم که محصولات اشتراک و وفاداری ما را توسعه می‌دهند.

سلام دوستان.

من تای اسمیت هستم.

من در Uber هستم و از توسعه‌دهندگانمان پشتیبانی می‌کنم.

این برای مدت بسیار طولانی تلفن همراه بوده است.

در چند سال گذشته، تمرکز زیادی روی این دوره هیجان‌انگیز جدیدی که با ابزارهای هوش مصنوعی در آن هستیم وجود داشته است.

سلام دوستان.

من کاوشیک گوپال هستم.

من به‌عنوان مهندس ارشد در Instacart کار می‌کنم و اتفاقاً این پادکست را درباره توسعه Android به‌نام Fragmented شروع کردم.

این روزها، همان‌طور که تای گفت، ما استراتژی‌هایمان را کمی تغییر داده‌ایم و، می‌دانید، درباره توسعه هوش مصنوعی صحبت می‌کنیم.

بسیار خوب.

بنابراین، ۳۰ دقیقه وقت داریم.

فکر می‌کنم زمان به‌سرعت می‌گذرد، بنابراین مستقیماً به سراغ سؤالات سخت می‌رویم.

ما همیشه، می‌دانید، در Android DevRel، گفته‌ایم که می‌خواهیم ساخت برنامه‌ها را سریع‌تر و آسان‌تر کنیم.

اکنون هوش مصنوعی آمده است و، می‌دانید، شنیده‌اید که ما اینجا می‌گوییم، «واقعاً همین‌طور است.

فکر می‌کنیم ساختن برنامه‌ها سریع‌تر و آسان‌تر شده است.»

اما می‌خواهم این سؤال را مطرح کنم: آیا واقعاً برنامه‌ها را سریع‌تر عرضه می‌کنیم، یا فقط انبوهی از کد تولید می‌کنیم که به جایی نمی‌رسد؟

بیا برویم، وینای.

بسیارخوب.

بله، همه داریم به هم نگاه می‌کنیم.

فوق‌العاده بود.

بنابراین، اگر فقط به اعداد خالص نگاه کنید، قطعاً می‌بینیم که خروجی ازنظر درخواست‌های ادغام، ازنظر خطوط کد، شاهد شتاب عظیمی بوده‌ایم و درنتیجه، وقتی نوبت به چیزهایی مانند محل ذخیره کد می‌رسد، با چالش‌های مقیاس‌بندی نیز مواجه می‌شویم، درست است؟

و بنابراین این شتاب بسیار واقعی است.

آنچه واضح نیست این است که چگونه بر نتایج تأثیر می‌گذارد، و فکر می‌کنم کل صنعت در تلاش است تا بفهمد سنجه مناسب برای نتایج چیست، چگونه بداند که چگونه بر نتیجه نهایی تأثیر می‌گذارد.

اما من قطعاً آن را در عمل می‌بینم.

فکر می‌کنم در شش ماه گذشته کدهای بیشتری نسبت‌به قبل ارسال کرده‌ایم، و بازهم این موضوع را مبهم نگه می‌دارم، اما مثل یک دوره زمانی بسیار طولانی است.

و درنتیجه، فکر می‌کنم استراتژی ما درباره نحوه اندازه‌گیری بهره‌وری هم تغییر کرده است، درست است؟

چون روش‌های مختلفی برای فکر کردن درباره آن وجود دارد.

ما در تلاشیم تا بفهمیم چگونه میانه را افزایش دهیم، درست است؟

چون وقتی به داده‌های پرت و میانه نگاه می‌کنید، بین این دو دسته از افراد تفاوت ۵ تا ۱۰ برابری وجود دارد، و تمرکز ما بر این است که سطح را بالا ببریم، میانه را بالا ببریم، و این افراد را به‌اندازه همتایان اطرافشان که می‌بینیم بهره‌ور هستند، بهره‌ور کنیم.

ترکیبی از نقش‌ها را می‌بینیم.

برخی افراد خیلی خیلی سریع‌تر حرکت می‌کنند.

افرادی هستند که روزانه صد درخواست بازبینی دارند و کارهای فوق‌العاده‌ای انجام می‌دهند.

اما این نوع فضایی است که آن‌ها در آن فعالیت می‌کنند.

شاید این موضوع بیشتر به این دلیل باشد که آن‌ها در این زمینه تازه‌کار هستند یا اینکه با ابزارها آشنایی بیشتری دارند.

همچنین افرادی را می‌بینیم که بیشتر در زمینه توسعه زیرساخت‌های موجود یا کار پلاتفرم فعالیت می‌کنند و از نوع دیگری از کار پشتیبانی می‌کنند که شاید سرعت کمتری داشته باشد، زیرا باید زمان بیشتری را صرف قضاوت انسانی کنند و مطمئن شوند که مشکلی پیش نمی‌آید.

و ترکیب این دو، می‌دانید، به‌طور قابل‌توجهی سریع‌تر از قبل است، اما فکر می‌کنم موضوع واقعاً جالب برای ما این است که حتی اگر ما بیشتر ارسال می‌کنیم، آیا کسب‌وکار واقعاً بیشتر به کاربران نهایی ارسال می‌کند؟

این حوزه‌ای است که در سال گذشته روی آن سرمایه‌گذاری کرده‌ایم تا واقعاً بفهمیم آیا ویژگی‌ها را سریع‌تر عرضه می‌کنیم، نه فقط کدها را؟

نشانه‌های اولیه می‌گویند که ما هستیم، اما این نگاه بسیار متفاوتی نسبت‌به PRهای خالص بوده است.

I think like the like what's happened is, very clearly, people are shipping far like, you know, the number of PRs, the counts have like, you know, increased.

اما فکر می‌کنم حتی درحال‌حاضر هم بسیاری از افراد فکر می‌کنند: «چگونه می‌توانیم از هوش مصنوعی و این ابزاری که داریم استفاده کنیم و فرایندهای موجود را تقویت کنیم؟»

درست است؟

مثلاً، بخش زیادی از نحوه ارسال کد در گذشته به‌گونه‌ای بود که انگار همیشه فکر می‌کردیم انسان کسی است که این فرایند را تا مرحله تولید هدایت می‌کند.

اما فکر می‌کنم چیزی که الان می‌بینیم این است که، بله، این کار جواب می‌دهد.

محصولات بیشتری ارسال می‌کنیم.

اما ما با هر گلوگاهی مواجه می‌شویم که در غیر این صورت در دنیای قبلی نمی‌دیدید، درست است؟

چون ما هرگز در گذشته با این مشکلات مواجه نشده بودیم، اما اکنون، مثلاً، ما درحال تقویت یک بخش از، مثلاً، یک چرخه چندمرحله‌ای هستیم، و فکر می‌کنم اینجاست که جالب می‌شود، که مثلاً، «بسیارخوب.

ما جلوه‌های بیشتری ارائه می‌دهیم، اما اکنون این جلوه‌ها مثل شلنگ آتش‌نشانی هستند.»

بنابراین، با چالش‌های دیگری مواجه هستیم.

نکته بسیار جالبی است، درست است، چون وقتی به آن فکر می‌کنید، مراحل مختلفی وجود دارد، اما از دیدگاه سطح بالا، می‌توانید آن‌ها را در سه مرحله دسته‌بندی کنید، درست است؟

کدنویسی وجود دارد که به‌وضوح درحال تسریع است.

سطح آمادگی تولید وجود دارد که شامل تعدادی چیز مانند مسائل حقوقی و حریم خصوصی و چیزهایی است که به شما امکان می‌دهد چیزی را از در خارج کنید، و سپس راه‌اندازی وجود دارد، درست است؟

و بعد، ارسال واقعاً بسته به جایی که هستید معانی مختلفی دارد، درست است؟

اگر محصول شما کاملاً سمت سرور باشد، احتمالاً عرضه به‌معنای فرایندی ساده‌تر است، درحالی‌که وقتی چیزی را عرضه می‌کنید که به دست مصرف‌کننده می‌رسد، درست است، مثلاً قرار دادن آن در مرحله آزمایش درست مثل وسط یک سفر است، درست است؟

هنوز باید آزمایش و اندازه‌گیری زیادی انجام دهید، و اینجاست که به آنچه می‌گفتید مرتبط می‌شود، یعنی احساس می‌کنید در یک منطقه شهری، در یک بزرگراه هستید، و یک نقطه گلوگاه دارید، و سپس شروع به شتاب گرفتن می‌کنید و می‌گویید: «بله، عالی است.

خیلی سریع پیش می‌روم،» اما حالا به نقطه گلوگاه بعدی می‌رسید.

و چیزی که هوش مصنوعی به‌وضوح نشان می‌دهد این است که شما نقاط اصطکاک را واضح‌تر می‌بینید، و برخی‌از آن‌ها هیچ ارتباطی با کدنویسی یا فناوری ندارند.

این موضوع به فرایندها و انسان‌ها مربوط می‌شود و اینکه چگونه می‌توانید آن را با هوش مصنوعی بهینه‌سازی کنید.

این چالش واقعاً جالبی است که چگونه می‌توانیم فرایند سرتاسری را ساده‌سازی کنیم.

یک روش جالب که ما کمی درباره آن فضا فکر می‌کنیم این است که فرد یا تیم چقدر اختیار دارد تا آن را به‌طور کامل ارسال کند؟

بنابراین، اگر به درون نگاه کنیم، می‌دانید، تیم‌های زیادی هستند که شاید ابزارهای داخلی می‌سازند، یا چیزهایی که به مشتری ارسال نمی‌شوند.

خیلی سریع‌تر ارسال می‌شوند، درست است؟

آن‌ها اختیار کامل دارند که آن را فوراً به مشتریان خود ارائه دهند.

اگر محصولی خارجی دارید که هنوز باید آزمایش با کاربر را پشت سر بگذارد، یا مثلاً زمان عرضه در فروشگاه برنامه، یا مثلاً کار با طراحی و محصول، همه این گلوگاه‌های دیگر اضافه می‌شوند و افرادی که کد را می‌نویسند، اختیار بسیار کمتری برای حرکت سریع در این زمینه دارند.

و بنابراین، آن‌ها فقط به بقیه گلوگاه‌های سیستم برخورد می‌کنند.

بنابراین، فکر می‌کنم تقسیم آن‌ها به دو حوزه مختلف واقعاً نشان می‌دهد که فرایندهای کسب‌وکارتان در کجا می‌تواند بهبود یابد.

بله، موافقم، و صادقانه احساس می‌کنم که مهندسی هرگز گلوگاه نبوده است.

سال‌ها است که این را می‌گویم.

مهندسی روش بسیار دقیقی برای انجام کارها دارد و همیشه از کسب‌وکار می‌پرسد: «مشکل چیست؟»

۱۰ پاسخ متفاوت برای آن دریافت می‌کنید.

و سپس، «بسیار خوب.

اکنون، بیایید آن را به نوعی به برخی راه‌حل‌ها با محصول ترجمه کنیم.

حالا بیایید کمی درباره آن فکر کنیم.

اوه، شاید بهتر باشد کمی درباره طراحی صحبت کنیم.

شوتش کن آنجا.»

وقتی به مهندسی می‌رسد، کم‌وبیش می‌دانیم که چه کاری باید انجام دهیم.

و بعد، فقط سعی می‌کنیم به Stack Overflow برویم، و چیزهایی را کپی-پیست کنیم، و آن چیز را به بیرون بفرستیم.

بنابراین، با هوش مصنوعی، جایی که من بیشترین سرعت را می‌بینم، فقط در اطراف آن کار انطباق است.

Those things where we've always wanted to modernize XYZ, or we've always wanted to like quickly upgrade the Spring Boot version.

ما این کار را خیلی سریع انجام می‌دهیم.

اما درباره ارائه واقعی ویژگی، نمی‌توانم بگویم که واقعاً شاهد بهبود قابل‌توجهی بوده‌ام.

بنابراین، همه شما به نوعی به این موضوع اشاره کردید که شاید گلوگاه جابه‌جا شده باشد و با این فرایندهایی مواجه می‌شوید که قبلاً واقعاً گلوگاه نبودند، اما اکنون گلوگاه هستند.

به‌جز اینکه این فرایندها احتمالاً از درس‌های سختی که در گذشته گرفته شده‌اند به‌دست آمده‌اند، درست است؟

بنابراین، آیا برای تغییر این موارد تحت فشار هستید، و فکر می‌کنم واضح‌ترین مورد بازبینی کد است.

به‌نظر ما آینده بازبینی کد چیست؟

درحال‌حاضر چه کاری انجام می‌دهیم؟

بله، دوست دارم بشنوم.

می‌دانید، این به همان نکته‌ای برمی‌گردد که گفتم.

فکر می‌کنم بسیاری از این گلوگاه‌ها به این دلیل است که ما فکر می‌کردیم مثلاً اگر یک چوب جادویی داشتید، به اصطلاح، و می‌توانستید مهندسی نرم‌افزار را دوباره اختراع کنید، و امروز هوش مصنوعی داشتید، درست است، آیا از بسیاری از همان چیزها استفاده می‌کردیم؟ آیا همان کارها را انجام می‌دادیم؟

مثلاً بازبینی کد به این دلیل بود که به یک انسان نیاز داشتیم تا چیزها را تأیید کند، مثلاً آن بررسی نهایی را انجام دهد.

فکر می‌کنم این هم درحال تغییر است، مثلاً، می‌دانید، روشی که اکنون درباره بازبینی کد فکر می‌کنیم این است که شاید باید از این ایده استقبال کنیم که، می‌دانید، اگر دارید نام را بازسازی می‌کنید، یا می‌خواهید کد را بازسازی کنید، و می‌دانید که آزمایش‌های عالی دارید، که مشخصاً همه دارند.

از هوش مصنوعی خواستیم آن‌ها را بنویسد، مشکلی ندارد.

نه، مثلاً شاید، می‌دانید، آیا شما کارتان را خیلی بهتر از آن نماینده انجام می‌دهید؟

نمی‌دانم، مثلاً شاید بهتر باشد وقتتان را برای مرور آن صرف نکنید.

ازطرف دیگر، اگر قرار است اشکالی را ارسال کنید و، می‌دانید، تماسی از مدیرعامل اجرایی‌تان دریافت می‌کنید که اساساً می‌گوید: «هی، این چیز برای ما X دلار هزینه دارد»، شاید بخش‌ها و سیستم‌هایی را شناسایی کنید که مثلاً «هی، این یک بخش حیاتی است.

این منطقه بحرانی نیست» و سپس دوباره بازآفرینی کنید.

مثلاً فکر نمی‌کنم امروز این‌طور عمل کنیم، درست است؟

امروز، مثل این است که «سلام، یک PR وجود دارد.

من مهندس هستم.

من روی این چیز تمرکز کرده‌ام.

قرار است بالا برود.

من از وینای می‌خواهم که مثلاً در نیمه‌شب کد را بازبینی کند، چون فقط می‌خواهم این چیز ادغام شود.»

درمقابل، شاید باید درباره خیلی از آن‌ها تجدیدنظر کنیم.

من کاملاً موافقم و بازبینی کد را به‌عنوان یک مسئله درستی‌سنجی می‌بینم. منظورم این است که در دنیایی که من به توانایی خودم برای درستی‌سنجی چیزی اطمینان کامل دارم، آیا همچنان ۱۰۰٪ درخواست‌های ادغامم را بازبینی کد می‌کنم؟

احتمالاً نه، درست است؟

بنابراین، بازبینی کد دو هدف را دنبال می‌کند.

یکی از آن‌ها قطعاً تأیید این است که ما کار درست را انجام می‌دهیم، و دومی آموزش است، درست است؟

مثلاً اینکه اطرافیانتان بدانند چه می‌کنید و با تصمیمتان موافق باشند یا نه.

بنابراین قطعاً دسته‌ای از کارها وجود دارد که باید در تسریع آن‌ها احساس راحتی کنیم و مطمئن شویم که به کد و حتی نسخه‌های انتشار راه پیدا می‌کنند.

اکنون، این ممکن است برای ۱۰۰٪ موارد اعمال نشود، اما فکر می‌کنم این عدد بسیار بالا و دو رقمی است که باید اعمال شود.

و فکر می‌کنم ما داریم برای ایجاد این تغییرات آماده می‌شویم و همه ما به‌عنوان یک جامعه باید مطمئن شویم که سیستم‌هایمان برای آن آماده هستند، چون این تغییرات در راه است.

راهی برای دور زدن آن وجود ندارد.

بالای قیف با سطوح مختلف بسیار گسترده است و به شما امکان می‌دهد درخواست‌های بازبینی بیشتری ایجاد کنید.

و سرعت شما به‌اندازه کندترین مرحله فرایندتان است.

و برای بسیاری از تیم‌ها، این بازبینی کد است، و تیم‌هایی که سریع‌تر حرکت می‌کنند، صادقانه این واقعیت را درک کرده و پذیرفته‌اند.

بله، و اگر با خودمان صادق باشیم، می‌خواهم بگویم ۷۰٪ از درخواست‌های ادغام که دیده‌ام به‌نظرم خوب می‌آیند.

مثلاً اگر همه پایگاه‌های کد دنیا را جستجو کنیم، نظرات PR فقط «به‌نظر من خوب است»، LGTM، در سراسر هیئت خواهد بود.

بنابراین، بخشی از آن این است که به‌عنوان متخصصان مهندسی، گاهی‌اوقات ما بیش‌از آنچه شایسته آن هستیم به خودمان اعتبار می‌دهیم.

واقعاً فکر می‌کنیم که ما هم در آنجا هستیم.

«آیا از الگوی فرمان استفاده کردند؟»

نه، ما فقط می‌گوییم: «بسیارخوب.

بله، به‌نظر من خوب است.»

پس چرا نمی‌توانم از یک عامل بخواهم این کار را انجام دهد؟

I really think like that's the future that we're going to see where like what is the looks good to me, like kind of what is the characteristics, what are the behaviors that made you feel that way?

و سپس بیایید مطمئن شویم که عامل هم به‌دنبال همان چیز می‌گردد.

یا مثلاً از طرف دیگر، سعی کنید به روش‌های مختلف مرور هم فکر کنید، درست است؟

مثلاً من افرادی را می‌شناسم که این روزها در توییتر هستند و این را می‌گویند، درست است؟

مثلاً وقتی‌که اکنون یک PR را تأیید می‌کنید، از نمایندگان خود بخواهید آن را به روشی متفاوت تجسم کنند، درست است؟

سلام، قبل‌از آن را به من نشان بده.

یک عکس بعداز خدمات به من نشان بده.

آزمایش‌هایی را که نوشته‌ای به‌جای مرور کد به‌صورت خط‌به‌خط به من نشان بده.

ولی این چالش را ایجاد می‌کند که می‌خواستی چیزی بگویی، لوئیس؟

نه، فکر می‌کنم این موضوع تأمل‌برانگیز است، درست است؟

مثلاً اینکه به جایی برسیم که شما واقعاً احساس راحتی کنید که CLها یا PRها بدون دخالت انسان انجام شوند.

بنابراین، من می‌خواهم کمی نقش مخالف را بازی کنم و بگویم که وقتی درباره اصطکاک صحبت می‌کنیم، فکر می‌کنم تمایلی وجود دارد که فکر کنیم اصطکاک بد است، اما اصطکاک خوب و بد وجود دارد.

و فکر می‌کنم که احساس می‌کنم مرورها هنوز در دسته اصطکاک خوب قرار دارند.

مسئله این است که چگونه آن را برای توسعه‌دهندگان کمتر دشوار کنیم، درست است؟

و گاهی اوقات مسئله این نیست که چطور آن بازبینی را در آن زمان بهتر یا کارآمدتر کنیم؟

اینکه چگونه می‌توانید با هوش مصنوعی توسعه بالادستی را دقیق‌تر کنید، درست است؟

چون اگر فقط بسته به اینکه چطور از هوش مصنوعی استفاده می‌کنید، مثلاً ورودی‌های خوب خروجی‌های بهتری تولید می‌کنند، اما ورودی‌های بد واقعاً خروجی‌های بی‌کیفیتی تولید می‌کنند، درست است؟

بنابراین، فکر می‌کنم برای رسیدن به آن وضعیت نهایی جذاب، باید یک بهبود جامع در فرایند با هوش مصنوعی از همان ابتدا وجود داشته باشد، یعنی استفاده از هوش مصنوعی برای درک بهتر معماری، داشتن مشخصات واقعاً محکم با تلاش کمتر ازسوی توسعه‌دهندگان، تا کدی که تولید می‌کند کیفیت بالاتری داشته باشد.

و بنابراین، مرورها اصطکاک کمتری برای توسعه‌دهندگان دارند.

فکر می‌کنم وضعیت نهایی این موضوع که چندان بحث‌برانگیز نخواهد بود این است که اکثر افراد می‌بینند که همه این کدها درنهایت بدون بازبینی انسانی وارد می‌شوند.

فکر می‌کنم در این میان، ما در این وضعیت درحال تکامل هستیم که مدل‌ها بهتر می‌شوند و کمتر نگران اشتباه فنی آن‌ها هستیم و بیشتر نگران اشتباه تجاری آن‌ها هستیم یا اینکه مشکل از قضاوت یا ایده‌پردازی‌ای بوده که در آن دخیل بوده است.

و بنابراین، این نیز به سیگنالی می‌رود که می‌خواهید آن را در مرحله بررسی جدا کنید.

مثلاً آیا باید در PR بررسی خط‌به‌خط انجام دهیم یا اینکه هدف آن‌ها را بررسی کنیم که، می‌دانید، بعداً می‌خواهند اعمال کنند؟

ما به این موضوع شاید به چند روش مختلف فکر می‌کنیم.

یکی از آن‌ها این است که چگونه اطلاعات مرتبط‌تری به کاربر ارائه دهیم تا بتواند اولویت‌بندی را شروع کند؟

مورد دیگر این است که آن مناطق امن‌تر که می‌توانیم در آن‌ها آزمایش کنیم و در این نوع برنامه‌ها سریع‌تر حرکت کنیم کدامند؟

همان‌طور که کاوشیک می‌گفت، همه حوزه‌ها به یک اندازه سخت‌گیری نیاز ندارند.

ما می‌توانیم این را شناسایی کنیم و می‌توانیم شروع کنیم به اینکه برخی را سریع‌تر رها کنیم، ریسک را کاهش دهیم درحالی‌که، می‌دانید، حوزه‌هایی را که بیشتر مبتنی بر رعایت مقررات هستند یا، می‌دانید، بسیار بنیادی هستند با اصطکاک بالاتر حفظ کنیم تا زمانی که واقعاً به آن نقطه برسیم که نه فقط به مدل‌ها، بلکه به ورودی‌هایی که به آن‌ها وارد می‌شوند اعتماد کنیم

تصمیمات درستی بودند.

مثلاً بازسازی کد واحد جدید Android در برنامه Uber، شاید خوب باشد.

به همه توسعه‌دهندگان Android سواری رایگان می‌دهیم، احتمالاً می‌خواهید آن کد را بررسی کنید.

باید این مورد را با مدیرعامل اجرایی‌مان بررسی کنم.

متأسفم، کاوشیک.

اما فکر می‌کنم این مشکل حل شده است.

درحال‌حاضر پرچم‌های ویژگی مشابهی داریم.

ما ازقبل استقرار آبی-سبز داریم.

ما درحال‌حاضر بسیاری از قطعات را داریم.

چالش این است که ما خیلی مشغول بوده‌ایم و نتوانسته‌ایم واقعاً این کار را انجام دهیم.

درحال‌حاضر ردیابی رفتاری داریم.

ما همه این نوع داده‌ها را داریم، اما آن‌ها در همه این سیستم‌های مختلف هستند.

ما ازقبل حوادث را ردیابی می‌کنیم.

ما داده‌های بسیار زیادی داریم، اما کنار هم قرار دادن همه آن‌ها در یک ردیابی جامع، همان قطعه‌ای است که وجود ندارد.

وقتی بالاخره متوجه شدیم که این نوع سرویس زمینه مهندسی در همه این شرکت‌های مختلف چگونه است، دیگر لازم نیست نگران باشیم زیرا حتی اگر PR فقط ادغام شود، ایمن است.

چون می‌دانیم، بله، آن را پشت پرچم ویژگی داریم.

ما استقرار آبی-سبز داریم.

همه قابلیت‌های مشاهده‌پذیری را دراختیار داریم.

و بعد می‌توانید با اعتمادبه‌نفس کامل بگویید: «اوه، آن را در خط لوله قرار دهید.»

اگر اتفاق بدی بیفتد، ما همه این محافظ‌ها و دروازه‌ها را در طول مسیر داریم.

فکر می‌کنم سرعت پاسخ‌دهی هم خیلی مهم است، درست است؟

اگر بدانید، بیایید برای یک دقیقه Android را انتخاب کنیم، اگر تغییری در Android ایجاد می‌کنید و این تغییر باید ازطریق فروشگاه Play ارسال شود و سپس برای مصرف‌کنندگان شما عرضه شود، توانایی شما برای رفع فوری آن واقعاً محدود می‌شود درمقایسه با زمانی که کاری انجام می‌دهید که استقرار داخلی با قابلیت مشاهده داخلی دارد و عاملی که بلافاصله روی آن است، فرصت‌های بسیار بیشتری برای حرکت سریع‌تر در آنجا دارید.

بنابراین، یکی از سؤالاتی که از شما داشتم این است که این مشکل هم وجود دارد که کارهایی باید روی این برنامه‌ها انجام شود، اما بعد این برنامه‌های گرین‌فیلد را دارید که آسان‌تر هستند، سپس این برنامه‌های براون‌فیلد را دارید، و بعد این لحظه وجود دارد که شما به زمان نیاز دارید تا بسیاری از این بررسی‌ها را انجام دهید، می‌دانید، تا بتوانید استفاده از هوش مصنوعی را گسترش دهید.

می‌دانم که خیلی از شما روی برنامه‌های بزرگ کار می‌کنید، درست است؟

خب، کنجکاوم بدانم نظرتان درباره آن چیست؟

Is it like, hey, CEO, give me like 3 months, let me just get this app AI-ready, or I mean, you know, like add it every single day?

آره.

به‌هرحال آن‌ها هرگز این کار را نمی‌کنند.

فکر نمی‌کنم.

منظورم این است که اکثر شرکت‌ها هرگز چنین فرصتی نخواهند داشت.

فکر می‌کنم باید همان‌طور که برای بدهی فنی وقت می‌گذاشتیم، برای این هم وقت بگذاریم، مثلاً ۲۰٪ از وقتمان را به این کار اختصاص دهیم، یا مثلاً ۵٪ از آن را برای بهبود پیام‌واره استفاده کنیم.

و سپس حتی درک کند که پیام‌واره چه کاری انجام می‌دهد و بافت را بهتر کند.

بنابراین، همان‌طور که درباره آن صحبت کردیم، فکر می‌کنم بخش زیادی از آن به این دلیل است که مهندسان هنوز نحوه عملکرد آن را درک نمی‌کنند.

هنوز هم بسیار جادویی و اسرارآمیز به‌نظر می‌رسد، بنابراین آن را به‌گونه‌ای پیکربندی و تنظیم نمی‌کنند که بتوانند بهترین ارزش و کارایی را از آن به‌دست آورند.

بنابراین، فکر می‌کنم باید نقطه‌ای وجود داشته باشد که رهبران بگویند: «چه کاری باید انجام دهیم تا تیممان را ارتقا دهیم تا بتوانند نحوه عملکرد این موضوع را درک کنند و سپس بتوانیم بیشتر به‌دست آوریم؟»

همچنین تداوم آن است.

چون این فناوری خیلی سریع درحال تغییر است، اگر مثلاً از تیمی بخواهم که یک هفته را صرف یادگیری جدیدترین و بهترین فناوری‌ها کند و آن‌ها را به‌کار گیرد، و بعداز آن دیگر وقتی برای ادامه یادگیری یا آزمایش نداشته باشد، و سال بعد به آن‌ها سر بزنیم، به‌طور قابل‌توجهی از قابلیت‌های جدید عقب خواهند ماند.

بنابراین، باید این همه ما باشیم، می‌دانید، ما به نوعی در حال ساختن هواپیما در حین پرواز هستیم، جایی که حفاظ‌ها را قرار می‌دهیم، و در حال یادگیری هستیم، و در حال تنظیم کردن هستیم، و تیم‌ها باید در جریان این موضوع باشند.

و در سازمان‌های بزرگ، تیم‌هایی مانند برخی از تیم‌های ما وجود دارند که سعی می‌کنند برخی از این اطلاعات را تقطیر کنند و آن را، می‌دانید، کمی مرتبط‌تر و قابل هضم‌تر کنند.

اما درحال‌حاضر این چالشی برای همه افراد در این صنعت است.

دوست دارم کمی تنوع بدهم.

شما بسیاری از شما در زیرساخت توسعه‌دهنده کار می‌کنید.

هزاران درخواست ادغام، آیا زیرساخت آزمایشی شما، سرورهای شما، همه درحال ذوب شدن هستند؟

و دوست دارم چند داستان نبرد بشنوم.

تای؟

بله.

در اوج هستند.

کاشت حلزونی من هر شب با گریه من گریه می‌کند تا بخوابم.

درحال‌حاضر تقریباً همه تیم‌های زیرساخت توسعه‌دهنده ما با مشکلات مقیاس‌بندی در محاسبات و مشکلات کارایی دست‌وپنجه نرم می‌کنند.

می‌دانید، کدهای قرمز درحال اجرا هستند.

آن‌ها این افزایش حجم عظیم را می‌بینند.

درحال اعمال تغییرات معماری در «عامل‌ها» هستیم.

ما می‌دانید سعی می‌کنیم کارهایی مانند گسترش اجرای ساخت از راه دور و ذخیره‌سازی با Bazel را در سریع‌ترین زمان ممکن انجام دهیم، به چیزهایی مانند اینکه چگونه همه اصلی‌ها باید همیشه سبز باشند، یا می‌توانیم با نمایندگان در مناطق خاصی شروع به اصلاح کنیم، به حجم ورودی از مهندسان نگاه کنیم، سعی کنیم کارهایی مانند CI خودبهبودی یا حلقه‌های بازخورد پایین‌تر انجام دهیم، و همه تیم‌ها فقط به‌طور فعال در همه این‌ها سرمایه‌گذاری می‌کنند تا سعی کنند با رشد همگام شوند و درعین‌حال سطحی از کارایی را حفظ کنند.

اما این کار بسیار چالش‌برانگیز است.

بله، من با هر چیزی که تای گفت موافقم، اما فکر می‌کنم این موضوع ما را مجبور می‌کند که تأمل کنیم و صادقانه از خودمان بپرسیم که اگر قرار باشد از این نقطه به بعد ۱۰ برابر شویم، آیا آماده‌ایم؟

و برای اکثر افراد، پاسخ احتمالاً منفی است.

و درنتیجه، وقتی به آینده فکر می‌کنیم، عمداً تلاش می‌کنیم تا جاه‌طلبی خود را با مقیاسی که زیرساخت می‌تواند پشتیبانی کند مطابقت دهیم.

و چیزی که هوش مصنوعی انجام داده این است که همه ما را بلندپروازتر کرده است، زیرا قبلاً آن جهش معنادار را دیده‌ایم، بنابراین صادقانه درحال بازنگری سیستم‌هایمان هستیم.

درست است، ما به این فکر می‌کنیم که چه سیستم دیگری قرار است خراب شود، یا پیش‌بینی می‌کنیم که خراب شود، و چه کاری می‌توانیم انجام دهیم تا از آن پیشی بگیریم تا غافلگیر نشویم؟

و درواقع، ما سعی می‌کنیم از غافلگیری جلوگیری کنیم.

درست است، تا زمانی که احساس کنیم کنترل دست ما است، همه خوشحال هستند.

لحظه‌ای که با یک غافلگیری مواجه می‌شویم، می‌دانم که این خبر بدی برای همه است.

درست است؟

و بنابراین این زمان خوبی برای تأمل و نگاه به گذشته، و ممیزی، و فهمیدن این است که چه چیزی قرار است در آینده خراب شود، زیرا این اتفاق خواهد افتاد.

اجتناب‌ناپذیر است.

فقط می‌خواهیم از آن جلو بزنیم.

نقل‌قول جالبی از مدیرعامل Inflow شنیدم.

او توضیح می‌داد که این همان خط زمانی است که Google برای رسیدن به، هرچه که هست، میلیاردها خط کدی که اکنون دارد طی کرده است و، می‌دانید، حدود ۲۰ سال طول کشیده است، و با شتاب گرفتن این روند، بسیاری از شرکت‌های ما در عرض چند سال کوتاه، براساس شتاب هوش مصنوعی، به مقیاس مشابهی خواهند رسید.

و فکر نمی‌کنم همه شرکت‌ها آماده باشند که زیرساخت‌های سطح Google را برای توسعه داشته باشند.

خب، در این موضوع، آیا شرکت‌های شما نوعی حد هزینه‌کرد اعمال می‌کنند؟

مثلاً، چطور مدیریت می‌کنید که برخی‌از توسعه‌دهندگان فقط برای همه‌چیز توکن مصرف می‌کنند، می‌دانید، همیشه از بهترین مدل ممکن استفاده می‌کنند.

مثلاً، آیا استراتژی خاصی پیدا کرده‌اید یا بهتر است آن‌ها را آزاد بگذارید چون آزمایش کردن به نتایج شیرینی منجر می‌شود؟

به‌نظر من سال گذشته سال آزمایش بود.

همه کارها را انجام دهید.

و شاید حتی نیمه اول امسال فقط استفاده معقول از آن بود.

و اکنون، از سپتامبر، محدودیت‌های توکن داریم.

بنابراین ما درواقع محدودیت‌هایی برای توسعه‌دهندگان در استفاده از توکن داریم.

و سپس ابزارهایی داریم که می‌توانند بفهمند آیا جلسات خوب و سالمی دارید؟

جلسه سالم به چه معنا است؟

آیا در هر جلسه این تعداد نوبت دارید؟

نوبت چیست؟

بنابراین، ما واقعاً تلاش می‌کنیم تا از ابزارها برای آموزش توسعه‌دهندگان نیز استفاده کنیم.

فکر می‌کنم این فقط اولین قدم است.

می‌دانید، قبل‌از اینکه بتوانید مشکلی را برطرف کنید باید بدانید که مشکلی وجود دارد.

بنابراین، حداقل دیدن این‌ها رایگان نیست.

قبلاً واقعاً احساس می‌شد که هوش مصنوعی رایگان است.

و مردم فقط از آن استفاده می‌کردند.

من می‌خواهم، «شعبه من را تغییر دهید»، می‌دانید، مثلاً، «اوه، مشکلی نیست آنیس، من آن شعبه را برای شما تغییر می‌دهم، ۵ دلار»، درست است؟

بنابراین، مثل الآن، به جایی می‌رسیم که مثلاً «بسیارخوب، می‌توانم به خط فرمان بروم و خودم این کار را انجام دهم، درست است؟»

بنابراین فکر می‌کنم که ما واقعاً باید مهندسان را درباره هزینه واقعی آموزش دهیم.

بیشتر شبیه این است که من فقط نمونه‌های ECS را راه‌اندازی نمی‌کنم و بعد از آن‌ها فرار نمی‌کنم.

شاید وقتی AWS برای اولین‌بار عرضه شد، ما این‌طور بودیم که «بله، می‌توانم نمونه خودم را صرف کنم.»

و ما فقط داشتیم هزینه زیادی برای شرکت ایجاد می‌کردیم.

فکر می‌کنم همین اتفاق اکنون برای توکن‌ها درحال رخ دادن است.

فکر می‌کنم محدودیت‌های عملی فرصت‌های واقعاً جالبی را نیز ارائه می‌دهند، درست است؟

چون وقتی به این فکر می‌کنید که در ابتدا چگونه از مدل‌های زبانی بزرگ استفاده می‌کردیم، همه چیز را به آن‌ها می‌دادیم، درست است؟

آن‌ها کد را بررسی می‌کنند، چیزها را متوجه می‌شوند، و برای شما جادو می‌کنند، درست است؟

اما این کار هزینه‌ای داشت.

و ما واقعاً واقعی هستیم-- می‌دانید، صنعت دارد به این موضوع پی می‌برد.

و این درواقع توسعه‌دهندگان و سازمان‌ها را مجبور می‌کند به این فکر کنند که چگونه می‌توانند آن را بهینه‌سازی کنند، درست است؟

What Why is, say for instance, I'll give you a concrete example: If you have a generator that is producing user interface components, and they need to comply with a specific structure, and unit tests, and things like that, why would you have the models generate that on the fly, if you can actually have it generate a deterministic tool that they can just create that for you, right?

بنابراین، در همین‌جا، فرصت‌های زیادی برای استفاده از محدودیت‌های توکن‌ها و استفاده به نفع خودتان وجود دارد و درواقع می‌توانید مؤثرتر عمل کنید.

بله، و درراستای این موضوعات، ما قطعاً محدودیت‌هایی را معرفی کرده‌ایم، حداقل همان‌طور که می‌دانید، در Instacart.

اما فکر می‌کنم هدف لزوماً محدود کردن میزان استفاده از هوش مصنوعی نیست، بلکه ایجاد نوعی بهداشت یا همان‌طور که می‌گویید، درون‌نگری است، درست است؟

مثلاً اینکه چه زمانی احتمالاً باید از مدل‌های خاصی درمقابل مدل‌های دیگر استفاده کنید.

می‌دانید، احتمالاً برای اینکه زمان را بدانید یا شاخه Git را تغییر دهید، به Fable یا Astra نیاز ندارید.

درست است؟

احتمالاً می‌توانید، می‌دانید، کمی وقت بگذارید و یک اسکریپت بنویسید و برای همیشه رایگان است.

هیچ نشانه‌ای در آنجا هدر نرفته است.

درست است؟

بنابراین، فکر می‌کنم اگر بتوانید نوعی محدودیت اضافه کنید که هدفش لزوماً محدود کردن استفاده نباشد، بلکه بیشتر به شما کمک کند تا فراتر از اینکه فقط همه چیز را به آن بسپارید فکر کنید.

درست است؟

از حرفت خوشم آمد، سال گذشته مثل سال آزمایش بود.

امسال این‌طور به‌نظر می‌رسد که، خب، چطور به‌طور مؤثر از این چیز استفاده کنیم؟

آره.

داستان‌های اینجا هم برای ما بسیار آشنا است.

به‌ویژه از آزمایش بیشتر به، می‌دانید، مجموعه‌ای متعادل از کارایی و پاسخگویی.

این درآمد از سرمایه‌گذاری‌های مختلفی به‌دست می‌آید.

مواردی مثل آموزش برای توسعه‌دهندگان و رؤیت‌پذیری وجود دارد.

مثلاً همان‌طور که آنیس درباره هزینه و اطلاعات جلسه فعال صحبت می‌کرد.

سرمایه‌گذاری در پیش‌فرض‌های ایمن که به جلوگیری از تعاملات بیهوده کمک می‌کند، اطمینان از اینکه مهارت‌هایی که استفاده می‌کنند کارآمد هستند، و جستجوی پس‌رفت‌ها و مواردی از این دست.

و پاسخگویی درباره هزینه‌ای که صرف می‌کنند.

بنابراین، همان‌طور که می‌دانید، ما محدودیت‌های داده‌واحد داریم.

و وقتی توسعه‌دهنده به آن‌ها می‌رسد، می‌تواند با یک کلیک روی دکمه، توجیهی ارائه دهد و مدیرش می‌تواند آن را تأیید کند.

بنابراین اگر کار خوبی درحال انجام است، مثلاً می‌خواهیم آن‌ها آن را تجربه کنند.

اما، می‌دانید، اگر شاید کاری پرهزینه‌تر یا آزمایشی انجام دهند، نمی‌توانند برای مدیرشان توجیه کنند که چرا، می‌دانید، چرا باید برای آن پول خرج کنند، بنابراین به آن‌ها کمک می‌کند تا آن را نیز تحت کنترل داشته باشند.

و این منجر به این می‌شود که نه تنها کار انجام نشود، بلکه نگاه کنیم و بگوییم، آیا این انتخاب مدل درستی است؟

آیا این وزن برای آن مناسب است؟

می‌دانید، بدیهی است که هزینه این توکن‌ها با برخی‌از فشارهای رقابتی شروع به کاهش کرده است.

اما به‌طور کلی، اینکه مهندسان ما فقط به این فکر کنند که ناظران خوبی برای پولی که به آن‌ها می‌دهیم باشند، به‌نظرم رویکرد سالم و درستی درحال‌حاضر است.

و سپس در درازمدت، بتوانیم این تصمیم را به‌طور کامل از آن‌ها بگیریم.

درست است؟

شما مسیریابی خودکار مدل و چیزهایی از این قبیل را می‌خواهید، جایی که آن‌ها هرگز مجبور نباشند به آن فکر کنند.

اما در این میان، این وضعیت سالمی است.

آره.

فکر می‌کنم بخش زیادی از تمرکز ما روی انجام کارهایی مانند مسیریاب مدل بوده است تا این تصمیم را از توسعه‌دهنده بگیریم و سعی کنیم آن را به مدل مناسب نگاشت کنیم، یعنی وظیفه را به مدل نگاشت کنیم.

اما این موضوع به داشتن تله‌های مناسب نیز مربوط می‌شود.

بنابراین، ما محدودیت‌های توکن را از چند جهت درنظر می‌گیریم.

ما هرگز نمی‌خواهیم توسعه‌دهنده را مسدود کنیم.

اما می‌خواهیم مطمئن شویم که لحظاتی وجود دارد که می‌توانیم برای یک ثانیه مکث کنیم و مطمئن شویم که در زمینه‌های درست و به روش درست هزینه می‌شود.

بنابراین، برای مثال، محدودیت‌های روزانه‌ای وجود دارد که صرفاً به‌عنوان یک هشدار عمل می‌کنند و توسعه‌دهنده می‌تواند خودش آن‌ها را لغو کند.

تنها کاری که باید انجام دهند این است که به درگاه بروند، روی دکمه‌ای کلیک کنند و بگویند: «سلام، من هیچ اتفاق غافلگیرکننده‌ای نیفتاد.

من کنترل می‌کنم.»

درست است؟

و این فقط یک اهرم ساده است چون همه درحال تکرار هستند و این تکرارها می‌توانند درطول شب اجرا شوند و ما نمی‌خواهیم این امر باعث افزایش هزینه شود.

بنابراین، این بسیار منطقی است.

ازسوی‌دیگر، می‌خواهیم مطمئن شویم که توسعه‌دهندگان ما بهترین مدل‌های موجود را دراختیار دارند.

اما برای این دسته از مدل‌ها، بودجه‌ای برای مدل‌های پیشرو ایجاد کرده‌ایم.

بنابراین، بودجه ماهانه‌ای درنظر گرفته شده است.

به‌اندازه کافی بالا است.

مسدود نشده‌اید.

اگر لازم است رفع انسداد شوید، فرایند استثنایی وجود دارد.

به مدیرتان ارسال می‌شود.

لحظه‌ای است که کاری را که انجام می‌دهید توصیف می‌کنید.

و ما به‌عنوان تیم پلاتفرم تصمیم‌گیرنده نیستیم، زیرا این تصمیمات باید نزدیک به جایی که کار درحال انجام است گرفته شود.

ازنظر استفاده از مدل مرزشکن، بازهم انعطاف‌پذیری کامل با سقف مشخصی به شما می‌دهیم.

و دلیل اینکه این روش کار می‌کند این است که درنهایت این کار باعث پیش‌بینی‌پذیری در فرایند می‌شود.

درست است؟

می‌خواهیم مطمئن شویم که وقتی بودجه مصرف توکن را تعیین می‌کنیم، و این چالشی برای همه است، آنچه را برنامه‌ریزی کرده بودیم درنظر گرفته‌ایم و این اهرم‌ها به ما اجازه می‌دهند این کار را انجام دهیم.

می‌دانید چه چیزی در این مکالمه‌ها برای من جذاب است؟

فکر می‌کنم دلیلش این است که همه ما در شرکت‌ها کار می‌کنیم.

و بنابراین، شرکت‌ها.

بنابراین، باید برای هریک از این نشان‌ها هزینه پرداخت کنیم.

درست است؟

اما بخش دیگری از اینترنت وجود دارد که افراد در آنجا از قیمت‌گذاری اشتراکی استفاده می‌کنند.

بنابراین، برای آن‌ها این یک حساب کاملاً متفاوت است.

درست است؟

اما فکر می‌کنم می‌دانید که این مسئله زمان است تا همه در یک استخر قرار بگیرند و شما باید درباره هر توکن فکر کنید.

و آن زمانی است که، می‌دانید، احتمالاً اتفاق ناخوشایند دیگری ازنظر مسئولیت‌پذیری بیشتر رخ خواهد داد، مثل کاری که اکنون باید در شرکت‌ها انجام دهیم.

یا در آزمایشگاه پیشرفته‌ای کار می‌کنید که بودجه نامحدود دارید.

And then you just keep operating and you know creating a lot of these really exciting like AI native ways of working that are all over Twitter.

همه شرکت‌های ما می‌خواهند این را منعکس کنند، اما فکر نمی‌کنند که بخواهند توکن‌هایی را که…

افرادی را داریم که در Google کار می‌کنند.

خیلی کنجکاوم.

چگونه کار می‌کند؟

بودجه Google چقدر است؟

می‌خواهی تو بگیری، لوئیس؟

فکر نمی‌کنم من فرد مناسبی برای صحبت کردن درباره جنبه اقتصادی آن باشم.

‫Google شرکت بسیار بزرگی است که سازمان‌های مختلفی دارد.

اما این درواقع ما را کاملاً دربرمی‌گیرد، چون ما درست به‌موقع هستیم.

راحت بود.

Saved by the bell.

این یعنی تعدیل عالی، دوستان.

افراد روابط عمومی…

به‌هرحال، از هیئت داوران سپاس‌گزاریم و بله، از اینکه به ADS آمدید متشکریم.