Building an AI-Native Development Workflow

1. Mở đầu và agenda

Speaker mở đầu bằng slide Agenda. Mục thứ hai của agenda là "Rethinking the software development life cycle". Speaker giải thích mục này là cách nghĩ và nghĩ lại các workflow của mình khi làm việc với AI, vì giờ AI đã nằm hẳn trong cuộc chơi. Sau đó chị sẽ nói về việc xây dựng human and AI collaboration: nó trông như thế nào, cần làm những bước gì. Phần cuối là in practice: những việc bạn thật sự bắt tay làm vào sáng thứ Hai để bắt đầu. Khán giả vỗ tay, chị cảm ơn ba lần rồi vào bài.

2. AI native development là gì, và khác AI embedded ra sao

Câu hỏi đầu tiên: AI native development là gì? Theo speaker, đó là quá trình thiết kế sản phẩm, platform và workflow của mình với AI là một phần cốt lõi của quy trình. Nó không còn là kiểu nghĩ "thôi thì chỗ này dùng Copilot Chat một chút, chỗ kia dùng Copilot code completions một chút". Đây là thiết kế lại workflow để AI trở thành một thành phần cốt lõi. AI được tính đến ngay từ nền móng, với kỳ vọng là nó sẽ tham gia vào phần việc đã được giới hạn phạm vi (scoped work) trên toàn bộ software development lifecycle.

Chị nhấn mạnh đây là một thay đổi rất lớn, và nó đã đổi cả nội dung các cuộc trao đổi. Trước đây khi nói chuyện với khách hàng, câu hỏi thường là "làm sao dùng AI để giúp tôi viết code" hoặc "dùng AI cho use case XY này thế nào". Giờ người ta hỏi: "development sẽ trông ra sao nếu AI là một bên tham gia chủ động ngay từ đầu?". Vậy khi chị nói AI native development, chị nói về trạng thái AI là first class participant trong lifecycle và trong các workflow đó.

Tiếp theo chị tách hai cách tiếp cận nghe thì giống nhau nhưng rất khác nhau, vì người ta hay lẫn embedded thành native và ngược lại:

• AI embedded: thêm AI vào workflow phát triển đang có. Bạn không thật sự đổi gì cả, chỉ bỏ AI vào hỗn hợp.
• AI native: thiết kế workflow phát triển xoay quanh các agent, quanh workflow của mình trong quy trình đó. AI nằm ở lõi.

Chị hứa "đừng lo, lát nữa có ví dụ". Tóm lại một câu: embedded là bắt đầu từ process rồi thêm AI vào; native là bắt đầu từ outcome rồi xây AI quanh outcome đó, để có thể dùng đi dùng lại trong tình huống ấy.

3. Ví dụ AI embedded: gắn AI vào từng khúc SDLC

Ví dụ đầu tiên là AI embedded. Trên slide là một software development lifecycle quen thuộc: Plan, Design, Build, Test, Deploy, v.v. Giả sử chị là một khách hàng và nghĩ: "được rồi, tôi thêm code completions vào khâu build". Rồi có thể thêm một agent vào khâu planning, và "tại sao không", thêm một testing agent vào khâu test.

Làm vậy thì từng khu vực đó chạy nhanh hơn: plan nhanh hơn, build nhanh hơn, test nhanh hơn. Nhưng bạn vẫn giữ nguyên các handoff và bottleneck cũ. Toàn bộ chu trình phần mềm vẫn y như trước, chỉ là có thêm AI. Đúng là nó sẽ nhanh hơn ở những chỗ đó, nhưng số lần chuyền tay và những chỗ tắc vẫn còn đủ. Điều chị muốn khán giả làm là dịch chuyển tư duy: thôi nghĩ tới việc nhét AI vào workflow đang có, chuyển sang AI native, nơi các workflow đã được dựng sẵn cho AI.

4. Ví dụ AI native: Brief, Agents, Review, Memory

Ở AI native, workflow đã có sẵn. Ví dụ có một issue đi vào, là một bug fix hoặc một improvement. Một AI agent sẽ nhận issue đó, và bạn duyệt (approve) bản brief: một problem statement rõ ràng, success criteria đã thống nhất, v.v. Từ brief đó, một agent nhận việc, investigate và implement giải pháp. Bạn có thể làm việc song song với AI, trong khuôn khổ các guardrail đã đặt cho workflow đó.

Tới đây con người bước vào làm checkpoint: kiểm tra công việc, approve, xem có cần cải thiện gì không. Phần cuối là memory: nếu workflow cần cập nhật hoặc cần thêm context, đây là chỗ bạn bổ sung context đó, để agent liên tục tốt lên. Speaker nói sẽ quay lại phần này kỹ hơn ở cuối bài.

Tóm lại vòng này là: brief cho agent, agent nhận việc, bạn review, và bạn cải thiện workflow trong lúc đi. Câu chốt của chị: khác biệt nằm ở system design đang có, không nằm ở số lượng tính năng hay công cụ AI bạn gắn vào workflow cũ.

5. Ba đặc tính của AI native development

Để tổng kết phần giới thiệu, speaker nêu ba đặc tính của AI native:

Shared context

Đây là cái chị "tâm huyết nhất", vì nó có thể cải thiện rất mạnh kết quả và chất lượng output của agent. Shared context gồm: team standards, repository patterns, issue history, architecture decisions, acceptance criteria. Tất cả những thứ đó có thể trở thành context mà bạn cho phép agent lấy.

Agentic execution

Với AI native, bạn cần agent làm việc thật. Đó có thể là các parallel agent chia ra vài khu vực. Có thể là các agentic workload chủ động nhận việc, tức là dựng những agent tự khởi động (proactive agents). Có thể là các agent phối hợp với nhau, được orchestrate qua nhiều hướng khác nhau, tất cả đều nhận context và boundary mà bạn đặt ra.

Adaptive workflows

Trong lúc làm việc với workflow, bạn dùng feedback nhận được để cải thiện nó, ngay khi có feedback. Kiểu: "cái này cần thêm chút nữa, cần chỉnh một chút, cần thêm context". Bạn đưa ngược vào instructions, vào agent skills, agent definitions, automations, tất cả những gì có sẵn trong môi trường của bạn.

Câu chốt trên slide: "Shared context, scoped execution, and reusable feedback are the operating model of AI-native development." Nghĩa là: context dùng chung, việc thực thi có phạm vi rõ, và feedback dùng lại được, ba thứ đó chính là mô hình vận hành của AI native.

6. Rethinking the SDLC: làm việc xuyên nhiều stage

Giờ đã có nền tảng về AI native và các đặc tính của nó, câu hỏi là áp vào software development lifecycle thế nào. Slide đưa ra lifecycle truyền thống: plan, design, build, test, deploy, maintain. Speaker muốn mọi người bỏ lối nghĩ "cắm một AI agent cho planning, một cái cho design, v.v.". Thay vào đó, hãy nghĩ xem workflow có thể được thiết kế lại cùng các agent, với điểm mạnh của agent trong đầu.

Chị muốn khán giả nghĩ tới hai điều:

• Làm việc xuyên nhiều stage trong SDLC, không một agent một khâu.
• Workflow enhancement: đừng nghĩ theo kiểu một đổi một, hãy nghĩ agent có thể làm gì để làm workflow mạnh lên, tận dụng đúng điểm mạnh của agent.

Ví dụ đầu tiên chị nêu cho ý này: thiết kế cái workflow sinh ra sản phẩm (design the workflow that produces the product), một câu chị sẽ lặp lại ở cuối bài.

7. Discover, define, deliver và khái niệm workforce

Có ba vùng lớn, khá rộng, để làm điều đó: discover, define và deliver. Và nó có thể mang vài hình dạng:

• Parallel agents: nhiều agent chạy song song.
• Orchestrated agents: các agent được điều phối, làm việc qua nhiều hướng.
• Workforce of agents: một lực lượng agent giúp bạn mỗi ngày.

Hôm nay chị tập trung vào chữ workforce: nó thật sự nghĩa là gì và trông ra sao. Workforce là tập hợp các scoped agent trải khắp bộ workflow của bạn. Chúng làm những việc khác nhau, có role và trách nhiệm khác nhau, nhưng tất cả đều giúp bạn hằng ngày.

Cách nghĩ "truyền thống" là đặt agent theo chức năng: một agent để briefing, một để research, một để implementation, một để review. Mỗi agent một trách nhiệm.

8. Workforce thật của speaker: năm agent có tên người

Chị kể cách mình dùng workforce hằng ngày: chị không đặt tên agent theo chức năng kiểu "briefing", "research". Chị đặt tên người thật. Chị có năm agent trong workforce:

• Dal (lúc đầu chị nói "Dale", rồi xin một giây và nói lại): agent daily digest. Dal có quyền truy cập Work IQ của chị, thứ cho phép xem Teams, lịch, có tích hợp Slack, và truy cập email. Chị dùng Dal để biết ưu tiên trong ngày, hôm nay phải làm gì. Dal chạy mỗi sáng, nhờ vậy chị không phải lục qua nhiều kênh khác nhau để tìm ưu tiên. Nguồn Work IQ: Work IQ overview, Microsoft Learn; bản MCP server và CLI: microsoft/work-iq.
• Brett: engineer của chị.
• Debbie: chuyên gia changelog. Debbie có quyền vào changelog và vào internal MCP server, để chị nắm được sản phẩm mới nhất là gì, luôn cập nhật thông tin mới nhất.
• Katie: agent lo communication.
• Cactus: agent giúp chị brainstorm.

Cả năm agent giúp chị mỗi ngày, và chị gọi chúng là workforce agents. Mỗi agent có scope khác nhau và có context khác nhau. Nhưng chính chị là người chỉ huy đội agent do mình cấu hình này, cho các việc thường ngày.

9. GitHub Copilot app: nơi chỉ huy cả đội

Mục đích của workforce là để chị tập trung vào những việc chị muốn tập trung. Vậy tất cả agent và context này tụ về đâu? Câu trả lời của chị là GitHub Copilot app. Ở đó chị dễ dàng chỉ huy đội của mình trong các boundary đã đặt. App này vốn có sẵn rất nhiều thông tin vì nằm trên GitHub: issues, pull requests, repositories, project context. Chị còn tùy biến nó bằng instructions, custom agents, v.v. Đó là nơi chị thật sự điều khiển đội. Nguồn: trang GitHub Copilot app và About the GitHub Copilot app, GitHub Docs.

Chị kể một buổi sáng điển hình:

1. Sáng thức dậy, xem daily digest của Dal nói gì.
2. Nhắn trong chat: "Brett, review giúp cái PR được giao cho tôi." và "Katie, soạn giúp một tin để tôi gửi đồng nghiệp ngay sau đó."
3. Rời máy đi pha cà phê, để hai agent làm lần lượt việc của mình.
4. Uống xong cà phê quay lại thì thấy mọi thứ đã xong. Lúc này chị review: "ừ, phần phân tích của Brett ổn, tin nhắn của Katie ổn", rồi gửi tin cho đồng nghiệp.

Chị chốt: đó là work context, agent và human judgment cùng vận hành trong một hệ thống kết nối.

10. Context engineering: lớp kiến thức dùng lại được

Chuyển sang phần 3 của agenda, building human and AI collaboration. Cách đầu tiên là context engineering. Chị nhắc lại đây là phần chị tâm huyết, vì nó giúp bạn không phải bắt đầu từ số không mỗi lần prompt. Có vài cách làm:

• Custom instructions, agent skills, agent definitions và những thứ tương tự. Tài liệu: custom instructions, agent skills, custom agents (GitHub Docs); chuẩn mở agentskills.io; file AGENTS.md trên slide: agents.md.
• MCP server: xuất phát từ thực tế không phải mọi thứ của bạn đều nằm trên GitHub. Nó nằm ở Slack, ở Jira, ở email, ở đủ loại kênh. MCP server nối những nguồn đó vào; plugins cũng dùng được cho việc này. Nguồn: Model Context Protocol.
• Memory và session history: những gì đã trao đổi và đã quyết ở phiên trước được mang sang phiên sau.

Tất cả được lắp ráp riêng cho từng task. Ví dụ Brett có một bộ thông tin khác với agent communication là Katie. Dal, agent daily digest, lại có bộ tool và kênh liên lạc khác hai agent kia. Tổng hợp instructions, tools và memory dẫn tới output agent tốt hơn. Mỗi thứ có thể khác nhau tùy agent, và tất cả do bạn quản: bạn chọn việc, kiến thức, tool và mọi quyền truy cập mà mỗi agent nhận.

11. A connected system, not a handoff

Điều thứ hai về human and AI collaboration: đây là một hệ thống kết nối, không phải một lần chuyền tay. Đừng nghĩ kiểu giao cho agent xong là hết, rồi không review gì cả. Chị muốn khán giả nhớ chu trình này:

1. Human direction + context: người quyết ưu tiên, outcome, context (slide thêm: constraints).
2. Agentic execution: agent nhận việc và làm: investigate, build, test, và đưa ra các phương án (slide: "Investigate, draft, build, test, and surface options").
3. Review + reusable feedback: bạn review và học từ outcome của output đó, để workflow liên tục được cập nhật.

Chị so sánh: công ty của bạn thay đổi context và thông tin mỗi ngày, thì bạn cũng phải bảo đảm thông tin đó được cập nhật vào agent, để mỗi vòng lặp cải thiện vòng workflow tiếp theo.

12. Mỗi lần học được thành context cho lần sau

Chị "double click", tức đào sâu, vào bước cuối: cập nhật agent và context trong lúc làm việc với workflow, sao cho mỗi điều học được trở thành context cho lần sau. Một review comment, một PR bị reject, một bản fix: chúng không chỉ là kết quả, mà là input để bạn feedback ngược lại cho agent và cho workflow.

Chỗ để cập nhật: custom instructions, agent skills, custom agents, automated checks. Nếu cải tiến chạy tốt thì đưa nó ngược vào hệ thống. "Chúng ta không muốn feedback đi vào hư không", phải liên tục feed back vào agent.

Điều cuối cùng chị để lại cho phần này: design the workflow that produces the product. Đừng nghĩ "chỗ nào tôi thêm AI được, chỗ nào tôi gắn agent này vào được". Hãy nghĩ về outcome bạn đang cố đạt, bắt đầu từ một outcome và xây workflow quanh nó.

13. Thiết kế workflow quanh outcome, và việc làm sáng thứ Hai

Ví dụ outcome: có thể bạn muốn bug được xử lý nhanh hơn, có thể muốn review tốt hơn hoặc code quality cao hơn. Từ đó bạn thiết kế system of work, trả lời các câu hỏi:

• Người làm gì, agent làm gì? Tôi nên làm gì, agent nên làm gì?
• Tool và context nào góp vào được, tôi cho phép agent dùng gì?
• Feedback làm phiên bản kế tiếp tốt hơn như thế nào?

Tức là thiết kế workflow tốt hơn quanh outcome bạn muốn. Rồi sang phần 4, in practice: sáng thứ Hai bắt đầu thế nào?

1. Monitor: bắt đầu với một workflow ít rủi ro. Quan sát công việc mình đang có: việc nào làm bạn mệt, chỗ nào trùng lặp nhiều nhất, việc gì lặp đi lặp lại trên bàn.
2. Build a workflow: dựng workflow hoặc workforce, tùy cái gì hợp với bạn. Xây vòng lặp đầu tiên để giúp việc lặp lại đó, rồi dần dựng "AI team" của mình.
3. Context engineering: agent của bạn cần gì để làm đời bạn dễ hơn? Thông tin nào thêm vào sẽ thành context hữu ích?
4. Inspire a new culture: lan truyền, khuyến khích người khác khám phá AI, phát triển ứng dụng, nói chuyện với đồng nghiệp xem cái gì đã chạy, cái gì không, rồi cải thiện workflow. Nhờ vậy tạo ra một môi trường AI native.

14. GitHub Copilot Learn và lời cảm ơn

Điều cuối cùng chị để lại: hãy vào GitHub Copilot Learn. Chị đã nói về rất nhiều khái niệm hôm nay, và tất cả đều có trong Skills repository của GitHub Learn. Với bất kỳ bài nào, bạn có thể mở một Codespace để thực hành ngay. Chị mời mọi người vào xem, rồi cảm ơn.

Ảnh chụp cho thấy trang tổ chức GitHub Skills trên github.com: "Learn how to use GitHub with interactive exercises designed for beginners and experts", các bài học chạy ngay trong Issues bằng GitHub Actions, làm trên bản sao của một project thật, có Octocat hướng dẫn, và mọi thứ dùng tính năng GitHub thật như Issues, Actions, Codespaces. Bảng tài nguyên liệt kê: GitHub Learn Skills catalog, Project Board, Exercise Creator, Exercise Template, Exercise Toolkit, Changelog.

Link: github.com/skills · catalog learn.github.com/skills · GitHub Codespaces docs.