- Mô hình năng suất cá nhân với
agentkhông đủ cho phát triển phần mềm, vốn là một môn thể thao đồng đội; việc mở rộng cá nhân chỉ làm trầm trọng thêm các vấn đề về phối hợp và đồng bộ. - Nút thắt cổ chai mới trong phát triển phần mềm không phải là cách xây dựng mà là quyết định nên xây dựng gì, do việc tạo mã trở nên quá nhanh và rẻ nhờ
agent, làm tăngchi phí cơ hộivà đòi hỏi sự đồng bộ sớm hơn. - ACE (Agent Collaboration Environment) là một
prototypecủa GitHub Labs, cung cấp môi trường cộng tác đa người chơi, dựa trênmicro VM, nơi con người vàagentcó thể cùng nhau lập kế hoạch, phát triển và đồng bộ hóa liên tục trước và trong quá trình triển khai.
Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub
- Hạn chế của năng suất cá nhân: Mặc dù
coding agentcó thể tăng tốc độ triển khai cá nhân, nhưng chúng không giải quyết được các thách thức cố hữu của phát triển phần mềm nhóm, nơi sự đồng bộ và phối hợp là tối quan trọng. - Chi phí cơ hội mới: Với tốc độ tạo mã nhanh chóng, câu hỏi khó nhất không còn là "làm thế nào để xây dựng nó?" mà là "chúng ta có nên xây dựng nó không?".
Chi phí cơ hộicủa việc chọn một tính năng thay vì tính năng khác trở thành chi phí thực sự. - Công cụ cũ không phù hợp với kỷ nguyên mới: Các công cụ phối hợp hiện có như
GitHub,Slack,Jirakhông được thiết kế cho sự nhanh chóng và khối lượng đầu ra của phát triểnagentic, dẫn đến quá tảipull requestvà thiếungữ cảnh. - Cần đồng bộ hóa sớm và liên tục: Sự đồng bộ hóa không thể dồn gánh nặng vào giai đoạn
reviewcuối cùng. Lập kế hoạch, thu thậpngữ cảnh, ra quyết định và phát triển cần diễn ra như một chu trình liên tục và tích hợp. - Tầm quan trọng của
ngữ cảnhxã hội: Hầu hếtngữ cảnhcần thiết để xây dựng đúng thứ không nằm trongcơ sở mãmà trong suy nghĩ của con người (ví dụ:ngữ cảnh nghiệp vụ,tầm nhìn sản phẩm,thông tin chi tiết từ nghiên cứu người dùng).Agentkhông thể tự khám phá điều này. - Giải pháp là môi trường cộng tác
agent: Các công cụ như ACE cung cấp một không gian làm việc chung, nơi cả người vàagentcó thể tương tác, chia sẻngữ cảnhvà làm việc trên cùng một máy ảo đám mây (micro VM), hỗ trợ phát triển đa người chơi theo thời gian thực. - Lập kế hoạch và thực hiện tích hợp: Trong các môi trường này,
agentcó thể tạo kế hoạch phát triển mà nhóm có thể cùng nhau chỉnh sửa và phê duyệt, sau đóagentsẽ thực hiện kế hoạch đó, đảm bảo mọi người đồng bộ về ý định trước khi mã được viết. - Quản lý
ngữ cảnhnhóm chủ động:Bảng điều khiểnvà các tính năngteam pulsegiúp tóm tắt công việc đang tiến hành, nhắc nhở cá nhân và cung cấpngữ cảnhxã hội về hoạt động của đồng nghiệp, giảm gánh nặng theo dõi trong bối cảnh tốc độ phát triển cao.
agent— AI agent / tác nhân AInăng suất— productivitychi phí cơ hội— opportunity costngữ cảnh— contextpull request(PR) — pull request (yêu cầu hợp nhất mã)issue— issue (vấn đề/phiếu công việc)merge conflict— merge conflict (xung đột hợp nhất)cơ sở mã— codebaseAgent Collaboration Environment(ACE) — Agent Collaboration Environment (Môi trường Cộng tác Tác nhân)micro VM— micro virtual machine (máy ảo siêu nhỏ)prompt— prompt (câu lệnh/yêu cầu gửi cho AI)bảng điều khiển— dashboard
Giới thiệu & Mục tiêu
Vâng, bài nói chuyện này có tên "Một nhà phát triển, hai tá agent nhưng không có sự đồng bộ." Đây là lý do tại sao chúng ta cần kỹ thuật AI cộng tác. Trước tiên, xin giới thiệu nhanh. Tôi là Maggie. Tôi làm việc tại GitHub với tư cách là kỹ sư nghiên cứu cấp cao. Ít nhất đó là chức danh của tôi. Thực ra tôi là một nhà thiết kế, từ thời mà thiết kế và kỹ thuật là hai lĩnh vực riêng biệt. Và tiếp theo là nhóm lab trong GitHub. Chúng tôi chuyên thực hiện các dự án thử nghiệm, rủi ro hơn so với phần còn lại của tổ chức. Chúng tôi thích gọi đó là "phòng ban thử nghiệm và khám phá". Và giống như mọi người khác, chúng tôi đang cố gắng định hình các tool agentic mới cho nhà phát triển.
Năng suất Cá nhân và Hạn chế
Tôi nghĩ đây là điều mà nhiều người đang hình dung về đỉnh cao của năng suất nhà phát triển hiện nay, phải không? Nó giống như một bức tường đầy các coding agent chạy trên terminal, tất cả song song trên một máy của một người. Tôi thích gọi đây là lý thuyết "một người với hai tá cords" của tương lai. Lời hứa mà chúng ta được nghe là một người với một đội quân agent sẽ làm công việc của cả một đội ngũ nhà phát triển. Vấn đề chính với giấc mơ này là nó giả định phần mềm được tạo ra bởi một người. Tất cả các tool này đều là interface dành cho một người chơi. Và chúng tập trung vào việc mở rộng quy mô công việc của cá nhân. Nhưng việc mở rộng quy mô một cá nhân có giá trị hạn chế. Bởi vì phần mềm không được tạo ra bởi một người duy nhất trong một môi trường cô lập. Đây là một môn thể thao đồng đội và mọi người xây dựng nó cần phải đồng ý về những gì họ đang xây dựng và tại sao. Tin rằng năng suất cá nhân dẫn đến phần mềm tuyệt vời cũng giống như logic "chín người phụ nữ làm ra một em bé trong một tháng". Đầu ra cá nhân nhiều hơn không giải quyết được các vấn đề yêu cầu giao tiếp và phối hợp; nó làm cho chúng tồi tệ hơn.
Nút Thắt Cổ Chai Mới: Quyết Định Nên Xây Dựng Gì
Việc triển khai đang nhanh chóng trở thành một vấn đề đã được giải quyết, phải không? Có lẽ mọi người ở đây đều tin điều đó. Viết mã bây giờ rất nhanh. Nó ngày càng rẻ hơn và chất lượng đang tăng lên. Câu hỏi khó không còn là làm thế nào để xây dựng nó, mà là chúng ta CÓ NÊN xây dựng nó hay không. Đồng ý về những gì cần xây dựng là nút thắt cổ chai mới. Vì vậy, mọi người trong nhóm của bạn cần tham gia vào việc đặt câu hỏi: "Chúng ta đang làm đúng việc không?", "Chúng ta có đang sử dụng năng lượng đúng chỗ không?", và "Làm thế nào để chúng ta tạo ra tác động lớn nhất?". Khi việc sản xuất rẻ, chi phí cơ hội (opportunity cost) trở thành chi phí thực sự. Bạn không thể xây dựng mọi thứ, và bất cứ điều gì bạn chọn đều phải đánh đổi bằng mọi thứ khác. Bất kỳ ai xuất bản phần mềm trong một nhóm đều biết đây không phải là vấn đề mới. Sự đồng bộ luôn là một nút thắt cổ chai, nhưng các agent đã khiến chi phí của việc không đồng bộ trong một nhóm trở nên cao hơn rất nhiều. Điều làm cho nó tệ hơn là tất cả các tool phối hợp của chúng ta vẫn thuộc về một kỷ nguyên khác. GitHub, Slack, Jira, Linear và các công cụ tương tự, như hiện tại, không được thiết kế cho thế giới phát triển agentic. Chúng ta đang đổ hàng loạt đầu ra agentic vào các nền tảng được xây dựng cho một cách phát triển phần mềm đã lỗi thời. Tôi biết tôi làm việc tại GitHub nên điều này có thể nghe có vẻ "ngoại đạo" khi tôi nói ra, nhưng tôi hứa nó không gây tranh cãi. Rất ít người trong nội bộ tin rằng PR và issue là tương lai của phát triển phần mềm, và có rất nhiều người trong chúng tôi đang cố gắng khám phá những gì sẽ đến tiếp theo.
Quá Trình Phát Triển Đã Thay Đổi và Hậu Quả
Đây là cách quy trình phát triển đã từng diễn ra. Chúng ta có giai đoạn lập kế hoạch, giai đoạn xây dựng và giai đoạn review. Chúng ta có tất cả các điểm tiếp xúc để đồng bộ hóa trong suốt quá trình và nó đủ chậm để chúng ta có thời gian trò chuyện trong Slack và các cuộc họp Zoom, bình luận về issue và draft PR để có thể thảo luận chi tiết, mọi người có thể đóng góp ý kiến và nhận lời khuyên từ chuyên môn của đồng nghiệp và cấp trên, phát hiện lỗi và điều chỉnh nếu có vấn đề. Nhưng đến khi mã được review và merge, cả nhóm đã nhìn thấy công việc đang diễn ra và họ đều hiểu sơ bộ về tình hình. Giờ đây, "cửa sổ triển khai" đã thu hẹp lại, và vì việc triển khai không còn tốn kém và tốn thời gian như trước, chúng ta nghĩ rằng không cần lập kế hoạch nhiều nữa. Do đó, hầu hết các điểm tiếp xúc ban đầu đó thực sự biến mất. Chúng ta biết rằng thời gian review cho mã được sinh mã thực tế đã tăng lên, điều này tạo ra nhiều điểm đồng bộ hơn nhưng chúng lại ở phía sai của quá trình triển khai. Thời gian giữa việc tạo một issue và một agent mở PR giờ chỉ còn vài phút. Mã quá rẻ đến nỗi chúng ta không dừng lại để suy nghĩ kỹ trước khi prompt nó. Không may, hầu hết các coding agent còn có local plan mode (chế độ lập kế hoạch cục bộ) hoàn toàn không được chia sẻ với người khác. Vì vậy, bạn thậm chí không kiểm tra với nhóm của mình xem kế hoạch mà agent đưa ra có tốt không trước khi ship nó (nếu bạn thậm chí còn đọc nó), và do đó chúng ta mất thêm nhiều điểm đồng bộ.
Hậu Quả Của Thiếu Đồng Bộ và Giải Pháp
Điều này khiến gánh nặng của toàn bộ sự đồng bộ dồn lên pull request. Tất cả các điểm kiểm tra giờ đây đến sau khi triển khai, vào cuối quy trình, khi đã quá muộn. Và đó không phải là điều mà PR được thiết kế để làm ngay từ đầu, vì vậy chúng hoạt động kém hiệu quả ở vai trò này. Không có tool hiện tại nào của chúng ta cung cấp cho các nhóm một không gian chung để thảo luận kế hoạch, thu thập đúng ngữ cảnh và làm việc với các agent như một tập thể. Tất cả chúng ta đều đang trải qua những hậu quả của việc này. Đi nhanh mà không có sự đồng bộ tốt dẫn đến lãng phí công sức – ví dụ như các feature không ai yêu cầu và không thực sự giải quyết vấn đề thực tế, hoặc nhận feedback quan trọng sau khi bạn hoàn thành một thứ gì đó và cuối cùng phải vứt bỏ toàn bộ. Và còn chiều sâu điều phối (coordination depth). Đây là khi bạn gặp phải các merge conflict rất phức tạp vì các agent sẽ chạm vào cùng các file hoặc nhà phát triển thậm chí làm việc trùng lặp vì cả hai đều nhận một việc và cố gắng hoàn thành nó trong một ngày. Hoặc như chúng ta đều biết, tất cả chúng ta đều có hàng đống PR khổng lồ cần review mà không ai có ngữ cảnh và thậm chí không biết chúng chứa gì. Vậy làm thế nào để chúng ta giải quyết vấn đề này? Chúng ta cần các tool giúp mọi người trong nhóm đồng bộ HÓA TRƯỚC KHI các agent bắt đầu làm việc, chứ không phải SAU ĐÓ. Sự đồng bộ cần phải diễn ra liên tục song song với việc triển khai. Lập kế hoạch và xây dựng không còn là các giai đoạn riêng biệt; chúng giờ là một chu trình. Các tool của tương lai cần đưa việc lập kế hoạch, thu thập ngữ cảnh, ra quyết định và phát triển về chung một mái nhà. Điều này đặc biệt đúng vì hầu hết ngữ cảnh bạn cần để đồng bộ và xây dựng đúng thứ không nằm trong cơ sở mã. Nó nằm trong đầu mọi người. Ngữ cảnh nghiệp vụ (business context) và các nguồn lực tài chính quyết định điều gì là đúng đắn để xây dựng. Động lực chính trị về người phụ trách và người đưa ra quyết định. Tầm nhìn sản phẩm (product vision) từ các lãnh đạo, thông tin chi tiết từ nghiên cứu người dùng (user research insight) từ các nhà thiết kế và lịch sử của tổ chức về những gì bạn đã xây dựng trước đây. Tất cả những điều này đều vô cùng quan trọng khi bạn quyết định điều gì là đúng đắn để nhóm của bạn xây dựng. Và các agent không bao giờ có thể tự mình khám phá ngữ cảnh này. Bạn cần một cách để con người chia sẻ nó sớm và một cách tự nhiên mà không cần thêm quy trình hay gánh nặng.
ACE: Môi Trường Cộng Tác Tác Nhân
Tất cả những điều này đã rất rõ ràng với chúng tôi trong nhóm next. Và chúng tôi đã xây dựng một prototype nghiên cứu mới nhằm khám phá cách chúng ta có thể giải quyết một số vấn đề này. Nó được gọi là ACE, viết tắt của Agent Collaboration Environment (Môi trường Cộng tác Tác nhân). Đây chưa phải là một sản phẩm chính thức. Vì vậy, nếu nó trông còn khá thô sơ, thì đúng là như vậy. Chúng tôi sắp ra mắt bản technical preview và sẽ thử nghiệm nó với vài nghìn người. Sau đó, chúng tôi sẽ học hỏi cách mọi người cộng tác và iterate từ đó.
Trải nghiệm ACE: Công cụ Phát triển Đa Người Chơi
Vậy là chúng ta đang ở trong ACE. Nó có lẽ trông khá quen thuộc. Chúng tôi không tái tạo lại bất kỳ bánh xe nào nhiều hơn mức cần thiết. Nó giống một chút như FLAQ GitHub, Copilot, và một loạt máy tính đám mây có một đứa con vậy. Chúng ta có danh sách session ở bên trái, và session là nơi bạn làm việc, phải không? Đó là một cuộc trò chuyện đa người chơi. Nó giống như một kênh Slack. Tôi có đồng đội ở đây và tôi có thể nói chuyện với họ về công việc chúng tôi đang làm, nhưng tôi cũng có các coding agent của mình ở đây. Tuy nhiên, mỗi session không chỉ là một kênh trò chuyện. Nó còn được hỗ trợ bởi một micro VM (máy ảo siêu nhỏ), tức là một máy tính sandbox (môi trường biệt lập) trên đám mây trên một Git branch riêng. Các thay đổi chúng tôi thực hiện trong mỗi session đều được cô lập (isolated) để chúng tôi có thể làm việc trên các task song song và chuyển đổi tức thì giữa chúng. Nếu tôi muốn hỏi ý kiến một đồng đội về một feature tôi đang xây dựng, không ai phải stash các thay đổi Git của họ và pull về một branch mới hoặc vật lộn với các worktree cục bộ. Tôi chỉ cần nhảy vào session của họ và tôi thấy họ đang làm gì chỉ với một cú nhấp chuột. Điều này bao gồm toàn bộ lịch sử prompt của họ với agent. Tôi có ngữ cảnh về cách họ đạt được các đầu ra hiện tại. Giống như một máy cục bộ, tôi có thể chạy các lệnh terminal trong session này. Ở đây tôi sẽ chạy bun install và bun dev để khởi chạy dự án của mình. Bạn sẽ thấy trong một phút nữa, live preview của tôi trong trình duyệt ở bên cạnh sẽ hiện lên khi tôi mở port. Dự án demo chúng tôi có ở đây là một phiên bản "bình tĩnh" của Hackernews. Nó chỉ hiển thị ba câu chuyện hàng đầu trong ba tháng qua, điều này thư thái hơn một chút so với mỗi ngày. Tôi sẽ yêu cầu agent thay đổi color theme sang màu tím ở đây và bạn sẽ thấy ngay lập tức nó xuất hiện trong preview của tôi. Nó chỉ đang chạy mã. Agent cũng đã tự động tạo một commit cho tôi với một commit message đẹp và tôi có thể mở các diff và xem các diff, tất cả đều là những thứ tiêu chuẩn mà bạn mong đợi từ các coding agent. Giả sử chúng ta muốn làm một công việc thực sự. Tôi có các đồng đội của mình ở đây trong session này và tôi sẽ yêu cầu ACE thêm một số color theme bổ sung vào ứng dụng của tôi. Chúng tôi sẽ chọn model mà chúng tôi muốn sử dụng và rõ ràng đó là opus 4.6, sau đó ACE sẽ bắt đầu. Chúng tôi cũng có một summary block tiện dụng ở góc trên bên phải. Điều này giúp tôi cập nhật những thay đổi mới nhất trong session này dù là từ tôi hay người khác, có nghĩa là tôi có thể chuyển đổi giữa nhiều session của nhiều người đang chạy song song và luôn định hướng được những gì đang diễn ra để bạn không bị choáng ngợp bởi lượng thông tin và hoạt động. Nhưng điều quan trọng hơn là tôi muốn nói chuyện với các đồng đội của mình và tôi muốn thảo luận về những thay đổi chúng tôi đang thực hiện. Tôi có thể hỏi họ nghĩ gì về các thay đổi hiện tại. Họ có thể tự khởi động dev server vì hãy nhớ rằng tất cả chúng ta đều đang làm việc trên cùng một máy tính trên Claude. Đây không phải là vấn đề. Tất cả chúng ta đều có thể xem cùng một preview. Tất cả chúng ta đều có thể viết các lệnh terminal và xem các đầu ra được chia sẻ. Sẽ không ai nói "nó không chạy trên máy của tôi". Các đồng đội của tôi, Nate và Dan, đang tham gia vào đây. Họ đã chụp một số ảnh màn hình. Họ đang đề xuất một số feature thay thế, đặt câu hỏi. Bây giờ điều chúng ta sắp thấy là Nate sẽ yêu cầu tác nhân ACE thực hiện các thay đổi. Trong một phút, ai là Nate? Đó là Nate. Vậy là anh ấy nói "ACE đó là TL theme 2". Vậy là tôi thực sự đã khởi tạo session này nhưng Nate hiện đang prompt agent. Đây thực sự là đa người chơi. Cả hai chúng tôi đều chia sẻ coding session này. Agent cũng có thể đọc toàn bộ cuộc trò chuyện của chúng tôi. Đó là tất cả đầu vào cho prompt. Nếu chúng ta có thể nói về những điều sắp tới và chỉ cần nói "@ACE hãy làm đi", chúng sẽ làm. Loại interface giống Slack dễ tiếp cận này có nghĩa là việc truy cập vào một coding agent mang mọi người tham gia vào quá trình tạo phần mềm. Không chỉ các nhà phát triển, mà cả nhà thiết kế, PM (Quản lý dự án) và nhân viên hỗ trợ khách hàng đều có thể tham gia cùng một cuộc trò chuyện, xem điều gì đang xảy ra theo thời gian thực khi một feature được xây dựng. Nếu bạn đang nghĩ tại sao chúng ta không chỉ sử dụng Slack cho việc này? Tôi nghĩ đó là vì Slack sẽ không bao giờ trở thành một tool phát triển phần mềm đầy đủ feature, trừ khi họ thực sự thay đổi mô hình kinh doanh hiện tại. Nó sẽ không bao giờ có các primitive phù hợp. Tôi thực sự nghi ngờ nó sẽ thêm chúng. Các diff và lệnh terminal và những thứ tương tự không phải là lĩnh vực kinh doanh của Slack. Chúng tôi muốn ACE vì nó được thiết kế rõ ràng cho phát triển phần mềm, nhưng nó chào đón các thành viên nhóm khác nhiều hơn terminal của bạn. Dù sao, chúng ta quay lại việc shipping các thay đổi của mình ở đây. Chúng tôi thích giao diện này, vì vậy chúng tôi sẽ tạo một PR. Bởi vì cuối cùng tất cả mã này phải trở lại GitHub, phải không? Vì vậy, chúng tôi tạo PR này trực tiếp từ bên trong ACE. Chúng tôi đợi một phút và nó sẽ hiển thị preview của PR. Và sau đó chúng ta có thể nhấp vào một link dẫn đến nó ở đây trong giây lát.
Phát triển cộng tác và Môi trường bền vững
Sau khi nhấp, chúng ta thấy PR của chúng ta hoạt động tốt. Nó tương thích ngược và có liên kết trở lại phiên ACE trong mô tả. Không phải tất cả mọi người đều cần ở trong ACE để sử dụng tính năng này. Bạn có thể có một vài thành viên hoặc một nhóm trong ACE, trong đó những người còn lại tiếp tục sử dụng công cụ khác. Đôi khi bạn vẫn cần tương tác với mã nguồn. Tôi làm nhiều việc front-end và các tác nhân thường không giỏi về CSS, chúng không bao giờ làm đúng như tôi muốn. Chúng ta có thể mở dự án của mình trong VS Code ngay tại đây.
Và chúng ta có khả năng chỉnh sửa đa người dùng theo thời gian thực, bởi vì đây chỉ là một máy tính đám mây microvm. Mọi người đều làm việc trên cùng một máy tính. Tôi có thể đóng laptop của mình và tiếp tục làm việc, phiên làm việc không bị mất. Đồng đội của tôi có thể tiếp tục prompting ACE và đạt được tiến độ. Chúng tôi chưa có giao diện người dùng di động, nhưng đang xây dựng. Kiến trúc microvm này có nghĩa là nó sẽ hoạt động liền mạch. Tôi không cần phải dùng điện thoại để SSH vào terminal trên máy tính của mình, máy tính không cần phải hoạt động. Và tôi không cần phải mua một chiếc Mac mini để giữ mọi thứ luôn sẵn sàng. Tôi chỉ cần tương tác với tác nhân AI luôn hoạt động của mình trên đám mây.
Lập kế hoạch theo tác nhân và Quy trình làm việc tích hợp
Đối với các tính năng lớn hơn, phức tạp hơn, bạn dĩ nhiên sẽ muốn tác nhân AI của mình lập kế hoạch. Đây là một quy trình làm việc rất tiêu chuẩn ở thời điểm hiện tại. Tại đây, chúng ta đang trò chuyện về việc thêm các khung thời gian biến đổi vào ứng dụng Hackernews.com của chúng ta. Sau đó, tôi đã yêu cầu ACE lập một kế hoạch, và nó sẽ thực hiện khá nhanh chóng. Vậy chúng ta có thể mở kế hoạch đó, phải không?
Và đây là kế hoạch của chúng ta. Tôi có thể thấy con trỏ của đồng đội mình. Chúng ta có thể cùng nhau chỉnh sửa, quyết định xem có thích kế hoạch này không, nó có tốt không, và liệu nó có đạt được ý định của chúng ta không. Đồng đội Nate của tôi đang đưa ra gợi ý về việc sử dụng một dropdown cho giao diện người dùng thay vì một điều khiển phân đoạn. Sau đó, nó đã cập nhật các yêu cầu, vì vậy tác nhân AI biết phải thực hiện điều đó. Và khi tất cả chúng ta đều hài lòng với các chi tiết, chúng ta quay lại chat. Chúng ta có thể chỉ cần nói, @ACE, thực hiện điều này. Và nó biết ngữ cảnh là gì.
Bảng điều khiển và Quản lý ngữ cảnh đội nhóm
Giờ tôi sẽ chuyển sang bảng điều khiển của chúng ta trong ACE. Rất nhiều kế hoạch và thảo luận mà trước đây sẽ diễn ra trên Slack, GitHub hoặc Linear, giờ đây đang diễn ra trong các phiên ACE của chúng ta. Do đó, chúng ta có quyền truy cập vào ngữ cảnh phong phú về công việc đang được tiến hành và ACE có thể tóm tắt hữu ích cho bạn.
Thứ Hai này, tôi đang cố nhớ lại những gì mình đã bỏ dở vào thứ Sáu tuần trước. Và ACE đang nhắc nhở tôi tiếp tục làm việc với một số React hooks mà tôi đang tạo như một phần của tái cấu trúc lớn, điều này rất hữu ích vì trí nhớ của tôi khá kém sau một kỳ nghỉ cuối tuần dài. Từ đây, tôi có thể bắt đầu một phiên mới, hoặc trong phần "tiếp tục công việc này", tôi có thể nhấp một lần để mở phiên và tiếp tục PR chưa được merge của mình. Tôi cũng có thể xem danh sách các PR và issue đã hoàn thành gần đây để cảm thấy năng suất hơn.
Và ở bên phải, chúng ta có một mục team pulse. Mục này tóm tắt những gì đồng nghiệp của tôi đã làm trong vài ngày qua. Tôi có thể thấy Nate đang triển khai một lobby channel và David đang sửa các vấn đề về access token. Ngoài ra còn có một luồng dữ liệu thô về các issue và PR gần đây trong kho lưu trữ GitHub này. Cá nhân tôi thấy bản tóm tắt này hữu ích hơn nhiều. Một trong những thách thức lớn nhất của phát triển dựa trên tác nhân là tốc độ và khối lượng công việc khiến việc theo dõi những gì đồng nghiệp của bạn đang làm trở nên rất khó khăn. Giờ đây họ đang triển khai năm tính năng mỗi ngày thay vì chỉ nửa tính năng.
Bảng điều khiển này là nỗ lực đầu tiên của chúng tôi nhằm giúp các tác nhân AI chủ động mang ngữ cảnh xã hội đó đến cho bạn. Nếu tất cả các cuộc trò chuyện của bạn xung quanh cơ sở mã đều có sẵn cho các tác nhân AI, nó sẽ cung cấp cho chúng quyền truy cập vào một nền tảng thông tin xã hội, nơi chúng có thể giúp bạn định hướng mỗi buổi sáng và giữ cho bạn được điều chỉnh cùng với nhóm của mình. Chúng có thể thông báo cho bạn về các quyết định được đưa ra hoặc kéo bạn vào một cuộc trò chuyện khi ai đó sắp mở rộng tính năng mà bạn đã xây dựng ban đầu. Vì vậy, đây không còn là một loạt các phiên terminal đơn lẻ, ngắt kết nối trên các máy tính cá nhân. Điều này trở thành một môi trường sống động, thông minh, nơi mọi người chia sẻ cùng một không gian làm việc và ngữ cảnh.
Lấy lại thời gian để tạo phần mềm chất lượng
Tất cả những điều này thực sự là về việc lấy lại thời gian. Trước khi các tác nhân viết mã xuất hiện, không ai trong chúng ta có đủ thời gian và năng lượng để tạo ra sản phẩm theo cách chúng ta mong muốn. Tôi dám chắc rằng mọi người trong căn phòng này đều đã phát hành phần mềm mà họ không tự hào. Có thể bạn không có đủ thời gian để thực hiện nghiên cứu người dùng, xem xét các chi tiết thiết kế hoặc suy nghĩ kỹ về những hàm ý của các lựa chọn kiến trúc của mình. Không phải vì bạn không muốn mà vì đơn giản là không có đủ thời gian, bởi vì triển khai đã chiếm quá nhiều thời gian và công sức.
Nhưng chúng ta đã được trao lại rất nhiều thời gian đó. Chúng ta có cơ hội không chỉ đi nhanh hơn và tạo ra một đống phần mềm tồi tệ tương tự, mà thay vào đó là tạo ra phần mềm tốt hơn nhiều thông qua tư duy phản biện nghiêm ngặt hơn và sự phối hợp tốt hơn trong giai đoạn lập kế hoạch. Bằng cách thực hiện nhiều khám phá, nhiều nghiên cứu hơn và suy nghĩ sâu sắc hơn về các vấn đề so với trước đây. Các tác nhân AI cho phép chúng ta mở rộng quy mô bản thân và nhóm của mình theo cách mà, nếu được thực hiện đúng, sẽ dẫn đến phần mềm chất lượng tốt hơn.
Tôi nghĩ nhiều người hiện đang nhận ra rằng trong một thế giới phần mềm nhanh chóng, giá rẻ, chất lượng trở thành yếu tố khác biệt mới. Tiêu chuẩn đang được đặt ra cao hơn nhiều, và sự khéo léo là điều khiến bạn nổi bật so với những phần mềm được viết một cách bản năng, cẩu thả. Nhưng sự khéo léo vẫn tốn thời gian và năng lượng. Nó không miễn phí. Và để có được thời gian và năng lượng cần thiết cho nó, bạn cần làm ít việc hơn nhưng tốt hơn, điều này đòi hỏi rất nhiều sự phối hợp mạnh mẽ. Cũng có nhiều yếu tố gây xao nhãng hơn bao giờ hết. Rất dễ để nhắc lệnh sai hướng hoặc thêm nhiều tính năng không cần thiết, không hữu ích vào sản phẩm của bạn.
Tôi nghĩ ước mơ của tôi là chúng ta sẽ có những công cụ, dù là ACE hay các công cụ khác, tạo ra các môi trường nơi các nhóm có thể cùng nhau suy nghĩ một cách nghiêm túc về các vấn đề khó. Các công cụ tác nhân của chúng ta nên giúp chúng ta thực hiện công việc chất lượng cao hơn, nhanh chóng đạt được sự phối hợp và xây dựng một vài sản phẩm đặc biệt thay vì hàng ngàn sản phẩm kém chất lượng.
Lời kêu gọi hành động và Tài nguyên
Cảm ơn bạn rất nhiều vì đã lắng nghe. Nếu bạn muốn truy cập sớm vào ACE, chúng tôi dự kiến sẽ phát hành nó trong vài tháng tới. Mã QR này sẽ đưa bạn đến một biểu mẫu nơi bạn nhập tên người dùng GitHub của mình, và sau đó chúng tôi sẽ cấp cho bạn quyền truy cập sớm ngay khi nó ra mắt. Bạn có thể đọc thêm về nhóm GitHub next và nghiên cứu của họ trên GitHubnext.com. Và tất cả công việc cũng như bài viết của tôi đều có trên MaggieAppleton.com, tôi sẽ đăng các slide và ghi chú cho bài trình bày này lên đó trong một hoặc hai ngày tới. Cảm ơn.
TL;DR
- Mô hình năng suất cá nhân với
agentkhông đủ cho phát triển phần mềm, vốn là một môn thể thao đồng đội; việc mở rộng cá nhân chỉ làm trầm trọng thêm các vấn đề về phối hợp và đồng bộ. - Nút thắt cổ chai mới trong phát triển phần mềm không phải là cách xây dựng mà là quyết định nên xây dựng gì, do việc tạo mã trở nên quá nhanh và rẻ nhờ
agent, làm tăngchi phí cơ hộivà đòi hỏi sự đồng bộ sớm hơn. - ACE (Agent Collaboration Environment) là một
prototypecủa GitHub Labs, cung cấp môi trường cộng tác đa người chơi, dựa trênmicro VM, nơi con người vàagentcó thể cùng nhau lập kế hoạch, phát triển và đồng bộ hóa liên tục trước và trong quá trình triển khai.
Điểm chính
- Hạn chế của năng suất cá nhân: Mặc dù
coding agentcó thể tăng tốc độ triển khai cá nhân, nhưng chúng không giải quyết được các thách thức cố hữu của phát triển phần mềm nhóm, nơi sự đồng bộ và phối hợp là tối quan trọng. - Chi phí cơ hội mới: Với tốc độ tạo mã nhanh chóng, câu hỏi khó nhất không còn là "làm thế nào để xây dựng nó?" mà là "chúng ta có nên xây dựng nó không?".
Chi phí cơ hộicủa việc chọn một tính năng thay vì tính năng khác trở thành chi phí thực sự. - Công cụ cũ không phù hợp với kỷ nguyên mới: Các công cụ phối hợp hiện có như
GitHub,Slack,Jirakhông được thiết kế cho sự nhanh chóng và khối lượng đầu ra của phát triểnagentic, dẫn đến quá tảipull requestvà thiếungữ cảnh. - Cần đồng bộ hóa sớm và liên tục: Sự đồng bộ hóa không thể dồn gánh nặng vào giai đoạn
reviewcuối cùng. Lập kế hoạch, thu thậpngữ cảnh, ra quyết định và phát triển cần diễn ra như một chu trình liên tục và tích hợp. - Tầm quan trọng của
ngữ cảnhxã hội: Hầu hếtngữ cảnhcần thiết để xây dựng đúng thứ không nằm trongcơ sở mãmà trong suy nghĩ của con người (ví dụ:ngữ cảnh nghiệp vụ,tầm nhìn sản phẩm,thông tin chi tiết từ nghiên cứu người dùng).Agentkhông thể tự khám phá điều này. - Giải pháp là môi trường cộng tác
agent: Các công cụ như ACE cung cấp một không gian làm việc chung, nơi cả người vàagentcó thể tương tác, chia sẻngữ cảnhvà làm việc trên cùng một máy ảo đám mây (micro VM), hỗ trợ phát triển đa người chơi theo thời gian thực. - Lập kế hoạch và thực hiện tích hợp: Trong các môi trường này,
agentcó thể tạo kế hoạch phát triển mà nhóm có thể cùng nhau chỉnh sửa và phê duyệt, sau đóagentsẽ thực hiện kế hoạch đó, đảm bảo mọi người đồng bộ về ý định trước khi mã được viết. - Quản lý
ngữ cảnhnhóm chủ động:Bảng điều khiểnvà các tính năngteam pulsegiúp tóm tắt công việc đang tiến hành, nhắc nhở cá nhân và cung cấpngữ cảnhxã hội về hoạt động của đồng nghiệp, giảm gánh nặng theo dõi trong bối cảnh tốc độ phát triển cao.
Từ vựng
agent— AI agent / tác nhân AInăng suất— productivitychi phí cơ hội— opportunity costngữ cảnh— contextpull request(PR) — pull request (yêu cầu hợp nhất mã)issue— issue (vấn đề/phiếu công việc)merge conflict— merge conflict (xung đột hợp nhất)cơ sở mã— codebaseAgent Collaboration Environment(ACE) — Agent Collaboration Environment (Môi trường Cộng tác Tác nhân)micro VM— micro virtual machine (máy ảo siêu nhỏ)prompt— prompt (câu lệnh/yêu cầu gửi cho AI)bảng điều khiển— dashboard
Nội dung chi tiết
Giới thiệu & Mục tiêu
Vâng, bài nói chuyện này có tên "Một nhà phát triển, hai tá agent nhưng không có sự đồng bộ." Đây là lý do tại sao chúng ta cần kỹ thuật AI cộng tác. Trước tiên, xin giới thiệu nhanh. Tôi là Maggie. Tôi làm việc tại GitHub với tư cách là kỹ sư nghiên cứu cấp cao. Ít nhất đó là chức danh của tôi. Thực ra tôi là một nhà thiết kế, từ thời mà thiết kế và kỹ thuật là hai lĩnh vực riêng biệt. Và tiếp theo là nhóm lab trong GitHub. Chúng tôi chuyên thực hiện các dự án thử nghiệm, rủi ro hơn so với phần còn lại của tổ chức. Chúng tôi thích gọi đó là "phòng ban thử nghiệm và khám phá". Và giống như mọi người khác, chúng tôi đang cố gắng định hình các tool agentic mới cho nhà phát triển.
Năng suất Cá nhân và Hạn chế
Tôi nghĩ đây là điều mà nhiều người đang hình dung về đỉnh cao của năng suất nhà phát triển hiện nay, phải không? Nó giống như một bức tường đầy các coding agent chạy trên terminal, tất cả song song trên một máy của một người. Tôi thích gọi đây là lý thuyết "một người với hai tá cords" của tương lai. Lời hứa mà chúng ta được nghe là một người với một đội quân agent sẽ làm công việc của cả một đội ngũ nhà phát triển. Vấn đề chính với giấc mơ này là nó giả định phần mềm được tạo ra bởi một người. Tất cả các tool này đều là interface dành cho một người chơi. Và chúng tập trung vào việc mở rộng quy mô công việc của cá nhân. Nhưng việc mở rộng quy mô một cá nhân có giá trị hạn chế. Bởi vì phần mềm không được tạo ra bởi một người duy nhất trong một môi trường cô lập. Đây là một môn thể thao đồng đội và mọi người xây dựng nó cần phải đồng ý về những gì họ đang xây dựng và tại sao. Tin rằng năng suất cá nhân dẫn đến phần mềm tuyệt vời cũng giống như logic "chín người phụ nữ làm ra một em bé trong một tháng". Đầu ra cá nhân nhiều hơn không giải quyết được các vấn đề yêu cầu giao tiếp và phối hợp; nó làm cho chúng tồi tệ hơn.
Nút Thắt Cổ Chai Mới: Quyết Định Nên Xây Dựng Gì
Việc triển khai đang nhanh chóng trở thành một vấn đề đã được giải quyết, phải không? Có lẽ mọi người ở đây đều tin điều đó. Viết mã bây giờ rất nhanh. Nó ngày càng rẻ hơn và chất lượng đang tăng lên. Câu hỏi khó không còn là làm thế nào để xây dựng nó, mà là chúng ta CÓ NÊN xây dựng nó hay không. Đồng ý về những gì cần xây dựng là nút thắt cổ chai mới. Vì vậy, mọi người trong nhóm của bạn cần tham gia vào việc đặt câu hỏi: "Chúng ta đang làm đúng việc không?", "Chúng ta có đang sử dụng năng lượng đúng chỗ không?", và "Làm thế nào để chúng ta tạo ra tác động lớn nhất?". Khi việc sản xuất rẻ, chi phí cơ hội (opportunity cost) trở thành chi phí thực sự. Bạn không thể xây dựng mọi thứ, và bất cứ điều gì bạn chọn đều phải đánh đổi bằng mọi thứ khác. Bất kỳ ai xuất bản phần mềm trong một nhóm đều biết đây không phải là vấn đề mới. Sự đồng bộ luôn là một nút thắt cổ chai, nhưng các agent đã khiến chi phí của việc không đồng bộ trong một nhóm trở nên cao hơn rất nhiều. Điều làm cho nó tệ hơn là tất cả các tool phối hợp của chúng ta vẫn thuộc về một kỷ nguyên khác. GitHub, Slack, Jira, Linear và các công cụ tương tự, như hiện tại, không được thiết kế cho thế giới phát triển agentic. Chúng ta đang đổ hàng loạt đầu ra agentic vào các nền tảng được xây dựng cho một cách phát triển phần mềm đã lỗi thời. Tôi biết tôi làm việc tại GitHub nên điều này có thể nghe có vẻ "ngoại đạo" khi tôi nói ra, nhưng tôi hứa nó không gây tranh cãi. Rất ít người trong nội bộ tin rằng PR và issue là tương lai của phát triển phần mềm, và có rất nhiều người trong chúng tôi đang cố gắng khám phá những gì sẽ đến tiếp theo.
Quá Trình Phát Triển Đã Thay Đổi và Hậu Quả
Đây là cách quy trình phát triển đã từng diễn ra. Chúng ta có giai đoạn lập kế hoạch, giai đoạn xây dựng và giai đoạn review. Chúng ta có tất cả các điểm tiếp xúc để đồng bộ hóa trong suốt quá trình và nó đủ chậm để chúng ta có thời gian trò chuyện trong Slack và các cuộc họp Zoom, bình luận về issue và draft PR để có thể thảo luận chi tiết, mọi người có thể đóng góp ý kiến và nhận lời khuyên từ chuyên môn của đồng nghiệp và cấp trên, phát hiện lỗi và điều chỉnh nếu có vấn đề. Nhưng đến khi mã được review và merge, cả nhóm đã nhìn thấy công việc đang diễn ra và họ đều hiểu sơ bộ về tình hình. Giờ đây, "cửa sổ triển khai" đã thu hẹp lại, và vì việc triển khai không còn tốn kém và tốn thời gian như trước, chúng ta nghĩ rằng không cần lập kế hoạch nhiều nữa. Do đó, hầu hết các điểm tiếp xúc ban đầu đó thực sự biến mất. Chúng ta biết rằng thời gian review cho mã được sinh mã thực tế đã tăng lên, điều này tạo ra nhiều điểm đồng bộ hơn nhưng chúng lại ở phía sai của quá trình triển khai. Thời gian giữa việc tạo một issue và một agent mở PR giờ chỉ còn vài phút. Mã quá rẻ đến nỗi chúng ta không dừng lại để suy nghĩ kỹ trước khi prompt nó. Không may, hầu hết các coding agent còn có local plan mode (chế độ lập kế hoạch cục bộ) hoàn toàn không được chia sẻ với người khác. Vì vậy, bạn thậm chí không kiểm tra với nhóm của mình xem kế hoạch mà agent đưa ra có tốt không trước khi ship nó (nếu bạn thậm chí còn đọc nó), và do đó chúng ta mất thêm nhiều điểm đồng bộ.
Hậu Quả Của Thiếu Đồng Bộ và Giải Pháp
Điều này khiến gánh nặng của toàn bộ sự đồng bộ dồn lên pull request. Tất cả các điểm kiểm tra giờ đây đến sau khi triển khai, vào cuối quy trình, khi đã quá muộn. Và đó không phải là điều mà PR được thiết kế để làm ngay từ đầu, vì vậy chúng hoạt động kém hiệu quả ở vai trò này. Không có tool hiện tại nào của chúng ta cung cấp cho các nhóm một không gian chung để thảo luận kế hoạch, thu thập đúng ngữ cảnh và làm việc với các agent như một tập thể. Tất cả chúng ta đều đang trải qua những hậu quả của việc này. Đi nhanh mà không có sự đồng bộ tốt dẫn đến lãng phí công sức – ví dụ như các feature không ai yêu cầu và không thực sự giải quyết vấn đề thực tế, hoặc nhận feedback quan trọng sau khi bạn hoàn thành một thứ gì đó và cuối cùng phải vứt bỏ toàn bộ. Và còn chiều sâu điều phối (coordination depth). Đây là khi bạn gặp phải các merge conflict rất phức tạp vì các agent sẽ chạm vào cùng các file hoặc nhà phát triển thậm chí làm việc trùng lặp vì cả hai đều nhận một việc và cố gắng hoàn thành nó trong một ngày. Hoặc như chúng ta đều biết, tất cả chúng ta đều có hàng đống PR khổng lồ cần review mà không ai có ngữ cảnh và thậm chí không biết chúng chứa gì. Vậy làm thế nào để chúng ta giải quyết vấn đề này? Chúng ta cần các tool giúp mọi người trong nhóm đồng bộ HÓA TRƯỚC KHI các agent bắt đầu làm việc, chứ không phải SAU ĐÓ. Sự đồng bộ cần phải diễn ra liên tục song song với việc triển khai. Lập kế hoạch và xây dựng không còn là các giai đoạn riêng biệt; chúng giờ là một chu trình. Các tool của tương lai cần đưa việc lập kế hoạch, thu thập ngữ cảnh, ra quyết định và phát triển về chung một mái nhà. Điều này đặc biệt đúng vì hầu hết ngữ cảnh bạn cần để đồng bộ và xây dựng đúng thứ không nằm trong cơ sở mã. Nó nằm trong đầu mọi người. Ngữ cảnh nghiệp vụ (business context) và các nguồn lực tài chính quyết định điều gì là đúng đắn để xây dựng. Động lực chính trị về người phụ trách và người đưa ra quyết định. Tầm nhìn sản phẩm (product vision) từ các lãnh đạo, thông tin chi tiết từ nghiên cứu người dùng (user research insight) từ các nhà thiết kế và lịch sử của tổ chức về những gì bạn đã xây dựng trước đây. Tất cả những điều này đều vô cùng quan trọng khi bạn quyết định điều gì là đúng đắn để nhóm của bạn xây dựng. Và các agent không bao giờ có thể tự mình khám phá ngữ cảnh này. Bạn cần một cách để con người chia sẻ nó sớm và một cách tự nhiên mà không cần thêm quy trình hay gánh nặng.
ACE: Môi Trường Cộng Tác Tác Nhân
Tất cả những điều này đã rất rõ ràng với chúng tôi trong nhóm next. Và chúng tôi đã xây dựng một prototype nghiên cứu mới nhằm khám phá cách chúng ta có thể giải quyết một số vấn đề này. Nó được gọi là ACE, viết tắt của Agent Collaboration Environment (Môi trường Cộng tác Tác nhân). Đây chưa phải là một sản phẩm chính thức. Vì vậy, nếu nó trông còn khá thô sơ, thì đúng là như vậy. Chúng tôi sắp ra mắt bản technical preview và sẽ thử nghiệm nó với vài nghìn người. Sau đó, chúng tôi sẽ học hỏi cách mọi người cộng tác và iterate từ đó.
Trải nghiệm ACE: Công cụ Phát triển Đa Người Chơi
Vậy là chúng ta đang ở trong ACE. Nó có lẽ trông khá quen thuộc. Chúng tôi không tái tạo lại bất kỳ bánh xe nào nhiều hơn mức cần thiết. Nó giống một chút như FLAQ GitHub, Copilot, và một loạt máy tính đám mây có một đứa con vậy. Chúng ta có danh sách session ở bên trái, và session là nơi bạn làm việc, phải không? Đó là một cuộc trò chuyện đa người chơi. Nó giống như một kênh Slack. Tôi có đồng đội ở đây và tôi có thể nói chuyện với họ về công việc chúng tôi đang làm, nhưng tôi cũng có các coding agent của mình ở đây. Tuy nhiên, mỗi session không chỉ là một kênh trò chuyện. Nó còn được hỗ trợ bởi một micro VM (máy ảo siêu nhỏ), tức là một máy tính sandbox (môi trường biệt lập) trên đám mây trên một Git branch riêng. Các thay đổi chúng tôi thực hiện trong mỗi session đều được cô lập (isolated) để chúng tôi có thể làm việc trên các task song song và chuyển đổi tức thì giữa chúng. Nếu tôi muốn hỏi ý kiến một đồng đội về một feature tôi đang xây dựng, không ai phải stash các thay đổi Git của họ và pull về một branch mới hoặc vật lộn với các worktree cục bộ. Tôi chỉ cần nhảy vào session của họ và tôi thấy họ đang làm gì chỉ với một cú nhấp chuột. Điều này bao gồm toàn bộ lịch sử prompt của họ với agent. Tôi có ngữ cảnh về cách họ đạt được các đầu ra hiện tại. Giống như một máy cục bộ, tôi có thể chạy các lệnh terminal trong session này. Ở đây tôi sẽ chạy bun install và bun dev để khởi chạy dự án của mình. Bạn sẽ thấy trong một phút nữa, live preview của tôi trong trình duyệt ở bên cạnh sẽ hiện lên khi tôi mở port. Dự án demo chúng tôi có ở đây là một phiên bản "bình tĩnh" của Hackernews. Nó chỉ hiển thị ba câu chuyện hàng đầu trong ba tháng qua, điều này thư thái hơn một chút so với mỗi ngày. Tôi sẽ yêu cầu agent thay đổi color theme sang màu tím ở đây và bạn sẽ thấy ngay lập tức nó xuất hiện trong preview của tôi. Nó chỉ đang chạy mã. Agent cũng đã tự động tạo một commit cho tôi với một commit message đẹp và tôi có thể mở các diff và xem các diff, tất cả đều là những thứ tiêu chuẩn mà bạn mong đợi từ các coding agent. Giả sử chúng ta muốn làm một công việc thực sự. Tôi có các đồng đội của mình ở đây trong session này và tôi sẽ yêu cầu ACE thêm một số color theme bổ sung vào ứng dụng của tôi. Chúng tôi sẽ chọn model mà chúng tôi muốn sử dụng và rõ ràng đó là opus 4.6, sau đó ACE sẽ bắt đầu. Chúng tôi cũng có một summary block tiện dụng ở góc trên bên phải. Điều này giúp tôi cập nhật những thay đổi mới nhất trong session này dù là từ tôi hay người khác, có nghĩa là tôi có thể chuyển đổi giữa nhiều session của nhiều người đang chạy song song và luôn định hướng được những gì đang diễn ra để bạn không bị choáng ngợp bởi lượng thông tin và hoạt động. Nhưng điều quan trọng hơn là tôi muốn nói chuyện với các đồng đội của mình và tôi muốn thảo luận về những thay đổi chúng tôi đang thực hiện. Tôi có thể hỏi họ nghĩ gì về các thay đổi hiện tại. Họ có thể tự khởi động dev server vì hãy nhớ rằng tất cả chúng ta đều đang làm việc trên cùng một máy tính trên Claude. Đây không phải là vấn đề. Tất cả chúng ta đều có thể xem cùng một preview. Tất cả chúng ta đều có thể viết các lệnh terminal và xem các đầu ra được chia sẻ. Sẽ không ai nói "nó không chạy trên máy của tôi". Các đồng đội của tôi, Nate và Dan, đang tham gia vào đây. Họ đã chụp một số ảnh màn hình. Họ đang đề xuất một số feature thay thế, đặt câu hỏi. Bây giờ điều chúng ta sắp thấy là Nate sẽ yêu cầu tác nhân ACE thực hiện các thay đổi. Trong một phút, ai là Nate? Đó là Nate. Vậy là anh ấy nói "ACE đó là TL theme 2". Vậy là tôi thực sự đã khởi tạo session này nhưng Nate hiện đang prompt agent. Đây thực sự là đa người chơi. Cả hai chúng tôi đều chia sẻ coding session này. Agent cũng có thể đọc toàn bộ cuộc trò chuyện của chúng tôi. Đó là tất cả đầu vào cho prompt. Nếu chúng ta có thể nói về những điều sắp tới và chỉ cần nói "@ACE hãy làm đi", chúng sẽ làm. Loại interface giống Slack dễ tiếp cận này có nghĩa là việc truy cập vào một coding agent mang mọi người tham gia vào quá trình tạo phần mềm. Không chỉ các nhà phát triển, mà cả nhà thiết kế, PM (Quản lý dự án) và nhân viên hỗ trợ khách hàng đều có thể tham gia cùng một cuộc trò chuyện, xem điều gì đang xảy ra theo thời gian thực khi một feature được xây dựng. Nếu bạn đang nghĩ tại sao chúng ta không chỉ sử dụng Slack cho việc này? Tôi nghĩ đó là vì Slack sẽ không bao giờ trở thành một tool phát triển phần mềm đầy đủ feature, trừ khi họ thực sự thay đổi mô hình kinh doanh hiện tại. Nó sẽ không bao giờ có các primitive phù hợp. Tôi thực sự nghi ngờ nó sẽ thêm chúng. Các diff và lệnh terminal và những thứ tương tự không phải là lĩnh vực kinh doanh của Slack. Chúng tôi muốn ACE vì nó được thiết kế rõ ràng cho phát triển phần mềm, nhưng nó chào đón các thành viên nhóm khác nhiều hơn terminal của bạn. Dù sao, chúng ta quay lại việc shipping các thay đổi của mình ở đây. Chúng tôi thích giao diện này, vì vậy chúng tôi sẽ tạo một PR. Bởi vì cuối cùng tất cả mã này phải trở lại GitHub, phải không? Vì vậy, chúng tôi tạo PR này trực tiếp từ bên trong ACE. Chúng tôi đợi một phút và nó sẽ hiển thị preview của PR. Và sau đó chúng ta có thể nhấp vào một link dẫn đến nó ở đây trong giây lát.
Phát triển cộng tác và Môi trường bền vững
Sau khi nhấp, chúng ta thấy PR của chúng ta hoạt động tốt. Nó tương thích ngược và có liên kết trở lại phiên ACE trong mô tả. Không phải tất cả mọi người đều cần ở trong ACE để sử dụng tính năng này. Bạn có thể có một vài thành viên hoặc một nhóm trong ACE, trong đó những người còn lại tiếp tục sử dụng công cụ khác. Đôi khi bạn vẫn cần tương tác với mã nguồn. Tôi làm nhiều việc front-end và các tác nhân thường không giỏi về CSS, chúng không bao giờ làm đúng như tôi muốn. Chúng ta có thể mở dự án của mình trong VS Code ngay tại đây.
Và chúng ta có khả năng chỉnh sửa đa người dùng theo thời gian thực, bởi vì đây chỉ là một máy tính đám mây microvm. Mọi người đều làm việc trên cùng một máy tính. Tôi có thể đóng laptop của mình và tiếp tục làm việc, phiên làm việc không bị mất. Đồng đội của tôi có thể tiếp tục prompting ACE và đạt được tiến độ. Chúng tôi chưa có giao diện người dùng di động, nhưng đang xây dựng. Kiến trúc microvm này có nghĩa là nó sẽ hoạt động liền mạch. Tôi không cần phải dùng điện thoại để SSH vào terminal trên máy tính của mình, máy tính không cần phải hoạt động. Và tôi không cần phải mua một chiếc Mac mini để giữ mọi thứ luôn sẵn sàng. Tôi chỉ cần tương tác với tác nhân AI luôn hoạt động của mình trên đám mây.
Lập kế hoạch theo tác nhân và Quy trình làm việc tích hợp
Đối với các tính năng lớn hơn, phức tạp hơn, bạn dĩ nhiên sẽ muốn tác nhân AI của mình lập kế hoạch. Đây là một quy trình làm việc rất tiêu chuẩn ở thời điểm hiện tại. Tại đây, chúng ta đang trò chuyện về việc thêm các khung thời gian biến đổi vào ứng dụng Hackernews.com của chúng ta. Sau đó, tôi đã yêu cầu ACE lập một kế hoạch, và nó sẽ thực hiện khá nhanh chóng. Vậy chúng ta có thể mở kế hoạch đó, phải không?
Và đây là kế hoạch của chúng ta. Tôi có thể thấy con trỏ của đồng đội mình. Chúng ta có thể cùng nhau chỉnh sửa, quyết định xem có thích kế hoạch này không, nó có tốt không, và liệu nó có đạt được ý định của chúng ta không. Đồng đội Nate của tôi đang đưa ra gợi ý về việc sử dụng một dropdown cho giao diện người dùng thay vì một điều khiển phân đoạn. Sau đó, nó đã cập nhật các yêu cầu, vì vậy tác nhân AI biết phải thực hiện điều đó. Và khi tất cả chúng ta đều hài lòng với các chi tiết, chúng ta quay lại chat. Chúng ta có thể chỉ cần nói, @ACE, thực hiện điều này. Và nó biết ngữ cảnh là gì.
Bảng điều khiển và Quản lý ngữ cảnh đội nhóm
Giờ tôi sẽ chuyển sang bảng điều khiển của chúng ta trong ACE. Rất nhiều kế hoạch và thảo luận mà trước đây sẽ diễn ra trên Slack, GitHub hoặc Linear, giờ đây đang diễn ra trong các phiên ACE của chúng ta. Do đó, chúng ta có quyền truy cập vào ngữ cảnh phong phú về công việc đang được tiến hành và ACE có thể tóm tắt hữu ích cho bạn.
Thứ Hai này, tôi đang cố nhớ lại những gì mình đã bỏ dở vào thứ Sáu tuần trước. Và ACE đang nhắc nhở tôi tiếp tục làm việc với một số React hooks mà tôi đang tạo như một phần của tái cấu trúc lớn, điều này rất hữu ích vì trí nhớ của tôi khá kém sau một kỳ nghỉ cuối tuần dài. Từ đây, tôi có thể bắt đầu một phiên mới, hoặc trong phần "tiếp tục công việc này", tôi có thể nhấp một lần để mở phiên và tiếp tục PR chưa được merge của mình. Tôi cũng có thể xem danh sách các PR và issue đã hoàn thành gần đây để cảm thấy năng suất hơn.
Và ở bên phải, chúng ta có một mục team pulse. Mục này tóm tắt những gì đồng nghiệp của tôi đã làm trong vài ngày qua. Tôi có thể thấy Nate đang triển khai một lobby channel và David đang sửa các vấn đề về access token. Ngoài ra còn có một luồng dữ liệu thô về các issue và PR gần đây trong kho lưu trữ GitHub này. Cá nhân tôi thấy bản tóm tắt này hữu ích hơn nhiều. Một trong những thách thức lớn nhất của phát triển dựa trên tác nhân là tốc độ và khối lượng công việc khiến việc theo dõi những gì đồng nghiệp của bạn đang làm trở nên rất khó khăn. Giờ đây họ đang triển khai năm tính năng mỗi ngày thay vì chỉ nửa tính năng.
Bảng điều khiển này là nỗ lực đầu tiên của chúng tôi nhằm giúp các tác nhân AI chủ động mang ngữ cảnh xã hội đó đến cho bạn. Nếu tất cả các cuộc trò chuyện của bạn xung quanh cơ sở mã đều có sẵn cho các tác nhân AI, nó sẽ cung cấp cho chúng quyền truy cập vào một nền tảng thông tin xã hội, nơi chúng có thể giúp bạn định hướng mỗi buổi sáng và giữ cho bạn được điều chỉnh cùng với nhóm của mình. Chúng có thể thông báo cho bạn về các quyết định được đưa ra hoặc kéo bạn vào một cuộc trò chuyện khi ai đó sắp mở rộng tính năng mà bạn đã xây dựng ban đầu. Vì vậy, đây không còn là một loạt các phiên terminal đơn lẻ, ngắt kết nối trên các máy tính cá nhân. Điều này trở thành một môi trường sống động, thông minh, nơi mọi người chia sẻ cùng một không gian làm việc và ngữ cảnh.
Lấy lại thời gian để tạo phần mềm chất lượng
Tất cả những điều này thực sự là về việc lấy lại thời gian. Trước khi các tác nhân viết mã xuất hiện, không ai trong chúng ta có đủ thời gian và năng lượng để tạo ra sản phẩm theo cách chúng ta mong muốn. Tôi dám chắc rằng mọi người trong căn phòng này đều đã phát hành phần mềm mà họ không tự hào. Có thể bạn không có đủ thời gian để thực hiện nghiên cứu người dùng, xem xét các chi tiết thiết kế hoặc suy nghĩ kỹ về những hàm ý của các lựa chọn kiến trúc của mình. Không phải vì bạn không muốn mà vì đơn giản là không có đủ thời gian, bởi vì triển khai đã chiếm quá nhiều thời gian và công sức.
Nhưng chúng ta đã được trao lại rất nhiều thời gian đó. Chúng ta có cơ hội không chỉ đi nhanh hơn và tạo ra một đống phần mềm tồi tệ tương tự, mà thay vào đó là tạo ra phần mềm tốt hơn nhiều thông qua tư duy phản biện nghiêm ngặt hơn và sự phối hợp tốt hơn trong giai đoạn lập kế hoạch. Bằng cách thực hiện nhiều khám phá, nhiều nghiên cứu hơn và suy nghĩ sâu sắc hơn về các vấn đề so với trước đây. Các tác nhân AI cho phép chúng ta mở rộng quy mô bản thân và nhóm của mình theo cách mà, nếu được thực hiện đúng, sẽ dẫn đến phần mềm chất lượng tốt hơn.
Tôi nghĩ nhiều người hiện đang nhận ra rằng trong một thế giới phần mềm nhanh chóng, giá rẻ, chất lượng trở thành yếu tố khác biệt mới. Tiêu chuẩn đang được đặt ra cao hơn nhiều, và sự khéo léo là điều khiến bạn nổi bật so với những phần mềm được viết một cách bản năng, cẩu thả. Nhưng sự khéo léo vẫn tốn thời gian và năng lượng. Nó không miễn phí. Và để có được thời gian và năng lượng cần thiết cho nó, bạn cần làm ít việc hơn nhưng tốt hơn, điều này đòi hỏi rất nhiều sự phối hợp mạnh mẽ. Cũng có nhiều yếu tố gây xao nhãng hơn bao giờ hết. Rất dễ để nhắc lệnh sai hướng hoặc thêm nhiều tính năng không cần thiết, không hữu ích vào sản phẩm của bạn.
Tôi nghĩ ước mơ của tôi là chúng ta sẽ có những công cụ, dù là ACE hay các công cụ khác, tạo ra các môi trường nơi các nhóm có thể cùng nhau suy nghĩ một cách nghiêm túc về các vấn đề khó. Các công cụ tác nhân của chúng ta nên giúp chúng ta thực hiện công việc chất lượng cao hơn, nhanh chóng đạt được sự phối hợp và xây dựng một vài sản phẩm đặc biệt thay vì hàng ngàn sản phẩm kém chất lượng.
Lời kêu gọi hành động và Tài nguyên
Cảm ơn bạn rất nhiều vì đã lắng nghe. Nếu bạn muốn truy cập sớm vào ACE, chúng tôi dự kiến sẽ phát hành nó trong vài tháng tới. Mã QR này sẽ đưa bạn đến một biểu mẫu nơi bạn nhập tên người dùng GitHub của mình, và sau đó chúng tôi sẽ cấp cho bạn quyền truy cập sớm ngay khi nó ra mắt. Bạn có thể đọc thêm về nhóm GitHub next và nghiên cứu của họ trên GitHubnext.com. Và tất cả công việc cũng như bài viết của tôi đều có trên MaggieAppleton.com, tôi sẽ đăng các slide và ghi chú cho bài trình bày này lên đó trong một hoặc hai ngày tới. Cảm ơn.