- tldr: Động não để ra spec, lập kế hoạch, rồi dùng LLM codegen để triển khai. Vòng lặp lặp lại theo từng bước. Và rồi điều kỳ diệu xảy ra
- Tôi đang dùng LLM để nhanh chóng tạo ra nhiều sản phẩm nhỏ khác nhau. Vừa vui, vừa hữu ích
- Tuy nhiên nếu rơi vào cách tiếp cận sai thì có thể lãng phí rất nhiều thời gian
- Nhiều lập trình viên có cách tiếp cận khá giống nhau, và dưới đây là workflow của tôi
> "Hiện tại nó hoạt động tốt, nhưng sau 2 tuần có thể không còn hoạt động hoặc hoạt động gấp đôi"
- Có 2 cách phát triển
- Greenfield code: bắt đầu một dự án mới
- Legacy modern code: cải thiện hoặc mở rộng codebase hiện có
Greenfield: bắt đầu mới từ đầu
- Đây là quy trình rất hợp với tình huống “bắt đầu từ con số 0”
- Luồng làm việc là động não ý tưởng, tài liệu hóa, lập kế hoạch từng bước nhỏ rồi dùng công cụ sinh mã để hiện thực hóa
- Bước 1: Cụ thể hóa ý tưởng
- Mô tả ý tưởng cho một LLM như ChatGPT, đồng thời dẫn dắt nó đặt câu hỏi từng bước để tinh chỉnh thành một spec cụ thể
- Cuối cùng tạo ra một spec chi tiết (
spec.md) và sắp xếp nó thành dạng tài liệu có thể chuyển cho lập trình viên
- Nếu cần, cũng có thể dùng các công cụ như Deep Research để lấy tài liệu làm căn cứ cho ý tưởng
- Bước 2: Lập kế hoạch
- Dựa trên spec, yêu cầu một model “hiểu biết/suy luận” mạnh hơn tạo ra bản thiết kế chi tiết theo từng bước
- Dù theo kiểu TDD hay không, hãy chia mỗi bước thành các đơn vị công việc nhỏ và sắp xếp theo thứ tự
- Qua quy trình này sẽ tạo ra
prompt_plan.md và todo.md
prompt_plan.md chứa thiết kế prompt cần cho việc sinh mã, còn todo.md chứa checklist
- Việc lập kế hoạch này thường chỉ mất khoảng 15 phút và cũng dễ tham chiếu lại về sau
- Bước 3: Thực thi
- Dùng nhiều công cụ hỗ trợ/tạo mã như Aider, Cursor, Claude để viết mã thực tế
- Ví dụ điển hình là cách dùng Claude và Aider
- Cách dùng Claude
- Thiết lập sẵn cấu trúc dự án (boilerplate, v.v.) rồi nhập các prompt theo từng bước vào Claude
- Sao chép mã kết quả vào IDE và chạy test
- Nếu có vấn đề, dùng công cụ như
repomix để chuyển codebase hiện tại cho Claude nhằm debug
- Workflow
- Thiết lập repo (boilerplate, uv init, cargo init, v.v.)
- Dán prompt vào Claude
- copy & paste từ claude.ai sang IDE
- Chạy code, chạy test, v.v.
- …
- Nếu chạy được, chuyển sang prompt tiếp theo
- Nếu không chạy được, dùng Repomix để gửi codebase cho Claude và debug
- Lặp lại quy trình này (rinse repeat)
- Cách dùng Aider
- Trong Aider cũng làm việc bằng cách đưa
prompt_plan.md vào theo thứ tự
- Nó hỗ trợ tự động chạy test, tìm lỗi và sửa lỗi
- Khi cần, giải quyết vấn đề thông qua debug kiểu hội thoại
- Thiết lập repo (boilerplate, uv init, cargo init, v.v.)
- Chạy Aider
- Dán prompt vào Aider
- Xem Aider nhảy múa ♪┏(・o･)┛♪
- Aider có thể chạy test hoặc chạy app để kiểm chứng
- Nếu chạy được, chuyển sang prompt tiếp theo
- Nếu không chạy được, sửa cùng Aider qua Q&A
- Lặp lại quy trình này (rinse repeat)
- Kết quả
- Với cách này, có thể hiện thực hóa nhiều dự án như script, ứng dụng Expo, Rust CLI trong thời gian ngắn
- Nếu bạn đang trì hoãn một dự án lớn hay nhỏ nào đó, tôi khuyên nên thử một lần
- Ưu điểm là có thể thử rất nhanh trong lúc học một ngôn ngữ hoặc công nghệ mới
Non-greenfield: công việc tăng dần/lặp lại trên code hiện có
- Đây là cách dùng khi áp dụng lặp đi lặp lại các tác vụ nhỏ lên một codebase đã tồn tại
- Thay vì một kế hoạch tổng thể lớn, luồng làm việc là trao đổi các yêu cầu cụ thể và kết quả theo từng đơn vị công việc
- Thu thập ngữ cảnh
- Có thể dùng công cụ như
repomix để tóm tắt codebase và chuyển cho LLM
- Quản lý các thiết lập lặp lại bằng
mise chẳng hạn, và lưu kết quả tóm tắt vào file output.txt
- Với codebase quá lớn, có thể điều chỉnh để chỉ tóm tắt những phần cần thiết
- Ví dụ workflow
- Dùng lệnh như
mise run LLM:generate_missing_tests để LLM xác định các phần còn thiếu test
- Áp dụng các đề xuất đó (issue) bằng Claude hoặc Aider, rồi test lại kết quả
- Theo cách này có thể cải thiện codebase hiện có một cách dần dần
Các ví dụ prompt chính
- Code review
“Hãy review code thật kỹ như một senior developer. Bao gồm số dòng và ngữ cảnh. Đừng review hời hợt, hãy xem xét thật sâu”
“You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
- Tạo GitHub Issue
“Hãy xem xét code như một senior developer và viết ra các issue chính dưới dạng GitHub issue”
“You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
- Missing tests
“Hãy review code như một senior developer và nêu cụ thể những test còn thiếu hoặc những test cần có“
“You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
Trượt tuyết ᨒ↟ 𖠰ᨒ↟ 𖠰
- Khi dùng LLM để viết code với tốc độ cao, đến một lúc nào đó độ phức tạp hoặc ngữ cảnh sẽ rối tung lên và trở nên khó hiểu
- Sẽ hữu ích nếu xem lại tài liệu ở giai đoạn lập kế hoạch (ví dụ quy trình Greenfield) hoặc viết test một cách có hệ thống
- Càng di chuyển nhanh thì càng quan trọng phải có lúc nghỉ một chút hoặc sắp xếp lại suy nghĩ
Tôi rất cô đơn (｡•́︿•̀｡)
- Hầu hết workflow dựa trên LLM hiện đều được tối ưu cho “chế độ một người”
- Khi cố gắng code cùng cả nhóm, các vấn đề như xung đột hay merge trở nên phức tạp
- Tôi hy vọng một môi trường cộng tác kiểu “multiplayer” cho phép nhiều người cùng dùng LLM đồng thời sẽ phát triển hơn
Thời gian
- Hiệu suất viết code đã tăng mạnh nhờ LLM, nhưng vẫn có “downtime” do phải chờ xử lý token
- Tôi tận dụng thời gian đó để nghĩ ý tưởng dự án khác, nghe nhạc hoặc trò chuyện
- Tôi đang trải nghiệm mức tăng năng suất cá nhân lớn hơn rất nhiều so với trước đây
Haterade ╭∩╮( •̀_•́ )╭∩╮
- Nhiều bạn bè của tôi có thái độ kiểu “LLM chết tiệt, thứ này hoàn toàn vô dụng”, còn tôi thì không quá bận tâm đến góc nhìn đó
- Tất nhiên tôi cũng không hoàn toàn chia sẻ lập trường ấy, nhưng đúng là vẫn cần một ánh nhìn hoài nghi
- Có vô số lý do để ghét AI, và điều tôi lo nhất là mức tiêu thụ điện năng cùng tác động môi trường
- Nhưng mà… "code phải chảy" đúng không… haizz
- Nếu muốn tìm hiểu thêm nhưng không nhất thiết muốn trở thành một cyborg programmer, lời khuyên của tôi là “đừng vội đổi ý kiến, hãy đọc ‘Co-Intelligence: Living and Working with AI’ của Ethan Mollick”
- Cuốn sách này diễn giải khá tốt những lợi ích mà LLM mang lại mà không cường điệu theo kiểu chủ nghĩa tư bản vô chính phủ công nghệ
- Cá nhân tôi đã nhận được rất nhiều ích lợi từ nó, và cũng có thể trò chuyện sâu sắc hơn nhiều với những người bạn đã đọc cuốn sách này
- Rất đáng đọc
6 bình luận
Cuốn Co-Intelligence: Living and Working with AI của Ethan Mollick
có vẻ sẽ được xuất bản vào tháng 3 với tựa đề Dual Brain.
Thì ra có Repomix. Mỗi lần tôi toàn phải copy-paste.. hu hu
Cảm ơn!
Liệu LLM có thể thay mình hứng cả những lời chửi mà các lập trình viên khác dành cho mình không?
Tôi vẫn đang dùng LLM như một Google nâng cao, một Stack Overflow thân thiện hơn; có lẽ nên thử nghĩ xem liệu còn cách nào tận dụng nó tốt hơn không. Tất nhiên chuyện tôi tạo ra như thế nào cũng quan trọng, nhưng có vẻ việc cùng AI suy nghĩ về vì sao nó hoạt động cũng quan trọng không kém. Khi tìm các tài liệu kỹ thuật cũ hay tiêu chuẩn trước đây, LLM rất hữu ích.
Ý kiến Hacker News
LLM là công cụ có thể nhanh chóng tạo ra nguyên mẫu cho các dự án mới. Tuy nhiên, khi áp dụng thay đổi vào mã hiện có hoặc các dự án đã trưởng thành, chúng thường thiếu ngữ cảnh, làm tăng độ phức tạp hoặc thêm các framework không cần thiết. LLM không phải là sự thay thế cho việc hiểu mã.
Khi cộng tác với LLM, việc xây dựng ngữ cảnh thông qua câu hỏi là rất quan trọng. Cách này hiệu quả hơn so với việc tự tạo ngữ cảnh một cách trực tiếp.
Gần đây, tôi đang thử mob programming cùng với LLM. Một LLM đảm nhiệm phần triển khai, còn một LLM khác đưa ra phê bình và đề xuất cải tiến.
Nên tránh thêm các framework mang tính áp đặt cao vào dự án. Vì điều đó làm tăng kích thước ngữ cảnh mà mô hình phải nhận biết. Ví dụ, thay vì dùng Plasmo, tôi giao cho LLM việc thiết lập tiện ích mở rộng trình duyệt.
Tôi muốn nghe trải nghiệm của những người đã bắt đầu với Cursor chat rồi phát triển sang quy trình làm việc tốt hơn. Tôi tò mò liệu thời gian đầu tư vào việc lập kế hoạch có hữu ích không, có giảm ảo giác không, và nhìn chung có tiết kiệm thời gian hay không.
Bài viết này giải thích cách sử dụng LLM đúng cách. Nhiều người vẫn chưa luyện tập đủ để giao tiếp hiệu quả với mô hình ngôn ngữ. Tác giả đã thành thạo việc giao tiếp với LLM, và quy trình này tối đa hóa hiệu suất.
Để tối đa hóa hiệu suất trong quy trình làm việc dùng LLM, cần có tốc độ gõ nhanh, khả năng phán đoán đúng đắn, và sự quen thuộc với điểm mạnh cũng như điểm yếu của từng mô hình.
Các công cụ lập trình dùng LLM thì thú vị, nhưng để xác nhận chúng thực sự hữu ích, cần đặt ra mục tiêu cụ thể và thời hạn rõ ràng. LLM có khả năng thất bại cao trong những điều kiện đó.
Nhiều lập trình viên mới quên mất phần đặc tả và lập kế hoạch thực thi trong lập trình. Để dùng LLM thành công, cần buộc nó tạo ra đặc tả và kế hoạch thực thi.
Tôi không hiểu kỳ vọng dành cho Claude. Khi hỏi về Apache Spark, nó tạo ra rất nhiều ảo giác. Tôi muốn hiểu vì sao Claude lại được cho là tốt hơn các mô hình khác.
Với nhà phát triển cá nhân thì có thể ổn, nhưng trong nhóm, nhiều instance LLM cùng phân tích một codebase thì không kinh tế và có thể rủi ro. Tôi tò mò liệu có sản phẩm nào cung cấp ngữ cảnh tập trung cho cả nhóm hay không.