Tôi cần giải tỏa một điều. Trước buổi phỏng vấn @cursor_ai, tôi thực sự chưa từng dùng Cursor.
Tại Meta, Claude Code đang bùng nổ dữ dội. Tôi thậm chí đã trả 200 đô một tháng cho gói cá nhân để dùng cho các dự án phụ của mình. Tôi yêu sự đơn giản của nó, và cảm giác hiệu quả nhanh chóng. Vấn đề mắc kẹt với tôi là phát triển bộ kỹ năng riêng để biến Claude Code thành bất cứ thứ gì tôi muốn. Tôi thậm chí đã bắt đầu xây dựng công cụ điều phối agent của riêng mình trên nền tảng đó.
Trong buổi phỏng vấn trực tiếp, tôi đã dùng Cursor trong 2 ngày để xây dựng dự án phỏng vấn. Lúc đó Cursor 3 chưa ra mắt, nên tôi dùng Editor Window. Tôi đã dùng VSCode nhiều năm đến mức hầu hết phím tắt vẫn còn trong bộ nhớ, nên việc quay lại IDE không quá khó. Tuy nhiên, phải thú thật trong 1-2 giờ đầu tôi khá nhớ CLI. Click chuột vào mọi thứ có vẻ thật man rợ. Nhưng có vài điều thực sự ấn tượng.
Đầu tiên, các mô hình tôi quen dùng - Opus và Codex - có vẻ thông minh hơn. Và thật tuyệt vời khi có thể chuyển đổi mô hình linh hoạt, dùng cả hai cùng lúc cho các phần khác nhau của dự án (Opus cho frontend, Codex cho hệ thống). Trước buổi phỏng vấn, tôi đã ca ngợi đánh giá đối kháng đa mô hình, nên việc làm điều này trực tiếp trong giao diện UI thấy rất tự nhiên. Thậm chí còn tuyệt hơn khi có thể tạo subagent từ các mô hình khác nhau để tận dụng điểm mạnh của cả hai trong cùng một cuộc hội thoại.
Thứ hai, compaction cực kỳ nhanh. Là người dùng Claude Code, tôi quen với việc compaction mất nhiều phút, nên luôn trong trạng thái cảnh giác về context và plan usage. Vì vậy tôi hoàn toàn sốc trước tốc độ của Cursor. Đến mức gần như không bao giờ cần kiểm tra lượng context đang dùng. Nó hoạt động trơn tru, trong khi với Claude Code tôi thường thấy mô hình trở nên siêu ngốc sau compaction.
Và điều thứ ba tôi nhận ra: GUI có thể mang lại nhiều hơn TUI. Việc mở ứng dụng trực tiếp trong trình duyệt của Cursor và thay đổi thiết kế với Design Mode thật trực quan, khiến tôi suy nghĩ về việc các giao diện chuyên dụng có thể làm cho coding agent hiệu quả hơn thế nào.
Xây dựng Cursor bằng Cursor
Từ khi gia nhập cuối tháng 3, tôi chủ yếu làm việc trên Agent Window của Cursor 3 và dùng nó hàng ngày. Dù tôi vẫn nghĩ Claude Code là sản phẩm thú vị với đội ngũ tuyệt vời, nhưng tôi nhận thấy sự đơn giản của nó thường khiến mọi người muốn xây dựng abstraction riêng để bọc quanh nó. Ở công ty cũ, dường như có một công cụ điều phối nội bộ mới xây trên Claude Code được công bố mỗi tuần.
@bcherny thường nói về "latent demand":
"Có một ý tưởng rất cũ trong sản phẩm gọi là nhu cầu tiềm ẩn... bạn xây dựng sản phẩm theo cách có thể hack được, đủ linh hoạt để mọi người có thể lạm dụng nó cho các ứng dụng khác. Sau đó bạn quan sát cách họ lạm dụng và xây dựng cho điều đó."
Chính xác là vậy! Mọi người hội tụ vào các công cụ điều phối cho thấy nhu cầu tiềm ẩn: dùng CLI biến bạn thành người điều phối.
Nhưng mọi quy trình agent tôi từng dùng đều tập trung sai thứ. Chạy nhiều CLI trong GUI là trượt mục tiêu. Cách tiếp cận tôi quan tâm là xây dựng niềm tin vào agent.
Là cựu quản lý kỹ thuật, tôi nhanh chóng nhận ra quản lý agent cũng giống xây dựng đội ngũ kỹ thuật con người. Nhân viên mới cần được onboarding để hiểu codebase và cách làm việc. Họ gia nhập với kỹ năng được đào tạo từ trước: cách debug, viết code chất lượng cao và test, giao tiếp, v.v.
Agent giống như nhân viên mới trong trạng thái mất trí nhớ và ngốc nghếch. Họ không nhớ bạn nói gì, không bao giờ học điều mới. Nhưng chúng ta có thể trang bị cho họ quy tắc, kỹ năng, công cụ và bộ nhớ dài hạn để mô phỏng. Họ có năng lực nhưng ngu ngốc, và rất dễ dạy. Tôi xem lỗi sai của họ là cơ hội để dạy mọi thứ tôi biết về kỹ thuật sâu sắc.
Vì khi thiếu sự chặt chẽ, agent sẽ nịnh hót làm mọi thứ để viết code bạn yêu cầu. Và nó viết được rất nhiều. Việc song song hóa ngây thơ chỉ khiến chúng viết code bẩn nhanh hơn.
Muốn nhanh thì phải đi sâu trước
Tôi tin việc điều phối agent có thể hiệu quả. Nhưng chúng ta cần đi theo chiều sâu.
Tôi đang open source pstack, bộ kỹ năng và nguyên tắc kỹ thuật cá nhân tôi dùng mỗi ngày để xây dựng @cursor_ai. Tôi phát triển các phiên bản đầu tiên trong dự án phụ và không ngừng hoàn thiện.
Tải tại đây: https://cursor.com/marketplace/cursor/pstack
Những kỹ năng này đã trở thành một trong những kỹ năng được đội Cursor sử dụng nhiều nhất, nên tôi rất hào hứng chia sẻ.
pstack dạy agent chặt chẽ hơn bằng cách dùng nhiều mô hình. Tôi đã thu thập mọi lỗi sai quan sát được và biến thành kỹ năng. Trái tim của plugin là /poteto-mode, một kỹ năng bậc cao giúp agent có sách lược đúng cho từng nhiệm vụ. Mục tiêu không phải số dòng code tối đa, mà ngược lại: tác động tối đa với ít code nhất.
Sự chặt chẽ được áp dụng bằng cách tiếp cận vấn đề như các kỹ sư dày dạn. Ví dụ, cách tốt để debug là tìm kiếm nhị phân trong không gian vấn đề. Bạn bắt đầu với giả thuyết về nguyên nhân, sau đó loại trừ có hệ thống để đến gần root cause. Nếu khó tái hiện, bạn có thể ép bug xảy ra hoặc thêm instrument logging để kiểm tra trạng thái chương trình.
Các bước này tạo thành sách lược cho agent debug triệt để thay vì đoán mò - điều chúng rất thích làm. pstack tích hợp nhiều kỹ năng và sách lược để bạn tiếp cận kỹ thuật phần mềm ở mức độ chặt chẽ này. Tôi hiện có sách lược cho:
- Tạo kỹ năng và đánh giá
- Làm việc tự động
- Sửa lỗi và điều tra runtime
- Phát triển tính năng
- Cân đối giao diện và tạo mẫu
- Và nhiều hơn nữa.
Khi cần sự chặt chẽ, hãy thêm /poteto-mode vào đầu prompt. Ví dụ:
Bạn cũng có thể gọi các kỹ năng khác theo yêu cầu:
- /how: bạn muốn giải thích cách một hệ thống con hoạt động.
- /why: bạn muốn biết tại sao thứ gì đó được xây dựng như vậy. Dùng MCP có sẵn để truy vấn song song các danh mục bằng chứng (source control, issue tracker, tài liệu dài, chat real-time, infra observability, error tracking, analytics warehouse).
- /architect: bạn sắp viết code qua ranh giới function và muốn xác định kiểu dữ liệu và cấu trúc trước.
- /arena: bạn muốn N nỗ lực song song cho cùng một việc, sau đó chọn phần tốt nhất.
- /interrogate: bạn muốn các mô hình khác nhau đánh giá đối kháng một thứ gì đó.
- /tdd: bạn đang sửa lỗi. Viết test thất bại trước, sau đó sửa.
- /unslop: bạn dọn dẹp bất kỳ văn bản AI nào. Làm cho chúng viết rõ ràng.
- /reflect: bạn muốn cải thiện kỹ năng liên tục sau các cuộc hội thoại dài.
- /figure-it-out: làm điều gì đó bất thường? Tạo sách lược chặt chẽ, có thể kiểm tra được.
- /show-me-your-work: bạn muốn dấu vết quyết định. Ghi lại quyết định vào file tsv để commit.
Và cuối cùng, bạn có thể tạo kỹ năng riêng với /automate-me. Nó khai thác transcript gần đây, tạo bản nháp kỹ năng từ cách bạn làm việc và định tuyến qua pstack.
pstack hoạt động với bất kỳ công cụ coding agent nào, nhưng đặc biệt tốt trong các công cụ đa mô hình như Cursor. Nhiều kỹ năng sử dụng quy trình đa mô hình để tận dụng điểm mạnh riêng. Đó là điều phối agent, nhưng áp dụng theo chiều sâu trước.
Nút thắt với agent là xác minh. Agent viết code nhanh, nhưng đảm bảo chính xác cực kỳ khó. Khi đến được đó, song song hóa agent thực sự - như nhà máy tối trong phần mềm - có thể khả thi.
Nhưng trước tiên, cần đi sâu và chặt chẽ. Tôi nghĩ chúng ta đạt được bằng cách tăng niềm tin.
Hãy dùng thử pstack và cho tôi biết bạn nghĩ gì.
Thiền và Nghệ thuật Bảo trì Phần mềm
Những kỹ năng này giúp tôi tự tin hơn khi viết code. Nhưng bảo trì code giờ là ác mộng khi agent viết mọi thứ. Bug, hiệu năng, yêu cầu tính năng vẫn mất thời gian. Và giờ còn nhiều code hơn!
Tôi tận dụng automations của Cursor tại Cursor. Chúng là cloud agent có thể lên lịch hoặc chạy khi có sự kiện như tin nhắn mới trong Slack. Một ví dụ là bot Benny của tôi. Tôi cho nó những kỹ năng giống pstack.
Benny đang trong quá trình hoàn thiện, nhưng tầm nhìn của tôi là tự động hóa càng nhiều quy trình bảo trì phần mềm càng tốt. Ý tưởng: nếu giờ chúng ta tự tin "one shot" vấn đề với pstack, với mức độ chắc chắn cao về chất lượng PR, chắc chắn chúng ta có thể tự động hóa phản hồi.
Nhà máy này bắt đầu với phân loại: thu thập thông tin từ nhân viên về báo cáo lỗi. Chúng tôi tự dùng Cursor rất nhiều nên nhận được nhiều phản hồi về bản phát hành thử nghiệm. Benny hiểu ảnh và video đính kèm, khám phá codebase bằng kỹ năng pstack, và trò chuyện với người báo cáo để biết các bước tái hiện.
Đây là phần quan trọng trong quy trình báo lỗi. Nếu không có bước tái hiện rõ ràng và hiểu biết về lỗi, agent chỉ có thể đoán giải pháp. Chúng ta cần cho chúng hiểu chính xác vị trí và cách lỗi xảy ra.
Sau phân loại, Benny tạo ticket với phát hiện từ code, lịch sử git về regression, Slack cho tin nhắn cùng lỗi, và Notion cho quyết định thiết kế: là bug hay được thiết kế như vậy?
Sau khi ticket được tạo, bot Benny khác tiếp nhận dùng kỹ năng /orchestrate.
Đầu tiên, nó thử tái hiện vấn đề qua computer use. Cloud Agent của Cursor có thể chạy chính Cursor trong cloud, tương tác với desktop, click và gửi input bàn phím. Nội bộ, nó dùng kỹ năng tôi tạo để điều khiển sản phẩm qua các giao thức như CDP.
Điều này cho phép chứng minh liệu báo cáo lỗi có thể tái hiện không. Nếu tái hiện nhất quán, nó cố gắng sửa. Nếu là vấn đề hiệu năng, Benny có thể chụp CPU trace và heap snapshot trước và sau. Các subplanner tạo thêm worker để xác minh bản sửa dùng kỹ năng pstack và kiểm tra với ticket.
Các worker khác quay video trước và sau, cuối cùng worker mở PR để review kèm video trong mô tả.
Mọi thứ vẫn đang phát triển và còn nhiều việc, nhưng tôi hào hứng với đội ngũ agent giúp sửa lỗi tự tin khi tôi ngủ hoặc làm việc khác. Mở rộng quy mô code review là lĩnh vực lớn, và Cursor sắp có tính năng thú vị để hỗ trợ.
Nhưng chìa khóa xây nhà máy phần mềm là niềm tin. Trừ khi bạn tin tưởng agent sở hữu vấn đề từ đầu đến cuối, bao gồm xác minh, bạn không thể tự động hóa. Khi tăng niềm tin bằng plugin như pstack giúp agent sâu hơn, bạn có thể giải quyết vấn đề tham vọng hơn. Cố song song hóa agent chưa đủ tin tưởng là lãng phí token và thêm code bẩn.
Cảm ơn vì đã đọc!
