Một người bạn thân của tôi là kỹ sư phần mềm tại một trong những công ty công nghệ lâu đời và lớn nhất thế giới — kiểu công ty luôn nằm trong mọi bộ chữ viết tắt “big tech” mà bạn biết. Họ đã làm việc ở đó gần một thập kỷ, và gần đây đang cố gắng tăng năng suất bằng cách sử dụng một AI coding agent nội bộ.
Khi họ chia sẻ những gì hiệu quả và những hạn chế của công cụ này với team, sự quan tâm nhanh chóng lan rộng trong toàn bộ tổ chức. Cuối cùng, họ đã phải trình bày trước hàng trăm kỹ sư trong công ty.
Nguồn: Gemini
Chúng tôi rất hứng thú khi nghe về trải nghiệm của họ. Dù là kỹ sư tại một công ty có trình độ kỹ thuật hàng đầu thế giới — thậm chí tự xây dựng foundation model riêng — họ vẫn gặp phải sự do dự đáng kể khi áp dụng coding agent.
Một số kỹ sư đơn giản là thích tự viết code — đó là một phần cách họ tư duy về nghề. Một số khác không biết công cụ này phù hợp với workflow của họ như thế nào. Một số đã thử, thấy UX khó hiểu, rồi lặng lẽ bỏ qua mà không đưa phản hồi.
Đây không phải câu chuyện về những người bảo thủ hay chống lại thay đổi. Đây là những kỹ sư rất giỏi tại một công ty hàng đầu — kiểu người mà bạn sẽ muốn phỏng vấn ngay nếu thấy CV của họ.
Thế nhưng với phần lớn họ, AI coding tools vẫn chỉ là thứ “đã nghe qua” chứ chưa thực sự tích hợp vào công việc hàng ngày.
Nếu ở đó còn như vậy, hãy tưởng tượng ở những nơi khác còn khó khăn đến mức nào.
“Bong bóng” nhỏ hơn bạn nghĩ
Nếu bạn đang đọc blog này, gần như chắc chắn bạn đang ở trong “bong bóng AI”. Bạn có thể đã dùng Claude Code hoặc Cursor để build thứ gì đó trong cuối tuần. Bạn chắc chắn đã thấy những bài post LinkedIn nói về việc repo với Claude Code sẽ thay đổi cách làm sales.
Vấn đề là: ở trong bong bóng lâu khiến bạn nhầm tưởng đó là cả thế giới.
Những người hào hứng nhất với AI — chấp nhận sản phẩm còn thô, liên tục thử nghiệm, tự build workflow — chỉ là một phần rất nhỏ trong tổng số người dùng tương lai của bạn.
Quan trọng hơn, sự nhiệt tình đó che đi rất nhiều vấn đề:
Nếu ai đó thực sự thích sản phẩm của bạn, họ sẽ chịu được onboarding rối rắm, bỏ qua UX kém, và tự tìm cách prompt đúng.
Bạn có thể build business ban đầu dựa vào những “true believers” này — và họ thực sự là nhóm người tuyệt vời.
Nhưng sớm hay muộn, bạn phải phục vụ phần còn lại.
Và hiện tại, phần lớn công ty AI chưa làm điều đó.
Khoảng cách này là vấn đề sản phẩm, không phải vấn đề con người
Khi người dùng không muốn adopt, phản xạ tự nhiên là nghĩ rằng họ sẽ thay đổi theo thời gian — rằng sản phẩm không cần thay đổi nếu đã hoạt động tốt với nhóm early adopters.
Nhưng AI khác với các làn sóng công nghệ trước đó — và lý do không chỉ nằm ở UX.
Danh tính người dùng
AI tác động trực tiếp đến danh tính nghề nghiệp của người dùng.
Hãy tưởng tượng một kỹ sư phần mềm đã dành nhiều năm tự hào về chất lượng code của mình. Giờ đây một agent tạo code nhanh gấp 10 lần — nhưng trông “rác” trong mắt họ.
Với nhiều senior engineer, điều này có thể đúng — họ viết tốt hơn nếu tự làm.
Quan trọng hơn, đoạn code đó đi ngược lại cách họ nhìn nhận bản thân.
Họ sẽ không bao giờ merge code đó nếu chưa kiểm tra kỹ — dù bạn có đưa bao nhiêu biểu đồ benchmark đi nữa.
Nhưng mặt còn lại mới là cơ hội sản phẩm:
AI tốt có thể củng cố danh tính người dùng.
Nó không khiến kỹ sư cẩn thận cảm thấy bị thay thế — mà khiến họ trở thành người tiên tiến nhất team.
Nó không khiến PM cảm thấy “ăn gian” — mà khiến họ là người ship prototype nhanh nhất.
Mục tiêu không phải là loại bỏ yếu tố danh tính — mà là nâng cấp nó.
Để làm được điều đó, bạn phải gặp người dùng ở đúng vị trí của họ — và đưa họ tiến dần lên.
Ví dụ rõ nhất là coding agent:
Sự tin tưởng không đến từ agent — mà từ tab completion.
Kỹ sư không bao giờ giao cả function cho AI, nhưng lại rất thoải mái với gợi ý 1–5 dòng.
Hàng nghìn tương tác nhỏ như vậy tạo nền tảng để họ tin tưởng agent.
Không phải ngẫu nhiên mà sản phẩm có adoption agent cao nhất hiện nay cũng là sản phẩm có tab completion tốt nhất từ trước.
Khả năng chọn lọc (editorial judgment)
Nguyên tắc quan trọng: đừng làm người dùng bị quá tải.
AI khiến việc ship feature nhanh hơn — và vì thế dễ “nhồi nhét” quá nhiều thứ.
Một người dùng còn do dự khi mở sản phẩm và thấy hàng loạt tính năng họ không hiểu sẽ không tìm cách học — họ sẽ rời đi.
Ở cấp độ feature cũng vậy:
Nếu người dùng còn đang làm quen với tab completion, việc đưa ngay agent tự động sẽ khiến họ sợ — không phải giúp họ adopt nhanh hơn.
Làm ít hơn, nhưng đúng thời điểm — đó là cách xây dựng niềm tin.
Điều này không chỉ đúng với coding.
Ví dụ: nhiều leader kỹ thuật mới bắt đầu cân nhắc AI SRE — trong khi các vendor đã quảng cáo rằng AI có thể tự động thay đổi hệ thống production khi bạn đang ngủ.
Nghe có vẻ hấp dẫn với người đam mê — nhưng với đa số, đó là điều “điên rồ”.
Hiện tại, phần lớn sản phẩm vẫn chưa tìm được điểm cân bằng này.
Thời điểm trưởng thành của AI
Có một so sánh lịch sử thú vị: cloud computing.
Ban đầu, khách hàng là startup và công ty công nghệ — sẵn sàng tự mò.
AWS năm 2008 rất mạnh nhưng còn thô — và người dùng đủ kỹ thuật để chịu được điều đó.
Sau đó là giai đoạn trưởng thành:
Doanh nghiệp lớn, ngân hàng, healthcare — những người có yêu cầu, rủi ro và tiêu chuẩn khác.
Những nhà cung cấp cloud thành công là những người thay đổi sản phẩm — không chỉ nhanh hơn hay rẻ hơn, mà phù hợp với user mới.
AI đang bước vào giai đoạn tương tự.
Những early adopters — người build app cuối tuần, người nói chuyện trước hàng nghìn kỹ sư — đã đưa ngành đi đến đây.
Nhưng giai đoạn tiếp theo là 50% ở giữa:
Những người tò mò nhưng hoài nghi, sẵn sàng thử nhưng rời đi nhanh, không muốn tự học cách prompt.
Đây mới là nhóm quyết định AI có thực sự tạo ra năng suất hay không.
Điểm đặc biệt là:
Không giống cloud, AI đang nén hai giai đoạn này lại với nhau.
Khoảng cách giữa “tool cho người đam mê” và “tool cho tất cả mọi người” đang thu hẹp nhanh hơn dự đoán.
Với product builder, đây vừa là cơ hội vừa là cảnh báo:
Những công ty vượt qua khoảng cách này sớm sẽ có lợi thế cực lớn so với những công ty vẫn đang build cho “bong bóng”.