Muốn xây nhà máy phần mềm tác tử, đội kỹ thuật phải bắt đầu từ cảm biến xác minh, không phải từ số lượng tác tử. Cảm biến cần trả kết quả đủ nhanh, phản ánh hành vi của hệ thống thật và xử lý đồng thời nhiều thay đổi. Nếu không, tác tử chỉ tạo mã nhanh hơn tốc độ hệ thống có thể phát hiện lỗi.
Khoảng cách về tốc độ phát hành giữa những đội kỹ thuật tốt nhất và phần còn lại từng được đo bằng số lần triển khai mỗi tuần. Nay tác tử đang khuếch đại khoảng cách đó theo cấp số nhân. Theo bài viết gốc của The New Stack, ranh giới không còn nằm ở công cụ hay nhân lực, mà ở việc đội ngũ đã xây lại hệ thống phân phối thành một nhà máy phần mềm hay chưa.
Trong mô hình này, con người đưa vào ý định và chịu trách nhiệm về đặc tả cùng các cổng kiểm soát. Tác tử lập kế hoạch, viết mã, kiểm thử và chuyển thay đổi tới môi trường vận hành. Mức tự chủ của toàn bộ hệ thống phụ thuộc vào khả năng xác minh rằng một thay đổi thực sự hoạt động trước khi hàng nghìn thay đổi tiếp theo được đặt lên trên nó.
Quy mô chênh lệch đã hiện ra trong số liệu của Anthropic. Theo tài liệu kỹ thuật về việc thiết kế lại hệ thống quản lý mã nguồn của Anthropic, công ty hợp nhất khoảng 2.500 thay đổi mã mỗi ngày vào tháng 5 và hơn 30.000 thay đổi mỗi ngày vào tháng 9. Viết mã không còn là nút thắt. Hạ tầng dành cho nhà phát triển, vốn được thiết kế theo tốc độ làm việc của con người, mới là phần không theo kịp.
Nội dung của nhà máy phần mềm tác tử
Nhà máy phần mềm tác tử là một hệ thống gồm nhiều vòng lặp có ràng buộc cùng xử lý công việc, xác minh kết quả và đưa thay đổi qua cổng rà soát trước khi triển khai. Con người quản lý ý định, đặc tả và chính sách ở tầng trên thay vì trực tiếp điều khiển từng bước.
Định nghĩa được Addy Osmani sử dụng mô tả nhà máy phần mềm như nhiều vòng lặp có ràng buộc cùng chạy, nhận việc từ một hàng đợi và đưa kết quả qua cổng rà soát trước khi vào môi trường vận hành.
Ý định được thể hiện bằng đặc tả, phiếu công việc và kịch bản mô tả thế nào là hoàn thành. Hàng đợi giữ danh sách việc cần xử lý. Mỗi tác tử hoạt động trong một bộ khung quy định công cụ, ngữ cảnh và nguyên tắc được phép dùng. Khâu tạo sinh do các tác tử viết mã đảm nhiệm.
Xác minh gồm kiểm thử, chạy kịch bản và kiểm tra khi vận hành để xác định thay đổi có hoạt động trước khi hợp nhất hay không. Cổng rà soát là nơi con người hoặc chính sách quyết định cho phép hợp nhất. Sau đó, khâu tích hợp và triển khai đưa thay đổi vào môi trường vận hành, còn dữ liệu đo lường cùng sự cố quay trở lại hàng đợi.
Đây là điểm khác biệt giữa một nhà máy phần mềm và việc chỉ bổ sung tác tử trí tuệ nhân tạo viết mã vào quy trình cũ. Mã có thể được tạo nhanh, nhưng tốc độ đó không có giá trị nếu hệ thống xác minh vẫn chạy theo nhịp của con người.
Tác tử đã thay đổi bộ điều khiển như thế nào?
Tác tử biến xác minh từ một chặng chờ do con người quản lý thành một dịch vụ nằm trong vòng lặp tạo mã. Mọi khâu phía sau phải tiếp nhận, kiểm tra và phản hồi theo tốc độ tác tử tạo ra thay đổi.
Nếu xem quy trình như một vòng điều khiển, ý định là giá trị đặt, tác tử là bộ điều khiển và xác minh là cảm biến. Bộ điều khiển chạy nhanh hơn cảm biến không làm hệ thống nhanh hơn. Nó chỉ lặp lại dựa trên thông tin cũ và có thể phát hành những lỗi mà cảm biến lẽ ra phải phát hiện.
Kỹ sư điều khiển đặt cảm biến trên hệ thống đang chạy vì đó là phép đo phản ánh hành vi thật. Quy trình truyền thống dùng các phương án thay thế rẻ hơn ở từng giai đoạn: kiểm thử đơn vị khi ghi nhận mã, kiểm thử tích hợp trong quy trình tích hợp liên tục, môi trường tiền vận hành dùng chung trước khi phát hành và dữ liệu đo lường sau khi triển khai. Cách đánh đổi độ sát thực tế để lấy tốc độ từng phù hợp khi con người quyết định nhịp làm việc.
Theo ví dụ của The New Stack, một lập trình viên dành hai ngày cho một thay đổi có thể không thấy bốn giờ chờ kết quả từ môi trường tiền vận hành là quá lâu. Một tác tử viết xong thay đổi trong bốn phút sẽ phải dừng lại hoặc tiếp tục bằng những tín hiệu sẵn có. Với nhiều đội ngũ, các tín hiệu đó chỉ đến từ kiểm thử đơn vị và thành phần mô phỏng.
Cảm biến quyết định tác tử có thể đi xa đến đâu
Mức tự chủ của tác tử không thể vượt quá năng lực của cảm biến xác minh. Khi cảm biến chỉ kiểm tra được một phần nhỏ của hệ thống, con người vẫn phải đọc và xác minh thay đổi. Khi cảm biến tạo được bằng chứng đáng tin cậy, tác tử có thể tự lặp cho đến khi đáp ứng yêu cầu.
Năm cấp độ viết mã bằng trí tuệ nhân tạo của Dan Shapiro có thể được đọc như một thang đo về cảm biến xác minh. Ở cấp độ 3, tác tử viết mã còn con người dành cả ngày đọc phần khác biệt giữa các phiên bản. Theo Shapiro, đây là mức mà gần như mọi người đều dừng lại. Ở cấp độ 4, kiểm thử trở thành cảm biến, nhưng độ an toàn phụ thuộc vào môi trường mà các kiểm thử đó sử dụng.
StrongDM gây chú ý với hai quy tắc: “con người không viết mã” và “con người không rà soát mã”. Hệ thống bản sao số của công ty khiến hai quy tắc này khả thi bằng cách cho phép tác tử chạy hàng nghìn kịch bản trên các bản sao hành vi của dịch vụ bên thứ ba. Con người tập trung vào ý định, kiến trúc và những vòng phản hồi chậm thay vì kiểm tra từng thay đổi do một bộ điều khiển tạo ra nhanh hơn tốc độ đọc của họ một trăm lần.
Những đội đang xây hạ tầng cho tác tử trên Kubernetes vì thế cần coi xác minh là một thành phần kiến trúc. Sao chép quy tắc vận hành không khó. Phần tốn kém là xây cảm biến đủ tốt để những quy tắc đó không biến thành nguồn phát hành lỗi.
Ba thuộc tính của cảm biến xác minh
Một cảm biến phù hợp với nhà máy phần mềm tác tử cần có ba thuộc tính: độ trễ thấp, độ sát thực tế cao và đủ băng thông để xác minh nhiều thay đổi cùng lúc. Thiếu một trong ba, vòng lặp sẽ chậm lại, tin vào tín hiệu sai hoặc mất khả năng gắn lỗi với thay đổi đã gây ra lỗi.
Độ trễ
Độ trễ là thời gian từ lúc thay đổi sẵn sàng đến khi cảm biến trả về kết quả đã xác minh trong một môi trường gần với môi trường vận hành. Tín hiệu đến muộn làm vòng lặp mất ổn định vì mọi hành động tiếp theo đều dựa trên một trạng thái đã thay đổi.
Tác tử có thể lặp lại trên mã chưa được xác minh, trong khi các tác tử khác tiếp tục xây trên thay đổi đó. Chỉ số cần theo dõi là thời gian đến tín hiệu, được tính bằng số phút từ khi thay đổi sẵn sàng đến khi có kết quả xác minh.
Độ sát thực tế
Độ sát thực tế cho biết phép đo gần với hành vi của hệ thống thật đến mức nào. Thuộc tính này còn quan trọng hơn độ trễ vì vòng lặp sẽ tin vào cảm biến ngay cả khi cảm biến bị lệch.
Kiểm thử đơn vị và thành phần mô phỏng chỉ cho biết thay đổi hoạt động ra sao trước một mô hình của các phần phụ thuộc. StrongDM từng thấy tác tử trả về giá trị đúng chỉ để vượt qua các kiểm thử hẹp. Công ty đã chuyển các kịch bản ra ngoài kho mã thành một tập dữ liệu giữ lại. Chỉ số phù hợp ở đây là tỷ lệ lỗi lọt qua, tức phần lỗi chỉ được phát hiện sau khi thay đổi đã hợp nhất.
Băng thông
Băng thông là số phép đo cảm biến có thể thực hiện cùng lúc. Đây là thuộc tính chịu áp lực sớm nhất khi số tác tử tăng lên vì mỗi thay đổi cần một kết quả riêng và có thể truy ngược.
Theo tình huống The New Stack nêu, một môi trường tiền vận hành dùng chung chỉ thực hiện được một phép đo tại một thời điểm. Khi kết quả của 50 tác tử bị xếp hàng hoặc trộn chung, đội ngũ không còn xác định được thay đổi nào gây lỗi.
Chỉ số cần đo là năng lực xác minh đồng thời. Nếu hệ thống không gắn được một kết quả thất bại với đúng thay đổi đã tạo ra nó, tác tử cũng không thể dùng kết quả đó để sửa mã.
Mức tự chủ phải đi theo năng lực xác minh
Một nhà máy chỉ có thể tự chủ trong phạm vi cảm biến đủ sức xác minh. Cảm biến càng nhanh, sát thực tế và có băng thông cao, tác tử càng có thể tự sửa và hoàn thành thay đổi mà không cần con người đọc từng dòng mã.
Addy Osmani gọi giới hạn này là áp lực ngược. Nếu chỉ có trình biên dịch và kiểm thử đơn vị, tác tử đưa ra đề xuất còn con người phải xác minh mọi thứ. Khi mỗi thay đổi được kiểm tra trong môi trường gần với môi trường vận hành, tác tử có thể tự lặp cho đến lúc kết quả đạt yêu cầu, còn con người rà soát ý định và bằng chứng.
Theo The New Stack, kỹ sư Anthropic vẫn rà soát mọi thay đổi lớn trong kho mã. Tuy nhiên, họ xem bằng chứng cho thấy thay đổi đáp ứng đúng ý định thay vì đọc từng dòng. Khi có kịch bản giữ lại và khả năng quay lui nhanh, một số nhóm thay đổi đã được xác định trước có thể hợp nhất mà không cần rà soát thủ công.
Các chỉ số đặt giới hạn tự chủ
Cảm biến, không phải mô hình, đặt ra mức tự chủ. Một bộ điều khiển tốt hơn nhưng dựa trên cảm biến sai lệch chỉ đi tới kết quả sai nhanh hơn. Việc con người đọc mọi thay đổi cũng là một loại cảm biến, nhưng có độ trễ tính bằng giờ và băng thông chỉ vài thay đổi cho mỗi người rà soát trong một ngày, theo phân tích của The New Stack.
Số yêu cầu hợp nhất hoặc lượng mã thông báo trên mỗi kỹ sư chỉ phản ánh mức độ hoạt động của tác tử. Thời gian đến tín hiệu, tỷ lệ lỗi lọt qua và năng lực xác minh đồng thời mới cho biết thuộc tính nào của cảm biến đang yếu. Tỷ lệ thay đổi gây lỗi và tỷ lệ phải làm lại cho biết vòng lặp có ổn định hay không.
Hệ thống đám mây nguyên sinh làm bài toán khó hơn
Trong hệ thống đám mây nguyên sinh, cảm biến phải xác minh cả tương tác giữa các dịch vụ chứ không chỉ từng thay đổi riêng lẻ. Đội kỹ thuật cần giữ độ sát thực tế mà vẫn cấp được môi trường đủ nhanh và đủ độc lập cho nhiều tác tử chạy đồng thời.
Trong hệ thống phân tán, lỗi thường xuất hiện tại ranh giới giữa các dịch vụ. Một trường dữ liệu được đổi tên ở dịch vụ này nhưng dịch vụ của đội khác vẫn đọc tên cũ. Một thành phần tiêu thụ dữ liệu giả định thứ tự mà luồng dữ liệu không bảo đảm. Từng thay đổi có thể đúng ở phạm vi riêng nhưng sai khi kết hợp.
Một cảm biến sát thực tế phải bao gồm các dịch vụ thật xung quanh thay đổi. Độ sát thực tế đòi hỏi những thành phần lân cận đó, còn độ trễ và băng thông đòi hỏi mỗi thay đổi có được môi trường tương ứng trong vài phút. Theo The New Stack, phần lớn đội ngũ chỉ đạt được hai trong ba thuộc tính.
Các cách cấp môi trường đều có đánh đổi
Xác minh một nhóm yêu cầu hợp nhất trên môi trường dùng chung giữ được độ sát thực tế nhưng mất độ trễ và băng thông. Môi trường thật chỉ đọc được một lượt tại một thời điểm và có thể trả kết quả sau nhiều giờ, nằm ngoài vòng lặp của tác tử. Gom nhiều thay đổi vào cùng lượt kiểm thử còn khiến đội ngũ không biết thay đổi nào tạo ra kết quả thất bại.
Nhân bản toàn bộ hệ thống hoặc phần lớn hệ thống cho từng thay đổi giúp tăng độ sát thực tế và khả năng cô lập. Đổi lại, theo The New Stack, quá trình cấp phát mất hàng chục phút, lâu hơn nhiều so với một lần thử của tác tử. Chi phí cũng tăng theo từng tác tử chạy đồng thời, buộc đội ngũ chỉ dùng cách này cho những thay đổi đủ quan trọng.
Bản sao hành vi phù hợp với dịch vụ bên thứ ba có hành vi công khai ổn định. Với 150 dịch vụ nội bộ trong ví dụ của The New Stack, mỗi bản sao lại trở thành một cách triển khai thứ hai có thể lệch khỏi dịch vụ thật đang chạy trong cụm. Ở quy mô lớn, nhà máy cần cấp cho từng tác tử và từng thay đổi một môi trường thực tế, nơi các dịch vụ thật trả lời lời gọi mà không phải sao chép toàn bộ hệ thống.
Thiết kế vòng đời phát triển phải bắt đầu từ cảm biến
Đội kỹ thuật nên đo năng lực xác minh hiện có trước khi tăng số tác tử hoặc lượng mã được tạo. Ba chỉ số cần theo dõi là thời gian đến tín hiệu, tỷ lệ lỗi lọt qua và năng lực xác minh đồng thời.
Khoảng cách giữa đội ngũ hợp nhất hơn 30.000 thay đổi mỗi ngày và phần còn lại không nằm ở việc ai có tác tử. Theo số liệu Anthropic được The New Stack dẫn lại, khác biệt nằm ở hệ thống phân phối đã được xây lại quanh một cảm biến có thể trả kết quả trong vài phút, phản ánh hệ thống thật và chạy đồng thời cho từng thay đổi.
Trong môi trường đám mây nguyên sinh, đây là phần khó xây nhất. Nó quyết định việc bổ sung tác tử sẽ giúp phát hành nhiều phần mềm hơn hay chỉ tạo thêm lỗi nhanh hơn.
Nếu đang thiết kế một nhà máy phần mềm tác tử, hãy bắt đầu bằng việc đo cảm biến xác minh hiện có trước khi tăng thêm tác tử.
