การเขียนโค้ดแบบ Agent: การประชุมกับผู้นำในอุตสาหกรรม

สวัสดีทุกคน

คุณได้ยินจาก Googler ของ Android จำนวนมากในสัปดาห์นี้หรือในช่วง 2 วันที่ผ่านมา

เราจึงคิดว่าคงจะดีไม่น้อยหากปิดท้ายการประชุมด้วยการฟังความคิดเห็นจากบุคคลภายนอก จากชุมชน และจากชุมชนนักพัฒนาแอป Android

เราจะพูดถึงการเขียนโค้ดแบบ Agentic และผลกระทบที่เกิดขึ้นจริงในโลกแห่งความเป็นจริง

เราจะเริ่มด้วยการแนะนำตัวก่อน

ผมชื่อ Ben เป็น Android DevRel

คุณได้ฟังจากฉันไปแล้วครั้งหนึ่งในการประชุมนี้ แต่เรามาดูแผงกันดีกว่า

สวัสดีทุกคน

ฉันชื่อ Vinay และฉันสนับสนุนการทำงานของเครื่องมือ AI ที่ Databricks

ตื่นเต้นมากที่ได้มาที่นี่

สวัสดี ฉันชื่อ Luis Artola

ฉันทำงานให้กับ Google Maps

ฉันเป็นผู้นำทีมที่ใช้ AI เพื่อสร้างประสบการณ์การใช้งาน Agentic และปรับปรุงวงจรการพัฒนาซอฟต์แวร์

สวัสดี ฉันชื่อ Annyce Davis

ฉันทำงานที่ Ford

ฉันเป็นหัวหน้าทีมวิศวกรที่พัฒนาผลิตภัณฑ์การสมัครใช้บริการและผลิตภัณฑ์สะสมคะแนน

สวัสดีทุกคน

ฉันชื่อ Ty Smith

ฉันทำงานที่ Uber เพื่อสนับสนุนนักพัฒนาซอฟต์แวร์ของเรา

ซึ่งก็คืออุปกรณ์เคลื่อนที่มาเป็นเวลานานมากแล้ว

ในช่วง 2-3 ปีที่ผ่านมา เรามุ่งเน้นอย่างมากกับช่วงเวลาใหม่ที่น่าตื่นเต้นนี้ซึ่งเรามีเครื่องมือ AI

สวัสดีทุกคน

ผม Kaushik Gopal

ผมทำงานเป็นวิศวกรหลักที่ Instacart และได้เริ่มทำพอดแคสต์เกี่ยวกับการพัฒนา Android ที่ชื่อว่า Fragmented

ปัจจุบัน อย่างที่ Ty บอก เราได้เปลี่ยนกลยุทธ์เล็กน้อย และเราพูดถึงการพัฒนา AI

โอเค

เรามีเวลา 30 นาที

เราคิดว่าเวลาจะผ่านไปอย่างรวดเร็ว ดังนั้นเราจะเข้าสู่คำถามที่ตรงประเด็นทันที

เราพูดเสมอว่าใน Android DevRel เราต้องการทำให้การสร้างแอปเร็วขึ้นและง่ายขึ้น

ตอนนี้ AI ได้เข้ามามีบทบาท และคุณก็ได้ยินเราพูดไปแล้วว่า "ใช่เลย

เราคิดว่าการสร้างแอปจะรวดเร็วและง่ายขึ้น"

แต่ผมอยากจะตั้งคำถามว่า เรากำลังจัดส่งแอปได้เร็วขึ้นจริงๆ หรือเราแค่สร้างโค้ดจำนวนมากที่ไม่ได้นำไปใช้ประโยชน์อะไรเลย

เริ่มกันเลย Vinay

ตกลง

ใช่ เราทุกคนต่างมองหน้ากัน

ดีมาก

ดังนั้น หากดูแค่ตัวเลขล้วนๆ เราจะเห็นได้อย่างชัดเจนว่าผลลัพธ์ในแง่ของ PR และบรรทัดโค้ดมีการเร่งความเร็วอย่างมาก และด้วยเหตุนี้ เราจึงพบกับความท้าทายด้านการปรับขนาดเมื่อพูดถึงสิ่งต่างๆ เช่น สถานที่ที่เราจัดเก็บโค้ดใช่ไหม

ดังนั้นการเร่งความเร็วนี้จึงเกิดขึ้นจริง

แต่สิ่งที่ไม่ชัดเจนคือผลกระทบต่อผลลัพธ์ และฉันคิดว่าทั้งอุตสาหกรรมกำลังพยายามหาว่าเมตริกที่เหมาะสมสำหรับผลลัพธ์คืออะไร และจะทราบได้อย่างไรว่าผลกระทบต่อผลกำไรเป็นอย่างไร

แต่เราเห็นการใช้งานจริงอย่างแน่นอน

ผมคิดว่าเราได้จัดส่งโค้ดในช่วง 6 เดือนที่ผ่านมามากกว่าช่วงก่อนหน้า และผมจะขอไม่ระบุระยะเวลาที่แน่นอน แต่เป็นระยะเวลาที่ยาวนานมาก

และด้วยเหตุนี้ ฉันคิดว่ากลยุทธ์ของเราได้เปลี่ยนไปในเรื่องวิธีวัดประสิทธิภาพการทำงานด้วยใช่ไหม

เพราะมีหลายวิธีในการคิดเกี่ยวกับเรื่องนี้

เรากำลังพยายามหาวิธีเพิ่มค่ามัธยฐานใช่ไหม

เพราะเมื่อดูที่ค่าผิดปกติและค่ามัธยฐาน จะเห็นว่ามีเดลต้า 5-10 เท่าระหว่างคน 2 กลุ่มนี้ และเรามุ่งเน้นที่การยกระดับมาตรฐาน ยกระดับค่ามัธยฐาน และทำให้คนเหล่านั้นมีประสิทธิภาพการทำงานเท่ากับเพื่อนร่วมงานรอบตัวที่เห็นว่ามีประสิทธิภาพการทำงาน

เราเห็นบทบาทที่หลากหลาย

บางคนก็ก้าวหน้าเร็วกว่าคนอื่นมาก

มีคนที่ได้รับ PR 100 รายการต่อวันซึ่งกำลังทำงานที่น่าทึ่งอยู่

แต่ก็เป็นพื้นที่ประเภทหนึ่งที่พวกเขาทำงานอยู่

ซึ่งอาจเป็นเรื่องใหม่หรืออาจเป็นเรื่องที่พวกเขาคุ้นเคยกับเครื่องมืออยู่แล้ว

นอกจากนี้ เรายังเห็นผู้คนที่ทำงานในส่วนของ Brownfield หรือแพลตฟอร์มมากกว่า และพวกเขากำลังสนับสนุนงานประเภทอื่นที่อาจไม่ได้เร่งรีบมากนัก เนื่องจากต้องใช้เวลามากขึ้นในการตัดสินใจโดยมนุษย์และตรวจสอบว่าสิ่งต่างๆ จะไม่เกิดความเสียหาย

และการรวม 2 สิ่งนี้เข้าด้วยกันทำให้คุณรู้ว่ามันเร็วกว่าเมื่อก่อนมาก แต่ฉันคิดว่าหัวข้อที่น่าสนใจจริงๆ สำหรับเราคือ แม้ว่าเราจะจัดส่งมากขึ้น แต่ธุรกิจจัดส่งไปยังผู้ใช้ปลายทางมากขึ้นจริงหรือไม่

นั่นเป็นส่วนที่เราลงทุนในช่วงปีที่ผ่านมาเพื่อทำความเข้าใจอย่างถ่องแท้ว่าเรากำลังจัดส่งฟีเจอร์ได้เร็วขึ้นหรือไม่ ไม่ใช่แค่จัดส่งโค้ดได้เร็วขึ้น

สัญญาณแรกเริ่มบอกว่าเราทำได้ แต่ก็มีลักษณะที่แตกต่างจาก PR ล้วนๆ มาก

ผมคิดว่าสิ่งที่เกิดขึ้นคือผู้คนกำลังส่งมอบโค้ดกันมากขึ้นอย่างเห็นได้ชัด เช่น จำนวน PR ที่เพิ่มขึ้น

แต่ผมคิดว่าแม้แต่ตอนนี้ หลายคนก็ยังคิดว่า "เราจะนำ AI และเครื่องมือที่เรามีมาใช้เพื่อเพิ่มประสิทธิภาพให้กับกระบวนการที่มีอยู่ได้อย่างไร"

ถูกต้องไหม

เช่น วิธีที่เราเคยจัดส่งโค้ดก่อนหน้านี้ทำให้รู้สึกว่าเราคิดเสมอว่ามนุษย์เป็นเหมือนคนที่คอยดูแลโค้ดนี้ไปจนถึงขั้นตอนการผลิต

แต่เราคิดว่าสิ่งที่เห็นในตอนนี้คือวิธีนี้ได้ผล

เรากำลังจัดส่งเพิ่มเติม

แต่เรากำลังเผชิญกับคอขวดทุกอย่างที่คุณอาจไม่เคยเห็นมาก่อนในโลกยุคก่อนหน้า จริงไหม

เพราะเราไม่เคยพบปัญหาเหล่านั้นมาก่อน แต่ตอนนี้เรากำลังเร่งกระบวนการส่วนหนึ่งของวงจรที่มีหลายขั้นตอน และผมคิดว่านั่นคือจุดที่น่าสนใจ ซึ่งก็คือ "โอเค

เราส่งมอบงานได้มากขึ้น แต่ตอนนี้งานก็ถาโถมเข้ามาไม่หยุด"

เราจึงพบปัญหาอื่นๆ ด้วย

เป็นประเด็นที่น่าสนใจมาก เพราะเมื่อพิจารณาแล้ว จะเห็นว่ามีขั้นตอนต่างๆ มากมาย แต่จากมุมมองระดับสูง คุณสามารถแบ่งขั้นตอนออกเป็น 3 ระยะ

การเขียนโค้ดซึ่งมีการเร่งความเร็วอย่างเห็นได้ชัด

ความพร้อมของเวอร์ชันที่ใช้งานจริงประกอบด้วยหลายสิ่งหลายอย่าง เช่น กฎหมาย ความเป็นส่วนตัว และสิ่งต่างๆ ที่ช่วยให้คุณเปิดตัวผลิตภัณฑ์ได้ จากนั้นก็จะเป็นการเปิดตัวใช่ไหม

และคำว่าการจัดส่งอาจมีความหมายแตกต่างกันไปตามสถานที่ที่คุณอยู่ใช่ไหม

หากคุณเป็นผลิตภัณฑ์ฝั่งเซิร์ฟเวอร์โดยสมบูรณ์ การจัดส่งอาจหมายถึงกระบวนการที่มีประสิทธิภาพมากขึ้น ในขณะที่เมื่อคุณจัดส่งสิ่งที่ส่งไปยังผู้บริโภค เช่น การทดสอบนั้นเป็นเพียงช่วงกลางของเส้นทางเท่านั้น

คุณยังคงต้องทำการทดสอบและการวัดผลอีกมาก และนั่นคือจุดที่เชื่อมโยงกับสิ่งที่คุณพูดว่าคุณรู้สึกเหมือนอยู่ในเขตเมืองใหญ่ บนทางด่วน และคุณมีจุดคอขวด จากนั้นคุณก็เริ่มเร่งความเร็วและคุณก็แบบ "ใช่ เยี่ยมเลย

ฉันกำลังไปได้เร็วมาก" แต่ตอนนี้คุณก็มาถึงจุดคอขวดถัดไปแล้ว

และสิ่งที่ AI ทำให้เห็นได้ชัดเจนมากคือคุณจะเห็นจุดที่เกิดความขัดแย้งได้ชัดเจนขึ้น และบางจุดก็ไม่เกี่ยวข้องกับการเขียนโค้ดหรือเทคโนโลยีเลย

ซึ่งเกี่ยวข้องกับกระบวนการและผู้คน รวมถึงวิธีที่คุณเพิ่มประสิทธิภาพด้วย AI

นั่นเป็นความท้าทายที่น่าสนใจมากเกี่ยวกับวิธีปรับปรุงประสิทธิภาพตั้งแต่ต้นจนจบ

วิธีที่น่าสนใจวิธีหนึ่งที่เรากำลังคิดเกี่ยวกับพื้นที่นี้คือ บุคคลหรือทีมมีสิทธิ์มากน้อยเพียงใดในการจัดส่งอย่างเต็มรูปแบบ

ดังนั้น หากเรามองจากภายใน คุณจะเห็นว่ามีหลายทีมที่อาจกำลังสร้างเครื่องมือภายใน หรือสิ่งต่างๆ ที่ไม่ได้จัดส่งให้ลูกค้า

จัดส่งได้เร็วขึ้นมากใช่ไหม

พวกเขามีสิทธิ์เต็มที่ในการนำเสนอข้อมูลดังกล่าวให้ลูกค้าทราบทันที

หากคุณมีผลิตภัณฑ์ภายนอกที่ยังต้องผ่านการทดสอบกับผู้ใช้ หรือคุณทราบเวลาเปิดตัวใน App Store หรือคุณทราบการทำงานร่วมกับฝ่ายออกแบบและผลิตภัณฑ์ คอขวดอื่นๆ ทั้งหมดเหล่านี้จะเพิ่มขึ้น และผู้ที่เขียนโค้ดจะมีสิทธิ์น้อยลงมากในการดำเนินการอย่างรวดเร็วในเรื่องนั้น

ดังนั้นจึงทำให้เกิดปัญหาคอขวดอื่นๆ ในระบบ

ดังนั้น ผมคิดว่าการแบ่งข้อมูลออกเป็น 2 ส่วนที่แตกต่างกันจะช่วยเน้นย้ำให้เห็นว่ากระบวนการทางธุรกิจของคุณสามารถปรับปรุงได้ในจุดใด

ใช่ ฉันเห็นด้วย และฉันคิดว่าวิศวกรรมไม่เคยเป็นปัญหาคอขวดเลย

ฉันพูดเรื่องนี้มาหลายปีแล้ว

วิศวกรรมมีวิธีการทำงานที่ค่อนข้างเป็นทางการ และมักจะมาจากธุรกิจที่ถามว่า "ปัญหาคืออะไร"

คุณจะได้คำตอบที่แตกต่างกัน 10 แบบ

แล้วก็ "โอเค

ทีนี้เรามาลองแปลความหมายของสิ่งนั้นเป็นโซลูชันบางอย่างที่เกี่ยวข้องกับผลิตภัณฑ์กัน

ตอนนี้มาลองคิดถึงเรื่องนั้นกันสักพัก

มาพูดคุยเรื่องการออกแบบกันสักหน่อย

เตะไปตรงนั้น"

เมื่อถึงขั้นตอนการออกแบบทางวิศวกรรม เราก็รู้แล้วว่าต้องทำอะไรบ้าง

จากนั้นเราก็แค่พยายามไปที่ Stack Overflow แล้วคัดลอกและวางบางอย่าง แล้วก็ส่งสิ่งนั้นออกไป

ดังนั้น AI จึงช่วยให้ผมทำงานได้เร็วขึ้นมากที่สุดในส่วนของการปฏิบัติตามข้อกำหนด

สิ่งที่เราต้องการปรับปรุง XYZ ให้ทันสมัยอยู่เสมอ หรือต้องการอัปเกรดเวอร์ชัน Spring Boot อย่างรวดเร็วอยู่เสมอ

เรากำลังดำเนินการเรื่องนี้อย่างรวดเร็ว

แต่ในแง่ของการนำเสนอฟีเจอร์จริง ฉันไม่เห็นว่ามีการปรับปรุงที่สำคัญมากนัก

คุณทุกคนได้พูดถึงเรื่องนี้ว่าคอขวดอาจย้ายไปแล้ว และคุณกำลังเจอกับกระบวนการเหล่านี้ซึ่งเดิมทีไม่ใช่คอขวด แต่ตอนนี้กลายเป็นคอขวดแล้ว

แต่กระบวนการเหล่านั้นอาจมาจากบทเรียนที่ยากลำบากในอดีตใช่ไหม

คุณรู้สึกกดดันไหมที่ต้องเปลี่ยนสิ่งเหล่านั้น และผมคิดว่าสิ่งที่ชัดเจนที่สุดคือการรีวิวโค้ด

เราคิดว่าอนาคตของการรีวิวโค้ดจะเป็นอย่างไร

สิ่งที่เรากำลังทำอยู่ในปัจจุบัน

ฉันอยากฟังความคิดเห็นของคุณ

คุณรู้ไหมว่ามันกลับไปที่ประเด็นที่ฉันพูดถึง

ผมรู้สึกว่าคอขวดเหล่านี้ส่วนใหญ่เกิดจากการที่เราคิดว่า ถ้าคุณมีไม้กายสิทธิ์และได้สร้างวิศวกรรมซอฟต์แวร์ขึ้นมาใหม่ และคุณมี AI ในปัจจุบัน เราจะใช้สิ่งเดิมๆ ไหม เราจะทำสิ่งเดิมๆ ไหม

เช่น การรีวิวโค้ดเป็นเพราะเราต้องการให้มนุษย์ตรวจสอบสิ่งต่างๆ เช่น การตรวจสอบข้ามขั้นสุดท้าย

ผมคิดว่าเรื่องนั้นก็กำลังเปลี่ยนไปเช่นกัน อย่างเช่น วิธีที่เราคิดเกี่ยวกับการรีวิวโค้ดในตอนนี้คือ บางทีเราควรเปิดรับแนวคิดที่ว่า หากคุณกำลังเปลี่ยนโครงสร้างภายในโค้ดของชื่อ หรือพยายามเปลี่ยนโครงสร้างภายในโค้ด และคุณรู้ว่าคุณมีการทดสอบที่ยอดเยี่ยม ซึ่งทุกคนมีอย่างชัดเจน

เรามี AI เขียนให้แล้ว ไม่เป็นไร

ไม่ คุณจะทำงานได้ดีกว่าตัวแทนคนนั้นไหม

ฉันไม่รู้เหมือนกัน บางทีอาจไม่ต้องเสียเวลาตรวจสอบเรื่องนั้นก็ได้

ในทางกลับกัน หากคุณกำลังจะส่งข้อบกพร่อง และคุณได้รับสายจาก CEO ที่บอกว่า "เฮ้ สิ่งนี้ทำให้เราเสียเงิน X ดอลลาร์" คุณอาจระบุพื้นที่และระบบที่ "เฮ้ นี่เป็นพื้นที่สำคัญ

นี่ไม่ใช่พื้นที่สำคัญ" แล้วลองจินตนาการใหม่

เราไม่คิดว่านั่นคือวิธีที่เราดำเนินการในปัจจุบันใช่ไหม

แต่ทุกวันนี้เหมือนกับว่า "เฮ้ มี PR ด้วย

ฉันเป็นวิศวกร

ฉันกำลังโฟกัสเรื่องนี้อยู่

มันจะเพิ่มขึ้น

ผมขอให้ Vinay ช่วยรีวิวโค้ดให้ตอนกลางดึก เพราะผมแค่อยากผสานโค้ดนี้ให้เสร็จ"

ในทางกลับกัน เราอาจต้องคิดใหม่เกี่ยวกับเรื่องเหล่านั้น

ผมเห็นด้วยอย่างยิ่ง และผมคิดว่าการรีวิวโค้ดเป็นปัญหาด้านการตรวจสอบ และสิ่งที่ผมหมายถึงก็คือ ในโลกที่ผมมั่นใจอย่างเต็มที่ในความสามารถของตัวเองในการตรวจสอบบางสิ่ง ผมจะยังคงรีวิวโค้ด 100% ของ PR ของผมไหม

คงไม่ใช่อย่างนั้นใช่ไหม

ดังนั้น การรีวิวโค้ดจึงมีวัตถุประสงค์ 2 ประการ

อย่างแรกคือการยืนยันว่าเรากำลังทำสิ่งที่ถูกต้อง และอย่างที่ 2 คือการให้ความรู้ใช่ไหม

เช่น คนรอบตัวคุณรู้ว่าคุณกำลังทำอะไรอยู่ และเห็นด้วยกับการตัดสินใจนั้นหรือไม่

ดังนั้นจึงมีงานบางประเภทที่เราควรเร่งดำเนินการและตรวจสอบว่างานนั้นจะรวมอยู่ในโค้ดและแม้แต่ในรุ่นต่างๆ

ซึ่งอาจใช้ไม่ได้กับทุกกรณี แต่เราคิดว่าใช้ได้กับกรณีส่วนใหญ่

และผมคิดว่าเรากำลังเตรียมพร้อมที่จะทำการเปลี่ยนแปลงเหล่านั้น และเราทุกคนในฐานะชุมชนต้องตรวจสอบว่าระบบของเราพร้อมสำหรับการเปลี่ยนแปลงนั้น เพราะมันกำลังจะมาถึง

ไม่มีทางหลีกเลี่ยงได้

ส่วนบนของ Funnel มีขนาดกว้างมากและมีแพลตฟอร์มต่างๆ ที่ช่วยให้คุณสร้าง PR ได้มากขึ้น

และคุณจะทำงานได้เร็วเท่ากับขั้นตอนที่ช้าที่สุดของกระบวนการ

และสำหรับหลายๆ ทีม นั่นคือการรีวิวโค้ด และทีมที่ก้าวหน้าได้เร็วกว่าก็เข้าใจและยอมรับความจริงข้อนี้อย่างตรงไปตรงมา

ใช่ และถ้าเราซื่อสัตย์กับตัวเอง ฉันอยากจะบอกว่า 70% ของ PR ที่ฉันเห็นนั้นดูดีสำหรับฉัน

เช่น หากเราค้นหาฐานของโค้ดทั้งหมดในโลก ความคิดเห็นเกี่ยวกับ PR ก็จะเป็น "ดูดีสำหรับฉัน" หรือ LGTM เต็มไปหมด

ดังนั้น ส่วนหนึ่งก็คือในฐานะวิศวกรมืออาชีพ บางครั้งเราก็ให้เครดิตตัวเองมากกว่าที่ควรจะเป็น

เราคิดว่าเราเหมือนอยู่ในนั้นจริงๆ

"พวกเขาใช้รูปแบบคำสั่งไหม"

ไม่เลย เราแค่คิดว่า "โอเค

ใช่ ดูดีเลย"

ถ้าอย่างนั้น ทำไมฉันจึงให้ Agent ทำแบบนั้นไม่ได้

เราคิดว่านั่นคืออนาคตที่เราจะได้เห็นว่าอะไรที่ดูดีสำหรับเรา เช่น ลักษณะเฉพาะคืออะไร พฤติกรรมที่ทำให้คุณรู้สึกแบบนั้นคืออะไร

จากนั้นตรวจสอบว่าตัวแทนค้นหาสิ่งเดียวกัน

หรือในทางกลับกัน ให้ลองคิดถึงวิธีต่างๆ ในการรีวิวด้วย

อย่างที่ฉันรู้จักคนที่เล่น Twitter ทุกวันนี้ พวกเขาพูดถึงเรื่องนี้ใช่ไหม

เช่น เมื่อคุณยืนยัน PR ในตอนนี้ ให้ตัวแทนของคุณแสดงภาพในรูปแบบที่ต่างออกไป ใช่ไหม

เฮ้ ขอดูรูปก่อนหน้าหน่อย

แสดงภาพหลังการปรับปรุงให้ฉันดูหน่อย

แสดงการทดสอบที่คุณเขียนขึ้นเพื่อตรวจสอบโค้ดแบบบรรทัดต่อบรรทัด

แต่ก็ท้าทาย คุณจะพูดอะไรหรือเปล่า Luis

ไม่นะ ผมคิดว่ามันเป็นเรื่องที่กระตุ้นความคิดใช่ไหม

เราจะไปถึงจุดที่คุณรู้สึกสบายใจที่จะปล่อยให้ CL หรือ PR ผ่านไปได้โดยไม่ต้องมีการแทรกแซงจากมนุษย์

ผมจะขอพูดในมุมมองที่ต่างออกไปสักหน่อย ผมอยากจะบอกว่าเมื่อเราพูดถึงอุปสรรค เรามักจะคิดว่าอุปสรรคเป็นสิ่งที่ไม่ดี แต่จริงๆ แล้วอุปสรรคมีทั้งดีและไม่ดี

และฉันคิดว่าฉันรู้สึกว่ารีวิวยังคงอยู่ในหมวดหมู่ของอุปสรรคที่ดี

ประเด็นคือเราจะทำอย่างไรให้นักพัฒนาแอปมีภาระน้อยลง

และบางครั้งก็ไม่ได้เกี่ยวกับวิธีที่เราจะทำให้การตรวจสอบนั้นดีขึ้นหรือมีประสิทธิภาพมากขึ้น ณ เวลานั้น

คุณจะใช้ AI เพื่อทำให้การพัฒนาต้นน้ำแม่นยำยิ่งขึ้นได้อย่างไร

เพราะถ้าคุณแค่... ขึ้นอยู่กับวิธีที่คุณใช้ AI เช่น การป้อนข้อมูลที่ดีจะสร้างเอาต์พุตที่ดีกว่า แต่การป้อนข้อมูลที่ไม่ดีจะสร้างผลลัพธ์ที่แย่มาก จริงไหม

ดังนั้น ผมคิดว่าการจะไปถึงสถานะสุดท้ายที่น่าสนใจนั้นจะต้องเป็นการปรับปรุงกระบวนการแบบองค์รวมด้วย AI ตั้งแต่ต้น โดยใช้ AI เพื่อให้เข้าใจสถาปัตยกรรมได้ดีขึ้น เพื่อให้มีข้อกำหนดที่ชัดเจนโดยที่นักพัฒนาซอฟต์แวร์ไม่ต้องใช้ความพยายามมากนัก เพื่อให้โค้ดที่สร้างขึ้นมีคุณภาพสูงขึ้น

ดังนั้น การตรวจสอบจึงมีอุปสรรคสำหรับนักพัฒนาแอปน้อยลง

ฉันคิดว่าสถานะสุดท้ายของเรื่องนี้ซึ่งไม่น่าจะก่อให้เกิดข้อขัดแย้งคือคนส่วนใหญ่เห็นว่าโค้ดทั้งหมดนี้จะได้รับการเผยแพร่โดยไม่มีการตรวจสอบจากเจ้าหน้าที่ในท้ายที่สุด

ผมคิดว่าในระหว่างนี้ เราอยู่ในสถานการณ์ที่กำลังพัฒนาซึ่งโมเดลต่างๆ กำลังดีขึ้น และเรากังวลน้อยลงเกี่ยวกับข้อผิดพลาดทางเทคนิค และกังวลมากขึ้นเกี่ยวกับข้อผิดพลาดทางธุรกิจ หรือการตัดสินหรือการหาไอเดียที่เข้ามาเป็นปัญหา

ดังนั้น คุณจึงควรแยกสัญญาณดังกล่าวออกในขั้นตอนการตรวจสอบ

เช่น เราควรตรวจสอบทีละบรรทัดใน PR หรือตรวจสอบเจตนาที่พวกเขาพยายามผลักดันหลังจากนั้น

เรากำลังพิจารณาเรื่องนี้ใน 2-3 วิธีที่แตกต่างกัน

ประเด็นแรกคือเราจะให้ข้อมูลที่เกี่ยวข้องมากขึ้นแก่ผู้ใช้ได้อย่างไร เพื่อให้ผู้ใช้เริ่มจัดลำดับความสำคัญของข้อมูลนั้นได้

อีกประเด็นคือพื้นที่ที่ปลอดภัยกว่าซึ่งเราสามารถทดลองและดำเนินการได้เร็วขึ้นในโปรแกรมประเภทนี้คืออะไร

อย่างที่ Kaushik กล่าวไว้ว่าไม่ใช่ทุกพื้นที่ที่ต้องใช้ความเข้มงวดในระดับเดียวกัน

เราสามารถระบุสิ่งนี้ได้และเริ่มปล่อยให้บางอย่างผ่านไปได้เร็วขึ้น ลดความเสี่ยงในขณะที่ยังคงรักษาพื้นที่ที่เน้นการปฏิบัติตามข้อกำหนดมากกว่า หรือพื้นที่ที่เป็นรากฐานสำคัญซึ่งมีอุปสรรคสูงกว่า จนกว่าเราจะถึงจุดที่เชื่อมั่นไม่เพียงแต่โมเดลเท่านั้น แต่ยังรวมถึงข้อมูลที่ป้อนเข้าไปด้วย

เป็นการตัดสินใจที่ถูกต้อง

เช่น การเปลี่ยนโครงสร้างภายในโค้ดของโมดูล Android ใหม่ในแอป Uber อาจเป็นเรื่องที่ยอมรับได้

เราให้บริการฟรีแก่นักพัฒนาแอป Android ทุกคน คุณอาจต้องตรวจสอบโค้ดนั้น

ฉันต้องตรวจสอบเรื่องนั้นกับ CEO ของเรา

ขออภัย คุณ Kaushik

แต่ผมก็คิดว่าปัญหานี้ได้รับการแก้ไขแล้ว

เรามีแฟล็กฟีเจอร์ที่คล้ายกันอยู่แล้ว

เรามี Blue-Green Deployment อยู่แล้ว

เรามีองค์ประกอบหลายอย่างอยู่แล้ว

ความท้าทายคือเรายุ่งเกินกว่าที่จะทำได้จริงๆ

เรามีการติดตามพฤติกรรมอยู่แล้ว

เรามีข้อมูลประเภทนี้ทั้งหมด แต่ข้อมูลเหล่านั้นอยู่ในระบบที่แตกต่างกัน

เราติดตามเหตุการณ์อยู่แล้ว

เรามีข้อมูลจำนวนมาก แต่การนำข้อมูลทั้งหมดมารวมกันเป็นร่องรอยที่ครอบคลุมคือส่วนที่ขาดหายไป

เมื่อเราทราบแล้วว่าบริการบริบทด้านวิศวกรรมประเภทนั้นมีลักษณะอย่างไรในบริษัทต่างๆ เหล่านี้ เราก็ไม่ต้องกังวลอีกต่อไป เพราะแม้ว่า PR จะถูกผสานรวม แต่ก็ปลอดภัย

เพราะเรารู้ว่าเรามีฟีเจอร์นั้นอยู่เบื้องหลังแฟล็กฟีเจอร์

เรามี Blue-Green Deployment

เรามีความสามารถในการสังเกตทั้งหมดพร้อมใช้งาน

จากนั้นคุณจะรู้สึกมั่นใจสุดๆ ที่จะพูดว่า "โอ้ ใส่ไว้ในไปป์ไลน์เลย"

หากเกิดสิ่งไม่ดีขึ้น เราก็มีเจ้าหน้าที่รักษาความปลอดภัยและประตูรั้วตลอดทาง

ผมคิดว่าความเร็วในการตอบสนองก็สำคัญมากเช่นกัน ใช่ไหม

หากคุณทราบ ลองมาดู Android กันสักครู่ หากคุณกำลังทำการเปลี่ยนแปลงใน Android และจำเป็นต้องจัดส่งผ่าน Play Store แล้วจึงเปิดตัวให้ผู้บริโภค ความสามารถในการแก้ไขด่วนทันทีจะถูกจำกัดอย่างมากเมื่อเทียบกับกรณีที่คุณทำสิ่งที่มีการติดตั้งใช้งานภายในพร้อมความสามารถในการสังเกตภายในและตัวแทนที่ดำเนินการทันที คุณจะมีโอกาสดำเนินการได้รวดเร็วกว่ามาก

คำถามหนึ่งที่ผมมีให้พวกคุณคือยังมีปัญหาที่ต้องดำเนินการกับแอปเหล่านี้ แต่คุณก็มีแอป Greenfield เหล่านี้ที่ง่ายกว่า จากนั้นคุณก็มีแอป Brownfield เหล่านี้ และยังมีช่วงเวลาที่คุณต้องใช้เวลาในการตรวจสอบสิ่งเหล่านี้จำนวนมาก เพื่อให้คุณสามารถแพร่กระจายการใช้ AI ได้

เราทราบดีว่าหลายๆ คนทำงานกับแอปขนาดใหญ่ใช่ไหม

ฉันจึงอยากรู้ว่าคุณคิดอย่างไรเกี่ยวกับเรื่องนี้

คุณต้องบอก CEO ว่า "ขอเวลา 3 เดือนเพื่อเตรียมแอปนี้ให้พร้อมสำหรับ AI" หรือว่าคุณต้องเพิ่ม AI เข้าไปทุกวัน

ใช่

ซึ่งปกติก็ไม่ทำอยู่แล้ว

ไม่น่าจะใช่

ซึ่งบริษัทส่วนใหญ่ไม่มีโอกาสได้ทำแบบนี้

ผมคิดว่าเราแค่ต้องทุ่มเทให้กับเรื่องนี้ในแบบเดียวกับที่เราเคยทำกับหนี้ทางเทคนิค (Tech Debt) เช่น ใช้เวลา 20% ไปกับเรื่องนี้ หรือใช้เวลา 5% เพื่อปรับปรุงพรอมต์

และยังเข้าใจว่าพรอมต์ทำอะไร และทำให้บริบทดีขึ้นด้วย

อย่างที่เราพูดถึงเรื่องนี้กันไปเยอะแล้ว ผมคิดว่าวิศวกรจำนวนมากยังไม่เข้าใจวิธีการทำงานของ AI

แต่ก็ยังรู้สึกว่ามันเป็นเรื่องมหัศจรรย์และลึกลับอยู่ดี พวกเขาจึงไม่ได้กำหนดค่าและปรับแต่งในแบบที่จะได้รับคุณค่าและประสิทธิภาพที่ดีขึ้น

ดังนั้น ฉันคิดว่าต้องมีจุดที่ผู้นำถามว่า "เราต้องทำอะไรเพื่อยกระดับทีมเพื่อให้เข้าใจวิธีการทำงานของสิ่งนี้ และเราจะได้รับประโยชน์มากขึ้น"

และยังเป็นความต่อเนื่องของเรื่องราวด้วย

เนื่องจาก AI เปลี่ยนแปลงเร็วมาก หากผมขอให้ทีมใช้เวลา 1 สัปดาห์เพื่อเรียนรู้สิ่งใหม่ๆ และดีที่สุด แล้วนำไปใช้จริง แต่หลังจากนั้นทีมไม่มีเวลาเรียนรู้หรือทดลองต่อ และเรากลับมาตรวจสอบอีกครั้งในปีหน้า ทีมจะตามหลังความสามารถใหม่ๆ อยู่มาก

ดังนั้นจึงต้องเป็นแบบนี้ทั้งหมด คุณก็รู้ว่าเรากำลังสร้างเครื่องบินขณะที่บินอยู่ โดยเรากำลังวางราวกั้น เรียนรู้ และปรับเปลี่ยนไปตามสถานการณ์ที่เกิดขึ้น และทีมต่างๆ ต้องคอยติดตามเรื่องนี้อยู่เสมอ

และในองค์กรขนาดใหญ่ ก็มีทีมอย่างทีมของเราที่พยายามกลั่นกรองข้อมูลบางส่วนและทำให้ข้อมูลนั้นเข้าใจง่ายและเข้าถึงได้มากขึ้น

แต่ก็เป็นความท้าทายสำหรับทุกคนในอุตสาหกรรมในขณะนี้

ฉันอยากลองทำอะไรใหม่ๆ บ้าง

คุณ หลายคนทำงานในโครงสร้างพื้นฐานของนักพัฒนาซอฟต์แวร์

PR หลายพันรายการ โครงสร้างพื้นฐานการทดสอบ เซิร์ฟเวอร์ของคุณ ทั้งหมดนี้ล่มไหม

และฉันก็อยากฟังเรื่องราวการต่อสู้ด้วย

Ty?

ได้

พวกเขากำลังมาแรง

CI ของฉันร้องไห้จนหลับไปทุกคืน

ตอนนี้ทีมโครงสร้างพื้นฐานสำหรับนักพัฒนาซอฟต์แวร์เกือบทั้งหมดของเรากำลังต่อสู้กับปัญหาการปรับขนาดในการประมวลผลและปัญหาด้านประสิทธิภาพ

คุณก็รู้ว่ามีโค้ดสีแดงอยู่

ปริมาณการเข้าชมเพิ่มขึ้นอย่างมาก

เรากำลังทำการเปลี่ยนแปลงสถาปัตยกรรมกับ Agent

เราพยายามทำสิ่งต่างๆ ให้เร็วที่สุดเท่าที่จะเป็นไปได้ เช่น ขยายการดำเนินการบิลด์ระยะไกลและการแคชด้วย Bazel โดยพิจารณาสิ่งต่างๆ เช่น คุณรู้ไหมว่า Main ทั้งหมดต้องเป็นสีเขียวตลอดเวลาได้อย่างไร หรือเราจะเริ่มแก้ไขล่วงหน้าด้วย Agent ในบางพื้นที่ได้ไหม โดยพิจารณาจากปริมาณที่มาจากวิศวกร พยายามทำสิ่งต่างๆ เช่น CI ที่แก้ไขตัวเองได้ หรือรายงานความคิดเห็นที่ต่ำลง และทุกทีมก็กำลังลงทุนอย่างแข็งขันในสิ่งเหล่านี้ทั้งหมดเพื่อพยายามตามการเติบโตให้ทันไปพร้อมกับรักษาประสิทธิภาพในระดับหนึ่งไว้

แต่ก็เป็นเรื่องที่ท้าทายอย่างยิ่ง

ใช่ ฉันเห็นด้วยกับทุกอย่างที่ Ty เพิ่งพูดไป แต่ฉันคิดว่ามันยังบังคับให้เราต้องไตร่ตรองและตั้งคำถามอย่างตรงไปตรงมาว่าหากเราจะเติบโตขึ้น 10 เท่าจากจุดนี้เป็นต้นไป เราพร้อมไหม

และสำหรับคนส่วนใหญ่ คำตอบน่าจะเป็น "ไม่"

และด้วยเหตุนี้ เมื่อเรานึกถึงอนาคต เราจึงพยายามจับคู่ความทะเยอทะยานของเรากับขนาดที่โครงสร้างพื้นฐานรองรับได้

และสิ่งหนึ่งที่ AI ทำคือทำให้เราทุกคนมีความทะเยอทะยานมากขึ้น เพราะเราได้เห็นการก้าวกระโดดที่มีความหมายแล้ว เราจึงกำลังคิดทบทวนระบบของเราใหม่อย่างจริงจัง

ใช่ เรากำลังคิดว่าระบบอื่นๆ จะมีปัญหาอะไรอีก หรือเราคาดการณ์ว่าจะมีปัญหาอะไร และเราจะทำอะไรได้บ้างเพื่อป้องกันไม่ให้เกิดปัญหาขึ้น

และในความเป็นจริง เราพยายามหลีกเลี่ยงปัญหาที่คาดไม่ถึง

ใช่ ตราบใดที่เรารู้สึกว่าเราควบคุมได้ ทุกคนก็มีความสุข

ทันทีที่เราพบกับเรื่องไม่คาดคิด ผมรู้เลยว่านั่นเป็นข่าวร้ายสำหรับทุกคน

ถูกต้องไหม

และนี่เป็นช่วงเวลาที่ดีในการทบทวนและมองย้อนกลับไป ตรวจสอบ และค้นหาว่าอะไรจะพังต่อไป เพราะมันจะเกิดขึ้น

เป็นสิ่งที่หลีกเลี่ยงไม่ได้

เราแค่ต้องการเตรียมพร้อมรับมือล่วงหน้า

มีคำพูดที่น่าสนใจจาก CEO ของ Inflow

เธออธิบายว่านี่คือไทม์ไลน์ที่ Google ใช้ในการเขียนโค้ดหลายพันล้านบรรทัดที่ใช้อยู่ในปัจจุบัน ซึ่งใช้เวลาประมาณ 20 ปี และด้วยการเร่งความเร็วของกระบวนการนี้ บริษัทจำนวนมากของเราจะมองหาขนาดที่คล้ายกันในเวลาเพียงไม่กี่ปี โดยอิงตามการเร่งความเร็วของ AI

และผมไม่คิดว่าทุกบริษัทจะพร้อมมีโครงสร้างพื้นฐานระดับ Google สำหรับการพัฒนา

ถ้าอย่างนั้น บริษัทของคุณมีการกำหนดวงเงินใช้จ่ายไหม

เช่น คุณจะจัดการกับนักพัฒนาซอฟต์แวร์บางรายที่ใช้โทเค็นอย่างสิ้นเปลืองกับทุกอย่างได้อย่างไร คุณก็รู้ว่าพวกเขาใช้โมเดลที่ดีที่สุดเท่าที่จะเป็นไปได้ตลอดเวลา

คุณมีกลยุทธ์อะไรไหม หรือปล่อยให้พวกเขาทำตามใจชอบไปเลยดีกว่า เพราะการทดลองจะนำไปสู่ผลลัพธ์ที่น่าพอใจ

ฉันคิดว่าปีที่แล้วเป็นปีแห่งการทดลอง

ทำทุกอย่าง

และบางทีในช่วงครึ่งแรกของปีนี้ก็อาจจะแค่ใช้ AI อย่างสมเหตุสมผล

และตอนนี้ ตั้งแต่เดือนกันยายนเป็นต้นมา เรามีขีดจำกัดโทเค็น

เราจึงจำกัดการใช้งานโทเค็นสำหรับนักพัฒนาแอป

และเรายังมีเครื่องมือวัดผลเพื่อให้เข้าใจว่าคุณมีเซสชันที่ดีและมีประสิทธิภาพหรือไม่

การมีเซสชันที่ดีต่อสุขภาพหมายความว่าอย่างไร

คุณมีจำนวนเทิร์นต่อเซสชันมากขนาดนี้ไหม

การเลี้ยวคืออะไร

เราจึงพยายามใช้เครื่องมือเพื่อให้ความรู้แก่นักพัฒนาแอปด้วย

ผมคิดว่านั่นเป็นเพียงก้าวแรกเท่านั้น

คุณต้องรู้ว่ามีปัญหาก่อนจึงจะแก้ไขได้

ดังนั้น อย่างน้อยก็ทำให้พวกเขาเห็นว่าการทำสิ่งนี้มีต้นทุน

ก่อนหน้านี้ AI ดูเหมือนจะใช้งานได้ฟรีจริงๆ

และผู้คนก็ใช้มัน

ฉันอยากได้แบบ "เปลี่ยนสาขา" เช่น "ได้เลย Annyce ฉันจะเปลี่ยนสาขาให้คุณในราคา $5"

ตอนนี้เรามาถึงจุดที่ว่า "โอเค ฉันไปที่บรรทัดคำสั่งแล้วทำเองได้เลยใช่ไหม"

ดังนั้นผมคิดว่าเราจะเริ่มให้วิศวกรได้รับการศึกษาเกี่ยวกับต้นทุนที่แท้จริง

More so like I wouldn't just spin up ECS instances and just like run away from them.

ตอนที่ AWS เปิดตัวครั้งแรก เราอาจคิดว่า "ฉันสร้างอินสแตนซ์ของตัวเองได้"

และเราก็ทำให้บริษัทเสียเงินไปเยอะมาก

ผมคิดว่าตอนนี้สิ่งเดียวกันนี้กำลังเกิดขึ้นกับโทเค็น

ผมคิดว่าขีดจำกัดในทางปฏิบัติก็ทำให้เกิดโอกาสที่น่าสนใจมากเช่นกัน จริงไหม

เพราะเมื่อคุณนึกถึงตอนแรกที่เราเริ่มใช้ LLM คุณจะป้อนข้อมูลทุกอย่างลงไปใช่ไหม

โดยจะตรวจสอบโค้ด ค้นหาสิ่งต่างๆ และทำสิ่งมหัศจรรย์ให้คุณใช่ไหม

แต่ก็ต้องแลกมาด้วยต้นทุนที่สูง

และเราก็เป็นของจริง ซึ่งอุตสาหกรรมก็ตระหนักถึงเรื่องนี้

ซึ่งทำให้นักพัฒนาซอฟต์แวร์และองค์กรต้องคิดว่าจะเพิ่มประสิทธิภาพได้อย่างไร

What Why คืออะไร ยกตัวอย่างเช่น ผมจะยกตัวอย่างที่เป็นรูปธรรมให้ฟัง หากคุณมีเครื่องมือสร้างที่สร้างคอมโพเนนต์อินเทอร์เฟซผู้ใช้ และคอมโพเนนต์เหล่านั้นต้องเป็นไปตามโครงสร้างที่เฉพาะเจาะจง การทำ Unit Test และสิ่งต่างๆ ในลักษณะนั้น ทำไมคุณถึงต้องให้โมเดลสร้างสิ่งนั้นขึ้นมาทันที หากคุณสามารถให้โมเดลสร้างเครื่องมือเชิงกำหนดที่สามารถสร้างสิ่งนั้นให้คุณได้เลย จริงไหม

ดังนั้น คุณจึงมีโอกาสมากมายที่จะใช้ขีดจำกัดของโทเค็นและการใช้งานให้เป็นประโยชน์ และมีประสิทธิภาพมากขึ้น

ใช่ และในธีมเหล่านั้น เราได้กำหนดขีดจำกัดไว้อย่างแน่นอน อย่างน้อยก็อย่างที่คุณทราบที่ Instacart

แต่ผมคิดว่าเป้าหมายไม่จำเป็นต้องเป็นการจำกัดปริมาณการใช้ AI แต่เป็นการสร้างสุขอนามัยบางอย่าง หรืออย่างที่คุณพูดคือการพิจารณาตนเอง ใช่ไหม

เช่น คุณควรใช้โมเดลบางอย่างเมื่อใดเมื่อเทียบกับโมเดลอื่นๆ

คุณรู้ไหมว่าคุณอาจไม่จำเป็นต้องใช้ Fable หรือ Astra เพื่อบอกเวลาหรือเปลี่ยน Git Branch

ถูกต้องไหม

คุณอาจใช้เวลาเขียนสคริปต์และใช้งานได้ฟรีตลอดไป

ไม่เสียโทเค็นไปเปล่าๆ แน่นอน

ถูกต้องไหม

ดังนั้น ฉันคิดว่าหากคุณสามารถเพิ่มข้อจำกัดบางอย่างที่ไม่จำเป็นต้องจำกัดการใช้งาน แต่ช่วยให้คุณคิดได้มากกว่าแค่การทุ่มเททุกอย่างให้กับสิ่งนั้น

ถูกต้องไหม

ฉันชอบสิ่งที่คุณพูด ปีที่แล้วให้ความรู้สึกเหมือนเป็นปีแห่งการทดลอง

ปีนี้จึงเป็นเหมือนปีที่เราต้องคิดว่าจะใช้สิ่งนี้อย่างมีประสิทธิภาพได้อย่างไร

ใช่

เรื่องราวที่นี่ทำให้เราเข้าใจความรู้สึกของคนอื่นๆ ได้เป็นอย่างดี

โดยเฉพาะอย่างยิ่งการเปลี่ยนจากการทดลองไปสู่การสร้างสมดุลระหว่างประสิทธิภาพและความรับผิดชอบ

ซึ่งมาจากการลงทุนที่หลากหลาย

มีทั้งการให้ความรู้แก่นักพัฒนาแอปและการแสดงข้อมูล

อย่างที่ Annyce พูดถึงเรื่องต้นทุนและข้อมูลเซสชันกิจกรรม

การลงทุนในค่าเริ่มต้นที่ปลอดภัยซึ่งช่วยหลีกเลี่ยงการโต้ตอบที่สิ้นเปลือง ตรวจสอบว่าทักษะที่ใช้มีประสิทธิภาพในการมองหาการถดถอยและสิ่งต่างๆ ในนั้น

และให้ความรับผิดชอบต่อค่าใช้จ่ายที่ใช้ไป

เรามีขีดจำกัดโทเค็น

และเมื่อนักพัฒนาแอปถึงขีดจำกัดดังกล่าว ก็สามารถคลิกปุ่มเพียงครั้งเดียวและใส่เหตุผลประกอบ จากนั้นผู้จัดการก็สามารถอนุมัติได้

ดังนั้น หากมีผลงานที่ยอดเยี่ยม เราก็อยากให้พวกเขาได้เห็น

แต่ถ้าพวกเขากำลังทำอะไรที่สิ้นเปลืองหรือเป็นการทดลองมากกว่า พวกเขาก็ไม่สามารถอธิบายให้ผู้จัดการฟังได้ว่าทำไมจึงควรใช้จ่ายเงินไปกับสิ่งนั้น ซึ่งจะช่วยให้พวกเขาควบคุมสิ่งนั้นได้เช่นกัน

และนั่นส่งผลให้ไม่เพียงแต่ไม่ทำงานเท่านั้น แต่ยังมองและพูดว่า นี่เป็นตัวเลือกโมเดลที่ถูกต้องหรือไม่

น้ำหนักนี้ถูกต้องไหม

คุณก็ทราบดีว่าต้นทุนของโทเค็นเหล่านี้เริ่มลดลงเนื่องจากแรงกดดันด้านการแข่งขัน

แต่โดยทั่วไปแล้ว การให้วิศวกรของเราคิดถึงเรื่องนี้ในฐานะผู้ดูแลเงินที่เรามอบให้เป็นอย่างดีนั้นเป็นแนวทางที่เหมาะสมและถูกต้องในตอนนี้

และในระยะยาว คุณจะนำการตัดสินใจนั้นออกจากเด็กๆ ได้อย่างสมบูรณ์

ถูกต้องไหม

คุณต้องการการกำหนดเส้นทางโมเดลอัตโนมัติและสิ่งต่างๆ ในลักษณะนั้น ซึ่งผู้ใช้ไม่ต้องคิดถึงเรื่องนี้เลย

แต่ในระหว่างนี้ สถานะนี้ถือว่าปกติ

ใช่

ผมคิดว่าเรามุ่งเน้นไปที่การทำสิ่งต่างๆ เช่น เราเตอร์โมเดล เพื่อให้นักพัฒนาซอฟต์แวร์ไม่ต้องตัดสินใจเรื่องนี้ และพยายามจับคู่งานกับโมเดลที่เหมาะสม

แต่ยังรวมถึงการมีมาตรการป้องกันที่เหมาะสมด้วย

ดังนั้น เราจึงพิจารณาขีดจำกัดของโทเค็นใน 2-3 วิธี

เราไม่ต้องการบล็อกนักพัฒนาแอป

แต่เราต้องการตรวจสอบให้แน่ใจว่ามีช่วงเวลาที่เราสามารถหยุดชั่วคราวเพื่อตรวจสอบว่ามีการใช้จ่ายในด้านที่เหมาะสมและในลักษณะที่ถูกต้อง

ดังนั้นจึงมีขีดจำกัดการใช้งานต่อวันเป็นตัวอย่าง ซึ่งเป็นเพียงมาตรการป้องกันที่นักพัฒนาแอปสามารถปลดบล็อกได้ด้วยตนเอง

สิ่งที่พวกเขาต้องทำก็แค่ไปที่พอร์ทัล คลิกปุ่ม แล้วพูดว่า "เฮ้ ฉัน ไม่มีอะไรน่าแปลกใจเกิดขึ้น

ฉันควบคุมได้"

ถูกต้องไหม

และนั่นเป็นเพียงตัวควบคุมง่ายๆ ตัวหนึ่ง เนื่องจากทุกคนกำลังวนซ้ำ และการวนซ้ำเหล่านี้สามารถทำงานได้ข้ามคืน และเราไม่ต้องการให้การทำงานนี้ทำให้เกิดค่าใช้จ่าย

ดังนั้นจึงเป็นเรื่องที่สมเหตุสมผลอย่างยิ่ง

ในทางกลับกัน เราก็ต้องการให้นักพัฒนาซอฟต์แวร์มีโมเดลที่ดีที่สุดพร้อมใช้งานด้วย

แต่สำหรับโมเดลประเภทนั้น เราได้สร้างงบประมาณระดับแนวหน้าขึ้นมา

ดังนั้นจึงมีการกำหนดงบประมาณรายเดือนไว้

สูงพอแล้ว

คุณไม่ได้ถูกบล็อก

หากต้องการให้เลิกบล็อก คุณสามารถทำตามกระบวนการข้อยกเว้นได้

ระบบจะส่งคำขอไปยังผู้จัดการของคุณ

ซึ่งเป็นช่วงเวลาที่คุณอธิบายสิ่งที่คุณกำลังทำอยู่

และเราไม่ได้เป็นผู้ตัดสินใจในฐานะทีมแพลตฟอร์ม เนื่องจากการตัดสินใจเหล่านั้นควรเกิดขึ้นใกล้กับจุดที่งานกำลังดำเนินอยู่

ในแง่ของการใช้ Frontier Model เราให้ความยืดหยุ่นอย่างเต็มที่แก่คุณโดยมีเพดานจำกัด

และเหตุผลที่วิธีนี้ได้ผลก็คือท้ายที่สุดแล้ว วิธีนี้จะทำให้กระบวนการต่างๆ คาดการณ์ได้

ถูกต้องไหม

เราต้องการให้แน่ใจว่าเมื่อเราจัดสรรงบประมาณการใช้จ่ายโทเค็น ซึ่งเป็นเรื่องที่ท้าทายสำหรับทุกคน เราได้พิจารณาสิ่งที่เราวางแผนไว้แล้ว และเครื่องมือเหล่านี้ช่วยให้เราทำเช่นนั้นได้

คุณรู้ไหมว่าฉันพบอะไรที่น่าสนใจในการสนทนาเหล่านี้

ฉันคิดว่าเป็นเพราะเราทุกคนทำงานในบริษัท

และองค์กรต่างๆ

ดังนั้นเราจึงต้องจ่ายเงินสำหรับทุกโทเค็น

ถูกต้องไหม

แต่ก็มีอีกด้านหนึ่งของอินเทอร์เน็ตที่ผู้คนใช้บริการแบบสมัครสมาชิก

ดังนั้น สำหรับพวกเขาแล้ว มันจึงเป็นการคำนวณที่แตกต่างกันมาก

ถูกต้องไหม

แต่ผมคิดว่าคุณก็รู้ว่าอีกไม่นานทุกคนจะอยู่ในสถานการณ์เดียวกันที่คุณต้องเริ่มคิดถึงโทเค็นทุกตัว

และนั่นคือตอนที่เรารู้ว่าอาจมีเรื่องไม่คาดคิดเกิดขึ้นในแง่ของการมีความรับผิดชอบมากขึ้น เช่นเดียวกับที่เราต้องทำในบริษัทต่างๆ ในตอนนี้

หรือคุณทำงานในห้องปฏิบัติการที่ล้ำสมัยซึ่งมีงบประมาณไม่จำกัด

จากนั้นคุณก็แค่ดำเนินการต่อไปและสร้างวิธีการทำงานแบบ AI เนทีฟที่น่าตื่นเต้นเหล่านี้ซึ่งมีอยู่มากมายใน Twitter

บริษัททั้งหมดของเราต้องการทำตาม แต่ไม่คิดว่าต้องการใช้โทเค็นที่…

เรามีพนักงานที่ทำงานที่ Google อยู่ที่นี่

ฉันอยากรู้มาก

ปุ่มนี้ทำงานอย่างไร

งบประมาณจาก Google คืออะไร

คุณอยากตอบไหม Luis

ฉันไม่คิดว่าฉันเป็นคนที่เหมาะสมที่จะพูดถึงเรื่องเศรษฐศาสตร์ของเรื่องนี้

Google เป็นบริษัทขนาดใหญ่มากที่มีองค์กรต่างๆ มากมาย

แต่จริงๆ แล้วเราก็สรุปได้ดีเลยนะ เพราะเราทำเวลาได้ดีมาก

สะดวกมาก

Saved by the bell

นี่คือการดูแลระดับท็อปเลยนะทุกคน

ฝ่ายประชาสัมพันธ์คือ…

อย่างไรก็ตาม ขอขอบคุณคณะผู้เชี่ยวชาญของเรา และขอบคุณที่มาร่วมงาน ADS