AI là bộ khuếch đại, không phải hướng đi.

Tác giả bài viết, nguồn: InfoQ

AI giúp bạn viết mã nhanh hơn 10 lần, rồi sau đó sao? Nhiều mã hơn nghĩa là thời gian biên dịch dài hơn, bài kiểm tra nặng hơn, quá trình duyệt mã ùn tắc hơn, và một kho mã mà không ai hiểu nổi. Phần mềm là nợ, bạn viết càng nhanh, bạn càng nợ nhiều hơn.

Cảnh báo từ Adam Bender, Kỹ sư phần mềm trưởng của Google, rất trực tiếp: Cách bạn xây dựng phần mềm hôm nay sẽ hoàn toàn không hoạt động được ở tốc độ gấp 10 lần. Nhưng những người chiến thắng thực sự trong thời đại AI không phải là những đội ngũ tạo ra nhiều nhất, mà là những đội ngũ có nền tảng vững chắc nhất. Vì AI chỉ có nhiệm vụ khuếch đại, không có nhiệm vụ định hướng.

Trong một bài diễn văn chính tại Google I/O 2026, Adam Bender đã đặt ra một câu hỏi mà đa số mọi người chưa kịp suy nghĩ: Khi AI đẩy tốc độ tạo mã lên mức vượt quá khả năng chịu đựng của các quy trình kỹ thuật hiện tại, thì điều gì sẽ sụp đổ đầu tiên trong hệ sinh thái nhà phát triển của chúng ta? Ông đã dùng một khái niệm mà có thể bạn chưa từng nghe đến để kết nối toàn bộ bài diễn văn: sinh thái phần mềm — ngành học nghiên cứu toàn diện về hệ sinh thái xã hội-kỹ thuật sản xuất phần mềm. Nói cách khác, bạn không chỉ xem xét công nghệ, mà còn phải xem xét con người, văn hóa và những quy tắc không thành văn trong tổ chức. Dựa trên video bài diễn văn này, InfoQ đã tổng hợp lại nội dung.

Các điểm chính như sau:

• AI không tự động giải quyết bất kỳ vấn đề nào cho bạn. Nếu thực hành của bạn tốt, nó sẽ khuếch đại chúng. Nhưng nếu chưa tốt, nó chỉ tạo thêm rắc rối.
• Việc mọi người đều là người xây dựng thật tuyệt vời, cho đến khi bạn phải duy trì tất cả những gì mọi người đã xây dựng.
• Thực hành kỹ thuật không phải là thiêng liêng và bất khả xâm phạm. Thực hành có thể thay đổi, nguyên tắc mới là điều quan trọng.
• Là một kỹ sư phần mềm hàng đầu, tại thời điểm then chốt này, bạn đang ở vị trí trung tâm quyết định hướng đi của ngành kỹ sư phần mềm. Từ công cụ đến quy trình làm việc, từ thực hành kỹ thuật đến văn hóa kỹ thuật, nếu bạn có thể nhìn rõ hệ thống đang vận hành, bạn sẽ tìm được điểm đòn bẩy.

“Hệ thống” là gì

Công việc của bạn năm 2026 hoàn toàn khác với những gì bạn từng tưởng tượng vào năm 2020. Nếu bạn cố gắng giải thích cho tôi năm 2020 về những điều đang xảy ra hôm nay, tôi sẽ không tin. Có quá nhiều thay đổi, nhiều đến mức khiến người ta có chút choáng ngợp. Tôi không thể dự đoán tương lai, nhưng tôi tin rằng nếu chúng ta nghiên cứu kỹ hệ sinh thái phần mềm hiện tại, một số câu trả lời sẽ gần hơn chúng ta tưởng.

Hôm nay tôi muốn nói với bạn về một từ: sinh thái phần mềm (Software Ecology). Nghe có vẻ như tôi vừa bịa ra để lên sân khấu, nhưng không, đây là một thuật ngữ chính thức. Trước khi đưa ra định nghĩa, tôi muốn chuẩn bị một số bối cảnh, cùng tìm hiểu sâu hơn về tư duy hệ thống.

Một hệ thống là một tập hợp các yếu tố liên kết với nhau, hoạt động theo một bộ quy tắc để tạo thành một tổng thể thống nhất. Nghe có vẻ trừu tượng, nhưng bạn không hề xa lạ với các hệ thống. Ví dụ như điều hòa không khí: một bộ điều nhiệt biết nhiệt độ mục tiêu, một hệ thống sưởi và làm mát chịu trách nhiệm tăng hoặc giảm nhiệt độ, một căn phòng, khi nhiệt độ đạt mức phù hợp, tín hiệu sẽ dừng lại — đó chính là một hệ thống.

Nếu bạn là kỹ sư phần mềm, bạn mỗi ngày đều làm việc với các hệ thống, bạn thiết kế hệ thống, xây dựng hệ thống, vận hành hệ thống, và trong quá trình này, bạn đã học được một điều: mọi thứ đều liên quan đến nhau.

Tiếp theo là hệ sinh thái, một loại hệ thống đặc biệt. Định nghĩa hơi dài, nhưng rất quan trọng: Hệ sinh thái là một mạng lưới động lực gồm các tác nhân phụ thuộc lẫn nhau, những tác nhân này cùng phát triển với môi trường của chúng, đặc trưng bởi các hành vi nổi bật và tính tự chủ phi tập trung. Nói cách đơn giản, hệ sinh thái rất phức tạp, các thành phần được kết nối sâu sắc, mỗi thành phần có tính tự chủ riêng để đưa ra quyết định và hành động. Và điểm quan trọng nhất: môi trường là một phần của hệ thống, bạn không thể tách rời hai yếu tố này.

Hệ sinh thái cũng là một hệ thống thích nghi phức tạp, có thể tăng trưởng, thay đổi và tiến hóa theo thời gian. Chúng còn có một đặc tính gọi là tính chất nổi bật (Emergent Property), tức là những điều bạn không thể thấy bằng cách quan sát bất kỳ bộ phận riêng lẻ nào, mà chỉ xuất hiện khi toàn bộ hệ thống được lắp ráp lại. Chính sự thay đổi liên tục, học hỏi liên tục cùng với tính chất nổi bật khiến việc hiểu rõ những gì đang xảy ra trong hệ sinh thái trở nên cực kỳ khó khăn.

Nói đến hệ sinh thái, có lẽ trong đầu bạn hiện lên cảnh núi non, sông nước, tiếng chim hót và hương hoa. Nhưng môi trường phát triển nội bộ cũng là một hệ sinh thái: gồm nhiều công cụ và dịch vụ khác nhau, những con người với những ý tưởng và nhu cầu riêng, cùng các ràng buộc về nghiệp vụ. Và đây là một hệ thống đặc biệt: hệ thống xã hội-kỹ thuật, tức là hệ thống được tạo thành bởi con người và công nghệ. Hệ thống xã hội-kỹ thuật cực kỳ phức tạp, bởi vì bạn bắt đầu từ tất cả những công nghệ đó, rồi sau đó đưa con người vào hỗn loạn.

Bạn rất có thể đã vô tình tiếp xúc với trí tuệ của các hệ thống xã hội-kỹ thuật. Bạn có biết định luật Conway không: công nghệ mà một tổ chức xây dựng sẽ phản ánh cấu trúc giao tiếp nội bộ của nó. Nói một cách đơn giản, nếu bạn có bốn đội nhóm cùng phát triển một trình biên dịch, bạn sẽ nhận được một trình biên dịch bốn lần, và đó chính là cách vận hành. Quan sát cốt lõi của định luật Conway là cách chúng ta xây dựng công nghệ không thể tách rời khỏi cấu trúc tổ chức tạo ra nó—tổ chức định hình những gì cuối cùng được tạo ra.

Nhưng không chỉ cơ cấu tổ chức ảnh hưởng đến hệ sinh thái nhà phát triển, mà cả giá trị và văn hóa cũng có tác động sâu sắc. Hệ sinh thái bạn xây dựng chính là những gì tổ chức khuyến khích, và văn hóa kỹ thuật của bạn tạo ra môi trường xung quanh hệ sinh thái nhà phát triển. Một khi bạn hiểu được các hệ thống xã hội-kỹ thuật, bạn sẽ thấy chúng ở mọi nơi trong phát triển phần mềm: kiến trúc, văn hóa phân tích sự cố, đánh giá mã, chính sách bảo mật—đều hiện diện khắp nơi. Những gì chúng ta xây dựng, cùng với cách chúng ta chọn xây dựng chúng, phản ánh những gì chúng ta coi trọng. Nếu chúng ta đủ tinh tế, chúng ta có thể tận dụng nhận thức này để khuếch đại các giá trị của mình, đưa chúng thấm sâu vào những gì chúng ta tạo ra.

Bây giờ tôi có thể đưa ra một định nghĩa chính xác: Sinh thái học phần mềm là ngành học nghiên cứu toàn diện về hệ sinh thái xã hội-kỹ thuật sản xuất phần mềm. Nếu những điều vừa rồi hơi trừu tượng, đừng lo, bây giờ hãy xem một ví dụ thực tế.

Hệ sinh thái nhà phát triển của Google

Tôi nói đến Google không phải vì tôi đang làm việc ở đó nên phải ca ngợi nó, mà vì đó là hệ sinh thái nhà phát triển mà tôi hiểu rõ nhất. Mục đích của tôi không phải là bảo các bạn phải sao chép Google, vì điều đó sẽ không có lợi cho các bạn. Các bạn là những công ty khác nhau, đang ở các giai đoạn khác nhau và đối mặt với những sự đánh đổi khác nhau. Nhiều lựa chọn mà Google đã thực hiện đều xuất phát từ nhu cầu cụ thể khi chúng tôi xây dựng hệ sinh thái vào thời điểm đó.

Vài năm trước, chúng tôi đã viết một cuốn sách, trong nội bộ gọi là "Sách Flamingo". Một nửa cuốn sách nói về kiểm soát phiên bản và kiểm thử, nhưng toàn bộ phần đầu đều nói về văn hóa kỹ thuật. Nhiều người hỏi tại sao lại dành nhiều không gian như vậy để nói về văn hóa, vì nếu bạn không hiểu văn hóa của Google, bạn sẽ không thể hiểu vì sao chúng tôi đưa ra những lựa chọn kỹ thuật đó—những điều này có mối liên hệ chặt chẽ với nhau.

Google có một vài đặc điểm văn hóa độc đáo. Chúng tôi là một tổ chức định hướng kỹ thuật sâu sắc, và các kỹ sư luôn có mặt khi đưa ra các quyết định quan trọng; chúng tôi cực kỳ coi trọng tính minh bạch, cố gắng để tất cả tài liệu và mã nguồn đều có thể truy cập bởi mọi người; chúng tôi khuyến khích tinh thần sẵn sàng giúp đỡ, thực tế là bất kỳ ai từng rời Google cũng sẽ nhắc đến sự giúp đỡ nhiệt tình của đồng nghiệp ngay lập tức; chúng tôi xem việc kiểm tra mã là cơ hội để hướng dẫn, chứ không phải để chấm điểm; chúng tôi cực kỳ coi trọng tiêu chuẩn hóa; chúng tôi tin tưởng vào cải tiến liên tục; chúng tôi đề cao việc phân tích sự cố không đổ lỗi; chúng tôi tin tưởng rằng tính bền vững quan trọng hơn chủ nghĩa anh hùng, và tự động hóa quan trọng hơn lao động thủ công. Tất nhiên, chúng tôi không phải lúc nào cũng đạt được tất cả những lý tưởng này, nhưng đó là hướng đi mà chúng tôi nỗ lực theo đuổi trong văn hóa của mình.

Về mặt kỹ thuật: một kho mã nguồn đơn lẻ, hầu hết mã nguồn đều nằm trong một kho; phát triển dựa trên nhánh chính, mọi thay đổi đều được hợp nhất trực tiếp vào nhánh chính; khi xây dựng một tệp nhị phân, gần như từng dòng mã đều được biên dịch từ mã nguồn; chuỗi công cụ xây dựng thống nhất, mọi người đều sử dụng; nền tảng tự động hóa kiểm thử toàn cầu, chạy tất cả các bài kiểm thử tại một nơi, hàng tỷ trường hợp kiểm thử mỗi ngày; tín hiệu “xanh cuối cùng” toàn cầu, tôi có thể cho bạn biết trạng thái của bất kỳ bản dựng nào thông qua một trang web nội bộ đơn giản; môi trường tính toán thống nhất, do đó câu nói “trên máy tôi chạy được” về cơ bản không bao giờ xảy ra; khung phát triển được chuẩn hóa cao và một nhóm nhỏ các ngôn ngữ lập trình cốt lõi.

Sự pha trộn giữa văn hóa và công nghệ này đã tạo nên Google như ngày nay; bạn không thể hiểu được một nửa mà bỏ qua nửa còn lại.

Chia sẻ số phận

Nếu phải chọn một nguyên tắc luôn âm thầm hướng dẫn chúng tôi, tôi sẽ chọn “Số phận chung (Shared Fate)”. Nguyên tắc này mô tả mức độ gắn kết chặt chẽ giữa một hệ sinh thái và các thành phần của nó; trong một hệ sinh thái có mức độ số phận chung cao, một thành phần có thể ảnh hưởng đến tất cả các thành phần khác. Trong hệ sinh thái nhà phát triển, số phận chung vừa là một lựa chọn kỹ thuật, vừa là một lựa chọn xã hội. Bạn không thể chỉ đơn giản đạt được số phận chung bằng cách khiến tất cả mọi người sử dụng cùng một công nghệ; bạn còn cần xây dựng một thỏa thuận xã hội về cách quản lý những công nghệ đó.

Tại Google, số phận chung bắt đầu từ kho mã nguồn đơn nhất. Mọi dòng mã của công ty, ngoại trừ một vài ngoại lệ như Android và Chrome, đều nằm trong một kho chung. Tất cả mã được gửi thẳng vào nhánh chính, không có nhánh riêng, không có phiên bản, mọi thứ đều tập trung tại một nơi. Sự chia sẻ số phận này giúp chúng tôi có thể áp dụng một bản vá bảo mật vào một tệp tin và biết rằng trong vòng một tuần, mọi ứng dụng trong công ty sẽ được sửa chữa. Chỉ với mười dòng mã để vá hơn mười tỷ dòng mã ứng dụng và phần mềm hệ thống, điều đó giống như một siêu năng lực.

Tuy nhiên, chia sẻ số phận không phải lúc nào cũng là điều tốt, mà đó là một sự lựa chọn. Có những nơi việc chia sẻ số phận là không phù hợp, ví dụ như trong môi trường sản xuất, chúng ta tuyệt đối không mong muốn một dịch vụ làm sụp đổ tất cả các dịch vụ khác, hoặc một cụm bị nhiễm bệnh lan rộng toàn bộ khu vực. Vì vậy, chúng tôi đã đầu tư rất nhiều nỗ lực để tránh những mối nguy hiểm do chia sẻ số phận gây ra, đặc biệt là những tình huống dẫn đến lỗi lan truyền. Chia sẻ số phận là một sự đánh đổi, bạn phải tìm được vị trí phù hợp và đảm bảo rằng nó hoạt động có lợi cho bạn.

Thay đổi quy mô lớn

Một trong những thuộc tính nổi bật thú vị nhất trong môi trường chia sẻ số phận của chúng tôi là sự thay đổi quy mô lớn. Hãy chú ý điều này: ngay cả trước khi AI ra đời, các công cụ nội bộ của Google đã cho phép một nhà phát triển có thể thay đổi hàng triệu dòng mã, những dòng mã mà họ sẽ không bao giờ đọc, không bao giờ nhìn lại, và có thể hoàn toàn không biết đến. Chúng tôi đã xây dựng các công cụ giúp mọi thứ này trở nên tự động, và ngày nay vẫn vậy, và chúng tôi đã làm như vậy ít nhất trong 15 năm qua.

Khả năng này cho phép chúng tôi liên tục phát triển kho mã nguồn đơn thể, cập nhật ngôn ngữ và khung công tác, ngăn chặn môi trường nội bộ trở nên cứng nhắc. Nói một cách không quá lời, nếu không có những thay đổi quy mô lớn, chúng tôi sẽ không phải là Google như ngày hôm nay. Những đồng nghiệp thực hiện các công cụ này đang làm công việc của những anh hùng thầm lặng, giúp công ty tiến bước với tốc độ cần thiết.

Nhưng điều cốt lõi là bạn không thể thực sự hiểu nó nếu không nắm rõ những thành phần văn hóa và kỹ thuật cho phép các thay đổi quy mô lớn xảy ra. Bạn cần gì? Một văn hóa kiểm thử phổ biến, nơi mọi người đều phải viết kiểm thử. Một nền tảng kiểm thử thống nhất, để bạn biết nơi lấy kết quả. Các công cụ xây dựng chung, để bạn xây dựng và tôi xây dựng cho ra kết quả giống nhau. Các thư viện chuẩn hóa, để khi thay thế thành phần, bạn không phải nhảy từ chỗ này sang chỗ khác tìm phiên bản nào phù hợp với bạn nhưng không phù hợp với tôi. Đánh giá mã chuẩn hóa, cùng với tính minh bạch của kho mã nguồn, để bạn biết chính xác những mã nào cần thay đổi. Thay đổi quy mô lớn là biểu hiện tối thượng của triết lý “tự động hóa ưu tiên hơn lao động thủ công” của Google, và nó chỉ có thể xảy ra khi toàn bộ hệ sinh thái cùng hợp tác. Bạn không thể chỉ trỏ vào một phần nào đó trong môi trường phát triển và nói: “Đây chính là lý do”, bởi vì chính sự kết nối giữa tất cả các phần mới là nguyên nhân.

Hệ sinh thái của bạn, sự cân nhắc của bạn

Mỗi hệ sinh thái nhà phát triển đều có những đặc tính nổi bật như vậy. Chúng thường là những điều khiến bạn cảm thấy nơi bạn làm việc có gì đó độc đáo, bởi vì chúng là sản phẩm của một chuỗi các lựa chọn mà bạn đã thực hiện.

Hệ sinh thái nhà phát triển của Google đã tạo ra một loạt các sự đánh đổi độc đáo nhằm phục vụ các mục tiêu công nghệ và kinh doanh của chúng tôi. Nhưng giống như mọi hệ sinh thái khác, nó không thể xuất sắc trong mọi nhiệm vụ. Chúng tôi chọn tối ưu hóa quy mô cực lớn, bảo mật và hiệu suất, ngay cả khi điều đó có nghĩa là đôi khi phải hy sinh năng suất của nhà phát triển—chúng tôi sẵn sàng chấp nhận sự đánh đổi này. Một hệ sinh thái của một công ty khởi nghiệp năm người sẽ trông hoàn toàn khác biệt, nơi tốc độ và linh hoạt mới là yếu tố quan trọng nhất.

Hệ sinh thái mà đa số bạn đang ở nằm trong khoảng từ năm người đến hai trăm nghìn người. Những sự đánh đổi mà bạn cần thực hiện rất đáng để quan tâm, vì khi bạn xem xét những sự đánh đổi này, bạn sẽ bắt đầu hiểu được giá trị cốt lõi của tổ chức: điều gì thực sự quan trọng với nó, không phải những gì nó nói ra, mà là những lựa chọn thực tế mà bạn quan sát được tiết lộ điều gì. Khi bạn hiểu được những giá trị này, bạn sẽ bắt đầu định hình những thay đổi đang diễn ra.

Thời điểm đòn bẩy 10 lần: Mỗi nút đều đang chịu áp lực

Đã đến lúc nói về con voi ăn token trong phòng: Một hệ sinh thái nhà phát triển lấy AI làm ưu tiên đầu tiên sẽ trông như thế nào?

Việc xây dựng một hệ sinh thái hoàn toàn mới từ con số không tất nhiên là tuyệt vời, nhưng không ai trong số bạn có sự sang trọng đó. Bạn phải tiếp tục giao phần mềm trong khi thay thế gần như từng bộ phận của nó. Công ty kỳ vọng bạn tiếp tục tạo ra giá trị, đồng thời đảm bảo không xảy ra sự cố.

Hãy tự hỏi bản thân một câu hỏi: Bạn hiểu bao nhiêu về hệ sinh thái nhà phát triển của mình hôm nay? Bạn có thể vẽ ra toàn bộ nó không? Bạn có biết tất cả các bộ phận nằm ở đâu, không chỉ về mặt kỹ thuật mà còn về mặt xã hội? Bạn có thể liệt kê các thành phần tạo nên hệ sinh thái của mình không? Những người khác trong tổ chức của bạn hiểu bao nhiêu? Những ưu điểm và nhược điểm của nó là gì? Các điểm nghẽn nằm ở đâu? Nơi nào bị hạn chế, nơi nào tự do? Bạn có những lựa chọn nào? Bạn đã thấy những thuộc tính nổi bật nào? Có lẽ quan trọng nhất: nếu hệ sinh thái của bạn đột ngột phải xử lý lượng mã nguồn gấp 10 đến 15 lần trong vòng 18 tháng tới, bạn có biết điều gì sẽ sụp đổ đầu tiên không?

Mỗi hệ sinh thái phát triển trên Trái Đất đều đang trải qua một cuộc biến đổi triệt để, có thể nó chưa đến với mọi ngóc ngách bạn đang ở, nhưng nó đang trên đường đến đây, và mỗi hệ sinh thái phát triển đều sẽ phải đối mặt với thời điểm 10 lần này. Đây là một thời đại đáng kinh ngạc, nhưng cũng khá mơ hồ. Những sự đánh đổi mà chúng ta đã chủ động phát triển trong 25 năm qua sẽ được cân bằng lại.

Viết mã nhanh hơn 10 lần và phát triển kỹ thuật nhanh hơn 10 lần là hai việc khác nhau. Tại Google, chúng tôi thường nói rằng kỹ thuật là tích lũy lập trình theo thời gian. Nhưng vấn đề là chúng ta đang tăng tốc đáng kể khâu viết mã, khiến cỗ máy mã hóa hoạt động nhanh hơn. Do đó, chúng ta phải tìm cách xây dựng kỹ thuật xung quanh cỗ máy mã hóa này để thực sự mang lại kết quả cho khách hàng. Không ai biết đợt tăng năng suất này có thể đẩy chúng ta đi xa đến đâu, nhưng có một điều chắc chắn: chúng ta đang đi lên từ đây.

Vấn đề là cách chúng ta xây dựng và giao phần mềm hôm nay sẽ không hoạt động ở tốc độ gấp 10 hoặc 100 lần, một số thứ phải thay đổi.

Hãy bắt đầu bằng một sơ đồ hệ sinh thái nhà phát triển được đơn giản hóa. Trong một thế giới mà hoạt động tăng 10 lần, điều gì phải thay đổi?

Mã được đưa vào kho

Viết mã nguồn. Nếu mọi người viết mã nhanh hơn nhiều, lượng mã sẽ tăng lên rất nhiều, điều này không phải là chuyện tốt. Jeff Atwood từng nói rằng phần mềm là một khoản nợ. Vì vậy, 10 lần mã nguồn, 10 lần nợ. Và bạn không thể đơn giản phát cho mỗi người một đống token rồi nói “Chúc may mắn”. Tôi mong bạn đầu tư sau khi đã được đào tạo: Bạn có biết tài liệu thực hành kỹ thuật của mình ở đâu không? Bạn có biết cách phát triển chúng không? Sau đó mới cân nhắc.

Xây dựng hệ thống. Nhiều mã hơn, hệ thống lớn hơn có nghĩa là thời gian biên dịch lâu hơn. Tôi chắc chắn rằng hiện tại không ai trong công ty bạn than phiền về việc biên dịch chậm. Nhưng bạn đoán xem sao, chúng sẽ còn chậm hơn nữa. Và nếu agent đang xử lý khối lượng công việc lớn, số lần biên dịch cũng đang tăng vọt. Biên dịch không miễn phí, dù về thời gian hay tài nguyên tính toán. Bạn có thể chưa bao giờ để ý mình đã tốn bao nhiêu thời gian cho việc biên dịch, nhưng ở quy mô gấp 10 lần, bạn chắc chắn sẽ nhận ra.

Thiết kế mã nguồn. Bạn có các kỹ năng phù hợp để khuyến khích sự tách rời không? Bạn có framework máy chủ phù hợp để đảm bảo kết hợp nhanh chóng và an toàn các khả năng khác nhau không? Bạn có biết công ty bạn đang sử dụng bao nhiêu cách triển khai ứng dụng web không? Có bao nhiêu framework máy chủ khác nhau đang chạy? Bạn quản lý việc tái sử dụng thành phần từ mã do agent viết như thế nào? Có lẽ bạn đang cược rằng điều này không quan trọng. Nhưng nếu agent tạo ra mã dễ viết nhưng khó bảo trì, thì đừng quá ngạc nhiên — đó chính là mức chuẩn hiện tại. Agent giỏi trong việc viết mã, nhưng không phải lúc nào cũng suy nghĩ dài hạn. Những đoạn mã đó, tôi chắc chắn sẽ không dễ dàng重构. Không sao, phần này chúng ta sẽ giải quyết sau. Nhưng sự thật là agent đang thực hiện rất nhiều công việc cho chúng ta, và chúng ta phải mỗi ngày tìm cách áp dụng những khả năng này một cách hiệu quả nhất.

Đến một lúc nào đó, các công việc được agent hóa này có thể khiến file nhị phân của bạn trở nên lớn đến mức không thể biên dịch. Hoặc lớn đến mức không thể đẩy lên điện thoại nữa. Bạn đã bao giờ tự hỏi: File nhị phân lớn nhất mà bạn có thể biên dịch là bao nhiêu? Tôi không biết câu trả lời, nhưng tôi biết rằng tại Google, chúng tôi đang chạm đến giới hạn, và ở một số nơi, file nhị phân đã lớn đến mức không thể biên dịch được, tôi tin rằng chúng tôi sẽ giải quyết được vấn đề này. Nhưng sự thật là, quy mô lớn mang lại nhiều hệ quả dây chuyền, tác động của quy mô hiện diện ở khắp nơi.

Có thể bạn đang sử dụng kiến trúc dịch vụ vi mô và đang nghĩ: “Các dịch vụ của tôi đều rất nhỏ, tôi cần lo lắng gì chứ?” Nhưng tôi có một câu hỏi: 10 lần lưu lượng mạng, 10 lần số lượng dịch vụ, 10 lần lượng giao tiếp, bạn đã sẵn sàng chưa? Không ai có thể thoát khỏi ảnh hưởng của quy mô — tác động của quy mô hiện diện ở khắp nơi.

Đánh giá mã. Giả sử bạn không thể biên dịch đáng tin cậy tất cả những mã này, quy trình đánh giá mã của bạn sẽ như thế nào? Mọi người đều lo lắng về đánh giá mã, và điều đó có lý do. Chúng ta đang gây áp lực cực lớn lên quy trình rất con người này, và trong nhiều trường hợp, nó đang trở thành điểm nghẽn—và con người không thích trở thành điểm nghẽn. Khi bạn gây áp lực lên họ, hành vi của họ sẽ trở nên kỳ lạ. Với lượng mã tăng 10 lần, bạn sẽ ли nhận được các thay đổi lớn gấp 10 lần, hoặc số lượng thay đổi tăng gấp 10 lần. Quản lý kỹ thuật của bạn có thể duy trì tốc độ đánh giá cần thiết không? Hầu hết các quản lý kỹ thuật không thể đánh giá hết lượng mã mà năm nhà phát triển 10x tạo ra trong một ngày.

Vì vậy, để không trở thành điểm nghẽn, họ sẽ bắt đầu sắp xếp lại quy trình, tìm cách đi tắt, đảm bảo không làm ai bị trì hoãn, vì không ai muốn trở thành người gây nghẽn. Bạn có thể sử dụng AI để giải quyết một phần vấn đề, chẳng hạn như triển khai AI để cải thiện việc duyệt mã. Nhưng điều này chỉ giải quyết được một phần, vì nếu các thành viên trong nhóm của bạn không còn viết mã nữa, thì thời điểm duy nhất họ tiếp xúc với mã là khi duyệt, mà lúc đó sự chú ý lại không đủ, vậy thì ai sẽ theo dõi sự phát triển của kho mã nguồn? Không ai cả. Nhanh chóng, kho mã nguồn của bạn sẽ trở thành một đống hỗn độn mà không ai hiểu nổi.

Kinh tế token. Token rất đắt, một số bạn đã biết điều này rồi. Trong quy mô lớn, token là một chi phí thực tế mà bạn phải tính đến. Nếu mọi người trong công ty bắt đầu sử dụng token với mức 10 lần hoặc 100 lần thì sẽ xảy ra gì? Nếu bạn vô tình tiêu hết ngân sách cả tháng trong một ngày thì sao? Nếu bạn phải ưu tiên quyết định token sẽ được dùng vào đâu, bạn có biết nên ưu tiên đầu tư vào đâu không? Bạn thậm chí có đang có khả năng nhìn thấy token đang chảy đến đâu không?

Chỉ trong vài nút đầu tiên của hệ thống đơn giản này, chúng ta đã phát hiện ra các vấn đề. Và rất rõ ràng sẽ có một số hiệu ứng bậc hai đầy thách thức.

Kiểm thử và kiểm soát phiên bản

Bạn từng xem cơ sở hạ tầng kiểm tra của mình tiêu tốn bao nhiêu tài nguyên tính toán chưa? Ở Google, tôi chưa bao giờ hài lòng với tốc độ kiểm tra của mình.

Mỗi thay đổi được đưa vào kiểm soát phiên bản đều phải được kiểm thử. Nhưng ngoài ra, agent cũng rất thích chạy các bài kiểm thử vì chúng cho biết mình làm tốt hay không. Do đó, agent đã tạo ra khối lượng công việc bổ sung, khiến công việc của tôi nhiều hơn. Vậy, với 10 lần số lượng commit cộng với tất cả công việc mà agent đã thực hiện, hiện tại tiêu tốn bao nhiêu tài nguyên tính toán cho kiểm thử?

Thực tế, tình huống có thể còn tồi tệ hơn. Chúng tôi quan sát thấy trên Google rằng, khi quy mô mã nguồn tăng lên, đồ thị phụ thuộc tăng theo cấp bậc hai, không phải tuyến tính. Vì vậy, nếu mã nguồn lớn lên 10 lần, số lượng bài kiểm tra bạn phải chạy có thể không phải là 10 lần, mà là 100 lần hoặc thậm chí 1.000 lần. Đây sẽ là một thách thức rất thú vị, và cuối cùng nó sẽ trở thành một dòng trong bảng ngân sách của bạn. Nếu bạn hiện tại không lo lắng về chi phí tài nguyên tính toán cho bài kiểm tra, điều đó khiến tôi lo lắng hơn nhiều, vì điều đó có nghĩa là bạn có thể thực sự không có đủ bài kiểm tra, và các agent đang YOLO trong mã nguồn của bạn mà không có mạng an toàn.

Giả sử vấn đề biên dịch và kiểm thử đã được giải quyết, giờ hãy xem hệ thống kiểm soát phiên bản. Hầu hết các hệ thống kiểm soát phiên bản phổ biến không được tối ưu hóa cho hiệu suất, mà được tối ưu hóa cho tính nhất quán và thứ tự. Đó là nhiệm vụ cốt lõi của chúng: duy trì hồ sơ đầy đủ, chứ không phải chạy nhanh như gió. Hệ thống kiểm soát phiên bản của bạn có thể xử lý bao nhiêu lần commit mỗi phút? Tôi đảm bảo con số đó ít hơn bạn tưởng rất nhiều. Nó không thể mở rộng lên tốc độ nhanh gấp 10 lần như bạn cần. Khi nào lần cuối bạn nghĩ đến hiệu suất của hệ thống kiểm soát phiên bản? Nếu bạn không phải là người phát triển Git, có lẽ bạn chưa bao giờ nghĩ đến. Nói thật đi, việc phải bàn đến hiệu suất của hệ thống kiểm soát phiên bản cho thấy đã có điều gì đó nghiêm trọng đi lệch hướng. Chúng ta đang ở tầng đáy nhất của trải nghiệm người phát triển, nhưng đây chính là hệ quả của những thay đổi mang tính hệ thống: chúng tìm đến mọi ngóc ngách trong hệ thống của bạn và nói: “Này, bạn có để ý không? Vì có chuyện bạn không lường trước đang đến.”

Đối với những ai định dùng nhiều kho nhỏ để giải quyết vấn đề kiểm soát phiên bản, hãy hỏi bất kỳ ai đã quản lý hàng trăm, hàng nghìn kho nhỏ, tôi cam kết rằng đó chỉ là một bộ hoàn toàn mới các thách thức, và AI không nhất thiết khiến những vấn đề này trở nên dễ dàng hơn.

Danh sách sự cố

Cho đến nay, chúng ta chỉ đang xem xét những nút dung lượng tương đối dễ phát hiện, tức là lấy một con số nhân với 10 rồi hỏi liệu sẽ tốt hay xấu, còn rất nhiều thách thức bất ngờ khác.

Xác minh chiến lược. Hôm nay, việc xác minh của bạn chủ yếu bao gồm nhiều bài kiểm tra đơn vị và một số bài kiểm tra tích hợp. Nhưng trong thế giới với 10 lần mã và 10 lần dịch vụ, kiểm tra tích hợp sẽ trở thành phần quan trọng nhất trong chiến lược chất lượng. Có bao nhiêu người trong số các bạn hài lòng với phương án kiểm tra tích hợp hiện tại của mình? Tôi cũng không hài lòng. Kiểm tra tích hợp thực sự rất khó, và hiện tại tôi vẫn chưa có công cụ nào giúp tôi thực hiện kiểm tra tích hợp theo cách tôi mong muốn.

Vấn đề hội tụ boolean. Hôm nay bạn đang phát hành phần mềm, bạn yêu cầu mọi bài kiểm tra phải thành công, tất cả các giá trị boolean đều chuyển sang màu xanh, và chỉ khi mọi thứ đều ổn mới tiến hành phát hành — điều này rất hợp lý. Nhưng khi bạn có một triệu bài kiểm tra, và cơ sở hạ tầng kiểm tra nền tảng không đáng tin cậy để chạy một triệu bài kiểm tra, thì điều gì sẽ xảy ra? Có thể việc yêu cầu tất cả các giá trị boolean phải là đúng mới có thể phát hành phần mềm sẽ trở nên không khả thi. Bạn cần một chiến lược mới, có thể dựa trên phương pháp thống kê, để xác định những bài kiểm tra nào nên chạy, vì bạn không thể chạy tất cả các bài kiểm tra.

Thay đổi cực lớn. Việc có thể tái cấu trúc toàn bộ, thay đổi ngôn ngữ và khung nền tảng thật sự thú vị. Nhưng bạn có quy trình làm việc và thỏa thuận xã hội nào để hỗ trợ mọi người xử lý xung đột hợp nhất với hàng chục nghìn, hàng trăm nghìn, thậm chí hàng triệu dòng mã không? Có lẽ là không. Nếu mọi người trong công ty đều có thể thực hiện những thay đổi cực lớn, chúng ta sẽ cần những chiến lược quy trình làm việc mới.

Cuộc chiến của các agent. Một agent thực hiện một thay đổi, một agent khác chạy đến nói: “Không, tôi không thích, tôi sẽ thực hiện một thay đổi khác.” Nghe có vẻ hài hước, cho đến khi bạn nhận ra bạn đang trả phí token cho cả hai bên.

Tần suất phát hành. Bạn phát hành cho khách hàng bao nhiêu lần một ngày? Mỗi ngày? Đó là khá tốt. Nếu không, bạn sẽ có hơn 10 lần phần mềm cần được triển khai, và tất cả những thứ này đều cần được đặt ở đâu đó. Nếu bạn không phát hành hàng ngày, mỗi lần thay đổi sẽ trở nên lớn hơn nhiều. Và các bạn SRE của tôi sẽ nói với bạn rằng những thay đổi cực lớn là vô cùng đáng sợ. Đừng làm vậy. Nhưng mã nguồn phải được triển khai mới tạo ra giá trị, vì vậy bạn có thể thử phát hành thường xuyên hơn, điều này rất tốt và sẽ khiến các bạn của DORA hài lòng. Tuy nhiên, đến một điểm nào đó, lợi ích sẽ giảm dần; phát hành mỗi giây một lần có lẽ sẽ không mang lại nhiều giá trị cho bạn. Mã nguồn vẫn sẽ tiếp tục tăng trưởng, và bạn cần tìm ra cách đặt nó ở đâu để không tạo ra thêm rủi ro.

API nội bộ. Tôi đã luôn nói với các đồng nghiệp của mình rằng tất cả API của bạn đột nhiên trở nên công khai. Agent sẽ không hỏi ý kiến bạn, nó sẽ tìm ra API và gọi trực tiếp. Nó sẽ sử dụng bất cứ thứ gì nó có thể truy cập, tôi đảm bảo. Nếu bạn chưa bao giờ bảo vệ các giao diện và bộ dữ liệu nội bộ giống như cách bạn bảo vệ API công cộng, agent sẽ tìm thấy những thứ bạn không muốn chúng tìm thấy.

Paradox của Jevons. Jevons cho rằng, một nguồn tài nguyên càng rẻ và hiệu quả hơn, chúng ta càng sử dụng nhiều hơn. Sự bùng nổ của Token chính là ví dụ sống động. Chúng ta đang đưa chúng vào mọi nơi, thay đổi cách chúng ta làm việc và suy nghĩ về công việc. Chúng ta đang định giá cho những lao động năng suất trước đây vô hình, điều này sẽ ảnh hưởng như thế nào đến hành vi của chúng ta? Tôi vẫn chưa biết.

Hồi phục. Bạn có biết tại sao hồi phục hôm nay về cơ bản là khả thi không? Vì tốc độ bạn phát hành phần mềm chậm hơn một chút so với thời gian bạn cần để phát hiện vấn đề trong môi trường sản xuất. Nếu bạn có thể phát hành cực kỳ nhanh, nhanh đến mức bạn chưa kịp phát hiện bất kỳ vấn đề nào, thì tư thế hồi phục của bạn sẽ như thế nào? Mỗi lần hồi phục sẽ buộc phải xử lý nhiều thay đổi chồng chéo và xung đột với nhau. Vì vậy, chỉ phát hành nhanh hơn là chưa đủ; bạn phải xem xét toàn bộ hệ thống, bao gồm cả cơ chế hồi phục — một van an toàn quan trọng. Nhân tiện, bạn cần cẩn thận khi đặt động cơ token. Nếu quy trình hồi phục của bạn phụ thuộc vào một agent có đủ dung lượng, mà trước đó ai đó đã tiêu hết ngân sách token của agent đó, khiến bạn hiện tại không thể hồi phục, thì đó chắc chắn không phải là điều tốt đẹp gì.

Mỗi người đều là người xây dựng. Bạn có thể từng nghĩ đến việc tạo ra một phiên bản thay thế cho công cụ mà bạn không thích trong công ty. Bây giờ, hãy nhân điều đó lên với mỗi người và mỗi công cụ trong công ty. Khi mọi người đều sử dụng những công cụ hoàn toàn khác nhau, cấu trúc xã hội của công ty sẽ xảy ra điều gì? Nếu bạn may mắn có một nền tảng dữ liệu thống nhất, nơi tất cả dữ liệu đều được tập trung vào một chỗ, thì vẫn ổn. Nhưng nếu không thì sao? Việc mỗi người đều là người xây dựng thật tuyệt vời, cho đến khi bạn phải duy trì tất cả những thứ mà mọi người đã xây dựng.

Khóa học cấp tốc về lãnh đạo kỹ thuật. Việc trở thành một người phụ trách kỹ thuật mất nhiều thời gian vì bạn cần tích lũy trực giác, khả năng phán đoán và năng lực chuyên môn để đưa ra quyết định, bởi khi bạn dẫn dắt một đội nhóm, sai lầm của bạn sẽ có phạm vi ảnh hưởng lớn hơn nhiều so với khi bạn làm việc một mình. Khi một sinh viên mới ra trường bước vào một môi trường có thể gọi đến năm mươi agent nhưng không có bất kỳ trực giác hay khả năng phán đoán nào, điều gì sẽ xảy ra sai? Làm thế nào tôi có thể dạy mười năm kinh nghiệm trong sáu tháng? Tôi không biết.

Sự chú ý của con người là nguồn tài nguyên quý giá nhất mà chúng ta có. Hiện nay có quá nhiều tiếng ồn, quá nhiều tác nhân và sự vật đang cạnh tranh sự chú ý của chúng ta, vì vậy chúng ta phải tìm cách quản lý điều này. Trước đây, chúng ta được hưởng lợi từ thực tế là khả năng gây ra rắc rối của chúng ta không vượt quá khả năng chúng ta đầu tư sự chú ý, nhưng giờ đây tình hình đã không còn như vậy.

Nghe có vẻ nhiều, bởi vì trong một hệ thống, mọi thứ đều liên quan đến nhau. Tất cả những thách thức tôi vừa đề cập, bạn không thể giải quyết bất kỳ vấn đề nào chỉ bằng cách xem một nút trong hệ thống; bạn phải xem toàn bộ hệ thống.

Để thích nghi với phát triển theo hướng agent, chúng ta đều phải bắt đầu học cách suy nghĩ một cách hệ thống liên tục. Khi bạn suy nghĩ về hệ thống, những điều bạn nên chú ý bao gồm: các vật thể đang trở nên lớn hơn, hiệu ứng thay đổi theo thời gian, chiều hướng lưu chuyển của nguyên nhân và kết quả, những nút nào đang giao tiếp với tất cả các láng giềng, sự nổi bật trông như thế nào, và những thứ xuất hiện không rõ từ đâu là gì. Các cơ chế khuyến khích — bao gồm cả xã hội và công nghệ — cùng với dung lượng, vòng phản hồi và điểm nghẽn, là những công cụ phân tích hệ thống.

Nghe có vẻ phức tạp, nhưng bạn thực sự chỉ cần hai câu hỏi: Tại sao (Why?), và nếu thế thì sao (What if?)? Tại sao chúng ta có ít bài kiểm tra tích hợp như vậy? Nếu chúng ta có nhiều bài kiểm tra tích hợp hơn bài kiểm tra đơn vị thì sao? Tại sao chúng ta sử dụng những ngôn ngữ cụ thể này? Nếu AI viết toàn bộ mã nguồn thì sao?

“Tại sao” là chiếc khoan bạn dùng để đi sâu vào lõi hệ thống và hiểu rõ cách nó hoạt động. Các bạn đều rất giỏi đặt câu hỏi “tại sao”, nhưng “nếu như” mới là phần khó hơn. “Nếu như” có thể khiến bạn sợ hãi, nếu nó đòi hỏi bạn phải từ bỏ những thực hành mà bạn từng cho là được thiết kế rất tốt. Nếu không kiểm tra thì sao? Nếu hoàn toàn không viết bài kiểm tra thì sao? Đừng đi quá xa. Nhưng nếu bạn cho phép điều đó xảy ra, “nếu như” cũng có thể rất thú vị.

AI là bộ khuếch đại, không phải hướng đi

AI là bộ khuếch đại. Ý tưởng này đến từ những người bạn của tôi tại DORA, trong báo cáo phát triển AI năm ngoái của họ đã phát hiện ra một mối quan hệ giữa những đội ngũ thực sự hiểu rõ vấn đề: họ đã tìm ra cách để biến AI thành bộ khuếch đại.

AI có thể mang lại cho bạn nhiều hơn: nhiều bài kiểm tra hơn, nhiều tài liệu hơn, nhiều mã hơn, nhưng cũng nhiều hỗn loạn hơn. Sự khuếch đại là về quy mô, không phải về hướng đi. AI không quan tâm những thứ đó đi đâu, nó chỉ đơn giản là cung cấp cho bạn nhiều hơn. Điều DORA thực sự phát hiện ra là những đội ngũ có nền tảng vững chắc có thể định hướng hiệu ứng khuếch đại này vào những hướng hữu ích.

Điều này đặt ra câu hỏi: Bạn cảm thấy thế nào về nền tảng cơ bản của mình? Văn hóa ra quyết định của công ty bạn như thế nào? Bạn có thể làm gì để cải thiện nó? Chiến lược công nghệ thì sao? Có ai quan tâm đến năng suất của nhà phát triển không? Mọi người trong tổ chức hôm nay hợp tác ra sao? Tình hình an ninh thế nào? Độ lành mạnh của mã nguồn, vệ sinh khi phát hành, độ tin cậy thì sao? AI không tự động giải quyết bất kỳ vấn đề nào cho bạn. Nếu thực hành của bạn tốt, nó sẽ khuếch đại chúng. Nhưng nếu chưa tốt, nó chỉ tạo thêm rắc rối.

Nhưng ngay cả khi nền tảng cơ bản vững chắc, chúng ta cũng sắp bước vào một hành trình thực sự. Tôi đoán rằng đến năm 2030, hệ sinh thái nhà phát triển ngày nay của chúng ta sẽ xa vời như năm 2001 đối với chúng ta hôm nay. Năm 2001, chúng ta vẫn đang phát hành phần mềm qua CD-ROM, đến năm 2030 có lẽ chúng ta sẽ cách xa nhau đến vậy.

Trong quá trình bạn tiếp tục củng cố nền tảng cơ bản, hãy để tôi cho bạn bốn điều bạn có thể suy ngẫm dọc đường.

Đầu tiên, năng lực cơ sở hạ tầng. Nếu bạn không biết mình có bao nhiêu nguồn lực để chi tiêu, bạn không thể triển khai AI hay triển khai tài nguyên tính toán; bạn cần một phương pháp tốt để theo dõi những điều này.

Thứ hai, xác minh chiến lược. Bạn không thể và không nên phát hành phần mềm chưa được xác minh. Nhưng chiến lược xác minh đang thay đổi, đã đến lúc bạn cần suy nghĩ rõ ràng. Kiểm thử tích hợp sẽ trở thành vũ khí quan trọng nhất của bạn, và có thể bạn chưa có công cụ phù hợp.

Thứ ba, cô lập. Bạn sẽ nhận được rất nhiều mã dùng cho các mục đích khác nhau, trong đó có một số mục đích trước đây hoàn toàn không dùng mã. Điều này không sao, nhưng bạn không muốn một mã prototype thú vị thực sự chạy vào môi trường sản xuất. Hãy đảm bảo những thứ vui vẻ không ảnh hưởng đến những thứ mang lại lợi nhuận.

Thứ tư, trừu tượng. Chúng ta xây dựng các mức trừu tượng để ngăn các nhà phát triển đưa ra những lựa chọn tồi, đó là lý do tại sao chúng ta có các thư viện và khung công tác. Không ai viết máy chủ web từ đầu. Việc để agent đưa ra quá nhiều quyết định sẽ dẫn đến hậu quả tương tự, vì vậy bạn cần các mức trừu tượng tốt để agent tuân theo. Đừng đưa cho chúng những lựa chọn tồi.

Bạn cũng phải chấp nhận một điều: thực hành kỹ thuật không phải là thiêng liêng và bất khả xâm phạm. Thực hành sẽ thay đổi, nhưng nguyên tắc mới là điều quan trọng. Nói thì dễ nhưng làm thì khó; nếu bạn chưa từng thực sự suy ngẫm về lý do tại sao nhóm của bạn kiểm thử phần mềm theo cách này, hoặc tại sao quy trình phát hành lại vận hành như vậy, bạn sẽ không thể phát triển nó. Hiểu được các nguyên tắc mới giúp bạn có sức mạnh và sự tự tin để vượt qua thời điểm 10 lần này.

Hiện nay là một thời đại đầy hấp dẫn đối với các kỹ sư phần mềm. Mọi khía cạnh trong công việc của chúng ta đều đang được định nghĩa lại; chúng ta cần sáng tạo hơn bao giờ hết; chúng ta cần kỹ năng để đối phó với những vấn đề như quản lý ngữ cảnh, kinh tế token, sự trôi dạt mô hình; chúng ta cần sự sáng tạo; chúng ta không nên quá đắm chìm trong cám dỗ tối ưu hóa mọi thứ, mà cần khuyến khích sự khám phá.

Một vấn đề luôn khiến tôi trằn trọc không ngủ được, và nó không thể được giải quyết chỉ bằng cách tối ưu hóa: Khi kho mã ngày càng lớn, chúng ta làm thế nào để duy trì sự kiểm soát trí tuệ đối với nó? Kiểm soát trí tuệ có nghĩa là con người có thể suy luận được về những gì đang ở trước mặt mình. Chúng ta đã thua cuộc chiến này ít nhất mười lăm năm rồi, những hệ thống lớn nhất của chúng ta đã vượt quá khả năng suy nghĩ của bất kỳ ai. Nếu bạn không tin, hãy thử một thí nghiệm: yêu cầu mỗi người trong nhóm bạn vẽ một sơ đồ kiến trúc hệ thống, rồi xem bạn sẽ nhận được bao nhiêu phiên bản khác nhau.

Nhiều hệ thống phần mềm của chúng tôi rất dễ bị tổn thương; chỉ một dòng mã kém hoặc một cờ cấu hình sai cũng có thể làm sụp đổ một hệ thống hàng triệu dòng mã, sự dễ tổn thương này buộc bạn phải suy nghĩ kỹ trước khi thực hiện bất kỳ thay đổi nào. Nhưng tôi có một ý tưởng rất hào hứng về AI: một không gian kiến trúc liên tục được cập nhật và gần như tương tác, nơi tôi có thể đặt câu hỏi cho nó. Nếu chúng ta di chuyển dung lượng này sang bờ đông sẽ xảy ra gì? Nếu tăng trưởng người dùng đột ngột tăng 40% thì sao? Đối với ngay cả một hệ thống quy mô trung bình ngày nay, việc làm điều này về mặt chức năng là gần như không thể, vì có quá nhiều biến số. Nhưng AI có thể hiểu những tập dữ liệu cực kỳ lớn, vì vậy tôi tin rằng có điều gì đó đáng khai thác ở đây.

Lý do tôi thích câu hỏi này là chúng ta không chỉ đơn thuần tập trung vào việc làm cho máy mã chạy nhanh hơn, mà chúng ta đang đặt câu hỏi: Làm thế nào để hiểu sâu hơn về những gì chúng ta đã xây dựng?

Sự thay đổi diễn ra rất nhanh, nhanh hơn hầu hết những gì các bạn từng trải qua. Một trong những điều quan trọng nhất các bạn có thể làm ngay bây giờ là giúp đỡ những người đang gặp khó khăn, dang tay hỗ trợ những người vẫn chưa hiểu rõ. Chúng ta đều đang tiến bước với tốc độ khác nhau và đối phó với sự thay đổi này theo những cách khác nhau. Việc cảm thấy mình đang bị bỏ lại phía sau là điều rất dễ xảy ra.

Các kỹ sư giàu kinh nghiệm, hãy trở thành người hướng dẫn. Tìm những người đang gặp khó khăn và giúp họ. Nếu bạn đã hiểu rõ quy trình phát triển AI, hãy chia sẻ với người khác—đây không phải là bí mật quý giá. Các kỹ sư trưởng, bạn phải tham gia tích cực để định hướng phát triển kỹ thuật phần mềm trong công ty bạn. Nếu bạn quan tâm đến chất lượng phần mềm hoặc thiết kế phần mềm, bạn phải dùng tiếng nói của mình để bảo vệ nó. Những người trong phòng này chính là những người phải làm những điều này—sếp của bạn có lẽ sẽ không làm.

Nếu chúng ta tưởng tượng hệ sinh thái nhà phát triển như một hệ sinh thái sống động, thì trước đây chúng ta đều quen với việc chăm chú nhìn từng chiếc lá trên từng cành cây, chăm sóc từng cây như thể chúng là những dạng sống đặc biệt. Nhưng chẳng bao lâu nữa, điều chúng ta cần quản lý sẽ không còn là một cây đơn lẻ, mà là cả một khu rừng. Và bạn không thể quản lý một khu rừng bằng cách chỉ chăm chú vào từng cây riêng lẻ — bạn phải nhìn nhận khu rừng như một hệ sinh thái để quản lý.

Các thay đổi hệ thống có một đặc điểm: chúng xảy ra đồng thời ở mọi nơi, mọi thứ, lớn đến mức khiến bạn cảm thấy không thể nắm bắt được điều gì. Lúc này, bạn có thể cảm thấy không có gì có thể giúp bạn vững vàng giữa làn sóng thay đổi dường như trào dâng mỗi tuần. Nhưng như chúng ta vừa tìm ra, trong một hệ thống, mọi thứ đều liên kết với nhau, những hành động nhỏ có thể tạo ra hậu quả lớn.

Dù bề ngoài có vẻ thế nào đi nữa, quá trình chuyển đổi AI không chỉ là lĩnh vực của các nhà lãnh đạo công ty. Là một kỹ sư phần mềm tuyến đầu, tại thời điểm then chốt này, bạn đang ở vị trí trung tâm quyết định hướng đi của kỹ thuật phần mềm. Từ công cụ đến quy trình làm việc, từ thực hành kỹ thuật đến văn hóa kỹ thuật, nếu bạn có thể nhận ra hệ thống đang vận hành, bạn sẽ tìm được điểm đòn bẩy. Bạn có nhiều tự chủ hơn bạn nghĩ — hãy tận dụng tốt sự tự chủ này để tạo ra tương lai cho tổ chức, đội nhóm và chính bản thân bạn.