Khi mã nguồn trở nên rẻ tiền: Chúng ta đã mất gì trong quá khứ và bài học cho kỷ nguyên AI

Khi mã nguồn trở nên rẻ tiền: Chúng ta đã mất gì trong quá khứ và bài học cho kỷ nguyên AI

Tôi từng làm việc tại một startup gọi là Heartland Information Services ở Toledo. Chúng tôi cung cấp dịch vụ phiên âm y tế cho một số bệnh viện lớn nhất nước Mỹ, và quy mô của chúng tôi không hề nhỏ. Heartland là một trong những tổ chức phiên âm y tế lớn nhất cả nước, đóng vai trò trung tâm trong làn sóng chuyển dịch phiên âm ra nước ngoài vào thời điểm đó. Mặc dù nghe có vẻ đơn giản, nhưng chúng tôi là loại dịch vụ mà thời gian chết (downtime) sẽ dẫn đến những hậu quả thực sự. Hãy tưởng tượng bạn cần phẫu thuật cấp cứu nhưng lại phải chờ bản ghi chép văn bản về quy trình thủ thuật. Việc chờ đợi có thể không phải là một lựa chọn.

Bóng cricket được sản xuất tại Ấn Độ

Các kỹ sư mà chúng tôi làm việc cùng tại Ấn Độ đều rất tài năng. Công ty hoạt động theo mô hình lai, và tại nhiều thời điểm, những công việc quan trọng nhất của chúng tôi được phát triển ở nước ngoài và triển khai tại Mỹ. Lý do rất đơn giản: chi phí. Phát triển phần mềm thuê ngoài (offshore) rẻ hơn rất nhiều, và đối với một startup phải tính toán từng đồng, khoản tiết kiệm này là không thể bỏ qua. Đây cũng là xu hướng của thời đại đó, khi Thomas Friedman tuyên bố "Thế giới phẳng" và các lập trình viên trong nước bắt đầu lo lắng. Câu hỏi trong tâm trí mọi người là liệu công việc của họ có phải là người tiếp theo bị cắt giảm không.

Mã nguồn được tạo ra rất tốt. Các kỹ sư là những người tài năng nhất mà tôi từng làm việc cùng. Tuy nhiên, có những khoảnh khắc — điều không thể tránh khỏi trong bất kỳ hệ thống phân tán nào của con người — nơi sự hiểu biết về tại sao một thứ gì đó được xây dựng theo một cách nhất định lại nằm ở một bên bán cầu, trong khi trách nhiệm bảo trì nó lại nằm ở bên kia. Kiến thức đó có tồn tại ở đâu đó, chỉ là nó không luôn ở nơi bạn cần, vào lúc bạn cần.

Gần đây, tôi thường nghĩ về Heartland, vì động thái này có vẻ rất quen thuộc.

Chi phí sản xuất mã nguồn đã sụt giảm mạnh. Các công cụ AI có thể tạo ra các đoạn mã chức năng, đầy đủ và ở mức trung bình với tốc độ và chi phí mà ngay cả 5 năm trước cũng khó có thể tưởng tượng nổi. Và giống như làn sóng gia công đầu những năm 2000, yếu tố kinh tế ở đây là có thật và hợp lý. Không ai sai khi sử dụng các công cụ này. Mã nguồn chúng tạo ra thường khá ổn. Nó hoạt động. Nó vượt qua các bài kiểm thử. Nó có thể được đưa ra thị trường ngay lập tức.

Nhưng chúng ta đã từng thấy mô hình này rồi. Khi việc sản xuất mã nguồn trở nên rẻ, chi phí không biến mất, nó di chuyển sang chỗ khác. Nó chuyển từ việc tạo ra sang việc hiểu nó. Đây là lập luận cốt lõi của cuốn sách Prediction Machines: khi một đầu vào cơ bản trở nên rẻ, giá trị sẽ chuyển sang các yếu tố bổ trợ của nó. Trong phần mềm, yếu tố bổ trợ của việc sản xuất luôn là sự thấu hiểu. Kỷ nguyên gia công đã dạy chúng ta rằng phần đắt đỏ của phần mềm không bao giờ là việc viết nó. Đó là việc hiểu nó đủ tốt để thay đổi nó một cách an toàn, để gỡ lỗi dưới áp lực, để giải thích cho người tiếp theo lý do tại sao một quyết định cụ thể lại được đưa ra vào 2 giờ sáng ngày thứ Ba.

Sự khác biệt lần này mang tính cấu trúc. Với gia công, kiến thức tồn tại trong đầu một con người. Một lập trình viên ở Delhi hay Bangalore hiểu ý định, ngay cả khi việc chuyển sự hiểu biết đó qua các múi giờ và ranh giới tổ chức là khó khăn. Với mã nguồn do AI tạo ra, kiến thức đó có thể không tồn tại ở bất cứ đâu. Không có con người nào ở phía bên kia từng nắm giữ bức tranh toàn cảnh. Mã nguồn đã được commit, đúng về mặt cú pháp nhưng lại thiếu vắng ý định.

Đây không phải là lập luận chống lại sự phát triển có hỗ trợ của AI. Tôi sử dụng các công cụ này mỗi ngày và chúng thực sự giúp tôi làm việc nhanh hơn. Nhưng năng suất chỉ được đo bằng số dòng mã tạo ra là một chỉ số mà chúng ta đã từ chối từ nhiều thập kỷ trước vì những lý do chính đáng. Kỷ nguyên gia công cuối cùng đã dạy cho hầu hết các tổ chức rằng giải pháp không phải là ngừng làm việc với các nhóm phân tán. Giải pháp là đầu tư có chủ đích vào ngữ cảnh chung, tài liệu, xem xét mã (code review) và công việc chậm chạp nhằm xây dựng sự thấu hiểu lẫn nhau. Những công ty phát triển mạnh mẽ là những công ty coi việc thấu hiểu là một mối quan tâm kỹ thuật hàng đầu, không phải là một sản phẩm phụ của sự gần gũi.

Chúng ta cần khoản đầu tư tương tự ngay bây giờ. Nếu mã nguồn trung bình là rẻ, thì nguồn lực khan hiếm không còn là khả năng sản xuất nó. Nguồn lực khan hiếm là khả năng đọc nó, điều hướng nó, biết được phần nào quan trọng và tại sao. Joel Spolsky đã viết hơn hai mươi lăm năm trước rằng "việc đọc code còn khó hơn cả việc viết code". Điều đó đúng lúc bấy giờ. Và nó không thể phủ nhận là đúng ngay bây giờ. Chúng ta cần các công cụ được xây dựng để thấu hiểu, không chỉ để sản xuất. Chúng ta cần các thực hành coi việc thấu hiểu là thứ mà bạn xây dựng có chủ đích, không phải là thứ bạn hy vọng nó sẽ tự xuất hiện.

Tôi nghĩ đây là điều mà các công cụ dành cho nhà phát triển nên giải quyết tiếp theo. Không chỉ giúp chúng ta viết code nhanh hơn, mà còn giúp chúng ta hiểu code chúng ta đã có, code chúng ta kế thừa, và code đến dưới dạng hoàn chỉnh từ một cỗ máy dự đoán thực sự không biết hay hiểu thế giới chúng ta đang sống. Đó là nơi nghề nghiệp này đang tồn tại ngay bây giờ.