- Trong hơn 50 năm qua, những nỗ lực đơn giản hóa phát triển phần mềm để giảm sự phụ thuộc vào lập trình viên đã lặp đi lặp lại
- Bắt đầu từ COBOL trong thập niên 1960, rồi đến công cụ CASE, Visual Basic, low-code·no-code, và gần đây là trợ lý viết mã AI, cùng một mô-típ vẫn tiếp diễn
- Mỗi công nghệ đều giúp tăng năng suất, nhưng quá trình tư duy để xử lý sự phức tạp vẫn là phần việc của con người
- AI khuếch đại năng lực của lập trình viên, nhưng không thể thay thế khả năng hiểu bài toán kinh doanh và năng lực phán đoán
- Chuỗi nỗ lực lặp đi lặp lại này cho thấy sự phức tạp của vấn đề chứ không phải giới hạn của công cụ, và cuối cùng, cốt lõi vẫn là đầu tư vào năng lực tư duy của con người
Khởi đầu của một mô-típ lặp lại
- Cứ mỗi 10 năm lại xuất hiện lời hứa rằng “lần này việc phát triển sẽ trở nên dễ dàng hơn”
- Sau chương trình Apollo năm 1969, phần mềm nổi lên như một công nghệ cốt lõi
- Nhưng rồi người ta nhận ra rằng phát triển đòi hỏi kiến thức chuyên môn, sự tập trung và đầu tư thời gian
- Từ đó bắt đầu giấc mơ kéo dài: “hãy đơn giản hóa việc phát triển để giảm nhu cầu nhân lực”
COBOL: Niềm tin rằng người phụ trách nghiệp vụ có thể tự viết mã
- Đúng như tên gọi Common Business-Oriented Language, COBOL được thiết kế để người phụ trách nghiệp vụ có thể viết mã giống như câu tiếng Anh
- Nhưng trên thực tế, sự phức tạp của logic, cấu trúc dữ liệu và thiết kế hệ thống vẫn còn nguyên, nên cuối cùng một tầng lớp lập trình viên COBOL chuyên nghiệp mới lại được hình thành
- Tầm nhìn “ai cũng có thể lập trình” đã không trở thành hiện thực
Thập niên 1980: Lời hứa tự động sinh mã của công cụ CASE
- Công cụ CASE (Computer-Aided Software Engineering) xuất hiện với lời hứa tự động sinh mã từ sơ đồ
- Các doanh nghiệp đầu tư quy mô lớn với kỳ vọng năng suất tăng gấp 10 lần
- Nhưng mã được tạo ra thất bại vì vấn đề hiệu năng, khó bảo trì và sai lệch giữa mô hình với thực tế
- Vì việc hiểu sự phức tạp về mặt logic vẫn là điều cần thiết, nên vấn đề không được giải quyết
Thập niên 1990: Cách tiếp cận của Visual Basic và Delphi
- Bằng phương thức kéo và thả, chúng giúp việc tạo UI trở nên dễ dàng hơn và hạ thấp rào cản gia nhập phát triển phần mềm
- Các ứng dụng đơn giản thì khả thi, nhưng với những hệ thống phức tạp cần tích hợp, bảo mật, hiệu năng và khả năng bảo trì, vẫn cần các lập trình viên dày dạn kinh nghiệm
- Kết quả là nhu cầu lập trình viên không giảm mà còn tiếp tục mở rộng
Từ thập niên 2000 trở đi: Web framework, low-code, no-code
- Ruby on Rails đề cao “quy ước thay vì cấu hình”, còn các nền tảng low-code·no-code đưa ra khẩu hiệu “phát triển không cần mã”
- Dù đạt được việc tăng tốc và mở rộng mức độ tham gia trong một số lĩnh vực, nhu cầu đối với lập trình viên chuyên nghiệp vẫn tiếp tục tăng
- Câu hỏi lặp lại là: “Vì sao mô-típ này cứ tiếp diễn?”
Bản chất của sự phức tạp
- Phần mềm thoạt nhìn có vẻ đơn giản, nhưng trên thực tế, sự phức tạp bùng nổ ở các tình huống chi tiết và xử lý ngoại lệ
- Ví dụ: xung đột giữ chỗ tồn kho, thanh toán thất bại, dịch vụ email ngừng hoạt động
- Chính những phán đoán chi tiết đó mới là bản chất của hoạt động phát triển, và không công cụ nào có thể loại bỏ chúng
Chương mới trong kỷ nguyên AI
- Trợ lý viết mã AI có thể tạo mã bằng ngôn ngữ tự nhiên, đồng thời thực hiện giải thích, gỡ lỗi và đề xuất cải tiến
- Đây là một bước tiến thực chất, nhưng định nghĩa vấn đề, bảo mật, tích hợp và phán đoán về bảo trì vẫn là vai trò của con người
- AI khuếch đại năng suất của lập trình viên, nhưng không thể thay thế khả năng phán đoán và hiểu ngữ cảnh
Năng lực phát triển vẫn còn thiếu hụt
- Công nghệ đã phát triển vượt bậc, nhưng nhu cầu phần mềm vẫn vượt quá nguồn cung
- Các doanh nghiệp tìm cách “xây dựng nhanh hơn, nhiều hơn” và tiếp tục đặt kỳ vọng vào các công cụ đơn giản hóa phát triển
- Nhưng nút thắt không nằm ở tốc độ gõ hay cú pháp, mà ở năng lực tư duy để xử lý sự phức tạp
Những câu hỏi mà lãnh đạo nên đặt ra
- Không phải “Công cụ này có thay thế được lập trình viên không?” mà là
- “Nó có giúp giải quyết các vấn đề phức tạp không?”
- “Nó có giảm bớt công việc lặp lại để con người tập trung vào vấn đề sáng tạo hơn không?”
- “Nó có đòi hỏi phải học thêm kỹ năng mới không?”
- Những câu hỏi này giúp nhận thức được giới hạn của công cụ và tính tất yếu của tư duy con người
Bài học của 50 năm: Vấn đề không mang tính cơ giới mà mang tính trí tuệ
- COBOL đã đơn giản hóa cú pháp, CASE loại bỏ việc gõ tay, còn AI có thể tạo ra cả một hàm, nhưng khó khăn cốt lõi vẫn còn đó
- Phát triển phần mềm là ‘hành động cụ thể hóa tư duy’, và điều này không thể bị thay thế bằng công cụ
- Giống như thiết kế kiến trúc hay chẩn đoán y khoa, chính quá trình tư duy mới là giá trị cốt lõi
Hướng đi trong tương lai
- Các công cụ mới sẽ tiếp tục xuất hiện, nhưng đầu tư vào năng lực tư duy của con người mới là điều quan trọng nhất
- Hãy thử nghiệm AI·low-code·framework mới, nhưng cần coi khả năng hiểu sự phức tạp là năng lực cốt lõi của tổ chức
- Cũng như chương trình Apollo, độ chính xác của tư duy chứ không phải công cụ mới là yếu tố quyết định thành công
Vì sao giấc mơ này vẫn tiếp diễn
- “Giấc mơ thay thế lập trình viên” không phải là thất bại, mà là sự lạc quan thúc đẩy đổi mới công cụ
- Mỗi lần thử nghiệm đều thất bại trong việc thay thế hoàn toàn, nhưng vẫn tạo ra một thế hệ công cụ hữu ích mới
- COBOL giúp phổ biến phát triển hệ thống nghiệp vụ
- CASE thúc đẩy sự phát triển của mô hình hóa trực quan
- Visual Basic mở rộng khả năng tiếp cận phát triển phần mềm
- AI thúc đẩy sự thay đổi trong cách phát triển
- Sau cùng, giới hạn nằm ở không phải công cụ mà là độ phức tạp của vấn đề mà chúng ta đang cố giải quyết
- Không cần từ chối các công cụ mới; điều cần thiết là nhận thức được kỳ vọng thực tế và tầm quan trọng của phán đoán con người
4 bình luận
Ý kiến trên Hacker News
Nhìn vào làn sóng đổi mới AI lần này, người ta nhận ra rằng phần lớn việc lập trình không phải là độ phức tạp bản chất mà là độ phức tạp ngẫu nhiên
Đây là hiện tượng trong đó công việc mang tính khái niệm với con người lại trở thành công việc mang tính thủ tục với AI
Ví dụ, trước đây để viết
public static void main(String[] args)trong Java thì phải học nhiều khái niệm, nhưng với AI chỉ cần đưa prompt kiểu “hãy viết phương thức entry của class” là gần như chắc chắn nó sẽ tạo ra đoạn mã đóTrong khi các công việc thủ tục khó với con người lại dễ với AI, xã hội lại được cấu trúc xoay quanh kiểu lao động thủ tục này, nên khi đổi mới lan rộng thì sẽ có người đi lên và sẽ có người phải chịu đau đớn
Lập luận “No-code sẽ thay thế lập trình viên” cứ lặp đi lặp lại, nhưng trên thực tế lại luôn tạo ra thêm nhiều việc làm cho lập trình viên hơn
COBOL, VB, Squarespace, và giờ là AI — khi công cụ hạ thấp rào cản gia nhập, nhiều người sẽ muốn tạo ra thứ gì đó hơn, và cuối cùng khi chạm tới giới hạn thì vẫn cần lập trình viên thực thụ
Các công việc lặp lại đơn giản sẽ biến mất, nhưng việc xác định phải xây cái gì và gỡ lỗi nó thì vẫn còn đó
Nếu AI có thể tự mình viết mã cho các dự án phức tạp, thì con người không cần bận tâm đến chi tiết nữa và nhu cầu với lập trình viên có thể giảm
Trước đây đã có những xu hướng lớn như internet, cloud, mobile, machine learning, nhưng tôi không chắc sau này có còn tiếp tục xuất hiện những “bài toán lớn” như vậy hay không
Trong 20 năm qua, người ta cũng đã thấy cùng một mô thức đó trong lĩnh vực quản trị hệ thống
Lời hứa rằng “mức trừu tượng cao hơn sẽ dân chủ hóa công việc của chuyên gia” cứ lặp lại, nhưng trên thực tế lại dẫn tới sự tái phát minh tốn kém
Những công cụ như Kubernetes được nói là đã che đi độ phức tạp, nhưng rốt cuộc các lập trình viên lại đang học lại cùng những vấn đề đó theo cách đắt đỏ hơn mà không biết các khái niệm nền tảng
Excel là ví dụ tiêu biểu — nó tạo ra vô số lỗi khủng khiếp, nhưng vẫn thành công nhờ tính dễ tiếp cận
Rốt cuộc, chúng ta muốn vừa có “tính dễ tiếp cận của Excel” vừa có “độ tin cậy của kỹ thuật”, nhưng không thể có cả hai
Thực tế là khi quy mô tăng lên thì độ phức tạp công việc cũng được đẩy lên mức cao hơn
Lý do mô thức này lặp lại là vì động lực khuyến khích của thị trường
Các công ty phải đóng gói AI như một lời giải vạn năng thì giá cổ phiếu mới tăng, nên cấu trúc này trở thành việc bán niềm tin hơn là bán hiệu năng thực tế
Cuối cùng khi thực tế lộ ra, thị trường sẽ trở nên hỗn loạn
Thực ra số lượng lập trình viên đã có thể giảm rồi
Nếu doanh nghiệp tuyển dụng chọn lọc hơn và đầu tư đào tạo nhiều hơn
Nhưng thực tế lại ngược lại, và các web framework được tạo ra không phải để tăng năng suất mà là để giảm chi phí đào tạo và mở rộng nguồn nhân lực
Quản lý trung gian và ban điều hành chỉ xem bộ phận kỹ thuật như một trung tâm chi phí
Vì vậy họ nhắc đến AI trong mọi thông cáo báo chí và hô hào cắt giảm nhân sự
Trên thực tế, họ đang giảm chi phí không phải nhờ AI mà nhờ thay thế bằng nhân lực offshore
Đội ngũ onshore còn lại phải gánh thêm nhiều việc hơn và đang tăng năng suất
Nguyên nhân không phải là cắt giảm nhân công mà là sự co hẹp đầu tư trên diện rộng
Kết cục là AI đang hút vốn vào đầu tư datacenter và qua đó làm giảm việc làm
Mục tiêu của AI không phải là thay thế lập trình viên mà là nâng mức trừu tượng để xử lý các vấn đề phức tạp hơn
Bắt đầu từ việc lập trình bằng cách đi dây ở máy tính đời đầu, rồi phát triển qua assembly, C, Python, framework, lập trình viên ngày càng xử lý những vấn đề ở cấp độ cao hơn
Tuy vậy, các giai đoạn trước đều là biến đổi có tính quyết định và có thể kiểm chứng, còn AI tạo sinh thì phi định tính, đó là điểm khác biệt
Có thể tham khảo The Story of Mel liên quan đến câu chuyện này
LLM thì không thể nhìn thấy token, AST, IR... như compiler, nên rất thiếu minh bạch
Những hệ thống phi định tính dựa trên ngôn ngữ tự nhiên khác với các thế hệ trừu tượng trước đây
Vì vậy phép so sánh “từ assembly sang C” là không phù hợp
Như Dijkstra từng nói, khoa học bị ghét vì nó khó, và những nhà khoa học sở hữu sức mạnh đó cũng bị ghét
Liên kết nguyên văn EWD1041
Ngược lại, các lập trình viên từ lâu vẫn luôn mơ về việc tự động hóa các nghề không phải lập trình
AI là phiên bản mới nhất của giấc mơ đó
Vào đầu những năm 2000, ở đại học, Rational Rose UML là môn học bắt buộc
Khi đó, một CEO startup từng nói rằng “giờ chỉ cần vẽ diagram là code sẽ được tạo tự động, nên không cần lập trình viên nữa”
Nhưng rốt cuộc lời tiên đoán đó vẫn không thành hiện thực
Máy móc tạo ra mã cho máy móc.
Lâu đài cát mà con người dựng lên trên ngôn ngữ máy cuối cùng cũng có số phận sụp đổ.
...nói vậy cũng được thôi nhỉ haha