Dùng AI để viết mã tốt hơn theo cách chậm rãi hơn

 (nolanlawson.com)
8 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Lập trình với AI không chỉ có thể được dùng để nhanh chóng tạo ra số lượng lớn mã chất lượng thấp, mà còn có thể được tận dụng để rà soát PR thật kỹ nhằm tạo ra mã chất lượng cao một cách chậm rãi hơn
  • Tác nhân LLM rất mạnh trong việc phát hiện bug trong codebase, nhưng khó khăn thực sự nằm ở việc ưu tiên và kiểm chứng các mục đã phát hiện
  • Một Claude skill dùng nhiều mô hình cùng lúc sẽ dùng Claude sub-agent, Codex và Cursor Bugbot để rà soát PR, rồi tạo báo cáo cuối cùng đã giảm bớt false positive
  • Luồng xử lý là lặp đi lặp lại việc sửa các vấn đề critical/high, bỏ qua những mục có lợi ích thấp so với chi phí, và từ bỏ PR nếu có quá nhiều vấn đề nghiêm trọng
  • Cách làm này coi trọng sức khỏe của codebase hơn tốc độ, đồng thời củng cố kiểu lập trình cẩn trọng bằng cách hiểu các failure mode và bug hiện hữu

Cách dùng AI coding theo hướng chậm lại

  • Quan điểm chỉ xem AI coding là công cụ để nhanh chóng sản xuất hàng loạt mã chất lượng thấp đã đánh giá thấp tính linh hoạt của LLM
  • LLM không chỉ hiệu quả trong việc sinh mã nhanh mà còn có thể được dùng hiệu quả để viết mã chất lượng cao hơn theo cách chậm rãi hơn
  • Trái ngược với kiểu đổ ra các PR lớn chưa được kiểm chứng như slop cannons, cũng có thể áp dụng cách rà soát PR sâu hơn và kiên trì xác minh các khả năng thất bại

Kiểm chứng và ưu tiên còn quan trọng hơn phát hiện bug

  • Mythos cho thấy các tác nhân LLM có thể tìm bug rất giỏi trong codebase
  • Các trường hợp khác cũng cho thấy những mô hình không phải Mythos có thể tìm ra nhiều bug trong các codebase chưa được rà soát
  • Các mô hình công khai mới nhất của Anthropic và OpenAI có khác biệt về khả năng phát hiện bug tinh vi và tránh false positive, nhưng đều có thể tìm ra đủ nhiều bug
  • Khó khăn thực tế không nằm ở bản thân việc tìm bug mà ở xác định mức độ ưu tiên và kiểm chứng

Claude skill rà soát PR bằng nhiều mô hình

  • Cách tiếp cận AI code review bằng cách cho nhiều mô hình so sánh và tranh luận tập trung vào việc dùng càng nhiều mô hình khác nhau thì càng giảm khả năng hallucination hoặc báo bug sai
  • Claude skill đang được dùng sẽ chạy Claude sub-agent, Codex và Cursor Bugbot để rà soát PR
  • Mỗi công cụ sẽ chấm mức độ bug trong PR theo các mức critical/high/medium/low, sau đó tổng hợp kết quả để tạo ra báo cáo cuối cùng đã loại bỏ false positive
  • Phạm vi của “bug” có thể được mở rộng theo tiêu chuẩn của dự án
    • Vi phạm nguyên tắc KISS và DRY
    • Việc viết HTML/JSX có đảm bảo accessibility hay không
    • Việc truy vấn SQL có dùng chỉ mục phù hợp hay không
    • Các tiêu chuẩn chất lượng khác theo từng dự án

Workflow thực tế và tiêu chí đánh giá

  • Cách làm này có thể tìm ra nhiều bug trong PR, đồng thời hạ tỷ lệ false positive xuống gần như bằng 0
  • Các vấn đề được phát hiện rất đa dạng, từ bug nghiêm trọng liên quan đến bảo mật và tính đúng đắn, đến vấn đề hiệu năng, cho tới những lỗi mức độ thấp như “comment dễ gây hiểu nhầm”

  • Luồng xử lý điển hình

    • Để tác nhân sửa các mục critical và high, nhưng con người sẽ hướng dẫn giải pháp phù hợp
    • Lặp lại cho đến khi không còn mục critical/high
    • Bỏ qua các vấn đề high/medium có lợi ích thấp so với chi phí sửa
    • Một ví dụ điển hình là phải viết 100 dòng code chỉ để sửa một edge case hẹp
    • Nếu có quá nhiều vấn đề critical đến mức cho thấy toàn bộ hướng tiếp cận là sai, thì sẽ bỏ PR

Tập trung vào sức khỏe codebase hơn là năng suất

  • Kỹ thuật này không nhất thiết giúp tăng tốc độ phát triển
  • Trong quá trình review, có thể phát hiện bug tồn tại từ trước cả trước khi PR được tạo, dẫn tới việc viết unit test và sửa các lỗi tinh vi
  • Nó gần như đối lập với kiểu phát triển “năng suất gấp 10 lần” thường được liên tưởng đến khi nói về “vibe coding”
  • Trong các kiến trúc phức tạp, failure mode còn đáng chú ý hơn cả luồng chạy bình thường, và quá trình hiểu rồi sửa những điểm lỗi đó có thể trở thành cách để làm quen với codebase
  • Cách này hữu ích để vừa cải thiện sức khỏe tổng thể của codebase vừa học được những góc ít được biết đến trong hệ thống

Cách thực hành vibe coding chậm rãi

  • Nếu là một lập trình viên đang dùng tác nhân để tạo ra các PR dài hàng trăm dòng mà chính mình cũng chưa hiểu hết, bạn có thể thử cách chậm hơn
  • Có thể hỏi tác nhân PR đó hoạt động như thế nào và nó có thể thất bại ở đâu
  • Nếu cần, có thể yêu cầu nó viết tài liệu Markdown có kèm Mermaid charts
  • Có thể dùng skill /grill-me của Matt Pocock cho đến khi hiểu PR từ đầu đến cuối
  • “Năng suất” tính theo số dòng code có thể sẽ không tăng, và sau khi tiêu tốn nhiều token, bạn vẫn có thể đi đến kết luận rằng kế hoạch ban đầu là sai
  • Cách làm này gần với việc tăng cường kiểu lập trình cẩn trọng, có hệ thống và ám ảnh với chất lượng vốn đã được theo đuổi từ trước thời LLM

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Ở chỗ làm của tôi, chúng tôi đã từ bỏ giấc mơ dùng AI để đi nhanh hơn. Trong trường hợp của chúng tôi, việc viết code không phải là nút thắt cổ chai
    Dù vậy, điều hay ở coding agent là nó giúp tôi làm việc như kiểu một kỹ sư mà tôi luôn muốn trở thành
    Ví dụ như dựng một test harness tử tế để có thể đẩy code đi xa thêm một chút, thêm bước CI để xác minh code được tạo ra có khớp với bản gốc hay không, và giám sát việc triển khai thay đổi cho ra hồn
    Trước đây, những việc đó là thứ tôi không thể kham nổi trong tiến độ, vì phải đọc manual GitLab CI, học cách khớp điều kiện và hiểu kiểu làm rối rắm của công ty tôi, nhưng giờ thì làm được, và tôi nghĩ đó mới là tương lai

  • Tôi đã khá thành công khi dùng LLM như một người đồng hành làm spike hiểu API hoặc một cỗ máy refactor cơ học, đặc biệt hiệu quả trong các ngôn ngữ có kiểu mạnh. Nó cũng tốt để viết test, nhưng cần có quy trình nhiều lớp để đảm bảo những bài test đó thực sự có sức ràng buộc
    Mutation testing khá hữu ích, và như bài gốc đề xuất, cũng cần nhiều vòng rà soát
    Trước đây tôi tiêu cực với LLM hơn nhiều, đến mức nhìn lại thấy gần như phi lý, nhưng phần lớn là vì lượng phần mềm chất lượng thấp mà LLM từng tuôn ra
    Khi tự đào sâu vào, tôi nhận ra cách đúng là dùng nó như một công cụ làm prototype bằng bìa carton và một người đánh máy nhanh hơn rất nhiều. Ví dụ, nếu tôi bảo “hãy tìm pattern này trong mọi theorem của project Lean này rồi đổi sang pattern kia, đánh dấu lại những chỗ không chạy ngay được và đưa tôi danh sách còn lại”, thì nó sẽ sửa hơn 100 theorem theo từng chunk trong khoảng thời gian mà tôi còn đang loay hoay thử một hai lần đầu bằng cách trộn vim, sed, awk và mấy mẹo tạm bợ
    Với Lean thì đặc biệt tốt vì do đặc tính ngôn ngữ và loại công việc tôi làm, khoảng cách giữa “biên dịch được” và “chạy đúng” là khá hẹp; với Rust tôi cũng có cảm giác tương tự nếu gắn kèm một test suite tốt và mutation testing
    Tôi nghĩ cái đuôi dài của các công cụ này không phải là kiểu “bấm nút là ra sản phẩm”, mà là để kỹ sư giỏi chấp nhận chúng, dồn năng lượng vào việc quan trọng, và giao phần lớn việc vặt trước đây cho máy móc

    • Ban đầu tôi cũng rất tiêu cực với LLM, nhưng giờ tôi nghĩ chúng đã tiến bộ đến mức giúp ích nhiều hơn là gây cản trở
      Ví dụ này khá thú vị: hồi còn làm ở một team framework JavaScript, tôi từng tự viết codemod cho các việc như nâng cấp hay migration. Đó là công việc cực nhọc của việc chỉnh AST
      Giờ thì tôi nghĩ có thể giao cho LLM và đạt được cỡ 90%

  • Tôi thích góc nhìn này. Việc công cụ có tính linh hoạt và không nhất thiết phải tạo ra kết quả chất lượng thấp nghe có vẻ hiển nhiên, nhưng cả phe ủng hộ lẫn phe phản đối đều thường bỏ qua góc nhìn đó
    Tôi vẫn chưa thử dùng LLM để review code, nhưng chắc nên đưa vào danh sách việc cần làm. Đến giờ tôi chủ yếu dùng nó để lên ý tưởng, hoặc nhờ giúp về SQL hay VimScript, còn code thì tự viết
    Một rủi ro là review code cũng là một kỹ năng, nên nếu dựa quá nhiều vào model thì khả năng đó có thể bị mai một. Dù vậy, trong môi trường thương mại, ngay cả review code tốt nhất thường cũng chỉ là sự kết hợp giữa “thời gian hợp lý” và “có tin người này không”, chứ hiếm khi gần với độ chính xác toán học

    • Điều đó cũng đúng, nhưng tôi lại thấy quy trình làm việc này còn giúp tăng khả năng review code của tôi. Vì tôi phải tự đánh giá xem “bug” đó có thực sự khả thi hay chỉ là lý thuyết, có đáng sửa không, hay nên để sang PR tiếp theo
      Với bug phức tạp thì tôi thường vẫn tự suy nghĩ đến cùng, vì 1) ảo giác vẫn còn lẫn vào, và 2) dù sao hiểu hệ thống từ đầu đến cuối vẫn luôn có giá trị

  • Nói chuyện meta một chút, tôi không hiểu các lá cờ gắn vào bài này. 1 cái off-topic, 3 cái spam, nghe rất lạ
    Bài trên cùng ở trang đầu cũng là bài về việc dùng LLM, mà còn là về viết lách nói chung nên có vẻ còn kém liên quan chủ đề hơn bài này vốn tập trung vào code, vậy mà hình như không bị gắn cờ nào

    • Có lẽ họ xem đó là tự quảng bá nên gắn cờ spam

  • Thấy kiểu góc nhìn này trên Lobsters khá mới mẻ. Tâm lý chống AI một màu ngày càng làm tôi mệt mỏi. Tôi nghĩ ai cũng có thể đồng ý rằng không ai thích kết quả chất lượng thấp
    Nhưng những người chọn tẩy chay AI hoàn toàn và giữ thái độ giáo điều sẽ khó chấp nhận tương lai hơn những người chọn cách tiếp cận thực dụng hơn
    Ngay từ đầu tôi đã nói AI giống như sự ra đời của dụng cụ điện. Nếu bạn muốn thay lốp bằng cờ lê tay thì cũng được, nhưng khi máy khoan lực xuất hiện, thợ máy đâu có tẩy chay nó. Trong ngữ cảnh bài viết thì đây không phải phép so sánh hoàn hảo nhất, nhưng tôi vẫn nghĩ vậy
    Tôi học được nhiều hơn khi dùng AI so với chỉ đọc tài liệu, vì tài liệu không cho phép tôi hỏi thêm khi cần ngữ cảnh, giải thích hay ví dụ. Dĩ nhiên cũng có thể bảo nó “cứ làm gì đó đi, đừng mắc lỗi”, nhưng tôi thích cách tiếp cận chậm hơn để thực sự học

    • Tôi không thấy có tâm lý chống AI một màu ở đây. Bạn có thể dẫn ví dụ không?
      Điều tôi thấy là sự chỉ trích đối với việc dùng LLM để thay đổi hàng triệu dòng code trong một lần rồi triển khai mà không có con người review. Cụ thể là những trường hợp như thread về việc port Bun từ Zig sang Rust
      Bài này cũng đang phê phán điều đó