Một tài xế Lyft vừa chia sẻ trên r/vibecoding một câu chuyện rất đáng chú ý: sau khi bị hành hung trong lúc chạy xe, anh ấy tự làm một app nhỏ để cảnh báo nếu cuốc xe mới có điểm đến rơi vào khu vực mà mình muốn tránh.
Điểm hay ở đây không nằm ở việc app dùng công nghệ gì quá hào nhoáng. Điểm hay là nó giải quyết đúng một nỗi đau thật, trong một ngữ cảnh mà nền tảng lớn có thể không bao giờ ưu tiên đủ nhanh.
Bối cảnh
Theo bài chia sẻ, người này chạy Lyft toàn thời gian. Sau một sự cố bị hành hung bởi hành khách, anh ấy vẫn phải quay lại làm việc. Không lâu sau, một cuốc xe khác hiện lên với điểm đến là đúng khu nhà nơi sự cố vừa xảy ra.
Từ đó anh ấy tự xây một công cụ:
- Tài xế tự khoanh các vùng muốn tránh.
- Khi có cuốc xe mới, app đọc địa chỉ điểm đến từ giao diện.
- App chuyển địa chỉ thành tọa độ.
- Sau đó so với các vùng đã khoanh để hiện cảnh báo rõ ràng nếu chuyến đó đi vào vùng rủi ro.
Stack được mô tả khá thực dụng: Claude Code, accessibility API, OCR, geocoding và geofence. Không phải sản phẩm bóng bẩy, nhưng đủ dùng cho ca làm thật.
Đây là kiểu use case AI coding làm rất tốt
Nhiều cuộc tranh luận về vibe coding hay bị kẹt ở câu hỏi: “AI có viết được app production-grade không?” Câu hỏi đó đúng, nhưng hơi rộng.
Trường hợp này cho thấy một lát cắt cụ thể hơn: AI coding rất mạnh khi người làm có domain pain cực rõ.
Người tài xế này biết chính xác:
- khoảnh khắc nào trong workflow gây nguy hiểm;
- dữ liệu nào cần đọc;
- cảnh báo cần xuất hiện lúc nào;
- mức “đủ tốt” để dùng mỗi ngày là gì.
Đó là lợi thế mà một team sản phẩm lớn chưa chắc có. Platform như Lyft phải cân nhắc chính sách, pháp lý, UX chung, false positive, vận hành nhiều thị trường. Một cá nhân thì chỉ cần giải quyết vấn đề sống còn của chính mình trước.
Bài học cho anh em làm sản phẩm
Nếu nhìn như một case study nhỏ, có vài điểm đáng ghi lại.
1. Bắt đầu từ rủi ro thật, không phải từ tính năng hay
App này không bắt đầu bằng “mình muốn thử geofence”. Nó bắt đầu bằng “mình không muốn bị đẩy vào lại một khu vực nguy hiểm mà không biết trước”.
Đây là thứ làm sản phẩm sắc hơn. Khi pain đủ thật, scope tự nhiên nhỏ lại.
2. Tool thô nhưng đúng điểm chạm vẫn có giá trị
Accessibility, OCR, geocoding nghe giống một chuỗi workaround hơn là kiến trúc đẹp. Nhưng với một app phụ trợ cá nhân, workaround có thể là con đường nhanh nhất để chứng minh giá trị.
Quan trọng là biết ranh giới: dùng được cho beta, dùng được để học, nhưng nếu mở rộng cho nhiều tài xế thì phải kiểm tra độ chính xác, quyền riêng tư, điều khoản nền tảng và trách nhiệm pháp lý.
3. AI coding phù hợp với “micro-SaaS theo nghề”
Mình nghĩ đây là hướng đáng theo dõi: những công cụ rất nhỏ, phục vụ một nghề rất cụ thể, do chính người trong nghề mô tả và lắp ráp bằng AI.
Ví dụ:
- tài xế cần cảnh báo vùng rủi ro;
- nhân viên sales cần tóm tắt CRM theo kiểu riêng;
- chủ shop cần kiểm tra đơn bất thường;
- kế toán cần rà lỗi file Excel theo quy trình nội bộ.
Các bài toán này đôi khi quá nhỏ hoặc quá đặc thù để startup lớn nhảy vào, nhưng lại đủ đau để người dùng tự trả tiền hoặc tự dùng hằng ngày.
Checklist nếu anh em muốn làm app kiểu này
Trước khi biến một pain thật thành app, thử trả lời nhanh 6 câu:
- Khoảnh khắc quyết định nằm ở đâu trong workflow?
- Người dùng cần biết điều gì trước khi bấm nút tiếp theo?
- Dữ liệu có thể lấy hợp pháp và ổn định từ đâu?
- Nếu app cảnh báo sai thì hậu quả là gì?
- Có cần lưu dữ liệu nhạy cảm không, hay xử lý cục bộ là đủ?
- Phiên bản đầu tiên có thể giúp một người dùng thật trong 24-48 giờ không?
Nếu trả lời được, AI coding có thể giúp rút ngắn đáng kể đoạn từ ý tưởng đến bản dùng thử.
Góc nhìn thực tế
Mình không xem case này như bằng chứng rằng vibe coding thay thế được product team chuyên nghiệp. Nhưng nó là một tín hiệu mạnh: người có vấn đề thật, hiểu ngữ cảnh thật, giờ có thể tự tạo phần mềm phòng thân nhanh hơn trước rất nhiều.
Và đôi khi, sản phẩm đáng giá nhất không phải là thứ “scale” ngay từ đầu. Nó là thứ giúp một người bước vào ca làm tiếp theo với nhiều quyền kiểm soát hơn một chút.
Top comments (0)