Lập trình với LLM (Mùa hè 2025)
(antirez.com)- Cập nhật trải nghiệm sử dụng LLM của antirez, nhà phát triển Redis
- Các LLM tiên tiến nhất như Gemini 2.5 PRO và Claude Opus 4 giúp khuếch đại năng lực của lập trình viên
- Sử dụng LLM có thể cải thiện hiệu suất công việc theo nhiều cách như loại bỏ lỗi, thử nghiệm ý tưởng, mở rộng kiến thức
- Có thể dễ dàng xử lý các lĩnh vực ngoài chuyên môn hoặc công nghệ mới nhờ sự hỗ trợ của LLM
- Tuy nhiên, để đảm bảo chất lượng tổng thể và khả năng quản lý của mã nguồn, hợp tác 'con người + LLM' là yếu tố then chốt
- Để tận dụng LLM tối ưu, cung cấp đủ ngữ cảnh và khả năng giao tiếp rõ ràng là rất quan trọng
Sự thay đổi trong phát triển phần mềm với LLM và những điểm cốt lõi
Các LLM tiên tiến nhất (Gemini 2.5 PRO, Claude Opus 4, v.v.) với khả năng hiểu biết rất rộng và năng lực xử lý khối lượng mã lớn đang đóng vai trò mở rộng năng lực của lập trình viên
- Nếu có thể mô tả vấn đề rõ ràng và quen với giao tiếp lặp lại
- Có thể loại bỏ lỗi ngay trước khi phát hành (ví dụ: trong trường hợp triển khai Vector Sets của Redis, bug được gỡ bỏ ngay nhờ Gemini/Claude review code)
- Có thể nhanh chóng kiểm tra ý tưởng có hoạt động hay không, đồng thời viết mã thử nghiệm và đánh giá hiệu năng
- Có thể thực hiện pair-design dựa trên kinh nghiệm và trực giác, kết hợp kiến thức chuyên môn phong phú của LLM với trực giác của con người
- Nếu cung cấp chỉ dẫn rõ ràng cho LLM, có thể nhanh chóng hoàn thành một phần việc triển khai mã
- Có thể thích nghi kỹ thuật nhanh chóng ngay cả trong lĩnh vực xa lạ (ví dụ: mã assembly 68000 cho Amiga)
Trong bài viết trước đây ‘LLMs và lập trình vào đầu năm 2024’, tác giả đã nhắc đến tính hữu ích của LLM, nhưng trong 1,5 năm gần đây LLM đã tiến bộ vượt bậc
Để tận dụng LLM tốt nhất, cả con người lẫn LLM đều cần một số năng lực và thói quen nhất định, vì vậy các nguyên tắc liên quan là rất quan trọng
Tiết chế Vibe Coding và nguyên tắc cộng tác người + LLM
Hiện tại, LLM rất xuất sắc với vai trò bộ khuếch đại năng lực lập trình viên, nhưng vẫn chưa đạt tới mức có thể tự mình xử lý toàn bộ công việc một cách tự chủ
- Với các dự án nhỏ, dùng một lần như test hoặc utility quy mô nhỏ, LLM có thể tự thiết kế một mình
- Nhưng nếu dùng riêng LLM cho các dự án lớn, không thông thường, rất dễ phát sinh các vấn đề như độ phức tạp, mã dư thừa, điểm yếu về cấu trúc
- Cộng tác giữa LLM và con người mang lại mức tăng năng suất lớn nhất, nhưng tiền đề là phải có kinh nghiệm giao tiếp hiệu quả và quản lý LLM
- Không nên giao hoàn toàn các tác vụ phức tạp cho LLM; cần chiến lược luôn để con người can thiệp tích cực vào quá trình
Tầm quan trọng của việc cung cấp đủ ngữ cảnh cho LLM
Để LLM hiểu đúng hướng phát triển hoặc sửa lỗi, việc cung cấp thông tin ngữ cảnh rộng và đầy đủ là bắt buộc
- Nên cung cấp bài báo, codebase mục tiêu (càng đầy đủ càng tốt), và ý định công việc
- Bao gồm các thông tin cốt lõi như mục tiêu triển khai, các phương án không cần thiết hoặc yếu, ý tưởng khả thi trọng tâm, mục tiêu, điều kiện bất biến, style code, v.v.
- Ví dụ, khi xử lý một công nghệ mới mà LLM chưa biết (như Redis vector sets), nếu đưa tài liệu README vào ngữ cảnh thì có thể nhận được câu trả lời ở mức chuyên gia ngay lập tức
Cách chọn và sử dụng LLM
LLM nổi tiếng nhất chưa chắc đã tạo ra kết quả tốt nhất trong thực tế
- Trong lập trình, Gemini 2.5 PRO và Claude Opus 4 đặc biệt hiệu quả
- Gemini 2.5 PRO nổi bật ở khả năng phát hiện bug phức tạp và giải quyết vấn đề
- Claude Opus 4 giỏi viết mã mới, đồng thời trải nghiệm người dùng cũng rất tốt
- Luân phiên dùng hai mô hình sẽ giúp tăng mức độ thấu hiểu trong các thiết kế phức tạp
- Nếu chỉ chọn một, tác giả khuyến nghị Gemini 2.5 PRO
- Các điều kiện nên tuân thủ khi dùng LLM
- Tránh dùng code agent hoặc agent tích hợp trong IDE
- Hãy để LLM có thể trực tiếp nhìn thấy toàn bộ ngữ cảnh (mã, tài liệu, v.v.) để dẫn tới câu trả lời tốt nhất
- Khi dùng các tính năng chỉ cho thấy một phần ngữ cảnh như RAG (truy xuất tri thức), hiệu năng sẽ suy giảm
- Ở mỗi bước, con người cần tự copy/paste mã và trực tiếp theo dõi luồng xử lý
Kết luận – Giữ quyền kiểm soát mới là cốt lõi
Ngày mà agent có thể tự viết mã một mình có lẽ không còn xa, nhưng ở thời điểm hiện tại, cách làm hiệu quả nhất vẫn là con người chủ động cộng tác với LLM để tạo ra mã sắc bén nhất
- Vai trò quyết định ‘làm gì, làm như thế nào’ của con người vẫn là cốt lõi
- Tận dụng LLM giúp vượt qua ranh giới kiến thức hiện có để học hỏi và phát triển với công nghệ hay khái niệm mới
- Khi trực tiếp kiểm soát mã, có thể giữ được tính nhất quán trong thiết kế và triển khai, đồng thời giảm thiểu sự bất định do lỗi của LLM gây ra
- Thường xuyên kiểm tra tình hình phát triển hiệu năng của các agent cũng là một chiến lược khôn ngoan
- Ở giai đoạn này, nếu né tránh việc sử dụng LLM thì có thể bị tụt lại trước thay đổi, vì vậy cách tận dụng cân bằng là điều quan trọng
1 bình luận
Ý kiến trên Hacker News
Tôi thấy khá đáng tiếc khi các mô hình LLM đóng như Gemini 2.5 PRO hay Claude Opus 4 đang dần trở thành tiêu chuẩn. Tôi rất tích cực về sự tiến bộ của LLM và sức mạnh của chúng như một công cụ, nhưng thật khó hiểu vì sao các lập trình viên, dù là người nổi tiếng hay vô danh, lại tiếp tục cho rằng việc phụ thuộc vào các dịch vụ trả phí của bên thứ ba để lập trình là điều chấp nhận được. Trước đây vẫn có thể code chỉ bằng mã nguồn mở và công cụ miễn phí. Tôi lo rằng vài năm nữa, việc phụ thuộc vào LLM trả phí sẽ trở nên bất tiện khi thiếu nó chẳng khác gì bây giờ code mà không có IDE hay vim. Kiểu lập luận rằng $200/tháng có đáng gì đâu không giải quyết được vấn đề cốt lõi.
Các mô hình mở hiện có thể chạy cục bộ hiện vẫn thiếu về chất lượng, và quan trọng hơn là chi phí vận hành cao hơn nhiều. Khi nào có thể chạy một mô hình cấp Claude 4 trên máy cá nhân một cách kinh tế thì lúc đó nhiều người sẽ thử. Hiện tại, các mô hình như Kimi K2 có thể chạy trên hai máy Mac Studio 512GB, nhưng riêng tiền phần cứng đã vào khoảng $20,000.
Mô hình thuê bao ban đầu tạo cảm giác giá trị nhận lại trên chi phí bỏ ra cực kỳ tốt. Nhưng rồi giá tăng dần, chất lượng giảm dần, và cuối cùng bạn bị trói vào dịch vụ. Nó giống như tập "Common People" của Black Mirror vậy.
Cá nhân tôi nghĩ một tương lai mà mọi lập trình viên đều bị ràng buộc tuyệt đối vào LLM trả phí là điều khó xảy ra. Về lâu dài, mọi người sẽ nhận ra rằng việc sản xuất quá nhiều mã nguồn tự nó đã là một vấn đề. Code là nợ, và khi mã không ổn định hoặc chậm chạp tích tụ lại thì món nợ đó cũng phình to. AI sẽ không biến mất, nhưng khi cơn sốt nguội đi, hiểu biết về việc nên dùng nó ở đâu và như thế nào sẽ tăng lên. Tôi cũng thắc mắc điều gì sẽ xảy ra khi dòng vốn đầu tư cạn đi. OpenAI và Anthropic không có lợi nhuận, và để duy trì trạng thái hiện tại thì vẫn cần vốn liên tục chảy vào. Nếu mức tiến hóa của LLM hiện nay đã gần như là giới hạn, đầu tư rồi sẽ rút đi, và khi đó hoặc chi phí sử dụng tăng lên, hoặc dịch vụ biến mất hoàn toàn.
Thực tế thì tôi không nghĩ đây là vấn đề quá lớn. Nếu không có lý do thực chất về tăng năng suất, sẽ không có lý do gì để tiếp tục phụ thuộc vào một dịch vụ đắt đỏ và khó chịu. Các mô hình mở cũng đang tiến bộ đều đặn, nên nếu khoảng cách với mô hình mở không lớn thì chẳng cần tiếp tục dùng. Nếu LLM tiếp tục phát triển nhanh không ngừng, thì với cách làm cũ chúng ta cũng không còn cạnh tranh được nữa và phải chuyển sang lĩnh vực khác. Tóm lại tôi nghĩ không cần quá lo. Tôi cũng cảm thấy giá trị của các công ty mô hình lớn đang bị thổi phồng rất mạnh so với thực tế.
Nhân chuyện có thể code bằng mã nguồn mở và công cụ miễn phí, tôi muốn nói thêm rằng JetBrains là công ty còn lâu đời hơn nhiều đồng nghiệp của bạn, còn Visual Basic/C++/Studio của MS đã giúp việc phát triển trên Windows trở nên dễ dàng hơn, nhưng tất cả đều là phần mềm trả phí.
Tôi không đồng ý với cụm từ "PhD-level knowledge". Mục tiêu của chương trình PhD không phải là tiếp thu kiến thức sẵn có, mà cốt lõi là học cách thực hiện nghiên cứu. Đây là một điểm thường bị hiểu sai trong các cuộc thảo luận về AI, khiến cụm "kiến thức cấp tiến sĩ" trở nên mơ hồ về ý nghĩa.
Ngoài chuyện PhD là quá trình học làm nghiên cứu, trọng tâm còn là bạn có biết đặt câu hỏi hay không. LLM giống một "người lao động lười biếng nhưng có nhiều kiến thức" hơn, chứ không tự đặt câu hỏi rồi khám phá giả thuyết. Lấy ví dụ từ trải nghiệm thực tế, khi tôi nhờ Claude Code(Max Pro) comment out số lượng test assertion, nó đã tạo ra lỗi dựa trên một giả định sai từ kế hoạch ban đầu. Chỉ khi tôi bảo nó tự viết lại kế hoạch thì nó mới tìm ra lý do và sửa được. Chẳng hạn, việc đối tượng ORM có giá trị null là do thiếu refresh sau commit, còn dữ liệu được nạp từ một DB session khác thì vẫn bị giữ nguyên sau khi session kết thúc.
Đồng ý. Nó có kiến thức ở mức chuyên gia, nhưng không làm được những gì con người làm giỏi đến mức tương đương. Ví dụ, LLM có thể viết ra một chương trình ấn tượng từ đầu đến cuối trong một lần, nhưng lại khó cải tiến nó một cách lặp đi lặp lại.
Dù hiểu rằng PhD còn hơn cả kiến thức, thì việc có một cách dễ dàng để tiếp cận lượng kiến thức đó vẫn có giá trị rất lớn. Ở công ty cũ của tôi, với những câu hỏi hóc búa mà thường chỉ người có PhD mới trả lời được — nói đại khái như "nếu đặt điện áp theo một hướng nhất định ở ranh giới giữa hai vật liệu thì hiện tượng gì xảy ra?" — thì LLM đôi khi cũng đưa ra câu trả lời khá hữu dụng.
Có bằng PhD không có nghĩa là sau đó bạn quan tâm hơn đến bản thân môn học; rốt cuộc điều quan trọng là bạn đã học được cách làm nghiên cứu.
Tôi nghĩ mọi thảo luận về code với LLM đều phải nêu rõ domain đang xử lý và ngôn ngữ lập trình đang dùng. Hai biến số này ảnh hưởng lớn hơn nhiều so với cách bạn dùng LLM. Nếu ai đó thích hoặc ghét coding với LLM, trước tiên nên hỏi họ đã giải quyết loại vấn đề nào, rồi tự mình thử giải quyết chính loại vấn đề đó bằng AI để hiểu rõ lập trường của nhau. Nếu không, cuối cùng lúc nào cũng chỉ thành những câu chuyện tiêu hao như "là do bạn dùng sai thôi" hoặc "tôi thử rồi nhưng thấy chẳng ra sao".
Dựa trên trải nghiệm làm việc vài tháng gần đây tập trung vào agentic coding, tôi đồng cảm với toàn bộ bài viết. Các LLM tối tân đúng là dễ dùng nhất vào lúc này, nhưng tôi kỳ vọng mô hình mở cũng sẽ sớm đuổi kịp. Bạn có thể nhờ LLM gợi ý phương pháp mới hoặc đề xuất những cách tiếp cận mà bạn vốn đã biết. Đôi khi LLM có xu hướng làm mọi thứ phức tạp hơn, nên chỉ cần phát hiện sớm hoặc yêu cầu nó refactor. Mỗi khi có thêm mô hình mới, tình hình lại thay đổi. Không phải việc nào cũng nhất thiết cần mô hình tối tân. Với các tính năng đơn giản hoặc bug fix nhỏ, Copilot cũng là một điểm khởi đầu khá ổn. Mong là mọi người tận hưởng quá trình thử nghiệm nhiều cách khác nhau và học hỏi trong làn sóng thay đổi mới này.
Tôi đã dùng GitHub action của Claude cho khoảng 10~20 issue, cả triển khai và review PR, và đúng là kiểu hên xui, nên tôi đồng ý rằng nó hợp làm công cụ tăng cường hơn là tự động hóa bừa bãi. Các tính năng nhỏ hoặc refactor nhỏ với thay đổi ít và test đầy đủ thì gần như tự động thành công. Chạy qua action thì tôi có thể làm việc khác trong lúc đó, nên cũng có lợi thế — nếu issue cũng do Claude viết hộ thì còn tiện hơn. Nhưng từ cỡ trung trở lên thì thường ra kết quả trông có vẻ hợp lý nhưng thực tế không chạy được. Có thể đây là trách nhiệm của tôi vì test coverage chưa đủ, nhưng chuyện này xảy ra khá thường xuyên. Dù viết issue chi tiết hơn hay thử nhiều prompt khác nhau thì kết quả vẫn đáng thất vọng. Các tác vụ lớn thì khỏi phải nói là rất khó. Tính năng review PR thì dùng được cho việc nhỏ và vừa, nhưng cũng có nhiều nhận xét vô ích. Tóm lại tôi nghĩ LLM còn lâu mới tự code hoàn toàn được. Cách hiệu quả nhất là chỉ giao các việc nhỏ, để nó viết issue rồi chờ PR được gửi lên. Với phần lớn công việc của tôi, tức các tác vụ cỡ trung, tôi chủ yếu chỉ cần đưa hướng đi cho Claude và gần như không phải tự code nữa, nên năng suất tăng rõ rệt. Tôi cũng đã thử Gemini, nhưng nếu cứ để mặc thì code của nó dao động đến mức khó lường. Ở công ty tôi cũng dùng Copilot để review PR, nhưng không hiệu quả mấy. Có lẽ với codebase lớn thì Gemini sẽ hữu dụng hơn.
Khác với OP, sau một tháng đào sâu mảng này, tôi thấy Gemini 2.5 PRO và Opus 4 cho kết quả tốt hơn trong các thảo luận trừu tượng như kiến trúc. Còn phần triển khai code cụ thể thì giao cho Sonnet lại hiệu quả hơn. 2.5 PRO và Opus thường có kiểu lượn quanh đáp án rồi tự sửa đi sửa lại, trong khi Sonnet đi thẳng đến câu trả lời hơn, dù đổi lại cần chỉ dẫn đủ chi tiết.
Hoàn toàn có thể như vậy. Thực tế Sonnet/Opus 4 có thể mạnh hơn ở những kết quả tốt nhất, nhưng ở một số mặt, tính nhất quán hay alignment của chúng còn kém hơn Sonnet 3.5v2 (cũng có người gọi là 3.6) hoặc thậm chí 3.7. Bản thân mô hình cũng là đối tượng rất phức tạp, nên tùy domain mà một mô hình "trông yếu hơn" lại có thể hoạt động tốt hơn. Ngoài ra, môi trường hội thoại (interactive) và môi trường thiên về agent dùng các kỹ thuật reinforcement learning khác nhau, nên hiệu năng của mô hình cũng thay đổi tùy cách sử dụng.
Dữ liệu thống kê nội bộ thực tế cũng xác nhận rằng Opus và Gemini 2.5 pro cho kết quả kém hơn Sonnet 4 trong môi trường thực tế liên kết thống kê liên quan
Tôi cũng có trải nghiệm tương tự. Tôi dùng Gemini 2.5 Pro trong AI Studio để kiểm chứng hoặc tinh chỉnh các ý tưởng thiết kế lớn, rồi mang yêu cầu sang Claude Code thì thường nó code khá gọn gàng. Gần đây tôi cũng thử Gemini CLI, nhưng khả năng code thua xa Claude Code. Nó có nhiều lỗi cú pháp, không thoát nổi khỏi vòng lặp, và kết quả thì dài dòng đến mức dù nhanh cũng khó theo kịp. Trong khi đó Claude Code debug rất giỏi. Với các bài toán kiểu "bức tranh lớn", DeepSeek R1 cũng đáng thử: rất chậm nhưng tỷ lệ ra đáp án đúng cao.
Đây là một ví dụ thực tế cho thấy AI/LLM đôi khi viết ra mã cực kỳ kém hiệu quả liên kết blog liên quan
Tôi đã có trải nghiệm rằng nếu trước hết yêu cầu LLM chỉ giải thích công việc mình muốn làm, rồi trong quá trình đó tôi góp ý ở giữa và lặp lại vài lần, thì chất lượng code tạo ra sau đó tốt hơn hẳn. Bắt nó xác nhận kế hoạch chi tiết trước khi làm sẽ hiệu quả hơn.
Theo trải nghiệm của tôi, ở frontend thì những công việc lặp đi lặp lại, đơn giản và dễ kiểm chứng có thể giao cho vibe coding, còn bình thường tôi dùng LLM như một đối tác sparring để review code của mình và đánh giá các phương án khác nhau. Ngay cả khi đề xuất của nó vô lý hoặc có lỗi logic, nó vẫn giúp tôi không bỏ sót những điều quá hiển nhiên. Tôi cũng hài lòng vì nó giúp sửa thói quen của mình là cứ muốn thử những cách quá đà cho các vấn đề vốn đã rối rắm.
Tôi không hiểu chính xác OP đang nói đến kiểu làm nào. Chẳng lẽ là bảo người ta thủ công dán file C của redis vào ô chat web của Gemini Pro sao?