- GitHub và Microsoft đã công bố bản xem trước công khai của GitHub Copilot Agent, đồng thời tiến hành thử nghiệm để tác nhân này tự động tạo PR trong kho lưu trữ .NET Runtime
- Tuy nhiên, các PR này lại chứa những chỉnh sửa sơ sài hoặc không cần thiết, khiến người review khổ sở, và người dùng Reddit đang xem đây như một khung cảnh dở khóc dở cười
- Các PR ví dụ:
- PR #115762 – thêm kiểm tra Null một cách không cần thiết vào đoạn mã đã có sẵn kiểm tra trong lời gọi
string.Concat
- PR #115743 – đề xuất refactor một câu lệnh điều kiện không tạo ra bất kỳ ảnh hưởng nào
- PR #115733, PR #115732 và các PR khác cũng trong bối cảnh tương tự
- Tác giả bày tỏ sự mệt mỏi và hoài nghi về việc áp dụng AI, nói rằng: “Nếu đây là tương lai của ngành, tôi sẵn sàng xuống xe”
- Nhưng đồng thời cũng nhấn mạnh rằng “tôi cảm thấy đồng cảm với những nhân viên phải nhận review này”, và nói thêm rằng tình huống này nhiều khả năng là gánh nặng phát sinh từ chỉ đạo triển khai Copilot từ cấp trên
> “schadenfreude (niềm hả hê)” của tôi là hướng tới ban lãnh đạo Microsoft, những người đang thổi phồng cơn sốt AI. Xin hãy tôn trọng các lập trình viên.
> * schadenfreude là từ có nguồn gốc Đức, dịch sát nghĩa là “niềm vui đến từ tổn hại”. Tức là “cảm giác khoái trá kín đáo trước vận rủi của người khác”
Tóm tắt các bình luận chính
1. PR do AI viết thiếu chính xác và không hiểu ngữ cảnh, chỉ lặp đi lặp lại việc 'đoán mò'
- Đề xuất thay đổi mà không hiểu đoạn mã trong PR thực sự đang làm gì
- Sửa lỗi lặp đi lặp lại → mã vẫn sai → lại sửa lỗi khác… thành một vòng lặp vô tận
- Cũng có ý kiến cho rằng quá trình “Tôi đã sửa rồi” → “Vẫn sai” → “Lần này tôi thực sự sửa rồi” giống hệt mẫu hành vi của Junior Dev
2. Với các vấn đề phức tạp, AI lại còn tốn nhiều thời gian hơn
- Có ích cho các chỉnh sửa đơn giản, nhưng vô dụng với những bài toán phức tạp mà người ta thực sự muốn tiết kiệm thời gian
- Cần hiểu bài toán → hiểu Copilot → so sánh → kiểm tra → xử lý thủ công
- Trên thực tế, tự mình giải quyết còn nhanh hơn
3. Chủ nghĩa 'AI làm được tất cả' của lãnh đạo doanh nghiệp đang khiến lập trình viên bị gạt ra ngoài
- Thông điệp “dùng Copilot thì sẽ không bị tụt hậu” đang xa rời thực tế của các lập trình viên làm việc trực tiếp
- Thời gian review PR kéo dài hơn, còn trách nhiệm lại bị đẩy về phía lập trình viên
- Cũng có lo ngại về 'vòng lặp học tập của AI phục vụ AI', nơi AI được huấn luyện bằng mã do Copilot tạo ra rồi tiếp tục làm giảm chất lượng mã
4. AI chỉ đưa ra những câu trả lời ‘sai nhưng đầy tự tin’, chứ không có khả năng khẳng định 'cái này đúng'
- Dù nhận phản hồi rằng mình sai, nó vẫn nói “Đã sửa rồi!” → rồi lại đề xuất một chỉnh sửa còn kỳ quặc hơn
- Nó không đưa ra nhận định kiểu “Đây là đoạn mã ổn, không cần sửa”
- Cũng có ý kiến cho rằng đây có thể là thiết kế nhằm né tránh trách nhiệm pháp lý
5. Việc liên tục bị ép áp dụng AI đang làm trải nghiệm của lập trình viên trở nên kiệt quệ
- Các thử nghiệm áp dụng AI vẫn tiếp diễn vì chỉ đạo của quản lý hoặc đánh giá thành tích
- Các lập trình viên than phiền về cảm giác như mình đã trở thành người trông trẻ cho AI
- Cũng có dự báo bi quan rằng nếu xu hướng này tiếp diễn, “các lập trình viên sẽ kiệt sức vì AI và rời bỏ ngành”
Những câu nổi bật
- “AI giống như một thực tập sinh cứ lặp lại những phỏng đoán sai nhưng vẫn rất chắc chắn về ý kiến của mình”
- “Thay vì tốn thời gian review mã do Copilot tạo ra, tôi thà tự viết lại còn hơn”
- “Đây là trạng thái 'reverse centaurs', nơi lập trình viên đang giúp máy móc”
- Từ do Cory Doctorow sử dụng, nghĩa là “chúng ta không phải con người được máy móc hỗ trợ, mà là con người bị ép phải hỗ trợ máy móc”
- “Copilot giống như việc lập trình viên dán một miếng băng cá nhân cẩu thả, chỉ khác là nó được tự động hóa nên biến thành hàng nghìn miếng băng phiền toái”
- “Có vẻ như mặc định của LLM là: ‘có thể sai, nhưng không hề bất định’”
12 bình luận
Năng suất đã tăng lên khá nhiều với quy trình làm việc bất đồng bộ kiểu ném vấn đề vào rồi nếu câu trả lời sai thì bỏ đi, nhưng như vậy chẳng phải cũng khá giống công cụ tĩnh sao? Nếu xem nó như một công cụ phân tích tĩnh cực kỳ tiến hóa thì đây là một người bạn tốt. Thành thật mà nói, nó phân tích cũng nhanh và biết nhiều hơn cả kỹ sư junior.
Tôi cũng có dùng AI, nhưng nó khá ngốc nên nếu không sửa lại cho đúng thì không thể triển khai cho ra hồn được. Nhìn kiểu vibe coding thì toàn là mã đầy lỗi...
Mỗi lần dùng LLM tôi đều có trải nghiệm như thế này. Những phần nó không làm được thì dù có chỉ ra vô hạn lần, nó vẫn cứ không làm được.
Cuối cùng tôi mệt quá nên lại tự phân tích và sửa trực tiếp. Khi những trải nghiệm như vậy cứ tích lũy dần, thì dù là LLM hay gì đi nữa cũng thấy toàn là rác và chẳng muốn dùng nữa.
Tôi chợt nhớ đến một webtoon nói về việc AI dùng prompt ngược để bắt con người đi code.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Có lẽ đây sẽ tiếp tục là vấn đề xảy ra, trừ khi AI thực sự có thể vừa giải quyết vấn đề vừa học hỏi như con người.
Chỉ cần đáp ứng đúng deadline và yêu cầu thì khi code, việc bạn dùng AI hay thậm chí không dùng IDE mà đầy chất đàn ông chỉ xài mỗi Notepad cũng chẳng mấy quan trọng đâu.
Khi còn nghĩ đây chỉ là công nghệ mới, tôi chỉ nhìn nó với sự tò mò,
nhưng giờ khi các nhà tuyển dụng thực sự tiến hành cắt giảm tuyển dụng và tiền lương vì những công nghệ kiểu này thì đúng là không thấy dễ chịu chút nào..
Có lẽ vì hiện tại vẫn đang là giai đoạn chuyển tiếp nên mới xảy ra nhiều chuyện dở khóc dở cười như vậy.
Về sau có thể sẽ thay đổi theo hướng tốt hơn, cũng có thể cứ tiếp diễn như thế, nên theo dõi xem nó sẽ thay đổi ra sao cũng khá thú vị nữa haha
Tôi đang gắn Gemini vào GitHub để nhận review PR, và đúng là thỉnh thoảng cũng gặp y hệt như vậy.
Ví dụ như ngay ở dòng phía trên đã có kiểm tra
null, nhưng nó vẫn review rằng đang dùng mà không kiểm tranullrồi bảo thêm lại y nguyên dòng ngay phía trên đó.Khi con người làm việc, những kiến thức nền, quy trình làm việc, kết quả kỳ vọng và cả định dạng của chúng mà ta nắm được một cách tự nhiên
không chỉ là không thể viết hết thành prompt, mà ngay cả nếu có thể viết ra đi nữa thì với một AI phức tạp như LLM,
tôi cũng thấy rằng tự động hóa bằng các thuật toán truyền thống từ trước thời deep learning có lẽ sẽ thực tế hơn.
Dùng thử thì đúng là vibe coding và coding agent có những điểm khá tiện, nhưng muốn tiện thì phải viết prompt cực kỳ chặt chẽ, mà ngay từ đầu cũng có nhiều dự án tùy theo tính chất là không hợp. Nếu các chức năng được tách nhỏ gọn gàng như web server kiến trúc MSA thì nó làm việc khá tốt, nhưng khi có nhiều module gắn trong một big monolith và cố sửa logic phức tạp bằng AI thì phải lập kế hoạch task cực kỳ kỹ, gửi prompt thật chuẩn mới được.
Ý kiến trên Hacker News
Chia sẻ sự thú vị của tình huống mọi bình luận đều có dòng "Help improve Copilot by leaving feedback using the or buttons" nhưng thực tế chưa từng thấy phản hồi nào được đính kèm; kinh nghiệm cho thấy khi dùng LLM mà thiết lập system prompt không chuẩn thì chuyện này xảy ra rất thường; ví dụ PR buồn cười nhất là nói sẽ sửa lỗi test thất bại nhưng lại xóa hẳn test case, comment chúng đi hoặc đơn giản là đổi assertion; phỏng đoán rằng các mô hình của Google và Microsoft dường như gặp kiểu tình huống này thường hơn OpenAI hay Anthropic, và có vẻ khác biệt trong quy trình nội bộ của từng công ty đã phản ánh vào kết quả; giới thiệu quá trình trong một PR thực tế nơi con người phải nhắc thêm 3 lần rồi bỏ cuộc; khó mà tưởng tượng nổi tâm trạng của những người phải review các PR như vậy, giống như đối phó với một lập trình viên mới không chịu nghe lời nhưng lại là một thực thể hoàn toàn không hiểu ngữ cảnh; có ví dụ một PR mà 90% nội dung là "Check failure" nên gần như không thể xem code/diff, và nỗi buồn khi trong unit test chỉ ghi đúng câu "Test expressions mentioned in the issue"; ý kiến thẳng thắn rằng nếu phía con người không phải chịu đựng đau đớn đến thế thì đây thực sự là một chuyện rất buồn cười
So sánh với lập trình viên mới là quá cường điệu; bản thân tôi cũng làm việc với người mới nhưng họ không thường xuyên mắc lỗi kỳ quặc như LLM, cũng không đòi hỏi quá nhiều công sức, và học rất nhanh; LLM là công cụ phụ trợ khá ổn nếu dùng cẩn thận, có thể giúp cải thiện tốc độ và cũng ổn như một đối tác brainstorm ý tưởng, nhưng không thể thay thế intern hay lập trình viên thực thụ
Khi mới bước vào ngành software engineering vào cuối thập niên 80 thì còn có niềm vui, nhưng giờ đây môi trường đã trở nên đầy độc hại với quy trình phỏng vấn, việc công ty vừa và nhỏ bắt chước big tech, và giờ là các thử nghiệm AI PR; cảm giác hoài nghi liệu ngày nay công việc của một lập trình viên chuyên nghiệp còn lại bao nhiêu niềm vui
Ít nhất với lập trình viên mới thì còn có thể bảo họ chạy test local trước khi gửi PR; lo ngại rằng đến một lúc nào đó lập trình viên con người sẽ đơn giản bỏ cuộc và đóng các PR "rác AI", chỉ giữ lại thứ nào thật sự hoạt động còn lại bỏ hết; cảm giác rằng nếu cứ tiếp tục chịu đựng các thí nghiệm của máy móc thì sẽ đến ngày mọi người mệt mỏi và bỏ hẳn
Nghi ngờ việc có cần hẳn một hệ thống feedback như vậy không; theo góc nhìn phát triển, thành công là PR được merge ngay lần đầu, thất bại là mức độ xấu đi tích lũy theo số lượng sửa đổi mà agent yêu cầu; yêu cầu feedback thủ công là kém hiệu quả, tốt hơn nên đo hiệu suất bằng các chỉ số như cycle time, approval rate, change failure rate giống hệt cách đánh giá lập trình viên
Chia sẻ trải nghiệm từng có cảm giác như đang nói chuyện với bức tường khi liên hệ đội hỗ trợ của Microsoft; dù gửi nhiều case vẫn chưa từng được giải quyết thỏa đáng; hiểu việc Microsoft tự dùng công nghệ của mình, nhưng xin đừng ép điều đó lên tôi; mong Microsoft đừng phát hành sản phẩm khi chưa sẵn sàng hỗ trợ
Chia sẻ trải nghiệm gần đây xem video Eric của Google nói về AI; ông cho rằng AI hiện đang bị đánh giá thấp; trích dẫn việc ông nhấn mạnh mình "không phải chuyên gia" trong quá trình dùng AI để lao vào các lĩnh vực không chuyên như lý do mua công ty tên lửa và Deep Research; bản thân tôi cũng không ghét AI, nhưng generative AI hiện tại dựa trên khôi phục mẫu có năng lực rất giỏi trong việc khiến người mới trầm trồ; nếu không có kiến thức về lĩnh vực đó thì kết quả trông rất ấn tượng, nhưng khi hiểu sâu hơn sẽ nhanh chóng thất vọng vì các lỗ hổng; những người làm ở tuyến đầu như tại Microsoft biết rất rõ vấn đề là gì, còn lãnh đạo cấp cao, đặc biệt là người như Eric, lại có nhược điểm là dễ bị AI đánh lừa chỉ bằng những lời lẽ hoa mỹ; vẫn hy vọng rồi sẽ đến ngày AI có thể trực tiếp viết ra code hoạt động đúng, nhưng hiện tại thì ngày đó còn xa
Cách dùng AI của tôi là chỉ dùng rất cẩn trọng và trong phạm vi cực kỳ hạn chế; trong khi đó những tỷ phú kiểu "mua công ty tên lửa" kia lại phát cuồng vì AI và còn dùng nó cho các quyết định đầu tư để tiếp tục phình to tài sản; kể cả có thất bại lớn thì thứ họ mất chỉ ở mức vài món phụ kiện nên sẽ không ảnh hưởng gì đến biến động xã hội; trong khi đó việc làm IT ở tuyến đầu lại có nguy cơ dẫn tới kết cục xấu theo cả hai hướng
Hãy tưởng tượng chuyện gì sẽ xảy ra nếu, cùng với tình huống các lãnh đạo không phải chuyên gia dễ dàng trầm trồ trước AI, Google hợp tác với quân đội Mỹ để gắn Gemini lên một đội drone tự hành quy mô lớn
Khó hiểu việc chứng kiến nhân viên Microsoft dành hàng giờ cãi nhau với LLM thay vì giải quyết vấn đề thực sự thì mang lại cảm giác yên tâm gì cho các công ty đã xây sản phẩm trên .NET
Trước đây, ngay cả trước khi đưa LLM vào, cũng từng thấy trên GitHub issue cảnh người dùng không mô tả được vấn đề cho ra hồn còn maintainer thì ngày càng bực bội; giờ thì thậm chí không cần cả người dùng cuối bực bội nữa
Trái lại, những kết quả như vậy mới chính là hệ quả tự nhiên của quản lý tồi và chỉ thị cẩu thả; lần này không còn có thể đổ lỗi cho người mới nữa, chỉ còn có thể tự trách mình
Đặc biệt nhấn mạnh cảm giác đau lòng khi ngay cả Stephen Toub, người nổi tiếng với blog về hiệu năng .net, cũng tham gia vào quá trình này
Không muốn ngăn cản việc thử nghiệm công nghệ mới, chỉ là điểm khác biệt ở đây là hiện tại toàn bộ thử nghiệm ấy đang bị phơi bày ra cho mọi người cùng thấy
Lập luận đầy mỉa mai rằng Microsoft từ xưa đã có văn hóa hễ có vấn đề là đẩy sang kiểu "cứ bỏ qua lỗi đi" bằng Will Not Fix để các quản lý tự thỏa mãn, nên rốt cuộc đã tự chuốc lấy tất cả những gì đang xảy ra bây giờ
Giải thích ngữ cảnh qua bình luận đầu tiên trong PR: họ đang tìm hiểu giới hạn của công cụ thông qua nhiều thử nghiệm khác nhau để chuẩn bị cho tương lai, và trách nhiệm merge vẫn thuộc về maintainer giống như với các PR bình thường; sẽ không có gì được merge cho đến khi đáp ứng tiêu chuẩn chất lượng
Nhân viên Microsoft viết bình luận đó cũng nêu ý kiến rằng nếu không suy nghĩ về việc dùng AI thì sẽ bị tụt hậu; bầu không khí tại Microsoft dường như vừa lo lắng vừa phấn khích trước khả năng AI làm đảo lộn ngành software engineering; việc này bị đọc thành tham gia cho có chỉ để giữ việc chứ không hẳn là thử nghiệm hợp lý nhằm hiểu giới hạn công cụ, nên càng làm giảm niềm tin
Cần hiểu rằng các quản lý chưa hẳn đã kết luận xong về năng lực của mô hình, mà đây có thể là thử nghiệm hợp lý để nắm được điểm mạnh và điểm yếu trong ngữ cảnh thực tế
Ngay việc assign một PR chưa qua được CI cho ai đó đã là điều kỳ lạ; tối thiểu phải chỉ assign các PR đã pass, nhưng hệ thống có vẻ hỗn loạn đến mức ngay cả chuyện đó cũng không làm được; sự mỉa mai rằng nếu vận hành tử tế thì mức đó phải là tối thiểu
Mong mọi người đừng diễn giải mọi tình huống theo kịch bản tệ nhất; thực tế những con người liên quan có lẽ đều biết đây là thử nghiệm và đã điều chỉnh kỳ vọng; nếu không có các cách tiếp cận thử nghiệm như vậy thì hệ thống khó phát triển, nên cũng có thể họ đang tuning và test trong môi trường thực; công ty tôi cũng từng làm y như vậy ở giai đoạn đầu triển khai công cụ hỗ trợ lập trình bằng AI, và dù chất lượng code tệ hơn so với khi con người tự viết, chúng tôi vẫn học được rất nhiều điều mới từ quá trình đó, đồng thời có baseline để thấy rõ xu hướng cải thiện
Trong phần bình luận có giải thích rằng do vấn đề firewall nên chưa kiểm tra được việc pass test, và chỉ cần xử lý xong vấn đề đó là có thể hoạt động bình thường
Dù thay AI agent bằng công nghệ mới nào khác thì đây vẫn là hình ảnh điển hình của một công ty: thử nghiệm công khai (dogfooding kiểu big tech), thực sự góp phần vào sự tiến bộ năng lực kỹ thuật của ngành, và nếu có vấn đề phát sinh thì thiệt hại hoàn toàn bị giới hạn trong nội bộ đội ngũ; đặt câu hỏi rằng thực ra chẳng có lý do gì để không ủng hộ những thử nghiệm như vậy
Khó hiểu bầu không khí ai cũng chỉ trích những thử nghiệm mở như thế; việc không giấu trong private fork mà công khai minh bạch năng lực thực tế như vậy có ích hơn nhiều và tốt hơn những lời khoa trương của sales marketing
Việc làm các thử nghiệm như vậy trên framework hạ tầng cốt lõi của phát triển phần mềm thì vẫn có thể gây tranh cãi
Nghi ngờ chuyện "chúng ta" vì sao, bằng cách nào, và nên ủng hộ/không ủng hộ cái gì; cá nhân tôi chỉ thấy cảnh MS thất bại ầm ĩ như vậy khá buồn cười
Khó mà xem đây là "tiến bộ" thực sự; việc để lộ vấn đề hệ thống ra bên ngoài mà không có POC nội bộ trước lại càng vô trách nhiệm; đặt câu hỏi vì sao không kiểm chứng trước môi trường nền tảng như firewall hay thử trên codebase nội bộ khác; code hạ tầng cần tiêu chuẩn rất cao, nên dù lấy danh nghĩa dogfooding thì cũng nên bắt đầu từ project cấp thấp hơn; phê phán rằng đây thậm chí còn chưa phải "state of the art" và kết quả quá thô sơ so với chi phí bỏ vào
Làm những thử nghiệm như vậy trên một project phổ biến mà vô số lập trình viên phụ thuộc vào là có vấn đề; lo ngại chất lượng suy giảm vì code tệ do AI tạo ra, mã vô dụng tích tụ hoặc chỉ bào mòn năng suất của các thành viên trong nhóm
Nếu đã là sự phục tùng thụ động với một điều gì đó thì cứ việc approve hết mọi yêu cầu không cần review, rồi khi tech stack của Microsoft sụp đổ trên toàn cầu thì nghỉ việc và đi làm consultant với mức lương gấp 3 lần là xong, một đề xuất đầy mỉa mai
Tôi không muốn làm việc với kiểu mỉa mai như vậy; không hiểu nổi khung đối đầu "chúng ta với họ" mang tính thù địch với ban lãnh đạo công ty, hay cách tiếp cận kiểu cố tình phá cho hỏng; việc phàn nàn về sự bất toàn không có nghĩa là sẽ cản trở hay tấn công cả tổ chức, điều đó không phù hợp với lương tâm của tôi
Phản ứng mỉa mai rằng thật ra tech stack của Microsoft vốn dĩ cũng đang hỏng rồi(?)
Chỉ ra rằng trên thực tế chính ban vận hành là người trực tiếp gửi các PR được tạo bằng CoPilot
Đùa rằng một ngày nào đó CoPilot sẽ ghi đè toàn bộ codebase, và nếu không còn code thì cũng sẽ không còn test fail nữa
Ý kiến cho rằng trong một tổ chức như vậy thì cũng chẳng cần trung thành làm gì vì lúc nào cũng có thể trở thành đối tượng layoff, như trường hợp người làm TypeScript compiler bằng Go
Việc mở PR ít nhất vẫn là cách thử nghiệm an toàn; nếu vô dụng thì có thể loại bỏ ngay; những thử nghiệm mới luôn đi kèm thử-sai và thất bại, nhưng chính trải nghiệm đó mới quan trọng; kỳ vọng rằng nếu được rèn giũa khắc nghiệt trên code thật và vấn đề thật thì công cụ có thể phát triển nhanh, ví dụ sau này có thể có khả năng lặp lại cho đến khi chạy được test hoặc có kiểm tra ngăn việc xóa test; cuối cùng dự đoán một tương lai nơi AI đảm nhận các việc lặp đi lặp lại, đơn giản trong quy trình phát triển, còn lập trình viên tập trung vào công việc sáng tạo cốt lõi
Tuy vậy, sẽ an toàn hơn nếu những thử nghiệm này diễn ra trong private fork thay vì public repository; nghi ngờ liệu việc các trường hợp như thế này bị công khai có phải quyết định đúng về mặt sales hay không; khi người ra quyết định trong công ty nhìn CoPilot trên tạp chí rồi muốn làm theo y hệt, thì những ví dụ thực tế như thế này có thể trở thành tài liệu tham khảo; đa số công ty thường có xu hướng che giấu tối đa các trường hợp ứng dụng gặp lỗi và chỉ công bố hình ảnh chỉn chu, hoàn thiện
Những vấn đề không dễ thấy còn có thể ẩn trong cả các PR trông bề ngoài có vẻ ổn, nên còn nguy hiểm hơn
Chia sẻ trải nghiệm rằng review code AI còn bực mình hơn cả công việc lặp đi lặp lại đơn giản, đặc biệt khi bug ẩn bên trong thì lập trình viên còn khổ hơn
Bản thân việc mở PR đã làm tăng tải và độ phức tạp cho quản lý dự án; thử nghiệm ở fork riêng sẽ là tấm gương tốt hơn cho cộng đồng; nhiều dự án mã nguồn mở đã kiệt sức vì phải quản lý đống PR tích lũy, đến mức maintainer bỏ hẳn hoặc có người fork ra để chỉ lấy các PR còn sống sót; lo ngại kiểu làm này sẽ khiến số dự án bị bỏ hoang và số fork tăng thêm
Nếu thật sự tin rằng LLM có thể học cách lập trình đúng trong trạng thái đầy bug như vậy, thì sau đó sẽ cần xây dựng dataset hầu như không có bug; còn thực tế thì điều đó không xảy ra, người ta chỉ cào về mọi loại dữ liệu có thể
GitHub đã tốn hàng tỷ đô để tạo ra một AI thường xuyên còn fail cả lint khoảng trắng trong một trong những repository trưởng thành nhất thế giới; nếu chỉ là thử nghiệm cho vui thì còn đỡ, nhưng đem gắn giá thật và bán như một "sản phẩm đột phá" thì rõ ràng gây tranh cãi
Với nhà nghiên cứu thì đây dĩ nhiên là thử nghiệm bình thường, vấn đề là thái độ của công ty khi đem bán ngay thứ còn dang dở như thế
Đùa rằng cựu CEO Nat Friedman chắc "chết mất rồi... à không, vẫn còn sống chứ"
Vấn đề thực sự là không có chỉ số khách quan để đo hiệu suất của lập trình viên; tình trạng chỉ có đánh giá chủ quan kiểu review cuối năm; cũng khó biết hiệu quả/không hiệu quả của việc dùng AI thực tế đang nghiêng về phía nào; thoạt nhìn có vẻ rẻ hơn junior nhưng lại làm lãng phí thời gian của senior và không làm đúng chỉ thị, kết hợp với văn hóa sùng bái CEO thì càng làm bất đồng nội bộ sâu sắc hơn; sự phản đối của lập trình viên bị gạt đi như "nỗi sợ bị thay thế", còn phía CEO thì tối đa hóa thành tích thúc đẩy triển khai; vì không có tiêu chuẩn ngành nào mà cả hai bên đều đồng ý nên không thể xác định sự thật; suy luận cực đoan hơn nữa là trong tổ chức có thể sẽ xuất hiện yêu cầu hạ thấp tiêu chuẩn review chỉ để tăng số lượng AI PR