Ask HN: Việc lập trình theo kiểu agentic có thực sự hiệu quả không?

• Tôi đã thử coding với agent, nhưng khoảng cách giữa những gì tôi thấy trên mạng và kết quả tôi thực sự làm ra khiến tôi đau đầu; có bằng chứng nào cho thấy cách này thực sự mang lại kết quả tích cực không?
• Vượt ra ngoài những lời quảng bá phóng đại, nếu ai đó đã triển khai thành công agentic coding thì xin hãy chia sẻ chi tiết cách bạn đã làm
• "Triển khai thành công" ở đây có nghĩa là:
  • Tạo ra nhiều giá trị hơn là nợ kỹ thuật
  • Viết mã có cấu trúc vững chắc đến mức người chịu trách nhiệm kiến trúc có thể phê duyệt
• Gần đây dường như có xu hướng giảm thiểu hoặc thậm chí loại bỏ hẳn code review, cùng với lập luận rằng cần chuyển từ "xác minh kiến trúc" sang "xác minh hành vi"
• Trên thực tế, điều này dường như có nghĩa là nếu vượt qua test và CI thì sẽ triển khai mà không cần nhìn vào mã, và tôi nghi ngờ liệu cách làm này có bền vững về dài hạn hay không

• Theo tôi, khi dùng Codex thì có thể chạy được trong những luồng thông thường, nhưng theo thời gian rất dễ trở thành "mã spaghetti" tích tụ các lỗi tinh vi, khó debug
• Khi tôi áp dụng Codex vào codebase hiện có, dù có đặt guideline hay không, thì một nửa thời gian của tôi vẫn bị dùng để sửa các lỗi tinh vi hoặc mã trùng lặp mà Codex tạo ra

• Cuối tuần trước tôi đã thử làm lại từ đầu một ứng dụng iOS nhắc cho thú cưng ăn
  • Tôi yêu cầu Codex trước hết nghiên cứu và đề xuất một bản thiết kế kiến trúc dựa trên SwiftUI, rồi cùng Codex viết ra đặc tả mô tả cần triển khai gì và bằng cách nào
  • Bản triển khai đầu tiên có vài lỗi nhưng tốt ngoài mong đợi, tuy nhiên sau đó thì mọi thứ xuống dốc rất nhanh
  • Trong phần còn lại của cuối tuần, tôi cố khiến Codex hoạt động đúng, sửa lỗi mà không tạo ra lỗi mới, và nghiên cứu best practice thay vì viết mã một cách tùy tiện
  • Mỗi khi phát hiện thêm guideline mới, tôi đều yêu cầu Codex ghi lại, nhưng tình hình không cải thiện và cuối cùng tôi bỏ cuộc
• Cá nhân tôi cho rằng việc triển khai mã chưa được review là không thể chấp nhận được
• Có gì đó đang sai. Sản phẩm phải hoạt động đúng, nhưng chất lượng mã cũng phải cao

[GN⁺]

Ý kiến trên Hacker News

• Khi LLM được xem là chìa khóa để cắt giảm chi phí, có rất nhiều tiền đang được đặt cược vào đó
  Ngay cả các influencer hay chuyên gia nổi tiếng cũng đôi khi đưa ra những phát biểu cường điệu để giữ hình ảnh “tối tân”
  Nhưng trên thực tế, cách tiếp cận tối ưu cho phát triển dựa trên LLM vẫn chưa được xác lập
  Lúc này, thay vì tin như một đức tin, tôi nghĩ điều quan trọng là tự mình xem xét cách nó vận hành bên trong

  • Gần đây tôi cũng nhận được đề nghị 200 đô từ một công ty để quảng bá “agentic coding platform” mới của họ
    Việc những đề nghị như vậy còn được gửi tới cả người dùng ngẫu nhiên cho thấy một chiến dịch marketing đáng kể đã diễn ra
  • LLM rõ ràng là một công cụ mang tính bước nhảy vọt, nhưng không phải chiếc chìa khóa vạn năng cho phát triển hoàn toàn tự động
    Nó rất thú vị với các tác vụ CRUD đơn giản, nhưng với dự án phức tạp thì ngược lại còn gây thất vọng
    Hiện tại là thời điểm cạnh tranh benchmark và vốn VC đổ vào dồn dập nên rất khó có được thảo luận tỉnh táo
  • Giống như khi GUI mới xuất hiện lần đầu, tôi nghĩ bây giờ là giai đoạn cảm nhận được giá trị trực quan
    Dù vẫn còn thiếu bằng chứng định lượng, nhưng ngay cả khi lập trình viên không biến mất hoàn toàn thì cách phát triển phần mềm đã thay đổi vĩnh viễn

• Một Principal Engineer của Google đã tweet rằng “Claude Code làm xong việc đáng ra mất 1 năm chỉ trong 1 giờ”
  Nhưng sau đó mới lộ ra rằng thứ AI tạo ra chỉ là một “phiên bản đồ chơi” đơn giản
  Những phát biểu cường điệu kiểu này làm méo mó kỳ vọng và dẫn tới thất vọng
  Liên kết tweet liên quan

  • Những tweet như vậy thường xuất phát từ áp lực nội bộ phải chứng minh thành tích lãnh đạo AI
  • Có người phản ứng rằng “nói như vậy thật vô lý”
  • Người khác lại chỉ ra rằng “thành quả AI còn phụ thuộc vào mức độ kinh nghiệm và chi phí đầu tư”
  • Cũng có phản ứng mỉa mai rằng “AI vẫn chỉ tạo ra mã không thể triển khai”
  • Có người châm biếm rằng “chuyện này cho thấy rất rõ Google là như thế nào”

• Nhìn lại 6 tháng qua, tôi đạt hiệu quả gấp 10 lần ở mã hạ tầng (ví dụ: Terraform)
  Nhưng việc phát triển tính năng chuyên biệt vẫn còn rất thất thường
  Dù vậy, nhờ giảm bớt việc lặp lại, tôi có thêm thời gian để nâng chất lượng kiểm thử và bảo mật
  Quan trọng hơn cả là tôi lại cảm thấy niềm vui khi lập trình

  • Tôi cũng đã làm dự án cá nhân 35 năm nay, và AI giúp giảm bớt việc gõ phím nhàm chán, khơi lại sự sáng tạo
  • Tôi cũng tăng tốc hơn 2 lần ở script build hay công việc CI, nhưng các dự án HPC phức tạp vẫn còn khó, và
    cách lập trình có hỗ trợ (assisted coding) là hiệu quả nhất
    Liên kết dự án
  • Tôi đã dùng Claude để làm công cụ tìm kiếm tệp cho NAS ở nhà, hoàn thiện backend Go và web UI có lập chỉ mục tự động hằng ngày chỉ trong một ngày
    Tôi nghĩ những dự án cá nhân như thế này mới là game changer thực sự
  • Nếu chia nhỏ công việc, agent sẽ hoạt động tốt hơn nhiều
  • Tuy nhiên, chất lượng mã kiểm thử vẫn còn thấp. Vì chính dữ liệu huấn luyện vốn đã yếu ở việc viết test

• Tôi đã đạt thành công lớn với cách gắn agent vào ứng dụng hiện có
  Agent yếu ở thiết kế kiến trúc, nhưng lại hoạt động rất tốt trên mã đã được cấu trúc sẵn
  Hệ thống kiểu càng chặt chẽ và độ phủ test càng rộng thì hiệu quả càng lớn

  • Hiện tại tôi đang thử để LLM trực tiếp quản lý và phát triển một dự án Rust
    Tôi làm việc dựa trên các tệp ROADMAP.md, TASKS.md, STATUS.md do Claude viết, và
    đáng ngạc nhiên là hiện đã hoàn thành khoảng 20%
  • C# hợp với agent nhờ compiler nghiêm ngặt và môi trường dựa trên quy tắc
    Ngược lại, Python hay JS khó tin cậy vì hệ thống kiểu yếu
  • Codebase hiện có càng gọn gàng, ngăn nắp thì agent càng hoạt động tốt
    Làm từ đầu thì khó, nhưng nếu có đặc tả rõ ràng thì hiệu quả sẽ cao
  • Go dễ để LLM xử lý nhờ ngôn ngữ đơn giản và các mẫu nhất quán
  • Typescript là lý tưởng cho agent nhờ biên dịch nhanh và hệ thống kiểu mạnh
    Trong khi đó, kiểu tùy chọn của Python lại gây ra lan truyền lỗi

• Tôi đã dùng Claude Code viết 100% một trình theo dõi nhịp tim Bluetooth thời gian thực cho Linux
  Liên kết dự án
  Nó được viết bằng C thuần, và tôi đã hoàn thiện cả giao diện web lẫn biểu đồ thời gian thực chỉ trong một ngày
  Lần này tôi còn triển khai thành công phần giao tiếp dBus–blueZ mà trước đây từng thất bại

  • Tuy nhiên, khi người khác xem lại mã thì hóa ra triển khai SSE thực tế không hoạt động
    Trong tài liệu ghi là SSE nhưng bên trong chỉ trả về phản hồi HTTP thông thường
  • Có người khác chỉ ra rằng “mã do AI viết lúc đầu trông có vẻ ổn nhưng chất lượng giảm dần theo thời gian”
  • Cũng có người cảm ơn vì đã chia sẻ ví dụ thực tế như vậy và đánh giá đây là trường hợp không cường điệu
  • Cũng có bình luận hỏi về thiết kế vì thấy phong cách UI khá thú vị

• Tôi dùng Augment + Claude Opus 4.5 mỗi ngày
  Gần như không tự viết code, mà hoàn thành dự án bằng quy trình lặp dựa trên đặc tả
  Cách chạy nhiều agent song song rồi review đặc biệt hiệu quả
  Viết đặc tả rõ ràng và phản hồi theo từng bước là chìa khóa

  • Dù không rành Ruby, tôi vẫn nhận được trợ giúp lớn khi phát triển ứng dụng Rails
    Tôi cảm thấy đây là thay đổi mang tính cách mạng nhất trong 30 năm làm nghề và tin chắc toàn ngành sẽ thay đổi
  • Có người đùa rằng “gọi một dự án 1 tuần là quy mô trung bình thì nó nhỏ quá”
  • Người khác nhận xét rằng “cái này gần với phát triển cộng tác với LLM hơn là phát triển bằng agent thực sự”
  • Cũng có ý kiến cho rằng “phát triển lấy đặc tả làm trung tâm (spec-driven) là chìa khóa để đạt chất lượng sản phẩm”
  • Tôi thêm một bước là để Claude đặt câu hỏi trước nhằm làm rõ yêu cầu
    Hiện tôi đang thực hiện một dự án từ điển tiếng Nhật–tiếng Anh bằng Claude
    Liên kết GitHub, website

• Là một lập trình viên có 20 năm kinh nghiệm, nhờ LLM mà ước lượng tốc độ công việc của tôi lệch hẳn đi
  Trước đây việc mất 2 tuần giờ chỉ cần 2 ngày
  Vẫn cần review mã và tương tác, nhưng tôi cảm thấy nó giỏi hơn phần lớn lập trình viên con người
  Trò chuyện với LLM giống như hợp tác với một lập trình viên senior, và
  kinh nghiệm lâu năm của tôi trong review code và phân chia công việc giúp ích rất nhiều

  • Có người hỏi về loại vấn đề vì cho rằng mức tăng tốc như vậy khó tin
  • Người khác chỉ ngắn gọn nói rằng “đã mong có bằng chứng nhưng không thấy”

• Cách ổn định nhất mà tôi từng dùng là giao cho Claude các đơn vị công việc nhỏ và rõ ràng
  Tôi lặp lại theo kiểu lập kế hoạch, xem xét, triển khai rồi review
  Dù không hoàn hảo, nó rất hữu ích để gỡ những điểm bị mắc kẹt
  Tuy nhiên nó không giỏi tuân thủ guideline, nên tự xác minh và dọn dẹp là bắt buộc

  • Tôi cũng dùng Claude giống như rubber duck debugging.
    Giao từng hàm một, rồi tham khảo kết quả để nghĩ ra ý tưởng tốt hơn
  • LLM đặc biệt mạnh ở công việc tài liệu hóa hay phân tích
    Nhưng khi chuyển sang vấn đề thiên về thiết kế, giới hạn của nó hiện ra rất rõ
  • Khi được hỏi “nên để guideline ở đâu”, có người khuyên nên đưa thông tin build và test vào CLAUDE.md

• Nhiều người đang hiểu sai về lập trình có AI hỗ trợ
  AI không phải thành viên trong nhóm mà là trợ lý
  Cốt lõi không phải xem bug hay trục trặc là thất bại, mà là quá trình một lập trình viên lành nghề dọn dẹp sự hỗn loạn đó

  • Có người hỏi “nếu vẫn phải động tay nhiều như vậy thì khác gì autocomplete trong IDE?”
  • Người khác đặt câu hỏi liệu các kỹ thuật mới nhất có thực sự chứng minh được cải thiện chất lượng hay không
  • Cũng có người mỉa mai rằng “nghe rốt cuộc vẫn chỉ là ‘bạn đang dùng sai thôi’”
  • Cũng có câu đùa rằng “nếu bạn mong nó vừa xem bóng chày vừa làm ra ứng dụng hoàn hảo, thì thứ bạn mua không phải AI mà là pháp sư”

• Tôi cũng dùng Claude mỗi ngày, nhưng mã kiểm thử do AI tạo ra thường rất tệ
  Thực tế nó sản xuất hàng loạt những test vô nghĩa như expect(true).to.be(true)

  • Mô hình cũ thì thất bại, nhưng tôi từng đọc rằng mô hình mới nhất lại tạo ra mã gian lận để vượt test
  • Vì thế tôi viết và review test trước theo cách làm TDD
    Nếu giao cả phần triển khai lẫn test cùng lúc thì sẽ phát sinh lỗi kiểu tự chấm điểm cho chính mình
  • Có người nói rằng “tôi đã bỏ cuộc trong việc viết test bằng Claude”
  • Cũng có người cười và bảo “đây đúng là một cách giải quyết quá con người”