AI đang làm chậm các nhà phát triển mã nguồn mở. Peter Naur có thể giải thích vì sao

• Theo một nghiên cứu gần đây, khi các nhà phát triển mã nguồn mở sử dụng công cụ AI trên codebase mà họ rất quen thuộc, thời gian làm việc lại tăng thêm 19%
• Các nhà phát triển tin rằng AI giúp họ nhanh hơn, nhưng thực tế lại chậm hơn, cho thấy khoảng cách giữa nhận thức và thực tế
• Nguyên nhân cốt lõi là mô hình tinh thần (cấu trúc hiểu biết) tinh vi mà nhà phát triển sở hữu và giới hạn trong việc truyền đạt tri thức giữa con người với AI
• Theo lý thuyết của Peter Naur, điều quan trọng nhất trong lập trình là "mô hình tinh thần" trong đầu nhà phát triển
  • Ông là nhà tiên phong khoa học máy tính người Đan Mạch và là người nhận giải Turing năm 2005. Ông đã đóng góp cho ký pháp Backus-Naur (BNF) dùng để mô tả cú pháp ngôn ngữ lập trình
• Ở góc nhìn dài hạn, để hiểu sâu một dự án thì điều quan trọng là tự tay viết mã để xây dựng mô hình tinh thần

---

Hiện tượng AI làm chậm các nhà phát triển mã nguồn mở

• Theo nghiên cứu của Metr, khi dùng công cụ AI, tốc độ giải quyết vấn đề lại chậm hơn 19%
• Trước khi làm việc, các nhà phát triển kỳ vọng AI sẽ giúp họ nhanh hơn 24%, và ngay cả sau khi hoàn thành, họ vẫn tin rằng mình nhanh hơn thực tế 20%
• Nghiên cứu này được thực hiện với các nhà phát triển giàu kinh nghiệm đang trực tiếp duy trì những dự án mã nguồn mở mà họ hiểu rất sâu
• Kết quả không thể khái quát cho mọi nhà phát triển, nhưng với nhóm này, nó cho thấy công cụ AI gây phản tác dụng đối với năng suất
• Trong môi trường doanh nghiệp, hoặc với các nhà phát triển thông thường phải thích nghi với codebase mới, công cụ AI có thể đóng vai trò tích cực hơn trong việc cải thiện năng suất

Vì sao AI làm chậm các nhà phát triển mã nguồn mở dày dạn kinh nghiệm

• Theo bài luận “Programming as Theory Building” của Peter Naur, sản phẩm thực sự của lập trình không phải là mã nguồn mà là ‘mô hình tinh thần của nhà phát triển về dự án’
• Mô hình tinh thần này là cốt lõi để hiểu hệ thống, chẩn đoán vấn đề và cải tiến hiệu quả
• AI dựa trên LLM không thể truy cập trực tiếp vào mô hình tinh thần của nhà phát triển, và ngay cả khi được cung cấp một phần thông tin, vẫn sẽ có tổn thất bản chất trong quá trình truyền đạt tri thức
  • Ví dụ, khi nhờ ai đó ru em bé ngủ, dù đã giải thích rõ ràng thì trên thực tế họ vẫn thường hành động khác với ý định ban đầu
• Việc truyền tải mô hình tinh thần là cực kỳ phức tạp, và gần như không thể để AI hấp thụ nó chỉ qua văn bản
• Vì vậy, nếu giao việc cho AI trong một dự án mà bản thân đã hiểu rất sâu, năng suất có thể còn giảm đi
• Lượng thông tin ngữ cảnh phong phú và sự thấu hiểu mang tính trực giác của nhà phát triển là điều AI khó có thể dễ dàng thay thế

Có nên cấm công cụ AI trong công việc thực tế không?

• Không hẳn. Điều này chỉ áp dụng với “những người đang làm trên dự án mà họ tự mình biết rõ và hiểu sâu”
• Nhiều lập trình viên doanh nghiệp thường phải bảo trì mã do các tiền bối đã rời đi để lại, hoặc làm việc khi chưa hiểu sâu kiến trúc tổng thể của hệ thống
• Trong những môi trường như vậy, AI có thể nhanh chóng nắm bắt codebase và tự động tạo ra thay đổi, từ đó góp phần cải thiện năng suất ngắn hạn
• Nếu chỉ xét việc tạo ra giá trị kinh doanh ngắn hạn và hiệu quả tức thời, công cụ AI có thể đóng vai trò tích cực đối với năng suất

Xây dựng mô hình tinh thần và AI

• Nếu chưa có mô hình tinh thần về dự án, LLM có thể giúp cải thiện năng suất
• Nhưng nếu bản chất của phát triển phần mềm là ‘xây dựng mô hình tinh thần’, thì việc phụ thuộc quá nhiều vào AI có thể làm suy giảm năng lực đó
• Về lâu dài, nếu muốn hiểu sâu dự án và chủ động thay đổi nó, trải nghiệm tự tay viết mã là cần thiết
• Ngược lại, nếu chỉ làm theo kiểu ‘miễn là chạy được’, thì việc tận dụng AI có thể hiệu quả

Thảo luận thêm và kết luận

• Với công cụ AI ở trình độ hiện tại, rất khó để nâng cao năng suất của các nhà phát triển đã có mô hình tinh thần đầy đủ
• Việc AI có thể hỗ trợ đúng cách cho mô hình tinh thần hoặc nâng năng suất của nhà phát triển dày dạn kinh nghiệm lên mức đột phá vẫn cần thêm nghiên cứu và phát triển
• Trong tương lai, khi mô hình tiến bộ hơn, có thể sẽ đến ngày con người không còn cần phải tự mình sở hữu mô hình tinh thần nữa, nhưng ở mức hiện tại thì sự thấu hiểu và học hỏi trực tiếp vẫn là điều thiết yếu
• Cuối cùng, AI có thể trở thành trở ngại trong môi trường ‘tôi hiểu rất sâu mình đang làm gì’, nhưng lại có thể là công cụ nâng năng suất trong môi trường ‘kết quả nhanh là quan trọng’

[paruaa]

> Các nhà phát triển tin rằng AI đã khiến họ làm việc nhanh hơn
Khi việc nghiên cứu với AI trở nên nhanh hơn, có lẽ cũng sẽ giúp nâng cao chất lượng, nên ngay cả với cùng một công việc thì kết quả cũng có thể tốt hơn đôi chút phải không. Có phải các nhà phát triển nghĩ rằng, nếu muốn phát triển sao cho phù hợp với chất lượng của thành phẩm sau khi hoàn thành công việc, thì nhờ AI hỗ trợ sẽ nhanh hơn so với tự mình đạt tới mức đó.
Tôi cũng nghĩ rằng, nếu ngay từ đầu không dùng nó, thì có lẽ người ta sẽ chỉ triển khai bằng lượng kiến thức mình thực sự biết nhiều hơn.

[tested]

> Ngược lại, nếu là kiểu công việc ‘chỉ cần cho nó chạy được’ thì việc tận dụng AI có thể hiệu quả.

Không chỉ riêng lập trình viên, nhưng vì có nhiều kiểu người với xu hướng khác nhau, nên tôi nghĩ rằng những người tình cờ làm nghề phát triển phần mềm, đồng thời ghét hoặc sợ việc viết hay đọc mã, và có tư duy chỉ cần chạy được là đủ hơn là diễn giải theo góc nhìn cấu trúc hệ thống hay khả năng bảo trì, dường như càng dễ phụ thuộc hoặc tin tưởng mù quáng vào AI hơn. Cũng có thể là tôi sai.

[xguru]

Đo lường "tác động của AI" lên năng suất của các nhà phát triển mã nguồn mở giàu kinh nghiệm

[GN⁺]

Ý kiến trên Hacker News

• Mọi người trên HN, tôi là tác giả của bài báo.
  Tôi nghĩ bài blog đó đã đề cập khá thú vị đến một yếu tố cụ thể có thể góp phần làm AI khiến tốc độ phát triển chậm lại.
  Trong bài báo (mục C.1.5) cũng có trích dẫn từ các lập trình viên, mọi người có thể tham khảo.
  Nhiều người đọc bài báo rồi thấy một yếu tố nào đó đồng cảm và dễ kết luận rằng “chỉ riêng vấn đề này là lý do khiến mọi thứ chậm đi”.
  Nhưng thực tế có nhiều yếu tố cùng lúc (ít nhất 5 yếu tố có khả năng cao, và chưa thể loại trừ tối đa 9 yếu tố, xem bảng các yếu tố ở trang 11).
  Phân tích nguyên nhân theo nhiều góc độ sẽ hợp lý hơn là giả định chỉ có một nguyên nhân duy nhất.
  Nếu ai có kế hoạch tự thử nghiệm, tôi rất mong mọi người chia sẻ kết quả qua email ghi trong bài báo.
  Và về tiêu đề bài viết là “AI slows down open source developers. Peter Naur can teach us why”, tôi nghĩ diễn đạt chính xác hơn sẽ là “Vào đầu năm 2025, AI làm chậm các lập trình viên nguồn mở giàu kinh nghiệm. Peter Naur cung cấp thêm bối cảnh cho một yếu tố cụ thể.”
  Cách diễn đạt đó có thể bớt giật gân hơn, nhưng tôi cho rằng tính chính xác là quan trọng.
  Một lần nữa xin cảm ơn vì bài viết rất hay, tôi vẫn đang tiếp tục đọc các bình luận
  Thảo luận liên quan trước đó
  Toàn văn bài báo
  • Tôi có một thắc mắc cá nhân: trong nghiên cứu, nhóm đã đo lường một cách đáng tin cậy mức chênh lệch thời gian thực tế trước và sau khi dùng AI như thế nào? Có phải các lập trình viên đã ước lượng trước họ sẽ tiết kiệm được bao nhiêu thời gian khi dùng AI, rồi sau đó nhóm đo thời gian thực tế để so sánh phần chênh lệch không? Và khi độ khó của từng issue hay thời gian cần để giải quyết vốn khó ước tính, nhóm nghiên cứu đã kiểm soát việc này ra sao? Tôi hoàn toàn đồng cảm rằng kiểu đo lường này thực sự rất phức tạp
  • Tôi đồng tình với kết quả và cảm ơn phản hồi. Tôi thích kiểu tiêu đề táo bạo nên không định đổi, nhưng sẽ sửa rõ trong bài rằng cách diễn đạt hiện tại là không chính xác. Tôi cũng muốn nói rõ rằng các yếu tố đóng góp chính trong kết quả nghiên cứu mà tôi viết tới như “mức độ quen thuộc rất cao của lập trình viên với repository”, “repository lớn và phức tạp”, “ngữ cảnh repository mang tính hàm ẩn” đều phù hợp với nghiên cứu. Tôi cũng muốn tự làm thử một thí nghiệm như vậy, nhưng cảm thấy rất khó tạo ra một môi trường được kiểm soát trong khi vẫn phải song song đáp ứng yêu cầu công việc. Cũng thiếu một danh sách các tác vụ rõ ràng có thể hoàn thành trong thời gian ngắn
  • Tôi kỳ vọng rằng nếu thay đổi workflow đã được tối ưu trong một dự án mình rất quen thuộc, ban đầu chắc chắn sẽ chậm hơn. Điều quan trọng là xem sau 6 tháng hay 1 năm thì những lập trình viên đó sẽ ra sao. Nghiên cứu này không cho thấy xu hướng dài hạn, nên hy vọng các nghiên cứu sau sẽ cho biết hiệu quả thay đổi như thế nào sau khi cùng một lập trình viên đã quen với công cụ. Bản thân tôi cũng đã trải nghiệm việc có thể script hóa nhiều công việc mà trước đây khó tự động hóa bằng AI. Luôn phải tự hỏi “việc này có đáng giá so với thời gian bỏ ra không?”
    truyện tranh quản lý thời gian của xkcd
  • Cũng cần nói rằng cách diễn đạt “đầu năm 2025 AI làm chậm các lập trình viên nguồn mở giàu kinh nghiệm” vẫn là một sự khái quát hóa quá mức. AI cũng có thể tiết kiệm thời gian cho những tác vụ nhất định, nên hiệu quả còn tùy vào loại công việc
  • Chậm đi không nhất thiết là điều xấu; tôi nghĩ lập trình chậm (lập trình văn chương/theo phong cách Knuth) đôi khi còn giúp ích hơn cho việc hình thành lý thuyết. Cũng có thể lập luận rằng phát triển chậm, với đủ suy nghĩ và trừu tượng hóa, quan trọng hơn kiểu lập trình fast-food
• Tôi rất đồng cảm với hiện tượng “lập trình viên không nhận ra công cụ thực sự đang làm mình nhanh hơn hay chậm hơn”. Người này lấy ví dụ chiếc thuyền bị gió và dòng chảy đẩy lệch khỏi mục tiêu, để chỉ ra rằng ta chỉ cảm nhận được tiến triển dựa trên chuyển động xung quanh hiện tại, chứ khó trực giác được mình có thật sự đến gần đích hay không. Vì vậy con người có xu hướng chọn những chiến lược tạo cảm giác “đang tiến lên”, và điều đó đôi khi dẫn đến các con đường kém hiệu quả hoặc thực ra chậm hơn (ví dụ khi lái xe thì liên tục rẽ phải, v.v.)
  • Khi mới dùng công cụ AI, cảm giác rất thích vì không bị khựng lại và thấy như công việc cứ thế trôi đi. Nhưng thực tế có những lúc tự sửa một dòng còn nhanh hơn, vậy mà vẫn gọi AI theo thói quen. Nó giống ví dụ lái xe: cứ gặp đoạn đường ùn là lại quay về nghe GPS gợi ý tuyến cũ
  • Nó giống như các app dẫn đường như Waze, dù thực tế chỉ đường vòng dài hơn nhưng vì phải luồn lách qua các ngả rẽ nên lại tạo ảo giác là mình “đang di chuyển” và do đó thấy như đi nhanh hơn. Công cụ AI cũng tạo cảm giác lập trình dễ hơn, nhưng năng suất thực tế có thể lại giảm. Con người dễ chỉ nhớ trải nghiệm ngắn hạn là tiến triển không đau đớn, rồi từ đó nghĩ rằng mình đã tiến bộ
  • Cuối cùng thì con người theo bản năng thích greedy algorithm
  • Người dùng Linux/Unix thường cho rằng điều khiển bằng bàn phím và công cụ CLI là hiệu quả nhất, nhưng có nghiên cứu cho thấy trong đa số tác vụ thì chuột lại nhanh hơn. Lý do ta cảm thấy gõ phím nhanh hơn là vì số thao tác mỗi giây nhiều hơn
  • Mã do AI sinh ra hầu như không được review kỹ, và nhiều lập trình viên vốn đã ngại code review nên từ chối đọc. Vì thế mới có hiện tượng framework mới hay các đợt viết lại code được ưa chuộng
    Joel on Software: Things you should never do, part I
    Rất nhiều đoạn mã do AI tạo ra chỉ đơn giản là được sinh ra, chạy qua vài bài test đơn giản rồi thôi. Thậm chí có rất nhiều đoạn mã mà ngay cả chính người dùng cũng không hiểu đầy đủ toàn bộ ngữ cảnh hay lý do tồn tại của nó
• Có thể tóm lược ý chính của nghiên cứu này là “AI tạo ra ảo giác rằng nó cải thiện năng suất nhiều hơn thực tế”. Chỉ một số ít người tham gia tăng năng suất nhẹ, còn đa số lại giảm đáng kể. Có rất nhiều người nói năng suất của họ bùng nổ nhờ AI, nhưng cái nhìn sâu sắc của nghiên cứu rằng chính hiệu quả đó có thể chỉ là ảo giác lại đang bị phớt lờ. AI là một sản phẩm được tối ưu để khiến người dùng tin rằng họ nên dùng nó và rằng nó hữu ích. Giá trị cá nhân là một dạng thực tại được cảm nhận nên không thể phủ nhận, nhưng những ai phụ thuộc mạnh vào AI thật sự cần cẩn trọng với sự méo mó trong tự nhận thức, cảm giác thành tựu giả và sự lệ thuộc vào công cụ. AI có thể trả lời bằng một luồng token đã được tối ưu, nhưng tôi nghĩ thỉnh thoảng cũng nên tự hỏi mục tiêu tối ưu hóa thật sự là gì
  • LLM đúng là có ích khi học cái gì đó, nhưng cảm giác phần hiểu biết đó rất trừu tượng và mang kiểu tư duy của LLM. Khi học thì nên phối hợp nhiều phương pháp khác nhau
  • Công cụ AI không hẳn khiến lập trình viên “nhanh hơn”, mà khiến họ cảm thấy “lanh lẹ tức thời”. Có một mặt giống như ảo giác giảm gánh nặng cho não bộ; đây là một hiệu ứng nhận thức thú vị phát sinh khi cảm giác bản thân thay đổi ở các vòng phản hồi khác và cả cơ chế hình thành ký ức cũng đổi theo
• Trong lúc bàn về nghiên cứu nói rằng “các lập trình viên nguồn mở giàu kinh nghiệm sẽ chậm hơn khi dùng AI trên chính dự án của mình”, tôi lại đang phải làm với một codebase 3 tháng tuổi hoàn toàn do người khác viết, cùng một framework không quen thuộc. Vậy mà nhờ Claude Code, chỉ trong vài giờ tôi đã hoàn thành rất nhanh những việc như đồng bộ dữ liệu, vốn ở các dự án trước có thể mất một hai ngày, thậm chí tối đa hai tuần. Nó là một cú jump-start rất lớn. Khi độ phức tạp tăng lên thì chắc sẽ chậm dần, nhưng việc khởi đầu được đẩy nhanh nhờ công cụ vẫn rất đáng ngạc nhiên
  • Tôi cũng có trải nghiệm tương tự, nhưng điều nghiên cứu này nói đến không phải giai đoạn ramp-up mà chúng ta trải qua, mà là trường hợp những lập trình viên nguồn mở đã cực kỳ quen thuộc với dự án của họ dùng AI để làm tác vụ. LLM đúng là giúp tăng tốc đáng kể việc làm quen với codebase mới, nhưng sau khi đã quen rồi thì tôi lại có cảm giác nó cản trở nhiều hơn
  • Cứ mỗi lần có ai nói “một PR đáng lẽ mất 2 tuần mà làm xong trong vài giờ”, câu chuyện tăng năng suất lại xuất hiện, nhưng tôi không thấy mấy khi chúng ta thực sự kiểm tra xem mình dự đoán thời gian phát triển chính xác đến đâu. Cũng cần xem chất lượng của PR làm gấp như vậy có đúng mức kỳ vọng ban đầu không, hay vì muốn nhanh mà bỏ sót những ngữ cảnh hệ thống quan trọng nên làm tăng xác suất bug. Không có AI thì nếu chấp nhận hy sinh chất lượng, ta cũng nhanh hơn thôi
  • Tôi cũng nghi ngờ liệu AI có thật sự giúp mức độ thành thạo trung bình với codebase và hệ thống tăng lên một cách tự nhiên hay không. Hiệu ứng học tập khi dùng LLM hơi giống việc có thể đọc một ngôn ngữ mới nhưng lại khó tự mình viết từ đầu. Lấy C++ làm ví dụ, ta có thể đọc và sửa cái đang có, nhưng rất khó bắt đầu tạo mới từ con số không
  • Ý tôi chỉ là mình đã có một cú jump-start rất lớn nhờ công cụ AI, chứ không phải để phê phán nghiên cứu, bài viết hay bài báo, mà để nói rằng trong một số bối cảnh AI thực sự rất hữu ích. Không chỉ là viết code; chẳng hạn Claude Code còn thử kết nối trực tiếp tới cụm AWS từ container nội bộ của dự án, và điều đó giúp tôi hiểu rất nhiều về toàn bộ hạ tầng cũng như cấu trúc hệ thống. Theo kinh nghiệm của tôi, 80–90% trường hợp thì “giá trị kinh doanh” được ưu tiên hơn chất lượng code. Tôi không chắc nó hữu ích đến đâu với những công việc mà chất lượng code thật sự quan trọng, hay các lĩnh vực cần thuật toán và cấu trúc dữ liệu đặc biệt. Nhưng tôi cũng đã thấy rằng chỉ cần cung cấp ví dụ tốt và ngữ cảnh rõ ràng, nó có thể viết ra mã khá dùng được. Các công cụ này cải thiện với tốc độ rất nhanh theo từng tuần hoặc từng tháng. Cuối cùng, AI không phải phép màu mà là công cụ, và trách nhiệm với sản phẩm/kết quả cuối cùng vẫn thuộc về chính mình
  • Cần nhớ rằng bài viết/bài báo đang nói về trường hợp trên những dự án cực kỳ quen thuộc. Trải nghiệm tôi gặp phải thì ngược lại: AI chủ yếu phát huy tác dụng trong những tình huống không quen thuộc
• Có người trích dẫn phép so sánh rằng “các công cụ AI agentic (Claude Code, Amp, Gemini CLI, v.v.) đối với lập trình cũng giống như máy cưa bàn đối với nghề mộc”, để lập luận rằng nếu học dùng đúng cách thì một số việc sẽ nhanh và tốt hơn, nhưng khi chưa quen thì có khi còn “cắt vào ngón tay”. Cá nhân tôi thấy nhờ agentic AI mà mình dám thử những dự án tham vọng hơn, còn những việc lặp đi lặp lại hay không muốn làm thì giao cho AI nên có thêm khoảng trống để suy nghĩ. Mặt khác, tôi cũng cảnh giác rằng không thể cứ để AI làm hết rồi commit mà không hiểu gì. Vì là công cụ, ta cần nỗ lực học cách dùng tốt hơn
  • Tôi thấy ví von với máy cưa bàn không hợp lắm. Máy cưa bàn là công cụ có độ chính xác cao hơn dụng cụ cầm tay, còn agentic AI thì lại rất xa với sự chính xác
  • Lập luận kiểu “bạn đang dùng AI sai cách” là một sự xúc phạm với những lập trình viên đã xây dựng cả stack nguồn mở từ trước khi AI xuất hiện. Hơn nữa, hiện vẫn chưa có bằng chứng rằng AI đã tạo ra phần mềm thật sự có giá trị
• Trong nghiên cứu này, chỉ có đúng một lập trình viên có hơn 50 giờ kinh nghiệm với Cursor (tính cả thời gian tham gia nghiên cứu), và người đó trải nghiệm mức tăng tốc 25%. Còn lại đều là người mới, mà người mới dùng công cụ mới thì chậm đi là điều quá hiển nhiên. Tôi không nghĩ có thể rút ra kết luận về năng suất AI chỉ từ nghiên cứu này
  • Nếu xem chi tiết bài báo, thì các nghiên cứu trước đó với những người có mức kinh nghiệm công cụ tương tự (thậm chí còn ít hơn) lại báo cáo tăng tốc độ. Kinh nghiệm với prompt LLM của đa số người tham gia cũng đã đủ nhiều, và đặc biệt Cursor khá giống VSCode nên không có đường cong học tập quá lớn. Nếu mọi lập trình viên đều trở nên cực kỳ quen với công cụ AI, thì cũng có thể kỹ năng làm việc không có AI sẽ giảm đi, để rồi khi dùng AI thì mốc so sánh vốn dĩ đã kém hơn và trông như tốc độ được cải thiện. Điều quan trọng không phải là họ dùng Tool nào, mà là insight rằng báo cáo năng suất tự thân đã lạc quan quá mức so với thực tế. Muốn đánh giá hiệu quả thật sự thì cần các số đo cụ thể
    (được bàn kỹ hơn trong mục C.2.7 của bài báo, “Mức độ tận dụng công cụ AI dưới trung bình”)
  • Nếu là lập trình viên đã dùng IDE của mình (Vim/Neovim, v.v.) trong thời gian dài, thì việc chuyển sang công cụ mới như Cursor có thể khiến năng suất giảm rõ rệt trong nhiều tháng
  • Tôi cũng nghĩ vậy. Lập trình viên dùng công cụ không quen thì chắc chắn sẽ chậm lại. AI cũng không ngoại lệ
• Tôi hiện là reviewer định kỳ cho Burn (framework deep learning viết bằng Rust). Gần đây tôi đã đóng một PR sửa bug trông như được AI agent viết toàn bộ. PR đó không hề giải quyết nguyên nhân gốc của vấn đề mà chỉ đơn giản là bỏ qua lỗi, thêm vào những đoạn mã biện hộ dài dòng vô ích, và thậm chí còn có cả test để kiểm tra việc bỏ qua lỗi. Có vẻ chỉ là hành vi để ghi thêm commit. Tôi lo rằng kiểu lạm dụng AI như vậy đang trở thành một xu hướng đáng ngại
  • Cái cách LLM khi không biết đáp án thì bịa ra điều gì đó, rồi khi bị chỉ ra là sai lại phản ứng kiểu “đúng rồi, để tôi sửa lại” thật kỳ lạ. Tôi thực sự lo rằng những người ít kinh nghiệm sẽ không phân biệt được vấn đề, hoặc dần dần sẽ không còn quan tâm đến code nữa. Cũng có nỗi lo rằng rồi sẽ có hàng loạt lỗ hổng và hình thức lạm dụng nghiêm trọng xuất hiện
  • Khi review MR của một đồng nghiệp, tôi phát hiện những test case rất rõ là do AI sinh ra: nội dung na ná nhau hết, chỉ thay đổi các tên biến như thing1, thing2. Tôi góp ý nên đặt tên dễ phân biệt hơn, thì lần này AI lại gắn những tên biến dài lê thê như thể liệt kê toàn bộ đặc điểm của từng case, khiến code cuối cùng càng khó đọc lướt hơn. Người viết có thể cảm thấy tốc độ viết tăng mạnh, nhưng thực tế thời gian dành cho phản hồi, review và sửa lại đã xóa sạch mọi lợi ích năng suất
  • Cũng có ý kiến đùa kiểu “framework deep learning bằng Rust → vòng luẩn quẩn gắn với AI”
  • Thực ra chuyện dùng AI chỉ để tạo commit trông có vẻ làm việc đã tồn tại từ lâu rồi. AI chỉ khiến việc tạo spam trở nên dễ hơn
    Tham khảo: vấn đề spam AI từ lâu
  • Có người chỉ ra rằng LLM hay viết try:catch quá rộng, khiến việc truy vết nguồn gốc vấn đề trở nên khó khăn hơn. Cá nhân tôi muốn lỗi lộ ra nhanh và rõ hơn (=fail fast) để sửa ngay
• Chia sẻ cảm nhận cá nhân thì với lập trình bằng AI, trạng thái tập trung bị gián đoạn thường xuyên hơn và tôi cũng dễ mệt hơn. Cả ngày chỉ ngồi code liên tục là chuyện hoang đường; bình thường chỉ tập trung được 1–3 tiếng mỗi lần rồi phải nghỉ giữa chừng. Ngay cả khi đọc code hay thay đổi của đồng nghiệp, quãng thời gian đó vẫn được tính là làm việc nhưng thực ra tiến độ hữu hình rất ít. agentic AI có thể hữu ích cho các việc như refactor nhỏ, nhưng mức tăng năng suất lớn thì tôi không thấy. Tự động hoàn thành code (ví dụ Copilot thời kỳ đầu) thì ngược lại còn tạo ra nhiều nhiễu vô ích hơn
  • Nếu quay lại cả ngày làm việc để xem mình thực sự đã làm gì, kết quả có lẽ sẽ khá u ám. Đặc biệt với codebase đã trưởng thành, ngay cả 1 giờ tập trung cũng có thể là con số bị phóng đại
• Khi debug một bug khó nhằn như race condition trong một codebase xa lạ, việc thêm logging, thay thế hàm thư viện, cải thiện cấu trúc là điều bắt buộc; nhưng nếu AI chỉ đưa ra lời giải ngắn hạn kiểu “đây là race condition và sửa như này là được”, thì về lâu dài nó có thể làm hại khả năng hiểu cấu trúc và logic của code. Nếu việc chỉnh sửa mã do AI dẫn dắt cứ tiếp diễn lâu dài, mã nguồn thậm chí có thể bị biến chất đến mức ngay cả AI cũng không còn xử lý tử tế được nữa
  • Mỗi lần nghe chuyện “tôi dùng AI để đóng góp cho một ngôn ngữ không biết, một codebase không quen”, tôi đều tự hỏi rốt cuộc người đó đã học được gì. Có thể kiểu đóng góp đó hữu dụng cho các tác vụ nhỏ trong ngắn hạn, nhưng tôi gần như không nghe thấy nhiều câu chuyện về kinh nghiệm bảo trì dài hạn
• Nhìn lại dự án đầu tiên gần đây mà tôi tích cực tận dụng công cụ AI, kết luận của tôi là: 1) tốc độ không nhanh hơn, 2) thậm chí có thể chậm hơn, 3) nhưng chất lượng kết quả tốt hơn. Việc chậm đi và chất lượng tăng lên có liên hệ với nhau, vì tôi chủ yếu dùng AI như công cụ hỗ trợ để kiểm chứng ý tưởng hay khám phá phương án khác. Nhờ AI mà trải nghiệm học hỏi ở lĩnh vực lạ cũng rất tốt, còn ở mảng chuyên môn chính của mình thì việc mài giũa ý tưởng của tôi hoặc của AI cuối cùng cũng giúp chất lượng đi lên. Tốc độ không phải là thứ duy nhất quan trọng; dù chất lượng khó định lượng, tôi vẫn thấy nó hoàn toàn xứng đáng
  • Vì AI thực sự có thể góp phần cải thiện chất lượng, dạo này tôi thích những AI biết phản biện và không đồng ý vô điều kiện hơn. Nếu nhờ AI đưa ra ý tưởng rồi yêu cầu nó công kích điểm yếu, hoặc cùng tìm lỗ hổng trong ý tưởng của mình, thì rất hiệu quả. Dù cuối cùng có thể không triển khai, nó vẫn giúp tôi nghĩ ra nhiều góc độ mà trước đây chưa từng nghĩ tới. Trải nghiệm này khá giống như trò chuyện với một đồng nghiệp có thể đưa ra ý kiến tương đối hợp lý về lĩnh vực đó

[eususu]

Tôi cũng từng có suy nghĩ tương tự nhưng khó diễn đạt cho rõ.
"Mô hình tinh thần" đúng là một cách đặt tên phù hợp. Tôi sẽ cố gắng dùng nó thường xuyên hơn.