Mục lục
Giới Thiệu AutoBE: Tương Lai Của Vibe Coding
Trong kỷ nguyên số hóa, tốc độ và độ tin cậy là tối quan trọng trong phát triển phần mềm. Chúng tôi tự hào giới thiệu **AutoBE**, một dự án mã nguồn mở đột phá được phát triển bởi Wrtn Technologies, một công ty khởi nghiệp AI hàng đầu từ Hàn Quốc. AutoBE đại diện cho một bước tiến mới trong “vibe coding” – một agent AI có khả năng tự động hóa việc tạo ứng dụng backend, mang đến trải nghiệm phát triển mượt mà và hiệu quả. Điểm nổi bật nhất của AutoBE là cam kết tạo ra mã nguồn với **100% tỷ lệ biên dịch thành công**, một lời hứa hiếm có trong thế giới phát triển phần mềm tự động.
Bạn có thể khám phá mã nguồn và các ví dụ tại đây:
- Kho lưu trữ Github của AutoBE: https://github.com/wrtnlabs/autobe
- Ví dụ ứng dụng backend được tạo: https://github.com/wrtnlabs/autobe-example-bbs
Bí mật đằng sau thành công này nằm ở hệ thống trình biên dịch độc quyền của chúng tôi. Các trình biên dịch tự phát triển này không chỉ hỗ trợ AI tạo ra mã an toàn về kiểu (type-safe) mà còn phát hiện lỗi và cung cấp phản hồi chi tiết, hướng dẫn AI chỉnh sửa để tạo ra mã chính xác. Bằng cách này, AutoBE luôn đảm bảo mỗi ứng dụng backend được tạo ra đều hoạt động hoàn hảo ngay từ lần biên dịch đầu tiên. Khi AI xây dựng dữ liệu AST (Abstract Syntax Tree) thông qua cơ chế Function Calling, trình biên dịch của chúng tôi sẽ xác thực, đưa ra phản hồi và cuối cùng tạo ra mã nguồn hoàn chỉnh.
Hiểu Rõ AI Function Calling
AI Function Calling là một công nghệ tiên tiến cho phép AI tạo ra dữ liệu có cấu trúc theo các schema hàm được định nghĩa trước. Thay vì chỉ tạo văn bản thông thường, nó tạo ra dữ liệu JSON tuân thủ các kiểu và định dạng cụ thể, có thể sử dụng trực tiếp trong các chương trình. Đây là xương sống giúp AutoBE giao tiếp hiệu quả với các trình biên dịch của mình.
Bí Quyết Thành Công: Hệ Thống Trình Biên Dịch Tầng Thác (Waterfall Compiler System)
AutoBE tạo ra các ứng dụng backend thông qua một hệ thống trình biên dịch tinh vi dựa trên mô hình Waterfall. Toàn bộ quy trình gồm năm giai đoạn tuần tự, mỗi giai đoạn được xử lý bởi một agent chuyên biệt.
--------------------------
| Facade Controller |
--------------------------
|
V
--------------------------
| Analyze Agent | (Phân tích yêu cầu)
--------------------------
|
V
--------------------------
| Prisma Agent | (Thiết kế DB Schema)
--------------------------
|
V
--------------------------
| Interface Agent | (Định nghĩa API Interfaces)
--------------------------
|
V
--------------------------
| Test Agent | (Tạo mã kiểm thử E2E)
--------------------------
|
V
--------------------------
| Realize Agent | (Triển khai API thực tế)
--------------------------
Facade Controller đóng vai trò điều phối toàn bộ quá trình, trong khi các agent chức năng thực hiện nhiệm vụ theo trình tự.
- Analyze Agent: Phân tích yêu cầu người dùng để tạo đặc tả chức năng chi tiết.
- Prisma Agent: Thiết kế schema cơ sở dữ liệu dựa trên đặc tả.
- Interface Agent: Định nghĩa các giao diện API.
- Test Agent: Tạo mã kiểm thử E2E (End-to-End).
- Realize Agent: Viết mã triển khai API thực tế.
Mỗi đầu ra của agent đều được xác thực thông qua các trình biên dịch chuyên dụng tương ứng. Đầu ra của Prisma agent được kiểm tra bởi trình biên dịch Prisma tự phát triển của chúng tôi, đầu ra của Interface agent bởi trình xác thực OpenAPI, và mã TypeScript từ Test và Realize agents bởi trình biên dịch TypeScript. Hệ thống xác thực từng giai đoạn này là cơ chế cốt lõi đảm bảo tỷ lệ biên dịch thành công 100%.
Các Trình Biên Dịch Độc Quyền Của AutoBE
Trình Biên Dịch Schema Cơ Sở Dữ Liệu Prisma
AutoBE sử dụng trình biên dịch DB tự phát triển để thiết kế cơ sở dữ liệu.
Quy trình bắt đầu bằng việc tạo cấu trúc AST (`AutoBePrisma.IFile`) thông qua AI function calling. Sau đó, nó phân tích dữ liệu do AI tạo ra để kiểm tra lỗi logic hoặc lỗi kiểu.
Nếu phát hiện lỗi logic, chúng sẽ được trả về AI dưới dạng `IAutoBePrismaValidation` kèm theo lý do chi tiết, hướng dẫn AI tạo dữ liệu `AutoBePrisma.IFile` chính xác trong lần gọi hàm tiếp theo. Các trường hợp lỗi logic phổ biến bao gồm:
- Lỗi trùng lặp: Định nghĩa trùng tên tệp, tên model, tên trường.
- Tham chiếu vòng: Hai model tham chiếu lẫn nhau làm khóa ngoại.
- Tham chiếu không tồn tại: Khóa ngoại trỏ đến model không có thật.
- Lỗi cấu hình index: Tạo index trên trường không tồn tại, định nghĩa index trùng lặp.
- Không khớp kiểu dữ liệu: Áp dụng index GIN cho các trường không phải chuỗi.
- Tên trường trùng tên bảng: Gây nhầm lẫn do lỗi chuẩn hóa.
Nếu phát hiện lỗi kiểu, chúng cũng được trả về AI dưới dạng `IValidation`, hướng dẫn AI tạo dữ liệu với kiểu chính xác.
Khi `AutoBePrisma.IFile` được tạo chính xác mà không có bất kỳ lỗi logic hay kiểu nào, nó sẽ được chuyển đổi thành Prisma DB schema (tạo mã). Đồng thời, ERD (Entity Relationship Diagram) và tài liệu cũng được tạo ra (prisma-markdown), giúp người dùng dễ dàng hiểu thiết kế DB của họ. Các tệp schema Prisma được tạo bao gồm các comment mô tả chi tiết cho từng bảng và trường. Những comment này không chỉ là tài liệu mã đơn thuần mà còn được prisma-markdown sử dụng trực tiếp khi tạo ERD và tài liệu, trở thành nội dung cốt lõi của các tài liệu thiết kế cơ sở dữ liệu.
// Ví dụ về Prisma Schema được tạo
model User {
id String @id @default(uuid())
email String @unique
name String?
posts Post[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
/// Represents a user in the application.
/// Used for authentication and authoring posts.
}
model Post {
id String @id @default(uuid())
title String
content String?
published Boolean @default(false)
author User @relation(fields: [authorId], references: [id])
authorId String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
/// Represents a blog post written by a user.
/// Includes title, content, and publication status.
}
Trình Biên Dịch Tài Liệu OpenAPI (Thiết Kế API)
AutoBE sử dụng trình biên dịch OpenAPI tự phát triển để thiết kế các giao diện API.
Trình biên dịch này có cấu trúc AST kiểu `AutoBeOpenApi.IDocument`, được tạo thông qua AI function calling. Sau đó, nó phân tích dữ liệu này, và nếu phát hiện lỗi logic hoặc lỗi kiểu, lý do chi tiết sẽ được trả về AI, hướng dẫn AI tạo dữ liệu `AutoBeOpenApi.IDocument` chính xác.
Sau khi AI thành công tạo ra một `AutoBeOpenApi.IDocument` hoàn hảo, AutoBE sẽ chuyển đổi nó thành cấu trúc OpenApi.IDocument chuẩn OpenAPI v3.1. Tiếp theo, cấu trúc này được chuyển đổi thành mã nguồn TypeScript/NestJS (tạo mã), hoàn thành việc triển khai giao diện API.
Mã nguồn TypeScript/NestJS được tạo bao gồm các lớp controller API và kiểu DTO (Data Transfer Object), trong đó mỗi phương thức controller API là một phương thức giả lập (mock method) chỉ tạo ra các giá trị ngẫu nhiên của kiểu trả về được chỉ định bằng cách sử dụng hàm typia.random<T>(). Do đó, các API do AutoBE tạo ra không thực sự có chức năng, nhưng chúng hoàn thành công việc nền tảng cho thiết kế và triển khai giao diện API. Tất cả các hàm controller và kiểu DTO được tạo đều bao gồm các comment JSDoc chi tiết. Mục đích của từng endpoint API, mô tả tham số và ý nghĩa giá trị trả về đều được tài liệu hóa rõ ràng.
// Ví dụ về NestJS Controller được tạo
/**
* Controller for managing user accounts.
* Provides endpoints for creating, retrieving, and updating users.
*/
@Controller("users")
export class UsersController {
/**
* Get a list of all users.
* @param limit The maximum number of users to return.
* @param offset The number of users to skip.
* @returns An array of user objects.
*/
@Get()
public async findAll(
@Query("limit") limit?: number,
@Query("offset") offset?: number,
): Promise<Array<IUser>> {
return typia.random<Array<IUser>>();
}
/**
* Create a new user.
* @param body The user data to create.
* @returns The newly created user object.
*/
@Post()
public async create(
@Body() body: ICreateUserDto,
): Promise<IUser> {
return typia.random<IUser>();
}
}
Trình Biên Dịch Chức Năng Kiểm Thử E2E
AutoBE sử dụng trình biên dịch tự phát triển khi tạo mã kiểm thử E2E.
Trình biên dịch kiểm thử E2E này có cấu trúc AST gọi là `AutoBeTest.IFunction`, được xây dựng thông qua AI function calling. Dữ liệu này sau đó được phân tích, và nếu phát hiện lỗi logic hoặc lỗi kiểu, lý do chi tiết sẽ được trả về AI, hướng dẫn AI tạo dữ liệu `AutoBeTest.IFunction` chính xác.
Sau khi AI thành công tạo ra dữ liệu `AutoBeTest.IFunction` hoàn hảo, AutoBE sẽ chuyển đổi nó thành mã nguồn TypeScript (tạo mã). Test agent sau đó kết hợp từng chức năng kiểm thử e2e được tạo với mã do Interface agent tạo ra để hoàn thành một ứng dụng backend mới.
Khi các chức năng kiểm thử E2E gọi các hàm API của máy chủ backend, chúng sử dụng một SDK (Software Development Kit) được tạo cho API máy chủ backend để đảm bảo các cuộc gọi hàm API an toàn về kiểu. Mỗi chức năng kiểm thử E2E được tạo đều bao gồm các comment chi tiết mô tả kịch bản và mục đích của kiểm thử. Các API nào được gọi theo thứ tự nào, điều gì được xác minh ở mỗi bước và kết quả mong đợi đều được tài liệu hóa rõ ràng.
// Ví dụ về mã kiểm thử E2E
describe("UserController", () => {
let app: INestApplication;
let agent: typia.IHttpClient;
beforeAll(async () => {
app = await NestFactory.create(AppModule);
await app.listen(3000);
agent = typia.createHttpClient("http://localhost:3000");
});
afterAll(async () => {
await app.close();
});
describe("/users (GET)", () => {
// Scenario: Retrieve a list of users with pagination
// Steps:
// 1. Call GET /users with limit=10 and offset=0.
// 2. Verify that the response is an array of 10 users.
// 3. Verify that each user object has required properties (id, email, name).
it("should return a list of users", async () => {
const response = await agent.users.findAll({ query: { limit: 10, offset: 0 } });
expect(response).toBeInstanceOf(Array);
expect(response.length).toBe(10);
for (const user of response) {
expect(user).toHaveProperty("id");
expect(user).toHaveProperty("email");
expect(user).toHaveProperty("name");
}
});
});
});
Lưu ý rằng khi ngăn xếp ứng dụng backend do AutoBE tạo ra là TypeScript/NestJS, AutoBE không xây dựng dữ liệu `AutoBeTest.IFunction` thông qua AI structured output. Thay vào đó, nó sử dụng AI structured output, nơi AI đưa ra kịch bản cho các endpoint API đã cho, viết mã kiểm thử nháp, sau đó xem xét và sửa đổi để viết mã cuối cùng. Mã do AI viết sau đó được xác minh thông qua API trình biên dịch TypeScript, và nếu biên dịch thất bại, lý do chi tiết sẽ được trả về AI, hướng dẫn nó tạo mã chính xác. Tuy nhiên, phương pháp này chỉ khả thi với ngăn xếp TypeScript/NestJS. Đối với các ngôn ngữ và ngăn xếp khác, dữ liệu `AutoBeTest.IFunction` vẫn được xây dựng và biên dịch thông qua AI function calling.
typia.llm.parameters<{
scenario: string; // kịch bản kiểm thử
draft: string; // mã nháp do AI viết
review: string; // tự đánh giá về mã nháp
final: string; // mã cuối cùng sau khi đánh giá
}, "chatgpt">();
Tối Ưu Hóa Trình Biên Dịch: TypeScript và AI Function Calling
Tích Hợp Trình Biên Dịch TypeScript
AutoBE tích hợp trình biên dịch TypeScript để thực hiện xác thực cuối cùng mã nguồn TypeScript do AI hoặc các trình biên dịch tích hợp của AutoBE tạo ra. Điều này đảm bảo rằng sản phẩm cuối cùng luôn đạt chất lượng cao nhất và hoàn toàn tuân thủ các quy tắc kiểu dữ liệu.
Thách Thức và Giải Pháp AI Function Calling Với typia
Bí quyết giúp AutoBE tạo ứng dụng backend với 100% biên dịch thành công nằm ở các trình biên dịch tự phát triển và việc tạo tất cả cấu trúc AST của chúng thông qua AI function calling. Tuy nhiên, giống như tất cả các cấu trúc AST của trình biên dịch trên thế giới, chúng thực sự là cấu trúc cây với các mối quan hệ tham chiếu đệ quy, và hệ thống phân cấp cũng như độ phức tạp của chúng là vô cùng cao.
Trong khi các JSON schema được sử dụng cho AI function calling hoặc structured output thường được viết thủ công bởi con người, các cấu trúc AST cho trình biên dịch của AutoBE lại quá lớn, phức tạp và rắc rối để con người có thể tự viết JSON schema của chúng. Hơn nữa, các đặc tả JSON schema được sử dụng cho AI function calling còn khác nhau giữa các nhà cung cấp AI. OpenAI và Gemini thậm chí còn tạo ra các đặc tả riêng của họ thay vì sử dụng định nghĩa JSON schema tiêu chuẩn, trong khi Claude, tuân theo định nghĩa JSON schema tiêu chuẩn, lại định nghĩa kiểu bằng cách sử dụng đặc tả JSON schema v7 lỗi thời trong hướng dẫn MCP của riêng họ. Các đặc tả JSON schema cho AI function calling thực sự hỗn loạn.
Do đó, mặc dù thường được khuyến nghị tránh các kiểu phức tạp và định nghĩa chúng đơn giản khi tạo AI agent bằng AI function calling hoặc structured output, AutoBE không thể làm như vậy vì nó phải thể hiện các cấu trúc AST của trình biên dịch. (Lưu ý: Gemini không hỗ trợ kiểu union, khiến nó không thể sử dụng trong AutoBE.)
Để giải quyết vấn đề này, các nhà phát triển nhóm AutoBE đã tạo ra typia, một thư viện plugin trình biên dịch TypeScript tự động tạo AI function calling và structured output schemas từ mã nguồn TypeScript, và đã tích hợp nó vào AutoBE. Khi bạn chỉ định kiểu đích và mô hình AI như dưới đây, typia sẽ tự động tạo AI function calling và structured output schemas. Ngoài ra, khi gọi typia.llm.application<Class, Model>(), nó cũng tạo các hàm validator để phản hồi xác thực kiểu cho tất cả các phương thức trong kiểu lớp đó.
typia.llm.parameters<AutoBeOpenApi.IDocument, "chatgpt">(); typia.llm.parameters<AutoBeOpenApi.IDocument, "claude">(); typia.llm.parameters<AutoBeOpenApi.IDocument, "llama">();
AutoBE đã triển khai một agent vibe coding với 100% biên dịch thành công bằng cách tích cực sử dụng công nghệ trình biên dịch cả bên trong và bên ngoài.
Nền Tảng Công Nghệ Backend Của AutoBE
TypeScript, NestJS và Prisma: Bộ Ba Hoàn Hảo
AutoBE hiện hỗ trợ sự kết hợp ngăn xếp backend **TypeScript/NestJS/Prisma**.
Lý do chính để chọn **TypeScript** là vì trình biên dịch và API của nó hoàn toàn mã nguồn mở và có thể mở rộng thông qua hệ thống plugin. Để triển khai kiến trúc dựa trên trình biên dịch cốt lõi của AutoBE, chúng tôi cần tận dụng sâu trình biên dịch của chính ngôn ngữ, và TypeScript đã đáp ứng hoàn hảo những yêu cầu này. Ngoài ra, hệ thống kiểu mạnh mẽ của nó cho phép chúng tôi đảm bảo an toàn kiểu của mã do AI tạo ra, điều cần thiết để đạt được mục tiêu 100% biên dịch thành công.
**NestJS** hiện thực hóa chức năng cốt lõi của AutoBE thông qua sự kết hợp với Nestia. Nestia là một công cụ phân tích mã nguồn NestJS để tự động tạo thư viện SDK client, cho phép các chương trình kiểm thử E2E do AutoBE tạo ra thực hiện các cuộc gọi API hoàn toàn an toàn về kiểu. Các vấn đề phổ biến trong kiểm thử REST API điển hình như lỗi chính tả URL, không khớp kiểu tham số và thay đổi cấu trúc phản hồi đều được phát hiện tại thời điểm biên dịch, cải thiện đáng kể độ tin cậy của mã kiểm thử.
**Prisma** xử lý việc quản lý schema cơ sở dữ liệu và tạo truy vấn an toàn về kiểu. Ngôn ngữ định nghĩa schema của Prisma có cấu trúc, phù hợp để trình biên dịch của AutoBE phân tích cú pháp và xác thực. Client TypeScript được tạo đảm bảo an toàn kiểu hoàn toàn trong các hoạt động cơ sở dữ liệu. Ngoài ra, hệ thống migration của nó cho phép quản lý có hệ thống các thay đổi schema cơ sở dữ liệu, giúp duy trì tính nhất quán giữa môi trường phát triển và sản xuất.
Sự kết hợp của ba công nghệ này là lựa chọn tối ưu để đạt được các mục tiêu của AutoBE về “tạo mã dựa trên trình biên dịch” và “100% biên dịch thành công.”
Khả Năng Mở Rộng Sang Ngôn Ngữ và Framework Khác
Kiến trúc của AutoBE được thiết kế để không phụ thuộc vào ngôn ngữ và framework. Nguyên tắc cốt lõi là AI tạo ra cấu trúc AST thông qua function calling, sau đó được chuyển đổi thành mã nguồn bằng ngôn ngữ tương ứng.
Hiện tại, chúng tôi chỉ hỗ trợ sự kết hợp TypeScript/NestJS/Prisma, nhưng về lý thuyết, việc mở rộng sang các ngôn ngữ và framework khác là hoàn toàn có thể. Ví dụ, để mở rộng sang các kết hợp như Java/Spring Boot, Python/FastAPI hoặc Go/Gin, chúng tôi cần định nghĩa các cấu trúc AST phù hợp cho từng ngôn ngữ và phát triển các trình biên dịch hoặc hệ thống xác thực tương ứng. Tuy nhiên, việc mở rộng cụ thể cho từng ngôn ngữ đòi hỏi đầu tư phát triển đáng kể. Hiện tại, chúng tôi tập trung vào việc cải thiện tính hoàn chỉnh trong ngăn xếp TypeScript, và sẽ xem xét hỗ trợ các ngôn ngữ khác dựa trên nhu cầu người dùng và hướng phát triển dự án trong tương lai.
Tình Trạng Phát Triển và Lộ Trình Của AutoBE
AutoBE hiện đang ở giai đoạn phát triển phiên bản alpha, với chưa tất cả các tính năng được hoàn thiện.
Đầu tiên, trong năm giai đoạn tạo nên mô hình Waterfall, agent Realize vẫn chưa hoàn thành. Do đó, mặc dù có thể tạo báo cáo phân tích yêu cầu, thiết kế DB và API, và viết mã kiểm thử E2E cho chúng thông qua AutoBE, nhưng chưa thể thực sự triển khai các chức năng API để hoàn thành ứng dụng. Agent Realize này hiện đang được phát triển và dự kiến sẽ được phát hành cùng với bản beta vào ngày 31 tháng 8 năm 2025.
Thứ hai, các prompt của AutoBE vẫn chưa được tối ưu hóa. Do đó, mặc dù mã do AutoBE tạo ra có thể biên dịch thành công và hoạt động tốt, nhưng có thể chưa thực sự là chức năng người dùng mong muốn.
Cuối cùng, AutoBE vẫn chưa bắt đầu tối ưu hóa RAG (Retrieval Augmented Generation). Do đó, lượng tiêu thụ token API có thể cao hơn dự kiến. Dựa trên mô hình GPT-4.1, việc tạo một ứng dụng backend với 200 API tiêu thụ khoảng 30 USD. Chi phí này sẽ dần được giảm thông qua tối ưu hóa RAG trong tương lai.
Kết Luận: Tầm Nhìn Mới Cho Phát Triển Phần Mềm
AutoBE đã đi theo một cách tiếp cận khác biệt so với các công cụ mã hóa AI hiện có. Thay vì dựa vào tạo mã dựa trên văn bản, chúng tôi đã triển khai tạo mã an toàn về cấu trúc bằng cách kết hợp công nghệ trình biên dịch với AI.
Thông qua cách tiếp cận này, nơi AI trực tiếp tạo AST, các trình biên dịch xác thực chúng và mã hoàn hảo được tạo ra thông qua phản hồi, chúng tôi đã đạt được 100% biên dịch thành công. Đây là một nỗ lực để cải thiện cơ bản chất lượng và sự ổn định của phát triển phần mềm, vượt ra ngoài việc chỉ tăng cường tiện lợi.
Hiện tại, AutoBE đang ở trạng thái phiên bản alpha, cần phát triển thêm cho đến khi phát hành bản beta. Tuy nhiên, chúng tôi tin rằng cách tiếp cận dựa trên trình biên dịch này có thể mang đến những khả năng mới cho các nhà phát triển. Chúng tôi cảm ơn những người đã quan tâm đến dự án AutoBE và mong bạn tiếp tục theo dõi tiến trình phát triển của chúng tôi.
Khám phá dự án tại: https://github.com/wrtnlabs/autobe
Phụ Lục: AutoBE So Sánh Với AWS Kiro
AWS Kiro đại diện cho một cột mốc quan trọng trong các công cụ phát triển được hỗ trợ bởi AI, đặc biệt thông qua việc triển khai plugin IDE. Sau khi quan sát cách tiếp cận của Kiro như một tiện ích mở rộng môi trường phát triển tích hợp, chúng tôi nhận ra giá trị to lớn mà mô hình này mang lại cho quy trình làm việc của nhà phát triển.
Chiến lược plugin IDE của Kiro cho thấy cách các trợ lý mã hóa AI có thể tích hợp liền mạch vào các môi trường phát triển hiện có, cung cấp hỗ trợ theo thời gian thực mà không làm gián đoạn quy trình làm việc đã thiết lập. Mô hình tích hợp này cho phép các nhà phát triển tận dụng khả năng của AI trực tiếp trong môi trường mã hóa quen thuộc của họ, làm cho công nghệ trở nên dễ tiếp cận và thực tế hơn cho việc sử dụng hàng ngày.
Lấy cảm hứng từ cách tiếp cận plugin IDE của Kiro, chúng tôi đang lên kế hoạch phát triển và phát hành một plugin IDE cho AutoBE cùng với bản phát hành v1 của chúng tôi (dự kiến vào cuối năm 2025). Plugin này sẽ tích hợp hệ thống trình biên dịch tầng thác của AutoBE trực tiếp vào IDE phổ biến như
VSCode
, cho phép các nhà phát triển:
- Tạo ứng dụng backend thông qua giao diện IDE quen thuộc.
- Nhận phản hồi và xác thực trình biên dịch theo thời gian thực.
- Trải nghiệm chu trình phát triển hoàn chỉnh từ phân tích yêu cầu đến triển khai.
- Tận dụng đảm bảo 100% biên dịch thành công của AutoBE trong môi trường phát triển hiện có của họ.
Tuy nhiên, chúng tôi phải thừa nhận rằng so với sự trưởng thành phát triển và sự hiện diện trên thị trường hiện tại của AWS Kiro, tiến trình của AutoBE vẫn còn ở giai đoạn đầu. Mặc dù chúng tôi đã đạt được các cột mốc kỹ thuật quan trọng với cách tiếp cận dựa trên trình biên dịch và tỷ lệ biên dịch thành công 100%, Kiro đã tự khẳng định mình là một giải pháp toàn diện với khả năng tích hợp IDE rộng rãi và được thị trường chấp nhận.
Trạng thái alpha hiện tại của chúng tôi, với agent Realize vẫn đang được phát triển và tối ưu hóa prompt đang chờ xử lý, làm nổi bật khoảng cách giữa khả năng hiện tại của chúng tôi và trải nghiệm hoàn thiện mà Kiro cung cấp. Thay vì xem đây là một hạn chế, chúng tôi coi đó là cơ hội để học hỏi sâu rộng từ những điểm mạnh và cách tiếp cận đã được chứng minh của Kiro.
Chúng tôi cam kết nghiên cứu các chiến lược thành công của Kiro, đặc biệt là thiết kế trải nghiệm người dùng, các mẫu tích hợp IDE và tối ưu hóa quy trình làm việc của nhà phát triển. Bằng cách tiếp thu những điểm mạnh của họ trong khi tận dụng kiến trúc dựa trên trình biên dịch độc đáo và đảm bảo biên dịch thành công, chúng tôi hướng tới việc tạo ra một dự án mã nguồn mở đặc biệt, kết hợp những điều tốt nhất của cả hai cách tiếp cận. Phát triển plugin IDE sẽ là một bước quan trọng để AutoBE dễ tiếp cận hơn với các nhà phát triển, và chúng tôi dự định kết hợp các bài học kinh nghiệm từ việc triển khai của Kiro để đảm bảo chúng tôi mang đến một giải pháp hoàn thiện, thực tế phục vụ cộng đồng nhà phát triển thông qua sáng kiến mã nguồn mở của chúng tôi.
