Vibe coding cho người mới: bắt đầu thế nào và cần kiểm soát gì?

Vibe coding cho người mới nên bắt đầu bằng một bài toán nhỏ, mô tả rõ kết quả mong muốn, để AI tạo code rồi trực tiếp chạy, kiểm thử và sửa từng điểm chưa đạt. Quy trình hiệu quả không phải “prompt một lần rồi dùng”, mà là vòng lặp có kiểm soát: prompt → tạo → chạy → kiểm thử → sửa.

Cách tiếp cận này tương đồng với tutorial chính thức của GitHub: người dùng có thể cộng tác với Copilot qua prompt để nghiên cứu yêu cầu, lập kế hoạch, xây dựng ứng dụng, kiểm thử rồi tiếp tục lặp lại các thay đổi. GitHub giới thiệu workflow này cho người đang học, người không chuyên lập trình và những trường hợp cần tạo proof of concept hoặc ứng dụng cá nhân. 

Điểm cần nhớ là AI có thể viết rất nhiều code, nhưng người sử dụng vẫn phải đánh giá kết quả. GitHub khuyến nghị luôn hiểu, review và kiểm tra code do Copilot đề xuất bằng test cùng các công cụ kiểm tra phù hợp. 

Vibe coding là gì?

Có thể hiểu vibe coding là cách phát triển phần mềm trong đó người dùng chủ yếu diễn đạt mục tiêu và yêu cầu bằng ngôn ngữ tự nhiên, còn AI đảm nhận phần lớn công việc tạo hoặc chỉnh sửa code.

Trong tutorial “Vibe coding with GitHub Copilot”, GitHub minh họa một workflow mà người dùng tương tác với Copilot qua giao diện chat và có thể để AI thực hiện phần coding. GitHub cho rằng cách làm này phù hợp với proof of concept, bản nháp ứng dụng cần tiếp tục phát triển hoặc ứng dụng dùng cho nhu cầu cá nhân. 

Vì thế, vibe coding không nhất thiết có nghĩa là người dùng phải viết từng dòng code thủ công.

Nhưng nó cũng không đồng nghĩa với việc bỏ qua hoàn toàn quá trình kiểm soát phần mềm.

Một workflow kiểu:

“Tạo ứng dụng này cho tôi” → AI sinh code → xong

có một vấn đề lớn: bạn chưa biết sản phẩm có thực sự đúng yêu cầu hay không.

Cách phù hợp hơn cho người mới là:

Ý tưởng → yêu cầu rõ → AI triển khai → chạy thật → kiểm tra → phản hồi → AI sửa → kiểm tra lại.

Đây chính là vòng lặp quan trọng xuyên suốt quá trình học vibe coding.

Người mới có thể học vibe coding không?

Có.

GitHub xác định người đang học phát triển phần mềm là một trong những nhóm phù hợp với tutorial vibe coding của họ. Tài liệu cũng đề cập đến người không làm trong đội kỹ thuật nhưng muốn nhanh chóng tạo proof of concept và cá nhân muốn xây một ứng dụng phục vụ công việc hoặc cuộc sống. 

Vibe coding giúp giảm một rào cản ban đầu: người học có thể biến một ý tưởng thành sản phẩm chạy được trước khi thành thạo toàn bộ cú pháp.

Tuy nhiên, có ba cấp độ rất khác nhau:

1. AI tạo ra code.
2. Code chạy được.
3. Code hoạt động đúng, đủ an toàn và có thể duy trì.

Người mới rất dễ dừng ở cấp độ thứ hai.

Một nút bấm hoạt động trong tình huống bạn vừa thử chưa chứng minh chức năng sẽ đúng với dữ liệu trống, dữ liệu sai, thao tác lặp lại hoặc những trường hợp biên.

GitHub cũng nhấn mạnh rằng Copilot có thể mắc lỗi và khuyến nghị người dùng phải review code, hiểu phần được đề xuất và sử dụng automated tests hoặc các công cụ kiểm tra để xác thực kết quả. 

Vì vậy, học vibe coding không chỉ là học cách đặt prompt.

Bạn đang học cách giao nhiệm vụ cho AI và cách kiểm chứng việc AI vừa làm.

Quy trình vibe coding cho người mới: prompt → tạo → chạy → kiểm thử → sửa

Thay vì tìm một “prompt thần thánh”, hãy hình dung vibe coding như một vòng lặp năm bước.

Bước 1: Prompt — nói rõ vấn đề trước khi yêu cầu AI viết code

Prompt tốt không nhất thiết dài.

Nó cần đủ rõ để AI hiểu:

• Bạn muốn tạo thứ gì?
• Ai sử dụng?
• Người dùng làm được những gì?
• Input là gì?
• Output mong muốn là gì?
• Có ràng buộc nào?
• Làm sao biết nhiệm vụ đã hoàn thành?

GitHub khuyến nghị khi prompt cho Copilot nên bắt đầu bằng mô tả tổng quát về mục tiêu hoặc tình huống rồi bổ sung các yêu cầu cụ thể. Với nhiệm vụ phức tạp, tài liệu khuyến nghị chia thành nhiều tác vụ nhỏ hơn. 

Ví dụ, prompt:

Tạo cho tôi app quản lý công việc.

để lại quá nhiều điều cho AI tự suy đoán.

Bạn có thể cụ thể hơn:

Tôi muốn một ứng dụng web quản lý công việc cá nhân. Phiên bản đầu chỉ cần thêm công việc, đánh dấu hoàn thành và xóa. Chưa cần tài khoản hay database online. Trước tiên hãy đề xuất cấu trúc tối thiểu và tiêu chí kiểm thử, chưa viết code.

Prompt này làm rõ cả scope lẫn điểm dừng.

Một công thức prompt đơn giản cho người mới

Bạn có thể sử dụng:

Mục tiêu + bối cảnh + chức năng + ràng buộc + tiêu chí hoàn thành

Ví dụ:

Tạo một form đăng ký nhận bản tin cho website cá nhân. Có trường email và nút gửi. Email phải được kiểm tra định dạng, không chấp nhận trường rỗng. Trước khi viết code, hãy liệt kê các trường hợp cần kiểm thử.

GitHub cũng khuyến nghị cung cấp ví dụ input, output hoặc cách triển khai mong muốn khi điều đó giúp giảm sự mơ hồ.

Bước 2: Tạo — để AI làm một phần nhỏ trước

Sai lầm phổ biến của người mới là yêu cầu:

Làm cho tôi website có đăng nhập Google, database, chatbot AI, thanh toán, dashboard, phân quyền admin và triển khai production.

Vấn đề không phải AI không thể tạo nhiều code.

Vấn đề là bạn sẽ rất khó kiểm soát code đó.

Nếu có lỗi, bạn không biết nó xuất phát từ:

• Giao diện.
• API.
• Database.
• Authentication.
• Dependency.
• Logic nghiệp vụ.
• Cấu hình môi trường.

GitHub khuyến nghị chia một nhiệm vụ lớn thành nhiều tác vụ nhỏ và thực hiện lần lượt thay vì giao toàn bộ bài toán phức tạp trong một yêu cầu.

Với ứng dụng to-do, một trình tự đơn giản hơn có thể là:

1. Tạo giao diện danh sách công việc.
2. Chạy thử.
3. Thêm chức năng tạo công việc.
4. Kiểm thử.
5. Thêm đánh dấu hoàn thành.
6. Kiểm thử.
7. Thêm chức năng xóa.
8. Kiểm thử lại toàn bộ.

Mỗi vòng chỉ thêm một lượng thay đổi đủ nhỏ để bạn hiểu.

Vì sao nên yêu cầu AI lập kế hoạch trước?

Các coding agent hiện đại không chỉ tạo code. Ví dụ, GitHub Copilot cloud agent có thể nghiên cứu repository, tạo implementation plan, thay đổi code trên branch và cho phép developer review diff, tiếp tục phản hồi rồi mới tạo pull request. 

Điều này gợi ý một thói quen hữu ích ngay cả với người mới:

Đừng luôn bắt đầu bằng “hãy code”. Có lúc nên bắt đầu bằng “hãy phân tích và lập kế hoạch”.

Bạn có thể prompt:

Hãy xem yêu cầu này và đề xuất các bước triển khai. Chưa sửa code.

Sau khi hiểu kế hoạch, bạn mới cho AI thực hiện bước đầu tiên.

Bước 3: Chạy — code AI tạo phải được thực thi

Màn hình chat không phải môi trường kiểm thử.

Nếu AI trả lời:

Tôi đã hoàn thành chức năng.

đó mới chỉ là một tuyên bố.

Bạn cần chạy chương trình.

Tùy dự án, bước này có thể gồm:

• Khởi động ứng dụng.
• Mở website trên trình duyệt.
• Chạy script.
• Build project.
• Chạy lint.
• Kiểm tra console hoặc terminal.
• Thực hiện trực tiếp tính năng vừa thêm.

Coding agent có thể tự thực hiện một phần công việc này. GitHub cho biết Copilot cloud agent hoạt động trong môi trường phát triển tạm thời dựa trên GitHub Actions, nơi agent có thể khám phá code, thay đổi file, chạy automated tests và linters. 

Nhưng dù máy hay người chạy test, tiêu chuẩn vẫn là:

Kết quả thực tế có đúng yêu cầu ban đầu hay không?

Bước 4: Kiểm thử — đừng chỉ thử trường hợp dễ nhất

Giả sử bạn yêu cầu một form:

Tuổi phải nằm trong khoảng từ 1 đến 120.

Nếu chỉ nhập 25 và form hoạt động, bạn chưa kiểm thử đủ.

Hãy thử:

• Để trống.
• Nhập 0.
• Nhập -1.
• Nhập 120.
• Nhập 121.
• Nhập chữ.
• Nhập số thập phân nếu hệ thống chỉ chấp nhận số nguyên.

Đây là sự khác nhau giữa:

“Có vẻ chạy được”

và:

“Tôi đã kiểm tra hành vi của chức năng”.

GitHub hướng dẫn rằng khi dùng Copilot tạo test, prompt nên xác định rõ các scenario cần bao phủ, bao gồm edge case, exception handling và data validation. GitHub cũng cảnh báo test được AI tạo có thể chưa bao phủ mọi trường hợp nên người dùng vẫn cần review và bổ sung. 

Người mới chưa biết viết automated test thì sao?

Bạn có thể bắt đầu bằng test thủ công.

Ví dụ với app to-do:

Sau đó đưa bảng này cho AI:

Dựa trên các trường hợp trên, hãy đề xuất automated tests phù hợp với project hiện tại. Trước tiên chỉ giải thích test plan.

GitHub cũng chỉ ra rằng unit test có thể được dùng như ví dụ mô tả hành vi mong muốn: tạo test trước rồi yêu cầu Copilot viết chức năng đáp ứng các test đó. 

Bước 5: Sửa — biến lỗi thành context cho prompt tiếp theo

Khi ứng dụng lỗi, prompt:

Không chạy. Sửa đi.

cung cấp rất ít thông tin.

Một prompt debug tốt hơn nên chứa:

• Bạn vừa làm gì?
• Bạn mong chờ điều gì?
• Điều gì thực sự xảy ra?
• Error message là gì?
• File hoặc chức năng nào có liên quan?
• Phần nào vẫn đang hoạt động?

Ví dụ:

Khi ô input chỉ chứa khoảng trắng rồi tôi bấm “Thêm”, ứng dụng vẫn tạo một công việc trống. Tôi muốn chuỗi được trim trước khi validation. Hãy xác định nguyên nhân và sửa với thay đổi tối thiểu. Sau đó thêm test cho trường hợp này.

GitHub khuyến nghị tránh prompt mơ hồ, chỉ rõ phần code liên quan và tiếp tục thử nghiệm, iterate nếu phản hồi đầu tiên chưa đạt yêu cầu.

Sau khi AI sửa, đừng kết thúc vòng lặp.

Hãy:

chạy lại → test lại → kiểm tra chức năng cũ → rồi mới sang thay đổi tiếp theo.

Coding agent thay đổi vibe coding như thế nào?

AI coding assistant ban đầu thường giúp trả lời câu hỏi hoặc tạo đoạn code trong IDE.

Coding agent có thể thực hiện nhiều bước hơn trong workflow.

Theo tài liệu GitHub hiện tại, Copilot cloud agent có thể nghiên cứu repository, lập implementation plan, sửa bug, triển khai tính năng tăng dần, cải thiện test coverage, cập nhật tài liệu và thực hiện thay đổi trên branch. Developer có thể review diff và tiếp tục yêu cầu chỉnh sửa. 

Điều này có nghĩa người sử dụng AI ngày càng ít phải tự gõ từng dòng code.

Nhưng một phần trách nhiệm khác trở nên quan trọng hơn:

giao đúng việc và kiểm tra đúng kết quả.

Coding agent làm được nhiều bước hơn không có nghĩa bạn nên trao cho nó một yêu cầu mơ hồ lớn hơn.

Ngược lại, nếu agent có khả năng sửa hàng chục file, khả năng kiểm soát scope, test và review càng quan trọng.

Người mới cần kiểm soát những gì khi vibe coding?

Có năm lớp kiểm soát nên hình thành từ sớm.

1. Kiểm soát yêu cầu

Trước khi AI làm việc, bạn phải biết ít nhất:

“Thành công trông như thế nào?”

Ví dụ, với chức năng đăng nhập:

Chưa đủ:

Thêm login.

Rõ hơn:

Người dùng đăng nhập bằng email và mật khẩu. Nếu thông tin sai, hiển thị lỗi nhưng không tiết lộ email hay mật khẩu nào sai. Sau khi đăng nhập thành công, chuyển về trang dashboard.

AI càng ít phải đoán, bạn càng dễ đánh giá kết quả.

GitHub cũng khuyến nghị prompt cụ thể về yêu cầu và chia nhỏ nhiệm vụ phức tạp. 

2. Kiểm soát phạm vi thay đổi

Bạn yêu cầu sửa nút “Save”.

AI sửa:

• Component.
• Database schema.
• Authentication.
• Ba package.
• Cấu hình build.

Đó là tín hiệu nên kiểm tra.

Nếu dùng Git, hãy xem diff.

Nếu dùng coding agent, hãy yêu cầu:

Giải thích các file đã thay đổi và lý do từng file cần thay đổi.

GitHub thiết kế workflow cloud agent để developer có thể xem các thay đổi trên branch, review diff và iterate trước khi tạo hoặc hoàn tất pull request. 

Một nguyên tắc hữu ích:

Thay đổi càng nhỏ thì càng dễ hiểu, test và rollback.

3. Kiểm soát dependency

AI có thể đề xuất package chỉ với một dòng lệnh.

Trước khi thêm, hỏi:

• Package này giải quyết vấn đề gì?
• Có cần thiết không?
• Project hiện tại đã có dependency tương tự chưa?
• Có thể giải quyết mà không thêm package không?
• Việc thêm dependency có yêu cầu thay đổi cấu hình nào?

Bạn không cần trở thành chuyên gia package management ngay lập tức.

Nhưng nên biết vì sao một dependency xuất hiện trong dự án của mình.

4. Kiểm soát test

Một test xanh không có ý nghĩa nếu test kiểm tra sai thứ.

Trước khi yêu cầu AI viết test, hãy thử hỏi:

Với yêu cầu này, hãy liệt kê happy path, edge case và failure case cần kiểm tra. Chưa viết test.

Sau đó xem checklist đã đủ chưa.

GitHub khuyến nghị review test do Copilot tạo và bổ sung các scenario còn thiếu thay vì giả định bộ test AI tạo ra đã đầy đủ. 

5. Kiểm soát phần code bạn không hiểu

Nếu AI tạo một đoạn code quan trọng mà bạn không hiểu, đừng chỉ bỏ qua vì nó đang chạy.

Hãy hỏi:

Giải thích đoạn code này cho người mới theo 4 phần: input, logic, output và failure case.

Hoặc:

Nếu xóa hàm này thì điều gì sẽ hỏng?

GitHub khuyến nghị người dùng hiểu suggested code trước khi triển khai và có thể dùng Copilot Chat để yêu cầu giải thích những phần chưa hiểu. 

Không nhất thiết phải hiểu ngay mọi syntax.

Nhưng bạn nên hiểu vai trò của code.

Ví dụ vibe coding cho người mới: tạo ứng dụng to-do

Một ứng dụng danh sách việc cần làm là bài tập phù hợp để luyện toàn bộ vòng lặp mà không tạo quá nhiều độ phức tạp.

Vòng 1: Định nghĩa sản phẩm tối thiểu

Yêu cầu:

• Thêm công việc.
• Đánh dấu hoàn thành.
• Xóa công việc.

Chưa cần:

• Đăng nhập.
• Cloud database.
• Social login.
• AI chatbot.
• Phân quyền.

Prompt:

Tôi muốn tạo một web app to-do tối thiểu với 3 chức năng: thêm, đánh dấu hoàn thành và xóa công việc. Hãy đề xuất cấu trúc đơn giản nhất và checklist nghiệm thu. Chưa viết code.

Vòng 2: Tạo chức năng đầu tiên

Prompt:

Triển khai giao diện và chức năng thêm công việc. Chưa làm đánh dấu hoàn thành hoặc xóa.

Chạy ứng dụng.

Thử:

• Một công việc bình thường.
• Chuỗi rỗng.
• Chỉ có khoảng trắng.
• Chuỗi dài.

Vòng 3: Sửa lỗi

Giả sử phát hiện item rỗng vẫn được tạo.

Prompt:

Khi input trống hoặc chỉ chứa khoảng trắng, ứng dụng vẫn thêm item. Hãy sửa validation cho riêng trường hợp này và không thay đổi chức năng khác.

Chạy test lại.

Vòng 4: Thêm chức năng tiếp theo

Chỉ sau khi chức năng thêm item ổn định mới chuyển sang:

Thêm khả năng đánh dấu một công việc là hoàn thành. Giữ nguyên hành vi hiện tại của phần tạo công việc.

Quy trình này có vẻ chậm hơn việc yêu cầu AI làm toàn bộ app cùng lúc.

Nhưng với người mới, nó giúp bạn biết:

• Điều gì vừa thay đổi.
• Lỗi xuất hiện ở vòng nào.
• Prompt nào tạo ra kết quả.
• Cách một chức năng kết nối với phần còn lại.

Đó là kỹ năng quan trọng khi học vibe coding.

6 lỗi thường gặp khi người mới vibe coding

Lỗi 1: Cố viết một prompt duy nhất cho cả ứng dụng

Prompt càng lớn, phạm vi sai càng lớn.

Chia nhỏ task giúp bạn dễ đánh giá và cũng phù hợp với hướng dẫn prompting chính thức của GitHub. 

Lỗi 2: AI nói “xong” thì coi là xong

Completion message không phải test result.

Luôn chạy ứng dụng và kiểm tra hành vi.

Lỗi 3: Chỉ thử happy path

Nếu form hoạt động khi input hoàn hảo, điều đó chưa nói lên cách nó xử lý input sai.

Hãy nghĩ đến:

• Empty.
• Null.
• Duplicate.
• Boundary.
• Error.
• Retry.

Lỗi 4: Mỗi lần sửa lại thay đổi quá nhiều

Một bug nhỏ nhưng AI refactor cả project sẽ làm tăng số biến số cần kiểm tra.

Yêu cầu:

Sửa với phạm vi tối thiểu và liệt kê các file cần thay đổi trước khi thực hiện.

Lỗi 5: Không đọc diff

Với dự án có Git, diff là nơi bạn thấy chính xác AI thêm, xóa và sửa những gì.

Workflow coding agent của GitHub cũng duy trì thay đổi trên branch để developer có thể xem xét và iterate. 

Lỗi 6: Không lưu phiên bản đang chạy tốt

Nếu AI sửa sai, bạn cần biết trạng thái tốt gần nhất nằm ở đâu.

Hãy học sớm một số thao tác Git cơ bản:

• status
• diff
• add
• commit
• xem lịch sử commit

Không cần học mọi lệnh Git trước khi vibe coding.

Chỉ cần đủ để không mất điểm quay lại.

Nên học gì song song với vibe coding?

Đọc cấu trúc project

Hãy biết:

• Source code nằm ở đâu.
• File entry point là gì.
• Dependency được khai báo ở đâu.
• Test nằm ở đâu.
• Config nằm ở đâu.

Bạn càng hiểu project, prompt càng có context tốt.

Đọc error message

Khi có lỗi, trước khi gửi toàn bộ màn hình cho AI, hãy tập tìm:

• Tên lỗi.
• File.
• Dòng.
• Function.
• Thao tác ngay trước khi lỗi xuất hiện.

Đó là nền tảng của debug.

Input, logic, output

Với bất kỳ function nào, hãy hỏi:

Input là gì → xử lý thế nào → output là gì?

Chỉ ba câu hỏi này đã giúp người mới đọc được nhiều đoạn code hơn.

Git và diff

AI làm code thay đổi nhanh.

Git giúp bạn biết code thay đổi như thế nào.

Tư duy kiểm thử

Trước khi chạy một chức năng mới, hãy thử tự trả lời:

Những cách nào có thể khiến chức năng này sai?

Sau đó mới hỏi AI bổ sung.

Như vậy, AI trở thành công cụ mở rộng tư duy kiểm thử chứ không thay thế tư duy đó.

Có nên để coding agent làm toàn bộ task?

Không có một câu trả lời áp dụng cho mọi task.

GitHub mô tả Copilot cloud agent phù hợp với nhiều nhiệm vụ như sửa bug, triển khai incremental features, tăng test coverage và cập nhật documentation. Agent cũng có thể nghiên cứu repository và lập kế hoạch trước khi viết code.

Với người mới, một quy tắc thực dụng là:

Scope càng nhỏ và tiêu chí nghiệm thu càng rõ, task càng dễ giao cho AI.

Ví dụ dễ kiểm soát:

Thêm validation cho trường email và test các trường hợp invalid.

Khó kiểm soát hơn:

Viết lại toàn bộ hệ thống authentication sao cho tốt hơn.

Ở task thứ hai, “tốt hơn” chưa được định nghĩa.

Bạn chưa xác định:

• Tốt hơn về bảo mật?
• UX?
• Tốc độ?
• Maintainability?
• Chi phí?
• Khả năng mở rộng?

Vibe coding hiệu quả phụ thuộc không chỉ vào khả năng của agent mà còn vào độ rõ của yêu cầu.

Vibe coding có thay thế việc học lập trình không?

Vibe coding có thể thay đổi cách người mới tiếp cận lập trình, nhưng không loại bỏ nhu cầu hiểu vấn đề và kiểm chứng sản phẩm.

GitHub cho phép người học tạo ứng dụng thông qua Copilot mà không nhất thiết tự viết từng dòng code trong tutorial vibe coding. Tuy nhiên, chính tài liệu best practices của GitHub vẫn yêu cầu người dùng kiểm tra suggested code, cân nhắc functionality, security, readability, maintainability và dùng tests hoặc tooling để xác thực kết quả. 

Vì vậy, thay vì đặt mục tiêu:

“Tôi sẽ học cách để không cần hiểu code.”

một mục tiêu hữu ích hơn là:

“Tôi sẽ dùng AI để tạo nhanh hơn, đồng thời học cách mô tả yêu cầu, kiểm tra kết quả, debug và hiểu dần hệ thống.”

Vibe coding có thể giúp bạn bước vào quá trình xây sản phẩm sớm hơn.

Sau đó, chính những lỗi và câu hỏi xuất hiện trong quá trình này có thể trở thành lộ trình học:

• Tại sao state không cập nhật?
• API là gì?
• Vì sao cần validation?
• Test này kiểm tra gì?
• Dependency này dùng để làm gì?
• Tại sao cần commit?
• Vì sao code chạy local nhưng lỗi khi deploy?

Thay vì học tất cả lý thuyết trước khi làm sản phẩm, người mới có thể học nhiều khái niệm đúng vào lúc chúng trở nên cần thiết.

Checklist vibe coding cho người mới

Trước khi chấp nhận một task AI vừa hoàn thành, hãy tự kiểm tra:

1. Tôi có mô tả rõ kết quả mong muốn không?
2. Task có đủ nhỏ để kiểm soát không?
3. Tôi đã chạy code thật chưa?
4. Tôi đã thử ít nhất một trường hợp lỗi chưa?
5. Automated tests hiện có còn chạy không?
6. AI đã thay đổi những file nào?
7. Có dependency mới không?
8. Tôi hiểu vai trò của phần code quan trọng vừa được thêm không?
9. Có chức năng cũ nào bị hỏng sau thay đổi không?
10. Tôi có điểm commit ổn định để quay lại không?

Nếu chưa trả lời được các câu hỏi trên, workflow vẫn chưa kết thúc chỉ vì agent thông báo đã hoàn thành.

Kết luận

Vibe coding cho người mới hiệu quả nhất khi được coi là vòng lặp kiểm soát chất lượng, không phải kỹ thuật nhập prompt một lần: prompt → tạo → chạy → kiểm thử → sửa → lặp lại.

Coding agent hiện nay có thể đảm nhận nhiều bước hơn, từ nghiên cứu repository, lập kế hoạch đến sửa code và chạy test, nhưng người dùng vẫn cần xác định yêu cầu và đánh giá kết quả.

Vì vậy, hãy bắt đầu bằng một ứng dụng nhỏ. Yêu cầu AI làm từng phần, chạy sản phẩm sau mỗi thay đổi, test cả trường hợp đúng và sai, xem phần code đã thay đổi rồi mới tiếp tục.

Nếu muốn tìm hiểu thêm về hướng tiếp cận lập trình cùng AI, bạn có thể tham khảo thông tin Vibe Coding của FUNiX.