Lý thuyết tiến hóa phần mềm trong kỷ nguyên AI

Trong nhiều doanh nghiệp ngày nay, hầu hết việc ra quyết định, thực thi, xác minh và cải thiện diễn ra trên hệ thống phần mềm. Các điểm tiếp xúc với khách hàng, thay đổi về giá và hợp đồng, điều chỉnh nguồn cung và tồn kho, hoạt động thu thập, phân tích log cùng quy trình nội bộ đều phụ thuộc sâu vào phần mềm. Đây không còn là giai đoạn CNTT chỉ đóng vai trò hỗ trợ; hoạt động kinh doanh giờ gắn liền với trạng thái của phần mềm, còn khả năng cập nhật phần mềm cũng chính là khả năng thay đổi doanh nghiệp.

Tình huống này không giới hạn ở ngành cụ thể. Trong mọi lĩnh vực và ở nhiều quy mô, doanh nghiệp vận hành với tốc độ và độ phức tạp nhất định sẽ không thể hoạt động nếu thiếu phần mềm ở vị trí cốt lõi. Khi điều kiện bên ngoài thay đổi nhanh hơn và chu kỳ ra quyết định–thực thi diễn ra thường xuyên hơn, chính khả năng thay đổi trở thành một lợi thế cạnh tranh. Khi giá trị dành cho khách hàng, điều kiện dịch vụ, ràng buộc vận hành, yêu cầu pháp lý và cơ cấu chi phí cùng thay đổi, doanh nghiệp không thể cập nhật phần mềm sẽ không thể biến quyết định thành hành động, không thể điều chỉnh hướng đi và cuối cùng sẽ đình trệ.

Trong môi trường này, việc cập nhật phần mềm thường trở thành nút thắt cản trở quá trình ra quyết định và thay đổi chính sách kinh doanh. Quyết định có thể được đưa ra, nhưng thay đổi cấu trúc cần thiết để thực thi không thể hoàn thành kịp thời, thu hẹp phạm vi sáng kiến có thể thực sự được kiểm nghiệm.

Thời gian cập nhật phần mềm càng dài, khoảng cách giữa quyết định và thực thi càng lớn. Trong thời gian trì hoãn đó, điều kiện môi trường tiếp tục thay đổi. Kết quả là nhiều quyết định hơn không được thực thi, và phạm vi vận hành của doanh nghiệp dần thu hẹp.

Khi nhìn vào phần mềm đã được sử dụng trong thời gian dài, hiếm khi thấy hệ thống giữ nguyên trạng thái ban đầu. Các tính năng được bổ sung, cấu hình được thay đổi, quy trình vận hành được điều chỉnh và phần mềm dần mang hình hài rất khác so với thiết kế ban đầu. Thông số kỹ thuật hay tài liệu thiết kế ban đầu hiếm khi còn hoàn toàn khớp với cách triển khai và vận hành sau nhiều năm. Điều đó không có nghĩa thiết kế ban đầu là vô ích; nó chỉ cho thấy những tiền đề ban đầu khó có thể được giữ nguyên trong suốt thời gian vận hành dài.

Khi phần mềm tiếp tục được sử dụng, những tác vụ và quyết định không được dự kiến từ đầu dần trở thành một phần của công việc hằng ngày. Hành vi người dùng thay đổi, khối lượng cùng ý nghĩa của dữ liệu phát triển và mối quan hệ với các hệ thống xung quanh cũng dịch chuyển. Các bước xử lý bổ sung, hoạt động tái tổ chức, thay thế và giải pháp tạm thời cứ thế tích lũy. Những gì ban đầu chỉ là ngoại lệ nhỏ cuối cùng trở thành thông lệ, và những thông lệ mới này buộc cấu trúc nội bộ phải mở rộng vượt khỏi thiết kế ban đầu. Theo thời gian, thiết kế từng đơn giản trở nên phức tạp hơn khi hấp thụ nhu cầu thực tế.

Cũng hiếm khi cùng một nhóm người chịu trách nhiệm suốt vòng đời hệ thống. Đội ngũ phát triển và vận hành thay đổi, cơ cấu tổ chức phát triển và vai trò được phân công lại. Ngay cả khi tài liệu vẫn còn, bối cảnh và những tiền đề đằng sau các quyết định trước đây thường không được truyền đạt đầy đủ. Điều bị mất không phải là lượng thông tin, mà là tập hợp bối cảnh từng khiến các quyết định trước đây trở nên hợp lý. Khi những giả định đó phai nhạt, cùng một văn bản không còn dẫn mọi người tới cùng một kết luận. Thay đổi trở nên thận trọng hơn, giải pháp cục bộ tăng, và tính nhất quán tổng thể dần suy giảm.

Những thay đổi này không phát sinh từ sự cố cụ thể hay hoàn cảnh đặc biệt. Những mô hình tương tự lặp lại ở nhiều tổ chức, ngành nghề và lĩnh vực kỹ thuật khác nhau. Điểm chung là phần mềm được sử dụng lâu dài trong khi các điều kiện xung quanh không ngừng thay đổi. Dù bản chất của sự thay đổi khác nhau theo từng bối cảnh, thay đổi là điều luôn hiện hữu ở mọi nơi.

Khác biệt nhỏ trong giả định tích lũy theo thời gian. Những điều chỉnh nhỏ từng có thể được xử lý trong công việc hằng ngày cuối cùng cũng buộc tổ chức phải xem xét lại cấu trúc. Khi đó, mức độ phức tạp và phạm vi của thay đổi đều tăng lên. Khi phạm vi ảnh hưởng mở rộng, chi phí kiểm chứng tăng, việc rollback khó hơn và quá trình ra quyết định chậm lại. Khi quyết định chậm, doanh nghiệp không thể kiểm nghiệm điều muốn thử. Đây không phải là trạng thái chất lượng thấp, mà là trạng thái trong đó khả năng học hỏi bị kìm hãm — và môi trường thay đổi càng nhanh, tác hại càng lớn.

Nhiều dự án phát triển truyền thống cố gắng hoàn thiện thiết kế ở mức tối đa trước khi bắt đầu triển khai. Cách tiếp cận này hữu ích cho việc xây dựng đồng thuận, phân công công việc và quản lý dự án quy mô lớn. Trong môi trường chi phí triển khai cao và thử nghiệm tốn kém, củng cố thiết kế sớm là lựa chọn thực tế, và thiết kế giúp giảm độ phức tạp ngay từ đầu.

Tuy nhiên, cách tiếp cận này có một giới hạn cố hữu liên quan đến thời gian. Ngay từ khi thiết kế hoàn tất, những điều kiện mà thiết kế giả định đã bắt đầu thay đổi. Khoảng cách từ lúc hoàn tất thiết kế đến khi triển khai càng dài, chênh lệch giữa giả định và thực tế càng lớn. Khi điều kiện thay đổi nhanh, độ lệch này có thể trở nên đáng kể vào lúc hệ thống hoàn thành. Những thứ thay đổi thường không phải là chi tiết kỹ thuật nhỏ, mà là ưu tiên cốt lõi, ràng buộc vận hành hoặc ý nghĩa của dữ liệu.

Điều này không hàm ý thiết kế sai. Trong nhiều trường hợp, đó là quyết định tốt nhất có thể vào thời điểm đó. Vấn đề phát sinh khi thiết kế không tính đến việc các giả định sẽ thay đổi theo thời gian. Nếu khả năng điều chỉnh sau khi hoàn thành không được tính đến trong thiết kế, hệ thống sẽ trở nên khó cập nhật ngay khi vừa hoàn thành. Khi việc hoàn thành được coi là điểm kết thúc, các thay đổi sau đó bị xử lý như ngoại lệ và tích lũy thành những phần bổ sung chắp vá. Theo thời gian, cập nhật chồng chất thành sửa chữa cục bộ, cấu trúc cứng lại, và tốc độ học tập của doanh nghiệp giảm.

Cách tiếp cận phát triển này xuất hiện vì lý do rõ ràng. Chi phí triển khai cao và gánh nặng thử nghiệm lớn khiến lập kế hoạch sớm trở nên thiết yếu. Trong môi trường đó, khả năng đánh giá điều kiện, sắp xếp các quan hệ phụ thuộc và xác định trước hình hài hoàn chỉnh của hệ thống đóng vai trò quan trọng. Xây dựng đồng thuận, phòng ngừa rủi ro và phân công lao động có cấu trúc là nhu cầu thực tế.

Khi điều kiện thay đổi, trọng tâm của giá trị cũng thay đổi. Những phán đoán, thất bại và lần điều chỉnh trong quá khứ không mất giá trị; chúng chỉ được tham khảo và vận dụng theo cách khác. Kinh nghiệm từ các lần review thiết kế không còn được dùng để dự đoán hoàn hảo tương lai, mà để nhận ra những điểm hệ thống có thể gặp lỗi khi thay đổi. Bài học vận hành cho biết nền tảng nào nên giữ cố định và vùng nào nên giữ linh hoạt. Kinh nghiệm quá khứ không bị loại bỏ; nó được tái sử dụng.

Khi tái sử dụng trở nên khả thi, giá trị kinh nghiệm thường tăng thay vì giảm. Trong môi trường thay đổi nhanh, tác động của một phán đoán sai cũng bị khuếch đại nhanh chóng. Chi phí thử nghiệm thấp hơn đồng nghĩa với nhiều lần thử hơn — và cả nhiều lần thử sai hơn. Kết quả là chất lượng của việc xác lập ưu tiên và phán đoán hướng đi có ảnh hưởng lớn hơn đến kết quả.

Những năm gần đây, thay đổi rõ ràng đã xuất hiện trong điều kiện phát triển. Chi phí triển khai và thử nghiệm đã giảm, và thời gian cần để biến giả thuyết thành dạng có thể kiểm nghiệm đã rút ngắn. Sự dịch chuyển này một phần đến từ việc các công cụ phát triển dùng AI để trực tiếp tạo và sửa code ngày càng phổ biến. Các công cụ này giảm chi phí kiểm chứng ban đầu của việc triển khai, đồng thời giúp việc thử nghiệm, loại bỏ và tái cấu trúc thiết kế trở nên khả thi trong thực tế.

Điều quan trọng ở đây không phải là có áp dụng AI hay không, mà là các điều kiện phát triển đã thay đổi. Khi điều kiện thay đổi, cấu trúc phù hợp với những điều kiện đó cũng phải thay đổi.

Điều quan trọng là không nên đặt phát triển bằng AI đối lập với phát triển do con người thực hiện. Điều đang diễn ra là sự kết hợp giữa phán đoán của con người — như xác lập ưu tiên, quyết định cấu trúc và hiểu bối cảnh — với khả năng tạo, sửa code do AI hỗ trợ. Con người quyết định thử gì và thay đổi ở đâu; AI giảm chi phí triển khai những quyết định đó. Sự kết hợp này cho phép thử nghiệm và học hỏi với tốc độ mà trước đây không thể đạt được trong thực tế.

Nhờ đó, lần đầu tiên mô hình phát triển liên tục cập nhật phần mềm theo nhịp thay đổi của doanh nghiệp trở thành một lựa chọn thực tế.

Trong những điều kiện này, cấu trúc dễ điều chỉnh về sau sẽ dễ quản lý hơn cấu trúc cố định mọi thứ từ đầu. Khi quy mô mở rộng và yêu cầu thay đổi, khả năng xem xét lại, sửa đổi cấu trúc trở thành điều kiện tiên quyết. Điều này không có nghĩa từ bỏ thiết kế. Điều đó có nghĩa là thu hẹp phần nền tảng phải cố định, xác định rõ phần nào cần linh hoạt và duy trì khả năng từng bước tái tổ chức cấu trúc theo thứ tự ưu tiên rõ ràng. Vì vậy, thiết kế nền tảng trở nên quan trọng hơn chứ không hề kém quan trọng.

Khi hệ thống mở rộng, hạ tầng tất yếu bị thay thế. Một cấu hình từng đủ dùng rồi sẽ cần thêm dự phòng, phân vùng, phân tán, khả năng quan sát và cơ chế phục hồi. Vận hành liên tục mang đến nhu cầu tái tổ chức và mở rộng tính năng. Trong môi trường thực, nâng cấp, hạ cấp, rollback, di chuyển theo giai đoạn, vận hành song song và thay thế từng phần là hoạt động thường nhật — không phải sự cố đặc biệt. Cấu trúc không hỗ trợ chuyển đổi qua lại sẽ làm tăng rủi ro và chi phí sau mỗi thay đổi, cuối cùng khiến quá trình cập nhật đình trệ.

Vì lý do này, cấu trúc phần mềm phải hỗ trợ việc đảo ngược và thay thế. Khi ranh giới không rõ ràng và hệ thống chỉ phát triển theo một hướng, thay đổi sẽ lan rộng, việc kiểm chứng trở nên nặng nề và rollback khó khăn. Ranh giới rõ ràng và các mô-đun có thể thay thế giúp quá trình học hỏi tiếp tục qua mỗi thay đổi.

Không thể phó mặc những quyết định này cho cách làm tùy hứng của từng cá nhân. Việc xác định phần nào giữ cố định, phần nào giữ linh hoạt và thay đổi nào có thể chấp nhận được phải được coi là giả định chung. Điều này đòi hỏi nhiều hơn việc chọn công cụ hay tiêu chuẩn code; nó cần sự thống nhất về cách thức hành động. Khi thiếu định hướng chung như vậy, hoạt động cập nhật sẽ phụ thuộc vào từng cá nhân, tốc độ chậm lại và quá trình học hỏi đình trệ.

Mỗi khi điều kiện thay đổi, cả phần mềm lẫn hoạt động kinh doanh đều xuất hiện thêm những ràng buộc mới. Mặc dù thiết kế và triển khai trước đây có thể không còn áp dụng trực tiếp, điều này không làm mất giá trị kinh nghiệm đằng sau chúng.

Kinh nghiệm hình thành từ những thay đổi trước — biết hệ thống dễ hỏng ở đâu, nút thắt xuất hiện tại đâu và tác động lan xa đến mức nào — tiếp tục được vận dụng khi điều kiện lại thay đổi. Ngay cả khi hình thức thay đổi, những phán đoán này tái xuất hiện khi quyết định thử gì tiếp theo và can thiệp ở đâu.

Trong môi trường phát triển hiện đại, sự kết hợp giữa khả năng phán đoán theo bối cảnh của con người và công cụ triển khai có AI hỗ trợ giúp kinh nghiệm được vận dụng nhanh hơn nhiều. Kiến thức tích lũy vẫn thể hiện qua chất lượng phán đoán và trực tiếp định hướng cho lần triển khai, kiểm chứng kế tiếp.

Nhờ đó, hệ thống không phải được xây lại từ đầu sau mỗi thay đổi, nhưng cũng không bị buộc phải giữ nguyên hình thái cũ. Thay vào đó, kinh nghiệm được tái sử dụng khi điều kiện dịch chuyển, và phần mềm tiến hóa tương ứng.

Thay đổi sẽ tiếp tục. Công nghệ và ràng buộc mới sẽ xuất hiện. Nhưng kinh nghiệm tích lũy sẽ không bị mất. Khi kinh nghiệm được tái sử dụng nhanh hơn và thường xuyên hơn, giá trị của nó cũng được phản ánh trực tiếp, nhất quán hơn trong kết quả.