Deep dive Cursor: cách senior engineer dùng Cursor từ Tab tới agent

1. Lộ trình của buổi deep dive và dự án mẫu TaskFlow

Himalay mở đầu bằng việc nhắc lại video trước của kênh ByteMonk, nói về cách Cursor hoạt động và vì sao SpaceX đang để mắt tới nó (theo video đăng ngày 30/09/2026). Sau video đó, rất nhiều người xem hỏi xin một buổi deep dive đúng nghĩa. Vì vậy video này cho thấy các engineer thực sự dùng Cursor từ đầu tới cuối như thế nào: các workflow, các mental model, và 25 mẹo thực hành có thể áp dụng ngay.

Anh đi qua lộ trình của buổi học theo từng phần:

• Đầu tiên là Cursor thực chất là gì và nó "nghĩ" như thế nào, để người xem có mental model đúng ngay từ đầu.
• Tiếp theo là ba kiểu tương tác: Tab, Command K và Chat. Mỗi kiểu có một use case riêng, và biết lúc nào nên dùng kiểu nào giúp tiết kiệm rất nhiều thời gian.
• Sau đó đi sâu vào Plan Mode và Agent Mode, một workflow hai pha mà theo anh chính là thứ tách cách dùng chuyên nghiệp ra khỏi kiểu chỉ "làm cho xong" bằng AI.
• Rồi tới Rules, Commands và Memories: tính năng bị dùng ít nhất trong Cursor, nhưng lại mang tới mức tăng năng suất lớn nhất, đặc biệt khi làm việc trong team.
• Cuối cùng là các workflow nâng cao: Parallel Agents, Background Agents, Bugbot và các integration MCP.

Xuyên suốt từng phần, anh rút ra các mẹo thực hành áp dụng được ngay. Lời hứa của anh: tới cuối video, người xem sẽ có một mối quan hệ hoàn toàn khác với IDE của mình.

Để mọi thứ có thật, cả khóa học xoay quanh một dự án thật: một API quản lý task. Anh mô tả nó được build bằng FastAPI và Next.js, và gợi ý hãy hình dung nó như một backend Jira gọn nhẹ, có users, tasks, projects và một notification service. Trên màn hình và trong repo mẫu, dự án mang tên TaskFlow, với backend Express dùng MongoDB và frontend React. Dự án được cố tình để dở dang, mới build khoảng 30%, và cả nhóm sẽ dựng nó lên dần qua từng phần. Tới cuối khóa, nó sẽ là một API hoạt động đầy đủ. Bộ khung khởi đầu (starting skeleton) có link trong phần mô tả video để người xem tải về và làm theo.

2. Cursor là gì, và mental model "kỹ sư giỏi mới vào team"

Phần nền tảng bắt đầu bằng một định nghĩa đơn giản: Cursor là một code editor được build trên VS Code. Cùng phím tắt, cùng extension, cùng giao diện. Nếu đang dùng VS Code, việc chuyển sang chỉ mất khoảng 5 phút và bạn sẽ thấy như ở nhà. Khi mở Cursor lần đầu, bạn sẽ thấy hai view: một agentic view và một editor view (theo video đăng ngày 30/09/2026). Người từ VS Code sang thì nên chuyển sang editor view: nó giống hệt thứ bạn đã quen, và bạn có thể làm việc hiệu quả ngay.

Tiếp theo là khác biệt căn bản giữa Cursor và mọi editor bạn từng dùng. Một editor bình thường chỉ thấy file bạn đang mở, vậy thôi. Cursor thấy toàn bộ codebase: mọi function, mọi class, mọi quan hệ giữa các file. Và nó dùng toàn bộ context đó để giúp bạn theo những cách mà một editor truyền thống đơn giản là không làm được.

Rồi tới mental model mà Himalay muốn người xem mang theo suốt cả khóa học. Hãy nghĩ về AI bên trong Cursor như một kỹ sư xuất sắc vừa gia nhập team. Người đó biết mọi ngôn ngữ, mọi framework, mọi design pattern. Nhưng người đó không biết gì về codebase cụ thể của bạn: các convention của bạn, các quyết định legacy, cấu trúc thư mục của bạn. Thiếu những hiểu biết đó, họ sẽ quay về các pattern chung chung: code đúng cú pháp nhưng sai về kiến trúc với dự án của bạn. Nó compile được, nhưng nó không khớp.

Việc của bạn là trao cho "kỹ sư mới" đó context thật nhanh, và đó chính xác là điều cả khóa học này dạy.

3. Hai điều về setup: chọn model và voice input

Trước khi đi tiếp, anh nói nhanh hai điều về setup.

Về chọn model, theo video đăng ngày 30/09/2026: nếu đang dùng gói free, bạn có chế độ Auto, tự chọn model phù hợp cho từng task. Như vậy là đủ để làm theo mọi thứ trong khóa học này. Còn nếu dùng gói Pro, giá 20 đô một tháng (theo video đăng ngày 30/09/2026; bảng giá hiện hành ở cursor.com/pricing), bạn được dùng các model như Claude Sonnet và Opus. Lời khuyên của anh:

• Dùng Sonnet cho phần lớn task: nhanh và chính xác.
• Dùng Opus khi làm việc phức tạp, như thiết kế kiến trúc hoặc debug một lỗi tinh vi trải trên nhiều file.
• Với các chỉnh sửa nhanh, Auto là ổn.

Về voice input: Cursor có sẵn voice mode, và còn một công cụ tên Wispr Flow mà anh giới thiệu là miễn phí và chạy tốt (theo video đăng ngày 30/09/2026). Khi phải viết prompt dài, nói ra nhanh hơn gõ đáng kể.

4. Ba mức can thiệp của AI, bắt đầu với Tab

Có ba cách tương tác với AI bên trong Cursor, mỗi cách hợp với một loại task khác nhau: Tab, Command K và Chat. Himalay đề nghị coi chúng là ba mức can thiệp của AI:

• Tab tự động và không cản đường bạn.
• Command K có chủ đích: bạn chọn chính xác thứ cần đổi.
• Chat là nơi bạn có một cuộc trò chuyện đầy đủ với codebase.

Đi qua khóa học, bạn sẽ tự nhiên hình thành cảm giác nên dùng cái nào và vào lúc nào.

Bắt đầu với Tab. Tab là autocomplete của Cursor, nhưng nó hoạt động khác với thứ bạn quen dùng. Đa số editor đoán vài ký tự tiếp theo dựa trên thứ bạn đang gõ. Cursor thì đoán lần chỉnh sửa tiếp theo của bạn dựa trên thứ bạn đang cố làm. Nó nhìn vào code xung quanh, hiểu ý định của bạn và gợi ý nguyên những khối code, đôi khi trải trên nhiều dòng.

Bạn sẽ nhận ra điều này ngay lần đầu dùng: viết xong một dòng, bấm Tab, và nó viết đúng ba dòng tiếp theo. Bấm Tab lần nữa, xong. Cảm giác như editor đang đọc được suy nghĩ của bạn một chút, và bạn sẽ hình thành muscle memory rất nhanh vì Tab luôn bật. Bạn không phải kích hoạt gì cả.

Một điểm đáng lưu ý: nếu gợi ý sai, chỉ cần bấm Escape rồi gõ tiếp. Cursor sẽ tự điều chỉnh.

Mẹo của phần này: sau khi chấp nhận một gợi ý Tab, hãy bấm Tab thêm lần nữa ngay lập tức. Cursor đoán thay đổi hợp lý tiếp theo dựa trên thứ bạn vừa chấp nhận. Nối các lần Tab như vậy lại với nhau, bạn đi qua những đoạn code lặp đi lặp lại rất nhanh. Phần lớn developer dừng lại sau một lần Tab. Đừng như vậy.

5. Command K: sửa có chủ đích trong một file, và cả trong terminal

Tiếp theo là Command K, và theo Himalay đây có lẽ là thứ bạn dùng nhiều hơn mọi thứ khác trong công việc hằng ngày. Anh mở dự án quản lý task để cho thấy chính xác Command K làm gì.

Anh mở notification service. Nhìn qua là thấy ngay không có error handling trong bất kỳ function nào: đây là một trong những lỗ hổng được cố tình để lại trong bộ khung. Anh bôi đen toàn bộ khối code, bấm Command K và gõ yêu cầu:

add error handling to every function

Cursor hiện ra một diff: màu xanh cho phần được thêm vào, màu đỏ cho phần bị bỏ đi. Anh review và chấp nhận. Cả việc mất khoảng 10 giây, và anh không hề rời khỏi file.

Đó là pattern: bôi đen, ra lệnh, review. Bạn có thể dùng nó cho bất kỳ việc có chủ đích nào trong một file, ví dụ:

• Chuyển đoạn này sang async/await.
• Thêm type annotation cho class này.
• Refactor đoạn này để dùng strategy pattern.

Mỗi lần, bạn nhận một diff chính xác cho đúng thứ bạn yêu cầu. Không có gì khác bị thay đổi.

Một điều mà phần lớn developer không bao giờ phát hiện ra: Command K hoạt động cả trong terminal (theo video đăng ngày 30/09/2026). Mở terminal tích hợp, bấm Command K và gõ bằng tiếng Anh thông thường, chẳng hạn "show me the last five commit messages for this project" hoặc "run all unit tests and log the failures". Nó sẽ viết lệnh shell cho bạn. Trên màn hình, với yêu cầu đầu tiên, Cursor đề xuất lệnh git log -5 --pretty=format:"%s". Rất hữu ích khi bạn không nhớ chính xác cú pháp.

Và một ranh giới quan trọng cần biết: dùng Command K cho các thay đổi có chủ đích trong một file. Ngay khi thay đổi liên quan tới hơn một file, hãy chuyển sang Chat. Bạn sẽ nhận kết quả tệ hơn nếu đẩy Command K vượt quá thứ nó được thiết kế để làm.

6. Chat và hệ thống @: tự chọn context cho model

Đã xong Tab và Command K, giờ tới Chat, nơi mọi thứ trở nên mạnh hơn. Command L mở panel chat. Bạn dùng nó bất cứ khi nào cần suy luận, cần thay đổi trên nhiều file, hoặc muốn hỏi code của mình hoạt động ra sao.

Khác biệt then chốt giữa Chat này và một thứ như ChatGPT là context. Khi bạn hỏi Cursor ở đây, nó không chỉ trả lời từ kiến thức chung. Nó nắm toàn bộ codebase của bạn: các file, cấu trúc, quan hệ giữa mọi thứ.

Nhưng có một điều quan trọng cần hiểu: Cursor không tự biết phần nào trong codebase liên quan tới câu hỏi của bạn. Bạn phải chỉ cho nó. Đó là việc của hệ thống @. Theo Himalay, giỏi hệ thống này chính là thứ tách những developer có kết quả tốt ra khỏi những developer có kết quả thất thường. Gõ @ trong chat là bạn tham chiếu được file cụ thể, thư mục, docs chính thức, git history, output của terminal, thậm chí cả nội dung web đang chạy.

Anh cho xem cách làm này trên dự án. Lúc đó terminal đang có lỗi: notification của phần quản lý task đang hỏng mà không báo gì (failing silently). Anh mở một chat mới, gõ @terminal để kéo output lỗi vào, rồi @notificationService.js để đưa file liên quan vào, và mô tả vấn đề. Cursor có cả lỗi lẫn code, và nó chỉ ra vấn đề ngay lập tức. Không phải copy lỗi dán sang một cửa sổ khác, không phải chuyển qua lại, mọi thứ nằm ngay tại đây.

Rồi anh nêu một nguyên tắc muốn người xem nhớ, áp dụng xuyên suốt khóa học: context lớn hơn không có nghĩa là câu trả lời tốt hơn. Relevance beats volume, sự liên quan thắng khối lượng. Nếu bạn đổ cả codebase vào context cho một bug fix đơn giản, bạn sẽ nhận câu trả lời tệ hơn so với khi chỉ tham chiếu hai file liên quan. Model bị nhiễu làm rối giống hệt như một kỹ sư con người. Nếu muốn ai đó sửa một bug trong notification service, bạn không đưa họ cả codebase rồi bảo "đây, tự tìm hiểu đi". Bạn nói: đây là file, đây là lỗi, sửa nó đi.

7. Một task một chat, debug bằng hai nguồn, lặp lại pattern từ một commit

Mẹo tiếp theo: luôn mở một chat mới cho mỗi task mới. Chuyện này không chỉ để tiết kiệm token; đó chỉ là lý do bề mặt. Lý do thật là context cũ từ task trước khiến agent đưa ra giả định dựa trên một bài toán sai. Theo Himalay, đó là nguyên nhân số một gây ra output tệ trong Cursor. Một task, một chat. Hãy biến nó thành thói quen từ ngày đầu tiên.

Khi debug, hãy kết hợp @terminal và @screenshot trong cùng một tin nhắn: đưa output lỗi và một screenshot của thứ bạn đang thấy trên browser. Sự kết hợp này cắt bớt đáng kể chuyện qua lại, vì model có cùng lúc cả tín hiệu kỹ thuật lẫn context hình ảnh.

Và đây là một workflow mà chính anh sẽ dùng ở phần sau của khóa học. Nếu cần lặp lại một pattern trên nhiều service, chẳng hạn bạn đã thêm error handling cho notification service ở commit trước và giờ muốn làm y như vậy cho tất cả các service khác, hãy mở một chat mới và nói kiểu:

Look at what we did in commit ABC123 and implement the same error handling pattern in emailService.js

Cursor đọc diff và lặp lại pattern một cách chính xác. Không copy paste, không phải giải thích lại từ đầu.

Tóm lại cho ba kiểu tương tác:

• Tab khi bạn đang vào guồng và muốn AI theo kịp mình.
• Command K khi bạn biết chính xác cần thay đổi gì ở một chỗ.
• Chat khi bạn cần suy luận hoặc thay đổi trên nhiều file.

Thành thạo ba thứ này là bạn đã làm việc hiệu quả hơn phần lớn developer dùng Cursor. Tới đây, dự án đã có error handling cho notification service và đã debug xong một lỗi trong terminal.

8. Plan mode rồi mới tới agent mode: feature task labels

Tiếp theo là cách build trọn một feature từ đầu tới cuối: Plan mode và Agent mode.

Phần lớn developer mở Cursor, chuyển thẳng sang agent mode, mô tả thứ mình muốn và để nó chạy. Và phần lớn thời gian, họ rơi vào một vòng lặp sửa sai. Agent làm một thứ hợp lý nhưng chưa hẳn đúng. Họ sửa. Nó lại trôi đi. Họ sửa lần nữa. Mọi thứ trở nên bực bội rất nhanh. Cách chữa là plan mode, và theo Himalay, một khi đã dùng đúng cách thì bạn sẽ không quay lại nữa.

Ví dụ trên dự án: cần thêm feature task labels, khả năng gắn nhãn cho task như urgent, blocked, in review. Việc này đụng tới thay đổi frontend, thay đổi backend và một database migration. Đúng loại task mà agent mode một mình, không có định hướng rõ, sẽ tạo ra thứ chạy được nhưng không khớp với phần còn lại của codebase.

Vì vậy anh chuyển chat sang plan mode và mô tả thứ mình muốn. Trên màn hình, prompt mở đầu bằng "We need to add a task labels feature to our project", nêu khả năng gắn nhãn "urgent", "blocked", "in review", và anh gõ @ để chèn thêm file Task.js vào context. Cursor chưa viết một dòng code nào. Thay vào đó, nó tạo một bản tổng quan kiến trúc, các thay đổi database schema, và một checklist đầy đủ mọi bước nó định làm. Trước khi ra plan, nó còn hỏi vài câu làm rõ, ví dụ UI tối thiểu bạn muốn cho label trên mỗi task là gì.

Anh có thể đọc qua plan này, chỉnh sửa nó, thêm một mục to-do, bỏ một thứ nằm ngoài phạm vi và điều chỉnh cách tiếp cận. Plan là thứ anh sở hữu, và anh có thể thay đổi nó trước khi bất cứ thứ gì bị động tới.

Khi plan đã ổn, anh bấm Build. Đó là lúc Cursor tự chuyển sang agent mode và bắt đầu thực thi. Nó đi lần lượt qua checklist: viết database migration, cập nhật task model, thêm các API endpoint, cập nhật frontend, và đánh dấu từng mục khi xong. Anh không làm gì ngoài việc ngồi xem và thỉnh thoảng review.

Mẹo của phần này: với mọi việc không tầm thường, luôn bắt đầu bằng plan mode. Nó buộc bạn nghĩ rõ mình muốn gì trước khi agent chạm vào code. Chỉ dẫn mơ hồ trong agent mode dẫn tới output mơ hồ. Một plan rõ ràng ngay từ đầu giúp tiết kiệm nhiều vòng sửa sai.

Nếu bạn đã có tài liệu yêu cầu hoặc một PRD, hãy đưa nó vào bằng @file ngay đầu plan mode. Cursor đọc nó và dựng plan trực tiếp từ các yêu cầu của bạn, nên bạn bỏ qua được toàn bộ phần câu hỏi làm rõ.

9. Test trước khi Keep, commit trước khi build, nhờ model thứ hai review

Himalay nhấn mạnh một điều quan trọng về cách agent mode hoạt động: code được ghi thẳng vào file thật của bạn trong lúc agent chạy. Nó đã tồn tại trên ổ đĩa ngay khi agent viết ra. Vì vậy trước khi bấm Keep All, hãy test trước. Chạy app, kiểm tra hành vi, chắc chắn nó làm đúng điều bạn mong đợi. Rồi mới chấp nhận. Nếu có gì sai, bạn có nút Undo All. Nhưng cánh cửa đó khép lại dần khi bạn tiếp tục build. Đó là lý do phải test trước khi chấp nhận, không phải sau.

Và đây là thói quen quan trọng nhất quanh agent mode, theo lời anh: commit code trước khi chạy agent. Không phải sau, mà là trước. Ngay lúc này, trước khi bấm Build cho plan, anh tạo một git commit. Nếu agent động vào 15 file và đi theo hướng anh không muốn, anh có một điểm revert sạch. Anh "bảo đảm" rằng sẽ có lúc chuyện này cứu bạn.

Khi agent làm xong, có một chốt chất lượng sẵn trong Cursor đáng dùng (theo video đăng ngày 30/09/2026): một model đã viết code, bạn có thể nhờ một model thứ hai review các thay đổi đó trước khi chấp nhận. Nó bắt được những thứ model đầu bỏ sót. Không cần công cụ thêm, mọi thứ có ngay trong giao diện.

Feature task labels đã xong và đã test. Theo anh, dự án giờ hoàn thành khoảng 55%: có auth, CRUD cho task, error handling trong notification service, và giờ có đầy đủ task labels với frontend và backend được nối với nhau.

10. Rules: onboarding doc mà agent đọc trước mỗi lần làm việc

Mọi thứ build tới giờ đều qua từng tương tác riêng lẻ: một chat, một task, một developer. Nhưng nếu bạn làm trong một team, hoặc chỉ đơn giản là làm cùng một dự án trong nhiều tháng, bạn sẽ gặp một vấn đề khác: agent không nhớ gì giữa các session. Mỗi chat mới là một tờ giấy trắng. Nó không biết team bạn dùng async database call ở mọi nơi. Nó không biết convention thư mục của bạn. Nó không biết có một module auth legacy không bao giờ được sửa trực tiếp. Rules, Commands và Memories là cách để sửa chuyện đó, và anh đi qua từng cái.

Bắt đầu với rules. Một rule là một chỉ dẫn lâu dài mà agent tự động đọc trước mọi tương tác trong dự án. Bạn viết một lần và nó áp dụng ở mọi nơi, không cần nhắc lại trong từng chat. Hãy nghĩ về nó như tài liệu onboarding bạn đưa cho một kỹ sư mới vào ngày đầu tiên: coding standard, các quyết định kiến trúc, những điều nên và không nên làm.

Cách bắt đầu nhanh nhất là gõ /generate trong chat. Cursor quét codebase hiện có: các pattern bạn đang dùng, các thư viện bạn đã import, cách các file được tổ chức, rồi tạo ra một file rules khớp với dự án của bạn. Anh làm luôn trên dự án: gõ /generate, Cursor phân tích codebase, và khoảng 30 giây sau đã có một bộ rules chắc chắn phản ánh những gì đã build. Anh review, chỉnh vài chỗ, và từ đó mọi tương tác của agent trên dự án đều theo các rules này mà anh không phải nhắc tới. (Trong repo mẫu, /generate là một skill đặt ở .cursor/skills/generate.)

Mẹo của phần này: thay vì viết rules từ con số không, hãy để Cursor đọc code hiện có và tạo ra chúng, rồi tùy chỉnh từ đó.

Khi đã có bộ rules cơ bản, có một nguồn từ cộng đồng tên cursor.directory đáng bookmark. Nó có những bộ rules đã được thử thách cho từng stack cụ thể: Next.js, TypeScript, Python, React, các pattern UI và UX, và nhiều thứ khác. Thay vì tự mò ra best practice, bạn tìm bộ rules khớp với stack của mình, mang về và điều chỉnh. Ai đó đã làm phần việc khó cho đúng setup của bạn. Trong cursor.directory, anh chỉ cho thấy những template được developer viết kỹ, chẳng hạn bộ rules cho dự án Next.js mở đầu bằng việc giao cho model vai một chuyên gia web development, gồm JS, TS và CSS, và khuyên người xem xem qua và thử dùng.

Bạn còn có thể giới hạn rule cho từng phần của dự án. Nếu chỉ muốn một rule áp dụng cho các file backend Node.js, anh đặt glob pattern là backend/**/*.js. Rules frontend ở lại frontend, rules backend ở lại backend. Rules không liên quan chỉ thêm nhiễu, và nhiễu làm giảm chất lượng output.

Anh nói có ba loại rules đáng biết, và kể ra hai: project rules nằm trong git repo và áp dụng cho mọi developer trong team khi họ pull về; user rules là sở thích cá nhân, ở lại trên máy bạn và không bao giờ được commit. Với convention của team, luôn dùng project rules. (Trang Rules trong docs Cursor, xem ngày 21/10/2026, liệt kê bốn loại: Project Rules trong .cursor/rules, User Rules, Team Rules quản lý từ dashboard cho gói Team và Enterprise, và file AGENTS.md.)

11. Commands: viết prompt một lần, cả team dùng mãi

Giờ tới commands, vì theo Himalay đây là chỗ năng suất cá nhân trở thành năng suất của cả team. Một command là một chỉ dẫn tái sử dụng được, bạn lưu thành file markdown và gọi bằng dấu gạch chéo.

Cách dễ hiểu nhất là qua một ví dụ cụ thể trên dự án. Anh cần thêm structured logging cho nhiều service: task service, notification service và email service. Anh có thể viết một prompt chi tiết mỗi lần, giải thích chính xác cấu trúc logging mình muốn. Hoặc viết prompt đó một lần, lưu thành command, và từ đó chỉ cần gõ /add-logging rồi trỏ vào bất kỳ file nào.

Anh tạo nó ngay: vào thư mục commands bên trong .cursor, tạo file mới tên add-logging.md và viết ra chỉ dẫn chính xác. Nội dung file trên màn hình:

import the logging library
create a logger object
add a log line at the start of every function with relevant context, add error logging in every exception block, and I include a sample snippet as a reference

Command đã sẵn sàng. Anh mở một chat mới, gõ /add-logging, tham chiếu notification service và bấm Enter. Cursor đọc file command và triển khai pattern một cách nhất quán, mỗi lần một cấu trúc như nhau. Rồi anh làm tương tự cho task service và email service. Ba service, cùng một pattern logging, không phải lặp lại prompt nào.

Mẹo của phần này: nếu thấy mình viết cùng một loại prompt hơn hai lần (thêm logging, viết test, migrate một phiên bản API), hãy lưu nó thành command. Bạn viết chỉ dẫn chi tiết một lần và dùng lại mãi mãi.

Thư mục commands nằm trong .cursor ở repo của bạn. Commit nó lên git, và mọi developer pull repo về đều tự động có toàn bộ commands. Một developer mới gia nhập, pull repo về, và ngay lập tức có quyền dùng mọi workflow tái sử dụng mà team đã xây. (Tính đến 21/10/2026, trang docs về commands của Cursor chuyển hướng tới trang Skills, có mục hướng dẫn chuyển commands sang skills.)

Gom phần này lại:

• Rules mã hóa các tiêu chuẩn của bạn để agent tự động tuân theo.
• Commands biến các workflow tốt nhất của bạn thành thứ tái sử dụng được cho cả team.
• Memories cho agent context lâu dài để bạn không phải bắt đầu lại từ đầu mỗi session.

Hãy thiết lập ba thứ này ở đầu mỗi dự án. Lần đầu mất khoảng 30 phút, và nó trả lại công sức ở mọi tương tác với agent từ đó trở đi. Dự án lúc này khoảng 70%: đã có error handling, đã build task labels, structured logging nhất quán trên mọi service, và agent đã có đúng rules để làm theo từ giờ.

12. Parallel agents: ba việc độc lập trong cùng một lúc

Tiếp theo là các workflow nâng cao, những thứ mà Himalay nói sẽ thực sự thay đổi lượng việc bạn ship được trong một ngày. Mọi thứ tới giờ đều là một agent, một task, một developer. Riêng chừng đó đã là mức tăng năng suất đáng kể. Nhưng còn một tầng nữa, và phần này nói về nó.

Bắt đầu với parallel agents, vì nó thay đổi cách bạn nghĩ về ngày làm việc của mình. Tính năng này cho bạn chạy nhiều agent cùng lúc, mỗi agent làm một task hoàn toàn riêng trong workspace cô lập của nó. Bên dưới, nó dùng git worktree: mỗi agent có branch riêng và không thể can thiệp vào việc của các agent khác. (Docs Cursor có trang riêng về Worktrees.)

Trên dự án, anh có ba việc cần làm: thêm pagination cho API danh sách task, viết unit test cho notification service, và sửa bug bộ đếm task (task counter) đã nằm trong bộ khung từ đầu. Bình thường, đó là một buổi chiều làm tuần tự. Anh khởi động cả ba agent cùng lúc. Trong khi agent 1 làm pagination, agent 2 viết test, agent 3 truy tìm bug. Anh review cả ba output khi chúng xong. Buổi chiều tuần tự ấy rút lại còn khoảng một giờ.

Mẹo của phần này: dùng parallel agents cho những task thực sự độc lập với nhau. Một feature mới, một bug fix và một bộ test là ứng viên hoàn hảo: chúng động tới các phần khác nhau của codebase và không cần phối hợp. Đừng chạy parallel agents cho các task phụ thuộc vào output của nhau. Như vậy sẽ tạo ra merge conflict, tốn nhiều thời gian hơn phần bạn tiết kiệm được.

13. Background agents: giao việc lên cloud như viết một ticket

Background agents còn đi xa hơn nữa. Chúng chạy trên cloud, không chạy trên máy bạn. Bạn mô tả một task, Cursor dựng một môi trường remote cô lập, clone repository của bạn, làm việc trên một branch riêng, và khi xong thì tạo ra một pull request sẵn sàng để merge, kèm screenshot, log và một bản ghi hình những gì nó đã làm (theo video đăng ngày 30/09/2026).

Bạn có thể kích hoạt một background agent rồi gập laptop lại, nó vẫn tiếp tục làm. Bạn quay lại và có một PR đang chờ bạn review. Trên dự án, anh có thể yêu cầu "implement error handling in all the APIs of the project". Background agent nhận việc, làm hết, và tạo ra một PR mà anh review như mọi PR khác.

Từ khóa với background agent là được định nghĩa rõ (well defined). Một chỉ dẫn mơ hồ tạo ra một PR mơ hồ, mà review nó còn tốn thời gian hơn phần đã tiết kiệm. Vì vậy hãy đối xử với nó như viết một ticket đúng nghĩa: phạm vi rõ, tiêu chí nghiệm thu (acceptance criteria) rõ.

Bạn cũng không cần mở Cursor để kích hoạt một background agent: có thể làm thẳng từ Slack, GitHub và Linear (theo video đăng ngày 30/09/2026). Nếu team bạn quản lý công việc trên Linear, hãy giao một ticket cho background agent ngay từ đó, và nó bắt tay vào làm ngay lập tức. (Tính đến 21/10/2026, docs Cursor gọi tính năng này là Cloud Agents và ghi rõ Cloud Agents trước đây tên là Background Agents.)

14. Bugbot: review tự động cho mọi pull request

Tiếp theo là Bugbot, một trong những tính năng Himalay thích nhất ở Cursor. Theo video đăng ngày 30/09/2026, Bugbot kết nối với GitHub repository của bạn và tự động review mọi pull request bạn mở. Nó phân tích các thay đổi, xác định bug tiềm ẩn và để lại comment ngay trên PR, đúng như một reviewer là người sẽ làm.

Khi tìm ra một vấn đề, nó thêm một link Fix in Cursor. Bạn bấm vào, Cursor mở ra với một prompt điền sẵn trỏ thẳng vào vấn đề. Bạn sửa và push.

Hãy nghĩ xem điều này nghĩa là gì khi ở quy mô lớn. Mọi PR đều có ngay một lượt review. Các reviewer người dành thời gian cho kiến trúc và logic, thay vì đi bắt những null check bị thiếu hay những exception không được xử lý.

Mẹo của phần này: bật Bugbot cho mọi repository đang hoạt động. Theo anh, cấu hình mất năm phút và từ đó nó chạy tự động (theo video đăng ngày 30/09/2026). Cách kết nối repo và các tùy chọn của Bugbot có trong docs Bugbot.

15. MCP và Context7: cho agent docs mới nhất của framework

Giờ tới MCP, Model Context Protocol. Theo Himalay, đây là thứ biến Cursor từ một editor tuyệt vời thành một môi trường phát triển được kết nối. MCP là một hệ thống plugin cho agent của Cursor. Nó cho agent kết nối với các công cụ và dịch vụ bên ngoài như GitHub, Notion, Figma, Stripe, Playwright, các database. Anh nói có hơn 1.800 MCP server có sẵn (theo video đăng ngày 30/09/2026). Khi bạn thêm một server, agent có thể tương tác trực tiếp với công cụ đó ngay trong workflow, không cần bạn chuyển context. (Cách thêm server có trong docs MCP của Cursor.)

Server hữu ích tức thì nhất để cài là Context7, và anh giải thích lý do. Khi Cursor viết code với một framework như FastAPI hay Next.js, nó dựa vào dữ liệu training. Nhưng dữ liệu đó có ngày cutoff. Nếu một framework ra bản cập nhật lớn sáu tháng trước, Cursor có thể vẫn đang sinh code theo API cũ. Code đó compile được, chạy được, nhưng dùng các pattern đã deprecated. Bạn chỉ phát hiện khi có thứ gì hỏng trên production.

Context7 là một MCP server luôn có docs mới nhất của các framework lớn, theo anh là được cập nhật hằng ngày (theo video đăng ngày 30/09/2026; xem context7.com và repo upstash/context7). Khi bạn thêm nó và đặt một rule như dưới đây, agent sẽ lấy docs hiện hành trước khi viết bất kỳ đoạn code nào gắn với framework, và bạn tự động hết bị nhận các pattern lỗi thời:

always use Context7 for API documentation

Mẹo của phần này: cài Context7 làm MCP server đầu tiên. Theo anh, cài chỉ mất một click (tính đến ngày đăng video, 30/09/2026), rồi thêm rule đó vào file rules là xong. Sau đó, thêm MCP server theo từng bước, không thêm tất cả cùng lúc. Bắt đầu với các công cụ bạn dùng hằng ngày: GitHub để quản lý PR, Notion nếu spec của bạn nằm ở đó, Playwright nếu bạn viết end-to-end test. Mỗi server bỏ bớt một lần chuyển context khỏi workflow của bạn.

16. Hooks, và việc của developer khi agent viết code

Thứ cuối cùng anh nói tới là hooks. Một hook cho bạn chạy script của riêng mình tại những điểm cụ thể trong vòng lặp của agent: sau mỗi lần sửa file, trước khi một lệnh chạy, và sau một commit (theo video đăng ngày 30/09/2026). (Danh sách đầy đủ các điểm hook có trong docs Hooks của Cursor, ví dụ afterFileEdit, beforeShellExecution và stop.)

Dự án lúc này đạt khoảng 80%. Pagination đã có, test đã viết, bug bộ đếm đã sửa, Bugbot đang bắt lỗi trên mọi PR, và agent đang lấy docs hiện hành qua Context7. Theo anh, đó là một trạng thái cuối thực tế cho một dự án thật, dùng một workflow thật.

Rồi anh nói về vai trò của developer. Việc của bạn không còn là viết từng dòng code nữa. Việc của bạn là đưa đúng context, đặt đúng ràng buộc và kiểm chứng output. Intent, context, constraints, validate, rồi lặp lại. Agent thực thi; bạn dẫn dắt và review.

Những developer tăng năng suất gấp 10 lần với Cursor không phải những người biết nhiều phím tắt nhất. Họ là những người đưa context tốt hơn, viết rules tốt hơn, build commands tốt hơn, và dùng plan mode trước khi để agent chạy. Theo Himalay, kỹ năng đó càng có giá trị khi model càng giỏi lên, chứ không giảm đi.

Một điều cuối: đừng chạy chế độ lái tự động hoàn toàn (full autopilot). Hãy review những gì agent viết, hiểu các thay đổi trước khi chấp nhận. Code được ship lên production là trách nhiệm của bạn, bất kể ai hay cái gì đã viết ra nó.

Anh để link bộ khung dự án dùng xuyên suốt khóa học trong phần mô tả video. Lời khuyên của anh là tải về, mở trong Cursor và tự thử các bước này khi đi qua dự án, vì đó thật sự là cách tốt nhất để quen với tất cả những thứ này. Anh hẹn gặp lại người xem ở video sau.