Spec-Driven Development: Agentic Coding at FAANG Scale and Quality — Al Harris, Amazon Kiro

• Kuro và công cụ Spectra and Development của họ đã chính thức ra mắt, tập trung vào việc cải thiện quy trình phát triển phần mềm (SDLC) cho AI. Mục tiêu là mở rộng quy mô phát triển AI, tăng cường kiểm soát các tác nhân AI, và nâng cao chất lượng mã cùng độ tin cậy.
• Spectra cung cấp một SDLC toàn diện, giúp nén chu trình phát triển bằng cách tạo ra một vòng lặp phản hồi chặt chẽ giữa khám phá yêu cầu, thiết kế và triển khai. Điều này được thực hiện thông qua việc sử dụng các yêu cầu định dạng EARS có cấu trúc, có thể chuyển đổi trực tiếp thành các thuộc tính để kiểm thử.
• Nền tảng này tích hợp Multi-Capability Platforms (MCPs) để mở rộng khả năng của Kiro, cho phép người dùng kéo dữ liệu bên ngoài và tùy chỉnh các tạo phẩm (artifacts) được tạo ra. Điều này giúp tạo ra các đặc tả robust hơn và tích hợp các tài liệu thiết kế như wireframe ngay từ giai đoạn đầu.

• Áp dụng Quy trình Phát triển AI có cấu trúc: Sử dụng Spectra and Dev để chuyển từ "vibe coding" sang một SDLC toàn diện cho các dự án AI, tập trung vào khả năng mở rộng, độ tin cậy và chất lượng cao.
• Sử dụng EARS để Định nghĩa Yêu cầu: Viết các yêu cầu bằng định dạng EARS (The Easy Approach to Requirements Syntax) để tạo ra các biểu diễn ngôn ngữ tự nhiên có cấu trúc, có thể dịch trực tiếp thành các thuộc tính kiểm thử của hệ thống.
• Thực hiện Kiểm thử dựa trên Thuộc tính (PBT): Chuyển đổi các yêu cầu EARS thành các thuộc tính hệ thống (invariants) và sử dụng PBT để kiểm thử nghiêm ngặt. Phương pháp này tìm cách làm sai lệch các bất biến, cung cấp độ tin cậy cao về việc triển khai nếu không tìm thấy phản ví dụ.
• Tích hợp Dữ liệu và Công cụ Bên ngoài bằng MCPs: Mở rộng Kiro bằng cách cài đặt và cấu hình MCPs (Multi-Capability Platforms). Các MCP này có thể kéo dữ liệu bên ngoài (ví dụ từ Asana, tìm kiếm web) để làm phong phú thêm quá trình tạo yêu cầu, thiết kế và triển khai.
• Tự động hóa Tạo Đặc tả từ Nguồn có sẵn: Sử dụng MCPs để tự động tạo đặc tả Spectra từ các tạo phẩm hiện có, chẳng hạn như các tác vụ trong công cụ quản lý dự án (ví dụ: Asana) hoặc các ví dụ được tìm thấy trên internet.
• Tùy chỉnh Tạo Tạo phẩm bằng Ngôn ngữ Tự nhiên: Điều khiển việc tạo các tạo phẩm thiết kế tùy chỉnh, như UI mocks hoặc wireframe diagrams, bằng cách cung cấp các lời nhắc bằng ngôn ngữ tự nhiên trong quy trình làm việc của Spectra, giúp tăng cường sự rõ ràng và cộng tác với các bên liên quan.
• Ưu tiên Thẩm định Yêu cầu: Tận dụng các công cụ tích hợp của Spectra để thẩm định yêu cầu, quét tìm sự mơ hồ quá mức, các ràng buộc không hợp lệ hoặc mâu thuẫn, và hỗ trợ giải quyết chúng bằng các kỹ thuật suy luận tự động.

• Agentic ID — Định danh Tác nhân
• Spectra and Development — Spectra và Phát triển
• SDLC (Software Development Life Cycle) — Vòng đời Phát triển Phần mềm
• development tool — Công cụ Phát triển
• guardrails — Hàng rào Bảo vệ
• agent — Tác nhân
• EARS (Easy Approach to Requirements Syntax) — Cú pháp Yêu cầu Dễ Tiếp cận
• property-based testing — Kiểm thử dựa trên Thuộc tính
• invariant — Bất biến
• MCP (Multi-Capability Platform) — Nền tảng Đa năng
• spec (specification) — Đặc tả
• artifact — Tạo phẩm
• UI mock / wireframe diagram — Mô phỏng Giao diện Người dùng / Sơ đồ Khung sườn

Giới Thiệu Kuro và Spectra and Dev

Với những ai chưa từng nghe về chúng tôi, Kuro và Agentic ID, chúng tôi đã chính thức phát hành rộng rãi (GA) vào thứ Hai gần đây nhất, tôi nghĩ là ngày 17, nhưng chúng tôi đã ra mắt bản xem trước công khai (public preview) vào ngày 14 tháng 7. Vậy là đã ra mắt được vài tháng, thu thập phản hồi từ khách hàng, và những thông tin giá trị khác. Chúng tôi sẽ nói một chút về việc sử dụng Spectra and Development để mài sắc bộ công cụ AI của bạn. Tôi đã hỏi và khoảng một phần tư số người ở đây quen thuộc với Spectra and Dev. Tên tôi là Al Harris, kỹ sư trưởng tại Amazon. Tôi đã làm việc trên Kuro trong nửa cuối năm ngoái. Chúng tôi là một nhóm rất nhỏ, cơ bản chỉ có ba hoặc bốn người ngồi trong một căn phòng, làm những gì chúng tôi nghĩ có thể cải thiện vòng đời phát triển phần mềm (SDLC) cho khách hàng. Vì vậy, chúng tôi được giao nhiệm vụ xây dựng một development tool (công cụ phát triển) nhằm giải quyết và cải thiện trải nghiệm cho Spectra and Development. Về mặt lý thuyết, chúng tôi được tài trợ bởi tổ chức hỗ trợ các dự án như QDEVs, nhưng chúng tôi cố ý tạo ra một sản phẩm rất khác so với hệ thống QE để có một cách tiếp cận khác đối với những vấn đề này. Chúng tôi muốn tập trung vào việc mở rộng quy mô, giúp bạn mở rộng phát triển AI (AI dev) sang các vấn đề phức tạp hơn, cải thiện mức độ kiểm soát bạn có đối với các tác nhân AI, và nâng cao chất lượng mã (code quality) cùng với độ tin cậy (reliability) của những gì bạn tạo ra.

Giải Pháp Spectra và Quy Trình Phát Triển Phần Mềm Toàn Diện

Quay lại với nội dung mới. Với giải pháp Spectra của chúng tôi, chúng tôi đã xem xét một số công cụ hiện có và nhận thấy rằng, vibe coding rất tuyệt vời, nhưng vibe coding phụ thuộc rất nhiều vào tôi, người vận hành (operator), để mọi thứ diễn ra đúng đắn. Tức là tôi phải cung cấp các hàng rào bảo vệ (guardrails) cho hệ thống, tôi phải đưa tác nhân (agent) đi qua một quy trình làm việc nghiêm ngặt (strict workflow). Chúng tôi muốn Spectra and Dev đại diện cho một SDLC (vòng đời phát triển phần mềm) toàn diện (holistic SDLC), bởi vì chúng tôi có 25-30 năm kinh nghiệm trong ngành về xây dựng phần mềm, xây dựng nó một cách tốt và với các phương pháp khác nhau. Chúng tôi đã trải qua waterfall đến XP. Chúng tôi có tất cả những cách khác nhau để thể hiện những gì một hệ thống nên làm, và chúng tôi muốn tôn trọng những gì đã có trước đó một cách hiệu quả.

Hình ảnh động này trông tốt hơn nhiều. Ban đầu nó chỉ là hình kim cương bên trái, nhưng ý tưởng là bạn đang lặp lại một ý tưởng. Tôi nghĩ một nửa quá trình phát triển phần mềm là khám phá yêu cầu (discovery requirements), và việc khám phá đó không chỉ xảy ra bằng cách ngồi đó và suy nghĩ xem hệ thống nên làm gì, hệ thống có thể làm gì? Tuy nhiên, khi làm việc với điều này, chúng tôi nhận ra rằng cách tốt nhất để làm cho các hệ thống này hoạt động là thực sự tổng hợp đầu ra (synthesize the output) và có thể đưa phản hồi đó rất nhanh chóng trở lại các yêu cầu đầu vào (input requirements), và thực hiện thiết kế, rồi nhận ra rằng, "Ồ, thực ra, nếu chúng ta làm điều này, sẽ có một tác dụng phụ (side effect) mà chúng ta chưa xem xét, chúng ta cần đưa điều đó trở lại các yêu cầu đầu vào." Và vì vậy, sự nén của SDLC này đã phát triển để mang lại cấu trúc vào luồng phát triển phần mềm.

Chúng tôi muốn lấy các tạo phẩm (artifacts) mà bạn tạo ra như một phần của thiết kế. Đó là các yêu cầu mà một quản lý sản phẩm (product manager) hoặc nhà phát triển (developer) có thể viết, đó sẽ là các tiêu chí chấp nhận (acceptance criteria). Thành công trông như thế nào khi kết thúc quá trình này? Và sau đó, chúng tôi muốn lấy các tạo phẩm thiết kế (design artifacts) mà bạn có thể xem xét với nhóm phát triển (dev team) của mình, bạn có thể xem xét với các bên liên quan (stakeholders) và nói, "Đây là những gì chúng ta sẽ xây dựng và triển khai." Và chúng tôi muốn đảm bảo rằng bạn có thể làm tất cả điều này trong một vòng lặp bên trong chặt chẽ (tight inner loop). Và đó ban đầu là Spectraven Dev.

Quy Trình Phát Triển Dựa Trên EARS của Spectra

Spectraven development trong Kiro ngày nay, hoặc ít nhất là trước khi GA (phát hành rộng rãi), là bạn cung cấp cho chúng tôi một lời nhắc (prompt) và chúng tôi sẽ lấy đó và biến nó thành một tập hợp các yêu cầu (requirements) rõ ràng với tiêu chí chấp nhận (acceptance criteria). Chúng tôi biểu diễn các tiêu chí chấp nhận này ở định dạng EARS. EARS là viết tắt của "The Easy Approach to Requirements Syntax". Và điều này cho phép bạn rất dễ dàng, về cơ bản, là một biểu diễn ngôn ngữ tự nhiên có cấu trúc (structured natural language representation) về những gì bạn muốn hệ thống thực hiện.

Trong bốn tháng rưỡi đầu tiên sản phẩm này tồn tại, định dạng EARS trông giống như một quyết định thú vị mà chúng tôi đã đưa ra, nhưng chỉ vậy thôi. Và với việc ra mắt GA vào thứ Hai, chúng tôi cuối cùng đã bắt đầu triển khai một số tính năng bổ sung, đó là kiểm thử dựa trên thuộc tính (property-based testing). Vì vậy, giờ đây các yêu cầu EARS của bạn có thể được dịch trực tiếp thành các thuộc tính của hệ thống (properties of the system), đó là những bất biến (invariants) mà bạn muốn cung cấp.

Đối với những bạn chưa từng, tôi đoán, thực hiện kiểm thử dựa trên thuộc tính (property-based testing) trước đây bằng cách sử dụng các công cụ như hypothesis trong Python hoặc fast-check trong Node.js, thư viện spec của closures là một ví dụ khác. Đây là các phương pháp tiếp cận để kiểm thử hệ thống phần mềm của bạn, nơi bạn thực sự cố gắng tạo ra một trường hợp kiểm thử (test case) duy nhất làm sai lệch bất biến (falsifies the invariant) mà bạn muốn chứng minh. Và nếu bạn có thể tìm thấy bất kỳ phản đảo (contrapositive) nào, thì bạn có thể nói rằng yêu cầu này không được đáp ứng. Nếu bạn không thể, bạn có một mức độ tự tin cao – trong đó từ "cao" ở đây có một chút ý nghĩa sâu sắc, vì nó phụ thuộc vào mức độ bạn viết các bài kiểm thử của mình. Nhưng nếu bạn có thể nói với mức độ tự tin cao rằng hệ thống thực hiện chính xác những gì bạn nói, vâng, đó là một thuộc tính.

Chúng ta sẽ đi sâu hơn một chút vào kiểm thử dựa trên thuộc tính và PBT sau. Nhưng đây là bước đầu tiên trong số nhiều bước chúng tôi đang thực hiện để thực sự lấy các yêu cầu ngôn ngữ tự nhiên có cấu trúc (structured natural language requirements) và sau đó liên kết chúng với một sợi dây xuyên suốt (through line) cho đến mã hoàn chỉnh (finished code) và nói rằng, nếu mã của bạn, nếu các thuộc tính của mã đáp ứng các yêu cầu ban đầu, chúng tôi có mức độ tự tin cao rằng bạn đã triển khai phần mềm (reliably shipped the software) một cách đáng tin cậy như bạn mong đợi.

Với Spectra and Dev, chúng tôi lấy lời nhắc của bạn, biến nó thành các yêu cầu, rút ra thiết kế từ đó, định nghĩa các thuộc tính của hệ thống, và sau đó chúng tôi xây dựng một danh sách tác vụ (task list) và bạn có thể chạy danh sách tác vụ của mình. Thực tế, đặc tả (spec) sau đó trở thành biểu diễn ngôn ngữ tự nhiên (natural language representation) của hệ thống của bạn. Nó có các ràng buộc (constraints), nó có các mối quan tâm xung quanh yêu cầu chức năng (functional requirements), yêu cầu phi chức năng (non-functional requirements), và nó là tập hợp các tạo phẩm mà bạn đang cung cấp.

Tôi không nghĩ tôi có slide này trong bộ slide này, nhưng cuối cùng, cách tôi nhìn vào đặc tả (spec) là: một là, tập hợp các tạo phẩm đại diện cho trạng thái của hệ thống của bạn tại một thời điểm T. Hai là, một quy trình làm việc có cấu trúc (structured workflow) mà chúng tôi đưa bạn qua để cung cấp phần mềm chất lượng cao một cách đáng tin cậy, và đó là các giai đoạn yêu cầu, thiết kế và thực thi (execution phases). Và ba là, tập hợp các công cụ và hệ thống trên đó giúp chúng tôi mang lại kết quả có thể tái lập (reproducible results), trong đó một ví dụ là kiểm thử dựa trên thuộc tính (property-based testing), một ví dụ khác, ít rõ ràng hơn một chút, nhưng chúng ta có thể nói sau, sẽ là thẩm định yêu cầu (requirements verification). Vì vậy, chúng tôi quét các yêu cầu của bạn để tìm sự quá mơ hồ (overambiguity), chúng tôi quét các yêu cầu của bạn để tìm các ràng buộc không hợp lệ (invalid constraints). Ví dụ, bạn có các yêu cầu mâu thuẫn (conflicting requirements), và chúng tôi giúp bạn giải quyết những mơ hồ đó bằng cách sử dụng các kỹ thuật suy luận tự động (automated reasoning techniques) cổ điển.

Và tôi có thể nói thêm một chút về các tính năng của Kiro, tôi nghĩ điều đó có thể ít thú vị hơn cho bài nói chuyện này vì chúng ta muốn nói về Spectra and Dev. Tuy nhiên, chúng tôi có tất cả những thứ bạn mong đợi. Chúng tôi có tính năng điều hướng (steering), một dạng bộ nhớ (memory) và quy tắc con trỏ (cursor rules). Chúng tôi có tích hợp MCP, và các hook phần mềm (software hooks).

Nâng Cao Chuỗi Công Cụ của Bạn với MCP

Bây giờ tôi sẽ tạm dừng một chút, chỉ một khoảnh khắc thôi, cho những người trong phòng có thể đã thử tải xuống Kiro hoặc thứ gì đó khác, và chỉ muốn hỏi, có bất kỳ câu hỏi nào ngay bây giờ không trước khi chúng ta đi sâu vào cách thực sự sử dụng Spectra để đạt được mục tiêu? Không có câu hỏi nào, đó có thể là một dấu hiệu tốt, có thể có nghĩa là tôi không nói về bất cứ điều gì đặc biệt thú vị.

Vì vậy, tôi thực sự muốn nói chi tiết cụ thể ở đây. Đây là một bài nói chuyện tôi đã trình bày vài tháng trước về cách sử dụng các MCP trong Kiro. Và một trong những thách thức mà những người đã thử nghiệm Kiro gặp phải, điều này có thể dễ thấy hơn một chút, là họ cảm thấy rằng luồng công việc mà chúng tôi đang thúc đẩy họ đi qua hơi quá cấu trúc. Giống như bạn không có quyền truy cập vào dữ liệu bên ngoài (external data), bạn không có quyền truy cập vào tất cả những thứ khác mà bạn muốn. Và vì vậy, một điều mà chúng tôi đã nói trong hành trình của mình ở đây để chạy của bạn, ồ, bạn biết đấy, không đúng thứ tự. Đây là hình ảnh được tạo bởi AI (AI generated image) đẹp của tôi.

Bạn có thể sử dụng MCP, tôi cho rằng mọi người ở đây đều đã quen thuộc với MCP vào thời điểm này, nhưng Kiro tích hợp MCP giống như tất cả các công cụ khác. Nhưng điều tôi nghĩ mọi người chưa làm đủ là sử dụng MCP của họ khi xây dựng các đặc tả (spec) của mình. Và vì vậy, bạn có thể sử dụng máy chủ MCP (MCP servers) của mình trong bất kỳ giai đoạn nào của quy trình phát triển dựa trên Spectra (Spectra-driven development workflow), đó sẽ là tạo yêu cầu (requirements generation), thiết kế và triển khai (design and implementation), và chúng tôi sẽ đi qua một ví dụ về từng giai đoạn.

Trước hết, việc thiết lập một đặc tả (spec) trong Kiro khá đơn giản. Chúng tôi có bảng điều khiển Kiro (Kiro panel) ở đây, nó hơi mờ ảo. Và sau đó bạn có thể đi xuống các máy chủ MCP của mình và nhấp vào nút dấu cộng. Bạn cũng có thể, cách yêu thích của tôi là yêu cầu Kiro thêm một MCP và sau đó cung cấp cho nó một số thông tin về vị trí của nó. Và nó có thể tự tìm ra thường từ đó hoặc bạn chỉ cần cung cấp cho nó khối JSON (JSON blob) và nó sẽ tự tìm ra. Khi bạn đã thêm MCP của mình, bạn sẽ thấy nó trong bảng điều khiển (control panel) ở đây và bạn có thể bật, tắt, cho phép các công cụ của chúng tôi, tắt công cụ, v.v. Vì vậy, bạn có thể quản lý ngữ cảnh theo cách đó. Hoặc lưu ý, việc thay đổi MCP và thay đổi công cụ nói chung là một thao tác làm mất hiệu lực bộ nhớ đệm (cache breaking operation). Vì vậy, nếu bạn đang ở rất sâu trong một phiên làm việc dài, có thể bạn không nên điều chỉnh cấu hình MCP (MCP config) của mình vì nó sẽ làm bạn chậm lại đáng kể.

Sử Dụng MCP trong Tạo Đặc Tả (Spec Generation)

Nhưng hãy nói về MCP trong việc tạo đặc tả (spec generation). Có một điều mà nhóm Kiro sử dụng Asana vì lý do nào đó, tôi không biết, nhưng đó là công cụ theo dõi kiểm thử (test tracker) mà chúng tôi lựa chọn. Vì vậy, một điều tôi muốn làm là có thể đi và nói, tôi không muốn viết các yêu cầu cho đặc tả từ đầu. Nhóm sản phẩm (product team) của tôi đã suy nghĩ một số điều. Chúng tôi đã lặp đi lặp lại Asana để chia nhỏ dự án (break a project down). Điều này không phải lúc nào cũng xảy ra, nhưng đôi khi thì có.

Vì vậy, trong trường hợp này, tôi có một tác vụ trong Asana, tôi không biết, tôi đã làm sai. Đó là hậu quả của việc phóng to. Vì vậy, tôi có tác vụ này trong Asana nói rằng, thêm view model và controller vào API này. Trong trường hợp này, đây là một ứng dụng demo (demo app) cụ thể mà tôi có thể chia sẻ trong vài phút nữa. Và chúng tôi thậm chí còn có, nó hơi lộ ra ở đây, nhưng chúng tôi có một số chi tiết về những gì chúng tôi muốn xảy ra. Bây giờ tôi có thể vào Kiro và chỉ cần nói, "bắt đầu thực thi tác vụ (start executing task), URL XYZ từ Asana." Và Kiro sẽ nhận ra đây là một URL Asana. Tôi đã cài đặt MCP Asana. Nó sẽ đi và kéo tất cả siêu dữ liệu (metadata) ở đó. Vì vậy, nó sẽ phân tích và từ đó, bắt đầu xác định những gì cần làm. Ồ, buồn cười thật, những tiêu đề này bị ngược. Về cơ bản, "tạo một đặc tả (spec) cho các tác vụ Asana đang mở của tôi." Một lần nữa, "hãy lấy tất cả các tác vụ từ Asana và sau đó cho mỗi tác vụ, tạo một yêu cầu dựa trên các tác vụ." Vì vậy, tôi nghĩ tôi có khoảng sáu tác vụ được giao cho mình. Một là quản lý người dùng (user management), một là quản lý thuộc tính (property management). Nó sẽ kéo chúng vào, tạo ra các yêu cầu. Và sau đó trong trường hợp này, tiêu đề sai, xin lỗi. "Bắt đầu thực thi tác vụ." Đây là, tôi muốn đi và thực hiện tổng hợp mã (code synthesis) cho điều này.

Và tôi sẽ tạm dừng nhanh ở đây để nói về cách bạn có thể làm điều này trong thực tế (in practice). Vì vậy, đối với những bạn đang theo dõi trong phòng, hãy thoải mái khởi động Kiro của bạn, mở một dự án, và sau đó chọn một máy chủ MCP (MCP server). Tôi sẽ chia sẻ một vài kho lưu trữ (repos) ở đây thật nhanh để bạn có thể thử nghiệm. Vì vậy, tôi đã triển khai một máy chủ MCP. Tôi có lofty views này, mà tôi nghĩ là triển khai Asana. Và sau đó tất cả những thứ này phải là công khai. Hãy để tôi kiểm tra lại. Vâng. OK. Vì vậy, ví dụ, nếu bạn muốn mở rộng MCP của tôi, tôi có một MCP Giải Nobel, nó gọi đến, có lẽ không ngạc nhiên, có một API Giải Nobel. Vì vậy, bạn có thể sử dụng UVX để cài đặt nó, hoặc bạn có thể git clone alharus/Nobel-MCP này. Đây chỉ là một ví dụ. Một ví dụ khác ở đây là nếu bạn muốn thử nghiệm với mẫu có trong video. Tôi có alharus/lofty-views.

Tối ưu hóa Tạo Spec với MCP

Tôi sẽ để cả hai liên kết này trên màn hình trong giây lát cho những ai muốn sao chép URL. Trong khi điều đó đang diễn ra, ồ không, hãy để tôi chuyển sang cùng một cửa sổ. Vậy điều tôi sẽ trình bày nhanh là việc sử dụng một MCP để làm cho việc tạo spec dễ dàng hơn hoặc đáng tin cậy hơn.

Ở đây tôi có, để xem, rất nhiều MCP. Hãy dùng... thực ra tôi muốn sử dụng GitHub MCP. Ồ không, bỏ qua tôi. Được rồi, tôi có Fetch MCP. Trong trường hợp này, tôi có thể vào đây và nói, "Này, tôi đã tạo một loạt task cho Lofty Views app." Đây về cơ bản là một CRUD web app rất đơn giản. "Nhưng tôi muốn Kiro sử dụng Fetch MCP để kéo các ví dụ từ các sản phẩm tương tự đang có trên internet." Bạn cũng có thể sử dụng MCP servers của Brave Search hoặc Tavoli Search. Nhưng trong trường hợp này, tôi sẽ chỉ sử dụng Fetch vì tôi đã kích hoạt nó.

Vì vậy, hãy nói, ồ, thực ra chúng ta có thể chạy web server và sử dụng Fetch. Đó là một ví dụ hay. Đây là một ví dụ về việc bạn có thể, tại bất kỳ điểm nào trong workflow tạo spec, sử dụng MCP servers của mình để làm cho mọi thứ hoạt động. Bây giờ, đây là kết quả của việc tôi đã không sử dụng một project nào trong một thời gian. Bây giờ chúng ta sẽ hủy bỏ điều đó. Chúng ta thực sự có thể làm điều gì đó thú vị hơn một chút, đó là một project riêng biệt mà tôi đã và đang thực hiện. Tôi đã và đang làm việc trên một Agent Core agent. Và đó có thể là... tôi biết project này hoạt động, đó là lý do tôi nhắc đến ở đây. Tôi đã gọi nó là gì nhỉ? Chà, có lẽ chúng ta sẽ thực hiện các live demo vào cuối buổi.

Đó là điều cơ bản nhất bạn có thể làm với Kiro là chỉ sử dụng MCP servers. Nhưng bất kỳ công cụ nào cũng sử dụng MCP servers. Tôi thực sự không nghĩ điều đó đặc biệt thú vị.

Tùy chỉnh Artifact và UI Mock

Vậy, hãy nói rằng trong quá trình cố gắng mài giũa toolkit spec-driven dev của chúng ta, chúng ta đã hoàn thành với độ nhám 200. Chúng ta đã thêm một số capabilities với MCP. Nó hữu ích nhưng sẽ không phải là một yếu tố thay đổi cuộc chơi đối với chúng ta. Tôi muốn đi sâu hơn và thực sự đạt đến độ nhám 400. Hãy bắt đầu đánh bóng thật kỹ.

Tôi muốn tùy chỉnh các artifact được tạo ra, bởi vì bạn có task list này, bạn có requirements list này. Và tôi không đồng ý với những gì bạn đã đưa vào đó. Bạn có thể nói rằng nhiều người cũng vậy. Và đó là một điểm khởi đầu tuyệt vời. Vì vậy, đây là điều tôi đã nghe vào đầu tuần này, bạn biết đấy, sớm hơn trong hội nghị, là mọi người thích làm những việc như sử dụng wireframes trong mocks của họ.

Sử dụng wireframe mocks bởi vì trong phạm vi natural language của bạn, việc sử dụng specs như một control surface để giải thích những gì bạn muốn system thực hiện. Do đó, tôi muốn có thể thực sự đưa UI mocks vào đây. Trường hợp đơn giản nhất là tôi chỉ cần vào đây và nói, Kiro đã hỏi tôi ở đây, "Thiết kế trông có ổn không? Bạn có hài lòng không?" Và tôi nói, "Cái này trông rất tuyệt. Nhưng bạn có thể bao gồm các wireframe diagrams cho các màn hình chúng ta sẽ xây dựng ở đây không?" Tôi đang thêm, đây một lần nữa là từ cái Lofty Views đó. Tôi đang thêm một user management UI. Nhưng tôi muốn thực sự thấy những gì chúng ta đang đề xuất xây dựng, chứ không chỉ architecture của nó.

Vậy Kiro sẽ ngồi đây và hoạt động trong vài giây. Nhưng bạn có thể thêm bất cứ điều gì bạn muốn vào bất kỳ artifact nào trong số này, bởi vì chúng là natural language. Vì vậy, có structure, có nghĩa là chúng ta muốn có một số reproducibility trong cách chúng trông như thế nào, nhưng cuối cùng, cách chúng trông như thế nào không quan trọng vì chúng ta có tác nhân ở đây có thể giúp dịch nó sang dạng cần thiết. Vì vậy, Kiro đang hoạt động ở đây. Nó đang suy nghĩ, suy nghĩ. Và sau đó nó sẽ xuất ra những ASCII diagrams được bao bọc bởi văn bản này. Tôi sẽ sửa phần bao bọc này trong video sau một giây. Nhưng cuối cùng, nó làm bất cứ điều gì bạn muốn.

Nếu bạn muốn thêm data vào requirements của mình, bạn có thể làm điều đó. Nếu bạn muốn thêm data vào design như thế này, bạn có thể dễ dàng thêm vào. Ở đây chúng ta có những wireframes và ASCII này giúp tôi hợp lý hóa những gì chúng ta sắp ship. Và sau đó tôi có thể tiếp tục trò chuyện và nói, "Thực ra, trong design, tôi không muốn, có lẽ tôi không muốn nút add user button này nằm ở phía trên cùng mọi lúc," trong trường hợp đó, tôi có thể trò chuyện với nó để thực hiện thay đổi đó một cách dễ dàng. Và bây giờ chúng ta đã thống nhất ngay từ đầu thay vì đợi đến lúc implementation. Vì vậy, chúng ta một lần nữa đã left-shifted một số concern.

Đó là một ví dụ. Tôi muốn thêm UI mocks vào design của một system.

Tùy chỉnh Artifact và Test Case

Một ví dụ khác, tuy nhiên, có thể là đây, đây là một ảnh chụp nhanh về end state đó, và bây giờ design của tôi có những UI mocks này. Nhưng một ví dụ khác mà tôi thực sự thích hơn một chút là việc bao gồm test cases trong definition và tasks.

Ngày nay, các task mà Kiro cung cấp cho bạn sẽ là những gạch đầu dòng của requirements và acceptance criteria bạn cần đạt được. Nhưng tôi muốn biết rằng ở end state của task này khi được thực thi, chúng ta có một sự hiểu biết rất rõ ràng rằng nó là chính xác, không chỉ đơn giản là "xong", bởi vì bất cứ ai đã thấy một tác nhân AI đều có thể chứng thực rằng các LLM rất giỏi trong việc nói, "Tôi xong rồi, tôi hài lòng, tôi chắc bạn hài lòng, tôi sẽ hoàn thành thôi." "Ồ, vâng, các test không vượt qua, nhưng chúng thật phiền phức. Tôi đã thử ba lần nhưng không được, tôi sẽ chuyển sang cái khác." Không, tôi không muốn điều đó. Tôi muốn thực sự biết rằng mọi thứ đang hoạt động.

Vì vậy, trong trường hợp này, tôi đã yêu cầu Kiro bao gồm các unit test cases rõ ràng sẽ được kiểm tra. Vì vậy, task của tôi ở đây, ví dụ, khi tạo Agent Core Memory Checkpointer này sẽ có tất cả các test cases cần vượt qua trước khi nó hoàn thành. Và sau đó tôi có thể sử dụng những thứ như Agent Hooks để đảm bảo chúng chính xác. Chúng ta sẽ chạy sample này sau một chút trong buổi nói chuyện. Đây là điều tôi sẵn sàng demo một chút. Vâng, đây là một ví dụ khác mà bạn có thể, một lần nữa, bạn đang làm việc trên tool bench của mình, bạn có tất cả các capabilities và primitives này dưới sự kiểm soát của mình, và bạn có thể điều chỉnh process để nó hoạt động cho bạn, chứ không chỉ là process mà tôi nghĩ là tốt nhất.

Khám phá Các Lựa chọn Thay thế cho Process

Và cuối cùng nhưng không kém phần quan trọng, độ nhám 800. Ở thời điểm này, chúng ta đang hoàn thiện công cụ. Chúng ta có thể sẽ stropping tiếp theo, nhưng chúng ta muốn, bạn biết đấy, bạn có thể iterate trên các artifact của mình, nhưng bạn cũng có thể iterate trên process thực tế đang chạy.

Vì vậy, một điều bạn có thể gặp phải, và tôi thường làm điều này rất nhiều, là tôi sẽ trò chuyện với Kiro, và tôi nói, "Này, tôi muốn, trong trường hợp này, tôi muốn thêm memory vào Agent Core của tôi. Hãy dump conversations vào S3 file vào cuối mỗi execution." Kiro sẽ nói, "Tuyệt vời. Tôi biết cách làm điều đó. Tôi sẽ nghiên cứu chính xác cách làm điều đó." "Tôi sẽ đạt được goal này cho bạn." Nhưng cuối cùng, điều tôi đã làm thực ra là giới thiệu một bias ngay từ đầu. Đó là tôi đang điều hướng toàn bộ tác nhân AI, nó đang sử dụng S3 làm storage solution này chỉ vì có thể tôi quen thuộc với nó, nhưng đó có lẽ không phải là cách tốt nhất để thực hiện.

Vì vậy, sau khi nó đã synthesized design và tất cả các task và tất cả những thứ này, tôi quay lại và nói, "Chà, chúng ta không cần phải tuân thủ workflow spec-driven dev cứng nhắc này đã được định nghĩa bởi Kiro." Tôi có thể yêu cầu các alternatives. "Liệu đây có phải là idiomatic way để đạt được session persistence không? Tôi không biết." Có lẽ có một cách tốt hơn. Có lẽ nếu chúng ta đang nói về AWS services, đó là S3, đó là Dynamo... Kiro sẽ vào đây và nói, "Câu hỏi hay. Để tôi nghiên cứu." Nó sẽ đi qua và gọi một loạt MCP tools mà tôi đã cấp quyền access cho nó. Điều này quay trở lại vấn đề, "Bạn nên sử dụng MCP." Và sau đó nó quay lại với recommendation này mà tôi không biết đó là một feature, đó là Agent Core memory. Nó nói rằng nó idiomatic hơn và future-proof (điều này có thể là TBD và nên được kiểm tra kỹ hơn một chút). Nhưng bạn cũng có thể sử dụng S3, đó là điều bạn đã đề xuất.

Thực ra, tôi cá là có nhiều hơn hai options ở đây. Vì vậy, bạn có thể tiếp tục hỏi Tác nhân, "Có options nào khác không?" Vâng, và nó sẽ tiếp tục khám phá. Nhưng bạn không nên tự mình khóa chặt vào rigid flow là điểm khởi đầu ở đây. Vâng, vậy đó, tôi nghĩ là hết deck của tôi rồi.

Live Demo: Agent Core và MCP Servers

Điều tôi sẽ nói đến là hãy chạy thử sample tôi vừa trình bày ở trên. Vậy về cơ bản, hãy để tôi xóa nó đi. Và tôi sẽ thực hiện một live demo về các specs trong Kiro và cách chúng ta có thể fine-tune mọi thứ một chút.

Project này là một Node.js app. Nó là một CDK. Một lần nữa, tôi không cố gắng bán thêm AWS. Đây chỉ là những technologies tôi quen thuộc, vì vậy tôi có thể làm việc nhanh hơn rất nhiều. Vì vậy, tôi muốn biết một chút về Agent Core, đó là một AWS offering mới. Và với tư cách là người xây dựng một tác nhân, tôi có lẽ nên quen thuộc với nó. Vì vậy, tôi không đủ quen thuộc với nó. Chúng tôi có một số người khác ở đây biết rất nhiều về nó. Vì vậy, tôi sẽ thừa nhận một chút rằng, bạn biết đấy, bạn đã bắt gặp tôi.

Vì vậy, tôi đã thiết lập một CDK stack, đó chỉ là IAC technology để deploy software. Tôi quen thuộc với nó, và tôi thích nó. Vì vậy, tôi có một stack ở đây cho phép tôi deploy bất cứ thứ gì mà một Agent Core runtime là. Tôi không biết; tôi yêu cầu Kiro làm điều đó. Chúng ta đã hard-coded phần này. Vì vậy, chúng ta đã hard-coded structure chung. Chúng ta có một tác nhân. Chúng ta đã thiết lập IAC. Sau đó tôi đã hard-coded thêm commitlint. Tôi đã thêm Husky. Một vài thứ như thế này mà tôi thích cho TypeScript project của riêng mình. Vì vậy, tôi khá chắc ESLint cũng có trong đó, tôi nghĩ vậy. Vì vậy, chúng ta có một basic project ở đây mà tôi biết có thể deploy lên AWS account cá nhân của tôi.

Bây giờ tôi sẽ vào đây và, ồ, và điều quan trọng, điều này cực kỳ quan trọng vì tôi không biết Agent Core hoạt động như thế nào. Và tôi có thể đọc docs, nhưng docs dài và phức tạp. Và tôi thực sự chỉ đang cố gắng xây dựng một POC để tự mình tìm hiểu về nó. Vì vậy, tôi đã thêm hai MCP servers. Ồ không, có lẽ tôi đã không thêm. Để tôi kiểm tra. Ồ, được rồi, vâng, xin lỗi. Nằm sâu dưới cùng này.

Đây là Kiro MCP config của tôi. Tôi đã thêm một MCP server quan trọng ở đây, đó là AWS documentation MCP server. Có những cách khác để lấy documentation. Bạn có thể sử dụng những thứ như Tetzl Level 7, nhưng trong trường hợp này, cái này được AWS cung cấp. Vì vậy, tôi có một số confidence rằng nó có thể chính xác. Vì vậy, tôi đã sử dụng cái này để giúp tác nhân có knowledge về những technologies nào tồn tại. Và tôi nghĩ tôi cũng đã sử dụng Fetch khá nhiều. Vì vậy, đây là hai MCP servers tôi đã cung cấp cho system. Hãy tạo và tiếp tục.

Thực thi Live Demo và Thách thức Kiro

Vì vậy, tôi sẽ chạy lại cái này từ đầu. Vậy điều tôi đã làm vào tối qua hoặc có lẽ là tối hôm trước là tôi đã ngồi xuống và system này về cơ bản đã hoạt động, và bây giờ tôi muốn bắt đầu thực hiện spec-driven development. Vì vậy, tôi muốn thêm session ID concept này và sau đó tôi muốn read/write conversation vào S3 file này, vân vân. Đây là toàn bộ vấn đề bias mà tôi đã chỉ cho bạn trước đó. Chúng ta sẽ kích hoạt điều đó thông qua Kiro. Nó sẽ bắt đầu chạy, chugging away. Và sau đó nó sẽ xem liệu spec có tồn tại không. Được rồi, folder có tồn tại. Nó có lẽ sẽ nhận ra không có files nào ở đó và bắt đầu hoạt động.

Nhưng từ đây, tôi sẽ live demo. Nó sẽ đọc qua requirements. Nó sẽ đọc qua docs hiện có. Nó sẽ đọc qua files hiện có, thu thập context cần thiết, và churn away. Nhưng trong chốc lát, một khi nó tạo ra requirements và design ban đầu, tôi sẽ thách thức nó sử dụng MCP servers của riêng nó. "Tôi muốn bạn đi và nghiên cứu cách tốt nhất để làm điều này và cung cấp cho tôi một số proposals." Và đây là lý do tại sao tôi hy vọng clip của tôi hoạt động vì tôi sẽ đặt cái này xuống một lúc.

Vậy, bạn biết đấy, "Tôi không biết liệu đây có phải là cách tốt nhất để làm điều này không. Hãy đọc docs, hãy sử dụng Fetch." Và nó sẽ làm điều đó. Nó sẽ tiếp tục hoạt động ở đây. Và sau đó quay lại với tôi sau khi nó có lẽ đã có một vài ideas và đã đề xuất chúng. Nhưng đây là một ví dụ về việc tôi chỉ sử dụng thêm capabilities: sử dụng Fetch, sử dụng docs MCP, sử dụng bất cứ thứ gì bạn có thể để có được best information, và đừng tin ngay những gì tôi nói. Đây thường là những điều chúng ta phải prompt khá mạnh mẽ để tác nhân thực hiện. Nhưng nếu bạn làm điều đó trong real time, nó hoạt động khá tốt.

Phân Tích Yêu Cầu và Quyết Định Thiết Kế

Một lần nữa, tất cả các tác nhân này đều rất dễ dàng thích nghi. Vì vậy, chỉ vì tôi đã nói điều gì đó trong tài liệu dành cho sinh viên, điều đó có thể không thực sự là điều quan trọng nhất từ ​​góc độ của tác nhân trong tương lai. Tác nhân đã thực hiện một chút nghiên cứu và hiểu rằng LANG graph, khung làm việc tác nhân mà chúng tôi đang sử dụng, đã có sẵn kiến thức về tính bền vững. Trên thực tế, trong trường hợp này, nó đã không tìm thấy—nó đã không sử dụng MCP cho các tài liệu của agent core—nó không tìm thấy rằng agent core có kiến thức về tính bền vững. Vì vậy, có lẽ, giả sử tôi vẫn không biết điều này là do tôi đã không chạy thử (dry run) nó vài ngày trước. Chúng ta có thể phải tìm hiểu điều đó sau trong giai đoạn design phase (thiết kế).

Vì vậy, tôi nghĩ nó sẽ lặp lại tất cả các requirements (yêu cầu) của tôi ở đây. Nó có thể sử dụng các requirements dựa trên những gì nó hiện biết về LANG graph và cách nó có thể tích hợp nguyên bản với checkpointing (điểm kiểm tra), nhưng nó vẫn bị ràng buộc chặt chẽ với quyết định S3 mà tôi đã ngụ ý trong lời nhắc. Vì vậy, đó là điều cần lưu ý. Bất cứ điều gì bạn đưa vào lời nhắc đều đang định hình tác nhân một cách hiệu quả, dù tốt hay xấu. Bạn thấy đấy, nó vẫn đang lặp lại. Vì vậy, nó xuất hiện và nói, "Điều này có ổn không?" Chúng tôi đã thay đổi thành... Tôi sẽ nói, "Trông tuyệt vời. Hãy chuyển sang giai đoạn design phase (thiết kế)."

Giờ đây, Kuro sẽ lấy các requirements của tôi và đưa tôi vào giai đoạn design phase (thiết kế) của dự án này. Tôi có thể làm cho điều này lớn hơn một chút, nhưng đây là một ví dụ về những gì tôi muốn nói về các EARs requirements này.

Định Dạng EARs và Suy Luận Tự Động

User story (câu chuyện người dùng) ở đây là: Với tư cách là một dev (nhà phát triển), tôi muốn triển khai các check pointers (bộ kiểm tra điểm) tùy chỉnh dựa trên S3. Tác nhân có thể sử dụng cơ chế bền vững của LANG graph với S3. Tuyệt vời. Điều đó nghe có vẻ hợp lý đối với tôi, một người đồng sáng tạo những requirements này.

Cú pháp "khi, thì, sẽ" này—đây là EARs format (định dạng EARs). Và ngôn ngữ tự nhiên có cấu trúc rất quan trọng để chúng tôi truyền nó qua các mô hình không dựa trên LLM và mang lại cho bạn kết quả mang tính xác định hơn khi chúng tôi phân tích các requirements của bạn. Bởi vì, mục tiêu cuối cùng của chúng tôi là thực sự sử dụng LLM càng ít càng tốt—không phải là ít nhất có thể, nhưng ngày càng ít hơn theo thời gian. Chúng tôi muốn sử dụng các kỹ thuật suy luận tự động cổ điển để cung cấp cho bạn kết quả chất lượng cao, chứ không phải chỉ là những gì mô hình mới nhất nói với bạn.

Formal Hóa Yêu Cầu cho Thuộc Tính Đúng Đắn

Vì vậy, tôi đã xem qua. Đây là một phần của tài liệu design doc (thiết kế). Hãy cùng xem nó ở định dạng markdown. Chắc chắn rồi, bạn có một server (máy chủ), check pointer đi tới S3 — điều đó có lý. Sudo code (mã giả), một lần nữa, trong một tình huống thực tế, có lẽ tôi sẽ đọc kỹ hơn một chút. Và điều thực sự mới mẻ, một thứ chúng tôi đã phát hành vào ngày 17, đó là giờ đây Kuro sẽ tiến hành hình thức hóa các requirements (yêu cầu) cho các thuộc tính đúng đắn (correctness properties).

Hiện tại, hệ thống đang xem xét các requirements mà bạn đã tạo. Đây là các requirements chúng ta đã đồng ý với hệ thống trước đó. Chúng trông ổn, tôi đồng ý với chúng. Nó đang xem xét bản design (thiết kế), và nó đang trích xuất các thuộc tính đúng đắn (correctness properties) của hệ thống mà chúng ta muốn chạy property-based testing (kiểm thử dựa trên thuộc tính) sau này. Điều này có thể không quan trọng đối với bạn trong giai đoạn prototyping phase (tạo mẫu), nhưng sẽ rất quan trọng khi bạn đưa vào production (sản xuất). Bởi vì nếu những thuộc tính này là đúng và tất cả các thuộc tính này đều được đáp ứng, thì hệ thống sẽ phù hợp một-một với các requirements về ý định mà bạn đã cung cấp.

Kuro so với các Planning Mode Khác

Vâng, trong khi quá trình này đang diễn ra, có câu hỏi nào không? Có ai tò mò về điều này không? Vâng. Sự khác biệt chính giữa các [từ không rõ] mà chúng tôi có là gì? Tôi đã không sử dụng planning mode (chế độ lập kế hoạch) trong vài tuần rồi, mọi thứ diễn ra quá nhanh, hơi khó hiểu. Nhưng tôi nghĩ cuối cùng, điều chúng tôi muốn nói là Kuro's Spectrum and Dev không chỉ được điều khiển bởi LLM mà còn được điều khiển bởi một hệ thống có cấu trúc. Và đối với planning mode, tôi không chắc liệu có một workflow (quy trình làm việc) thực sự nào đằng sau nó dẫn dắt bạn qua các bước hay không, nhưng vâng, đây chắc chắn là cách tiếp cận của chúng tôi. Thật không may, tôi không đủ quen thuộc để đưa ra một ví dụ cụ thể hơn. Ý tôi là, nó không giống như điểm số của trường học, không giống như việc bạn đang ở trong ngôi trường nhỏ của mình, nhưng những gì Kuro làm về cơ bản là nằm trong kế hoạch của bạn. Chỉ là một execution plan (kế hoạch thực thi). Ồ, tôi hiểu rồi. Vậy sự khác biệt cơ bản là gì... Kế hoạch đó có được lưu trữ ở đâu không, hay nó chỉ là tạm thời? Được rồi.

Mục Tiêu Dài Hạn: Documentation Sống và Bidirectional Sync

Vậy điều tôi muốn theo thời gian không chỉ là cách chúng ta thực hiện những thay đổi mà chúng ta quan tâm, mà còn là documentation (tài liệu) và specification (đặc tả) về những gì hệ thống thực hiện. Vì vậy, mục tiêu dài hạn của tôi là với Kuro, chúng tôi có thể thực hiện một loại bidirectional sync (đồng bộ hóa hai chiều). Tức là, khi bạn tiếp tục làm việc với Kuro, bạn không chỉ tích lũy những task lists (danh sách tác vụ) này.

Và vì vậy tôi sẽ chỉ nói "Tiếp tục đi" để chuyển sang các tasks (tác vụ). Nhưng chúng tôi không chỉ tích lũy các task lists; thực ra, nếu tôi quay lại và, giả sử, thay đổi các requirements (yêu cầu) sau này, chúng tôi sẽ sửa đổi một spec (đặc tả) trước đó. Vì vậy, tôi thực sự chỉ đang xem xét một diff (sự khác biệt) của các requirements. Khi bạn đi qua green field process (quá trình phát triển dự án mới), bạn sẽ tạo ra rất nhiều "green" (mã mới) trong các PR (Pull Request) của mình, điều này có thể không phải là tốt nhất, vì tôi chỉ đang xem xét ba tệp markdown khổng lồ mới.

Nhưng lần tiếp theo, hoặc những lần sau đó, khi tôi mở tài liệu đó lên, tôi muốn thấy, "Ồ, bạn thực sự đã nới lỏng requirement (yêu cầu) trước đó. Bạn đã thêm một requirement mới và điều đó thực sự có tác động này đến design doc (tài liệu thiết kế)." Đó là quy trình mà nhóm Kuro nội bộ sử dụng để thảo luận về các thay đổi đối với hệ thống Kuro. Vì vậy, các design docs của chúng tôi nói chung đã được thay thế bằng spec reviews (đánh giá đặc tả).

Vì vậy, chúng tôi sẽ, bạn biết đấy, ai đó sẽ lấy một spec (đặc tả) từ markdown, họ sẽ đưa nó vào wiki của chúng tôi về cơ bản bằng cách sử dụng một MCP tool (công cụ MCP) mà chúng tôi sử dụng nội bộ. Và sau đó chúng tôi sẽ xem xét điều đó và bình luận về nó trong một loại design section (phần thiết kế) thay vì, bạn biết đấy, tệp markdown hoặc wiki này từ đầu. Vì vậy, nó trở thành một loại... tốt, nó thực sự không giống như một ADR (Hồ sơ quyết định kiến trúc) vì nó không cố định theo thời gian. Nó giống như living documentation (tài liệu sống) về hệ thống. Nhưng vâng, cảm ơn câu hỏi.

Cấu Trúc Templates và Quy Trình Linh Hoạt

Có một câu hỏi ở đây. Đây có thể là một câu hỏi về phổ phát triển, nhưng liệu có một template (mẫu) cho một tập hợp các tệp mà bạn điền vào không? Hiện tại, bạn đang ở trong design.md. design.md này là một hộp duy nhất, hay có... Ồ, câu hỏi hay. Vâng, câu hỏi là, liệu có—hãy sửa nếu tôi sai—một tập hợp các templates được sử dụng cho hệ thống không? Và câu hỏi đó có nhằm mục đích hỏi liệu bạn có thể thay đổi các templates không? Hay chỉ là liệu có tồn tại các templates không? Được rồi. Vậy, vâng, câu hỏi là, "Liệu có một tập hợp các templates không?" Có những lời nhắc ngầm trong hệ thống của chúng tôi về cách chúng tôi xử lý các specs của bạn. Bạn sẽ thấy ở thanh điều hướng trên cùng ở đây.

Hiện tại, chúng tôi rất cứng nhắc về requirement (yêu cầu) này—design (thiết kế), giai đoạn task list phase (danh sách tác vụ), nhưng chúng tôi biết điều đó không phù hợp với tất cả mọi người. Ví dụ, nếu bạn đang bắt đầu —chúng tôi nhận được phản hồi này từ rất nhiều nhân viên Amazon nội bộ—rằng tôi muốn bắt đầu với nó. Tôi có một ý tưởng cho một technical design (thiết kế kỹ thuật) và tôi không nhất thiết phải biết các requirements là gì, nhưng tôi biết tôi muốn tạo ra... có lẽ "thiết kế" thậm chí là từ sai. Tôi muốn bắt đầu bằng một technical note (ghi chú kỹ thuật). Chẳng hạn, "Tôi muốn refactor (tái cấu trúc) cái này," điều này thực sự thường xuyên xảy ra với refactoring. Vì vậy, tôi muốn refactor điều này để không còn phụ thuộc vào... Đây là một ví dụ điển hình: Kuro, chúng tôi sử dụng rất nhiều mutexes (cơ chế khóa) xung quanh hệ thống để đảm bảo rằng chúng tôi khóa một cách thích hợp khi tác nhân thực hiện các hành động nhất định vì chúng tôi không muốn các tác nhân khác cản trở nhau.

Nhưng có lẽ tôi muốn thách thức các requirements (yêu cầu) của hệ thống để tôi có thể loại bỏ một trong những mutexes này (hay một số khóa, tôi phải nói). Vì vậy, tôi có thể bắt đầu với một technical note (ghi chú kỹ thuật) và sau đó từ đó trích xuất các requirements mà tôi muốn chia sẻ với nhóm và nói, "Bạn biết đấy, tôi đã phải thử nghiệm với nó một thời gian để hiểu mình muốn xây dựng gì." Tôi vẫn muốn tạo ra tất cả các artifacts (hiện vật/kết quả) phong phú này.

Vì vậy, ngày nay đó là một workflow (quy trình làm việc) có cấu trúc. Chúng tôi đang thử nghiệm rất nhiều để làm cho nó linh hoạt hơn một chút. Nhưng cấu trúc rất quan trọng vì nó cho phép chúng tôi xây dựng các tooling (công cụ) có thể tái tạo mà không chỉ là một LLM. Vì vậy, tôi nghĩ đó là một điểm khác biệt quan trọng mà chúng tôi tạo ra: tác nhân của chúng tôi không chỉ là một LLM với một công việc trên đó. Phần back end (phụ trợ) có thể là một LLM hoặc có thể là các neuro symbolic reasoning tools (công cụ suy luận thần kinh-biểu tượng) khác ẩn bên dưới.

Và vì vậy chúng tôi cố gắng giữ sự phân biệt đó rõ ràng một chút rằng bạn không chỉ nói chuyện với Sonnet hay Gemini hay bất cứ thứ gì khác; bạn đang nói chuyện với một sự kết hợp của các hệ thống dựa trên loại task (tác vụ) bạn đang thực thi tại bất kỳ thời điểm nào. Mặc dù khi bạn trò chuyện, bạn chỉ đang nói chuyện với một LLM.

Nhưng vâng, chúng tôi có một template (mẫu) cho các requirements. Chúng tôi có một template cho design doc này bởi vì có những phần mà chúng tôi nghĩ là quan trọng cần đề cập. Và một lần nữa, nếu bạn không đồng ý và bạn nói, "Tôi không quan tâm đến phần testing strategy (chiến lược kiểm thử)," thì chỉ cần hỏi [Kuro/hệ thống]. Tương tự, task list (danh sách tác vụ) được cấu trúc vì chúng tôi cũng có các UI elements (thành phần giao diện người dùng) được xây dựng trên đó. Nó giống như task management (quản lý tác vụ). Chúng ta sẽ đến đó khi thực hiện một số property-based testing (kiểm thử dựa trên thuộc tính), nhưng có một số UI bổ sung mà chúng tôi sẽ thêm cho những thứ như tasks tùy chọn và những thứ tương tự. Và vì vậy chúng tôi cần cấu trúc ở đó để casual cell usp của chúng tôi hoạt động, chẳng hạn. Vâng, cảm ơn câu hỏi.

Dự Án Gramps: Dad Joke Generator với Memory

Ý tôi là, tôi cần ai đó nhắc tôi chúng ta đang làm gì. Ồ, đúng rồi. Chúng tôi đã xem xét và tổng hợp spec (đặc tả) để thêm memory (bộ nhớ) và một lượng persistence (tính bền vững) vào tác nhân của tôi. Tôi chưa giới thiệu cho bạn dự án này. Dự án này tên là Gramps. Nó là một tác nhân mà tôi đang triển khai tới agent core để tìm hiểu về nó. Tôi đã đề cập đến điều đó nhưng điều tôi chưa nói với bạn là nó là một dad joke generator (trình tạo truyện cười ông bố) — một cái rất đắt tiền vì chúng tôi đang cung cấp năng lượng cho nó thông qua các LLM. Nhưng về cơ bản, những câu chuyện cười của dad joke generator của bạn phải sạch sẽ. Chúng nên dựa trên lối chơi chữ, bạn biết đấy, rõ ràng là điểm cộng nếu chúng hơi sến sẩm nhưng đáng yêu.

Vì vậy, chúng tôi đang triển khai cái này vào phần back end (phụ trợ). Lý do tôi muốn memory (bộ nhớ) là vì mỗi khi tôi yêu cầu dad joke generator kể một câu chuyện cười, nó lại kể cùng một câu chuyện cười. Và điều đó thật nhàm chán, con tôi sẽ không hào hứng với điều đó. Vì vậy, tôi muốn memory để khi tôi quay lại cùng một session (phiên), tôi sẽ nhận được những câu chuyện cười khác nhau lặp đi lặp lại. Đó là context (ngữ cảnh) của dự án. Vì vậy, chúng tôi đã xem xét ở đây và thực sự nói rằng chúng tôi đã tạo ra thứ này. Chúng tôi đã thực hiện task list (danh sách tác vụ). Tôi đã nói, "Này, đây có phải là cách làm chuẩn không?" Điều tôi biết là chúng tôi thực sự không sử dụng tính năng memory của agent core, điều này có lẽ là một sai lầm lớn.

Thực Thi Tasks và System Prompt

Và bạn biết đấy, một cuộc biểu quyết nhanh: Chúng ta có muốn mắc lỗi và đi đến cùng, bao gồm cả synthesis (tổng hợp) và deployment (triển khai), không? Hay chúng ta nên sửa nó ngay bây giờ? "Chúng ta muốn sửa nó ngay bây giờ vì chúng ta biết rõ hơn." "Không, tôi muốn mắc lỗi. Cứ tiếp tục đi." Tôi có ba người đồng ý trong một căn phòng trống rỗng. Vì vậy, chúng ta sẽ mắc lỗi và sau đó quay lại sửa chữa sau.

Vậy hãy nói, "Chạy tất cả tasks (tác vụ) theo thứ tự." Lý do tôi đề cập "theo thứ tự" (nghe có vẻ rất cụ thể) là vì đây là một bản dựng xem trước của Kuro. Và ai đó vừa thêm vào system prompt (lời nhắc hệ thống): "Tôi chỉ nên thực hiện một task tại một thời điểm." Và tôi thấy rằng nếu tôi nói, "Chạy tất cả tasks," nó nghĩ rằng bằng cách nào đó tôi muốn nói hãy thực hiện tất cả song song. Vì vậy, điều đó sẽ được sửa trước khi những thay đổi này được đưa vào production (sản xuất).

Quy Trình Back End và Steering Docs

Kuro sẽ tiếp tục xử lý hệ thống ở phần back end. Nó có các steering docs (tài liệu hướng dẫn) giải thích cách thực hiện công việc của nó. Nó có — mà tôi đoán tôi nên cho các bạn xem — steering (điều hướng) một lần nữa giống như memory (bộ nhớ). Vì vậy, tôi có một số steering về cách thực hiện commits (cam kết).

Cải thiện Quy trình Triển khai với Kiro

Tôi muốn có các commit, nhưng đồng thời cũng muốn điều hướng các vấn đề như làm thế nào để thực sự triển khai thứ này? Làm thế nào để bạn xử lý core tác nhân và sau đó làm thế nào để bạn chạy lệnh cần thiết để triển khai nó vào tài khoản dev cục bộ của tôi? Đó hầu hết chỉ là một ví dụ nữa về việc mài giũa các công cụ của bạn. Tôi đã trải qua một quá trình khá khó khăn để tìm ra rằng bạn phải sử dụng tham số này trên CDK, lệnh CDK này, bạn phải sử dụng cờ này, nếu không nó sẽ không hoạt động chính xác. Và vì vậy, một khi tôi đã vượt qua được nỗi đau của việc học đó, tôi chỉ nói Kiro, nơi bạn học được vào một tài liệu hướng dẫn (steering doc) và nó thường làm rất tốt việc tóm tắt. Và vì vậy, tôi đã tự động tạo ra tệp MD workflow đồ thị chiều dài core tác nhân này. Tức là, nó sẽ tiếp tục chạy và hoàn thành công việc của mình ở chế độ nền, và chúng ta có thể theo dõi nó, nhưng trong thời gian chờ đợi.

Tôi nghĩ ở thời điểm này, chúng ta đang ở một vị trí khá linh hoạt. Vì vậy, đối với những người muốn, hãy thoải mái sử dụng Kiro, hãy thử SpectreDev trên máy của riêng bạn. Tôi sẽ tiếp tục chạy cái này ở chế độ nền và nhận câu hỏi, bình luận, nhưng đó là phần đã lên lịch cho ngày hôm nay. Kiro hoạt động như thế nào đối với các cơ sở mã lớn, hiện có? Vâng, câu hỏi là Kiro hoạt động như thế nào đối với các cơ sở mã lớn và hiện có, về cơ bản là trường hợp sử dụng brownfield.

Kiro và Cơ sở mã lớn hiện có

Câu trả lời là nó phụ thuộc vào những gì bạn đang cố gắng làm cho SpectreDev. Bạn có thể yêu cầu nghiên cứu của bạn về những gì đã tồn tại. Vì vậy, khi bạn bắt đầu một spec mới, nó thường sẽ bắt đầu bằng cách đọc qua cây làm việc (working tree). Nhưng tác nhân thường bắt đầu từ một góc độ trống rơn, đúng không? Và vì vậy, để hiểu hệ thống. Trong thực tế, điều đó có nghĩa là bạn sẽ có rất nhiều thứ như nếu hệ thống của bạn đã có tách biệt mối quan tâm (separation of concerns) tốt. Các thành phần trong hệ thống của bạn có tính gắn kết (cohesive) cao và chúng khá mạch lạc (coherent) và gắn kết cao. Nó sẽ làm rất tốt, đúng không? Nó sẽ có thể nói rằng đây là mô-đun thực hiện việc này. Tôi không cần phải giữ 18 thứ trong ngữ cảnh của mình để làm công việc của tôi. Và nó sẽ làm tốt.

Nếu bạn, hãy lấy một ví dụ ngẫu nhiên, nếu bạn đang cố gắng ra mắt một IDE rất nhanh chóng trước một đợt ra mắt AWS và bạn đã chấp nhận rất nhiều nợ kỹ thuật (tech debt) trên đường đi mà bạn cần phải tháo gỡ. Và bạn biết đấy, tôi chắc chắn rằng không ai ở đây sẽ làm điều đó. Nhưng trong trường hợp bạn đã làm như tôi, thì tác nhân của bạn thực sự có thể gặp khó khăn hơn nhiều khi duyệt qua cơ sở mã theo cùng một cách mà dev sẽ làm, đúng không? Vì vậy, từ góc độ đó, những thứ đáng tin cậy hơn như bộ kiểm thử (test suite) của bạn và những thứ dễ hiểu hơn như tách biệt mô-đun (module separation) và phân rã mối quan tâm (decomposition of concerns) thì tác nhân sẽ làm tốt hơn. Và điều ngược lại cũng đúng, tất nhiên.

Đối với những thứ như hiểu cơ sở mã, đây là một ví dụ không hay vì đây là một cơ sở mã rất nhỏ. Nhưng chúng tôi có những thứ như tìm kiếm mã (code search) và không gian làm việc (workspace). Tôi không biết bạn có gọi những thứ này là nhà cung cấp ngữ cảnh (context providers) hay không. Vì vậy, bạn có thể vào đây và chỉ nói, tôi muốn tìm mã. Cái gì vậy? Tôi có thể đã tắt nó. Tôi đã tắt nó vì các cơ sở mã không đủ lớn sẽ làm những việc như lập chỉ mục (indexing) ở chế độ nền. Vì vậy, tác nhân, giống như bạn có thể thực hiện tìm kiếm ngữ nghĩa (semantic search) trên những gì bạn có. Nhưng nếu bạn chỉ trò chuyện, thì nói chung, Kiro sẽ đi vào và thực hiện một loại tìm kiếm nền để tìm ra cách làm công việc của nó. Khi cơ sở mã mở rộng (scales up), nó sẽ ít, bạn có thể làm kém hiệu quả hơn nói chung, nhưng đó là một điều chúng tôi đang cố gắng thực hiện như một nhóm. Điều đó có trả lời câu hỏi của bạn không hay tôi đã đi chệch hướng một chút? Vâng, tôi hiểu rồi. Tuyệt vời. Còn gì nữa không?

Lập chỉ mục và Quản lý Ngữ cảnh

Bạn sẵn lòng chờ đợi bao lâu để quá trình lập chỉ mục hoàn tất? Một ví dụ tôi có là Code OSS. Nếu không quá rõ ràng khi nhìn vào, Kiro là một phân nhánh (fork) của Code OSS, giống như Cursor và Surf. Một trong những thách thức chúng tôi gặp phải là cơ sở mã của Code OSS rất lớn, khá dài. Có những cơ sở mã lớn khác ngoài kia, nhưng đó là loại cơ sở mã lớn của tôi vì tôi không bị buộc phải làm việc với nó thường xuyên. Và vì vậy, chắc chắn có một sự chậm lại đáng kể khi bạn đối phó với một thứ lớn như vậy, đặc biệt là khi bạn nói về lập chỉ mục cơ sở mã, đây là một lĩnh vực công việc rất tích cực đối với chúng tôi. Vì vậy, tôi đang cố gắng làm những việc như loại bỏ lập chỉ mục khỏi đường găng (critical path) để bạn không phải chờ đợi ở đó trên một loại luồng hiển thị (render thread) chậm vì quá trình lập chỉ mục đang chạy. Nhưng trên thực tế, không nên có. Ý tôi là, một lần nữa, tác nhân có thể hoạt động kém hơn trong thực tế, nhưng chúng ta sẽ nói chuyện trong vài tuần tới hoặc tại Reinvent về cách một số tính năng template trong Kiro được xây dựng thông qua spec trong một cơ sở mã mà chúng tôi không hiểu rõ lắm vì chúng tôi không phải là nhà phát triển mã. Và Kiro đã làm khá tốt việc đó. Nhưng một lần nữa, đó là minh chứng cho thực tế là cơ sở mã được cấu trúc khá tốt. Và giống như nếu bạn đã dành thời gian để hiểu cách nó hoạt động, nó rất dễ hiểu. Nếu bạn chưa, nó có thể hơi khó hiểu khi nhìn vào.

Vâng, về mặt lập chỉ mục thì nó giống như chỉ đưa, đây là một phương trình từ trọng tâm vào ngữ cảnh hay có cách nào để tạo ra một loại cơ sở dữ liệu vector (vector database) của toàn bộ cơ sở mã và sau đó truy vấn (query) không? Vâng, câu hỏi là, bạn muốn nói gì về lập chỉ mục vì lập chỉ mục có thể là nhiều thứ khác nhau. Và ý tôi là, tác nhân thực sự không được cung cấp. Tôi sẽ giữ ngữ cảnh tác nhân càng nhỏ càng tốt. Chúng tôi sử dụng chỉ mục cho hầu hết các hiệu ứng phụ như nếu bạn đang thực hiện tìm kiếm mã, hoặc nếu tôi làm một cái gì đó như tìm kiếm pound, thì tệp trong đây là server giống như chúng tôi sử dụng nó nhiều hơn cho các loại giao diện người dùng này, hơn là đưa nó cho tác nhân bởi vì tác nhân làm điều này, đây là một loại giai thoại và dựa trên điểm chuẩn (benchmarks) của chúng tôi, hoạt động tốt hơn khi được cung cấp ít ngữ cảnh hơn nhưng được cung cấp các công cụ để hiểu nơi tìm thấy mọi thứ. Điều chúng tôi đã nghe rất nhiều tại hội nghị này là một loại tiết lộ tăng dần (incremental disclosure) và một lần nữa, chúng tôi không muốn tải quá nhiều vào đầu ngữ cảnh và cuộc trò chuyện với tác nhân sẽ là tác nhân tự khám phá ngữ cảnh phù hợp cho nhiệm vụ. Vâng. Cảm ơn bạn.

Quản lý Phiên và Ưu tiên Độ chính xác

Các bạn quản lý độ dài phiên (session length) như nén (compression) của người dùng hoặc cắt tỉa (pruning) khỏi các cabinets thông thường như thế nào? Vâng. Vì vậy, câu hỏi là làm thế nào chúng tôi quản lý độ dài phiên. Chúng tôi không có cắt tỉa tăng dần (incremental pruning) hay tóm tắt tăng dần (incremental summary) nào hôm nay. Về cơ bản, bạn chỉ tạo ngữ cảnh cho đến khi bạn đạt giới hạn của mình, mà tôi nghĩ bây giờ tôi đang ở chế độ tự động, có giới hạn mã thông báo (token limit) là 200K tương tự như Sonnet. Vì vậy, chúng tôi chưa có một thuật toán rất tinh vi ở đây, chúng tôi đã xem xét một vài thứ nhưng mối quan tâm số một của chúng tôi thực sự là tỷ lệ truy cập bộ nhớ đệm lời nhắc (prompt caching hit rate). Và vì vậy, trong một trường hợp sử dụng (use case) thông thường, tôi có thể đạt được khoảng 90-95% mã thông báo được lưu vào bộ nhớ đệm trên mỗi lượt, điều đó có nghĩa là các tương tác của tôi rất nhanh và đó là hoặc chúng nhanh hơn nhiều so với giải pháp thay thế, đó là tôi đang gửi 160K mã thông báo tới Bedrock lạnh.

Đó là một trong những lý do chúng tôi thực sự chưa thử nghiệm nhiều với tóm tắt tăng dần. Tính năng tóm tắt của chúng tôi tồn tại khi bạn đạt đến giới hạn. Nó không tốt lắm. Đó là một thứ chúng tôi đang cố gắng ra mắt một phiên bản cải tiến rất, rất sớm. Ví dụ, trong vài tuần tới, nó sẽ nhanh hơn. Hiện tại, đó là một thao tác một lần (one off operation) có thể mất tới 30 hoặc 45 giây, đây là một trải nghiệm kinh khủng. Chúng tôi hy vọng sẽ khắc phục điều đó ở đây và biến nó thành một trải nghiệm thời gian thực. Vì vậy, đó là lý do duy nhất. Ý tôi là SpectreDev ít liên quan đến hiệu suất (performance) mà liên quan nhiều hơn đến khả năng tái tạo (reproducibility) và độ chính xác (accuracy) của tác nhân. Và nếu chúng tôi có thể cung cấp cho bạn kết quả đúng.

Cách tôi và tôi nghĩ rằng chúng tôi nói về nó nội bộ trong nhóm này là, nếu tôi dành 10 giây để đưa một lời nhắc cho tác nhân và sau đó nó đi và làm sai, thì tôi không bị thiệt hại gì nhiều, đúng không? Tôi đã đốt bao nhiêu mã thông báo và bạn biết đấy, một vài xu phí sử dụng tín dụng với bất kỳ nhà cung cấp nào của tôi, nhưng tôi đã dành 10 giây để tạo một lời nhắc. Nếu tôi dành 5 đến 10 phút với hệ thống tạo ra một tài liệu thiết kế (design doc) chi tiết hoặc thậm chí là một bộ yêu cầu (requirements) chi tiết, tôi muốn nó làm một công việc khá tốt. Nếu tôi dành một giờ để tạo một tài liệu thiết kế, xem xét với nhóm của tôi và sau đó tổng hợp từ đó, tôi muốn nó phải làm đúng. Vì vậy, mục tiêu không nhất thiết chỉ là độ trễ (latency), mà thực sự là độ chính xác khi chúng ta nói về điều đó. Vâng, đó là cả hai và bạn cần làm cả hai, nhưng spec đến nhiều hơn từ mục tiêu có đầu ra có khả năng tái tạo cao. Tôi sẽ đi qua đây trước rồi đến lượt bạn.

Quản lý Ngữ cảnh giữa các Tác nhân và Nhiệm vụ

Làm thế nào để mỗi tác nhân nhiệm vụ (task agent) này chuyển ngữ cảnh cho nhau? Và sau đó, bạn chỉ nên chạy nhiệm vụ cha (parent task) này vì nó vừa hoàn thành tất cả các nhiệm vụ như 3.1, 3.2, 3.3, nhưng sau đó nó vẫn nghĩ rằng 3.1 chưa hoàn thành và đã chạy lại nhiệm vụ đó và 3.2. Vâng, không sao. Được rồi. Vâng. Vì vậy, nếu bạn. Câu hỏi là nếu bạn đang ở trong giao diện người dùng (UI) và bạn đang chạy các nhiệm vụ và tôi có thể chỉ cần kéo danh sách nhiệm vụ của mình lên đây. Vì vậy, nếu tôi chỉ nhấn bắt đầu, bắt đầu, bắt đầu. Mỗi cái này sẽ là một phiên (session) mới, điều đó có nghĩa là ngữ cảnh hoàn toàn độc đáo.

Cá nhân tôi, nếu tôi có đủ ngữ cảnh được cung cấp, tôi chỉ nói hãy làm tất cả các nhiệm vụ, bởi vì tôi thấy điều đó dễ hiểu hơn. Và tôi nghĩ tôi thực sự đạt được hiệu suất tốt hơn. Nhưng theo mặc định, mỗi nhiệm vụ sẽ là một phiên mới không có ngữ cảnh chia sẻ với các phiên trước đó. Vì vậy, phiên thực sự chỉ được khởi tạo bằng đặc tả của bạn. Và sau đó, giống như ở đây bạn đang làm việc trên một spec làm tất cả những thứ này, khối văn bản. Và bạn đang làm nhiệm vụ này mà không làm bất kỳ nhiệm vụ nào khác, chỉ làm nhiệm vụ này. Vì vậy, điều đó nghe có vẻ giống như một lỗi. Đã có một số tác nhân cho một số thứ. Chúng tôi chưa có một số tính năng tác quyền (agency) trong Kiro. Một số thứ chúng tôi đang nghiên cứu. Vâng. Vâng, bởi vì ý tôi là, tôi thực sự có thể đọc nếu chúng tôi nhấp vào nhiệm vụ ba. Và tôi có 3.1, 3.2, 3.3 ở đó được tách biệt. Không có gì tốt. Chúng không thể có các hệ thống khác nhau làm việc trên chúng. Vâng. Chúng tôi có tác nhân tùy chỉnh (custom agents) trong CLI của Kiro. CLI của Kiro có khái niệm về tác nhân tùy chỉnh, có thể được chạy như một nhiệm vụ. Đó là một thứ chúng tôi đang thử nghiệm ngay bây giờ trong Kiro Desktop. Và tôi nghĩ bạn có một cái khác. Vâng, tôi xin lỗi vì điều này, nhưng từ thư mục spec. Và sau đó khi bạn thực hiện ngày càng nhiều nhiệm vụ này theo thời gian.

Cấu trúc Đặc tả trong Dự án

Vâng. Nó chỉ là tất cả trong một tài liệu thiết kế, các nhiệm vụ? Toàn bộ dự án của bạn được định nghĩa ở đó hay nó được nhóm lại? Đó là một câu hỏi hay. Vâng. Tôi sẽ có nhiều. Tôi sẽ có một. Câu hỏi là khi bạn làm nhiều hơn, bạn tạo ra, giả sử nhiều spec hơn theo thời gian. Bạn có đang tạo ra một spec khổng lồ không và không. Hãy để tôi mở một dự án khác. Đây là, ví dụ, tiện ích mở rộng của Kiro, là một tiện ích mở rộng 1P (1p extension) bên trong IDE của Kiro. Đây là nơi tác nhân sống. Và vì vậy, chúng tôi đã cắt tỉa một số spec. Nhưng có những spec ở đây mà chúng tôi có thể nói chuyện hoặc tôi chỉ có thể trình diễn.

Vì vậy, đây là cách tôi nghĩ về nó là các spec giống như đại diện cho một tính năng (feature) hoặc lĩnh vực vấn đề (problem area) trong dự án. Và vì vậy, ví dụ, tôi có thể phóng to cái này một chút. Ví dụ, chúng tôi có một số kiểm thử (tests). Chúng tôi đã làm những việc như, ồ, liệu chúng ta có thể có một bộ đăng ký lời nhắc (prompt registry) không? Liệu chúng ta có thể có một trình tải tệp (file loader) không? Chúng có thể hoặc không thể đi đến môi trường sản phẩm (production). Tôi muốn, hãy để tôi thử trên giao diện người dùng trò chuyện (chat UI). Vì vậy, đây chỉ là một người nào đó sẽ đi và dành có lẽ vài ngày làm việc cho một Kỹ sư phần mềm. Hỗ trợ Mb của tác nhân là một ví dụ hay, nơi chúng tôi chỉ, bạn biết đấy, tôi đã nói nghiên cứu Agent's Md là gì và xây dựng nó theo cách bạn xây dựng tài liệu hướng dẫn và hỗ trợ theo cùng một cách. Spec này khá khó có khả năng chúng tôi sẽ quay lại và xem xét lại trong tương lai. Vì vậy, tôi thực sự có thể chỉ xóa nó, đó là điều chúng tôi đã làm với một số spec cũ hơn. Nhưng một ví dụ điển hình mà chúng tôi có thể quay lại là công cụ làm sạch lịch sử tin nhắn (message history sanitizer) của chúng tôi.

Khắc Phục Lỗi Trình Tự và Hệ Thống Sanitizer

Một vấn đề chúng tôi gặp phải sớm trong quá trình phát triển dự án Heroes là việc gửi các chuỗi thông báo không hợp lệ. Ví dụ, API của Anthropic yêu cầu các tool phải nằm cùng thứ tự mà chúng được gọi trong phản hồi, nhưng hệ thống lại không thực hiện điều đó. Vì vậy, chúng tôi đã xây dựng một hệ thống sanitizer (bộ lọc/làm sạch) hoàn chỉnh với nhiều yêu cầu cụ thể. Ví dụ: "Khi một cuộc trò chuyện được xác thực, hệ thống phải kiểm tra rằng mỗi đầu vào của người dùng đều có nội dung không trống hoặc là phản hồi từ tool". Chúng tôi từng gặp các trường hợp chuỗi trống được truyền vào nhưng vẫn có phản hồi từ tool. Đây là một ví dụ điển hình về việc theo thời gian, chúng tôi đã bổ sung các yêu cầu, đặc biệt là vào tiêu chí chấp nhận của các yêu cầu đó, khi các quy tắc xác thực mới được phát hiện.

Cập nhật Spec và Nghiên cứu Tự động

Bạn xử lý các trường hợp này như thế nào? Chẳng hạn, bạn có một tính năng cần... để tôi diễn đạt lại. Bạn sẽ quay lại và cập nhật spec đó. Thông thường, bạn sẽ thấy... để tôi thử một cuộc trò chuyện mới ở đây. Không, đó là một ý tưởng tồi.

Ở đây, tôi đã thực hiện một yêu cầu trong chế độ inspect mode để thêm UI telemetry vào hệ thống. Tôi sẽ giúp bạn thêm nó. Tôi sẽ kiểm tra xem có bất kỳ runbook liên quan nào trong codebase và gửi phần triển khai. Nó có thể sẽ thực hiện một chút nghiên cứu ở đây. Và sau đó, một lần nữa, vì đây là một LLM, nó có thể tìm thấy hoặc không tìm thấy spec hiện có, nhưng lý tưởng nhất là sau khi nghiên cứu, nó sẽ nói rằng "đã tồn tại một spec cho các thứ như UI telemetry. Tôi sẽ sửa đổi cái đó." Trong trường hợp này, tôi sẽ chỉ yêu cầu nó như một operator của hệ thống. Nhưng theo thời gian, chúng tôi muốn điều đó dễ dàng hơn cho bạn với tư cách là người dùng, không cần phải suy nghĩ quá nhiều. Chúng tôi có thể xem nó hoạt động.

Tích hợp AWS và Các Nền tảng Khác

Có điều gì chúng tôi đã cấu hình ở đây để giúp nó hoạt động tốt hơn với AWS không? Tôi đang cố gắng... không hẳn. Câu hỏi không phải là "có điều gì ở đây được cấu hình sẵn để làm cho nó hoạt động tốt hơn với AWS không?" Không, chúng tôi chủ đích... chúng tôi được AWS tài trợ, điều mà Andy Jassy và Jeff Bezos đang trả tiền cho tôi, nhưng chúng tôi không phải là một sản phẩm của AWS được tích hợp sâu rộng với phần còn lại của hệ sinh thái AWS. Mặc dù vậy, tôi vẫn nhận được ba email khi ai đó nói "tại sao thứ khác mà chúng tôi xây dựng với AWS lại không hoạt động với Cure?"

Tương tự, nếu bạn đang xây dựng trên GCP, Azure, hoặc chạy một hệ thống on-prem nào đó, sản phẩm của chúng tôi vẫn sẽ hoạt động tốt cho bạn. Đó là mục tiêu của chúng tôi. Một câu trả lời tiềm năng là tài liệu AWS và thành phần SDK. Vâng. Có các dịch vụ entity mà bạn có thể thêm vào bất kỳ thứ nào trong số này để giúp phần còn lại hoạt động. Vâng, đó là một điểm hay. Chẳng hạn, trong trường hợp này, tôi thực sự phải thêm tài liệu AWS MCP vào đây. Tất nhiên chúng tôi có thể đã đóng gói nó sẵn, nhưng tôi không muốn cung cấp nó cho những khách hàng không cần. Vâng, bởi vì AWS không phải là tài liệu duy nhất mà chúng tôi quan tâm.

Quản lý Spec Đa Chức năng

Quay lại câu hỏi của bạn, nó đã tìm thấy spec hiện có cho telemetry. Nó đã đọc nó. Nó đã đọc các phần khác nhau của nó. Và bây giờ nó đang thực hiện các sửa đổi. Chúng ta có thể theo dõi diff khi nó hiển thị ở đây. Vì vậy, nó đã thêm các yêu cầu mới vào spec đã tồn tại. Đây thực sự là một trường hợp khác về việc thay đổi hệ thống thay vì chỉ thêm một chuỗi spec không ngừng.

Tôi tự hỏi là, làm thế nào để họ biết quyết định đặt spec ở đâu? Bạn biết đấy, nếu bạn chia dự án của mình thành các danh mục khác nhau, vâng, tôi hình dung sẽ có sự chồng chéo. Vâng, đó là một phần cốt lõi của phát triển phần mềm, đúng không? Làm thế nào để bạn thực sự xác định ranh giới giữa các phần khác nhau của hệ thống, các mối quan tâm khác nhau của sản phẩm?

Và nếu bạn muốn xây dựng một thứ gì đó như "tôi có một nhiệm vụ, nó sẽ tốn rất nhiều tiền để thay đổi ba hoặc bốn thứ". Vâng, bạn sẽ thay đổi ba hoặc bốn spec và sau đó chạy các nhiệm vụ trên ba hoặc bốn... Ồ, không, nó không nên làm thế. Nó có lẽ... một lần nữa, tôi không có một ví dụ tốt ngay bây giờ mà chúng ta có thể thực hiện. Nhưng quan điểm của tôi là nếu bạn đang làm việc trên một thứ gì đó đa chức năng... Nhân tiện, câu hỏi là: "Nếu tôi đang làm việc trên một thứ gì đó, giả sử tôi có một spec cho yêu cầu bảo mật, và tôi có một spec cho thiết kế API (như hình dạng API), và tôi có một spec cho logging. Và tôi đang thay đổi một cái gì đó trong giao diện công khai của API mà là một vấn đề liên quan đến bảo mật vì chúng ta đang biên tập PII trong logging." Tôi nghĩ đó có lẽ là một trường hợp sử dụng bán hữu hình mà tất cả chúng ta có thể hình dung đến từ các nhóm quản trị của mình. Tôi hình dung rằng bạn sẽ chọn một trong số đó để tải các yêu cầu vào hoặc bạn tạo một loại spec đa chức năng. Tôi nghĩ bạn, với tư cách là một operator, sẽ đưa ra quyết định đó, giống như cách bạn thực sự triển khai nó có thể là... bạn sẽ không nhất thiết phải triển khai các module biên tập PII API của tôi như một thứ độc lập. Tôi hình dung nó sẽ là một chủ đề xuyên suốt codebase của bạn.

Cũng có những ví dụ tuyệt vời khác, có các sản phẩm multi-group works, chúng đã được phát hành, ra mắt GA vào thứ Hai, và bây giờ bạn có thể kéo các... ví dụ như trong ví dụ của bạn về API và tất cả chúng, và thậm chí cả các thứ frontend, bạn có thể đưa các dự án đó vào nếu bạn làm việc riêng biệt và sau đó vẫn làm việc. Vâng, cảm ơn Berk. Mô hình tinh thần: spec tạo ra mã sau đó, như tất cả những gì bạn có thể chỉ định.

Quy trình từ Spec đến Code

Vâng, vậy là chúng tôi đã tổng hợp spec một cách hiệu quả. Chúng tôi đã ngồi lại, định nghĩa các yêu cầu, thiết kế và danh sách nhiệm vụ. Tôi đã yêu cầu Kieran bây giờ thực hiện tất cả các nhiệm vụ trong spec này, vì vậy nó đã chạy chúng từng cái một. Nó cơ bản làm việc trên các phần nhỏ, dễ xử lý, từng chunk một, và bây giờ điều này đã hoàn tất.

Vậy, những gì chúng tôi thực sự đã sản xuất không chỉ là spec hoàn chỉnh, mà nó còn đi vào tác nhân của tôi ở đây và thực hiện một vài điều trong CDK repo, bởi vì nó đang thực hiện persistence test three. Tôi chắc rằng nó đã thêm một bucket, một số mã hóa bucket mới trong dữ liệu. Sau đó, nó đi vào tác nhân, thêm S3 checkpoints saver. Có vẻ như nó đã tạo một check pointer. Nó thêm cái này vào biểu đồ, và nó truyền cái này xuyên suốt hệ thống. Và S3 check pointer ở đây, tôi chắc rằng nó có một số kiến thức về cách ghi các checkpoint vào và từ S3. Vì vậy, chúng tôi không chỉ định nghĩa hệ thống mà còn sản xuất và cung cấp nó, bao gồm cả property tests, tôi tin là vậy.

Tùy chọn CLI và Tool của Cure

Tôi có một câu trả lời cho một slide trước đó liên quan đến một số tính năng cụ thể liên quan đến AWS giúp làm việc dễ dàng hơn. Cure CLI có đi kèm với việc sử dụng các tool AWS không? Vâng, vâng, ý của Rob bây giờ là Cure CLI, mà chúng tôi vừa đổi tên trong tuần này, có một tool useAWS, về cơ bản là một wrapper (trình bao bọc) qua AWS SDK để thực hiện một số việc đó dễ dàng hơn. Nhưng một lần nữa, BYO (Bring Your Own) use GCP tool là một FCP server nếu bạn đang bán client nếu đó là tool bạn chọn, và tôi tin rằng... đừng trích lời tôi về điều này. CLI khá mới đối với tôi, tôi nên nói vậy, nhưng tôi tin rằng bạn cũng có thể tắt các tool trong CLI. Hãy cho tôi biết nếu điều đó không đúng. Vâng, đó là như action out strict của bạn trong sản phẩm máy tính để bàn ngày nay, bạn không thể kiểm soát các tool, các native tool được tích hợp sẵn, nhưng trong CLI thì có thể.

Đánh giá Hiệu suất Dự án với và không có Spec

Vì vậy, tôi hiểu một cách trực quan lợi ích của việc có một spec. Bạn đã thực hiện bất kỳ công việc nào để xem xét một cách nội tại cách một dự án hoặc vấn đề hoạt động có hoặc không có spec chưa? Vâng, chúng tôi có các benchmark bao gồm dữ liệu hiện tại. Tôi nghĩ một phần trong số đó có trong các blog của chúng tôi, vì vậy nếu bạn truy cập cure.dev/blog, trên trang web, chúng tôi nói rất rõ ràng về một số điều như property-based testing góp phần vào task accuracy.

Nhóm khoa học của chúng tôi luôn làm việc về những thứ đó. Tôi nhớ bài blog về spec và nó đến từ cơ sở dữ liệu. Vâng, Kỹ sư xuất sắc về cơ sở dữ liệu. Nó thực sự là một thứ gì đó mà tôi nghĩ nó có dữ liệu mà bạn... Vâng.

Các Yêu cầu Phi Chức năng và Tối ưu hóa Token

Nó hoạt động như thế nào? Tôi hiểu về mặt tính năng, nhưng nó hoạt động như thế nào trong một kịch bản phi chức năng, hơi khó khăn hơn? Các vấn đề càng khó càng dài? Chà, vâng, đó là mục tiêu cuối cùng ở đây, đúng không? Chúng tôi đang nói rằng bạn đang thực hiện một khoản đầu tư ban đầu lớn hơn một chút, nhưng chúng tôi tin rằng cấu trúc mà chúng tôi đang mang lại sẽ giúp bạn tăng độ chính xác của kết quả. Vì vậy, trong khi chúng tôi có một nhóm người về cơ bản đang làm việc để cải thiện spec, công việc của tôi khi tôi bay về Seattle là làm cho Cure nói chung nhanh hơn nhiều.

Một là thực thi, giống như việc làm chậm UI này. Nhưng hai là làm thế nào để chúng ta đưa mã thông báo qua hệ thống nhanh hơn? Làm thế nào để chúng ta nhận được phản hồi cho bạn nhanh hơn để bạn không phải chi quá nhiều tiền vào Cure để sử dụng một spec? Vâng, tôi không nói về bản thân tool Cure. OK. Mã được tạo từ spec. Ồ, ồ, vâng. OK. Vâng, ý bạn là các yêu cầu phi chức năng của mã được tạo.

Điều đó sẽ phụ thuộc vào những gì bạn đang cố gắng thực hiện cụ thể. Vì vậy, bạn có thể thêm... một trong những slide tôi có ở đây đã nói một chút về cách điều chỉnh quy trình và điều chỉnh các artifact cho các use case của bạn. Một lần nữa, bạn có thể rất dễ dàng thêm một cái gì đó như "Tôi muốn các yêu cầu phi chức năng về tốc độ và thời gian chạy, và những thứ như lock contention được xem xét trong giai đoạn thiết kế." Vâng, đó là điều bạn chắc chắn có thể thêm vào. Vì vậy, bạn có thể chỉ định bằng Rust hoặc Java. Vâng, hoàn toàn. Vâng.

Tôi nghĩ nó có thể nằm trong phần chức năng tùy thuộc vào kế hoạch. Ý tôi là, nó sẽ phải... vâng, tôi nghĩ không có cách nào khác để tiếp cận nó. Một lần nữa, tôi chỉ quen với... không, nó... nên tôi đang làm mọi thứ ở đây bằng Node, nhưng bạn có thể sử dụng cái này với bất kỳ ngôn ngữ nào. Tôi nghĩ về mặt kỹ thuật, chúng tôi nói rằng chúng tôi hỗ trợ Java, Python, JavaScript, TypeScript, Java và Rust, nhưng trên thực tế, không có lý do gì mà cái này không hoạt động với bất kỳ ngôn ngữ nào. Ý tôi là, nó chỉ là một LLM. Không có gì cụ thể về ngôn ngữ hay framework cụ thể trong hệ thống. Và đối với những bạn...

Steering và Tùy chỉnh Hành vi của Tác nhân AI

Có một hội nghị vào đầu tuần này do Tessel tổ chức, nơi họ đang thực hiện các spec cho knowledge base. Miễn là bạn có các grounding doc phù hợp ở đó, thì đây là một loại... Lập luận của họ là không quan trọng bạn đang xây dựng gì. Tất cả những điều đó chỉ được thông báo bởi context bạn đang xây dựng cho hệ thống của mình.

Đây cũng là một điểm rất tốt cho steering. Với steering, bạn có thể khiến tác nhân phát triển mã theo cách bạn muốn. Trở thành một nhà phát triển là về việc đánh đổi, và vấn đề với sản phẩm của chúng tôi khi mới ra lò là nó quá lịch sự. Nó cố gắng trở thành mọi thứ cho mọi người. Và đặc biệt là với latency và chi phí cũng như những thứ khác tương tự. Chỉ cần nói với nó trong steering những gì bạn muốn nó ưu tiên. Và sau đó điều đó sẽ ảnh hưởng đến bất kỳ mã nào được tạo ra. Vâng. Bạn cũng có thể dựa vào khoa học dựa trên điều đó. Vì vậy, nếu có điều gì đó rất cụ thể cho use case của bạn, ngành công nghiệp hoặc bất cứ điều gì, chỉ cần đặt jobs vào steering file. Và đó là...

Vâng, chính xác là vậy. Ví dụ, tôi sẽ để Cure tạo commit cho tôi. Và một trong những điều tôi cá nhân quan tâm là tôi phân biệt các commit tôi tạo với các commit mà Cure tạo, đó là những commit đến từ hệ thống. Và vì vậy, steering doc của tôi, mặc dù ngắn gọn, bao gồm những thứ như: cụ thể, yêu cầu của tôi đối với Cure là "chỉ sử dụng UI." Điều đó tôi biết tôi đã coi tác nhân Cure là co-author, điều này là nhỏ nhặt, nhưng tôi cũng muốn nó xảy ra mọi lúc. Vì vậy, trong trường hợp này, tôi vừa tạo một commit có co-author là tác nhân Cure. Vì vậy, đó là một ví dụ về việc bạn có thể thêm bất cứ điều gì bạn muốn vào đó. Không chỉ những thứ thực sự liên quan đến commit, mà bạn có thể làm về code style. Bạn có thể làm...

Tổng kết dự án và Triển khai

Bạn biết đấy, code style, code coverage. Bất cứ khi nào bạn thêm một đặc tả (spec) hoặc thêm một mô-đun mới, hãy đảm bảo rằng bạn... Tôi đã đặt yêu cầu code coverage tối thiểu là 90% vì đó là điều tôi quan tâm. Bạn phải đưa bất cứ điều gì bạn muốn vào đó. Tin tốt là có vẻ như những gì chúng ta đã xây dựng hoạt động. Cure có vẻ rất hài lòng với bản thân, ít nhất là vậy, và có vẻ như tất cả các bài kiểm thử đều đã vượt qua. Tuy nhiên, chúng ta có thể triển khai điều này lên backend và xem mọi thứ hoạt động như thế nào. Về mặt kỹ thuật, chúng ta gần hết thời gian rồi. Vì vậy, nếu có bất kỳ ai có câu hỏi nào khác, tôi sẽ ở lại đây một lúc. Nhưng cảm ơn tất cả các bạn đã tham gia, lắng nghe và tìm hiểu thêm một chút về Spectre và Dev.