Có thể phát triển đến đâu với vibe coding?
(github.com/delos-cresco)Đây là phần hồi tưởng về những gì tôi cảm nhận được ở khía cạnh công nghệ và triển khai hơn là bản thân sản phẩm.
Đây hoàn toàn là suy nghĩ cá nhân.
Xin hãy cân nhắc rằng đây là dự án tôi vừa học vừa làm trong thời gian học kỳ năm 4 đại học!
Vì sao tôi bắt đầu dự án này
- Phát triển sản phẩm với tư duy là đang lập startup, từ góc nhìn PM/PO
- Kiểm chứng xem có thể thực sự làm một MVP full-stack bằng Claude Code hay không
- Giải quyết bài toán tìm kiếm cổ phiếu trong đầu tư chứng khoán
- Chủ động đưa các sản phẩm thương mại vào sử dụng để rút ra insight trong quá trình đó
Timeline dự án và thông tin bổ sung
- Lập kế hoạch + phát triển: 1 tháng
- Triển khai: 1 tuần
- Vận hành: 2 tháng
- Chi phí đầu tư
- Claude Code: 100 USD
- Tài khoản Apple Developer: 100 USD
- AWS: khoảng 220 USD
- Managed DB: khoảng 300 USD
- Free tier: Datadog, Langfuse, Posthog
- Quảng cáo: 40.000 won
- Tổng cộng: khoảng 1.000.000 won (tiền túi của tôi..)
Quá trình phát triển
Frontend
- Định nghĩa design token
- Triển khai 3 trang cốt lõi bằng Figma
- Áp dụng design token vào Expo, triển khai bằng cách tận dụng Figma MCP
- Đã thử dùng Expo MCP nhưng không ổn định nên tự xem kết quả và debug trực tiếp
- Tạo trang mới mà không cần wireframe Figma bằng prompt kiểu “dùng design token và mượn concept thiết kế của các trang khác…”
Backend
- Yêu cầu phát triển API dựa trên yêu cầu bài toán
- Yêu cầu tạo luôn các endpoint cần thiết dựa trên yêu cầu từ frontend
- Dùng stack phổ biến là Django nên có thể phát triển bằng Claude Code mà hầu như không bị nghẽn ở khâu triển khai
AI
- Định nghĩa kiến trúc multi-agent rồi yêu cầu triển khai dựa trên đó
- Đính kèm link web để tham khảo nhằm theo kịp các spec mới nhất của LangChain và LLMOps
- Dùng chính LLM để tạo prompt cho dịch vụ LLM rồi đưa vào sử dụng
Observability
- Xây dựng trên nền ClickStack rồi migrate sang Datadog
- Sau khi phát triển toàn bộ hệ thống thì áp dụng logging và analytics
Hạ tầng
- Ban đầu định dùng Pulumi nhưng Claude Code làm chưa tốt nên viết file triển khai bằng script dựa trên AWS CLI
- Do chi phí nên không xây dựng CI/CD và Dev Server
Danh sách công nghệ được áp dụng
- Dịch vụ: đăng ký thuê bao/thanh toán, đăng nhập mạng xã hội, dark mode
- Dữ liệu: thu thập dữ liệu qua API, CDC, ETL
- AI: multi-agent, Text-to-SQL, Agentic RAG, streaming SSE, quản lý session, Retry, Rate Limit
- LLMOps: AB Test, Cloud Based Prompt Management(OTA Update), Synthetic Dataset, Evaluation
Insight
Triển khai
- Chỉ với gói Claude Code 100 USD trong khoảng 1 tháng, tôi có thể một mình tạo ra một sản phẩm ở quy mô như thế này
- Tôi chỉ định nghĩa chuẩn design token để triển khai UI, nhưng nếu xây luôn cả design system và đưa nó vào Claude.md thì có thể phát triển frontend nhanh hơn và ổn định hơn
- Tầm quan trọng của design system. Nó cải thiện năng suất phát triển frontend rất nhiều. So với việc làm Figma, cứ triển khai trước rồi chỉnh sửa sau còn nhanh hơn. Thực tế có những trang đã được triển khai nhưng không hề có trong Figma.
- Định nghĩa các trường hợp ngoại lệ. Điều này càng quan trọng hơn với app di động và hệ thống AI. Cần lên kế hoạch và triển khai cho các tình huống không phải happy path như quản lý timeout trên toàn hệ thống, chính sách background, khôi phục streaming, lỗi đơn giản... Có lúc Claude Code tự xử lý lỗi, nhưng không giải quyết một cách gọn đẹp trên cả frontend lẫn backend. Vì vậy cần yêu cầu thêm với Claude Code để xử lý các phần này.
- Cấm refactor quy mô lớn. Lúc đầu tôi nhét toàn bộ mã React và CSS vào một file frontend rồi refactor để tách ra. Kết quả là thất bại. Dù đã tách được nhưng UI khác đi so với ban đầu, cuối cùng vẫn phải tách dần từng chút một. Có vẻ cần suy nghĩ về kiến trúc mã ngay từ đầu, và nếu dùng component thì nên thêm nội dung liên quan vào prompt để tận dụng tốt hơn.
- Tận dụng Claude.md. Sau khi phát triển một tính năng, tôi yêu cầu Claude Code bổ sung vào Claude.md những gì nên lưu lại dựa trên nội dung đó. Dần dần file trở nên quá lớn nên lại yêu cầu chỉ giữ phần thật sự cần thiết và xóa phần còn lại. Kết hợp readme và claude.md một cách hợp lý để điều chỉnh context cho LLM. (thời chưa có skills)
- Không dùng sub-agent. Vì không có cũng làm được khá tốt nên tôi không dùng. Chỉ đơn giản là dùng Plan mode để yêu cầu cho đến khi kế hoạch phát triển đủ cụ thể, sau đó để Agent tự phát triển.
- Nên định nghĩa trước package và công nghệ sẽ dùng rồi thông báo rõ ràng. Cần ghi chính xác vào Claude.md, Readme hoặc spec cụ thể để tránh tạo mã trùng lặp hoặc rơi vào tình huống dùng stack khác. (Skills?)
Hệ thống AI
- ReAct chậm. UX rất tệ. Dù đã cấu hình để chạy multi-agent song song nhưng vẫn quá chậm.
- UX. Để giải quyết vấn đề phản hồi chậm, tôi đưa vào UX hiển thị từng step của multi-agent, streaming, animation, render Markdown động v.v. Nhưng nếu một câu trả lời mất đến 1 phút thì những thứ đó có còn ý nghĩa gì nữa?… (app B2C)
- Quản lý prompt và tool schema trên nền tảng cloud. Điểm hay là có thể áp dụng trong môi trường online. Giờ tôi nghĩ đây là thứ bắt buộc, và tôi rất thích Langfuse.
- Với Text-to-SQL thì phải đưa schema vào prompt. Nhưng việc này ngốn context quá nhiều. Có vẻ có thể giải quyết bằng fine-tuning hoặc RAG.
- Đánh giá và iteration. Tôi xây dựng Synthetic Dataset theo từng persona người dùng và đánh giá bằng LLM-as-a-Judge. Tôi muốn tự động hóa nhưng đúng là một mình thì thiếu tài nguyên phát triển.
- Metric đánh giá và rubric: phiền hơn tôi tưởng. Tôi nghĩ metric phổ quát kiểu như DAU và MAU. Nhưng chỉ với những metric như vậy thì không thể rút ra insight. Cần định nghĩa metric theo từng trường hợp để phân biệt các ca chất lượng thấp, giải quyết chúng rồi tiếp tục iteration. Cuối cùng vẫn cần một hệ thống giúp tạo custom metric thật tốt. (multi-turn thì sao?..)
- OpenAI Tier chặt hơn tôi tưởng. Ở tier thấp thì không thể dùng các model tốt cho môi trường production.
Hạ tầng
- AWS đắt, Managed DB đắt. Tốt thì tốt nhưng tôi thấy hối hận
- Clickhouse rất đắt nhưng tốt. Dùng bản managed nên tiện. Đặc biệt là làm luôn được cả CDC. (nhanh thì có ích gì khi LLM lại chậm)
- Qdrant, Redis Cloud cũng không tệ. Mất ít thời gian để dựng, mà chi phí cũng rẻ.
- Datadog. Quá tốt. Chỉ là sẽ rất đắt nên tôi chỉ dùng free tier. Đặc biệt tính năng gom riêng các lỗi phát sinh rồi thông báo là rất hay. Tôi dùng agent dạng sidecar trên ECS.
Dịch vụ
- Thanh toán và đăng ký thuê bao. Tôi đã cân nhắc dùng Toss Pay nhưng cuối cùng không dùng. Trước hết là phải có phí thường niên, hơn nữa không có tài liệu cho React Native nên SDK cũng không ổn. Tôi khá thất vọng. Kết quả là tôi chọn Nice Payments. Không có phí thường niên, lại có development server nên có thể phát triển khá ổn.
- Thanh toán Apple. Dù dùng Nice Payments nhưng vẫn có vấn đề. Chính sách thanh toán của Apple rất khắt khe. Trong quá trình phát triển iOS đã có các vấn đề liên quan đến chính sách của Apple, cần giải quyết bằng nhiều tài liệu và cả về UI. Có lẽ cứ dùng hệ thống thanh toán nội bộ của Apple sẽ đỡ đau đầu hơn.
- Thanh toán và đăng ký thuê bao (thanh toán tự động) là hai thứ khác nhau. Để triển khai thanh toán tự động cần hạ tầng scheduling, đồng thời cũng phải chú ý đến bảo mật khi lưu card key. Dù cuối cùng tôi cũng làm được, nhưng phức tạp hơn tưởng tượng. Điều đó khiến tôi nghĩ mình muốn thử dùng Stripe.
- Push notification. Có thể dựng khá tiện trong Expo. Cuối cùng vẫn cần back office để gửi thông điệp, nhưng tôi nghĩ đây là tính năng thiết yếu.
Những suy nghĩ
- Tầm quan trọng của software design pattern và architecture có lẽ sẽ còn tăng lên.
- Tôi hy vọng mọi người sẽ quan tâm nhiều hơn đến việc dùng coding agent để tạo ra sản phẩm vượt ra ngoài mức toy project.
- Hãy tránh over-spec. Nhưng muốn xin việc thì chẳng phải cũng cần biết over-spec sao? Có lẽ lần sau cứ dùng
docker-composetrên một instance là xong… (với supabase chăng?) - Thời đại khởi nghiệp một người gần như đã tới. Nhưng tôi nghĩ chuyện kiếm tiền và chuyện làm ra sản phẩm là hai việc khác nhau.
- Làm một mình thì không vui
- Linear cũng ổn để dùng thay Jira. Vì mới dùng lần đầu nên tôi vẫn chưa rõ cách gom và xem theo hệ phân cấp ticket.
Kết quả
- Dự án đã kết thúc vì không thể gánh nổi chi phí máy chủ.
- Số dư -100
Tham khảo
Có thêm nội dung từ trang 4 trở đi.
8 bình luận
Số dư -100
haha
Cảm ơn bạn đã chia sẻ nội dung hay.
Chắc hẳn đây là một trải nghiệm trị giá hơn cả triệu won. Tôi cũng nhớ là hồi năm 4 đại học mình gần như không có nhiều kinh nghiệm làm dự án. Dùng AI mà có thể làm được đến mức đó thì thật sự rất đáng nể.
Chia sẻ trải nghiệm thật sự rất thú vị. Tôi đã đọc rất thích. Hóa ra bạn thậm chí còn là hậu bối ở trường cũ của tôi nữa cơ. Dạo này đến năm 4 mà cũng thử những thử thách như thế này sao, thật sự rất ngầu.
Có lẽ là cố tình over-engineer cho mục đích học tập, nhưng chi phí thì thật đáng tiếc.
Gọn gàng đấy.
Chất lượng portfolio của sinh viên đại học dạo này thật sự không phải dạng vừa. 20 năm trước, khi tôi tốt nghiệp, cảm giác như mình ra trường mà chẳng biết gì cả, thật đáng nể.
AI đã kéo mặt bằng chung lên rất nhiều.
Bây giờ có khi đáp án đúng thật là cứ chọn người tử tế, dễ làm việc làm dev thôi cũng nên haha