8 điểm bởi GN⁺ 3 giờ trước | Chưa có bình luận nào. | Chia sẻ qua WhatsApp
  • Nguyên tắc "Choose Boring Technology" tập trung vào các stack công nghệ có thể kiểm chứng càng trở nên quan trọng hơn trong thời đại công cụ lập trình AI
  • Doanh nghiệp nên sử dụng chiến lược các "innovation tokens" hữu hạn của mình cho những công nghệ đã được chứng minh về độ tin cậy
  • Các công cụ lập trình AI hiện đại có thể tạo ra đoạn mã trông rất thuyết phục cho gần như mọi stack công nghệ, nhưng khi người dùng kết hợp từ hai công nghệ trở lên mà bản thân không hiểu rõ thì không thể xác minh lỗi
  • Với stack công nghệ đã rất quen thuộc, công cụ lập trình AI hoạt động như force multiplier (công cụ khuếch đại năng lực), nhưng với công nghệ xa lạ thì lại chỉ còn là phương tiện để phụ thuộc
  • Chất lượng mã do AI tạo ra càng cao thì càng khó phát hiện vấn đề, nên giá trị của sự hiểu biết sâu về công nghệ lại càng lớn hơn

Khẳng định lại nguyên tắc Choose Boring Technology

  • Quan điểm từng đồng cảm với bài viết "Choose Boring Technology" của Dan McKinley cách đây 10 năm vẫn không thay đổi sau một thập kỷ
    • Khi bắt đầu một dự án mới, trước tiên cần tự hỏi: "Đây là cái cớ để học thứ mới hay là để giải quyết vấn đề?"
    • Nếu là để học cái mới thì hãy giới hạn yếu tố chưa biết ở một thứ, còn nếu là để giải quyết vấn đề thì hãy bám vào công nghệ mình đã biết
  • Với sự xuất hiện của LLM và các công cụ lập trình AI mang tính agentic, nguyên tắc này càng trở nên critical hơn

Lập luận cốt lõi của McKinley

  • Doanh nghiệp sở hữu số lượng "innovation tokens" hữu hạn, và nên dùng chúng một cách chiến lược cho các công nghệ đã được thiết lập và hiểu rõ, thay vì các công nghệ thú vị nhưng chưa được kiểm chứng
  • Công nghệ nhàm chán có các failure modes (chế độ lỗi) đã được biết đến, tính năng được hiểu rõ, và độ tin cậy vận hành đã được chứng minh
    • Khi sự cố xảy ra lúc 3 giờ sáng, tốt hơn là debug một công nghệ có sẵn câu trả lời trên Stack Overflow thay vì khai phá vùng đất chưa biết
  • Nguyên tắc này đúng vào năm 2015 và đến hôm nay vẫn đúng

Công cụ lập trình AI như một biến số mới

  • Các công cụ lập trình AI hiện đại có thể tạo ra mã trông chuyên nghiệp cho gần như mọi stack công nghệ có thể tưởng tượng ra
    • Nếu yêu cầu Claude hoặc Copilot triển khai microservices dựa trên Kubernetes, GraphQL federation, hay framework JavaScript mới nhất, chúng sẽ trả về mã tuân theo quy tắc và có thể chạy được
  • Nếu dùng từ hai công nghệ trở lên mà bản thân không hiểu, thì gần như không có cách nào để xác minh liệu AI có đang đưa ra kết quả sai hay không
    • Dù có năng lực ấn tượng, LLM vẫn hallucinate (ảo giác) ở các chi tiết kỹ thuật
  • Đã chứng kiến những trường hợp kỹ sư chấp nhận nguyên trạng đoạn mã có vấn đề do AI tạo ra
    • Sử dụng API đã deprecated, triển khai security anti-pattern, hoặc các vấn đề hiệu năng tinh vi chỉ lộ ra dưới tải production
    • Mã trông có vẻ đúng, tuân theo quy ước đặt tên, có xử lý lỗi phù hợp, nhưng vẫn sai theo cách mà chỉ người quen thuộc với công nghệ đó mới phát hiện được

Công nghệ chưa biết + mã AI = phép nhân của bất định

  • Kết hợp công nghệ không quen thuộc với mã do AI tạo ra không phải là cộng thêm ẩn số, mà là nhân chúng lên
    • Không biết lựa chọn framework có phù hợp hay không
    • Không biết phần triển khai của AI có tuân theo best practice hay không
    • Không biết phần nào trong mã được tạo ra là boilerplate và phần nào là business logic cốt lõi
    • Không biết cần theo dõi failure mode nào
  • Đây không chỉ là cargo-culting đơn thuần mà là vấn đề ở mức "cargo-culting nhân 2.356"

Điểm công nghệ nhàm chán và AI tạo ra hiệp lực

  • Khi hiểu stack nền tảng, công cụ lập trình AI trở nên cực kỳ mạnh
    • Vì đã hiểu Rails đủ sâu nên có thể phát hiện khi Claude đưa ra đề xuất đáng ngờ (có tận dụng hỗ trợ của context7)
    • Vì hiểu đặc tính của JavaScript nên có thể fact-check các đề xuất của Copilot
  • AI là force multiplier với công nghệ đã hiểu, nhưng sẽ trở thành chiếc nạng phụ thuộc (crutch) với công nghệ chưa biết

Hướng dẫn thực dụng trong thời đại AI

  • Khi đánh giá công nghệ mới, trước tiên hãy tự hỏi: "Nếu AI tạo mã triển khai cho công nghệ này, liệu mình có thể review nó một cách đúng đắn không?"
    • Nếu câu trả lời là "không", thì không nên dùng công nghệ đó ở nơi mission-critical
  • Nếu đã quyết định học thứ mới (và bạn chỉ có một innovation token), hãy thực sự dành thời gian để hiểu đủ sâu nhằm fact-check các gợi ý của AI
    • Đừng chỉ copy-paste rồi cầu mong nó hoạt động
  • Hãy chống lại cám dỗ ôm nhiều công nghệ mới cùng lúc chỉ vì có công cụ AI
    • AI khiến người ta có cảm giác như có thể xử lý đồng thời ngôn ngữ mới, framework mới và hạ tầng mới, nhưng thực tế là không thể xác minh đầy đủ thứ nào cả

Rủi ro gia tăng trong thời đại AI và kết luận

  • Lập luận ban đầu của "choose boring technology" là để giảm độ phức tạp vận hành và gánh nặng nhận thức, và mối lo đó vẫn còn nguyên giá trị
  • Trong thời đại AI còn có thêm một rủi ro: false confidence (sự tự tin sai lầm) mà AI mang lại khi tạo ra mã trông chuyên nghiệp cho bất kỳ stack nào
  • Chính vì chất lượng mã do AI tạo ra mà độ khó phát hiện vấn đề lại tăng lên
    • Trước đây mã tệ thì trông đã tệ, còn bây giờ phải hiểu đủ sâu về domain mới nhận ra được những vấn đề tinh vi
  • Khi giải quyết vấn đề, hãy dùng thứ mình đã biết; khi học cái mới, hãy tập trung vào việc học; và đừng nhầm lẫn mã do AI tạo ra với sự hiểu biết
  • Công nghệ nhàm chán nhất trong stack có thể chính là công nghệ mà bạn hiểu đủ rõ để nhận ra khi AI sai
    • Trong một thế giới nơi AI có thể tự tin tạo ra hàng nghìn dòng mã cho một công nghệ bạn chưa từng dùng, giá trị của sự hiểu biết đó còn lớn hơn bao giờ hết

Chưa có bình luận nào.

Chưa có bình luận nào.