- Sự phát triển của AI đang chuyển đổi công việc của kỹ sư phần mềm từ viết mã trực tiếp sang tập trung vào lập kế hoạch và đánh giá mã do AI tạo ra.
- Để tối ưu hóa hiệu quả, cần ưu tiên phương pháp dựa trên kế hoạch chi tiết ngay từ đầu, giảm thiểu các vòng lặp đánh giá liên tục, đặc biệt với các tác vụ có tính chất ổn định và ít trạng thái.
- Khi các tác nhân AI chạy lâu hơn (vượt quá 5 phút), các nhà phát triển cần thay đổi hành vi làm việc, áp dụng các giao diện mới cho phép song song hóa và quản lý nhiều luồng công việc để duy trì năng suất.
Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban
- Chuyển đổi công việc: Công việc chính của kỹ sư phần mềm đang dịch chuyển từ viết mã sang lập kế hoạch và đánh giá mã do AI tạo ra, với thời gian viết mã trực tiếp giảm đáng kể nhờ các công cụ AI.
- Phương pháp dựa trên kế hoạch ưu việt: Dành thời gian lập kế hoạch chi tiết ban đầu giúp giảm đáng kể thời gian đánh giá sau này, dẫn đến mã chất lượng cao hơn và ít lỗi hơn từ các mô hình AI.
- Lựa chọn phương pháp theo ngữ cảnh: Phát triển tính năng front-end có thể đòi hỏi nhiều vòng lặp đánh giá hơn do tính phụ thuộc trạng thái và tương tác phức tạp, trong khi back-end, tái cấu trúc và di chuyển phù hợp hơn với phương pháp lập kế hoạch (phát triển hướng kiểm thử).
- Thời gian chạy của tác nhân AI kéo dài: Các tác nhân AI đang dần chạy lâu hơn (từ vài giây lên đến 5-10 phút, và có thể lâu hơn) do khả năng gọi công cụ, kiểm tra kiểu và chạy thử nghiệm được cải thiện.
- Yêu cầu giao diện và quy trình mới: Để quản lý các tác vụ AI chạy lâu, cần có các giao diện mới hỗ trợ song song hóa nhiều luồng công việc, giảm thiểu việc chuyển đổi ngữ cảnh liên tục của con người.
- Tối đa hóa thời gian tác nhân hoạt động: Công cụ lý tưởng nên được thiết kế để tác nhân AI có thể hoạt động càng lâu càng tốt mà không cần sự can thiệp của con người, sau đó mới trả quyền kiểm soát lại để con người đánh giá.
- Vai trò con người trong QA và Code Review: Dù AI có tiến bộ đến đâu, con người vẫn sẽ đóng vai trò quan trọng trong việc đảm bảo chất lượng (QA) và đánh giá mã (code review) trước khi triển khai, đặc biệt với các hệ thống sản xuất.
- Thách thức kinh doanh trong thị trường AI DevTools: Việc kiếm tiền từ các công cụ hỗ trợ phát triển bằng AI đang gặp khó khăn, đặc biệt đối với các công ty không tập trung vào khách hàng doanh nghiệp hoặc mô hình bán lại mã thông báo.
AI— Trí tuệ nhân tạoAgent— tác nhânCode— mãPlan-based approach— phương pháp dựa trên kế hoạchEvaluation-intensive— đánh giá chuyên sâuEdge case— trường hợp biênTool calling— gọi công cụQA— đảm bảo chất lượng / kiểm soát chất lượngParallelize— song song hóaCode review— đánh giá mãPull request (PR)— yêu cầu kéo (PR)Enterprise— doanh nghiệpReselling tokens— bán lại mã thông báo
Giới thiệu & Người trình bày
[Nhạc] Mic đã bật chưa? Vâng, mic đã bật rồi. Mọi người khỏe không? Woo! [transcript bị gián đoạn] Tuyệt vời. Vâng, chúng ta hãy bắt đầu. Được rồi. À, đây là... Vì vậy, tiêu đề của bài nói này là về lập kế hoạch và đánh giá, nhưng tôi nghĩ điểm mấu chốt thực sự đằng sau nó là chúng ta sẽ làm gì khi Trí tuệ nhân tạo (AI) ngày càng trở nên xuất sắc hơn. Tôi là Louie, người sáng lập một công ty khởi nghiệp tên là Vibe Canvas. Tôi cũng đã thành lập chi nhánh AI Tinkers tại London, một cộng đồng tuyệt vời nếu bạn ở London và đang tìm kiếm các sự kiện. Và bạn nên lắng nghe tôi vì tôi đã đạt được một số thành tựu như đứng đầu bảng xếp hạng đã xác minh của SweeBench trước cả OpenAI. Điều này đã cách đây vài tháng rồi, nhưng dù sao, bạn biết đấy, luôn tốt khi biết rằng những người đang nói đã thực hiện một số nghiên cứu trong lĩnh vực này.
Chương trình nghị sự
Chương trình nghị sự hôm nay, thưa các bạn, là tôi sẽ hướng dẫn các bạn lý do tại sao tôi đi đến kết luận rằng về cơ bản, công việc cả ngày của tất cả các kỹ sư phần mềm sẽ chỉ là lập kế hoạch và đánh giá. Tôi sẽ nói về cách cân bằng công việc đó nếu đó là những gì bạn làm cả ngày. Tôi sẽ nói về thời gian hoạt động và cách các tác nhân đang chạy lâu hơn, và điều đó thay đổi hành vi của công việc như thế nào. Và cuối cùng, chúng ta sẽ đóng cửa công ty của tôi. [Khụt khịt] Chúng ta sẽ nói về điều đó sau. Vậy, hãy bắt đầu nào.
Sự thay đổi: Mọi thứ đều là Lập kế hoạch và Đánh giá
Mọi thứ đều là lập kế hoạch và đánh giá. Vậy, công việc mà chúng ta, những kỹ sư phần mềm, làm là gì? Có ai ở đây không phải là kỹ sư phần mềm không? Vâng. Được, hầu hết mọi người. Chúng ta lập kế hoạch, chúng ta viết code, chúng ta đánh giá code và chúng ta đánh giá code của người khác. Đại khái là công việc chúng ta làm.
Tỷ lệ công việc cho đến khi GitHub Copilot xuất hiện đối với tôi đại khái là như thế này: Tôi biết nó phụ thuộc vào việc bạn làm việc ở công ty lớn hay công ty nhỏ và những thứ tương tự, nhưng phần lớn là viết code, và so với đó, phần lập kế hoạch và đánh giá code thì không nhiều lắm. Và điều chúng ta thấy là theo thời gian, với những thứ như phiên bản đầu tiên của GitHub Copilot, phần viết code bắt đầu thu hẹp lại. Bạn biết đấy, ChatGPT ra đời, đột nhiên bạn có thể tạo ra các hàm và dán chúng vào, và sau đó Cursor – không phải Cursor hiện tại mà là phiên bản gốc của Cursor – xuất hiện, và nó có thể hoàn thành cả một trang code. Và rồi bạn có Claude Code, và bạn sẽ nghĩ, "Wow, mình thực sự không viết code nhiều nữa."
Vì vậy, nó đặt ra một câu hỏi thú vị: Nếu trước đây chúng ta dành 4 giờ mỗi ngày để viết code, liệu điều đó có nghĩa là tôi sẽ có lại 4 giờ đó nếu tôi không thực hiện bất kỳ công việc viết code thực tế nào không? Câu trả lời, tất nhiên, là không. Nó đã dịch chuyển công việc. Công việc hoặc thời gian trước đây dành cho việc viết code đã dịch chuyển. Nó đã dịch chuyển sang lập kế hoạch và đánh giá. Tôi nghĩ đó là một yếu tố thúc đẩy. Bạn có thể hoàn thành nhiều việc hơn trong ngày, nhưng có lẽ là bạn có 20 phút rảnh rỗi cho mỗi nửa giờ bạn dành cho việc viết code, và một khoảng thời gian khác đã chuyển sang lập kế hoạch và đánh giá.
Vì vậy, tôi muốn nói về điều đó. Cách làm việc mới này là gì? Và tôi nghĩ về cơ bản có hai phương pháp mà mọi người áp dụng. Tôi sẽ không đi sâu vào chi tiết về, bạn biết đấy, specs hay Playwright MCPs hay những thứ tương tự. Tôi nghĩ có rất nhiều bài nói chuyện hấp dẫn về điều đó tại sự kiện này. Tôi chỉ muốn khái quát hóa những gì chúng ta đang nói ở đây hôm nay.
Hai phương pháp tiếp cận: Dựa trên kế hoạch và Đánh giá chuyên sâu
Phương pháp đầu tiên là phương pháp dựa trên kế hoạch (plan-based approach). Đây là nơi bạn dành nhiều thời gian ban đầu để lập kế hoạch cho công việc mà bạn muốn một tác nhân viết code thực hiện. Những dấu hiệu cho thấy bạn đang thực hiện loại công việc này có lẽ sẽ trông giống như bạn đang viết một tài liệu kế hoạch rất toàn diện, một tệp markdown. Có thể bạn đang sử dụng một trong các framework đặc tả này. Bạn đang thẩm vấn. Bạn biết đấy, tôi đã thấy một số điều thú vị khi mô hình liên tục hỏi bạn cho đến khi nó hoàn toàn cạn kiệt tất cả các câu hỏi có thể có về công việc cần được thực hiện.
Lợi ích của điều này, tất nhiên, là bạn về cơ bản sẽ dành ít thời gian hơn để đánh giá công việc đó vì bạn đã đầu tư thời gian từ đầu để loại bỏ các edge case, cung cấp cho các mô hình càng nhiều thông tin càng tốt về công việc bạn đang cố gắng thực hiện. Kết quả của việc đó sẽ là các mô hình ít có khả năng lỗi hơn, và bạn sẽ nhận được đầu ra tốt hơn, và có lẽ, ít vòng đánh giá hơn. Nhược điểm là bạn phải dành nhiều thời gian hơn để lập kế hoạch, nhưng điều đó là hiển nhiên, phải không?
Cách khác để thực hiện điều này, cách lớn khác để làm việc với AI là bạn không xác định một kế hoạch rất chi tiết, mà thay vào đó, bạn để nó chạy, và sau đó bạn sẽ dành nhiều thời gian hơn để đánh giá công việc đó. Vì vậy, bạn biết đấy, lợi ích của điều này là bạn có thể làm việc một cách ngẫu hứng, kiểu như, "À, hãy thêm một contact form vào trang web." Và sau đó, bạn biết đấy, điều bạn phải làm là bạn sẽ phải điều chỉnh qua lại vài lần để sửa các kiểu dáng, tìm hiểu mọi thứ.
Tôi sẽ nói rằng nếu bạn coi thời gian của con người là điều có giá trị, và bạn có một lựa chọn, bạn luôn muốn thực hiện hành vi đầu tiên trong số các hành vi này, về cơ bản là phương pháp lập kế hoạch, bởi vì nó sẽ giúp bạn tiết kiệm rất nhiều thời gian. Rất tốn thời gian khi phải chuyển đổi qua lại với một tác nhân đang cung cấp cho bạn một phần công việc chưa hoàn thành, và bạn liên tục phải đánh giá nó.
Các chế độ làm việc và Ngữ cảnh
Tôi nghĩ một cách khác để phân loại các chế độ làm việc, nơi một là lập kế hoạch và một là đánh giá, là nghĩ về loại công việc bạn đang làm. Và tôi nghĩ việc phát triển tính năng (feature development) thực sự rất khác so với việc di chuyển (migrations) và công việc bảo trì (maintenance). Và front-end rất khác với back-end. Tôi đã cố gắng suy nghĩ về điều này trước buổi nói chuyện, và đây là ma trận tôi đã đưa ra, nơi về cơ bản, nếu bạn đang làm việc trên front-end và bạn đang phát triển tính năng, về cơ bản là không thể thực sự đặc tả mọi thứ ra. Có quá nhiều edge case và, bạn biết đấy, front-end rất phụ thuộc vào trạng thái (stateful). Có các tương tác, hoạt ảnh, kiểu dáng, có chức năng. Và vì vậy, cá nhân tôi, tôi thấy tốt hơn nhiều khi ở trong vòng lặp với một tác nhân viết code. Đó là hành vi thứ hai trong số những hành vi mà chúng ta đã nói đến.
Nhưng đối với mọi thứ khác, tôi nghĩ thực sự có thể thiên về lập kế hoạch. Vì vậy, đối với phát triển tính năng back-end, bạn gần như có thể thực hiện phát triển hướng kiểm thử (test-driven development). Và đối với bất kỳ thứ gì như tái cấu trúc (refactoring) và dựa trên di chuyển (migration-based), bạn chắc chắn có thể làm điều đó, và bạn không nên ở trong vòng lặp với bất kỳ công việc nào trong số đó. Tất cả những điều đó nên là phát triển hướng kiểm thử.
Vì vậy, tôi đoán nếu bạn phải tóm tắt bài trình bày dài dòng này thành một câu, thì đó sẽ là: "Dành 5 phút lập kế hoạch giúp bạn tiết kiệm 30 phút đánh giá code do AI tạo ra." Và đó về cơ bản là điều cốt lõi.
Tác nhân chạy lâu hơn và thay đổi hành vi
Điều khác mà tôi nghĩ khá thú vị để xem xét là cách mọi thứ đang chạy lâu hơn. Vì vậy, khi các tác nhân viết code trở nên có khả năng AI hơn, khi các mô hình tốt hơn, khi tool calling cải thiện, bạn chuyển từ việc gọi một tập hợp rất nhỏ các công cụ sang việc hiện tại, các CLI viết code có thể gọi một loạt lớn các công cụ và thực hiện kiểm thử và những thứ tương tự. Kết quả của điều đó là mỗi khi bạn gửi một lời nhắc, bạn sẽ phải đợi lâu hơn trước khi nó quay lại với bạn và nói, "Này Louie, đã đến lúc bạn phải làm gì đó."
Để minh họa điều này, bạn biết đấy, hãy nghĩ lại về GitHub Copilot. Nó hoàn thành một dòng code duy nhất, và mất vài giây. Sau đó bạn có Cursor gốc hoàn thành một tệp duy nhất, và điều đó chạy trong, bạn biết đấy, 30 giây. Và sau đó bạn có Claude Code, mà, bạn biết đấy, năm ngoái có thể chạy trong một hoặc hai phút, và năm nay tôi đã nhận được một số kết quả khá tốt với các lần thực thi 5 hoặc 10 phút. Và điều đó sẽ tiếp tục bởi vì về cơ bản, chúng ta đã chuyển từ việc bạn yêu cầu AI làm gì đó và nó chỉ phản hồi, sang AI chạy type checker sang AI kiểm thử sự thay đổi của nó.
Ý tôi là, đây là biên giới của mọi thứ. Và những điều này tốn ngày càng nhiều thời gian. Chỉ trả về code thì rất nhanh. Chạy type checker chậm hơn một chút. Chạy Playwright MCP chậm hơn một bậc độ lớn so với bất kỳ điều nào trong số đó. Nhưng điều đó đáng làm bởi vì, bạn biết đấy, điều bạn đang cố gắng tối đa hóa, một lần nữa, là lượng thời gian bạn dành – hoặc tối thiểu hóa, đúng hơn – là lượng thời gian bạn dành để làm việc với tác nhân. Vì vậy, nếu bạn có thể đạt được độ chính xác cao hơn bằng cách chờ đợi lâu hơn, thì đó là một sự đánh đổi đáng giá.
Và đây có lẽ là nơi biên giới đang ở: nếu tôi phải dự đoán chúng ta sẽ ở đâu trong 9 tháng tới, tôi sẽ nói rằng về cơ bản, AI bắt đầu có khả năng QA công việc front-end, và đó sẽ là một bước đột phá lớn. Bạn thấy một số bản demo thú vị về điều này trên Twitter với, bạn biết đấy, Chrome hoặc Playwright MCP nhấp chuột xung quanh mọi thứ. Thực tế là tôi chưa gặp một người nào thực sự làm điều này trong quá trình phát triển chính thống của họ. Nhưng tôi thực sự rất hào hứng với nó, và tôi nghĩ nó sẽ là bước đột phá lớn tiếp theo, nơi về cơ bản, hầu hết các cuộc trao đổi qua lại mà bạn thực hiện với một mô hình sẽ chỉ được thực hiện bởi chính mô hình đó vì nó sẽ có thể thực sự chạy dự án của bạn, nhấp chuột xung quanh và tìm lỗi, và đảm bảo nó đã hoàn thành.
Nhưng điều này đặt ra một câu hỏi thú vị, đó là: điều gì xảy ra khi thời gian trung bình mà một tác nhân chạy vượt quá, ví dụ, 5 phút? Bởi vì tôi nghĩ 5 phút là khoảng thời gian bạn có thể ngồi đó và đợi một điều gì đó, xem nhật ký, có lẽ thực tế hơn là lướt Twitter, những thứ như vậy. Và khi chúng ta vượt qua mốc 5 phút đó, bạn phải thay đổi hành vi của mình. Bạn biết đấy, hãy tưởng tượng những thứ này sẽ mất 20 phút để chạy. Bạn sẽ không ngồi đó 20 phút để xem nhật ký tác nhân. Bạn sẽ phải suy nghĩ về việc viết code và toàn bộ công việc của một nhà phát triển phần mềm theo một cách rất, rất khác.
Song song hóa và Giao diện mới
Điều này tôi chắc chắn mọi người đều đã thấy, đó là khái niệm tối ưu hóa terminal kiểu này, nơi bạn về cơ bản là song song hóa, phải không? Bạn chạy nhiều tác vụ này cùng một lúc. Giả sử mỗi tác vụ mất 10 phút để chạy. Vì vậy, cách bạn khắc phục vấn đề chờ đợi là bạn có nhiều tác vụ đang chạy cùng một lúc. Ngay sau khi bạn hoàn thành, chẳng hạn, việc đánh giá một phần công việc, một phần khác đã hoàn thành và bạn có thể chuyển sang phần đó.
Và đó về cơ bản là những gì chúng tôi bắt đầu làm. Đây là dự án chúng tôi đã bắt đầu cách đây khoảng một năm, được gọi là Vibe Kanban. Và về cơ bản, nó bắt đầu như một nỗ lực để giúp việc song song hóa các tác nhân trở nên rất dễ dàng. Chúng tôi đã xây dựng một số thứ hay ho. Có một sidebar nơi bạn có thể tạo nhiều không gian làm việc (workspaces) chạy bất kỳ tác nhân viết code nào, như Codex, Cool Code, những thứ tương tự. Khi bạn muốn đánh giá code, bạn sẽ nhận được các diffs. Nếu bạn muốn nhận xét về điều gì đó, bạn có thể làm điều đó giống như cách GitHub làm. Nếu bạn muốn xem trước điều gì đó hoặc, bạn biết đấy, nhấp vào điều gì đó và kiểu như, "À, thực sự làm cho cái này lớn hơn một chút hoặc cái kia nhỏ hơn một chút," bạn cũng có thể làm điều đó.
Và bạn có thể đã thấy tất cả những thứ này trước đây, nhưng bạn có thể chưa thấy những thứ này bắt đầu sớm như ngày 14 tháng 6 năm 2025. Chúng tôi đã làm điều đó trước, tôi thề!
Vậy, những cân nhắc. Tôi nghĩ rằng hành vi của con người sẽ thay đổi vì các tác nhân sẽ vượt qua ngưỡng 5 phút này. Và ai biết được, điều đó có thể tiếp tục. Bạn có thể kết thúc việc vượt qua ngưỡng một giờ. Vì vậy, chúng ta cần các giao diện mới để làm cho công việc này trở nên tuyệt vời. Bởi vì nếu bạn cố gắng làm điều đó bằng cách sử dụng các công cụ hiện có, nó sẽ khá tệ. Bạn phải nhảy vòng quanh, đánh giá code ở một nơi, xem trước mọi thứ ở một nơi khác.
Khung làm việc cho Tác nhân AI hỗ trợ Lập trình viên
Nếu tôi có một danh sách mong muốn về một công cụ tác nhân AI hỗ trợ mã hóa tối ưu cho các nhà phát triển phần mềm, nó sẽ cơ bản phải chấp nhận thực tế rằng tôi phải quản lý nhiều luồng công việc cùng một lúc – điều mà hầu hết các nhà phát triển phần mềm chưa từng phải làm. Họ thường chỉ cần tập trung sâu vào một phần công việc duy nhất. Vì vậy, công cụ này sẽ tập trung vào việc "tối đa hóa sự tập trung" (focus maxing) – tôi không biết đây có phải là một từ hay không, nhưng tôi muốn định nghĩa nó ngay tại đây. Nó nên chấp nhận thực tế rằng bạn không thể kéo con người ra khỏi một việc rồi lại đưa họ quay trở lại một việc khác sau mỗi 30 giây, vì điều đó làm "cháy" não bộ và đó không phải là một cách sống.
Vì vậy, công cụ nên được xây dựng xung quanh việc khai thác tối đa khả năng của con người để một tác nhân có thể hoạt động càng lâu càng tốt, sau đó "trả lại" quyền kiểm soát cho con người. Điều này trái ngược với việc khuyến khích các mô hình mà bạn liên tục phải "nhảy" vào, "nhảy" ra để nắm bắt lại ngữ cảnh của những gì một tác nhân cụ thể đang làm. Nó nên giúp bạn viết tác vụ và lên kế hoạch mọi thứ, hiển nhiên. Nó cũng nên giúp bạn kiểm soát chất lượng (QA) công việc, vì đó sẽ là phần lớn công việc của con người. Và nó nên giúp bạn thực hiện đánh giá mã (code review). Tôi nghĩ rõ ràng là đánh giá mã hiện nay đã được thực hiện nhiều với Trí tuệ nhân tạo, nhưng rất ít công ty có tiền trong tay sẽ thực sự triển khai những sản phẩm được viết mã hoàn toàn bằng Trí tuệ nhân tạo mà không kiểm tra mã. Vì vậy, đọc mã có lẽ là điều mà hầu hết mọi người trong căn phòng này vẫn sẽ phải làm. Cuối cùng, nó nên hỗ trợ dẫn dắt sự thay đổi cho đến khi được triển khai – đây là một khía cạnh mới nổi. Nói một cách đơn giản nhất, nó giống như việc giám sát các yêu cầu kéo (pull request) trên GitHub, tìm kiếm các bình luận và tự động phản ứng với chúng. Rất nhiều công việc hành chính liên quan đến việc chuyển đổi từ "tôi đã hoàn thành nhiệm vụ" sang "tôi đã triển khai nhiệm vụ" chỉ đơn thuần là theo dõi và phản ứng với các bình luận.
Quyết định dừng hoạt động công ty
Tôi đã viết bài nói chuyện này và gửi nó vài tuần trước. Đến thứ Ba vừa rồi, tôi quyết định đóng cửa công ty. [tiếng cười khẩy] Về cơ bản, có một phần trong bài nói chuyện này là về việc tôi sẽ kể cho bạn nghe nhiều hơn về Vibe Kanban và cố gắng bán nó cho bạn, nhưng điều đó sẽ không xảy ra nữa vì công ty hiện đang đóng cửa. Vì vậy, thay vào đó, tôi nghĩ chúng ta có thể cùng nhau đóng cửa công ty. Tôi vẫn chưa chính thức thông báo điều này.
[tiếng vỗ tay]
Được rồi, và chúng ta sẽ làm điều đó bằng cách sử dụng Vibe Kanban, tất nhiên rồi. Đó phải là cách làm.
Thực hiện đóng cửa công ty bằng Vibe Kanban
Được rồi, vậy thì, làm ơn hãy thêm một bài đăng blog vào trang web với nội dung này. [tiếng rên rỉ và cười khẩy] Và tôi đã viết trước lời nhắn buồn bã đó. Được rồi, chúng ta đã có trang web Vibe Kanban. Được rồi, nó sẽ tiến hành làm điều đó. Tôi có thể cho bạn một chuyến tham quan nhỏ về thứ này.
Nó đang chạy một script cài đặt. Nó đã tạo một cây làm việc Git (Git work tree). Nó đã chạy một script cài đặt trong cây làm việc để cài đặt các phần phụ thuộc (dependencies) cho trang web của chúng tôi. Và khi hoàn tất, nó sẽ tiến hành chạy bất kỳ tác nhân nào bạn đã chọn. Tôi sử dụng Codex hầu hết thời gian, nhưng nó hỗ trợ tám trong số các mô hình phổ biến nhất. Và nó sẽ cố gắng tìm cách thực hiện điều đó.
Nguyên nhân và cảm xúc khi đóng cửa công ty
Còn điều gì hay ho nữa không? Bạn có buồn không? Tôi có buồn không? Tôi nghĩ tôi đã suy nghĩ về nó quá nhiều nên tôi cảm thấy khá nhẹ nhõm. Khi bạn điều hành một công ty trong vài năm, bạn có một trách nhiệm lớn lao đối với nhân viên và nhà đầu tư, và tất cả những thứ khác. Tôi không biết, tôi cảm thấy như một gánh nặng đã được cất bỏ.
Chúng ta cũng có thể nói về lý do tại sao chúng tôi đóng cửa công ty. Chúng tôi có rất nhiều người dùng, 30.000 người dùng hoạt động hàng tháng (monthly active users) và 25.000 lượt đánh dấu sao trên GitHub (stars on GitHub). Thực tế, dự án sẽ tiếp tục phi thương mại (non-commercially). Và chúng tôi vẫn đang đẩy các thay đổi ngay cả khi chúng tôi đang đóng cửa mọi thứ, nhưng thực sự rất khó để kiếm tiền trong môi trường hiện tại. Tất cả những người đang kiếm tiền đều đang làm hai việc: họ đang bán cho doanh nghiệp (enterprise) và họ đang bán lại mã thông báo (reselling tokens). Và chúng tôi không làm cả hai điều đó. Chúng tôi không phải là một tác nhân viết mã. Chúng tôi có một nút giúp bạn chạy một cái gì đó trong Codex hoặc Cool Code. Vì vậy, mọi người có thể, chúng tôi có một gói đăng ký. Mọi người sẽ chi khoảng 30 đô la cho chúng tôi và sau đó nhấn một nút giúp họ chi 3.000 đô la cho Codex. Điều đó đơn giản là không bền vững. Và tất cả người dùng của chúng tôi đều là cá nhân, startup, các công ty nhỏ hơn. Tôi nghĩ chúng tôi có thể đã làm việc để giải quyết vấn đề đó và di chuyển lên (move up) thị trường doanh nghiệp, nhưng tôi không biết. Đây là một thị trường trưởng thành (mature market) tại thời điểm này và không vui khi cạnh tranh cho vị trí thứ tám. Vì vậy, chúng tôi quyết định đóng cửa mọi thứ.
Hoàn thành quy trình đóng cửa và Hỏi & Đáp
Được rồi. Bài đăng blog đã sẵn sàng. Hãy xem nó có hoạt động không. Vậy là chúng ta có tính năng xem trước trực tiếp, hiển nhiên. Hãy chờ nó biên dịch (compile). Được rồi. Trông ổn đấy. Vậy thì chúng ta có thể tiếp tục, mở một yêu cầu kéo. Thay đổi chưa được cam kết (uncommitted changes). Ồ. Không biết đó là gì nữa. Bạn có đang phát hiện ra điều này trước các nhà đầu tư của bạn không? [tiếng cười khẩy] Không, bạn không phải lo lắng đâu. Hầu hết trong số họ... Thực ra, một số người tôi cần gọi cho họ sau buổi này. Đó là một điểm rất hay. Tôi hoàn toàn cam kết đóng cửa cái này trực tiếp trên sân khấu. Được rồi. Xong rồi. Nó sẽ đi qua CDN của Cloudflare.
[tiếng vỗ tay]
Cảm ơn bạn. Tôi nghĩ chúng ta còn thời gian cho một hoặc hai câu hỏi. Tôi không biết liệu có ai trong khán giả có một... một phút 45 giây. Chỉ cần...
Steve? Điều gì tiếp theo?
Tạm nghỉ một thời gian, bắt đầu một công ty khác. Đồng sáng lập của tôi sẽ tham gia một phòng thí nghiệm (lab). Và hầu hết đội ngũ đã tìm được công việc tốt tại Agent Labs, những nơi tương tự. Vâng. Có câu hỏi nào khác không? [tiếng cười khẩy]
Cảm giác chung khi bạn nhìn lại là tích cực hay tiêu cực?
Ồ, vâng. Không, tôi sẽ không làm bất cứ điều gì khác biệt. Tôi nghĩ rằng đây là điều thú vị nhất mà tôi từng làm và nó đang ở tiên tiến nhất (cutting edge) của tác nhân và tất cả những thứ này. Tôi nghĩ chắc chắn tôi không biết. Nó đã nâng cao giá trị của tôi với tư cách một con người khi làm điều này, vì vậy tôi sẽ làm lại tất cả. Vâng. Cứ nói đi.
Những điều giá trị nhất bạn học được từ vài năm điều hành một công ty là gì?
Những điều giá trị nhất, tôi chỉ muốn nói là hãy làm việc với những người tuyệt vời. Chúng tôi đã trải qua vài đợt thay đổi thành viên trong đội ngũ, và đội ngũ mà chúng tôi có được cuối cùng thì tốt hơn một cách phi thường. Không có ý xúc phạm đến đội ngũ trước đây, nhưng đó có lẽ là cách, bạn biết đấy, tôi nghĩ, và cả sự làm việc chăm chỉ nữa. Tôi nghĩ chúng tôi đã mất một thời gian để học được làm việc chăm chỉ thực sự là gì. Và bạn đến một điểm mà bạn ngồi đó vào nửa đêm với đội ngũ trong văn phòng vào một ngày thứ Bảy và mọi người đều có động lực, và đó, vâng, phải mất một thời gian để bạn tìm ra cách để đạt đến điểm đó. Và một khi bạn cảm nhận được nó, bạn biết điều đó như thế nào. Tôi nghĩ nó khó cho đến khi bạn đạt được điều đó. Vâng. 12 giây. Không? Được rồi.
Nhìn lại quá khứ, bạn sẽ thay đổi điều gì?
Tôi sẽ thay đổi điều gì? Tôi sẽ thuê một người thực sự giỏi trong việc bán hàng cho doanh nghiệp. Được rồi, xin cảm ơn rất nhiều.
[tiếng vỗ tay]
Cảm ơn.
[nhạc]
TL;DR
- Sự phát triển của AI đang chuyển đổi công việc của kỹ sư phần mềm từ viết mã trực tiếp sang tập trung vào lập kế hoạch và đánh giá mã do AI tạo ra.
- Để tối ưu hóa hiệu quả, cần ưu tiên phương pháp dựa trên kế hoạch chi tiết ngay từ đầu, giảm thiểu các vòng lặp đánh giá liên tục, đặc biệt với các tác vụ có tính chất ổn định và ít trạng thái.
- Khi các tác nhân AI chạy lâu hơn (vượt quá 5 phút), các nhà phát triển cần thay đổi hành vi làm việc, áp dụng các giao diện mới cho phép song song hóa và quản lý nhiều luồng công việc để duy trì năng suất.
Điểm chính
- Chuyển đổi công việc: Công việc chính của kỹ sư phần mềm đang dịch chuyển từ viết mã sang lập kế hoạch và đánh giá mã do AI tạo ra, với thời gian viết mã trực tiếp giảm đáng kể nhờ các công cụ AI.
- Phương pháp dựa trên kế hoạch ưu việt: Dành thời gian lập kế hoạch chi tiết ban đầu giúp giảm đáng kể thời gian đánh giá sau này, dẫn đến mã chất lượng cao hơn và ít lỗi hơn từ các mô hình AI.
- Lựa chọn phương pháp theo ngữ cảnh: Phát triển tính năng front-end có thể đòi hỏi nhiều vòng lặp đánh giá hơn do tính phụ thuộc trạng thái và tương tác phức tạp, trong khi back-end, tái cấu trúc và di chuyển phù hợp hơn với phương pháp lập kế hoạch (phát triển hướng kiểm thử).
- Thời gian chạy của tác nhân AI kéo dài: Các tác nhân AI đang dần chạy lâu hơn (từ vài giây lên đến 5-10 phút, và có thể lâu hơn) do khả năng gọi công cụ, kiểm tra kiểu và chạy thử nghiệm được cải thiện.
- Yêu cầu giao diện và quy trình mới: Để quản lý các tác vụ AI chạy lâu, cần có các giao diện mới hỗ trợ song song hóa nhiều luồng công việc, giảm thiểu việc chuyển đổi ngữ cảnh liên tục của con người.
- Tối đa hóa thời gian tác nhân hoạt động: Công cụ lý tưởng nên được thiết kế để tác nhân AI có thể hoạt động càng lâu càng tốt mà không cần sự can thiệp của con người, sau đó mới trả quyền kiểm soát lại để con người đánh giá.
- Vai trò con người trong QA và Code Review: Dù AI có tiến bộ đến đâu, con người vẫn sẽ đóng vai trò quan trọng trong việc đảm bảo chất lượng (QA) và đánh giá mã (code review) trước khi triển khai, đặc biệt với các hệ thống sản xuất.
- Thách thức kinh doanh trong thị trường AI DevTools: Việc kiếm tiền từ các công cụ hỗ trợ phát triển bằng AI đang gặp khó khăn, đặc biệt đối với các công ty không tập trung vào khách hàng doanh nghiệp hoặc mô hình bán lại mã thông báo.
Từ vựng
AI— Trí tuệ nhân tạoAgent— tác nhânCode— mãPlan-based approach— phương pháp dựa trên kế hoạchEvaluation-intensive— đánh giá chuyên sâuEdge case— trường hợp biênTool calling— gọi công cụQA— đảm bảo chất lượng / kiểm soát chất lượngParallelize— song song hóaCode review— đánh giá mãPull request (PR)— yêu cầu kéo (PR)Enterprise— doanh nghiệpReselling tokens— bán lại mã thông báo
Nội dung chi tiết
Giới thiệu & Người trình bày
[Nhạc] Mic đã bật chưa? Vâng, mic đã bật rồi. Mọi người khỏe không? Woo! [transcript bị gián đoạn] Tuyệt vời. Vâng, chúng ta hãy bắt đầu. Được rồi. À, đây là... Vì vậy, tiêu đề của bài nói này là về lập kế hoạch và đánh giá, nhưng tôi nghĩ điểm mấu chốt thực sự đằng sau nó là chúng ta sẽ làm gì khi Trí tuệ nhân tạo (AI) ngày càng trở nên xuất sắc hơn. Tôi là Louie, người sáng lập một công ty khởi nghiệp tên là Vibe Canvas. Tôi cũng đã thành lập chi nhánh AI Tinkers tại London, một cộng đồng tuyệt vời nếu bạn ở London và đang tìm kiếm các sự kiện. Và bạn nên lắng nghe tôi vì tôi đã đạt được một số thành tựu như đứng đầu bảng xếp hạng đã xác minh của SweeBench trước cả OpenAI. Điều này đã cách đây vài tháng rồi, nhưng dù sao, bạn biết đấy, luôn tốt khi biết rằng những người đang nói đã thực hiện một số nghiên cứu trong lĩnh vực này.
Chương trình nghị sự
Chương trình nghị sự hôm nay, thưa các bạn, là tôi sẽ hướng dẫn các bạn lý do tại sao tôi đi đến kết luận rằng về cơ bản, công việc cả ngày của tất cả các kỹ sư phần mềm sẽ chỉ là lập kế hoạch và đánh giá. Tôi sẽ nói về cách cân bằng công việc đó nếu đó là những gì bạn làm cả ngày. Tôi sẽ nói về thời gian hoạt động và cách các tác nhân đang chạy lâu hơn, và điều đó thay đổi hành vi của công việc như thế nào. Và cuối cùng, chúng ta sẽ đóng cửa công ty của tôi. [Khụt khịt] Chúng ta sẽ nói về điều đó sau. Vậy, hãy bắt đầu nào.
Sự thay đổi: Mọi thứ đều là Lập kế hoạch và Đánh giá
Mọi thứ đều là lập kế hoạch và đánh giá. Vậy, công việc mà chúng ta, những kỹ sư phần mềm, làm là gì? Có ai ở đây không phải là kỹ sư phần mềm không? Vâng. Được, hầu hết mọi người. Chúng ta lập kế hoạch, chúng ta viết code, chúng ta đánh giá code và chúng ta đánh giá code của người khác. Đại khái là công việc chúng ta làm.
Tỷ lệ công việc cho đến khi GitHub Copilot xuất hiện đối với tôi đại khái là như thế này: Tôi biết nó phụ thuộc vào việc bạn làm việc ở công ty lớn hay công ty nhỏ và những thứ tương tự, nhưng phần lớn là viết code, và so với đó, phần lập kế hoạch và đánh giá code thì không nhiều lắm. Và điều chúng ta thấy là theo thời gian, với những thứ như phiên bản đầu tiên của GitHub Copilot, phần viết code bắt đầu thu hẹp lại. Bạn biết đấy, ChatGPT ra đời, đột nhiên bạn có thể tạo ra các hàm và dán chúng vào, và sau đó Cursor – không phải Cursor hiện tại mà là phiên bản gốc của Cursor – xuất hiện, và nó có thể hoàn thành cả một trang code. Và rồi bạn có Claude Code, và bạn sẽ nghĩ, "Wow, mình thực sự không viết code nhiều nữa."
Vì vậy, nó đặt ra một câu hỏi thú vị: Nếu trước đây chúng ta dành 4 giờ mỗi ngày để viết code, liệu điều đó có nghĩa là tôi sẽ có lại 4 giờ đó nếu tôi không thực hiện bất kỳ công việc viết code thực tế nào không? Câu trả lời, tất nhiên, là không. Nó đã dịch chuyển công việc. Công việc hoặc thời gian trước đây dành cho việc viết code đã dịch chuyển. Nó đã dịch chuyển sang lập kế hoạch và đánh giá. Tôi nghĩ đó là một yếu tố thúc đẩy. Bạn có thể hoàn thành nhiều việc hơn trong ngày, nhưng có lẽ là bạn có 20 phút rảnh rỗi cho mỗi nửa giờ bạn dành cho việc viết code, và một khoảng thời gian khác đã chuyển sang lập kế hoạch và đánh giá.
Vì vậy, tôi muốn nói về điều đó. Cách làm việc mới này là gì? Và tôi nghĩ về cơ bản có hai phương pháp mà mọi người áp dụng. Tôi sẽ không đi sâu vào chi tiết về, bạn biết đấy, specs hay Playwright MCPs hay những thứ tương tự. Tôi nghĩ có rất nhiều bài nói chuyện hấp dẫn về điều đó tại sự kiện này. Tôi chỉ muốn khái quát hóa những gì chúng ta đang nói ở đây hôm nay.
Hai phương pháp tiếp cận: Dựa trên kế hoạch và Đánh giá chuyên sâu
Phương pháp đầu tiên là phương pháp dựa trên kế hoạch (plan-based approach). Đây là nơi bạn dành nhiều thời gian ban đầu để lập kế hoạch cho công việc mà bạn muốn một tác nhân viết code thực hiện. Những dấu hiệu cho thấy bạn đang thực hiện loại công việc này có lẽ sẽ trông giống như bạn đang viết một tài liệu kế hoạch rất toàn diện, một tệp markdown. Có thể bạn đang sử dụng một trong các framework đặc tả này. Bạn đang thẩm vấn. Bạn biết đấy, tôi đã thấy một số điều thú vị khi mô hình liên tục hỏi bạn cho đến khi nó hoàn toàn cạn kiệt tất cả các câu hỏi có thể có về công việc cần được thực hiện.
Lợi ích của điều này, tất nhiên, là bạn về cơ bản sẽ dành ít thời gian hơn để đánh giá công việc đó vì bạn đã đầu tư thời gian từ đầu để loại bỏ các edge case, cung cấp cho các mô hình càng nhiều thông tin càng tốt về công việc bạn đang cố gắng thực hiện. Kết quả của việc đó sẽ là các mô hình ít có khả năng lỗi hơn, và bạn sẽ nhận được đầu ra tốt hơn, và có lẽ, ít vòng đánh giá hơn. Nhược điểm là bạn phải dành nhiều thời gian hơn để lập kế hoạch, nhưng điều đó là hiển nhiên, phải không?
Cách khác để thực hiện điều này, cách lớn khác để làm việc với AI là bạn không xác định một kế hoạch rất chi tiết, mà thay vào đó, bạn để nó chạy, và sau đó bạn sẽ dành nhiều thời gian hơn để đánh giá công việc đó. Vì vậy, bạn biết đấy, lợi ích của điều này là bạn có thể làm việc một cách ngẫu hứng, kiểu như, "À, hãy thêm một contact form vào trang web." Và sau đó, bạn biết đấy, điều bạn phải làm là bạn sẽ phải điều chỉnh qua lại vài lần để sửa các kiểu dáng, tìm hiểu mọi thứ.
Tôi sẽ nói rằng nếu bạn coi thời gian của con người là điều có giá trị, và bạn có một lựa chọn, bạn luôn muốn thực hiện hành vi đầu tiên trong số các hành vi này, về cơ bản là phương pháp lập kế hoạch, bởi vì nó sẽ giúp bạn tiết kiệm rất nhiều thời gian. Rất tốn thời gian khi phải chuyển đổi qua lại với một tác nhân đang cung cấp cho bạn một phần công việc chưa hoàn thành, và bạn liên tục phải đánh giá nó.
Các chế độ làm việc và Ngữ cảnh
Tôi nghĩ một cách khác để phân loại các chế độ làm việc, nơi một là lập kế hoạch và một là đánh giá, là nghĩ về loại công việc bạn đang làm. Và tôi nghĩ việc phát triển tính năng (feature development) thực sự rất khác so với việc di chuyển (migrations) và công việc bảo trì (maintenance). Và front-end rất khác với back-end. Tôi đã cố gắng suy nghĩ về điều này trước buổi nói chuyện, và đây là ma trận tôi đã đưa ra, nơi về cơ bản, nếu bạn đang làm việc trên front-end và bạn đang phát triển tính năng, về cơ bản là không thể thực sự đặc tả mọi thứ ra. Có quá nhiều edge case và, bạn biết đấy, front-end rất phụ thuộc vào trạng thái (stateful). Có các tương tác, hoạt ảnh, kiểu dáng, có chức năng. Và vì vậy, cá nhân tôi, tôi thấy tốt hơn nhiều khi ở trong vòng lặp với một tác nhân viết code. Đó là hành vi thứ hai trong số những hành vi mà chúng ta đã nói đến.
Nhưng đối với mọi thứ khác, tôi nghĩ thực sự có thể thiên về lập kế hoạch. Vì vậy, đối với phát triển tính năng back-end, bạn gần như có thể thực hiện phát triển hướng kiểm thử (test-driven development). Và đối với bất kỳ thứ gì như tái cấu trúc (refactoring) và dựa trên di chuyển (migration-based), bạn chắc chắn có thể làm điều đó, và bạn không nên ở trong vòng lặp với bất kỳ công việc nào trong số đó. Tất cả những điều đó nên là phát triển hướng kiểm thử.
Vì vậy, tôi đoán nếu bạn phải tóm tắt bài trình bày dài dòng này thành một câu, thì đó sẽ là: "Dành 5 phút lập kế hoạch giúp bạn tiết kiệm 30 phút đánh giá code do AI tạo ra." Và đó về cơ bản là điều cốt lõi.
Tác nhân chạy lâu hơn và thay đổi hành vi
Điều khác mà tôi nghĩ khá thú vị để xem xét là cách mọi thứ đang chạy lâu hơn. Vì vậy, khi các tác nhân viết code trở nên có khả năng AI hơn, khi các mô hình tốt hơn, khi tool calling cải thiện, bạn chuyển từ việc gọi một tập hợp rất nhỏ các công cụ sang việc hiện tại, các CLI viết code có thể gọi một loạt lớn các công cụ và thực hiện kiểm thử và những thứ tương tự. Kết quả của điều đó là mỗi khi bạn gửi một lời nhắc, bạn sẽ phải đợi lâu hơn trước khi nó quay lại với bạn và nói, "Này Louie, đã đến lúc bạn phải làm gì đó."
Để minh họa điều này, bạn biết đấy, hãy nghĩ lại về GitHub Copilot. Nó hoàn thành một dòng code duy nhất, và mất vài giây. Sau đó bạn có Cursor gốc hoàn thành một tệp duy nhất, và điều đó chạy trong, bạn biết đấy, 30 giây. Và sau đó bạn có Claude Code, mà, bạn biết đấy, năm ngoái có thể chạy trong một hoặc hai phút, và năm nay tôi đã nhận được một số kết quả khá tốt với các lần thực thi 5 hoặc 10 phút. Và điều đó sẽ tiếp tục bởi vì về cơ bản, chúng ta đã chuyển từ việc bạn yêu cầu AI làm gì đó và nó chỉ phản hồi, sang AI chạy type checker sang AI kiểm thử sự thay đổi của nó.
Ý tôi là, đây là biên giới của mọi thứ. Và những điều này tốn ngày càng nhiều thời gian. Chỉ trả về code thì rất nhanh. Chạy type checker chậm hơn một chút. Chạy Playwright MCP chậm hơn một bậc độ lớn so với bất kỳ điều nào trong số đó. Nhưng điều đó đáng làm bởi vì, bạn biết đấy, điều bạn đang cố gắng tối đa hóa, một lần nữa, là lượng thời gian bạn dành – hoặc tối thiểu hóa, đúng hơn – là lượng thời gian bạn dành để làm việc với tác nhân. Vì vậy, nếu bạn có thể đạt được độ chính xác cao hơn bằng cách chờ đợi lâu hơn, thì đó là một sự đánh đổi đáng giá.
Và đây có lẽ là nơi biên giới đang ở: nếu tôi phải dự đoán chúng ta sẽ ở đâu trong 9 tháng tới, tôi sẽ nói rằng về cơ bản, AI bắt đầu có khả năng QA công việc front-end, và đó sẽ là một bước đột phá lớn. Bạn thấy một số bản demo thú vị về điều này trên Twitter với, bạn biết đấy, Chrome hoặc Playwright MCP nhấp chuột xung quanh mọi thứ. Thực tế là tôi chưa gặp một người nào thực sự làm điều này trong quá trình phát triển chính thống của họ. Nhưng tôi thực sự rất hào hứng với nó, và tôi nghĩ nó sẽ là bước đột phá lớn tiếp theo, nơi về cơ bản, hầu hết các cuộc trao đổi qua lại mà bạn thực hiện với một mô hình sẽ chỉ được thực hiện bởi chính mô hình đó vì nó sẽ có thể thực sự chạy dự án của bạn, nhấp chuột xung quanh và tìm lỗi, và đảm bảo nó đã hoàn thành.
Nhưng điều này đặt ra một câu hỏi thú vị, đó là: điều gì xảy ra khi thời gian trung bình mà một tác nhân chạy vượt quá, ví dụ, 5 phút? Bởi vì tôi nghĩ 5 phút là khoảng thời gian bạn có thể ngồi đó và đợi một điều gì đó, xem nhật ký, có lẽ thực tế hơn là lướt Twitter, những thứ như vậy. Và khi chúng ta vượt qua mốc 5 phút đó, bạn phải thay đổi hành vi của mình. Bạn biết đấy, hãy tưởng tượng những thứ này sẽ mất 20 phút để chạy. Bạn sẽ không ngồi đó 20 phút để xem nhật ký tác nhân. Bạn sẽ phải suy nghĩ về việc viết code và toàn bộ công việc của một nhà phát triển phần mềm theo một cách rất, rất khác.
Song song hóa và Giao diện mới
Điều này tôi chắc chắn mọi người đều đã thấy, đó là khái niệm tối ưu hóa terminal kiểu này, nơi bạn về cơ bản là song song hóa, phải không? Bạn chạy nhiều tác vụ này cùng một lúc. Giả sử mỗi tác vụ mất 10 phút để chạy. Vì vậy, cách bạn khắc phục vấn đề chờ đợi là bạn có nhiều tác vụ đang chạy cùng một lúc. Ngay sau khi bạn hoàn thành, chẳng hạn, việc đánh giá một phần công việc, một phần khác đã hoàn thành và bạn có thể chuyển sang phần đó.
Và đó về cơ bản là những gì chúng tôi bắt đầu làm. Đây là dự án chúng tôi đã bắt đầu cách đây khoảng một năm, được gọi là Vibe Kanban. Và về cơ bản, nó bắt đầu như một nỗ lực để giúp việc song song hóa các tác nhân trở nên rất dễ dàng. Chúng tôi đã xây dựng một số thứ hay ho. Có một sidebar nơi bạn có thể tạo nhiều không gian làm việc (workspaces) chạy bất kỳ tác nhân viết code nào, như Codex, Cool Code, những thứ tương tự. Khi bạn muốn đánh giá code, bạn sẽ nhận được các diffs. Nếu bạn muốn nhận xét về điều gì đó, bạn có thể làm điều đó giống như cách GitHub làm. Nếu bạn muốn xem trước điều gì đó hoặc, bạn biết đấy, nhấp vào điều gì đó và kiểu như, "À, thực sự làm cho cái này lớn hơn một chút hoặc cái kia nhỏ hơn một chút," bạn cũng có thể làm điều đó.
Và bạn có thể đã thấy tất cả những thứ này trước đây, nhưng bạn có thể chưa thấy những thứ này bắt đầu sớm như ngày 14 tháng 6 năm 2025. Chúng tôi đã làm điều đó trước, tôi thề!
Vậy, những cân nhắc. Tôi nghĩ rằng hành vi của con người sẽ thay đổi vì các tác nhân sẽ vượt qua ngưỡng 5 phút này. Và ai biết được, điều đó có thể tiếp tục. Bạn có thể kết thúc việc vượt qua ngưỡng một giờ. Vì vậy, chúng ta cần các giao diện mới để làm cho công việc này trở nên tuyệt vời. Bởi vì nếu bạn cố gắng làm điều đó bằng cách sử dụng các công cụ hiện có, nó sẽ khá tệ. Bạn phải nhảy vòng quanh, đánh giá code ở một nơi, xem trước mọi thứ ở một nơi khác.
Khung làm việc cho Tác nhân AI hỗ trợ Lập trình viên
Nếu tôi có một danh sách mong muốn về một công cụ tác nhân AI hỗ trợ mã hóa tối ưu cho các nhà phát triển phần mềm, nó sẽ cơ bản phải chấp nhận thực tế rằng tôi phải quản lý nhiều luồng công việc cùng một lúc – điều mà hầu hết các nhà phát triển phần mềm chưa từng phải làm. Họ thường chỉ cần tập trung sâu vào một phần công việc duy nhất. Vì vậy, công cụ này sẽ tập trung vào việc "tối đa hóa sự tập trung" (focus maxing) – tôi không biết đây có phải là một từ hay không, nhưng tôi muốn định nghĩa nó ngay tại đây. Nó nên chấp nhận thực tế rằng bạn không thể kéo con người ra khỏi một việc rồi lại đưa họ quay trở lại một việc khác sau mỗi 30 giây, vì điều đó làm "cháy" não bộ và đó không phải là một cách sống.
Vì vậy, công cụ nên được xây dựng xung quanh việc khai thác tối đa khả năng của con người để một tác nhân có thể hoạt động càng lâu càng tốt, sau đó "trả lại" quyền kiểm soát cho con người. Điều này trái ngược với việc khuyến khích các mô hình mà bạn liên tục phải "nhảy" vào, "nhảy" ra để nắm bắt lại ngữ cảnh của những gì một tác nhân cụ thể đang làm. Nó nên giúp bạn viết tác vụ và lên kế hoạch mọi thứ, hiển nhiên. Nó cũng nên giúp bạn kiểm soát chất lượng (QA) công việc, vì đó sẽ là phần lớn công việc của con người. Và nó nên giúp bạn thực hiện đánh giá mã (code review). Tôi nghĩ rõ ràng là đánh giá mã hiện nay đã được thực hiện nhiều với Trí tuệ nhân tạo, nhưng rất ít công ty có tiền trong tay sẽ thực sự triển khai những sản phẩm được viết mã hoàn toàn bằng Trí tuệ nhân tạo mà không kiểm tra mã. Vì vậy, đọc mã có lẽ là điều mà hầu hết mọi người trong căn phòng này vẫn sẽ phải làm. Cuối cùng, nó nên hỗ trợ dẫn dắt sự thay đổi cho đến khi được triển khai – đây là một khía cạnh mới nổi. Nói một cách đơn giản nhất, nó giống như việc giám sát các yêu cầu kéo (pull request) trên GitHub, tìm kiếm các bình luận và tự động phản ứng với chúng. Rất nhiều công việc hành chính liên quan đến việc chuyển đổi từ "tôi đã hoàn thành nhiệm vụ" sang "tôi đã triển khai nhiệm vụ" chỉ đơn thuần là theo dõi và phản ứng với các bình luận.
Quyết định dừng hoạt động công ty
Tôi đã viết bài nói chuyện này và gửi nó vài tuần trước. Đến thứ Ba vừa rồi, tôi quyết định đóng cửa công ty. [tiếng cười khẩy] Về cơ bản, có một phần trong bài nói chuyện này là về việc tôi sẽ kể cho bạn nghe nhiều hơn về Vibe Kanban và cố gắng bán nó cho bạn, nhưng điều đó sẽ không xảy ra nữa vì công ty hiện đang đóng cửa. Vì vậy, thay vào đó, tôi nghĩ chúng ta có thể cùng nhau đóng cửa công ty. Tôi vẫn chưa chính thức thông báo điều này.
[tiếng vỗ tay]
Được rồi, và chúng ta sẽ làm điều đó bằng cách sử dụng Vibe Kanban, tất nhiên rồi. Đó phải là cách làm.
Thực hiện đóng cửa công ty bằng Vibe Kanban
Được rồi, vậy thì, làm ơn hãy thêm một bài đăng blog vào trang web với nội dung này. [tiếng rên rỉ và cười khẩy] Và tôi đã viết trước lời nhắn buồn bã đó. Được rồi, chúng ta đã có trang web Vibe Kanban. Được rồi, nó sẽ tiến hành làm điều đó. Tôi có thể cho bạn một chuyến tham quan nhỏ về thứ này.
Nó đang chạy một script cài đặt. Nó đã tạo một cây làm việc Git (Git work tree). Nó đã chạy một script cài đặt trong cây làm việc để cài đặt các phần phụ thuộc (dependencies) cho trang web của chúng tôi. Và khi hoàn tất, nó sẽ tiến hành chạy bất kỳ tác nhân nào bạn đã chọn. Tôi sử dụng Codex hầu hết thời gian, nhưng nó hỗ trợ tám trong số các mô hình phổ biến nhất. Và nó sẽ cố gắng tìm cách thực hiện điều đó.
Nguyên nhân và cảm xúc khi đóng cửa công ty
Còn điều gì hay ho nữa không? Bạn có buồn không? Tôi có buồn không? Tôi nghĩ tôi đã suy nghĩ về nó quá nhiều nên tôi cảm thấy khá nhẹ nhõm. Khi bạn điều hành một công ty trong vài năm, bạn có một trách nhiệm lớn lao đối với nhân viên và nhà đầu tư, và tất cả những thứ khác. Tôi không biết, tôi cảm thấy như một gánh nặng đã được cất bỏ.
Chúng ta cũng có thể nói về lý do tại sao chúng tôi đóng cửa công ty. Chúng tôi có rất nhiều người dùng, 30.000 người dùng hoạt động hàng tháng (monthly active users) và 25.000 lượt đánh dấu sao trên GitHub (stars on GitHub). Thực tế, dự án sẽ tiếp tục phi thương mại (non-commercially). Và chúng tôi vẫn đang đẩy các thay đổi ngay cả khi chúng tôi đang đóng cửa mọi thứ, nhưng thực sự rất khó để kiếm tiền trong môi trường hiện tại. Tất cả những người đang kiếm tiền đều đang làm hai việc: họ đang bán cho doanh nghiệp (enterprise) và họ đang bán lại mã thông báo (reselling tokens). Và chúng tôi không làm cả hai điều đó. Chúng tôi không phải là một tác nhân viết mã. Chúng tôi có một nút giúp bạn chạy một cái gì đó trong Codex hoặc Cool Code. Vì vậy, mọi người có thể, chúng tôi có một gói đăng ký. Mọi người sẽ chi khoảng 30 đô la cho chúng tôi và sau đó nhấn một nút giúp họ chi 3.000 đô la cho Codex. Điều đó đơn giản là không bền vững. Và tất cả người dùng của chúng tôi đều là cá nhân, startup, các công ty nhỏ hơn. Tôi nghĩ chúng tôi có thể đã làm việc để giải quyết vấn đề đó và di chuyển lên (move up) thị trường doanh nghiệp, nhưng tôi không biết. Đây là một thị trường trưởng thành (mature market) tại thời điểm này và không vui khi cạnh tranh cho vị trí thứ tám. Vì vậy, chúng tôi quyết định đóng cửa mọi thứ.
Hoàn thành quy trình đóng cửa và Hỏi & Đáp
Được rồi. Bài đăng blog đã sẵn sàng. Hãy xem nó có hoạt động không. Vậy là chúng ta có tính năng xem trước trực tiếp, hiển nhiên. Hãy chờ nó biên dịch (compile). Được rồi. Trông ổn đấy. Vậy thì chúng ta có thể tiếp tục, mở một yêu cầu kéo. Thay đổi chưa được cam kết (uncommitted changes). Ồ. Không biết đó là gì nữa. Bạn có đang phát hiện ra điều này trước các nhà đầu tư của bạn không? [tiếng cười khẩy] Không, bạn không phải lo lắng đâu. Hầu hết trong số họ... Thực ra, một số người tôi cần gọi cho họ sau buổi này. Đó là một điểm rất hay. Tôi hoàn toàn cam kết đóng cửa cái này trực tiếp trên sân khấu. Được rồi. Xong rồi. Nó sẽ đi qua CDN của Cloudflare.
[tiếng vỗ tay]
Cảm ơn bạn. Tôi nghĩ chúng ta còn thời gian cho một hoặc hai câu hỏi. Tôi không biết liệu có ai trong khán giả có một... một phút 45 giây. Chỉ cần...
Steve? Điều gì tiếp theo?
Tạm nghỉ một thời gian, bắt đầu một công ty khác. Đồng sáng lập của tôi sẽ tham gia một phòng thí nghiệm (lab). Và hầu hết đội ngũ đã tìm được công việc tốt tại Agent Labs, những nơi tương tự. Vâng. Có câu hỏi nào khác không? [tiếng cười khẩy]
Cảm giác chung khi bạn nhìn lại là tích cực hay tiêu cực?
Ồ, vâng. Không, tôi sẽ không làm bất cứ điều gì khác biệt. Tôi nghĩ rằng đây là điều thú vị nhất mà tôi từng làm và nó đang ở tiên tiến nhất (cutting edge) của tác nhân và tất cả những thứ này. Tôi nghĩ chắc chắn tôi không biết. Nó đã nâng cao giá trị của tôi với tư cách một con người khi làm điều này, vì vậy tôi sẽ làm lại tất cả. Vâng. Cứ nói đi.
Những điều giá trị nhất bạn học được từ vài năm điều hành một công ty là gì?
Những điều giá trị nhất, tôi chỉ muốn nói là hãy làm việc với những người tuyệt vời. Chúng tôi đã trải qua vài đợt thay đổi thành viên trong đội ngũ, và đội ngũ mà chúng tôi có được cuối cùng thì tốt hơn một cách phi thường. Không có ý xúc phạm đến đội ngũ trước đây, nhưng đó có lẽ là cách, bạn biết đấy, tôi nghĩ, và cả sự làm việc chăm chỉ nữa. Tôi nghĩ chúng tôi đã mất một thời gian để học được làm việc chăm chỉ thực sự là gì. Và bạn đến một điểm mà bạn ngồi đó vào nửa đêm với đội ngũ trong văn phòng vào một ngày thứ Bảy và mọi người đều có động lực, và đó, vâng, phải mất một thời gian để bạn tìm ra cách để đạt đến điểm đó. Và một khi bạn cảm nhận được nó, bạn biết điều đó như thế nào. Tôi nghĩ nó khó cho đến khi bạn đạt được điều đó. Vâng. 12 giây. Không? Được rồi.
Nhìn lại quá khứ, bạn sẽ thay đổi điều gì?
Tôi sẽ thay đổi điều gì? Tôi sẽ thuê một người thực sự giỏi trong việc bán hàng cho doanh nghiệp. Được rồi, xin cảm ơn rất nhiều.
[tiếng vỗ tay]
Cảm ơn.
[nhạc]