Thế giới công nghệ luôn sôi động với những video mới hàng tuần về “AI dành cho lập trình viên”. Tuy nhiên, khi đối mặt với các dự án thực tế, câu hỏi trở nên đơn giản hơn: Làm thế nào để sử dụng những công cụ này mà không làm chậm quy trình làm việc hay vô tình đẩy mã lỗi lên môi trường sản phẩm? Trong suốt một năm qua, với kinh nghiệm làm việc trên các dự án frontend lớn dùng Next.js và backend bằng Python FastAPI, tôi đã đúc kết được một số quy tắc và mô hình hoạt động hiệu quả.
Đây chính là cuốn cẩm nang mà tôi ước mình đã có khi bắt đầu tích hợp Zed cùng Claude và Gemini vào quy trình làm việc hàng ngày. Nó không chỉ giúp tăng năng suất mà còn đảm bảo chất lượng và tính ổn định của sản phẩm.
Mục lục
1. Luôn Dùng Hai Công Cụ AI, Không Phải Một
Điều đầu tiên giúp thay đổi đáng kể năng suất làm việc của tôi là coi các công cụ AI như một phần của cơ sở hạ tầng: không bao giờ có một điểm lỗi duy nhất. Trong thực tế, điều này có nghĩa là tôi sử dụng kết hợp:
- Trình soạn thảo Zed: Dành cho việc viết mã trực tiếp, tái cấu trúc (refactor) và xử lý ngữ cảnh cục bộ.
- Claude hoặc Gemini: Đóng vai trò lớp agent/chat cho việc lập kế hoạch, thay đổi nhiều tệp và thảo luận kiến trúc.
Tại sao điều này quan trọng đối với công việc thực tế?
- Hạn chế tốc độ và sự cố: Các giới hạn về số lượng yêu cầu (rate limits) và sự cố dịch vụ luôn xảy ra, thường là vào những thời điểm tồi tệ nhất. Với hai công cụ, bạn chỉ cần chuyển đổi ngữ cảnh và tiếp tục công việc mà không bị gián đoạn.
- Mỗi công cụ có thế mạnh riêng: Zed nổi bật như một môi trường chỉnh sửa nhanh chóng, trong khi Claude và Gemini tốt hơn trong việc suy luận trên toàn bộ kho mã nguồn (repo-wide reasoning) và các quy trình làm việc mang tính tác nhân (agentic workflows).
Nếu toàn bộ quy trình làm việc của bạn phụ thuộc vào một sản phẩm AI duy nhất, bạn chỉ cách một ngày tồi tệ là sẽ không thể hoàn thành được gì. Đây là một chiến lược quan trọng để đảm bảo tính liên tục và linh hoạt trong phát triển phần mềm.
2. Đừng Dùng AI Cho Các Tác Vụ Dưới 3 Phút
Một quy tắc vàng đã giúp tôi tiết kiệm rất nhiều thời gian: nếu một tác vụ có thể được sửa thủ công trong vòng chưa đầy 3-4 phút, đừng nhờ đến AI. Những việc như:
- Đổi tên một biến.
- Thêm một điều kiện (conditional) đơn giản.
- Sửa một lỗi chính tả hoặc lỗi import hiển nhiên.
Việc khởi động một tác nhân AI, giải thích ngữ cảnh và chờ đợi kế hoạch của nó thường tốn thời gian hơn là tự bạn gõ sửa lỗi. AI thực sự tỏa sáng khi:
- Thay đổi cần thực hiện trải rộng trên nhiều tệp.
- Bạn cần khám phá các tùy chọn hoặc các trường hợp biên (edge cases).
- Công việc bao gồm cả lập kế hoạch và triển khai.
Hãy sử dụng AI ở những nơi nó giúp giảm tải nhận thức (cognitive load) cho bạn, chứ không phải ở những nơi nó chỉ thêm vào sự phức tạp không cần thiết cho các tác vụ đơn giản.
3. Chế Độ Lập Kế Hoạch Trước, Sau Đó Mới Để Agent Chạy
Các công cụ và quy trình làm việc hiện đại ngày càng dựa vào khái niệm “chế độ lập kế hoạch” (plan mode). Đây là lúc tác nhân AI sẽ:
- Đọc kho mã nguồn của bạn.
- Đề xuất một kế hoạch từng bước.
- Liệt kê các tệp mà nó dự định chỉnh sửa và những thay đổi sẽ thực hiện.
Quy trình làm việc của tôi diễn ra như sau:
- Mô tả vấn đề như một ticket chuẩn: hành vi hiện tại, hành vi mong muốn, các ràng buộc, các trường hợp biên.
- Yêu cầu tác nhân AI giữ nguyên ở chế độ lập kế hoạch cho đến khi kế hoạch trông giống như một nhiệm vụ bạn sẽ giao cho một lập trình viên junior.
- Chỉ sau đó mới ra lệnh: “Được rồi, hãy thực hiện kế hoạch này.”
Việc lập kế hoạch trước có thể tốn thêm vài phút, nhưng bù lại sẽ giảm thiểu đáng kể những bất ngờ không mong muốn trong bản so sánh mã nguồn (diff) của bạn. Đây là một bước quan trọng để đảm bảo tính chính xác và an toàn.
4. Cung Cấp Ngữ Cảnh Thực Từ Cơ Sở Mã Nguồn Của Bạn
Sự khác biệt lớn nhất giữa một kết quả AI “tàm tạm” và một kết quả “tuyệt vời, rất hữu ích” chính là ngữ cảnh. Khi làm việc với một tác nhân AI trên một tính năng trong hệ thống Next.js + FastAPI:
- Dán hoặc liên kết đến các triển khai hiện có tương tự (ví dụ: “hãy sao chép cách các sự kiện công khai được triển khai và tái sử dụng mẫu đó”).
- Đề cập đến các trang, API route, dịch vụ hoặc feature flag liên quan.
- Chỉ ra các ràng buộc như “không được chạm vào proxy thanh toán này” hoặc “phải tương thích ngược với API hiện có.”
Các công cụ AI này rất giỏi trong việc sao chép các mẫu đã tồn tại trong kho mã nguồn của bạn. Nếu bạn không chỉ cho chúng các mẫu đó, chúng sẽ vui vẻ tạo ra những mẫu mới, làm tăng sự phức tạp và lộn xộn của codebase. Việc cung cấp ngữ cảnh chi tiết giúp AI tạo ra mã chất lượng cao và phù hợp với kiến trúc hiện có.
5. Để Agent Làm Việc Bất Đồng Bộ Trong Khi Bạn Làm Việc Khác
Việc ngồi nhìn một tác nhân AI làm việc có thể thú vị trong hai lần đầu tiên, nhưng sau đó sẽ trở thành một kẻ giết chết năng suất thực sự. Một khi kế hoạch đã được phê duyệt và tác nhân bắt đầu chỉnh sửa:
- Đẩy nó về chế độ chạy nền.
- Thực hiện một tác vụ nhỏ khác, xem xét mã (review) hoặc xử lý một ticket lập kế hoạch.
- Chờ thông báo hoặc tin nhắn hoàn thành.
Hãy coi AI như một đồng đội mà bạn tin tưởng sẽ tuân thủ các quy cách kỹ thuật, chứ không phải là một màn hình mà bạn cần phải dán mắt vào. Đây là lúc các công cụ hỗ trợ chạy tác nhân bất đồng bộ và thông báo thực sự phát huy tác dụng. Việc này giúp tối đa hóa hiệu quả làm việc của lập trình viên.
6. Cung Cấp Cho AI Quyền Truy Cập Toàn Bộ Luồng (Frontend + Backend)
Hầu hết các vấn đề thực tế không phải là “thuần frontend” hay “thuần backend” đơn thuần. Một luồng thi đấu, thanh toán, hoặc quy trình onboarding thường bao gồm: trang Next.js, các thành phần React, API route của FastAPI, cơ sở dữ liệu, feature flags và hệ thống phân tích. Nếu tác nhân AI chỉ nhìn thấy một nửa bức tranh, nó sẽ:
- Sửa frontend nhưng bỏ qua phần xác thực backend.
- Chắp vá API nhưng quên trạng thái biên của giao diện người dùng.
Vì vậy, đối với các thiết lập đa phần, hãy:
- Thêm tất cả các thư mục liên quan vào không gian làm việc của AI (ứng dụng Next.js, backend FastAPI, thư viện dùng chung).
- Chỉ rõ nơi tính năng bắt đầu và kết thúc (“từ trang landing này đến điểm cuối FastAPI và bảng DB này”).
Cái nhìn tổng thể càng tốt, AI càng có thể thực hiện các thay đổi “end-to-end” (đầu cuối) một cách toàn diện hơn. Điều này đặc biệt quan trọng trong các hệ thống phức tạp, nơi sự hiểu biết toàn diện về kiến trúc là chìa khóa.
7. Xem Xét Các Bản Thay Đổi (Diffs) Như Một Kỹ Sư Cấp Cao
Điều tồi tệ nhất bạn có thể làm là coi kết quả đầu ra của AI là “mã đáng tin cậy.” Sau khi tác nhân AI hoàn thành:
- Mở bản so sánh mã (diff) trong trình soạn thảo hoặc công cụ quản lý mã nguồn (SCM) của bạn và xem xét nó như một yêu cầu kéo (pull request) từ một lập trình viên junior.
- Tìm kiếm các trừu tượng hóa không cần thiết, logic trùng lặp và những thay đổi hành vi tinh tế.
- Chạy các bài kiểm tra và tự mình nhấp qua các luồng quan trọng theo cách thủ công.
AI không hiểu rõ nghiệp vụ của bạn, các thỏa thuận mức độ dịch vụ (SLA), hay cái dashboard quan trọng của CEO có thể bị lỗi nếu một trường thay đổi kiểu dữ liệu. Khả năng phán đoán đó vẫn là trách nhiệm của bạn. Đây là giai đoạn không thể thiếu để đảm bảo chất lượng và an toàn sản phẩm.
8. Sử Dụng AI Để Xem Xét Mã Của Chính Bạn
Một trường hợp sử dụng bị đánh giá thấp: AI như một người đánh giá mã (code reviewer). Sau khi bạn đã commit các thay đổi của mình:
- Yêu cầu một tác nhân AI khác (không phải tác nhân đã viết mã đó) xem xét commit hoặc pull request gần đây nhất.
- Chỉ dẫn nó tập trung vào các trường hợp biên, hiệu suất, xử lý lỗi và bảo mật.
- Sử dụng phản hồi như một cặp mắt thứ hai, không phải là thẩm quyền cuối cùng.
Mô hình hai tác nhân này giúp phát hiện ra những vấn đề mà bạn có thể đã bỏ qua vì quá tập trung vào thay đổi đó. Nó bổ sung thêm một lớp kiểm tra chất lượng mạnh mẽ.
9. Biết Rõ Khu Vực Nào AI Không Được Phép Đụng Đến
Mọi hệ thống sản phẩm nghiêm túc đều có những khu vực “không được phép sai sót”: định tuyến thanh toán, phân tách khách hàng (tenant isolation), xác thực, cấu hình cơ sở hạ tầng quan trọng. Đối với những khu vực này:
- Hoặc không cho phép các tác nhân AI chạm vào chúng chút nào, hoặc
- Buộc phải thực hiện các thay đổi cực kỳ nhỏ, có phạm vi giới hạn chặt chẽ với sự xem xét kỹ lưỡng của con người.
Việc một trang landing page công khai bị lỗi trong 5 phút là điều có thể chấp nhận được; nhưng việc một cấu hình đa khách hàng làm rò rỉ dữ liệu giữa các khách hàng vì tác nhân AI đã tái cấu trúc một middleware dùng chung sai cách thì không thể chấp nhận được. Quy tắc chung:
- Sử dụng AI trên mã bạn đã hiểu rõ và có thể tự mình triển khai.
- Sử dụng AI cho các bản thử nghiệm khái niệm (proofs-of-concept) ở những khu vực không rõ ràng, sau đó quay lại triển khai lại hoặc kiểm toán kỹ lưỡng.
Tư duy này giữ cho AI là một yếu tố nhân lên sức mạnh (force multiplier) thay vì một nguồn gây ra sự cố sản phẩm thầm lặng.
Trước Khi Tích Hợp AI Sâu Hơn Vào Quy Trình Làm Việc Của Bạn
Nếu bạn là một lập trình viên cấp cao hoặc tech lead, mục tiêu không phải là “sử dụng AI ở mọi nơi,” mà là “tạo ra nhiều giá trị hơn với ít gánh nặng tinh thần và rủi ro hơn.” Thiết lập hoạt động hiệu quả nhất cho một stack Next.js + FastAPI trong Zed là:
- Hai công cụ bổ trợ: Zed làm trình soạn thảo, Claude hoặc Gemini làm bộ não tác nhân/chat.
- Một bộ lọc cứng rắn: Không dùng AI cho các sửa lỗi tầm thường hoặc các đường dẫn mã cực kỳ quan trọng.
- Quy trình làm việc: Lập kế hoạch trước, cung cấp ngữ cảnh phong phú, làm việc bất đồng bộ, trong đó tác nhân thực hiện công việc nặng nhọc còn bạn làm công việc tư duy và xem xét.
Với tư duy đó, AI không còn là một món đồ chơi hay một mối đe dọa, mà trở thành đúng như nó nên là: một lập trình viên junior rất nhanh, rất vâng lời, không bao giờ biết mệt mỏi – nhưng luôn cần sự phán đoán của bạn trước khi bất cứ điều gì được đẩy lên môi trường sản phẩm. Đây là cách để tận dụng tối đa tiềm năng của AI trong phát triển phần mềm mà vẫn duy trì được sự kiểm soát và trách nhiệm của con người.
