Lập trình dựa trên tác nhân: Buổi thảo luận bàn tròn với các nhà lãnh đạo trong ngành

Chào mọi người.

Bạn đã nghe chia sẻ của nhiều nhân viên Google phụ trách Android trong tuần này hoặc hai ngày qua.

Vì vậy, chúng tôi nghĩ rằng sẽ rất tuyệt nếu kết thúc hội nghị bằng cách lắng nghe ý kiến của một số người bên ngoài, từ cộng đồng, từ cộng đồng Nhà phát triển Android.

Chúng ta sẽ nói về lập trình dựa trên tác nhân và tác động thực tế của nó.

Vì vậy, chúng tôi sẽ bắt đầu bằng việc giới thiệu về bản thân.

Tôi là Ben, Quan hệ nhà phát triển Android.

Các bạn đã nghe tôi nói một lần trong hội nghị này, nhưng hãy cùng xem qua ban hội thẩm.

Chào các bạn.

Tôi là Vinay, người hỗ trợ các nỗ lực phát triển công cụ AI tại Databricks.

Tôi rất vui khi được tham gia.

Xin chào, tôi là Luis Artola.

Tôi làm việc cho Google Maps.

Tôi lãnh đạo các nhóm sử dụng AI để xây dựng trải nghiệm tác tử và cải thiện chu kỳ phát triển phần mềm.

Chào bạn, tôi là Annyce Davis.

Tôi làm việc tại Ford.

Tôi lãnh đạo một số nhóm kỹ thuật phát triển các sản phẩm về gói thuê bao và chương trình khách hàng thân thiết.

Chào các bạn.

Tôi là Ty Smith.

Tôi làm việc tại Uber và hỗ trợ các nhà phát triển của chúng tôi.

Đó là thiết bị di động trong một thời gian rất dài.

Trong vài năm qua, chúng tôi đã tập trung rất nhiều vào giai đoạn mới mẻ và thú vị này khi có sự xuất hiện của các công cụ AI.

Chào các bạn.

Tôi là Kaushik Gopal.

Tôi là kỹ sư trưởng tại Instacart và tôi tình cờ bắt đầu podcast về phát triển Android có tên là Fragmented.

Như Ty đã nói, gần đây chúng tôi đã thay đổi chiến lược một chút và chúng tôi nói về việc phát triển AI.

Được rồi.

Chúng ta có 30 phút.

Tôi nghĩ thời gian sẽ trôi qua rất nhanh, nên chúng ta sẽ đi thẳng vào những câu hỏi hóc búa.

Chúng tôi luôn, bạn biết đấy, trong nhóm Quan hệ với nhà phát triển Android, chúng tôi luôn nói rằng chúng tôi muốn giúp việc xây dựng ứng dụng trở nên nhanh chóng và dễ dàng hơn.

Giờ đây, AI đã xuất hiện và như bạn biết, chúng tôi đã nói rằng: "Đúng vậy.

Chúng tôi cho rằng việc này giúp xây dựng ứng dụng nhanh chóng và dễ dàng hơn".

Nhưng tôi muốn đặt câu hỏi là liệu chúng ta có thực sự phát hành ứng dụng nhanh hơn hay chỉ đang tạo ra một loạt mã không đi đến đâu?

Bắt đầu thôi, Vinay.

Được rồi.

Đúng vậy, chúng tôi đều nhìn nhau.

Tuyệt vời.

Vì vậy, nếu chỉ nhìn vào những con số thuần tuý, chúng tôi chắc chắn thấy rằng kết quả về số lượng yêu cầu kéo, về số dòng mã, chúng tôi đã thấy sự tăng tốc đáng kể và kết quả là chúng tôi cũng đang gặp phải những thách thức về quy mô khi nói đến cả những thứ như nơi chúng tôi lưu trữ mã, phải không?

Và tốc độ tăng trưởng đó là có thật.

Điều chưa rõ ràng là mức độ tác động của quảng cáo đến kết quả, và tôi nghĩ rằng toàn ngành đang cố gắng tìm ra chỉ số phù hợp về kết quả, cách để biết mức độ tác động của quảng cáo đến lợi nhuận.

Nhưng tôi chắc chắn thấy được hiệu quả của nó.

Tôi nghĩ rằng chúng tôi đã phát hành nhiều mã hơn trong sáu tháng qua so với trước đây, và một lần nữa, tôi sẽ giữ điều này mơ hồ, nhưng giống như một khoảng thời gian rất dài.

Và kết quả là tôi nghĩ chiến lược của chúng tôi đã thay đổi về cách đo lường năng suất, đúng không?

Vì có nhiều cách để nghĩ về vấn đề này.

Chúng ta đang cố gắng tìm cách nâng mức trung bình, đúng không?

Vì khi xem xét các trường hợp ngoại lệ và giá trị trung vị, có sự chênh lệch từ 5 đến 10 lần giữa hai nhóm người này. Trọng tâm của chúng tôi là nâng cao mức tối thiểu, nâng cao giá trị trung vị và giúp những người đó làm việc hiệu quả như những người xung quanh mà chúng tôi thấy là làm việc hiệu quả.

Chúng ta thấy có nhiều vai trò kết hợp.

Một số người đang tiến nhanh hơn nhiều.

Có những người có hàng trăm PR mỗi ngày và họ đang làm những công việc đáng kinh ngạc.

Nhưng đó là một loại không gian mà họ đang hoạt động.

Có thể họ có nhiều cơ hội hơn hoặc họ thành thạo hơn với các công cụ.

Chúng tôi cũng thấy những người làm việc trong môi trường cũ hoặc trên nền tảng, và họ đang hỗ trợ một loại công việc khác có thể không được đẩy nhanh vì họ phải dành nhiều thời gian hơn cho việc đánh giá của con người và đảm bảo mọi thứ không bị hỏng.

Và sự kết hợp của hai yếu tố này, bạn biết đấy, nhanh hơn đáng kể so với trước đây, nhưng tôi nghĩ chủ đề thực sự thú vị đối với chúng ta là mặc dù chúng ta đang vận chuyển nhiều hơn, nhưng liệu doanh nghiệp có thực sự vận chuyển nhiều hơn đến người dùng cuối không?

Đó là lĩnh vực mà chúng tôi đã đầu tư trong năm qua để thực sự hiểu xem liệu chúng tôi có đang phát hành các tính năng nhanh hơn hay không, chứ không chỉ là phát hành mã nhanh hơn.

Các tín hiệu ban đầu cho thấy chúng tôi đang làm được điều đó, nhưng cách tiếp cận này rất khác so với việc chỉ gửi PR thuần tuý.

Tôi nghĩ rằng điều đã xảy ra là, rõ ràng là mọi người đang vận chuyển rất nhiều, bạn biết đấy, số lượng PR, số lượng đã tăng lên.

Nhưng tôi nghĩ ngay cả bây giờ, nhiều người vẫn nghĩ rằng: "Làm thế nào để chúng ta sử dụng AI và công cụ này để tăng tốc các quy trình hiện có?"

Đúng không?

Trước đây, khi phát hành mã, chúng tôi luôn nghĩ rằng con người là người sẽ đưa mã vào giai đoạn phát hành chính thức.

Nhưng tôi nghĩ những gì chúng ta đang thấy hiện nay là, đúng vậy, cách đó có hiệu quả.

Chúng tôi đang vận chuyển thêm.

Nhưng chúng ta đang gặp phải mọi điểm tắc nghẽn mà trước đây chúng ta chưa từng thấy, đúng không?

Vì trước đây chúng tôi chưa từng gặp phải những vấn đề đó, nhưng giờ đây, chúng tôi đang tăng tốc một phần của một chu trình gồm nhiều bước, và tôi nghĩ đó là lúc mọi thứ trở nên thú vị, kiểu như: "Được rồi.

Chúng tôi đang cung cấp nhiều hiệu ứng hơn, nhưng giờ đây, các hiệu ứng này giống như một vòi cứu hoả."

Vì vậy, chúng tôi đang gặp phải những thách thức khác.

Đó là một điểm rất thú vị, phải không, vì khi bạn nghĩ về nó, có nhiều bước khác nhau, nhưng từ góc độ cấp cao, bạn có thể chia chúng thành ba giai đoạn, phải không?

Có lập trình, rõ ràng là đang được tăng tốc.

Có mức độ sẵn sàng phát hành công khai, bao gồm một số yếu tố như pháp lý, quyền riêng tư và những yếu tố giúp bạn phát hành sản phẩm, sau đó là ra mắt, đúng không?

Và sau đó, vận chuyển thực sự có nghĩa là những điều khác nhau tùy thuộc vào nơi bạn đang ở, phải không?

Nếu bạn là một sản phẩm hoàn toàn phía máy chủ, có lẽ việc vận chuyển có nghĩa là một quy trình hợp lý hơn, trong khi khi bạn vận chuyển thứ gì đó đến người tiêu dùng, phải không, giống như việc đưa thứ đó vào thử nghiệm giống như giữa hành trình, phải không?

Bạn vẫn phải thử nghiệm và đo lường rất nhiều, và đó là lý do khiến bạn cảm thấy như đang ở trong một khu đô thị, trên đường cao tốc và gặp phải một điểm tắc nghẽn, sau đó bạn bắt đầu tăng tốc và cảm thấy "Tuyệt vời.

Tôi đang đi rất nhanh", nhưng giờ bạn lại gặp phải điểm tắc nghẽn tiếp theo.

Và điều mà AI đang làm rõ là bạn đang thấy các điểm ma sát rõ ràng hơn, và một số điểm trong số đó không liên quan gì đến lập trình hoặc công nghệ.

Vấn đề này liên quan đến quy trình, con người và cách bạn tối ưu hoá quy trình đó bằng AI.

Đó là một thách thức thực sự thú vị về cách tinh giản quy trình từ đầu đến cuối.

Một cách thú vị mà chúng tôi đang nghĩ đến là người hoặc nhóm đó có bao nhiêu quyền tự quyết trong việc triển khai đầy đủ?

Vì vậy, nếu nhìn vào nội bộ, bạn biết đấy, có rất nhiều nhóm có thể đang xây dựng các công cụ nội bộ hoặc những thứ không được cung cấp cho khách hàng.

Họ vận chuyển nhanh hơn nhiều, đúng không?

Họ có toàn quyền đưa thông tin đó đến khách hàng ngay lập tức.

Nếu bạn có một sản phẩm bên ngoài và vẫn phải thử nghiệm với người dùng, hoặc bạn biết đấy, thời gian phát hành trên cửa hàng ứng dụng, hoặc bạn biết đấy, làm việc với bộ phận thiết kế và sản phẩm, thì tất cả những điểm tắc nghẽn khác này sẽ cộng dồn lại và những người viết mã sẽ có ít quyền tự quyết hơn để đẩy nhanh tiến độ.

Và vì vậy, họ chỉ đang gặp phải những điểm tắc nghẽn còn lại trong hệ thống.

Vì vậy, tôi nghĩ việc chia thành hai lĩnh vực riêng biệt thực sự làm nổi bật những điểm mà bạn có thể cải thiện quy trình kinh doanh của mình.

Đúng vậy, tôi đồng ý và tôi cảm thấy thành thật mà nói, kỹ thuật chưa bao giờ là điểm nghẽn.

Tôi đã nói điều này nhiều năm rồi.

Kỹ thuật có cách làm việc rất chặt chẽ và luôn xuất phát từ doanh nghiệp, "Vấn đề là gì?"

Bạn sẽ nhận được 10 câu trả lời khác nhau cho câu hỏi đó.

Sau đó, "Được rồi.

Bây giờ, hãy chuyển những điều đó thành một số giải pháp cho sản phẩm.

Bây giờ, hãy suy ngẫm về điều đó một chút.

Ồ, hãy nói chuyện với nhóm thiết kế một chút.

Đá bóng sang bên kia đi."

Đến khi chuyển sang giai đoạn kỹ thuật, chúng tôi ít nhiều đã biết mình cần làm gì.

Sau đó, chúng ta chỉ cần truy cập Stack Overflow, sao chép và dán một số nội dung rồi phát hành sản phẩm.

Vì vậy, với AI, tôi thấy tốc độ tăng nhanh nhất là trong công việc tuân thủ.

Những việc mà chúng tôi luôn muốn hiện đại hoá XYZ, hoặc chúng tôi luôn muốn nhanh chóng nâng cấp phiên bản Spring Boot.

Chúng tôi đang làm việc đó rất nhanh.

Nhưng về việc phân phối tính năng thực tế, tôi không thể nói rằng tôi thực sự thấy sự cải thiện đáng kể.

Như vậy, các bạn đều đã đề cập đến việc có thể điểm tắc nghẽn đã thay đổi và các bạn đang gặp phải những quy trình trước đây không thực sự là điểm tắc nghẽn, nhưng giờ lại là điểm tắc nghẽn.

Ngoại trừ những quy trình có thể xuất phát từ những bài học khó khăn trong quá khứ, phải không?

Vậy bạn có cảm thấy áp lực khi phải thay đổi những điều đó không? Tôi nghĩ điều rõ ràng nhất là việc xem xét mã.

Chúng ta nghĩ gì về tương lai của quy trình xem xét mã?

Chúng tôi đang làm gì?

Tôi rất muốn nghe ý kiến của bạn.

Bạn biết đấy, điều này quay lại điểm mà tôi đã nêu.

Tôi cảm thấy nhiều điểm tắc nghẽn này là do chúng ta nghĩ rằng, nếu bạn có một cây đũa thần, và bạn có thể tái tạo kỹ thuật phần mềm, và bạn có AI ngày nay, thì liệu chúng ta có sử dụng nhiều thứ giống nhau không? Chúng ta có làm những việc giống nhau không?

Ví dụ: chúng tôi cần người xem xét mã để phê duyệt, tức là thực hiện bước kiểm tra chéo cuối cùng.

Tôi nghĩ điều đó cũng đang thay đổi, chẳng hạn như, bạn biết đấy, cách chúng ta nghĩ về việc xem xét mã hiện nay là, có lẽ chúng ta nên cởi mở với ý tưởng rằng, bạn biết đấy, nếu bạn đang cải tiến tên hoặc bạn đang cố gắng cải tiến mã và bạn biết rằng bạn có các bài kiểm thử tuyệt vời, điều mà mọi người rõ ràng đều có.

Chúng tôi đã có AI viết chúng, không sao đâu.

Không, có thể là, bạn biết đấy, bạn có làm tốt hơn nhiều so với nhân viên hỗ trợ đó không?

Tôi không biết, có lẽ chỉ là không dành thời gian xem xét việc đó.

Mặt khác, nếu bạn sắp phát hành một lỗi và bạn nhận được cuộc gọi từ CEO của mình, về cơ bản là nói rằng, "Này, lỗi này đang khiến chúng ta mất X đô la", thì có thể xác định các khu vực và hệ thống như, "Này, đây là một khu vực quan trọng.

Đây không phải là một khu vực quan trọng", sau đó thử hình dung lại.

Tôi không nghĩ đó là cách chúng ta hoạt động hiện nay, đúng không?

Ngày nay, mọi người sẽ nói: "Này, có một PR.

Tôi là kỹ sư.

Tôi đang tập trung vào việc này.

Nó sẽ tăng lên.

Tôi nhờ Vinay xem xét mã vào lúc nửa đêm vì tôi chỉ muốn hợp nhất mã này."

Ngược lại, có lẽ chúng ta nên cân nhắc lại nhiều điều trong số đó.

Tôi hoàn toàn đồng ý và tôi coi việc xem xét mã là một vấn đề xác minh. Ý tôi là trong một thế giới mà tôi hoàn toàn tin tưởng vào khả năng xác minh của mình, liệu tôi có còn xem xét mã 100% PR của mình không?

Có lẽ là không, đúng không?

Vì vậy, việc xem xét mã có hai mục đích.

Một là xác minh rằng chúng tôi đang làm đúng, và hai là giáo dục, đúng không?

Chẳng hạn như những người xung quanh bạn biết bạn đang làm gì và liệu họ có đồng ý với quyết định đó hay không.

Vì vậy, chắc chắn có một loại công việc mà chúng ta nên cảm thấy thoải mái khi đẩy nhanh tiến độ và đảm bảo rằng công việc đó được đưa vào mã và thậm chí là các bản phát hành.

Giờ đây, điều này có thể không áp dụng cho 100% trường hợp, nhưng tôi nghĩ rằng nó nên áp dụng cho một con số rất cao, có hai chữ số.

Và tôi nghĩ chúng ta đang chuẩn bị sẵn sàng để thực hiện những thay đổi đó và tất cả chúng ta, với tư cách là một cộng đồng, cần đảm bảo rằng hệ thống của chúng ta đã sẵn sàng cho điều đó, vì điều đó sắp xảy ra.

Không có cách nào khác.

Phần đầu phễu rất rộng với nhiều nền tảng, giúp bạn tạo thêm nhiều PR.

Và tốc độ của bạn sẽ bằng với tốc độ của bước chậm nhất trong quy trình.

Và đối với nhiều nhóm, đó là quy trình xem xét mã. Những nhóm đang phát triển nhanh hơn đã thực sự hiểu và chấp nhận thực tế này.

Đúng vậy, và nếu thành thật với bản thân, tôi muốn nói rằng 70% PR mà tôi thấy đều có vẻ ổn.

Ví dụ: nếu chúng ta tìm kiếm tất cả toàn bộ mã nguồn trên thế giới, thì các nhận xét về PR sẽ chỉ là "looks good to me" (tôi thấy ổn), LGTM, trên toàn bộ bảng.

Vì vậy, một phần là do với tư cách là các chuyên gia kỹ thuật, đôi khi chúng ta tự cho mình nhiều công lao hơn mức xứng đáng.

Chúng tôi thực sự nghĩ rằng chúng tôi đang ở trong đó.

"Họ có sử dụng mẫu lệnh không?"

Không, chúng tôi chỉ nói: "Được thôi.

Ừ, tôi thấy ổn."

Vậy tại sao tôi không thể nhờ một tác nhân làm việc đó?

Tôi thực sự nghĩ rằng đó là tương lai mà chúng ta sẽ thấy, nơi mà những gì trông có vẻ tốt đối với tôi, như kiểu đặc điểm là gì, hành vi nào khiến bạn cảm thấy như vậy?

Sau đó, hãy đảm bảo rằng nhân viên hỗ trợ cũng tìm kiếm thông tin tương tự.

Hoặc ngược lại, cũng nên thử nghĩ đến nhiều cách đánh giá khác nhau, đúng không?

Giống như tôi biết những người đang dùng Twitter hiện nay, họ nói điều này, phải không?

Chẳng hạn như khi bạn xác minh một yêu cầu kéo, hãy yêu cầu tác nhân của bạn trực quan hoá yêu cầu đó theo một cách khác, đúng không?

Này, cho tôi xem ảnh trước khi chỉnh sửa.

Cho tôi xem kết quả sau khi dọn dẹp.

Hãy cho tôi xem các bài kiểm thử bạn đã viết thay vì xem xét mã từng dòng một.

Nhưng nó thách thức Bạn định nói gì à, Luis?

Không, tôi nghĩ đây là một điều đáng suy ngẫm, đúng không?

Như vậy, chúng ta sẽ đạt đến mức mà bạn cảm thấy thực sự thoải mái khi để CL hoặc PR được thông qua mà không cần con người can thiệp.

Tôi sẽ đóng vai người phản biện một chút và tôi muốn nói rằng khi nói về rào cản, tôi nghĩ mọi người có xu hướng cho rằng rào cản là xấu, nhưng thực ra có rào cản tốt và rào cản xấu.

Và tôi nghĩ rằng tôi cảm thấy các bài đánh giá vẫn nằm trong danh mục rào cản tích cực.

Vấn đề là làm thế nào để giảm bớt gánh nặng cho nhà phát triển, đúng không?

Và đôi khi, vấn đề không phải là làm thế nào để chúng tôi cải thiện hoặc tăng hiệu quả cho quy trình xem xét đó tại thời điểm đó.

Đó là cách bạn có thể sử dụng AI để giúp quá trình phát triển ngược dòng trở nên chính xác hơn, đúng không?

Bởi vì nếu bạn chỉ... Tuỳ thuộc vào cách bạn sử dụng AI, chẳng hạn như dữ liệu đầu vào tốt sẽ tạo ra kết quả tốt hơn, nhưng dữ liệu đầu vào kém sẽ tạo ra kết quả thực sự tệ, đúng không?

Vì vậy, tôi nghĩ rằng để đạt được trạng thái cuối cùng hấp dẫn đó, chúng ta phải cải thiện toàn diện quy trình bằng AI ngay từ đầu, sử dụng AI để hiểu rõ hơn về cấu trúc, có các thông số kỹ thuật thực sự vững chắc mà không cần nhà phát triển phải nỗ lực nhiều, nhờ đó mã mà AI tạo ra sẽ có chất lượng cao hơn.

Do đó, quy trình xem xét sẽ ít gây trở ngại hơn cho nhà phát triển.

Tôi nghĩ rằng kết quả cuối cùng của việc này sẽ không gây tranh cãi nhiều, vì hầu hết mọi người đều thấy rằng tất cả mã này cuối cùng sẽ được đưa vào mà không cần con người xem xét.

Tôi nghĩ trong thời gian chờ đợi, chúng ta đang ở trong tình huống phát triển, nơi các mô hình đang trở nên tốt hơn và chúng ta ít lo lắng hơn về việc chúng mắc lỗi kỹ thuật, mà lo lắng hơn về việc chúng mắc lỗi kinh doanh hoặc phán đoán hoặc ý tưởng đưa vào đó là vấn đề.

Và do đó, tín hiệu này cũng sẽ được đưa vào giai đoạn xem xét để bạn tách riêng.

Chẳng hạn như chúng ta nên xem xét từng dòng trong PR hay xem xét mục đích mà họ đang cố gắng đạt được?

Chúng tôi đang nghĩ đến một vài cách khác nhau.

Một là làm thế nào để cung cấp thông tin phù hợp hơn cho người dùng để họ có thể bắt đầu ưu tiên thông tin đó?

Mặt khác, đâu là những lĩnh vực an toàn hơn để chúng tôi có thể thử nghiệm và tiến nhanh hơn trong các chương trình như thế này?

Như Kaushik đã nói, không phải lĩnh vực nào cũng cần mức độ nghiêm ngặt như nhau.

Chúng tôi có thể xác định điều này và có thể bắt đầu cho phép một số mô hình phát triển nhanh hơn, giảm rủi ro trong khi vẫn duy trì, bạn biết đấy, những lĩnh vực thiên về tuân thủ hơn hoặc, bạn biết đấy, rất cơ bản với mức độ ma sát cao hơn cho đến khi chúng tôi thực sự đạt đến điểm tin tưởng không chỉ các mô hình mà còn cả dữ liệu đầu vào cho các mô hình đó

Là những quyết định đúng đắn.

Chẳng hạn như việc tái cấu trúc mô-đun Android mới trong ứng dụng Uber, có thể là được.

Cho tất cả nhà phát triển Android đi xe miễn phí, có lẽ nên kiểm tra mã đó.

Tôi sẽ phải kiểm tra vấn đề đó với Giám đốc điều hành của chúng tôi.

Xin lỗi Kaushik.

Nhưng tôi cũng nghĩ rằng đây là một vấn đề đã được giải quyết.

Chúng ta đã có các cờ tính năng tương tự.

Chúng tôi đã có quy trình triển khai xanh lam-xanh lục.

Chúng tôi đã có nhiều mảnh ghép.

Thách thức là chúng tôi quá bận rộn để thực sự làm điều đó.

Chúng tôi đã có tính năng theo dõi hành vi.

Chúng tôi có tất cả những dữ liệu này, nhưng chúng lại nằm trong nhiều hệ thống khác nhau.

Chúng tôi đã theo dõi các sự cố.

Chúng ta có rất nhiều dữ liệu, nhưng việc kết hợp tất cả dữ liệu đó thành một dấu vết toàn diện là điều còn thiếu.

Khi cuối cùng chúng ta tìm ra được dịch vụ bối cảnh kỹ thuật đó trông như thế nào trên tất cả các công ty khác nhau này, thì chúng ta không cần phải lo lắng nữa vì ngay cả khi PR vừa được hợp nhất, thì nó vẫn an toàn.

Vì chúng tôi biết rằng chúng tôi đã đặt tính năng đó sau một cờ tính năng.

Chúng tôi có mô hình triển khai xanh dương-xanh lục.

Chúng tôi có đầy đủ khả năng ghi nhận.

Sau đó, bạn có thể tự tin nói rằng: "Ồ, hãy đưa ý tưởng đó vào quy trình sản xuất".

Nếu có chuyện gì xảy ra, chúng tôi có tất cả các biện pháp bảo vệ và rào chắn này trong suốt quá trình.

Tôi nghĩ tốc độ phản hồi cũng rất quan trọng, đúng không?

Nếu bạn biết, hãy chọn Android trong một phút, nếu bạn đang đưa ra một thay đổi trong Android và thay đổi đó cần được cung cấp thông qua Cửa hàng Play rồi triển khai cho người tiêu dùng, thì khả năng khắc phục sự cố ngay lập tức của bạn thực sự bị hạn chế so với việc bạn đang làm một việc có triển khai nội bộ với khả năng ghi nhận nội bộ và một tác nhân có mặt ngay lập tức, bạn có nhiều cơ hội hơn để di chuyển nhanh hơn ở đó.

Vì vậy, một trong những câu hỏi mà tôi dành cho các bạn là cũng có vấn đề là có công việc cần phải thực hiện trên các ứng dụng này, nhưng sau đó bạn có các ứng dụng mới dễ dàng hơn, sau đó bạn có các ứng dụng cũ, và sau đó có thời điểm bạn cần thời gian để thực hiện nhiều bước kiểm tra này, bạn biết đấy, để có thể phổ biến việc sử dụng AI.

Tôi biết nhiều người trong số các bạn làm việc trên các ứng dụng lớn, đúng không?

Vậy nên, tôi tò mò muốn biết bạn nghĩ thế nào về vấn đề này?

Có phải là kiểu: "Này CEO, cho tôi 3 tháng để chuẩn bị ứng dụng này cho AI", hay là thêm vào mỗi ngày?

Vâng.

Dù sao thì họ cũng không bao giờ làm vậy.

Tôi không nghĩ vậy.

Ý tôi là, hầu hết các công ty sẽ không bao giờ có được sự xa xỉ đó.

Tôi nghĩ chúng ta chỉ cần dành thời gian cho việc này giống như cách chúng ta từng làm với nợ kỹ thuật, tức là dành 20% thời gian cho việc này, và dành 5% trong số đó để cải thiện câu lệnh.

Và sau đó, thậm chí còn hiểu được câu lệnh làm gì và cải thiện bối cảnh.

Như chúng ta đã thảo luận, tôi nghĩ phần lớn là do các kỹ sư vẫn chưa hiểu cách hoạt động của công nghệ này.

Họ vẫn cảm thấy công nghệ này rất kỳ diệu và huyền bí, nên họ không định cấu hình và điều chỉnh công nghệ này theo cách có thể giúp họ khai thác giá trị và hiệu quả tốt nhất.

Vì vậy, tôi nghĩ rằng các nhà lãnh đạo cần phải đặt ra câu hỏi: "Chúng ta cần làm gì để nâng cao năng lực cho đội ngũ của mình để họ có thể hiểu cách thức hoạt động của công nghệ này, từ đó chúng ta có thể đạt được nhiều thành tựu hơn?"

Đó cũng là sự tiếp nối của nó.

Vì công nghệ này thay đổi rất nhanh, nên nếu tôi yêu cầu một nhóm dành một tuần ngay bây giờ để tìm hiểu những điều mới nhất và hay nhất, rồi áp dụng vào thực tế, sau đó họ không có thời gian để tiếp tục tìm hiểu hoặc thử nghiệm, và chúng tôi kiểm tra lại vào năm sau, thì họ sẽ bị tụt hậu đáng kể so với những khả năng mới.

Vì vậy, chúng ta cần phải, bạn biết đấy, chúng ta đang vừa bay vừa chế tạo máy bay, vừa đặt ra các rào chắn, vừa học hỏi và điều chỉnh khi mọi thứ diễn ra, và các nhóm cần phải nắm bắt được điều này.

Và tại các tổ chức lớn, có những nhóm như một số nhóm của chúng tôi cố gắng chắt lọc một số thông tin đó và làm cho thông tin đó dễ hiểu và dễ tiếp thu hơn.

Nhưng đây là thách thức cho mọi người trong ngành hiện nay.

Tôi muốn thay đổi một chút.

Nhiều người trong số các bạn làm việc trong lĩnh vực cơ sở hạ tầng cho nhà phát triển.

Hàng nghìn PR, có phải cơ sở hạ tầng thử nghiệm, máy chủ của bạn, tất cả đều đang quá tải?

Và tôi rất muốn nghe một số câu chuyện về trận chiến.

Ty?

Có.

Họ đang làm rất tốt.

CI của tôi khóc đến s- khóc tôi khóc tôi ngủ mỗi đêm.

Hầu hết các nhóm cơ sở hạ tầng dành cho nhà phát triển của chúng tôi hiện đang phải giải quyết các vấn đề về quy mô trong việc tính toán và các vấn đề về hiệu quả.

Có, bạn biết đấy, mã đỏ đang diễn ra.

Họ thấy khối lượng tăng lên rất nhiều.

Chúng tôi đang thực hiện các thay đổi về cấu trúc đối với tác nhân.

Chúng tôi đang cố gắng thực hiện những việc như mở rộng khả năng thực thi và lưu vào bộ nhớ đệm của bản dựng từ xa bằng Bazel nhanh nhất có thể, xem xét những việc như làm thế nào để tất cả các nhánh chính luôn hoạt động tốt, hoặc liệu chúng tôi có thể bắt đầu sửa lỗi chuyển tiếp bằng các tác nhân trong một số khu vực nhất định hay không, xem xét khối lượng công việc đến từ các kỹ sư, cố gắng thực hiện những việc như CI tự khắc phục hoặc giảm vòng hồi tiếp, và tất cả các nhóm đều đang tích cực đầu tư vào tất cả những việc này để cố gắng theo kịp tốc độ tăng trưởng trong khi vẫn duy trì được một mức hiệu quả nhất định.

Nhưng đây là một việc cực kỳ khó khăn.

Tôi đồng ý với mọi điều Ty vừa nói, nhưng tôi nghĩ điều này cũng buộc chúng ta phải suy ngẫm và tự hỏi một cách trung thực rằng nếu chúng ta tăng gấp 10 lần từ thời điểm này trở đi, liệu chúng ta đã sẵn sàng chưa?

Và đối với hầu hết mọi người, câu trả lời có lẽ là không.

Do đó, khi nghĩ về tương lai, chúng tôi đang cố gắng điều chỉnh tham vọng của mình cho phù hợp với quy mô mà cơ sở hạ tầng có thể hỗ trợ.

Và một điều mà AI đã làm được là giúp tất cả chúng ta trở nên tham vọng hơn vì chúng ta đã thấy được bước nhảy vọt có ý nghĩa đó, và vì vậy, chúng tôi thực sự đang xem xét lại hệ thống của mình.

Đúng vậy, chúng tôi đang nghĩ xem hệ thống nào khác sẽ gặp sự cố hoặc chúng tôi dự đoán sẽ gặp sự cố và chúng tôi có thể làm gì để đón đầu sự cố đó để không bị bất ngờ?

Và trên thực tế, chúng tôi đang cố gắng tránh những điều bất ngờ.

Đúng vậy, miễn là chúng ta cảm thấy mình nắm quyền kiểm soát, thì ai cũng vui.

Tôi biết rằng khi chúng tôi gặp phải một điều bất ngờ, đó sẽ là tin xấu cho mọi người.

Đúng không?

Vì vậy, đây là thời điểm thích hợp để suy ngẫm, nhìn lại, kiểm tra và tìm ra điều gì sẽ xảy ra tiếp theo, vì điều đó chắc chắn sẽ xảy ra.

Điều này là không thể tránh khỏi.

Chúng tôi chỉ muốn giải quyết trước vấn đề này.

Tôi đã nghe một câu nói thú vị của Giám đốc điều hành Inflow.

Cô ấy đang mô tả rằng đây là dòng thời gian mà Google cần để đạt được, bất kể, hàng tỷ dòng mã mà họ đang có và, bạn biết đấy, mất khoảng 20 năm, và với sự tăng tốc của điều này, rất nhiều công ty của chúng ta sẽ xem xét quy mô tương tự chỉ trong một vài năm ngắn ngủi, dựa trên sự tăng tốc của AI.

Và tôi không nghĩ rằng tất cả các công ty đều sẵn sàng có cơ sở hạ tầng cấp Google để phát triển.

Vậy thì về chủ đề đó, công ty của bạn có áp dụng hạn mức chi tiêu nào không?

Ví dụ: làm thế nào để quản lý một số nhà phát triển chỉ sử dụng mã thông báo cho mọi thứ, bạn biết đấy, luôn sử dụng mô hình tốt nhất có thể.

Ví dụ: bạn có tìm thấy chiến lược nào không, hay tốt hơn là cứ để họ tự do vì thử nghiệm sẽ mang lại kết quả tốt đẹp?

Tôi cho rằng năm ngoái là năm thử nghiệm.

Làm mọi việc.

Và có lẽ ngay cả nửa đầu năm nay cũng chỉ là sử dụng một cách hợp lý.

Và giờ đây, kể từ tháng 9, chúng tôi có giới hạn về mã thông báo.

Vì vậy, chúng tôi có giới hạn về mức sử dụng mã thông báo cho nhà phát triển.

Và sau đó, chúng tôi có các công cụ đo lường để họ có thể hiểu được, chẳng hạn như, bạn có đang có những phiên hoạt động tốt, lành mạnh không?

Thế nào là một phiên hoạt động lành mạnh?

Bạn có số lượt tương tác mỗi phiên nhiều như vậy không?

Lượt chơi là gì?

Vì vậy, chúng tôi thực sự đang cố gắng sử dụng công cụ này để hướng dẫn các nhà phát triển.

Tôi nghĩ đó chỉ là bước đầu tiên.

Bạn biết đấy, bạn phải biết mình gặp vấn đề thì mới có thể khắc phục.

Và vì vậy, ít nhất họ cũng thấy rằng việc này không miễn phí.

Trước đây, AI thực sự mang lại cảm giác miễn phí.

Và mọi người chỉ việc sử dụng.

Tôi muốn "Thay đổi chi nhánh", kiểu như "Ồ, không sao đâu Annyce, tôi sẽ đổi chi nhánh đó cho bạn, 5 đô la", đúng không?

Giờ thì chúng ta đang tiến đến giai đoạn mà bạn có thể nghĩ: "Được rồi, tôi có thể chuyển đến dòng lệnh và tự làm việc đó, đúng không?"

Vì vậy, tôi nghĩ rằng chúng ta sẽ bắt đầu đào tạo các kỹ sư về chi phí thực tế.

Tôi sẽ không chỉ khởi động các phiên bản ECS rồi bỏ mặc chúng.

Có thể khi AWS mới ra mắt, chúng ta đã nghĩ: "Ừ, mình có thể tự tạo phiên bản của riêng mình".

Và chúng tôi đã khiến công ty tốn rất nhiều tiền.

Tôi nghĩ điều tương tự cũng đang xảy ra với mã thông báo.

Tôi nghĩ rằng những giới hạn thực tế cũng mang lại những cơ hội thực sự thú vị, phải không?

Vì khi nghĩ về cách chúng ta bắt đầu sử dụng LLM, bạn sẽ đưa mọi thứ vào đó, đúng không?

Chúng sẽ tự kiểm tra mã, tìm ra vấn đề và làm những điều kỳ diệu cho bạn, phải không?

Nhưng điều đó cũng có cái giá của nó.

Và chúng tôi thực sự – bạn biết đấy, ngành này đang nhận ra điều đó.

Và điều đó thực sự buộc các nhà phát triển và tổ chức phải suy nghĩ về cách tối ưu hoá, đúng không?

Lý do là, chẳng hạn như, tôi sẽ đưa ra một ví dụ cụ thể: Nếu bạn có một trình tạo đang tạo các thành phần giao diện người dùng và các thành phần đó cần tuân thủ một cấu trúc cụ thể, các bài kiểm thử đơn vị và những thứ tương tự, thì tại sao bạn lại để các mô hình tạo ra các thành phần đó ngay lập tức, nếu bạn thực sự có thể để mô hình tạo ra một công cụ thuật toán tất định mà họ có thể chỉ cần tạo ra các thành phần đó cho bạn, đúng không?

Vì vậy, ngay tại đó, có rất nhiều cơ hội để sử dụng giới hạn của mã thông báo và mức sử dụng để mang lại lợi thế cho bạn và thực sự trở nên hiệu quả hơn.

Đúng vậy, và theo những chủ đề đó, chúng tôi chắc chắn đã đưa ra các giới hạn, ít nhất là như bạn biết, tại Instacart.

Nhưng tôi nghĩ mục tiêu không nhất thiết là hạn chế mức độ sử dụng AI, mà là để tạo ra một thói quen lành mạnh, hoặc như bạn nói, là để tự nhìn nhận lại, đúng không?

Chẳng hạn như khi nào bạn nên sử dụng một số mô hình nhất định thay vì các mô hình khác.

Bạn biết đấy, có lẽ bạn không cần đến Fable hay Astra để biết giờ hoặc thay đổi một nhánh Git.

Đúng không?

Bạn có thể dành chút thời gian để viết một tập lệnh và tập lệnh đó sẽ miễn phí mãi mãi.

Không lãng phí mã thông báo.

Đúng không?

Vì vậy, tôi nghĩ nếu bạn có thể thêm một số loại ràng buộc không nhất thiết phải giới hạn việc sử dụng, mà là để giúp bạn suy nghĩ xa hơn, thay vì chỉ dồn mọi thứ vào đó.

Đúng không?

Tôi thích ý kiến của bạn, năm ngoái giống như một năm thử nghiệm.

Năm nay, câu hỏi đặt ra là làm thế nào để sử dụng công cụ này một cách hiệu quả?

Vâng.

Chúng tôi cũng rất đồng cảm với những câu chuyện ở đây.

Đặc biệt là khi chuyển từ việc thử nghiệm nhiều hơn sang, bạn biết đấy, một bộ hiệu quả và trách nhiệm giải trình cân bằng.

Khoản tiền này đến từ nhiều khoản đầu tư.

Có những thứ như giáo dục cho các nhà phát triển và khả năng hiển thị.

Bạn biết đấy, như Annyce đã nói về chi phí và thông tin của phiên hoạt động.

Đầu tư vào các chế độ mặc định an toàn, giúp tránh các hoạt động tương tác lãng phí, đảm bảo rằng các kỹ năng mà họ đang sử dụng là hiệu quả, tìm kiếm các lỗi hồi quy và những vấn đề tương tự.

Và chịu trách nhiệm về chi phí mà họ đang chi tiêu.

Vì vậy, bạn biết đấy, chúng tôi có giới hạn về số lượng token.

Và khi nhà phát triển đạt đến các giới hạn đó, họ có thể nhấp vào một nút và đưa ra lý do, sau đó người quản lý của họ có thể phê duyệt.

Vì vậy, nếu có những tác phẩm hay, chúng tôi muốn họ xem những tác phẩm đó.

Nhưng nếu họ làm điều gì đó lãng phí hoặc mang tính thử nghiệm hơn, họ không thể giải thích cho người quản lý lý do tại sao họ nên chi tiền cho việc đó, thì điều này cũng giúp họ kiểm soát được việc đó.

Và điều đó không chỉ giúp giảm bớt công việc, mà còn giúp chúng ta xem xét và đánh giá xem đây có phải là lựa chọn mô hình phù hợp hay không.

Đây có phải là trọng lượng phù hợp không?

Rõ ràng là chi phí của các mã thông báo này đã bắt đầu giảm do một số áp lực cạnh tranh.

Nhưng nhìn chung, việc các kỹ sư của chúng tôi chỉ nghĩ về việc sử dụng hiệu quả số tiền mà chúng tôi cung cấp cho họ, theo tôi, là cách tiếp cận đúng đắn và lành mạnh vào lúc này.

Và về lâu dài, chúng tôi có thể loại bỏ hoàn toàn quyết định đó khỏi họ.

Đúng không?

Bạn muốn có tính năng định tuyến mô hình tự động và những tính năng tương tự, để người dùng không bao giờ phải bận tâm về việc đó.

Nhưng trong thời gian chờ đợi, đây là một trạng thái tốt.

Vâng.

Tôi nghĩ rằng chúng tôi tập trung nhiều vào việc thực hiện những việc như bộ định tuyến mô hình để chúng tôi đưa ra quyết định đó thay cho nhà phát triển và cố gắng ánh xạ quyết định đó đến đúng mô hình, ánh xạ nhiệm vụ đến mô hình.

Nhưng điều quan trọng là phải có các biện pháp cảnh báo phù hợp.

Vì vậy, chúng tôi xem xét giới hạn về mã thông báo theo một số cách.

Chúng tôi không bao giờ muốn chặn nhà phát triển.

Tuy nhiên, chúng tôi muốn đảm bảo rằng có những thời điểm chúng ta có thể tạm dừng một chút để đảm bảo rằng ngân sách được chi tiêu cho đúng lĩnh vực và đúng cách.

Ví dụ: chúng tôi có giới hạn hằng ngày, chỉ để làm rào cản mà nhà phát triển có thể tự gỡ bỏ.

Họ chỉ cần truy cập vào cổng thông tin, nhấp vào một nút và nói: "Này, tôi Không có gì bất ngờ xảy ra.

Tôi nắm quyền kiểm soát."

Đúng không?

Và đó chỉ là một đòn bẩy đơn giản vì mọi người đều đang lặp lại và các vòng lặp này có thể chạy qua đêm và chúng tôi không muốn điều này làm tăng chi phí.

Vì vậy, điều này rất hợp lý.

Mặt khác, chúng tôi cũng muốn đảm bảo rằng các nhà phát triển có thể sử dụng những mô hình tốt nhất.

Nhưng đối với danh mục mô hình đó, chúng tôi đã tạo một ngân sách tối tân.

Do đó, bạn cần đặt ngân sách hằng tháng.

Nó đủ cao.

Bạn không bị chặn.

Nếu cần được bỏ chặn, bạn có thể thực hiện quy trình ngoại lệ.

Được gửi đến người quản lý của bạn.

Đó là khoảnh khắc bạn mô tả những việc mình đang làm.

Và chúng tôi không phải là người ra quyết định với tư cách là một nhóm nền tảng, vì những quyết định đó phải gần với nơi công việc đang diễn ra.

Về việc sử dụng mô hình tiên phong, chúng tôi cũng cho phép bạn linh hoạt hoàn toàn trong một hạn mức.

Và lý do cách này hiệu quả là vì cuối cùng, cách này giúp chúng ta dự đoán được quy trình.

Đúng không?

Chúng tôi muốn đảm bảo rằng khi lập ngân sách cho việc chi tiêu mã thông báo (đây là một thách thức đối với mọi người), chúng tôi đã tính đến những gì chúng tôi dự định và những đòn bẩy này cho phép chúng tôi làm điều đó.

Bạn có biết điều gì khiến tôi thấy thú vị trong những cuộc trò chuyện này không?

Tôi nghĩ là vì tất cả chúng ta đều làm việc tại các công ty.

Và vì vậy, các doanh nghiệp.

Vì vậy, chúng ta phải trả phí cho từng mã thông báo.

Đúng không?

Nhưng có một khía cạnh khác của Internet, nơi mọi người sử dụng mô hình định giá theo gói thuê bao.

Vì vậy, đối với họ, đó là một phép tính rất khác.

Đúng không?

Nhưng tôi nghĩ bạn biết rằng, vấn đề chỉ là thời gian trước khi bạn biết mọi người đều ở cùng một vị trí, nơi bạn phải bắt đầu suy nghĩ về từng mã thông báo.

Và đó là lúc, bạn biết đấy, có lẽ chúng ta sẽ phải chịu trách nhiệm nhiều hơn, giống như những gì chúng ta phải làm ngay bây giờ trong các công ty.

Hoặc bạn làm việc tại một phòng thí nghiệm tiên phong, nơi bạn có ngân sách không giới hạn.

Sau đó, bạn chỉ cần tiếp tục vận hành và tạo ra nhiều cách làm việc thú vị dựa trên AI, như những cách mà bạn thấy trên Twitter.

Tất cả các công ty của chúng tôi đều muốn làm theo, nhưng họ không muốn chi tiêu số token mà…

Chúng tôi có nhân viên làm việc tại Google ở đây.

Tôi rất tò mò.

Nút này hoạt động như thế nào?

Ngân sách của Google là bao nhiêu?

Bạn có muốn nhận không, Luis?

Tôi không nghĩ mình là người phù hợp để nói về khía cạnh kinh tế của vấn đề này.

Google là một công ty rất lớn với nhiều tổ chức khác nhau.

Nhưng điều đó thực sự giúp chúng ta kết thúc một cách hoàn hảo, vì chúng ta đang đúng giờ.

Thật tiện lợi.

Saved by the bell.

Đó là cách kiểm duyệt xuất sắc, thưa các bạn.

Người làm PR là…

Cảm ơn ban hội thẩm và cảm ơn các bạn đã đến với ADS.