eSimphony được xây bởi một đội kỹ sư năm người. Sản phẩm phủ hơn 150 quốc gia, ship app native iOS và Android, vận hành một stack tích hợp nhà mạng đa khu vực, hỗ trợ năm ngôn ngữ trọn vẹn, và ship thay đổi sản phẩm hằng tuần. Chúng tôi không phải một telco nghìn người. Chúng tôi là một đội nhỏ vận hành với đòn bẩy có chủ ý.

Đòn bẩy đến từ một cách tiếp cận cụ thể về kỹ thuật mà chúng tôi đã thấm trong 18 tháng qua. Chúng tôi gọi nó là phát triển AI-native. Đây là điều nó thực sự trông như thế nào trong thực tế.

Hình dạng của đội

Năm kỹ sư. Một designer sản phẩm. Một CEO vẫn tự viết một số spec sản phẩm. Không có Product Manager chính thức — spec đến từ CEO + nháp được Moza hỗ trợ + phán đoán kỹ thuật. Không có đội QA chuyên trách — testing là một phần của vòng build. Không có DevOps riêng — hạ tầng thuộc về người nào ship tính năng đó.

Đây không phải khoe khoang. Đó là một ràng buộc. Với cỡ đội này, cách duy nhất để ship một sản phẩm ở phạm vi của eSimphony là nhân lên sản lượng của mỗi kỹ sư. AI là cấp số nhân chúng tôi đã chọn dựa vào.

Quy trình năm giai đoạn

Mọi thay đổi tại eSimphony — từ sửa câu chữ đến tích hợp một nhà mạng mới — đều đi qua cùng năm giai đoạn. Mỗi giai đoạn có AI hỗ trợ; mỗi giai đoạn có người trong vòng lặp.

1. Khám phá (không có rào cản kỹ thuật)

Khi một yêu cầu mới xuất hiện ("chúng ta cần tích hợp nhà mạng X cho độ phủ Ai Cập"), bước đi đầu tiên của kỹ sư không phải là giả định những gì họ chưa biết. Đó là dùng AI để khám phá vùng đất xa lạ trong 20 phút thay vì 2 ngày.

Trong thực tế: một kỹ sư chưa bao giờ tích hợp một MVNO Ai Cập có thể prompt một trợ lý AI với tài liệu API của nhà mạng đó, nhận một bản tóm tắt có cấu trúc về bề mặt tích hợp, hỏi tiếp về các trường hợp biên ("luồng eKYC điển hình ở thị trường này là gì?"), và sản xuất một đánh giá một trang về công sức, rủi ro và ẩn số trước bữa trưa.

Điều thay đổi: nút thắt không còn là "chúng ta có kỹ sư biết lĩnh vực này không?" Mà là "kỹ sư chúng ta có, được AI hỗ trợ, có đủ năng lực trong lĩnh vực này trong vài giờ không?" Hầu như luôn luôn là có.

2. Spec (giờ, không phải tuần)

Hầu hết spec sản phẩm ở hầu hết công ty mất 1–3 tuần: một PM nháp, các bên liên quan review, các trường hợp biên được thêm vào, tiêu chí chấp nhận được tinh chỉnh, rồi kỹ thuật scope lại. Đến khi spec "xong," cơ hội ban đầu đã dịch chuyển.

Cách của chúng tôi: kỹ sư (hoặc CEO, tùy tính năng) phác thảo một ý sản phẩm một câu. AI mở rộng thành một PRD có cấu trúc — user flow, các trường hợp biên, chỉ số thành công, tiêu chí chấp nhận, câu hỏi mở. Đội tinh chỉnh trong một buổi làm việc 45 phút. Spec được giao cho kỹ thuật ngay trong ngày.

Đánh đổi: spec từ quy trình này hơi thô hơn so với spec truyền thống do PM dẫn dắt trong 2 tuần. Chúng tôi chấp nhận điều đó. Sự nén thời gian đến lần triển khai đầu tiên đáng giá hơn sự mơ hồ bổ sung, vốn sẽ được giải quyết trong quá trình build, không phải trước đó.

3. Thiết kế (vòng lặp phản hồi nhanh)

Với các tính năng có nhiều UI, designer của chúng tôi làm việc cùng kỹ sư trong một vòng lặp "thiết kế-build-phản hồi" đo bằng phút, không phải ngày. Các mockup do AI sinh (Figma plugin + image generator) khám phá các biến thể nhanh chóng. Kỹ sư ship một prototype trong vài giờ. Designer review trên phần cứng thật. Vòng lặp đo bằng chu kỳ trong ngày.

Kết quả là thiết kế và kỹ thuật không tuần tự — chúng đồng thời. Khi thiết kế "cuối cùng," việc triển khai đã đi được hầu hết đường đến sản xuất.

4. Build (AI viết code; người review mọi diff)

Đây là phần AI-native dễ thấy nhất. Quy trình kỹ thuật tại eSimphony hôm nay:

AI sinh ra ~90% code mới (Cursor, Claude, GitHub Copilot, thường kết hợp)
Kỹ sư viết các quyết định kiến trúc, ranh giới tích hợp, logic nghiệp vụ rối rắm cần hiểu biết hệ thống sâu
100% code được con người review trước khi merge. Mọi diff. Mọi PR. Không ngoại lệ.

Điểm cuối này quan trọng và thường bị hiểu lầm. "AI viết code" không có nghĩa là "không có ai nhìn code." Có nghĩa là vai trò của kỹ sư chuyển từ gõ triển khai sang review triển khai. Công việc nhận thức — code này có khớp spec không, có xử lý các trường hợp biên không, có vừa kiến trúc không, có scale được không — vẫn là của kỹ sư. Công việc cơ học — dịch ý định thành code đúng cú pháp, đúng phong cách — được giao đi.

Một PR điển hình tại eSimphony có:

200–800 dòng code thay đổi (so với ~100–200 truyền thống ở các đội năm 2024)
1 kỹ sư review chi tiết
Thường có unit test do AI sinh với độ phủ >80% trên code mới
Bình luận của reviewer tập trung vào kiến trúc, không phải cú pháp

5. Ship (thích nghi trong vài phút)

Việc ship diễn ra dần dần: feature flag cho các thay đổi rủi ro, canary deploy cho dịch vụ backend, telemetry được AI giám sát hiện ra bất thường trong vài phút sau rollout. Khi một lần ship làm hỏng gì đó, rollback đo bằng phút, không phải giờ.

Phần "telemetry được AI giám sát" đáng nói một câu: sau deploy, một agent AI theo dõi bất thường về tỷ lệ lỗi, độ trễ, vấn đề người dùng báo và conversion. Khi bất thường vượt ngưỡng, kỹ sư on-call được page với tóm tắt về các nguyên nhân gốc khả thi. Điều này nén thời gian phát hiện từ "người dùng báo bug lúc 9 giờ sáng" thành "cảnh báo bắn lúc 09:03."

Số liệu

Các chỉ số xấp xỉ trong 12 tháng qua:

Chu kỳ sprint: 1 tuần. Tính năng mới ship hằng tuần; sửa lỗi nhỏ ship hằng ngày.
5 kỹ sư làm full-time trên sản phẩm. Một kỹ sư bổ sung làm contract part-time.
>90% code mới do AI sinh (chủ yếu Cursor + Claude).
100% code đã merge được con người review.
Thời gian trung vị từ spec đến sản xuất: 5–10 ngày.
Sự cố sản xuất mỗi quý: 1–2. Dưới mức trung bình ngành so với phạm vi của chúng tôi.
Ticket hỗ trợ leo thang đến kỹ thuật: ~5/tuần. Hầu hết được giải quyết trong ngày.

Những con số này không lý thuyết. Đó là nhịp vận hành thực tế của đội.

Đây không phải là gì

Cũng đáng nói rõ phát triển AI-native tại eSimphony không có nghĩa là gì.

Không phải "vibe coding." Code được review từng dòng. Quyết định kiến trúc do người làm. AI tăng tốc việc gõ, không phải việc suy nghĩ.

Không phải "không cần testing." Test do AI sinh có những điểm yếu cụ thể (chúng có xu hướng test happy path kỹ hơn các trường hợp biên), nên kỹ sư thêm test viết tay cho các trường hợp biên. Độ phủ test luôn trên 80% trên code mới.

Không phải "không cần kỹ sư senior." Ngược lại. AI nâng giá trị của phán đoán senior lên đáng kể, vì kỹ sư senior có thể review và tinh chỉnh đầu ra của AI nhanh gấp 5–10× so với việc tự viết từ đầu. Kỹ sư junior dùng AI mà không có senior review thường sinh ra code biên dịch được nhưng yếu về cấu trúc.

Không phải "không cần tư duy thiết kế hay sản phẩm." AI vô dụng nếu không có spec rõ ràng và user flow được nghĩ kỹ. Công việc nhận thức "chúng ta nên xây gì, vì sao, cho ai" vẫn thuộc về con người.

Cần những gì

Ba thứ, theo thứ tự tầm quan trọng.

1. Review của con người rất chặt

Mọi dòng code do AI sinh đều đi qua review của một kỹ sư senior trước khi merge. Cám dỗ bỏ qua review cho các thay đổi nhỏ "rõ ràng đúng" là có thật và nguy hiểm. Chúng tôi đã giữ vững nguyên tắc 100% review.

2. Rào kiến trúc chặt chẽ

Khi AI sinh code, nó tuân theo các quy ước cục bộ. Quy ước mạnh = đầu ra AI mạnh. Chúng tôi đã đầu tư nhiều vào ranh giới module rõ ràng, đặt tên nhất quán, interface định kiểu tốt, và tài liệu rõ ràng về "ở đây chúng tôi làm thế nào" để AI có thể khớp mẫu sạch sẽ.

3. Văn hóa chấp nhận AI là mặc định

Đội đã đồng ý, một cách rõ ràng, rằng hỗ trợ AI là mặc định trong mọi quy trình. Kỹ sư mới được onboard vào mặc định này. Phản đối ("nhưng tôi thích tự viết hơn") được lắng nghe và thảo luận, nhưng chuẩn mực đội là AI xử lý công việc cơ học trừ khi có lý do cụ thể không nên.

Chúng tôi không dùng AI cho

Review code do AI sinh (chúng tôi muốn ánh mắt tươi mới của con người)
Quyết định xây gì (chiến lược sản phẩm là việc của con người)
Leo thang hỗ trợ khách trực tiếp (con người xử lý các tình huống khó)
Review hiệu suất và phản hồi đội (chỉ con người)
Quyết định tuyển dụng (chỉ con người, với AI hỗ trợ tìm nguồn và sàng lọc)

Mẫu hình: AI tăng cường thực thi; con người sở hữu quyết định.

Vì sao điều này quan trọng với sản phẩm

Đầu ra của quy trình này thấy được trong sản phẩm. Chúng tôi đã ship:

Kiến trúc eSIM trọn đời (một dự án nhiều quý ở hầu hết công ty)
Moza, trợ lý du lịch AI, ở năm ngôn ngữ
AI Dynamic Plans qua ba khu vực
AI Troubleshooting với tự chữa
App iOS và Android native với release hằng tuần
Backend đa khu vực với uptime 99.9%+
Bản địa hóa 5 ngôn ngữ trên toàn bề mặt sản phẩm

Danh sách này thường cần 30–50 kỹ sư và 3+ năm. Chúng tôi đã ship nó với 5 kỹ sư trong 18 tháng.

Một lưu ý về tuyển dụng

Chúng tôi đang phát triển đội một cách thận trọng. Những kỹ sư làm tốt ở đây chia sẻ ba đặc điểm:

Phán đoán cao hơn sản lượng cao. AI lo việc gõ; chúng tôi muốn kỹ sư xuất sắc trong việc review, quyết định và định hình.
Thoải mái với AI như một đồng nghiệp. Kỹ sư đối xử với AI như đồng nghiệp (giao việc cho nó, review nó, phản biện nó) thay vì coi nó là một quả cầu phép màu hay một mối đe dọa với danh tính mình.
Quan tâm đến người dùng. Quy trình AI-native đủ nhanh để sản xuất nhiều code biên dịch được nhưng chẳng có ý nghĩa. Kỹ sư có thể gắn mọi PR vào "cái này có giúp người dùng không" tạo ra công việc tốt nhất.

Nếu đó là bạn, chúng tôi đang tuyển. Liên hệ qua trang careers hoặc nhắn trực tiếp cho Trung.

Sắp ship gì

Cùng quy trình đã xây sản phẩm hiện tại đang ship lộ trình:

Quản lý đa eSIM (tháng 5/2026)
Gói gia đình (tháng 6/2026)
Loyalty và phần thưởng (tháng 8/2026)
Độ phủ trực tiếp nhà mạng toàn cầu (2027)

Mỗi cái trong số này là một dự án nhiều tháng ở một telco truyền thống. Ước lượng nội bộ của chúng tôi là cả bốn sẽ ship đúng lịch, với cùng đội năm người.

Đó là đòn bẩy. Đó là canh bạc. Đó là cách một đội nhỏ ship chống lại quán tính của cả một ngành.

Xem eSimphony hoạt động, đọc về định vị của chúng tôi, hoặc xem pitch deck của chúng tôi từ MVNO Nation Americas.

Đội 5 người ship gấp 10×: Kỹ thuật AI-native tại eSimphony