Rủi ro đánh mất đức tính lười biếng

• Trong lập trình, lười biếng không phải là sự lười nhác, mà được định nghĩa như một đức tính trí tuệ hướng đến trừu tượng hóa và sự đơn giản.
• Lười biếng đích thực là quá trình suy nghĩ sâu về vấn đề để tiết kiệm thời gian cho tương lai, và điều đó cũng có lợi cho các nhà phát triển thế hệ sau.
• Trừu tượng hóa cấp cao hiện đại và văn hóa ‘brogrammer’ làm mất dần đức tính này, thay thế bằng sự cần cù giả tạo.
• LLM khuếch đại xu hướng này, trở thành một công cụ sản xuất dư thừa, khiến người ta lầm tưởng giá trị phần mềm nằm ở lượng mã.
• Cần duy trì lối lười biếng có tính đức hạnh xuất phát từ thời gian hữu hạn của con người, và sử dụng LLM để thiết kế hệ thống đơn giản và bền vững.

---

Lười biếng như một đức tính của lập trình viên và rủi ro khi mất đi

• Larry Wall trong cuốn 『Programming Perl』 nhấn mạnh rằng trong ba đức tính của một lập trình viên: lười biếng (laziness), vội vã (impatience), kiêu ngạo (hubris), thì lười biếng là đức tính sâu sắc nhất.
  • Lười biếng không phải là tự coi thường bản thân, mà là khái niệm bao hàm sự cần thiết và mỹ học của sự trừu tượng hóa.
  • Nó là động lực để làm hệ thống càng đơn giản càng tốt và thông qua trừu tượng hóa mạnh mẽ giúp làm nhiều việc hơn một cách dễ dàng.
• Lười biếng đích thực là một quá trình giống như ‘hammock-driven development’, trông như đang nghỉ ngơi, nhưng thực tế là lao động trí tuệ suy ngẫm sâu về vấn đề nhằm tiết kiệm thời gian cho tương lai.
  • Khi một trừu tượng hóa đúng đắn được tạo ra, nó mang lại lợi ích không chỉ cho bản thân lập trình viên mà cả cho các nhà phát triển thế hệ sau.
  • Sự lười biếng này giúp việc viết phần mềm dễ dàng hơn và hệ thống dễ cấu hình hơn.

• Kỷ nguyên đức tính lười biếng biến mất

  • Trong 20 năm qua, khi phạm vi làm ra phần mềm mở rộng, số lượng người không tự nhận mình là lập trình viên đã tăng lên.
    • Với nhóm này, đức tính lười biếng đã đánh mất ý nghĩa nguyên thủy.
  • Sự bùng nổ năng suất mang lại bởi trừu tượng hóa cấp cao hiện đại lại tiếp tay cho sự cần cù giả (false industriousness).
    • Điều này thể hiện qua văn hóa ‘brogrammer’ và ‘hustle porn’, thay cho lối lười biếng châm biếm bằng hành vi đổ mã vô hạn.

• LLM mang lại sự dư thừa mới

  • Sự xuất hiện của LLM (mô hình ngôn ngữ lớn) đã khuếch đại xu hướng này.
    • LLM là công cụ khuếch đại thái độ sáng tạo của con người, đóng vai trò như steroid của văn hóa ‘brogrammer’.
  • Ví dụ, Garry Tan cho biết anh đã viết 37,000 dòng mã trong một ngày nhờ LLM.
    • Để tham chiếu, toàn bộ cơ sở mã của DTrace ở mức khoảng 60,000 dòng.
  • Tuy nhiên, cách làm này là một điều xấu thiếu đức tính lười biếng, phơi bày sai lầm khi đánh giá phần mềm bằng lượng mã.

• Hạn chế của LLM và giá trị của lười biếng con người

  • Vì chi phí lao động của LLM là 0, nó tạo ra hệ thống ngày càng phức tạp vô hạn mà không tính đến việc tiết kiệm thời gian của tương lai.
    • Hệ quả là hệ thống càng to và phức tạp hơn, thỏa mãn các chỉ số dựa trên lòng tự phụ nhưng làm hại chất lượng cốt lõi.
  • Lười biếng của con người bắt nguồn từ ràng buộc của thời gian hữu hạn, và điều đó buộc có trừu tượng hóa rõ ràng và thiết kế hệ thống giản lược.
    • Kỹ thuật tốt nhất luôn được sinh ra từ ràng buộc, và giới hạn thời gian con người hạn chế tải nhận thức, thúc đẩy việc theo đuổi sự đơn giản.
    • LLM không có những ràng buộc này nên không có động cơ nội tại để tự tìm kiếm tính đơn giản.

• Hướng sử dụng LLM như một công cụ

  • LLM vẫn có thể đóng vai trò quan trọng như một công cụ mạnh mẽ trong kỹ thuật phần mềm.
    • Theo hướng dẫn sử dụng LLM của Oxide, LLM chỉ là một công cụ, không thể thay thế các đức tính của con người.
  • LLM có thể được dùng để xử lý các vấn đề lười biếng không hiệu quả như nợ kỹ thuật (technical debt), hoặc tăng cường sự nghiêm ngặt kỹ thuật.
  • Nhưng mục đích sử dụng phải nhất thiết đi theo hướng thực hiện ‘lười biếng có đức tính’.
    • Nói cách khác, cần xây dựng hệ thống mạnh hơn nhưng đơn giản hơn, để lại kết quả có lợi cho những nhà phát triển thế hệ tương lai.

[GN⁺]

Nhận xét trên Hacker News

• Trong lĩnh vực của tôi, Computational Fluid Dynamics cũng có những người khoe rằng họ có rất nhiều test, giống kiểu khoe LOC.
  Nhưng khi nhìn kỹ thì các test đó không hề nghiêm ngặt, mà thậm chí còn thô sơ hơn rất nhiều so với test do tôi tự viết thủ công.
  1 triệu test đơn giản sẽ vô nghĩa nếu không bao phủ phần cốt lõi của mã

  • Tôi cũng nhận ra rằng mình phải tự viết test.
    Và luôn dùng git diff để kiểm tra thay đổi test, nhằm tránh để Claude “sửa” test khi code không chạy.
    Khi quản lý test nghiêm ngặt, Claude triển khai tốt cả thuật toán khó trong paper, giúp tiết kiệm thời gian, nhưng cần rất nhiều công sức chăm sóc
  • Đấy giống như một dạng reward hacking
    Mô hình lợi dụng hàm thưởng là test để dùng như một cách “kết thúc bằng chiến thắng”.
    Có thể các mẫu như vậy cũng đã có mặt trong dữ liệu tiền huấn luyện của RL
  • Việc tạo test không ngu ngốc cho LLM thật sự khó
    Hàng trăm test vô dụng kiểu assert(1==1) sẽ xuất hiện
    Vì vậy phải duy trì riêng một danh sách cấm cho những test như vậy

• Sau 30 năm coding thủ công, giờ tôi chuyển hẳn sang AI coding, và thấy buồn cười khi người khác nhận công LOC hay tính năng từ code do AI sinh ra.
  Tự hào “đã code hàng trăm nghìn dòng trong một ngày” thì cuối cùng chẳng phải chỉ là gõ vài dòng prompt sao.

  • Đây giống như một phổ
    Sửa đổi do tôi trực tiếp duyệt thì có thể được công nhận một phần, nhưng vibe-coded app hoàn toàn thì tôi gần như không can thiệp
    Tôi nằm giữa: không review toàn bộ code do AI viết, nhưng tôi dẫn dắt hướng thiết kế kiến trúc và refactor
    Kết quả giống như khi tôi tự làm, nhưng hoàn tất nhanh hơn rất nhiều
  • Meta giờ có leaderboard sử dụng AI, cho biết người tiêu thụ nhiều token Claude nhất.
    Vì Meta dùng Claude nên có lẽ Anthropic khá vui
  • Thực tế, nhiều LOC có thể là dấu hiệu của kết quả kém
  • Một số người cho rằng LoC không có ý nghĩa là chỉ số chất lượng
    Vì giờ cài đặt, test và bảo trì đều do agent đảm nhiệm
    Họ xem LoC chỉ là chỉ báo về khả năng đẩy yêu cầu của agent
    Feedback phê bình của con người vẫn có thể tiêm vào dưới dạng review

• Câu “phải trừu tượng hóa nhiều hơn” từng đúng ngày trước, nhưng bây giờ tôi lại thấy ngược lại
  Tôi thích triết lý WET (Write Everything Twice) — viết hai lần rồi mới suy nghĩ tới trừu tượng hóa ở lần thứ ba

  • Cũng gọi là Rule of Three
    Xem bài wiki
  • Vẻ đẹp thật sự của phần mềm nằm ở trừu tượng hóa đúng chỗ
    HĐH, RDBMS, cloud orchestration là những ví dụ của đổi mới
    Nhưng phần lớn code chỉ là logic nghiệp vụ, nên trừu tượng hóa lại cản trở
    Vì vậy nguyên tắc của tôi là: “đừng xây nền tảng cho đến khi có ít nhất ba trường hợp sử dụng thực tế đã được xác nhận”
  • Viết lại hai lần không phải là chuẩn thấp, nên tôi không thấy nó mâu thuẫn với trích dẫn của Perl
  • Viết lại lần hai là cơ hội cải thiện khi đã hiểu vấn đề hơn
    Khi thử trừu tượng hóa ở lần thứ ba cần tránh Second-System Effect — tự tin quá mức gây ra hệ thống phức tạp
  • Sự bùng nổ của các lớp trừu tượng kể từ Programming Perl năm 1991 là điều khó tin

• Chia sẻ câu nói nổi tiếng của tướng Đức Kurt von Hammerstein-Equord
  Người thông minh chăm chỉ là tham mưu, người ngốc và lười là công việc thường nhật, người thông minh lười là lãnh đạo,
  và người ngốc nhưng chăm chỉ là nguy hiểm, nên đừng bao giờ giao trách nhiệm cho họ

  • Tôi đùa: “Vậy tôi thuộc nhóm 90% lười biếng ở đâu?”

• Khoe đã viết 200.000 LOC bằng LLM là dại, nhưng cười nhạo “code của họ ngu ngốc” thì cũng sai tương tự
  Rốt cuộc, trọng tâm không phải là đầu ra code mà là tạo ra giá trị
  Tôi không biết Garry Tan thực sự tạo được giá trị hay chưa

  • Nếu xem chất lượng code là không quan trọng thì sẽ có chuyện rất lớn
    Vụ bê bối Horizon IT cho thấy code xấu thực sự gây ra thiệt hại
    Trong review của Gregorein, lập trình viên người Ba Lan, app của Garry có cả test harness, app Hello World, file logo trùng lặp v.v. và rối tung lên
    Lo ngại rằng code như vậy đã làm mở rộng bề mặt tấn công bảo mật
  • Garry không phải chỉ là developer thông thường, mà là CEO của YC
    Anh ấy không quan tâm LOC, mà đăng một bài quảng bá cho AI
  • Chỉ số thật sự là giá trị – chi phí
    AI giảm chi phí dev/ops, nhưng lại làm tăng các chi phí ẩn như rủi ro bảo mật, pháp lý
    Người ủng hộ AI thường chỉ nhấn mạnh một phía
  • Không có thời gian đọc 200.000 LOC để chứng minh đây là ý tưởng tồi
    Đó là việc mà một vibe coder phải làm để chứng minh Khoe bằng LOC vẫn vẫn là dại
  • Chính cụm từ “tạo giá trị” có thể đã nguy hiểm rồi
    Giống tăng trưởng phụ thuộc nhiên liệu hóa thạch, giá trị ngắn hạn có thể tạo chi phí dài hạn

• Gần đây xem vài PR, tôi thường thấy LLM đưa ra giải pháp sai
  Chẳng hạn implement parser JSON mới dù đã có parser có sẵn
  Con người có lẽ sẽ nghĩ “vô dụng quá”, nhưng vì LLM không biết lười nên nó lại kiên trì làm theo hướng sai

  • Nó cũng không nhận ra hàm trùng lặp trong dự án
    Cả ba hàm formatTimestamp tồn tại, chỉ cần grep một lần cũng thấy, nhưng nó vẫn bỏ qua

• Tôi đồng tình với ý kiến rằng LLM không bao giờ lười
  Không biết chuyện này có phải vấn đề cố hữu hay sẽ được giải quyết ở lần cập nhật model tiếp theo hay trong pipeline CICD
  Sau khi xong feature, tôi hay prompt “kiểm tra xem có lỗi hay refactor không”,
  Có thể về sau sẽ có bước tự động phân tích commit gần đây để đề xuất cách đơn giản hóa

  • Nhưng khi bảo “hãy tìm X”, LLM thì luôn tìm ra thứ gì đó
    Vì thế khó định nghĩa điều kiện dừng
  • Cuối cùng, vấn đề là không nằm ở bản chất công cụ mà ở giới hạn cách dùng
    Bảo “thêm vào” là nó sẽ luôn thêm; bảo “giảm bớt” là nó sẽ giảm LOC
    Giao việc lớn rồi bỏ qua review rất dễ tích lũy code slop

• LLM có xu hướng làm full SPA thay vì chương trình console output
  Và nó cũng không thể giữ file spec.md thật ngắn gọn
  Bảo “cập nhật tài liệu này và đơn giản hóa phần xung quanh”, nó lại làm phức tạp hơn
  Kết quả là vẫn cần con người viết summary để có docs dễ đọc
  Chỉnh sửa output của LLM đau đầu vô cùng, viết thủ công mới giữ được độ hiểu biết

• Đây là lúc dạy cho LLM và vibe coder bài học kinh điển phát triển phần mềm
  Như câu chuyện Negative 2000 Lines of Code, giảm code mới nhiều khi là tiến bộ thật sự

• Nghĩ xem nếu có thể làm việc cùng kiểu lãnh đạo như vậy thì hay biết mấy
  Thật sự làm cùng một leader có sự thấu hiểu là một cơ hội rất lớn