AI: Sự bất tài được tăng tốc
(slater.dev)- Trong kỹ thuật phần mềm, việc phụ thuộc quá mức vào LLM sẽ nhanh chóng thúc đẩy sự bất tài
- LLM có những giới hạn khiến chúng không thể thay thế tư duy phản biện và năng lực giải quyết vấn đề
- Việc sử dụng LLM đi kèm nhiều rủi ro như đầu ra sai, lỗi đầu vào, chất lượng mã suy giảm, năng lực lập trình viên suy giảm, mất niềm vui sáng tạo
- LLM không thể cung cấp những năng lực phát triển cốt lõi như lý thuyết chương trình và entropy của chương trình
- Về dài hạn, năng lực kỹ thuật và khả năng tư duy sâu quan trọng hơn bao giờ hết
Giới thiệu
Kể từ khi AI và LLM bùng nổ trong sự chú ý đại chúng vào cuối năm 2022, đã có rất nhiều cuộc thảo luận xoay quanh chúng.
Với tư cách là một kỹ sư phần mềm giàu kinh nghiệm, tác giả nêu ra hai vấn đề chính đã quan sát được ở LLM.
Góc nhìn “LLM là bạn của tôi”
Những kỹ sư xem LLM là công cụ tối thượng thường đặt tốc độ làm giá trị ưu tiên cao nhất.
LLM có thể tạo ra rất nhiều mã rất nhanh, nhưng điều đó hàm chứa rủi ro dài hạn.
Rủi ro khi sử dụng LLM
- Rủi ro đầu ra sai: LLM tạo ra mã rõ ràng là sai (không thể biên dịch) cũng như mã có lỗi tinh vi (như lỗi logic).
- Khi người thiếu năng lực thẩm định yêu cầu mã nguồn, khả năng nhận được câu trả lời không phù hợp là rất cao
- Rủi ro đầu vào sai: LLM không phản biện các giả định sai hoặc prompt thiếu ngữ cảnh.
- Chúng không phân biệt được câu hỏi đúng và cũng không thấu hiểu vấn đề XY (không xác định được nguyên nhân gốc)
- Tốc độ phát triển trong tương lai suy giảm: Việc đưa LLM vào làm tăng nợ kỹ thuật rất nhanh, khiến nội bộ dần biến thành một codebase hỗn loạn và khó bảo trì
- Rủi ro làm người dùng kém trưởng thành: Khi cơ hội giải quyết vấn đề và phát triển tư duy biến mất, sự thoái hóa năng lực của nhân tài phát triển tăng tốc.
- Lập trình viên senior không có được trải nghiệm giải quyết vấn đề sâu hơn, còn lập trình viên junior thì thậm chí không thể tích lũy năng lực
- Mất niềm vui sáng tạo: Việc viết mã dựa trên LLM cướp đi trạng thái nhập tâm (flow) và niềm vui sáng tạo; đọc rồi chỉnh sửa mã do AI tạo ra thường là một trải nghiệm đầy đau đớn
Nỗi lo “Liệu tôi có mất việc vì AI không?”
Khả năng đó là rất thấp.
Có hai năng lực phát triển mà LLM không thể thay thế: lý thuyết chương trình và entropy của chương trình.
Lý thuyết chương trình
- Như Peter Naur từng lập luận, “lập trình là hoạt động xây dựng lý thuyết thiết kế”.
- Mã nguồn không phải là đầu ra thực chất; sự hiểu biết tập thể (lý thuyết) mới quan trọng hơn
- Nếu giao cùng một bài toán cho hai đội có năng lực ngang nhau rồi chỉ chuyển giao mã, thì đội trực tiếp tạo ra nó sẽ có khả năng bổ sung tính năng hiệu quả hơn rất nhiều
- Với một codebase xa lạ, năng suất ban đầu thấp; nhưng khi hiểu rõ hơn lý thuyết thiết kế nội tại, năng suất sẽ dần tăng lên
LLM và lý thuyết chương trình
- LLM chỉ có bộ nhớ trong ngữ cảnh, nên không thể nội tại hóa một lý thuyết chương trình thực sự hay thiết kế ở chiều sâu.
- Trên thực tế, bản chất đích thực của lập trình (thiết kế và xây dựng lý thuyết) là thứ chỉ con người mới có thể đạt được
Entropy của chương trình
- Fred Brooks gọi độ phức tạp (entropy) là bài toán nền tảng khó khăn nhất của lập trình.
- Bảo trì chương trình làm gia tăng độ phức tạp, và ngay cả cách thực thi tốt nhất cũng vẫn đẩy hệ thống tới sự lão hóa không thể đảo ngược
LLM và entropy của chương trình
- LLM chỉ thực hiện dự đoán token ở cấp độ văn bản, nên không thể tư duy ngữ nghĩa ở cấp độ ý tưởng, bản thiết kế hay yêu cầu.
- Càng xử lý hội thoại dài hoặc những khối mã lớn, chúng càng lặp lại các thay đổi không cần thiết hoặc kỳ quặc, từ đó chỉ làm độ phức tạp tăng thêm
- Công việc giảm hoặc kháng lại độ phức tạp là điều chỉ con người mới có thể làm
Kết luận
Dựa trên những hiểu biết sâu sắc của hai người tiên phong, bài viết tái khẳng định bản chất của thiết kế phần mềm và độ phức tạp.
Nếu kỳ vọng AI sẽ cải thiện sự nghiệp phát triển của mình, cần lưu ý rằng nó có thể ngược lại khiến sự bất tài tăng tốc.
Là những lập trình viên có kinh nghiệm phong phú và tay nghề vững, cần nhận thức rằng LLM không thể thay thế kỹ sư con người.
Sức hấp dẫn về mặt kinh doanh của việc áp dụng AI nằm ở cắt giảm chi phí, nhưng trên thực tế nó tạo ra những rủi ro mới; nếu lạm dụng, chi phí bổ sung dài hạn và rủi ro tổ chức sẽ tích tụ.
Tầm quan trọng của năng lực kỹ thuật và khả năng tư duy sâu sẽ không thay đổi về dài hạn; hãy dùng AI như một công cụ và tiếp tục đầu tư vào những năng lực cốt lõi vốn đã quan trọng từ năm 2019.
Bài tiếp theo
Trong các bài viết sau, tác giả dự định sẽ bàn về các giải pháp cụ thể cho từng rủi ro.
Tài liệu tham khảo
- Leading Question: https://en.wikipedia.org/wiki/Leading_question
- The XY Problem: https://en.wikipedia.org/wiki/XY_problem
- ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
- Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
- Thoughts on Thinking: https://dcurt.is/thinking
- The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
- "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
- Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
- Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
- Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle
1 bình luận
Ý kiến trên Hacker News
Kỹ sư phần mềm luôn được kỳ vọng tạo ra phần mềm có hành vi dự đoán được và vượt qua kiểm thử, đồng thời tooling cũng phát triển hơn nhiều
Trong khi đó, với kỹ sư machine learning, việc làm việc với các mô hình xác suất là chuyện thường ngày, và việc test cũng thường xoay quanh đánh giá theo chỉ số hơn là đầu ra cụ thể
Vì vậy họ quen hơn với thực tế rằng AI không phải lúc nào cũng đáng tin cậy
Họ cũng tiếp cận coding assistant với tư duy rằng dù chỉ đúng 80% thì 20% còn lại mình có thể tự bắt lỗi
Khi làm ở Amazon, các giải pháp dựa trên ML rất hữu ích cho những bài toán không có cách tiếp cận cổ điển
Nhưng ở một startup, người ta lại cố chấp dùng cách tiếp cận dựa trên học máy mà không hiểu cả những thứ cơ bản như filtering hay mapping, khiến việc ước lượng tư thế của một máy bay đang đứng yên liên tục cho ra kết quả lố bịch
Khoảng cách giữa ML và kỹ thuật phần mềm là rất rõ, và mong rằng sẽ có cách thể hiện điều này tốt hơn trong quy trình tuyển dụng
Ở một công ty bán sản phẩm mà độ chính xác và tính đúng đắn là cốt lõi, đội ML lại cho rằng 80~90% là đủ, và đã chứng kiến sự bất mãn của kiến trúc sư về điều đó
Giống như ví dụ tranh luận về tỷ lệ tử vong 1% trong đại dịch, cần nhớ rằng chỉ vài phần trăm nhỏ cũng có thể tạo ra tác động lớn
Bài viết này tập trung vào một mối bận tâm mang tính meta của AI và software engineering, tức là quản lý entropy của chương trình
Quản lý entropy là một phần rất lớn trong việc xây dựng sản phẩm phần mềm, và AI có thể một ngày nào đó sẽ làm phần này dễ hơn, nhưng hiện tại nhiều khi còn khiến entropy tệ hơn
Xem MLE từ góc nhìn rộng hơn của SWE, cần hiểu toàn bộ việc xây dựng pipeline robust, tích hợp mô hình, triển khai, v.v.
Nhưng phần lớn những người học chuyên sâu MLE lại thiếu góc nhìn SWE, và thường chỉ hiểu ML mà thiếu trực giác kiểu máy tính
Muốn trở thành full-stack thực thụ thì bắt buộc phải hiểu cả hệ thống mức thấp, cấu trúc, triển khai lẫn MLE
Thế nhưng thị trường tuyển dụng phần lớn chỉ tìm SWE hoặc tiến sĩ MLE, nên rất muốn được đề nghị mức đãi ngộ xứng đáng cho người biết tất cả những điều này
Ví dụ như thiết kế lại race condition, dự đoán p99 của các lệnh gọi DB, hay A/B test
Là một lập trình viên kỳ cựu với 30 năm kinh nghiệm, việc phải đọc code do AI tạo ra đồng nghĩa luồng phát triển đang chuyển sang hướng lấy code review làm trung tâm
Điều này giúp cả lập trình viên cá nhân học được cảm giác trách nhiệm ở tầm đội nhóm cũng như kinh nghiệm đọc code
Ngoài ra, để dùng LLM đúng cách thì khả năng hiểu cấu trúc phân tầng của vấn đề là điều bắt buộc
Việc thiết kế chi tiết theo từng phần trước khi triển khai tự nhiên cũng giúp định nghĩa interface và boundary tốt hơn
LLM là chất xúc tác giúp junior tăng tốc trở thành senior và cho họ trải nghiệm việc học từ những lập trình viên nhiều kinh nghiệm
AI sẽ không thay thế lập trình viên mà cuối cùng sẽ thấm vào như một công cụ
Code do LLM tạo ra có thể đơn điệu, nhưng chính điều đó cũng là cơ hội học tập
Tôi biết thêm rất nhiều idiom mới/cách gọi thư viện mới từ code do LLM sinh ra
Càng là senior thì càng có thể viết prompt tốt hơn, nên LLM lại càng đóng vai trò chất xúc tác mạnh hơn
Từ big tech, mid tech đến small tech đều đang tiếp tục cắt giảm nhân sự
Lập luận là AI gần với kiểu thay đổi thực tế này hơn là singularity
Chia sẻ thực tế rằng cách giảng dạy/bài tập/lớp học từng được xem là hiển nhiên trước đây đang thay đổi rất nhanh trên toàn cầu do sự xuất hiện của LLM
Nếu không có SpaceX thì đã có rất nhiều lĩnh vực thực sự là bất khả thi
Kết cục là các ngân hàng lại đi bán sản phẩm tài chính dựa trên Bitcoin
In 3D không được xem là để thay thế sản xuất truyền thống mà chủ yếu dừng ở mục đích prototype/mockup/PoC
Nếu chấp nhận code mà không hiểu thì sau này lúc bảo trì sẽ phải trả cái giá lớn dưới dạng technical debt
Giống như ảo giác về tốc độ miễn phí, nhưng thực tế là technical debt tích lũy với hiệu ứng như lãi suất hằng năm cỡ 40%
Hãy để AI tự động hóa việc gõ phím, còn tư duy vẫn phải do con người đảm nhiệm
tdd, microservices, v.v.)Có ý kiến cho rằng những thứ như
tdd, microservices vốn không cần thiết trong phát triển truyền thống, nhưng ở thời đại LLM lại trở nên có giá trị hơnChỉ một chút mơ hồ trong prompt cũng có thể khiến kết quả lệch hoàn toàn, và khi nhận ra thì đã rất khó cứu vãn về sau
Chính vì tính mơ hồ của ngôn ngữ con người mà cuối cùng mới xuất hiện ngôn ngữ hình thức rõ ràng
Cá nhân cảm thấy khi dùng AI tooling thì năng lực của mình dường như suy giảm nhanh chóng, thậm chí có trường hợp còn tốn thêm thời gian và năng lượng
AI có ích, nhưng có vẻ đang chia thành một phe hiểu rằng trong các vấn đề phức tạp sai sót nhỏ sẽ tích lũy, và một phe quản lý/người không kỹ thuật chỉ nhìn kết quả rồi cho rằng nó có thể 'thay thế vai trò'
[Kinh nghiệm chi tiết: bình luận trước đó]
Cũng như máy tính cầm tay khiến con người giảm khả năng tính nhẩm, AI cũng có thể làm suy giảm năng lực viết lách, giao tiếp và giải quyết vấn đề
Vì vậy chỉ dùng LLM cho các tác vụ nhỏ, rõ ràng hoặc những vấn đề vốn sẽ tìm trên StackOverflow
Coi câu trả lời không phải chân lý tuyệt đối mà là để tham khảo
Năng lực để con người hiểu toàn bộ bản thiết kế tổng thể là cốt lõi của khả năng chống lại entropy
Làm vậy sẽ giúp gọt giũa chủ đề/ngữ cảnh rõ ràng hơn
Hy vọng mẹo này cũng hữu ích với người khác
Ví dụ: cuộc chiến Coke vs Pepsi ngày xưa
Nếu hỏi LLM theo kiểu 'hãy cho tôi code đã được đơn giản hóa' để làm rõ ý đồ thiết kế, thì hoàn toàn có thể nhận được một ý kiến thứ hai khá tốt
Nếu không hỏi thì ngay từ đầu đã không có câu trả lời, và cấu hình mặc định cũng là do chúng ta chọn nên đây không phải lập luận liên quan đến bản chất của công nghệ nền
Trong thực tế không ai có thể nắm toàn bộ một chương trình khổng lồ trong đầu, nên công cụ và ngôn ngữ phần lớn đều phát triển dựa trên hiểu biết từng phần
LLM cũng chia sẻ giới hạn đó, nên trong khuôn khổ này con người và LLM có các giới hạn tương tự nhau
Điều đáng tiếc là LLM khó có khả năng hỏi ngược lại về định hướng kiểu 'tại sao lại làm như vậy?'
Có phần đúng, nhưng đa số vốn dĩ đã không giỏi tìm đường, và ngược lại công nghệ bản đồ giúp năng lực đi từ A→B của con người trung bình tăng lên
Ngay cả với số ít người vốn đã rất thành thạo, công nghệ cũng đóng vai trò hỗ trợ chứ không thay thế năng lực của họ
AI cũng sẽ tạo ra thay đổi tương tự ở quy mô lớn hơn; sẽ có những điểm năng lực giảm sút và mất mát, nhưng cũng sẽ thu được rất nhiều thứ
Bản đồ gần như luôn cho ra giá trị như mong đợi, còn LLM thì ngay cả với cùng một prompt kết quả cũng có thể khác, nên khó tin cậy
Cũng như có người lao xe xuống hồ vì quá tin bản đồ, việc mù quáng tin LLM có thể gây ra vấn đề còn lớn hơn
Có thể thoải mái đi lạc rồi khi cần mới bắt lại lộ trình, nên trải nghiệm còn được khuếch đại hơn
Còn AI thì có trường hợp còn thua cả người bình thường mới thử làm lĩnh vực đó vài ngày
Các LLM gần đây rõ ràng có thể làm việc ở cấp độ khái niệm (ví dụ: chuyển dịch/áp dụng concept)
Có ý kiến cho rằng chúng còn hiểu được cả những khái niệm mà con người chưa từng trực tiếp trải nghiệm cá nhân
Ví dụ: quanh từ 'dog' sẽ tập hợp các từ liên quan
Nhưng chúng không mô hình hóa được tổ hợp/chủ đích/lý luận phản thực
Với những câu hỏi tương tự dữ liệu huấn luyện thì chúng phát huy tốt
Ở các lĩnh vực có khái niệm hóa được định nghĩa rõ như software engineering thì chúng khá hữu ích
Cuối cùng thì người vốn không nỗ lực trong công việc dù có dùng AI cũng vậy, còn chỉ những người thật sự học hỏi mới phát triển cùng AI
Nếu AI làm việc tốt hơn thì điều đó chỉ tạo thêm lý do để thay thế chính người dùng nó
FSD (tự lái hoàn toàn) cũng tốt hơn nhiều so với một tài xế bình thường không phải chuyên gia
Đang cân nhắc hình thức forum, mailing list, multi-blog, v.v.
Mailing list tạm thời
Đã có những ví dụ thành công trong một số cộng đồng nhất định