Công việc của bạn là bàn giao đoạn mã đã được chứng minh là hoạt động

 (simonwillison.net)
31 điểm bởi GN⁺ 2025-12-19 | 4 bình luận | Chia sẻ qua WhatsApp
  • Trong môi trường phát triển có trợ lý AI, ngày càng có nhiều trường hợp kỹ sư còn non kinh nghiệm gửi PR quy mô lớn chưa được kiểm chứng
  • Nhiệm vụ cốt lõi của lập trình viên không phải chỉ là viết mã, mà là cung cấp đoạn mã đã được chứng minh là hoạt động
  • Để làm được điều đó, bắt buộc phải thực hiện hai bước: kiểm thử thủ công và kiểm thử tự động
  • Tác nhân lập trình cũng cần được thiết lập để tự xác minh các thay đổi do chính nó tạo ra
  • Cuối cùng, trách nhiệm thuộc về lập trình viên con người, và chỉ những đoạn mã đi kèm bằng chứng xác minh mới thực sự có giá trị

Vấn đề của việc gửi mã chưa được kiểm chứng

  • Bài viết đề cập đến những trường hợp kỹ sư junior dùng công cụ LLM để gửi PR khổng lồ chưa được kiểm chứng rồi dựa vào code review
    • Điều này bị xem là bất lịch sự, kém hiệu quả, và là hành vi né tránh trách nhiệm của một lập trình viên
  • Vai trò của kỹ sư phần mềm không chỉ là sản xuất mã, mà là cung cấp đoạn mã đã được chứng minh là hoạt động
    • Mã chưa được kiểm chứng bị xem là hành vi chuyển gánh nặng sang người review

Hai bước để chứng minh mã hoạt động

  • Bước đầu tiên là kiểm thử thủ công, tức phải trực tiếp xác nhận rằng mã vận hành đúng như mong đợi
    • Cần thiết lập hệ thống về trạng thái ban đầu, áp dụng thay đổi rồi kiểm chứng kết quả
    • Có thể đính kèm lệnh terminal và kết quả đầu ra vào comment code review hoặc chứng minh bằng video quay màn hình
    • Sau khi xác nhận hoạt động bình thường, cần tiếp tục tìm vấn đề thông qua kiểm thử các trường hợp biên
  • Bước thứ hai là kiểm thử tự động, được nhấn mạnh là quy trình bắt buộc nhờ sự phát triển của các công cụ LLM
    • Cần đi kèm kiểm thử tự động cùng với thay đổi, và nếu hoàn tác phần triển khai thì bài kiểm thử phải thất bại
    • Việc viết kiểm thử tuân theo cùng quy trình như kiểm thử thủ công, và năng lực tích hợp test harness là yếu tố quan trọng
    • Việc cho rằng chỉ kiểm thử tự động là đủ rồi bỏ qua kiểm thử thủ công bị xem là cách tiếp cận sai lầm

Vai trò và việc xác minh của tác nhân lập trình

  • Một xu hướng lớn của lĩnh vực LLM trong năm 2025 là sự tăng trưởng bùng nổ của các tác nhân lập trình, tiêu biểu như Claude Code và Codex CLI
    • Chúng có thể chạy mã và tự sửa vấn đề
  • Tác nhân lập trình cũng phải chứng minh các thay đổi của chính mình, bằng cách thực hiện cả kiểm thử thủ công lẫn tự động
    • Với công cụ CLI, có thể huấn luyện để tác nhân tự chạy trực tiếp, hoặc tự động hóa bằng các hệ thống như CLIRunner của Click
    • Với thay đổi CSS, có thể cấu hình để xác nhận kết quả bằng chụp ảnh màn hình
  • Nếu dự án đã có sẵn kiểm thử, tác nhân sẽ mở rộng chúng hoặc tái sử dụng các mẫu hiện có
    • Cấu trúc và chất lượng của mã kiểm thử ảnh hưởng trực tiếp đến chất lượng kiểm thử do tác nhân tạo ra
    • Cảm quan thẩm mỹ đối với mã kiểm thử được nhắc đến như một năng lực cốt lõi để phân biệt kỹ sư senior

Trách nhiệm của con người và giá trị của mã

  • Máy tính không thể chịu trách nhiệm, và con người phải đảm nhận vai trò đó
    • Việc để LLM tạo ra các bản vá lớn không còn là điều có giá trị nữa
  • Giá trị thực sự nằm ở việc cung cấp đoạn mã đã được chứng minh là hoạt động
    • Khi gửi PR, bắt buộc phải kèm theo bằng chứng cho thấy mã hoạt động đúng

Bài viết liên quan

4 bình luận

 
ethanhur 2025-12-19

Tôi rất đồng cảm. Hiện tại, trách nhiệm đối với mã theo cách PR đang bị chuyển sang cho maintainer và reviewer. Không có bất lợi nào đối với người gửi lên mã do LLM tạo ra mà chưa được tự mình rà soát.

Khi thử đóng góp vào codebase của Google, tôi thấy họ đo lường những thứ như mức độ tín nhiệm của contributor; có lẽ các dự án mã nguồn mở / doanh nghiệp khác cũng sẽ bắt đầu áp dụng điều này. Tôi nghĩ niềm tin sẽ trở thành một tài sản còn quan trọng hơn nữa.
 
roxie 2025-12-19

Ồ, vậy là Google dùng khái niệm đó à.
 
GN⁺ 2025-12-19
Ý kiến trên Hacker News

  • Gần đây có một giai thoại buồn xuất hiện khá thường xuyên. Một kỹ sư junior được tiếp sức bởi công cụ LLM ném một PR khổng lồ, chưa được kiểm thử cho đồng nghiệp hoặc maintainer mã nguồn mở, rồi kỳ vọng code review sẽ xử lý phần còn lại. Tệ hơn nữa là kiểu hành xử này không chỉ đến từ junior mà còn từ cả các lập trình viên senior

    • Hôm qua và hôm nay chính tôi đã làm đúng kiểu đó. Nhóm chúng tôi nhận được một bug report và đánh giá đó là vấn đề từ vendor bên ngoài. Nhưng vendor đẩy ngược lại và nói là lỗi từ phía chúng tôi. Thế là tôi để Codex xem thử, nó tìm ra vấn đề và chuẩn bị một PR. Tôi không tự review hay test mà giao cho cả nhóm xác minh. Quá trình đó cũng giúp huấn luyện cả nhóm sử dụng LLM như công cụ làm việc
    • Trong hai ngày gần đây, có hai thành viên không phải lập trình viên hỏi AI agent cách sửa lỗi trên mobile rồi đưa nguyên câu trả lời đó thành nội dung chính của ticket. Cuối cùng tôi vẫn phải đọc hết và xác định lại yêu cầu thực sự
    • Có rất nhiều người mang danh “senior” nhưng hành xử như junior. Có lẽ đây là hiện tượng xảy ra khi giờ chỉ cần ra trường được 2 năm cũng đã bị gọi là senior
    • Những lập trình viên có thể phớt lờ hoặc lách quy tắc là nguy hiểm nhất. Điều đó làm tôi nhớ đến những lập trình viên 10x từng gặp. Nếu cứ bỏ qua quy tắc và chỉ xả tính năng, cuối cùng người khác sẽ phải dọn hậu quả
    • Tôi tự hỏi junior đang ở đâu trong quá trình code review. Nếu họ không tham gia review, sẽ rất khó để họ cảm thấy có trách nhiệm với chất lượng mã của mình

  • Cách viết PR tốt không chỉ áp dụng cho mã do AI sinh ra mà đúng trong mọi trường hợp. Khi viết mô tả PR, tôi thường sắp xếp theo thứ tự: cách hệ thống đang hoạt động, lý do thay đổi, và nội dung thay đổi. Tôi còn kèm cả cách test, ảnh chụp màn hình, và lệnh test E2E để giảm gánh nặng cho reviewer. Cách này cũng hữu ích cho cộng tác bất đồng bộ hoặc các nhóm làm việc lệch múi giờ

    • Tôi luôn tự xem lại một lần nữa trước khi yêu cầu review. Xử lý trước những lỗi gõ nhỏ hay xóa log thừa có thể tiết kiệm thời gian cho reviewer. Copilot review cũng bắt được mấy chỗ kiểu này khá tốt
    • Dù viết mô tả kỹ đến đâu thì nhiều khi cũng chẳng ai đọc. Nhưng tôi vẫn tiếp tục viết vì đó là trách nhiệm của mình
    • Dù là PR có AI hỗ trợ hay không thì vẫn phải có bằng chứng kiểm thử và xác minh
    • Trước đây tôi từng viết mô tả rất dài, nhưng rồi nhận ra chẳng ai đọc. Tóm tắt trọng tâm bằng bullet point lại hiệu quả hơn
    • Template PR của nhóm chúng tôi có số ticket, mô tả yêu cầu, trạng thái hiện tại, trạng thái sau thay đổi, và cả ‘mood gif’ nữa

  • Bản chất của kỹ sư là hiểu yêu cầu, chuyển chúng thành luồng logic, cân bằng trade-off, và chịu trách nhiệm với kết quả. Việc sinh code hay ném PR bừa bãi là triệu chứng của sự thiếu hụt những nền tảng đó. Các coding agent ngược lại đang là dịp nhắc mọi người nhớ lại bản chất của nghề kỹ sư

    • Bài này có ví dụ một dòng code gây thiệt hại 60 triệu USD. Một PR 10.000 dòng do AI tạo ra mà không hiểu code là một thảm họa tiềm tàng
    • Thực tế thì doanh nghiệp coi trọng marketing và lợi nhuận hơn chất lượng. Sản phẩm gắn nhãn ‘premium’ thường bán chạy hơn sản phẩm thực sự chất lượng cao. Cuối cùng, thứ được ưu tiên không phải engineering mà là ‘thứ bán được’
    • Nhưng vấn đề là khi tổ chức gây áp lực kiểu “dùng AI để hoàn thành tính năng trong 3 ngày, không thì gặp HR”, thì rất khó giữ được các nguyên tắc engineering lý tưởng

  • Test là cần thiết nhưng không đủ. Cần xác minh code bằng logic. Test chỉ chứng minh việc hoạt động bình thường trong những đầu vào và môi trường cụ thể mà thôi

    • Tôi cũng nghĩ vậy. Code chạy tốt vẫn có thể rất tệ
    • So với “proof”, từ “demonstrate” có lẽ phù hợp hơn. Test chỉ là bằng chứng trong một số trường hợp cụ thể
    • Tôi không chỉ tin vào test mà còn cố tự tay phá ứng dụng bằng nhiều cách khác nhau. Trong quá trình đó tôi thường cải thiện được code tốt hơn
    • Vì phần lớn code không thể được chứng minh hình thức, các cách tiếp cận như property-based testing có vẻ hữu ích
    • Đạt 100% test coverage cũng vô nghĩa nếu code không đủ vững chắc

  • Tôi không coi test là nghĩa vụ. Tôi làm test đơn giản vì muốn tận mắt thấy code thực sự chạy được. Nếu nhìn code chạy mà bạn không thấy hào hứng thì nghề này có lẽ không hợp với bạn

  • Tôi có nghe chuyện junior nhờ LLM rồi ném ra PR khổng lồ, nhưng trong tổ chức của chúng tôi thì chuyện đó vẫn chưa xảy ra

    • Không đến mức PR khổng lồ, nhưng tôi thường xuyên thấy mã do LLM tạo ra mà chính lập trình viên cũng không hiểu
    • Ở chỗ chúng tôi cũng có các trường hợp như vậy. Vấn đề gồm có như sau
      • Agent hoàn tác phản hồi trước đó
      • Không tuân theo chuẩn của codebase
      • Phát minh lại giải pháp đã có
      • Trả lời feedback trong PR bằng đầu ra của agent
      • Việc chỉ cần sửa 10~20 dòng lại bị nộp thành PR 50.000 dòng
      • Thiếu test, xử lý lỗi kém
    • Những người vốn từ trước đã nộp PR chất lượng thấp thì nhờ LLM chỉ đơn giản là nộp nhanh hơn thôi
    • Nhìn vào WireGuard Android PR #82, #80 sẽ thấy nguyên cả câu trả lời copy-paste từ AI vẫn còn nằm nguyên ở đó. Mở tab “files changed” ra là thấy rối ngay
    • Một người bạn của tôi làm ở startup 11 người, CTO của họ đẩy thẳng 10.000 dòng code lên main lúc 3 giờ sáng. Ở giai đoạn khám phá thì còn chấp nhận được, nhưng ở giai đoạn ổn định thì đó là một rủi ro kinh khủng

  • Tôi không đồng ý với câu “công việc là bàn giao code ở trạng thái đã được chứng minh”. Công việc thật sự là giải quyết vấn đề kinh doanh. Tất nhiên trong đa số trường hợp điều đó dẫn tới code, nhưng phân biệt như vậy vẫn quan trọng

    • Nhưng chứng minh tính đúng đắn của code là một phần của việc giải quyết vấn đề kinh doanh. Không phải chuyện tách biệt
    • Không thể giải quyết vấn đề kinh doanh bằng cách bàn giao code không đáp ứng yêu cầu
    • Điều quan trọng là giải quyết vấn đề mà không tạo ra vấn đề mới. Vì vậy mới cần tính bảo mật và độ ổn định
    • Có thể vì tôi chưa có nhiều năm kinh nghiệm, nhưng tôi không hiểu làm sao có thể giải quyết vấn đề bằng code chưa được xác minh
    • Cuối cùng thì mọi nghề đều nhằm giải quyết vấn đề. Chỉ là chúng ta làm điều đó thông qua máy tính mà thôi

  • Ở công việc trước đây tôi từng làm tại một nhà sản xuất phần cứng chất lượng cao của Nhật, nơi nếu bộ phận QA tìm ra bug thì việc ra mắt sản phẩm sẽ bị dừng lại. Vì vậy mỗi bộ phận phát triển đều lập đội QC riêng để tăng cường test trước. Kết quả là phần mềm được xác minh rất kỹ lưỡng

    • Tôi thắc mắc “get dinged” nghĩa là gì. Cấu trúc như vậy ngược lại cũng có thể khiến mọi người sợ thay đổi hơn

  • Dạo này bản chất công việc đã biến thành đóng ticket. Chất lượng code không hiện ra trong thống kê nên thành ra không còn quan trọng. Tôi không tham gia vào hệ thống như vậy. Giờ tinh thần nghề thủ công đã biến mất, ai cũng chỉ muốn gỗ dán rẻ tiền và keo dính

    • Ngay khoảnh khắc LLM được triển khai toàn diện và mọi người được kỳ vọng phải dùng nó, software engineering không còn là một ngành kỹ thuật nghiêm túc nữa
    • Cũng có người hỏi những ai chỉ trích thái độ đó rằng “thế anh sống bằng trợ cấp chính phủ à?”

  • Vấn đề nằm ở ý nghĩa của “code đã được chứng minh”. Cũng có trường hợp người ta gắn thêm test do LLM tạo rồi nộp một PR khổng lồ. Tôi cũng vibe coding trong dự án cá nhân, nhưng làm vậy ở quy mô cả nhóm là một thói quen xấu. Lý do người ta thuê kỹ sư là để mua lấy chuyên môn của họ

    • Vì thế tôi nhấn mạnh test thủ công. Chỉ cần cho thấy hành vi thực tế bằng ảnh chụp màn hình hoặc video thôi cũng tạo được niềm tin rất lớn