- Các hệ thống công nghệ hiện đại đã phát triển thành cấu trúc quá phức tạp đến mức một cá nhân không thể hiểu toàn bộ
- Khi phát triển phần mềm và ứng dụng AI gia tăng, số trường hợp các lập trình viên xây dựng hệ thống mà không hiểu cơ chế bên trong cũng tăng theo
- Simon Wardley cảnh báo về rủi ro khi tạo ra hệ thống mà không có sự thấu hiểu, Adam Jacob chỉ ra rằng AI đang thay đổi cách phát triển, còn Bruce Perens nhận định độ phức tạp đã vượt ngưỡng từ lâu
- Louis Bucciarelli thông qua ví dụ về hệ thống điện thoại cho thấy công nghệ được đan cài qua nhiều tầng lớp, đến mức không ai có thể đạt được sự hiểu biết hoàn chỉnh
- Bài viết nhấn mạnh rằng AI đang làm sâu sắc thêm sự phức tạp này, nhưng trên thực tế con người từ lâu đã luôn xử lý công nghệ trong trạng thái chỉ hiểu một phần
Độ phức tạp công nghệ và giới hạn của sự hiểu biết
- Sau sự suy tàn của Twitter, trên LinkedIn đã diễn ra sôi nổi các thảo luận về mức độ hiểu biết kỹ thuật và sự phức tạp
- Các bài đăng của Simon Wardley, Adam Jacob và Bruce Perens được giới thiệu như những chủ đề có liên hệ với nhau
- Wardley cảnh báo về nguy cơ xây dựng hệ thống mà không nắm các nguyên lý nền tảng
- Cách gọi “Magic” được dùng để chỉ trích các framework che giấu cách vận hành nội bộ, trong đó Ruby on Rails được nêu như ví dụ tiêu biểu
- Jacob chỉ ra rằng AI đang thay đổi căn bản cách phát triển phần mềm
- AI nâng cao hiệu suất, nhưng cũng có xu hướng khiến lập trình viên làm việc mà không hiểu hạ tầng bên dưới
- Perens nói rằng tình huống mà Wardley lo ngại thực ra đã trở thành hiện thực
- Do độ phức tạp của CPU và hệ điều hành hiện đại, nhiều lập trình viên đang hiểu sai nguyên lý vận hành thực tế
Trường hợp ‘điện thoại’ của Louis Bucciarelli
- Bucciarelli trong cuốn Designing Engineers xuất bản năm 1994 đã bàn về giới hạn của năng lực hiểu biết công nghệ
- Phần lớn mọi người không thể giải thích nguyên lý hoạt động của điện thoại ở cấp độ vật lý
- Các yếu tố đa tầng như định tuyến, xử lý tín hiệu, truyền dẫn vệ tinh, vận hành doanh nghiệp và cấu trúc quản lý của mạng viễn thông đan xen với nhau
- Ông đi đến kết luận rằng “không ai thực sự biết đầy đủ điện thoại của chính mình hoạt động như thế nào”
- Điều này tượng trưng cho việc các hệ thống công nghệ phức tạp vượt ra ngoài khả năng hiểu trọn vẹn của con người
Phỏng vấn kỹ thuật và ‘giới hạn của tri thức’
- Tác giả hồi tưởng một cuộc trò chuyện với Brendan Gregg trong thời gian làm việc tại Netflix
- Gregg cho biết khi phỏng vấn, ông đánh giá giới hạn tri thức của ứng viên và cách họ phản ứng với điều đó
- Ông tiến hành phỏng vấn với tiền đề rằng “không ai có thể hiểu hoàn toàn toàn bộ hệ thống”
- Cách tiếp cận này cho thấy thái độ thừa nhận điều mình không biết quan trọng không kém năng lực kỹ thuật
Bản chất của độ phức tạp và tác động của AI
- Các quan điểm của Wardley, Jacob, Perens và Bucciarelli cùng cho thấy tính tất yếu của độ phức tạp ở những tầng lớp khác nhau
- Wardley: rủi ro của việc xây dựng mà không hiểu
- Jacob: hiệu suất và khoảng cách do AI mang lại
- Perens: thực tế của độ phức tạp vốn đã tồn tại
- Bucciarelli: sự bất khả trong việc hiểu toàn bộ hệ thống
- Bài viết thừa nhận AI sẽ làm vấn đề này trầm trọng hơn, nhưng đồng thời nhắc lại thực tế lâu nay rằng con người luôn xử lý công nghệ trong trạng thái hiểu biết từng phần
Tóm tắt thảo luận của độc giả
- Trong phần bình luận, nhiều ý kiến bày tỏ lo ngại rằng AI đang làm suy yếu việc học và sự thấu hiểu
- Một số người chỉ ra rằng “LLM viết mã thay con người khiến chuỗi hiểu biết bị đứt gãy”
- Wardley giải thích rằng “trước đây sự hiểu biết được duy trì trong một chuỗi phân cấp, nhưng LLM đã loại bỏ chuỗi đó”
- Một độc giả khác phản bác rằng “khẳng định lợi ích của AI lớn hơn rủi ro là quá vội vàng”
- Nhìn chung, sự đánh mất hiểu biết kỹ thuật trong thời đại AI và sự đứt gãy của quá trình học tập nổi lên như các điểm tranh luận chính
1 bình luận
Ý kiến trên Hacker News
Điều đáng lo trong lập trình dạo này là kiểu "phát triển ở tầng giữa" đang tăng lên: không biết tầng trên (mục đích của sản phẩm) mà cũng không biết tầng dưới (cách triển khai)
Trước đây dù không hiểu business thì vẫn hiểu ý nghĩa của code, còn giờ bầu không khí như thể chẳng cần biết code vận hành thế nào cũng được
Dùng Claude một thời gian thì có cảm giác khả năng nhận thức bối cảnh của mình đang giảm dần. Trong văn hóa phát triển mà chỉ cần test pass và nút bấm hoạt động là xong, tôi thấy mình như một người không còn gì để học hay đóng góp nữa
Đặc biệt ở các công ty lớn thì càng thiếu minh bạch. Có lần tôi tăng ca để kịp deadline, nhưng lịch đã bị dời mà chỉ mình tôi không biết
Nếu tôi bị xem như một công cụ đơn thuần thì tôi sẽ chỉ làm đúng vai đó. Nhưng nếu thật sự muốn ownership, thì cần có chỗ ngồi trong bàn ra quyết định
Trước đây tôi lãng phí thời gian cho các công việc thiết lập lặp đi lặp lại, còn giờ có thể chỉ tập trung vào tính năng cốt lõi. Nhờ vậy tôi giữ được cấu trúc tổng thể trong đầu tốt hơn
Ví dụ trong IDE chọn vài dòng rồi nói bằng giọng nói "hãy đổi đoạn này thành như thế này" và nó phản ánh ngay lập tức
Nếu đủ nhanh thì điều khiển bằng chuột + giọng nói cũng có thể là một công cụ trợ năng rất tốt
Tôi nghĩ LLM thậm chí có thể giúp giảm bớt kiểu phức tạp này. Tôi thích mức trừu tượng vừa phải, nhưng không thích hoàn toàn không biết bên trong có gì
Bài này đang nói về hiện tượng con người sử dụng trừu tượng hóa (abstraction) mà không biết nội bộ bên trong
Nhưng đó là một quá trình phát triển tự nhiên. Đã có ai đó thiết kế ra lớp trừu tượng đó và làm cho tầng trên có thể dùng được
Lý luận kiểu "tôi không biết Wi-Fi driver nên cũng không cần biết code" là không đứng vững
Trước đây người ta trực tiếp xử lý những "độ phức tạp cần thiết" để rèn năng lực tư duy, còn bây giờ nhiều khi chỉ đóng vai trò như một cái ống dẫn
Giải pháp là bọc sự trừu tượng hóa bằng DSL (ngôn ngữ đặc thù miền) thay vì dùng ngôn ngữ đa dụng. Nếu là SaaS thì tôi thấy cách tiếp cận DSL-first tốt hơn API-first
Tôi không nghĩ AI còn tệ hơn thế. Điều quan trọng là phải hiểu những lớp trừu tượng mà mình đang dựa vào
Cây phụ thuộc mới thật sự là thứ gây ra vấn đề lớn nhất
Chỉ cần nhìn các dự án Node.js là đã có hàng trăm package phụ thuộc. Đa phần không cần biết nội bộ cũng được, nhưng sẽ nguy hiểm nếu interface liên tục bị phá vỡ
Nhiều team còn không theo dõi EOL (hết hỗ trợ) hay lỗ hổng bảo mật. Thực tế là có khi họ còn chẳng biết "cái này còn được bảo trì không?"
Nhưng ngay cả trước thời AI, đã có rất nhiều dự án rơi vào địa ngục phụ thuộc vì xung đột phiên bản
Tôi nghĩ con người không cần biết mọi thứ, nhưng sự ngu dốt do đánh mất nền tảng thì rất nguy hiểm
Lấy nấu ăn làm ví dụ, bạn không cần tự trồng lúa mì, nhưng nếu đến cả cách rán trứng cũng không biết thì đó là vấn đề
Nếu doanh nghiệp chuẩn hóa và nấu sẵn toàn bộ thức ăn cho mọi người, thì đó là tiến bộ hay thụt lùi?
Nếu một ngày nào đó robot hoàn toàn thay thế việc sản xuất thực phẩm, thì không biết nấu ăn cũng sẽ không còn quan trọng
Chẳng lẽ phải hiểu tới cả khoa học vật liệu mới tránh được sự phụ thuộc sao?
Các tầng thấp hơn như lệnh CPU và cache đã được kiểm chứng và tài liệu hóa kỹ lưỡng suốt hàng chục năm
Trong khi đó, code do LLM tạo ra thì không đáng tin đến thế và có thể cần refactor ngay ngày mai
Tôi có thể không biết chi tiết vận hành của tầng dưới, nhưng tôi hiểu code của mình hoạt động thế nào
Không biết tầng dưới khác hoàn toàn với không biết phạm vi trách nhiệm của chính mình
Bây giờ điều thực sự nguy hiểm là xuất hiện những mảnh code mà không ai hiểu
Tôi không đồng ý với lập luận rằng AI đang làm mọi thứ tệ hơn
Trái lại, vì LLM đã học gần như toàn bộ tri thức nên nó có thể giải thích có hệ thống cho những câu hỏi như "điện thoại hoạt động thế nào?"
Con người có giới hạn là "thậm chí không biết mình không biết gì", còn LLM thì gần như bao quát được mọi tri thức đã được biểu đạt bằng ngôn ngữ
Tất nhiên khả năng suy luận hay sinh code còn yếu, nhưng năng lực tích hợp tri thức thì vượt trội hơn con người
Nó không thể thay thế tài liệu thật. Dù vậy, nó rất hữu ích trong việc chỉ ra cho con người "cần tra cứu điều gì"
Thiết kế tốt là làm sao để hệ thống vẫn hoạt động dù không cần biết toàn bộ
Vấn đề không nằm ở hệ thống do AI tạo ra, mà ở chỗ chúng ta vẫn chưa hiểu rõ các dạng thất bại và giới hạn của nó
Cuối cùng, điều cốt lõi là năng lực thiết kế tổ chức để điều phối con người và AI nhằm tạo ra hệ thống cần thiết
Tôi không hiểu hoàn toàn nội bộ của máy tính, nhưng vẫn giải quyết vấn đề bằng tự động hóa script theo hướng thực dụng
Không cần học assembly x86 tôi vẫn có thể quản lý hạ tầng bằng Python
Nhưng tôi nghĩ các lập trình viên giàu kinh nghiệm có trách nhiệm chia sẻ kiến thức đó. Tôi cũng muốn một ngày nào đó tiếp nối vai trò ấy
Đừng đánh mất sự tò mò, và hãy tích cực trò chuyện với các lập trình viên đi trước
Nhưng thực tế rằng dù nhấn mạnh thế nào thì tầm quan trọng của hiểu biết nền tảng vẫn bị phớt lờ khiến tôi rất bức bối
Tôi thực sự có thể trả lời những câu hỏi như "điều gì xảy ra khi bạn nhập một URL?"
Tôi từng làm kỹ thuật viên lò phản ứng tàu ngầm cho Hải quân Mỹ và đã học từ lý thuyết điện tử đến xử lý sự cố hệ thống
Sau đó chuyển sang IT, tôi vẫn giữ nguyên thái độ đó và đào tới cùng thông qua tài liệu và thực nghiệm
Nhờ thói quen này, khi giải quyết vấn đề thì sự kết nối của các mảnh kiến thức rời rạc giúp ích rất nhiều
Bài viết wiki về VMEbus cũng đáng tham khảo
Chỉ là tôi thuộc kiểu không chịu nổi việc không biết, nên có lẽ là trường hợp ngoại lệ