AI-Native Development. AI-DLC trong thực tế: Từ ý tưởng đến production
Nguyên tắc và framework chỉ có giá trị khi chúng hoạt động trong thực tế. Phần này đi vào hai kịch bản cụ thể — xây mới hoàn toàn (Green-Field) và phát triển trên hệ thống cũ (Brown-Field) — để thấy AI-DLC vận hành như thế nào từng bước một.
Kịch bản thực tế: Xây dựng Recommendation Engine
Hãy tưởng tượng một Product Owner bước vào phòng họp với một câu nói ngắn gọn:
"Chúng ta cần xây dựng một recommendation engine để cross-sell sản phẩm."
Đây là Intent. Từ đây, AI-DLC bắt đầu vận hành — không phải bằng cách chờ đợi con người lên kế hoạch chi tiết, mà bằng cách AI chủ động tạo ra Level 1 Plan, team validate và tinh chỉnh, rồi cùng nhau đi vào thực thi.
Green-Field: Xây từ đầu
Inception Phase — Biến câu nói thành bản đồ hành động
Mob Elaboration bắt đầu. AI không ngồi chờ được giao việc — nó chủ động hỏi ngược lại:
"Ai là người dùng chính của tính năng này? Kết quả kinh doanh nào cần đạt được? Dữ liệu lịch sử giao dịch hiện có ở đâu?"
Những câu hỏi này không phải nghi lễ xã giao — chúng là cách AI thu hẹp không gian mơ hồ của Intent trước khi bắt đầu phân rã. Càng ít mơ hồ ở đầu vào, càng ít lãng phí ở đầu ra.
Sau khi nhận đủ ngữ cảnh, AI elaborates Intent thành User Stories và NFRs, rồi nhóm chúng lại thành các Units có tính cohesion cao:
| Unit | Nội dung |
|---|---|
| User Data Collection | Thu thập và chuẩn hóa dữ liệu hành vi người dùng |
| Recommendation Algorithm | Chọn và huấn luyện mô hình gợi ý phù hợp |
| API Integration | Expose recommendation service cho các hệ thống downstream |
Ví dụ về human oversight trong thực tế: Product Owner nhìn vào Unit "User Data Collection" và nhận ra AI chưa đề cập đến GDPR. Họ điều chỉnh requirements để bổ sung privacy compliance — một quyết định mà AI không thể tự đưa ra vì nó phụ thuộc vào chính sách tổ chức và bối cảnh pháp lý cụ thể.
Kết thúc Inception, team có trong tay: PRFAQ, User Stories đầy đủ Acceptance Criteria, NFR definitions, Risk descriptions và kế hoạch Bolts sơ bộ. Tất cả được AI tạo ra, tất cả được con người validate.
Construction Phase — Từ domain model đến code chạy được
Đây là giai đoạn mà AI-DLC tỏa sáng rõ nhất. Developer mở session với AI, và AI — không phải Developer — chủ động khởi xướng Bolt được phân công.
Bước 1: Domain Design
AI áp dụng DDD để mô hình hóa business logic của Unit "Recommendation Algorithm":
- Entities:
Product,Customer,PurchaseHistory - Value Objects:
RecommendationScore,ProductCategory - Domain Events:
ProductViewed,PurchaseCompleted,RecommendationGenerated - Aggregate Root:
CustomerRecommendationProfile
Developer review và phát hiện một edge case quan trọng: "Hệ thống xử lý thế nào khi customer mới — chưa có purchase history?" AI chưa xử lý cold start problem. Developer thêm vào domain model một fallback strategy: dùng popularity-based recommendation cho new customers thay vì collaborative filtering.
Bước 2: Logical Design
AI dịch domain model sang kiến trúc kỹ thuật, đề xuất:
- Pattern: Event-driven architecture với Amazon EventBridge
- Compute: AWS Lambda cho serverless recommendation serving
- Storage: Amazon DynamoDB cho user profiles và recommendation cache
- ML: Amazon SageMaker để train và host collaborative filtering model
Developer đánh giá trade-offs và ghi đè một quyết định: chấp nhận Lambda cho scalability, nhưng chuyển từ Aurora sang DynamoDB vì query performance quan trọng hơn relational flexibility trong bài toán này. AI ghi nhận quyết định này vào ADR (Architecture Decision Record) để traceability.
Bước 3: Code Generation & Testing
AI sinh code cho collaborative filtering, tích hợp DynamoDB data source, và tự động tạo toàn bộ test suite:
- Unit tests: Kiểm tra logic tính RecommendationScore
- Integration tests: Luồng từ PurchaseCompleted event → recommendation update
- Security tests (SAST): Scan static code vulnerabilities
- Performance tests: Load test với 10,000 concurrent requests
AI chạy tests, phân tích kết quả, và phát hiện: query DynamoDB đang bị N+1 problem khiến p99 latency vượt NFR. AI đề xuất fix bằng BatchGetItem. Developer review, approve, AI implement và rerun — latency về đúng ngưỡng.
Operations Phase — AI trực chiến sau khi deploy
Sau khi Deployment Unit được AI đóng gói (container image + Lambda functions + Terraform stack) và Developer approve rollout:
Observability tự động: AI liên tục phân tích telemetry. Trong tuần đầu sau launch, AI phát hiện latency spike vào giờ cao điểm tối và đề xuất:
"Recommendation cache hit rate giảm 40% vào 20:00–22:00. Đề xuất tăng DynamoDB provisioned capacity từ 500 đến 1,200 RCU trong khung giờ này, ước tính giảm p95 latency từ 340ms xuống 95ms."
Developer validate con số, approve — AI thực thi scaling policy. Không cần on-call engineer ngồi canh dashboard lúc 10 giờ tối.
Brown-Field: Thêm tính năng vào hệ thống đang chạy
Brown-field là kịch bản phổ biến hơn nhiều trong thực tế: không ai bắt đầu từ tờ giấy trắng. Hầu hết công việc engineering là thêm tính năng, tối ưu NFR, hoặc trả technical debt cho hệ thống đã tồn tại hàng năm.
AI-DLC xử lý kịch bản này với một bước quan trọng được thêm vào đầu Construction Phase.
Inception Phase
Giống hệt Green-Field — AI hỏi, team elaborates, Units và Bolts được định nghĩa.
Construction Phase — Điểm khác biệt: Reverse Engineering thành Semantic Models
Trước khi viết một dòng code mới, AI phải hiểu hệ thống hiện tại. Thay vì đọc hàng chục nghìn dòng code thô, AI nâng codebase lên một lớp abstraction cao hơn:
Static Model — Bản đồ cấu trúc:
Các components là gì? Responsibilities của từng component? Relationships và dependencies giữa chúng?
Dynamic Model — Bản đồ hành vi:
Các components tương tác như thế nào để thực hiện các use case quan trọng? Data flow trông ra sao?
Tại sao cần bước này? Không có ngữ cảnh đủ phong phú về hệ thống hiện tại, AI sẽ sinh code "đúng về mặt kỹ thuật nhưng sai về mặt kiến trúc" — không tích hợp được với patterns đang dùng, vi phạm invariants đã có, hoặc duplicate logic đã tồn tại ở nơi khác.
Developer và Product Owner cùng review các models này — thường là lúc phát hiện ra những "bí mật" của codebase mà không ai còn nhớ. Sau khi models được validate, phần còn lại của Construction Phase diễn ra giống Green-Field.
Làm thế nào để áp dụng AI-DLC?
Hiểu phương pháp là một chuyện — đưa nó vào tổ chức thực tế là chuyện khác. AI-DLC đề xuất hai con đường:
1. Learning by Practicing — Unicorn Gym
Thay vì training trên tài liệu và slides, AWS Solution Architects thiết kế AI-DLC Unicorn Gym: một chương trình thực hành các rituals (Mob Elaboration, Mob Construction) trực tiếp trên các bài toán thực tế mà team đang giải quyết.
Không có lý thuyết trước khi thực hành. Không có bài tập giả định. Team học bằng cách làm ngay trên công việc thật — với AI-DLC guide đồng hành.
2. Embedding vào Developer Experience Tooling
Cách tiếp cận dài hạn hơn: tích hợp AI-DLC trực tiếp vào các orchestration tools mà developer dùng hàng ngày. Khi workflow AI-DLC là một phần của IDE hoặc internal developer platform, developer thực hành phương pháp mà không cần "chuyển đổi tư duy" — nó đã là cách làm việc mặc định.
Một số ví dụ đang triển khai: FlowSource (Cognizant), CodeSpell (Aspire), AIForce (HCL).
Điểm mấu chốt
Đọc về AI-DLC qua nguyên tắc, người ta có thể băn khoăn: "Liệu đây có thực tế không?" Kịch bản Recommendation Engine cho thấy câu trả lời là có — và cụ thể hơn, nó cho thấy vai trò của con người không giảm đi mà thay đổi bản chất:
- Từ người viết code → người quyết định trade-offs
- Từ người lên kế hoạch → người validate kế hoạch
- Từ người chạy tests → người phán xét kết quả
AI xử lý khối lượng công việc. Con người giữ phán đoán. Cả hai cùng chịu trách nhiệm về kết quả.
Đó là sự cộng tác thực sự giữa người và AI — không phải AI thay thế con người, cũng không phải con người dùng AI như một công cụ đơn thuần.
All rights reserved
