Vượt ra ngoài khả năng ghi nhớ: Ảo tưởng về năng lực trong thời đại AI

Có hai quan điểm trái chiều thường thấy về AI và lập trình: một bên cho rằng AI gần như vô dụng vì viết code tệ, sửa lỗi còn lâu hơn tự viết; bên kia tin rằng code do AI tạo ra quá tốt và sẽ khiến lập trình viên trở nên lỗi thời. Nhưng cả hai đều tập trung nhầm chỗ, bởi vì họ quá chú trọng đến việc ai viết code.

Chúng ta chưa bao giờ tự viết toàn bộ code

Tôi chưa bao giờ coi việc ghi nhớ cú pháp hay gõ code từ trí nhớ là kỹ năng quan trọng trong công việc. Tôi dùng tài liệu, tìm kiếm trên internet, copy ví dụ từ Stack Overflow, đọc blog và xem code của đồng nghiệp.

Trong một hệ thống phần mềm hiện đại, điều này gần như là bắt buộc. Một ứng dụng điển hình có thể liên quan đến TypeScript, Python hoặc Go, YAML, Dockerfile, SQL, file cấu hình, pipeline CI/CD và hàng tá công nghệ khác. Không ai có thể nhớ hết mọi chi tiết của tất cả chúng.

Vậy nếu copy code hữu ích từ Stack Overflow luôn được chấp nhận, thì việc nhờ máy móc tạo ra code đó có gì khác biệt về bản chất?

Sở hữu chưa bao giờ là chuyện tác giả

Có một lý do khác khiến tôi thấy lập luận "AI viết code" không thuyết phục: Chúng ta luôn làm việc trên những hệ thống mà mình không viết ra.

Bạn tiếp nhận một service từ team khác. Một người đã nghỉ việc viết nửa số code. Ba người khác đóng góp vào phần bạn đang phụ trách, và bạn thậm chí không nhớ ai viết function nào. Nhưng sau một thời gian làm việc với hệ thống, bạn bắt đầu coi nó như "của mình". Tại sao?

Không phải vì bạn viết từng dòng code. Mà vì bạn hiểu nó.

Bạn biết nó làm gì. Bạn biết tại sao nó hành xử như vậy. Bạn biết ranh giới của nó, các dependency của nó và điều gì xảy ra khi có sự cố.

Đó mới là cảm giác sở hữu thực sự.

Thứ nguy hiểm để giao ra ngoài

Đây là điểm khiến AI hỗ trợ lập trình trở nên thú vị. Vấn đề không phải máy viết code, mà là bạn dễ dàng để nó chiếm luôn phần tư duy.

Có sự khác biệt lớn giữa việc nói "Tôi hiểu chuyện gì cần xảy ra, hãy viết giúp tôi" và việc nói "làm cho nó chạy được" rồi chấp nhận bất cứ thứ gì trả về.

Trong trường hợp đầu, bạn đã ủy thác việc gõ phím; còn trường hợp sau, bạn đã ủy thác cả sự thấu hiểu. Hai việc này hoàn toàn không tương đương.

Debug là nơi sự thật lộ diện

Viết code thì dễ giao ra ngoài. Debug thì khó giao hơn nhiều nếu không muốn đánh mất thứ quan trọng.

Khi bạn tự debug một hệ thống, bạn buộc phải xây dựng một mô hình tinh thần về nó. Bạn có kết quả mong đợi. Điều gì đó khác đã xảy ra. Bạn suy ngược: lẽ ra điều gì phải xảy ra? Điều gì cần xảy ra để tạo ra kết quả quan sát được? Ở khâu nào thực tế đã lệch khỏi kỳ vọng?

Sau nhiều lần như vậy, bạn phát triển được thứ cực kỳ giá trị: trực giác về cách hệ thống vận hành.

Tôi từng làm việc với những dev thiếu kỹ năng này. Khi có lỗi, họ sửa đại, bắn súng trong đêm tối cho đến khi tình cờ có thứ hoạt động, nhưng họ không hiểu vì sao. Đó không phải là debug.

AI khiến việc rơi vào kiểu này trở nên cực kỳ dễ dàng. Đưa lỗi cho máy, nhận bản vá, thử, báo lỗi tiếp theo, lặp lại cho đến khi test pass. Bạn có thể tạo ra phần mềm chạy được mà không bao giờ xây dựng nổi một mô hình tinh thần hữu ích về phần mềm mình đang tạo ra.

Ảo tưởng về năng lực

Điều khiến tôi lo lắng hơn cả việc AI thay thế lập trình viên chính là việc AI có thể tạo ra ảo tưởng rằng bạn hiểu hệ thống, bởi vì nó có thể làm cho hệ thống hoạt động theo ý bạn. Bạn hỏi một câu và nhận được câu trả lời. Bạn gặp lỗi và nhận được bản vá. Bản vá không chạy, bạn gửi lỗi mới và nhận được bản vá khác. Cuối cùng máy tìm ra thứ hoạt động.

Nhìn từ bên ngoài, trông như bạn có năng lực. Nhưng nếu bạn không hiểu vì sao giải pháp đó hoạt động, bạn không thực sự trở nên giỏi hơn. Bạn đang trở nên phụ thuộc vào máy để duy trì ảo tưởng đó.

Hậu quả trở nên nghiêm trọng khi có thứ gì đó máy không giải quyết được, hoặc bạn hết token. Lúc đó bạn cần đến mô hình tinh thần mà mình chưa bao giờ xây dựng.

Điều này còn nghiêm trọng hơn với junior

Với developer kỳ cựu, họ có một kho kiến thức tích lũy từ nhiều năm giải quyết vấn đề theo cách khó khăn. Nhưng với người mới bắt đầu hôm nay, trải nghiệm đó có thể sẽ không bao giờ tích lũy được theo cách tương tự.

Nếu mọi phiên debug đầy bực bội đều có thể đẩy cho AI, thì sẽ chẳng có động lực nào để dành bốn giờ tìm hiểu vì sao hệ thống hành xử như vậy. Và bốn giờ đó không phải là thời gian lãng phí. Đó chính là nơi mô hình tinh thần được hình thành.

Bạn không học hệ thống bằng cách thay đổi thành công chúng; bạn chỉ có thể thay đổi chúng thành công khi bạn giải thích được vì sao chúng thất bại.

Đừng giao sự thấu hiểu ra ngoài

Tôi không nghĩ giải pháp là ngừng dùng AI – hoàn toàn ngược lại. Hãy dùng nó mạnh mẽ. Để nó viết boilerplate. Để nó nhắc cú pháp. Để nó khám phá thư viện lạ. Để nó triển khai những phần tẻ nhạt.

Nhưng hãy giữ phần quan trọng cho mình.

Bạn nên hiểu vấn đề. Bạn nên quyết định hệ thống nên làm gì. Bạn nên đưa ra các quyết định kiến trúc. Bạn nên giải thích được các mảnh ghép khớp với nhau như thế nào và tại sao chúng được thiết kế như vậy.

Hãy để AI viết code, chứ không phải thiết kế giải pháp.

Developer sẽ trở nên kiến trúc hơn

Nếu việc viết code trở nên rẻ và dễ dàng cho tất cả mọi người, thì viết code không còn là yếu tố tạo khác biệt. Những developer nổi bật sẽ là những người hiểu hệ thống.

Kiến trúc. Tích hợp. Hệ thống phân tán. Khả năng quan sát. Chế độ lỗi. Ranh giới. Đánh đổi. Những thứ tồn tại xung quanh code chứ không phải bên trong nó.

Theo nghĩa đó, AI có thể đẩy developer về phía vai trò kiến trúc hơn.

Những developer giỏi nhất sẽ không phải là người từ chối để máy viết code. Họ sẽ là những người dùng máy để hiểu hệ thống tốt hơn, trong khi vẫn nắm chắc quyền kiểm soát các quyết định quan trọng.

Tôi cũng đã làm một video thảo luận về chủ đề này nếu bạn muốn xem: Beyond recall: The role of the Software Engineer in the age of AI.

Cảm ơn bạn đã đọc.