AI tạo tác đã thay đổi sự nghiệp của tôi
Đúng vậy, tôi xin thú nhận. Nỗi xấu hổ thầm kín của tôi.
Tôi trở thành quản lý chỉ sau vài năm kinh nghiệm, và không lâu sau đó là giám đốc. Điều hành một đội ngũ 20 người có nghĩa là tôi dành toàn bộ thời gian để quản lý, và không có chút thời gian nào cho việc lập trình.
Tôi đã dành cả sự nghiệp của mình để ao ước rằng mình có thể “nhảy vào code” và giúp đỡ đội nhóm, nhưng mỗi lần mở IDE lên, tỷ lệ giữa công sức bỏ ra và tác động mang lại quá chênh lệch. Việc quản lý dự án vẫn tốt hơn cho tôi.
Khoảng 4 tháng trước, tôi bắt đầu "vibe-coding" hết tốc lực trên codebase chính của chúng tôi. Không phải các dự án phụ, cũng không phải các ứng dụng nội bộ dùng một lần rồi bỏ. Tôi bắt đầu vibe-coding trong một monorepo hàng triệu dòng lệnh, trên chính đoạn code điều khiển phi đội drone của chúng tôi.
Hai tháng đầu tiên tôi dành cho vibe-coding, và hai tháng tiếp theo tôi dành cho AI tạo tác. Về mặt số lượng code gửi lên, hiện tôi nằm trong top 5 người đóng góp nhiều nhất tại Skydio, gửi tới 10 pull request mỗi giờ. Những thay đổi code của tôi không phức tạp, nhưng chúng rất giá trị!
Hỡi các quản lý và giám đốc: các bạn có thể đóng góp vào code của đội mình NHIỀU hơn bạn nghĩ rất nhiều.
Mục đích của bài blog này là để giải thích vibe-coding và AI tạo tác là gì, và cách tôi đang áp dụng nó tại Skydio. Trong một bài viết tiếp theo, tôi sẽ đi sâu vào cách bạn có thể thiết lập điều này tại công ty của mình.
Vibe coding và AI tạo tác là gì?
Đây là câu hỏi phù hợp hơn cho Google, nhưng đây là câu trả lời nhanh.
Lập trình có AI hỗ trợ / Vibe Coding là lập trình cặp
Windsurf và Cursor giúp bạn đạt được trạng thái dòng chảy (flow) khi lập trình, nơi bạn chuyển đổi liền mạch giữa vai trò người cầm lái (driver) và người quan sát (observer) trong một quy trình lập trình cặp. Với vai trò người cầm lái, bạn viết code và AI đưa ra những gợi ý hữu ích. Với vai trò người quan sát, AI là người thực hiện thay đổi, và bạn chỉ cần xem lại code (code review), từng dòng một.
AI tạo tác giống như có một thực tập sinh
Trong mô hình tạo tác, bạn giao việc cho một thực tập sinh quá tham vọng. Bạn cung cấp càng nhiều ngữ cảnh cho agent, khả năng nó hoàn thành nhiệm vụ theo ý bạn càng cao. Rất giống một thực tập sinh.
Sự khác biệt chính giữa hai loại này là:
Vibe-coding là một quá trình chủ động với vòng lặp được tính bằng giây. AI tạo tác là một quá trình bị động với vòng lặp được tính bằng phút.
Trong phần tiếp theo của bài blog, tôi sẽ trình bày quá trình tăng tốc của mình từ vibe-coding ở tốc độ 0.5x lên AI tạo tác ở tốc độ 10x.
Vibe coding ở tốc độ 0.5x: chỉ là một gã với trình soạn thảo.
Mục tiêu ban đầu của tôi rất đơn giản: liệu tôi có thể giúp giải quyết một vài ticket dễ cho đội đang quá tải nhất của mình không?
Một lĩnh vực mà đội nhóm nói rằng tôi có thể giúp ích rất nhiều là các lỗi nhỏ về thiết kế (design nits) và lỗi giao diện người dùng (UI bug) không đòi hỏi kỹ năng của một kỹ sư toàn thời gian, nhưng vẫn ngốn hàng giờ đồng hồ. Những thứ như “thay đổi nội dung chữ trên trang này” hoặc “trang này trông kỳ lạ khi thu nhỏ cửa sổ”.
Lúc đó tôi đã cân nhắc các lựa chọn của mình: liệu tôi có thể thúc đẩy đội nhóm nhanh hơn bằng cách huấn luyện tích cực hơn (tức là quản lý vi mô), dọn dẹp hàng đợi Jira (tức là tự thỏa mãn của người quản lý), hay chỉ đơn giản là tự mình sửa lỗi? Hãy thử diệt bug xem sao. Lưu ý rằng tôi không biết (và vẫn không biết) TypeScript.
Lưu ý không gian dành cho Terminal + Code, điều này sẽ sớm thay đổi.
- Đầu tiên, tôi sẽ tìm kiếm thủ công đoạn code cần chỉnh sửa.
- Sau đó, tôi yêu cầu Windsurf (Cascade) thực hiện thay đổi.
- Cuối cùng, tôi xem lại trên trình duyệt và lặp lại nếu cần.
Hóa ra, backlog của chúng tôi có rất nhiều lỗi UX nhỏ mà không ai có thời gian để giải quyết. AI sẽ mất nhiều vòng để thực hiện đúng thay đổi và code thường cần chỉnh sửa sau khi review, nhưng dù vậy, tôi vẫn giải quyết xong hết ticket này đến ticket khác.
Tôi có nhanh hơn một lập trình viên không? Không.
Vibing ở tốc độ 1.5x: giải quyết vấn đề bằng 'vũ phu'
Bước đột phá đầu tiên của tôi: tại sao chỉ có 1 máy khi bạn có thể có 3?
Có một lần, tôi bị kẹt ở một bug trông có vẻ rất đơn giản, nhưng lại là một vấn đề gai góc nằm sâu trong Relay. UGH. Tôi thậm chí còn không thể nói cho bạn biết sự khác biệt giữa Redux và Relay, huống chi là tìm ra cách giải quyết. AI bị kẹt trong một vòng lặp tồi tệ:
Từ A -> B -> A -> B -> A -> B -> A ->B trong hơn một giờ.
Tôi không phải là người dễ dàng thừa nhận thất bại. Tôi sẽ sửa cái bug này. Sau khi cuộc trò chuyện kéo dài một giờ, AI đã bị kẹt một cách vô vọng. Ngữ cảnh của nó sâu đến nỗi nó từ chối thử các cách tiếp cận mới. Vì vậy, tôi đã thử một điều điên rồ: sẽ thế nào nếu tôi bắt đầu:
- 3 không gian làm việc Coder mới (máy phát triển từ xa)
- với 3 mô hình khác nhau (Gemini, Claude và GPT)
- với 3 prompt khác nhau
Tôi sẽ lần lượt kiểm tra và đưa ra phản hồi cho từng không gian làm việc, hy vọng rằng một trong số chúng sẽ sửa được lỗi. Về cơ bản, tôi đã 'tấn công DDoS' cái bug đó bằng sự lạc quan. Tôi không còn quan tâm đến code nữa. Tất cả những gì quan trọng là sửa được lỗi. Tôi nghĩ rằng nếu nó sửa được lỗi, tôi có thể dọn dẹp code sau. Sau một giờ, không gian làm việc thứ hai đã tìm ra giải pháp, và thế là xong: tôi đã gửi và hợp nhất code!
Điều này đã khởi đầu một làn sóng phát triển mới cho tôi: nếu điều này hiệu quả với 3 agent AI trên 1 vấn đề khó, tôi cũng có thể áp dụng 3 agent AI cho 3 vấn đề dễ. Giờ đây, tôi bắt đầu xử lý các bug, tăng tốc độ của mình lên gấp ba.
Tôi có nhanh hơn một lập trình viên không? Nhanh hơn một kỹ sư junior.
Vibe coding ở tốc độ 3x với 3 không gian làm việc
Bây giờ tôi đang 'cày' ticket như máy. Tôi đã nhờ trưởng phòng thiết kế viết cho tôi một danh sách tất cả các lỗi vặt về giao diện người dùng (UI jank) mà anh ấy gặp phải, và tôi sẽ xử lý chúng nhanh hơn cả tốc độ anh ấy viết ra. Tôi sẽ luôn mở 3 Windsurf cùng một lúc, kiểm tra, đưa ra phản hồi và tiếp tục. Nếu một Windsurf nào đó bị kẹt, tôi sẽ nhân đôi/nhân ba nỗ lực bằng cách giao cùng một vấn đề cho Windsurf tiếp theo. Thách thức lớn nhất tiếp theo là giảm thời gian dành cho chu kỳ thay đổi/kiểm tra. Tôi cần AI thực hiện thay đổi chính xác nhanh hơn.
Giới thiệu: Tệp ngữ cảnh (ví dụ: Windsurf Rules)
Skydio làm việc trên một monorepo lớn duy nhất, nó không hẳn là một codebase mà giống một cuộc khai quật khảo cổ về lịch sử 10 năm qua của Skydio hơn. Các bản di chuyển dở dang, code cổ xưa và các thực tập sinh đã rải rác khắp repo những anti-pattern và thông tin sai lệch. Khi AI chỉ có đầu vào của tôi và các đoạn code khác làm ngữ cảnh, code mà nó viết ra có thể khớp mẫu với code của một thực tập sinh từ nhiều năm trước. Thật tệ.
Để có kết quả tốt hơn, tôi cần cung cấp cho AI các quy tắc lập trình tốt nhất (best practices) của chúng tôi và các anti-pattern cần tránh. Tôi cần cho nó biết những lệnh nào nó có thể sử dụng để chạy unit test trước khi đẩy lên CI. Đối với tôi, đó là Windsurf Rules, chỉ là một bộ các tệp Markdown bạn đặt trong .windsurf/rules/my-practices.md. Hóa ra, siêu đơn giản.
Bạn có thể hình dung các quy tắc chỉ là những prompt được lưu sẵn và tự động đưa vào hệ thống. Ví dụ, nếu prompt của bạn là chỉnh sửa TypeScript cho ứng dụng frontend, bạn có thể có một tệp tương ứng là .windsurf/rules/typescript-best-practices.md. Nội dung trong hướng dẫn thực hành tốt nhất này về cơ bản sẽ được tự động chèn vào sau prompt của bạn.
Đây là cách tôi tiếp cận việc viết tệp này:
Lặp đi lặp lại việc cải thiện ngữ cảnh là điều làm cho nó hiệu quả
Về cơ bản, trong khi giải quyết các ticket, tôi cũng đồng thời làm việc với ngữ cảnh cung cấp năng lượng cho AI. Khi nó gặp khó khăn trong việc giải quyết một vấn đề, tôi sẽ hỏi nó sau đó rằng thông tin chi tiết nào đã mở khóa giải pháp cuối cùng. Sau đó, tôi sẽ chỉnh sửa tệp ngữ cảnh, bắt đầu một không gian làm việc mới (hoàn toàn sạch), và đưa cho nó cùng một prompt. Nếu AI giải quyết dễ dàng trong lần chạy này, thì những thay đổi trong tệp ngữ cảnh của tôi đã có tác dụng như mong muốn.
💡** Điểm mấu chốt cho các nhà quản lý: AI không tự động giải quyết vấn đề của bạn*. Bạn phải đầu tư vào công cụ.*
Đến thời điểm này, tôi đã giải quyết đủ nhiều ticket đến mức các lập trình viên khác nhận thấy điều gì đang xảy ra, và họ bắt đầu hỏi nhiều hơn về các quy trình làm việc với AI.
Tôi có nhanh hơn một lập trình viên không? Nhanh hơn một kỹ sư senior đối với các công việc đơn giản.
Vibe coding ở tốc độ 10x với 10 không gian làm việc
Để tăng năng suất của mình lên gấp ba lần nữa, tôi cần loại bỏ yếu tố chậm nhất ra khỏi phương trình: chính tôi. Tôi có thể duy trì khoảng 3 Windsurf hoạt động cùng lúc, nhưng nó chiếm hết sự chú ý của tôi. Nếu tôi yêu cầu nó thực hiện một tác vụ dài, tôi phải luôn mở Windsurf và xác nhận các bước tiếp theo sau mỗi vài phút. Tôi cần tự động hóa những việc sau:
- Tự động thiết lập không gian làm việc và máy chủ phát triển.
- Đưa ra phản hồi cơ bản về một thay đổi UX
- Soạn thảo commit và PR trên GitHub.
Giới thiệu Coder Tasks
Coder Tasks là một điểm khởi đầu mới cho AI tạo tác
Coder Tasks là các không gian làm việc tự động, tập trung vào việc tự động hóa luồng công việc từ “prompt” → agent AI thực thi tác vụ. Nếu bạn thiết lập để nó tự động đẩy code lên GitHub, bạn có thể song song hóa nhiều tác vụ và không cần tham gia lại cho đến khi pull request sẵn sàng để review.
Trong mô hình này, tôi không lãng phí thời gian chờ đợi giữa các bước.
Việc tác vụ kéo dài vài giờ cũng không thực sự quan trọng, vì tôi không tham gia tích cực cho đến khi AI hoàn thành thay đổi của nó. Ngoài ra, lưu ý rằng việc viết một prompt và kiểm tra bản xem trước không đòi hỏi kỹ năng kỹ thuật, điều đó có nghĩa là:
AI tạo tác cho phép mọi người ở mọi vai trò đều có thể đóng góp để làm cho sản phẩm của bạn tốt hơn.
Các nhà thiết kế có thể gửi các bản sửa lỗi về màu sắc và định dạng. Các quản lý sản phẩm có thể sửa lỗi chính tả, câu chữ. Và đội kiểm tra bay của Skydio có thể gửi các bản sửa lỗi cùng với các bug mà họ tìm thấy.
MCP là mảnh ghép cuối cùng
MCP chỉ là một cách nói hoa mỹ của “Tích hợp AI”, trong đó “MCP” là tiêu chuẩn kỹ thuật mà Anthropic đã thuyết phục thế giới tuân theo. Nó cho phép GitHub (công ty) tạo ra một tích hợp duy nhất hoạt động cho tất cả các agent AI. Đối với tôi, có 2 tích hợp MCP đã tạo ra sự khác biệt to lớn: GitHub (tương tác với Issue và Pull Request) và Playwright (tương tác với trình duyệt)
Màu xanh lá cây đại diện cho giá trị gia tăng từ các MCP GitHub và Playwright so với quy trình làm việc cũ của tôi.
Với MCP GitHub, bạn mở khóa khả năng đọc từ GitHub Issues. Điều này cho phép bạn đơn giản hóa prompt của mình thành: “Sửa <issue> này, đồng thời ghi nhớ <ngữ cảnh bổ sung>.” Phần quan trọng hơn là nó có thể tự động tạo Pull Request. Tại Skydio, điều này cho phép cả các kiểm tra CI dài chạy, và nó kích hoạt bản xem trước Vercel của chúng tôi. Điều này có nghĩa là tôi có thể đợi cho đến khi bản xem trước Vercel sẵn sàng trước khi tham gia trở lại. Luồng làm việc của tôi trở thành:
- [Bước 1]
- [Bước 2]
- [Bước 3]
- [Bước 4]
Với luồng làm việc này, tôi bị giới hạn bởi khả năng nghĩ ra tác vụ tiếp theo hơn là bởi chính các tác vụ đó! Tuy nhiên, cải tiến đột phá tiếp theo là cải thiện khả năng lặp lại của AI mà không cần đến tôi…
Với MCP Playwright, AI có thể điều hướng xung quanh bất kỳ trang web nào, bao gồm cả stack phát triển của bạn! Điều này có nghĩa là AI có thể được yêu cầu thực hiện những việc sau:
- [Bước 1]
- [Bước 2]
- [Bước 3]
- [Bước 4]
Hãy dừng lại và suy nghĩ xem điều này mạnh mẽ đến mức nào. Khi chu kỳ phản hồi phụ thuộc vào câu trả lời của tôi, tôi chỉ có thể duy trì 3 Windsurf hoạt động cùng lúc mà không cảm thấy quá tải. Tuy nhiên, khi AI có thể tự lặp lại với chính nó, giới hạn sẽ cao hơn nhiều. Tôi có thể tạo ra hàng chục tác vụ đồng thời, miễn là tôi có thể cho AI biết cách xác minh thay đổi của nó.
Chìa khóa để thành công với AI tạo tác là tạo ra một chu kỳ phản hồi không liên quan đến phản ứng của con người.
Đây là lúc Skydio mở toang cánh cửa. Năng lượng kích hoạt cần thiết để đưa ra một prompt cho một Coder Task gần như bằng không. Tôi bắt đầu chạy 10 tác vụ cùng một lúc. Đây là một ví dụ (có thật):
- Một lập trình viên senior đã soạn thảo một component mới để làm tiêu chuẩn cho việc lọc dữ liệu trong bảng. Nó đòi hỏi cả một truy vấn GraphQL mới và thay thế một component ở frontend.
- Họ đã di chuyển 2 bộ lọc để làm ví dụ.
- Sau đó, tôi đã giao hơn một chục tác vụ Coder để hoàn thành toàn bộ việc di chuyển trên toàn bộ ứng dụng của chúng tôi trong một ngày duy nhất.
Đây là lúc tôi đạt đến điểm bùng phát của AI tạo tác. Thay vì tôi tự mình thúc đẩy nó, nó bắt đầu có sức sống của riêng mình. Tại thời điểm viết bài này, Claude Code hiện là nhà phát triển số hai tại Skydio về tốc độ commit! Bầu trời là giới hạn!
Trọng tâm tiếp theo: khiến AI thực hiện các quy trình làm việc nâng cao!
Tổng kết
Đối với số ít các bạn đã đọc đến cuối bài viết này, tôi rất cảm kích! Đây là một hành trình mà tôi tự hào. Sử dụng AI tạo tác để sản xuất hàng loạt pull request là điều mà tôi đã đề xuất với Skydio từ đầu năm, nhưng có rất nhiều viên gạch nền tảng cần được đặt trước trên con đường đó.
Sự chuyển đổi tại Skydio thật đáng kinh ngạc, và backlog của đội tôi chưa bao giờ sạch sẽ hơn thế. Nhưng điều thú vị nhất là được thấy những người không phải là lập trình viên đóng góp trực tiếp vào sản phẩm.
Cảm ơn bạn đã đọc câu chuyện của tôi!
Theo dõi trên X