AI không thể tạo ra sản phẩm hoàn chỉnh: Khoảng cách từ bản mẫu đến hệ thống thực tế vẫn cần tư duy kỹ thuật

Việc xây dựng phần mềm chưa bao giờ mang lại cảm giác dễ dàng đến thế. Bạn mô tả một ý tưởng bằng ngôn ngữ tự nhiên, và chỉ trong vài phút, một bản mẫu (prototype) hoạt động được sẽ xuất hiện trên màn hình. Nó có giao diện người dùng (UI). Nó kết nối với cơ sở dữ liệu. Nó thực hiện đúng những gì bạn hình dung. Đối với một người chưa từng viết một dòng code nào, khoảnh khắc đó thật kỳ diệu. Đối với một người đã dành nhiều năm vật lộn với trình biên dịch và các bản ghi lỗi (stack traces), điều đó thực sự đáng kinh ngạc.

Bản mẫu chạy được trên máy tính xách tay của bạn. Nó bị lỗi khi chịu tải. Nó không có cơ chế xử lý lỗi. Bạn phát hiện ra rằng nó có thể đang làm rò rỉ các API token của mình. Mô hình dữ liệu có vẻ hợp lý cho bản demo nhưng lại sụp đổ ngay khi bạn thêm người dùng thứ hai. Xác thực người dùng chỉ được duy trì bằng những giả định. Bạn luôn canh cánh nỗi lo liệu mọi thứ có an toàn hay không. Bạn muốn triển khai nó, và đột nhiên bạn đứng trước một vực thẳm giữa "nó chạy được" và "nó sẵn sàng để sử dụng".

Việc tạo ra một bản mẫu chưa bao giờ là phần khó nhất.

Các kỹ sư phần mềm luôn có khả năng tạo ra thứ gì đó chạy được một cách nhanh chóng. Điều tốn thời gian là tất cả những thứ còn lại: thiết kế các hệ thống có khả năng chịu tải tốt, xử lý các trường hợp người dùng không nên gặp phải nhưng chắc chắn sẽ gặp, xây dựng khả năng quan sát (observability) để bạn biết khi nào hệ thống gặp sự cố, và đưa ra những quyết định có chủ đích về kiến trúc dữ liệu mà bạn sẽ ít phải hối tiếc hơn sau ba năm nữa. Không có điều nào trong số đó thay đổi cả. AI đã đẩy nhanh đáng kể con đường dẫn đến phiên bản hoạt động đầu tiên. Nó không hề rút ngắn khoảng cách giữa phiên bản hoạt động đầu tiên và một sản phẩm đạt chuẩn thương mại (production-grade).

Sự nhầm lẫn nảy sinh vì vòng lặp phản hồi cho giai đoạn đầu của hành trình đã trở nên quá nhanh và quá thỏa mãn. Bạn yêu cầu, bạn nhận được, bạn thấy kết quả. Chu kỳ đó thực sự thú vị, và nó tạo ra ấn tượng rằng phần còn lại của quá trình phát triển phần mềm cũng phải được rút gọn tương tự. Thực tế không phải vậy. Những vấn đề khó khăn trong việc xây dựng phần mềm chưa bao giờ chủ yếu nằm ở việc viết cú pháp. Chúng nằm ở khả năng phán đoán: xây dựng cái gì, cấu trúc nó ra sao, cái gì nên trì hoãn, khi nào nên nói không. Khả năng phán đoán đó chính là thứ biến một "vibe-coder" thành một nhà điêu khắc, một nghệ nhân. Đó cũng là thứ phân biệt một bản mẫu với một hệ thống đạt chuẩn thương mại.

Lập luận sai lầm về việc không cần học khoa học máy tính.

Như dự đoán, sự dễ tiếp cận của code do AI tạo ra đã tạo nên một làn sóng những người mới gia nhập ngành, những người đang đặt câu hỏi liệu việc học khoa học máy tính (computer science) còn ý nghĩa hay không. Nếu bạn có thể mô tả để tạo ra một ứng dụng hoạt động được, tại sao phải mất nhiều năm nghiên cứu thuật toán, cấu trúc dữ liệu, hệ điều hành và lý thuyết?

Giá trị của việc học khoa học máy tính chưa bao giờ chỉ nằm ở khả năng tạo ra code. Nó nằm ở việc phát triển một mô hình tư duy về cách các hệ thống vận hành, cách chúng thất bại và tại sao lại như vậy. Mô hình đó là thứ cho phép bạn nhìn vào code do AI tạo ra và nhận ra rằng truy vấn mà nó viết sẽ gây ra tình trạng quét toàn bộ bảng (full table scan) trên một bảng có năm mươi triệu dòng. Đó là thứ cho phép bạn thấy rằng chiến lược bộ nhớ đệm (caching) mà nó đề xuất sẽ tạo ra tình trạng tranh chấp (race condition) khi có tải đồng thời. Đó là thứ cho bạn biết rằng kiến trúc mà nó gợi ý giải quyết được vấn đề bạn mô tả nhưng sẽ làm cho vấn đề tiếp theo trở nên khó khăn hơn đáng kể.

Nếu không có nền tảng đó, bạn hoàn toàn phụ thuộc vào khả năng phán đoán của mô hình. Và các mô hình thì không có khả năng phán đoán. Chúng chỉ có khả năng khớp mẫu (pattern matching), với sự nhiệt tình tạo ra code mà nó tin rằng khớp với ý định của bạn. Chúng sẽ tự tin tạo ra đoạn code trông có vẻ đúng, tuân thủ các quy ước, nhưng lại thất bại trong môi trường thực tế theo những cách mất hàng ngày trời để chẩn đoán nếu bạn không biết mình đang tìm kiếm điều gì.

Có thể nói đây là thời điểm tốt nhất trong lịch sử để học khoa học máy tính, vì khoảng cách giữa sự hiểu biết và kết quả đầu ra đã bị xóa bỏ. Một sinh viên thực sự nắm vững cách một hệ thống phân tán hoạt động giờ đây có thể xây dựng nó trong thời gian chỉ bằng một phần nhỏ so với một thập kỷ trước.

Điều gì thay đổi, và điều gì không.

Nhu cầu đối với các kỹ sư chỉ có thể viết code một cách máy móc, và những người chỉ biết dịch các yêu cầu thành các dòng lệnh, đang thực sự suy giảm. Phần đó của công việc đang được tự động hóa.

Điều đang xảy ra là sự thu hẹp ở phân khúc năng suất thấp và sự mở rộng giới hạn cho những người ở phân khúc cao nhất. Một kỹ sư giàu kinh nghiệm sử dụng các công cụ AI hiện đại có thể làm việc với tốc độ không tưởng cách đây năm năm. Không phải vì các vấn đề khó đã biến mất, mà vì công việc máy móc vốn tiêu tốn quá nhiều thời gian và sự chú ý đã được xử lý phần lớn. Bạn sẽ có nhiều thời gian hơn trong ngày cho những công việc thực sự đòi hỏi chuyên môn.

Những kỹ sư bị bỏ lại phía sau không phải là những người thiếu kỹ năng AI. Họ là những người sử dụng AI để thay thế cho sự hiểu biết, những người "vibe-code" qua các hệ thống mà họ không thể lý giải, để rồi thấy mình không thể sửa chữa những gì bị hỏng, không thể mở rộng những gì đang phát triển, và không thể giải thích những gì mình đã xây dựng cho bất kỳ ai cần bảo trì nó.

Học cách vận hành ở một cấp độ khác.

Sự thay đổi cần thiết không nằm ở việc áp dụng một bộ công cụ mới. Nó nằm ở việc vận hành ở một cấp độ trừu tượng cao hơn trong khi vẫn giữ vững nền tảng cơ bản. Sự kết hợp đó thực sự mạnh mẽ và thực sự hiếm có.

Những kỹ sư sẽ vượt xa đồng nghiệp trong vài năm tới là những người coi AI là công cụ nhân bản sức mạnh (force multiplier) cho kiến thức chuyên sâu thay vì là vật thay thế cho nó. Họ hiểu những gì họ đang yêu cầu mô hình tạo ra. Họ xem xét code được tạo ra với con mắt phê bình giống như cách họ đánh giá một pull request của kỹ sư cấp dưới. Họ mang tư duy kiến trúc vào cuộc đối thoại, chứ không chỉ là các mô tả tính năng. Họ biết khi nào cần phản biện lại những gì mô hình đề xuất.

Đó là bộ kỹ năng cũ, được áp dụng vào một bối cảnh mới, với đòn bẩy cao hơn đáng kể.

Bản mẫu chỉ là phần dễ. Sự khác biệt bây giờ là ai cũng có thể thấy rõ điều đó. Những gì đến sau bản mẫu vẫn rất khó, vẫn đòi hỏi khả năng phán đoán kỹ thuật thực thụ, và vẫn là thứ phân biệt những người xây dựng phần mềm đáng tin cậy với những người chỉ tạo ra các bản demo.

Hãy học các nguyên lý cơ bản. Sau đó hãy học các công cụ mới. Theo đúng thứ tự đó.