Outline
@autobe
is based on the waterfall model but incorporates the spiral modelโs iterative improvement cycles, producing high-quality code through continuous feedback between users and AI.
The spiral process ensures not only well-structured code but also safe and reliable implementations verified by integrated TypeScript/Prisma compilers, OpenAPI validator, and automated test programs at each development stage.
Waterfall | AutoBE | Description |
---|---|---|
Requirements | Analze | Debate requirements with user. |
Analysis | Analze | Write requirement analysis reports. |
Design | Prisma | Write prisma schema (DB ORM) files and draw ERD. |
Design | Interface | Write OpenAPI document, convert it to a NestJS project. |
Development | Realize | Write implementation code for each API endpoint. |
Testing | Test | Write e2e test functions for each API endpoint. |
Maintenance | * | Users can request AutoBE to modify the backend application. |
Analyze Agent
An agent that analyzes requirements and creates specification documents.
- Input: All conversation history between users and AI
- Output: Structured requirements specification
- Features:
- Separates business logic from technical requirements
- Generates follow-up questions for ambiguous requirements
- Establishes priorities and defines development scope
The Analyze agent serves as the foundation of the entire development process. It not only captures initial requirements but also continuously refines understanding through iterative conversation with users. When requirements are ambiguous or incomplete, it proactively formulates targeted questions to elicit necessary information before proceeding with development.
Additionally, once other agents have generated code, the Analyze agent can interpret change requests in the context of existing implementations, assessing the impact and feasibility of modifications while maintaining system integrity. This comprehensive approach ensures that all subsequent development stages work from a clear, complete, and consistent specification.
Prisma Agent
An agent that generates database schemas through AutoBEโs specialized AST-based approach.
- Input: Requirements specification
- Output: Prisma DB schema and ERD documentation
- Features:
- No-code approach using
AutoBePrisma.IApplication
AST structure - Built-in AutoBE Prisma compiler for validation and code generation
- Automatic ERD documentation generation (using
prisma-markdown
) - Schema optimization through self-review system
- No-code approach using
The Prisma agent implements AutoBEโs no-code methodology by working with structured data rather than text files. Instead of writing Prisma schema code directly, the AI constructs AutoBePrisma.IApplication
AST (Abstract Syntax Tree) data through function calling. This approach eliminates syntax errors and ensures consistency by operating at a higher abstraction level.
The workflow begins with analyzing the requirements specification to understand the data model needs. The AI then uses function calling to build the AutoBePrisma.IApplication
AST, which represents the complete database structure including entities, relationships, attributes, and constraints in a validated format.
AutoBEโs built-in Prisma compiler validates this AST for correctness, consistency, and adherence to database design best practices. When validation errors occur, theyโre immediately fed back to the AI, enabling rapid iteration and refinement. This creates a feedback loop that continuously improves the schema design without manual debugging.
Once validation passes, the compiler automatically generates the actual Prisma schema files from the AST. The generated schemas include comprehensive documentation for each entity and attribute, explaining their business purpose and relationships. Finally, ERD documentation is produced using prisma-markdown
, and the entire output undergoes quality review to ensure it meets project standards.
/// Final component information on units for sale.
///
/// `shopping_sale_snapshot_unit_stocks` is a subsidiary entity of
/// {@link shopping_sale_snapshot_units} that represents a product catalog
/// for sale, and is a kind of final stock that is constructed by selecting
/// all {@link shopping_sale_snapshot_unit_options options}
/// (variable "select" type) and their
/// {@link shopping_sale_snapshot_unit_option_candidates candidate} values in
/// the belonging unit. It is the "good" itself that customers actually
/// purchase.
///
/// - Product Name) MacBook
/// - Options
/// - CPU: { i3, i5, i7, i9 }
/// - RAM: { 8GB, 16GB, 32GB, 64GB, 96GB }
/// - SSD: { 256GB, 512GB, 1TB }
/// - Number of final stocks: 4 * 5 * 3 = 60
///
/// For reference, the total number of `shopping_sale_snapshot_unit_stocks`
/// records in an attribution unit can be obtained using Cartesian Product.
/// In other words, the value obtained by multiplying all the candidate
/// values that each (variable "select" type) option can have by the number
/// of cases is the total number of final stocks in the unit.
///
/// Of course, without a single variable "select" type option, the final
/// stocks count in the unit is only 1.
///
/// @namespace Sales
/// @erd Carts
model shopping_sale_snapshot_unit_stocks {
/// Primary Key.
///
/// @format uuid
id String @id @db.Uuid
/// Belonged unit's {@link shopping_sale_snapshot_units.id}
///
/// @format uuid
shopping_sale_snapshot_unit_id String @db.Uuid
/// Name of the final stock.
name String @db.VarChar
/// Nominal price.
///
/// This is not real price to pay, but just a nominal price to show.
/// If this value is greater than the `real_price`, it would be shown
/// like seller is giving a discount.
///
/// @minimum 0
nominal_price Float @db.DoublePrecision
/// Real price to pay.
///
/// @minimum 0
real_price Float @db.DoublePrecision
/// Initial inventory quantity.
///
/// If this stock has been sold over this quantity count, the stock can't
/// be sold anymore, because of out of stock. In that case, the seller can
/// supplement the inventory quantity by registering some
/// {@link shopping_sale_snapshot_unit_stock_supplements} records.
///
/// @minimum 0
quantity Int
/// Sequence order in belonged unit.
sequence Int @db.Integer
}
Interface Agent
An agent that designs API interfaces through AutoBEโs specialized AST-based approach.
- Input: Requirements specification, ERD documentation
- Output:
- OpenAPI Document generated from AST
- Complete NestJS project with TypeScript code
- TypeScript DTO types
- NestJS Controllers
- Client SDK Library
- E2E Test Functions
- Features:
- No-code approach using
AutoBeOpenApi.IDocument
AST structure - Built-in AutoBE API design compiler for validation and transformation
- Multi-stage transformation pipeline (AST โ OpenAPI โ NestJS)
- Comprehensive API documentation generation
- No-code approach using
The Interface agent employs AutoBEโs no-code methodology to create precise, validated API interfaces. Rather than writing OpenAPI documents or TypeScript code manually, the AI constructs AutoBeOpenApi.IDocument
AST structures through function calling - a specialized, streamlined format optimized for AutoBEโs development workflow.
The process starts with comprehensive analysis of the requirements specification and ERD documentation to understand business needs and data relationships. Using function calling, the AI builds the AutoBeOpenApi.IDocument
AST that captures the complete API design including endpoints, request/response schemas, validation rules, and documentation.
This custom AST format provides a more constrained and validated structure compared to raw OpenAPI or TypeScript, helping maintain consistency and preventing design flaws that could arise from unrestricted flexibility. The structured approach ensures that all APIs follow established patterns and conventions.
AutoBEโs built-in API design compiler validates the AST structure for correctness, consistency, and best practices. The validation covers HTTP method usage, naming conventions, status codes, and documentation completeness. Any validation errors trigger feedback to the AI for immediate correction, creating an iterative refinement process.
The transformation pipeline operates in two distinct stages. First, the AutoBeOpenApi.IDocument
AST is converted into a standard OpenApi.IDocument
format that conforms to the official OpenAPI specification. This OpenAPI document undergoes additional specification-compliant validation. Second, the validated OpenAPI document feeds into AutoBEโs code generation pipeline, producing the complete NestJS project including controllers, DTOs, client SDK library, and E2E test scaffolds.
Each generated interface includes comprehensive JSDoc documentation explaining its purpose, behavior, and relationships. An internal review process continuously validates the generated interfaces against the original requirements and data model, ensuring completeness and consistency throughout the development cycle.
API Controller
import { Controller } from "@nestjs/common";
import { TypedRoute, TypedBody, TypedParam } from "@nestia/core";
import typia, { tags } from "typia";
import { ICart } from "../../api/structures/ICart";
import { IPageICart } from "../../api/structures/IPageICart";
@Controller("/carts")
export class CartsController {
/**
* Create a new shopping cart (member or guest) with optional initial
* contents (CartOrder.carts).
*
* This operation creates a new shopping cart (possibly with initial
* contents) for the authenticated user or guest (session_token provided).
* The CartOrder.carts table supports multiple carts per user or session
* (e.g., guest session and later migration to member).
*
* On creation, mandatory fields are: user_id (if authenticated, optional
* for guest), and session_token (identifies guest cart until login).
* Optionally, initial cart_items may be created.
*
* Business logic: Cart expiration is calculated on creation (configurable).
* Duplicate cart creation with the same session_token/user is prevented
* (enforced by DB unique constraints).
*
* Success returns full cart info (ID, status, items, expiry, etc.). Access
* is restricted to the owner. Errors include violation of unique
* constraints, invalid or expired session_token, and permission checks.
* This endpoint complements cart listing, detail, and item-editing APIs.
*
* @param body Cart creation info (may include items, session_token,
* user_id).
* @autobe Generated by AutoBE - https://github.com/wrtnlabs/autobe
*/
@TypedRoute.Post()
public async post(
@TypedBody()
body: ICart.ICreate,
): Promise<ICart> {
body;
return typia.random<ICart>();
}
/**
* List/search the current user's shopping carts with pagination
* (CartOrder.carts).
*
* Returns a paginated, filterable list of shopping carts owned by the
* current user (including guest carts where session_token matches). The
* CartOrder.carts table supports both user_id and session-based cart
* tracking. Supports searching by cart status (active, expired), expiry
* window, and optionally session_token (for guest/anonymous users).
*
* Results support pagination and sorting (e.g., by updated_at) to handle
* users with multiple carts (frequent behavior with cart templates,
* guest/member, and cross-device migration). RBAC ensures only the current
* user's carts are returned.
*
* Business cases: resuming abandoned carts, cross-device shopping, cart
* analytics, and migration on login. Errors include invalid search params
* or permission denied for other users' carts.
*
* Relation to: cart detail (GET), create (POST), update (PUT), delete
* (DELETE).
*
* @param body Filter/search/paging info for cart listing.
* @autobe Generated by AutoBE - https://github.com/wrtnlabs/autobe
*/
@TypedRoute.Patch()
public async patch(
@TypedBody()
body: ICart.IRequest,
): Promise<IPageICart> {
body;
return typia.random<IPageICart>();
}
/**
* Retrieve detail for a single cart owned by the user or guest
* (CartOrder.carts).
*
* Returns all data and items for a specific shopping cart. The
* CartOrder.carts table tracks authentic carts for users (member or guest).
* The ID parameter identifies the cart; access is only granted for carts
* that belong to the authenticated user or have a matching session_token
* (for guest flows).
*
* Returned detail includes cart status, items, last updated, expiration,
* and links to product variants for the contained items.
*
* Business logic: attempting to access someone else's cart returns 'not
* found' or 'permission denied' for privacy/compliance. Edge cases:
* expired/soft-deleted carts may require special handling (e.g., display as
* 'abandoned').
*
* Paired with cart list/search (PATCH), item editing (PUT/POST), and
* checkout order creation APIs.
*
* @param id Cart unique ID for lookup.
* @autobe Generated by AutoBE - https://github.com/wrtnlabs/autobe
*/
@TypedRoute.Get(":id")
public async getById(
@TypedParam("id")
id: string,
): Promise<ICart> {
id;
return typia.random<ICart>();
}
/**
* Replace or update an existing cart by its ID in the carts table.
*
* This API operation allows updating or replacing the persistent shopping
* cart identified by the provided cart ID. The carts table represents user
* or session scoped shopping carts, supporting both guest and member flows
* as outlined in Cart & Order requirements. The operation requires a full
* update of the atomic cart state, such as user assignment (migrating guest
* to member), session token changes (e.g., after login), or updating
* expiration logic.
*
* When a cart is updated, new metadata (like extension of expiry or session
* handoff) triggers compliance tracking via audit fields (e.g.,
* updated_at). User and session linkage are validated; associated cart
* items are NOT affected and remain intact unless separately updated
* through cart item endpoints. All changes are strictly audit-logged to
* meet regulatory traceability.
*
* This operation enforces full replacement of the specified cart resource,
* not partial patching. In accordance with soft delete policy, 'deleted_at'
* may be set to force logical deletion.
*
* Related operations include creating a new cart (POST /carts) or deleting
* a cart (DELETE /carts/{id}). For managing cart items, dedicated endpoints
* (e.g., /cartItems) are used.
*
* On error, validation failures (invalid user/session or expired cart)
* return explicit error codes. Soft delete compliance is enforced in all
* flows by marking 'deleted_at', not physical deletion.
*
* @param id Unique identifier for the target cart.
* @param body Updated cart entity data.
* @autobe Generated by AutoBE - https://github.com/wrtnlabs/autobe
*/
@TypedRoute.Put(":id")
public async putById(
@TypedParam("id")
id: string & tags.Format<"uuid">,
@TypedBody()
body: ICart.IUpdate,
): Promise<ICart> {
id;
body;
return typia.random<ICart>();
}
/**
* Soft delete a cart by its ID in the carts table.
*
* This API operation performs a logical (soft) deletion of the persistent
* shopping cart referenced by the provided cart ID. The carts table
* enforces soft delete across all shopping carts in the system to meet
* compliance, full audit, and reversibility requirements specified in Cart
* & Order.
*
* When invoked, this endpoint updates the 'deleted_at' column for the
* specified cart record, marking it as deleted but retaining the record for
* later audit analysis or undelete flows if necessary. Attempting to delete
* a non-existent or already deleted cart returns an error with reason.
*
* Related endpoints include creating a cart (POST /carts), updating a cart
* (PUT /carts/{id}), and managing cart items separately. Carts must be
* referenced using their unique identifier and must match RBAC and session
* ownership rules to protect user/session scoping integrity.
*
* No physical deletion occurs; full compliance with GDPR, CCPA, and
* regional audit laws is enforced. This endpoint does not affect related
* cart items, which must be deleted via dedicated cartItem endpoints if
* needed.
*
* @param id Unique identifier of the cart to delete.
* @autobe Generated by AutoBE - https://github.com/wrtnlabs/autobe
*/
@TypedRoute.Delete(":id")
public async eraseById(
@TypedParam("id")
id: string & tags.Format<"uuid">,
): Promise<ICart> {
id;
return typia.random<ICart>();
}
}
Test Agent
An agent that enhances and completes E2E test code for each API interface.
- Input: API interfaces, OpenAPI Schema, pre-generated E2E test scaffolds
- Output: Complete test code for each API function
- Features:
- Enhancement of automatically generated test scaffolds
- Dependency analysis for proper test sequencing
- Complex scenario generation with business logic validation
- Comprehensive test documentation
- TypeScript compiler validation
- Test coverage optimization
The Test agent builds sophisticated test suites from the foundation provided by the Interface agentโs automatically generated E2E test scaffolds. When the Interface agent transforms AutoBeOpenApi.IDocument
AST into a NestJS project, it mechanically creates basic test function scaffolds for each API endpoint. The Test agentโs role is transforming these skeletal structures into comprehensive, business-aware test suites.
Working with the pre-generated scaffolds alongside requirements specifications, ERD documentation, and API interfaces, the Test agent develops sophisticated test scenarios that validate individual endpoint functionality and business rule compliance. It analyzes cross-endpoint interactions to ensure comprehensive system validation.
A key capability is dependency analysis between API functions. When endpoints require preconditions established by other API calls, the agent structures integrated test scenarios with proper execution sequencing. This dependency-aware approach ensures tests reflect real-world usage patterns and catch integration issues.
The agent designs comprehensive test scenarios covering edge cases, error conditions, and complex business workflows. Each enhanced test includes detailed documentation explaining the testโs purpose, prerequisites, expected outcomes, and relationship to business requirements, serving as both executable validation and living documentation.
Built-in TypeScript compiler validation provides immediate feedback on syntax and type correctness. Compilation errors trigger iterative refinement, creating a self-correcting development loop. An internal review process evaluates test coverage and quality, ensuring optimal validation thoroughness across the entire API surface.
import { TestValidator } from "@nestia/e2e";
import api from "@ORGANIZATION/PROJECT-api";
import { IBbsArticle } from "@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle";
import { IBbsArticleComment } from "@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticleComment";
import typia from "typia";
export async function test_create_comment_on_article_with_special_characters(connection: api.IConnection): Promise<void> {
// 1. Create an article to comment on
const articleInput: IBbsArticle.ICreate = {
writer: "employee_special",
format: "txt",
title: "Test Article for Special Comment",
body: "This is a base article for comment posting.",
files: [],
password: "secure_pw1!"
};
const article = await api.functional.bbs.articles.post(connection, {
body: articleInput,
});
typia.assert<IBbsArticle>(article);
// 2. Post a comment with special characters, emojis, and multilingual text
const specialCommentBody =
"Greetings! ๐ ใใใซใกใฏ๏ผ๐ก รa va? ะัะธะฒะตั! ู
ุฑุญุจุง! ไฝ ๅฅฝ๏ผ & <script>alert('XSS')</script> \n -- ุงูุณูุงู
ุนูููู
-- ๐โจ";
const commentInput: IBbsArticleComment.ICreate = {
writer: "employee_special",
format: "txt",
body: specialCommentBody,
files: [],
password: "special_comment_pw1@"
};
const comment = await api.functional.bbs.articles.comments.postByArticleid(connection, {
articleId: article.id,
body: commentInput,
});
typia.assert<IBbsArticleComment>(comment);
// 3. Retrieve the comment and validate its content
const commentId = comment.id;
const readComment = await api.functional.bbs.articles.comments.getByArticleidAndId(connection, {
articleId: article.id,
id: commentId,
});
typia.assert<IBbsArticleComment>(readComment);
TestValidator.equals("comment writer")(
comment.writer
)(readComment.writer);
TestValidator.equals("special comment body")(
comment.snapshots[0].body
)(specialCommentBody);
// 4. (Negative/robustness) Try posting an empty body (should be rejected or stored as empty)
const invalidCommentInput: IBbsArticleComment.ICreate = {
writer: "employee_special",
format: "txt",
body: "",
files: [],
password: "special_comment_pw2@"
};
await TestValidator.error("should reject empty body")(
() => api.functional.bbs.articles.comments.postByArticleid(connection, {
articleId: article.id,
body: invalidCommentInput,
})
);
}
Realize Agent
An agent that implements complete service logic for each API function.
- Input: Requirements specification, Prisma schema, API interfaces, enhanced test code
- Output: Complete service implementation code for each API endpoint
- Features:
- Direct TypeScript implementation (traditional coding approach)
- Dual feedback validation (compilation + runtime testing)
- Business logic implementation with best practices
- Database integration through Prisma
- Comprehensive error handling and security
The Realize agent represents the culmination of the AutoBE development pipeline, synthesizing all previous agentsโ outputs to create fully functional service implementations. Unlike other agents that use AST-based no-code approaches, the Realize agent employs traditional coding methods to write actual TypeScript implementation code.
The implementation process begins with comprehensive analysis of all available artifacts. The requirements specification defines business logic requirements, the Prisma schema provides the data model, the OpenAPI document specifies API contracts, and the enhanced test code establishes validation criteria. This multi-source analysis ensures implementations satisfy all defined requirements and constraints.
The agent creates maintainable, efficient code that correctly implements business logic while following established best practices. Generated service providers handle database interactions through Prisma, implement security and validation checks, process business rules according to specifications, and ensure proper error handling and logging.
A robust dual-feedback validation system ensures high-quality output. The embedded TypeScript compiler provides immediate compilation feedback, catching syntax errors and type mismatches. More critically, implementation code undergoes continuous testing against the Test Agentโs enhanced test suites, providing runtime validation of functional correctness and business logic compliance.
This compile-time and runtime validation creates a comprehensive quality assurance environment where errors are caught and corrected iteratively. An internal review process evaluates code quality, identifying optimization opportunities, performance improvements, and coding standard adherence. The result is implementation code that is functionally correct, maintainable, and performant.