- Các cuộc thảo luận hiện tại về LLM đang diễn ra mà không có cơ sở định lượng rõ ràng
- Trải nghiệm của từng người dùng là rất rời rạc, và hầu như không chia sẻ các yếu tố cốt lõi như môi trường sử dụng thực tế hay kiến thức nền
- Do tính phi xác định, cùng một tác vụ cũng có thể cho ra kết quả khác nhau theo từng thời điểm, nên độ tin cậy bị giới hạn
- Những tuyên bố phóng đại từ các lãnh đạo trong ngành đang thúc đẩy việc chấp nhận thiếu phê phán và kỳ vọng quá mức
- Trên thực tế, tác giả cũng sử dụng nhiều công cụ AI hằng ngày và chia sẻ trải nghiệm rằng chỉ khoảng một nửa số lần mới đạt được kết quả mong muốn
Góc nhìn về tranh luận và công nghệ xoay quanh LLM
Phê bình LLM và bầu không khí tranh luận
- Trong các cuộc tranh luận gần đây về AI, đặc biệt là LLM (mô hình ngôn ngữ lớn), đang hình thành bầu không khí mà các quan điểm phê bình thường bị hạ thấp thành “ý kiến của những người không thực sự hiểu công nghệ”
- Trên Hacker News và các nơi tương tự, liên tục xuất hiện phản ứng kiểu “chỉ cần hỏi AI là đủ”, xem sự hoài nghi là biểu hiện của thiếu hiểu biết về bản chất vấn đề
Khoảng cách trải nghiệm giữa người dùng
- Về tính hữu ích thực tế của LLM, có sự khác biệt rõ giữa những người cho rằng “nó cũng giúp được phần nào” và những người nói rằng “đã thử mọi cách nhưng hầu như vô dụng”
- Lý do tạo ra khác biệt này là không có tiêu chí và thông tin cụ thể về trải nghiệm được chia sẻ
- Đã dùng trong dự án nào
- Tình trạng của codebase (dự án mới, mã đã trưởng thành, mã nguồn riêng tư, v.v.)
- Mức độ chuyên môn của người dùng, và chuyên môn đó gắn với vấn đề thực tế đến đâu
- Cần thêm bao nhiêu công sức để tinh chỉnh và triển khai kết quả do LLM tạo ra một cách đúng nghĩa
Khó khăn trong việc so sánh trải nghiệm và tính phi xác định
- Ngay cả khi một người dùng chia sẻ toàn bộ thông tin thật chi tiết, việc so sánh trải nghiệm với người dùng khác vẫn gần như là bất khả thi
- LLM và các tác nhân tự động hóa về bản chất đều phi xác định
- Ngay cả khi đưa ra cùng một yêu cầu cho cùng một vấn đề theo cùng một cách, mỗi lần vẫn nhận được kết quả khác nhau
- Loại dự án, mô hình sử dụng, công cụ, ngôn ngữ và nhiều yếu tố biến đổi khác khiến việc kiểm chứng nhất quán trở nên khó khăn
Lãnh đạo ngành và kỳ vọng bị thổi phồng
- Có nhiều trường hợp các lãnh đạo trong ngành nhấn mạnh quá mức thành quả của LLM
- Ví dụ: một lãnh đạo trong ngành chia sẻ rằng dùng "Claude Code" để sửa một lỗi cũ dễ đến ngạc nhiên, và nhận được sự hưởng ứng rộng rãi dù không cung cấp chi tiết cụ thể
- Các thông tin cốt lõi bị lược bỏ, như quy mô mã nguồn, độ khó của lỗi, có cần thêm lao động bổ sung hay không, ngôn ngữ lập trình và framework đã dùng
- Những trường hợp như vậy ghi nhận hơn 1,8 nghìn lượt hưởng ứng và 204 lượt chia sẻ lại, cho thấy kiểu tiếp thị cường điệu có thể lan rất nhanh
Trải nghiệm sử dụng và nhận thức thực tế
- Tác giả cũng sử dụng hằng ngày nhiều công cụ AI như v0 của Vercel, Claude Code, Midjourney
- Tạo ứng dụng giám sát bằng SwiftUI dù không có kiến thức về Swift
- Tự động tạo poster cho sự kiện bằng Midjourney
- Viết hàm máy chủ MCP dựa trên Elixir
- Tuy vậy, xác suất thành công chỉ vào khoảng 50%, và kết quả đầu ra không bao giờ nhất quán hoàn toàn
- Đôi khi LLM thực sự tạo cảm giác như phép màu, nhưng trên thực tế nó chỉ là một mô hình thống kê phi xác định
- Trong bối cảnh đó, tác giả chỉ ra rằng thảo luận trong ngành vẫn chỉ dừng ở thế lưỡng phân (phép màu vs. kỹ thuật)
Kết luận
- Thực tế xoay quanh LLM và AI có xu hướng ưu ái những tưởng tượng, kỳ vọng và niềm tin bị thổi phồng dù thiếu hệ thống kiểm chứng chắc chắn và rõ ràng
- Điều quan trọng là không ngừng tư duy phản biện và nỗ lực kiểm chứng chi tiết chức năng cũng như hiệu quả thực tế
- Điều cốt yếu trong thảo luận là chia sẻ thông tin cụ thể và có tính định lượng
- Cần một góc nhìn cân bằng về cả giới hạn lẫn tiềm năng của LLM
1 bình luận
Ý kiến trên Hacker News
Tôi thấy bức bối khi ban lãnh đạo ở nơi tôi làm việc nghe nói về mức tăng năng suất gấp 10 lần. Thậm chí một số người còn nghe trực tiếp những điều đó từ những người tiên phong áp dụng trong công ty tôi. Nhưng kỳ vọng như vậy là quá cao. Định luật Amdahl cũng góp phần ở đây, vì phần lớn thời gian của tôi không phải để code mà là để suy nghĩ và giao tiếp. Ngay cả nếu việc code thực sự nhanh hơn 10 lần đi nữa (mà trong đa số trường hợp là không), thì năng suất tổng thể cũng chỉ tăng khoảng 10~15%. Dù vậy đây vẫn là kết quả khá tốt, chỉ là không phải 10 lần
Có lẽ vì công việc hiện tại của tôi mang tính R&D hơn, nên LLM cũng đem lại lợi ích lớn cho phần “suy nghĩ” gần ngang với phần “code” (còn giao tiếp thì tôi tự xử khá ổn). Làm công việc tư duy với LLM cho tôi cảm giác giống như thời làm chủ việc tìm kiếm trên web 20 năm trước. Trước đây, với công cụ tìm kiếm, tôi phải biết mình cần tìm gì, còn giờ LLM giúp tôi tìm ra cả việc cần phải tìm cái gì trước đã (và còn tìm thay luôn). Những việc trước kia tôi xếp vào loại khó thì giờ nhờ LLM mà xử lý dễ dàng. Hiện tại khoảng 1/3 việc tìm kiếm web của tôi là bằng ChatGPT o3. Giờ bảo bỏ cái này đi thì tôi không thể tưởng tượng nổi. Thêm nữa, LLM còn có yếu tố tâm lý rất lớn khi nó giúp sắp xếp những ý nghĩ còn dang dở của tôi và đóng vai đối tượng để thảo luận. Nhờ đó nhiều việc bớt đáng sợ hơn hẳn, và sự khác biệt đó cũng rất lớn
Ở công ty tôi tình hình cũng tương tự. Những mức tăng năng suất mà các nhóm áp dụng sớm trong nội bộ đưa ra thường được đo theo cách rất hẹp, hoặc bản thân phép tính đã khá lỏng lẻo
Có thể LLM còn tăng tốc cho senior nhiều hơn junior (vì junior không phân biệt tốt code tốt/xấu). Một senior dùng workflow LLM được cải thiện có thể đạt năng suất tương đương mười junior trước đây. Thậm chí với lập trình viên kém thì năng suất thực tế có thể thành số âm (vì làm mất thời gian của senior). Ngay cả junior khá ổn thì cũng bị đẩy vào các việc lặp lại mà LLM đã làm tốt hơn rồi. Vì vậy tôi thuộc phe cho rằng công việc thực sự có thể biến mất
Nếu dùng công cụ LLM mà năng suất chỉ tăng 10~15%, trong khi chi phí tuyển dụng lại tăng thêm 10~15% vì tiền công cụ LLM, thì tôi không thấy có lợi thế gì đặc biệt. Theo tôi phải tính đến tổng chi phí sản xuất
Với dự án cá nhân thì dễ tăng tốc gần 10 lần. Nhưng trong công ty thì môi trường đó không phù hợp vì còn phải bàn với nhiều team, thay đổi yêu cầu, review PR, v.v. Kiểu thiết kế tối ưu và các pattern tiêu chuẩn như vậy chỉ khả thi ở startup nhỏ hoặc dự án solo. Chỉ cần nhiều người tham gia là bản thân việc đạt đồng thuận đã khó rồi. Để AI đạt hiệu quả cao nhất thì mọi thứ phải được chuẩn hóa, nhưng thực tế mọi thứ đều lệch nhau một chút nên rất khó đạt hiệu quả như vậy trong tổ chức thật. Nếu chỉ có một nhóm nhỏ các lập trình viên cùng chí hướng hợp tác với nhau thì 10 lần có thể xảy ra, nhưng trong môi trường doanh nghiệp thì gần như bất khả thi. Tôi nghĩ AI hợp hơn với middle management và lập kế hoạch dự án
Người bị bài viết chê trách chính là tôi đây. Tôi đã ra mắt một sản phẩm greenfield vào thời ChatGPT còn khá kém. Sau đó tôi dùng Claude rồi copy-paste giữa web chat và XCode, rồi tiếp đến là Cursor. Lỗi build thì vẫn hay xảy ra, nhưng dù vậy năng suất của tôi ít nhất cũng tăng gấp 3. Giờ thì agent đã tốt hơn và Claude 4 cũng ra rồi, nên tôi gần như không code nữa. Tôi làm vai Architect/Manager, dùng chuyên môn của mình để chỉ đạo agent cho tốt. Tôi đã không tự viết lấy một dòng code nào trong startup suốt mấy tháng nay. Trước khi tự mở PR thì tôi kiểm tra toàn bộ và test rất kỹ, nhưng tổ hợp Cursor+Sonnet là quá điên. Số dòng code chẳng quan trọng, ngược lại các chuyên gia lâu năm của codebase hiện tại còn hỏi tôi về mấy bug lặt vặt. Nhờ Claude mà tôi còn đụng vào cả việc của frontend developer nên cũng đang cố thận trọng. Tôi không chỉ ném truy vấn đơn giản, mà bắt nó đi qua quá trình nghiên cứu kỹ lưỡng, lập kế hoạch, khám phá theo từng bước. Kiến thức domain là bắt buộc. Dù vậy tôi vẫn thấy lạ khi có người không tận dụng được nó đến mức này. Cảm giác như tuần nào tôi cũng thấy hai bài như vậy
Tôi cũng có trải nghiệm tương tự nhưng trong bối cảnh hơi khác (nghiên cứu sinh PhD). Tôi từng hoài nghi LLM, nhưng từ sau Claude Code thì cách tôi làm việc thay đổi hoàn toàn. Dù vậy việc tuyển chọn vẫn hoàn toàn là phần việc của tôi (vừa là soft skill quan trọng phải học trong chương trình PhD, vừa vì LLM nhanh chóng mất mục tiêu hoặc ngữ cảnh và không nhớ được). Nếu có thể giao tiếp chính xác, thì với CC tôi có thể tổ chức việc tính toán theo cách mà trước đây là không thể. Không phải lập trình trở nên dễ hơn, mà là một hình thức hoàn toàn khác đã xuất hiện
Tôi tò mò về quy trình xác minh/kiểm tra thực tế, như cách bạn kiểm tra nhanh phần code không đáng tin do LLM tạo ra, hay LLM có viết cả unit test không, độ dài prompt trung bình là bao nhiêu
Có ý kiến chỉ ra rằng bạn không thể tin ngay đầu ra của LLM. Nó không nắm được toàn bộ ngữ cảnh dự án, và nói bậy (hallucination) rất nhiều, nên vẫn cần xác minh
Tôi cảm thấy chất lượng code của LLM nhìn chung còn thiếu hụt khá nhiều. Phải sửa đi sửa lại nhiều lần nên lắm khi tự viết còn nhanh hơn. Nhưng với những đợt refactor mang tính cơ học quy mô lớn thì agent cực kỳ hữu ích. Tôi dùng agent thay vì viết vim macro phức tạp hay script AST
Nghe nói mấy tháng không tự viết một dòng code nào thì cá nhân tôi thấy chắc chán lắm
Bình luận này chỉ đang xác nhận lại đúng những gì bài blog đã nói (không thể kiểm chứng, tuyên bố thành quả khổng lồ, v.v.). Có vẻ tài khoản cũng mới tạo
Theo tôi, phần lớn lao động thực tế trong ngành dịch vụ là các việc thủ công như chuyển dữ liệu giữa bảng Excel, hay từ CRM/email sang Excel. Ở các tập đoàn lớn, số nhân viên toàn thời gian làm những việc lặp lại kiểu này có lẽ nhiều gấp khoảng một trăm lần kỹ sư phần mềm. Vì vậy việc LLM không làm được OCaml cũng chẳng quan trọng; chỉ cần nó làm Excel nhỉnh hơn con người một chút là đã tạo ra giá trị khổng lồ. Nếu dùng thứ như MCP để nối email-CRM-Excel rồi tự động hóa, thì tỷ lệ lỗi hay hallucination cũng giảm mạnh. Con người cũng không có tính xác định, nên với những quy trình này tính quyết định không phải thứ quan trọng. LLM và crypto hoàn toàn khác nhau về utility hay mức độ áp dụng. Nó làm tôi nhớ đến thời smartphone phổ cập. Ngay cả bạn bè không làm kỹ thuật của tôi giờ cũng dùng LLM cho rất nhiều mục đích khác nhau
Tôi nghĩ so sánh với crypto không mang tính xây dựng. Về mặt kỹ thuật thì chẳng liên quan gì nhau. Dù vậy đúng là có hiện tượng quá tin vào công nghệ. Với những người đến giờ còn chưa đụng đến tự động hóa cơ bản, LLM có thể trông như khoa học viễn tưởng. Trước đây chưa từng có lĩnh vực nào trở nên mainstream đến mức này. Từ giờ có lẽ sẽ là một miền Viễn Tây nơi thành công và thất bại, nhiều quan điểm khác nhau và kinh nghiệm thực chiến cùng tồn tại. Điều hay là giờ ngay cả ý tưởng app của một người bạn cũng có thể tự đem ra thử nghiệm được
Ngay cả những FTE (Full-time Employee) làm việc dọn dữ liệu thủ công cũng còn phải xác minh kết quả, đảm bảo đúng hạn và chịu trách nhiệm pháp lý. LLM không thể tự hiểu những ngoại lệ tạm thời (ví dụ, do ngày nghỉ nên giá trị phải là 0) ngoài ngữ cảnh để kiểm tra. Chỉ riêng việc xác minh đó đã đủ đáng để dùng một FTE rồi
Tôi muốn biết chuyện 100 FTE làm data pipelining thủ công cho mỗi 1 kỹ sư phần mềm thì chỉ đúng với kiểu công ty nào. Tôi không cho rằng phần lớn công việc thật sự là back-office/data entry. Tôi đồng ý AI có sức ảnh hưởng lớn, nhưng hoài nghi với nhận định rằng gần như toàn bộ giới white-collar chỉ là lực lượng email + nhập liệu
Tôi nghĩ bạn đang đánh giá thấp độ phức tạp của những loại công việc này
Là một lập trình viên đã nghỉ hưu, tôi không thể tưởng tượng được việc giao trách nhiệm mission-critical cho đoạn code được sinh ra theo xác suất. Nếu chỉ là thứ có vẻ dùng được sau vài chỉnh sửa nhỏ thì tôi còn hiểu được. Ở các lĩnh vực ngoài coding (brainstorming, tư duy sáng tạo, hỗ trợ nghiên cứu), LLM thật sự ấn tượng. Tôi xem LLM như một đối tác tư duy. Nó vẫn mắc lỗi, nhưng khá dễ phát hiện nếu kiểm chứng bằng nguồn khác hoặc nhờ một LLM khác rà lại
Tôi cũng vốn là kiểu người hoài nghi vô điều kiện, nhưng sau khi thực sự dùng thử thì nó vượt xa kỳ vọng của tôi trên mọi phương diện. Chỉ trong vài giờ tôi đã đẩy tiến độ từ prototype đến launch cho những dự án vốn phải mất vài tháng. Những việc tôi làm được thì nhanh hơn, còn những việc tôi không làm được (đáng lẽ phải thuê ngoài hoặc tuyển người) thì giờ cũng xử lý được với chi phí nhỏ và tốc độ cao. Dĩ nhiên nó không hoàn hảo và có nhiều điểm gây bực mình (phớt lờ chỉ dẫn rõ ràng, nói dối, v.v.), nhưng với tôi đây là game changer
Có lúc tôi thấy dùng LLM như đối tác tư duy khá ổn, nhưng rồi đến một điểm thì tính hoang tưởng của nó lộ ra. LLM rất giỏi khiến người ta lầm tưởng rằng nó đang có tri thức hay suy luận. Đặc biệt ở lĩnh vực tôi không biết thì còn nguy hiểm hơn. Với công cụ tìm kiếm, tôi có thể so độ tin cậy của nguồn, còn LLM thì không làm được vậy. Việc bắt lỗi cũng không phải lúc nào dễ
Tôi là dev 40 năm kinh nghiệm và mới bắt đầu dùng LLM từ vài tháng trước, nhưng cách làm việc đã thay đổi lớn. Dán lỗi log vào là trong 1 phút đã có cách sửa, brainstorming thiết kế, đề xuất giải pháp mới, v.v. Tôi vẫn kiểm tra code, nhưng ngày nào cũng ngạc nhiên với độ chính xác và sự thông minh của nó. (Hoàn toàn không giống crypto)
Tôi thuộc phe hoài nghi LLM, nhưng thật ra mọi đoạn code do con người viết về bản chất cũng đều mang tính xác suất. Vì thế mới có code review, unit test, pair programming, guideline, v.v. Không nên dùng đầu ra của LLM hay của con người một cách thiếu phản biện. Chỉ là tôi lo LLM không phải phép màu, và ngoài phần hữu ích của nó, nó có thể bị lạm dụng để chỉ tăng thêm boilerplate trong khi bỏ qua những giá trị dài hạn như hiệu quả, độ an toàn hay khả năng refactor
Theo tôi, thứ LLM làm tốt nhất là data science. IO rõ ràng nên dễ xác minh kết quả. Nếu biết đặc tính của bộ dữ liệu cụ thể thì cũng dễ bảo nó tạo test code. Khi cần ngữ cảnh, Claude Code tạo ra khác biệt rất lớn. Ví dụ như trích xuất nhiều message trong từng gói UDP từ file PCAP, lọc, pattern matching, tách ra để test, v.v. Chỉ cần nói “hãy viết unit test cho tất cả các hàm này” là LLM còn có thể tự xác minh nữa
Tôi đã dùng LLM gần như mỗi ngày từ một năm nay, và 90% thời gian nó giải quyết được vấn đề cho tôi. Tôi không biết đến khi nào thì những ý kiến tiêu cực về AI/LLM mới cần được coi là nghiêm túc. Theo kinh nghiệm của tôi, tôi chưa bao giờ nạp cả codebase vào rồi chờ phép màu; tôi chỉ đặt những câu hỏi chính xác và cụ thể mà bản thân biết rõ/hiểu rõ, rồi áp dụng lời giải theo cách có thể kiểm chứng được. Nếu không dùng theo cách đó thì là đang dùng LLM sai. Muốn thực sự cảm nhận được phép màu, chìa khóa là sử dụng nhỏ, thường nhật và nhất quán
Châm biếm kiểu parody Weatherman rằng “nó luôn hoạt động với xác suất 60%”. Tôi cũng dùng GPT và Claude qua Cursor mỗi ngày. GPT o3 tốt cho tra cứu kiến thức phổ thông, còn Claude đôi khi thất bại. Bản thân model khá ngốc nhưng thỉnh thoảng vẫn chạm đúng trọng tâm. Tôi nghĩ nếu tự biết mình muốn gì và biết thuần hóa LLM thì có thể dùng nó hiệu quả
Có ý kiến cho rằng cũng khó tin với tuyên bố kiểu “theo trải nghiệm của tôi thì 90% là ổn”
Có vẻ tác giả bài viết bực tức trước những lời bình thiếu chính xác của các cây bút tranh luận. Thực ra tôi nghĩ chính những người dùng hằng ngày, cũng là người cổ vũ, mới hiểu rất rõ vấn đề và giới hạn của LLM vì họ va chạm với chúng mỗi ngày. Những bài toán vốn không thể hoặc gần như không thể như dịch thuật, chép lời, sinh code (đến một quy mô nhất định) nay đã được giải quyết hoàn toàn hoặc gần như hoàn toàn
Dịch thuật, chép lời, sinh code thật sự từng gần như không thể sao? Google Translate, Whisper đã tồn tại từ lâu, có người chỉ ra như vậy
Người phơi bày lỗi thực tế là detractor (người chỉ trích), còn promoter (người tung hô) mới là phía tâng bốc LLM như thể nó toàn năng mà không phê phán
Gần đây tôi thấy cách dùng từ AGI và AI, nhất là trong các bài báo khoa học, quá mơ hồ. Tôi nghĩ ít nhất mỗi bài báo cũng nên nêu rõ định nghĩa riêng của mình. Nếu định nghĩa AGI được xác định rõ, thì thậm chí còn có thể chứng minh bằng logic rằng một AI cụ thể có đáp ứng định nghĩa đó hay không. Dù có vẻ không hữu dụng trong thực tế, nó vẫn tốt hơn nhiều so với một thuật ngữ vô nghĩa. Hiện tại tôi có cảm giác người ta dùng AGI mà không định nghĩa rồi lảng đi. Trên wiki nó được mô tả là “gần như mọi nhiệm vụ nhận thức ngang hoặc hơn con người”, nhưng điều đó lại không thể đo được. Tôi cứ băn khoăn vì sao lại dùng một thuật ngữ rỗng như vậy
Không nhất thiết mọi người phải dùng nó theo cùng một nghĩa. Bạn chỉ cần có tiêu chuẩn riêng cho từ AGI là được (dù số đông không đồng ý cũng không sao). Với tôi, crypto vốn là cryptography. Tiêu chuẩn của số đông và tiêu chuẩn cá nhân của tôi có thể khác nhau
Nếu AI có một định nghĩa, thì đó là “thứ chưa làm được thì gọi là AI”, kèm liên kết giải thích về AI effect
Gần đây công ty tôi bắt đầu dùng LLM. Việc đầu tiên là chép lời 20.000 cuộc gọi chăm sóc khách hàng và trích xuất dữ liệu (sản phẩm được so sánh, vấn đề gặp phải, use case tiêu biểu, v.v.). Trước đây kiểu nghiên cứu này phải mất vài tuần, còn giờ xong trong vài giờ. Chúng tôi còn xây dựng được cả chiến lược kinh doanh mới và thực sự thu được giá trị lớn. LLM cực kỳ xuất sắc như một công cụ xử lý ngôn ngữ tự nhiên. Đúng là có nhiều quảng bá quá đà, nhưng với chúng tôi nó thật sự hữu ích. Nó chỉ là một công cụ thôi, tôi không thấy cần phải chứng minh với ai cả
Tôi nghĩ việc thổi phồng không hẳn là vô hại. Nó có thể gây méo mó thị trường, đầu tư quá mức, cắt giảm tổ chức, kỳ vọng phi thực tế và nhiều hệ quả tiêu cực khác. Những bài viết như thế này là cần thiết để hạ nhiệt thị trường/kỳ vọng. Những người bán LLM thường không nói về việc tóm tắt cuộc gọi tư vấn, mà nói về đủ mọi kịch bản phóng đại chuyện thay thế nhân sự
Có vẻ chỉ những ai chưa từng trải nghiệm xử lý dữ liệu quy mô lớn theo cách đáng tin cậy mới nói LLM vô dụng. Giờ ngay cả dịch thuật cũng xử lý được ngữ cảnh tốt hơn rất nhiều
Những người đáng tin trong ngành công nghệ cũng trực tiếp nói rằng GenAI giúp ích lớn cho năng suất phát triển phần mềm. Ý nghĩa có thể dao động rất rộng, kiểu từ 5% đến 100%. Nhưng ít nhất nó nên được chấp nhận là một công cụ khá hữu ích. Tôi không nghĩ cần phải có những con số cụ thể như số dòng code, byte hay CPU để đưa ra nhận định như vậy
Công nghệ LLM rồi cũng sẽ có chỗ dùng đúng, nhưng giờ đã có quá nhiều người lạm dụng nên không thể quay lại nữa. Rất nhiều lập trình viên mới vào nghề sẽ chấp nhận rủi ro rồi thất bại, và rất nhiều vốn đầu tư sẽ bị lãng phí. Các công ty cũng không thể bỏ cuộc và đều đã all-in cả rồi