- Tác giả cho biết lý do lớn nhất khiến mình không dùng công cụ lập trình AI là vì chúng không giúp anh ấy làm việc nhanh hơn
- Anh ấy cho rằng thời gian để rà soát và hiểu mã do AI tạo ra có thể còn lâu hơn tự viết trực tiếp
- Vì chất lượng mã và trách nhiệm vẫn thuộc về chính lập trình viên, nên dùng mã AI mà không rà soát là rất rủi ro
- Trước quan điểm nên xem AI như một thực tập sinh, tác giả phản bác rằng AI không thể học hỏi, nên giống một thực tập sinh bị mất trí nhớ hơn
- Khi giải thích sự khác biệt giữa đóng góp mã nguồn mở và mã do AI tạo ra, anh ấy nhấn mạnh tương tác với con người mang lại những ý tưởng mới nên vẫn rất có giá trị
Mở đầu
- Nhiều người thường hỏi tôi có dùng công cụ lập trình AI tạo sinh hay không và tôi nghĩ gì về chúng
- Trong bài này, tôi chỉ tổng hợp trải nghiệm kỹ thuật cá nhân của mình, không đứng hẳn về phe ủng hộ hay phản đối nào
- Tôi sẽ giải thích vì sao AI không giúp ích cho việc lập trình của tôi từ góc độ kỹ thuật
AI không nhanh hơn
- Dù dùng công cụ lập trình AI tạo sinh, tốc độ làm việc của tôi không hề nhanh hơn
- Dù AI có viết mã giúp tôi, trách nhiệm với đoạn mã đó vẫn thuộc về tôi, nên tôi chỉ có thể đưa nó vào dự án sau khi đã rà soát kỹ toàn bộ và hiểu hoàn toàn
- Rà soát mã đòi hỏi thời gian và sự tập trung nhiều không kém gì viết mã, và trong ngành cũng có câu rằng “đọc mã còn khó hơn viết mã”
- Tin tưởng mã do AI viết như một “hộp đen” là một lựa chọn rất vô trách nhiệm. Nếu mã có lỗi, trách nhiệm pháp lý và tài chính cũng vẫn thuộc về lập trình viên
- Không thể có chuyện tăng năng suất hay tăng lợi nhuận nhờ AI mà không phải đánh đổi bằng suy giảm chất lượng và gia tăng rủi ro
AI không phải là công cụ đòn bẩy
- Một số người cho rằng công cụ lập trình AI giúp nhân hiệu quả làm việc lên, nhưng theo tôi đó chỉ là ấn tượng chủ quan
- Một số người tiết kiệm thời gian bằng cách dùng mã do AI tạo ra mà không rà soát hoặc chỉ rà soát một phần, nhưng tôi không thể bỏ qua quy trình đó nên nó không giúp ích gì cho tôi
- Tôi cũng không đồng ý với quan điểm rằng dùng AI để học ngôn ngữ hay công nghệ mới là hiệu quả. Chính quá trình học cái mới mới là niềm vui của lập trình
- Trên thực tế, tôi tự học nhiều ngôn ngữ như Rust, Go, TypeScript, và không giao trải nghiệm đó cho AI
- Bởi vì trách nhiệm với mọi dòng mã cuối cùng vẫn thuộc về tôi
Mã do AI tạo ra khác với mã do con người viết
- Tôi thường gặp câu hỏi: “Đóng góp mã nguồn mở cũng là mã không phải do tôi viết, vậy tại sao lại đối xử khác với mã do AI tạo ra?”
- Thực ra, tôi cũng đầu tư thời gian để rà soát kỹ PR mã nguồn mở. Nhưng hợp tác với người dùng lại dẫn tới những ý tưởng mới và tạo thêm động lực
- Cũng có ý kiến cho rằng chạy nhiều AI agent để nhận PR sửa bug issue là bước ngoặt lớn, nhưng cuối cùng nút thắt của việc rà soát mã vẫn là con người nên thậm chí còn chậm hơn
- Khi các công cụ AI trở nên phổ biến, PR chất lượng thấp xuất hiện ngày càng thường xuyên. Mã AI có cảm giác gượng gạo, tinh vi khó tả, và khi hỏi người gửi PR thì nhiều trường hợp họ cũng không trả lời được
- Đóng góp mã có trách nhiệm và giao tiếp trong cộng đồng mã nguồn mở chính là những điểm khác biệt quan trọng của mã do con người viết
Sự khác biệt giữa AI và thực tập sinh
- Cũng có người ví AI như một thực tập sinh, nhưng chúng khác nhau về bản chất
- Mã ban đầu của thực tập sinh có thể cần nhiều thời gian và công sức để rà soát, nhưng họ phát triển rất nhanh nhờ phản hồi
- Đầu tư vào sự trưởng thành của thực tập sinh rồi sẽ giúp họ trở thành một đồng đội quan trọng có thể tự đảm nhận công việc
- Công cụ AI thì với mỗi công việc mới lại quên kiến thức cũ và bắt đầu lại, không thể trưởng thành hay tích lũy kinh nghiệm
- Điều đó giống như một thực tập sinh không bao giờ tiến bộ, nên không thể đóng góp vào việc nâng cao năng suất
Kết luận
- Qua bài viết này, tôi muốn truyền đạt rõ những vấn đề kỹ thuật khi áp dụng công cụ lập trình AI tạo sinh
- Trong lập trình với AI, không tồn tại cái gọi là ‘bữa trưa miễn phí’
- Những tuyên bố rằng AI giúp làm nhanh hơn hay tăng năng suất thường xuất phát từ việc hạ thấp tiêu chuẩn chất lượng để chấp nhận thêm rủi ro, hoặc từ lợi ích của bên bán AI
- Lập trình viên cần luôn ghi nhớ rằng mình là người chịu trách nhiệm cuối cùng
5 bình luận
Tôi đã hoàn toàn ổn định với chế độ agent của copilot (claud) + codex (o3/4o/codex-mini chạy đồng thời 3 model qua mcp), nhưng tôi nghĩ hiệu quả của nó khác nhau một trời một vực tùy theo người dùng và tính chất của dự án.
Tôi thường giao việc đồng thời trên 5-6 workspace và kiểm tra theo thứ tự hoàn thành; model có thể tự làm toàn bộ cả những việc như đào sâu vào bên trong mã nguồn mở rồi xác minh, nên tôi thấy khá ổn. Nếu giao việc vào giờ ăn trưa thì thường sẽ có một hai việc xong sẵn. Thỉnh thoảng cũng có trường hợp chạy qua đêm, nhưng cái gọi là copilot rate limit lại là một hộp đen...
Ngay cả những tác vụ như kernel hiệu năng cao, đơn giản hóa toàn bộ call stack, hay đảm bảo readability — những việc vốn mất thời gian với con người vì phải chuyển đổi ngữ cảnh nhiều — nếu đưa prompt và mục tiêu đủ tốt thì nó vẫn làm được (vì nó có thể đưa nhiều mã vào bộ nhớ hơn con người), nên việc review patch trong kiểu mã như vậy lại khá dễ... Và với những ai từng gặp sự cố do dùng API sai hoặc do bug ngay trong dự án mã nguồn mở, thì để Agent xác minh một cách chắc chắn cũng khá tốt cho sức khỏe tinh thần...
Tuy vậy, dù sao đi nữa thì lập trình viên sử dụng nó vẫn phải hiểu được patch. Và tất nhiên cũng phải biết cách viết prompt. Vì chỉ khi có thể nhanh chóng xác định vấn đề từ kinh nghiệm rồi ném nó vào thì mới bắt đầu được từ đó. Cũng giống như không thể phát triển kernel hiệu năng cao nếu không có công thức vậy. Việc phán đoán xem vấn đề nằm ở mức chip/os, mức ứng dụng, hay do remote resource, có lẽ vẫn là vai trò của senior ở thời điểm hiện tại.
Từ góc nhìn của một người đã dùng Copilot, ChatGPT, Cursor và các công cụ tương tự ở một mức độ nhất định, chúng khá phù hợp với vai trò như template hay snippet của công cụ phát triển, nhưng chưa đến mức một agent hay đồng nghiệp.
Tôi đang dùng cursor.
Tôi thích chế độ chat
askhơnagent, vì cuối cùng tôi vẫn muốn sau khi xem xét thì mới áp dụng vào code của mình, và nhìn chung tôi cũng đồng ý với những nhược điểm như trong bài viết.Dù vậy tôi vẫn sẽ tiếp tục dùng AI tạo sinh, vì cũng có nhiều trường hợp nó tạo ra những ý tưởng hoặc đoạn code mà tôi không nghĩ tới, nên tôi cho rằng xét như một mục đích tham khảo thì nó hoàn toàn đủ giá trị.
Theo kinh nghiệm cá nhân của tôi, những cảm nhận về việc sử dụng công cụ lập trình sinh sinh cũng khá giống như vậy.
Ý kiến Hacker News
Có người mỗi khi học một ngôn ngữ hay công nghệ mới thì lại nảy sinh thắc mắc, trước đây thường phải tìm trên Google hoặc đăng câu hỏi lên Stack Overflow rồi chờ câu trả lời; còn bây giờ có thể hỏi ngay ChatGPT hoặc Gemini và nhận được câu trả lời nhanh hơn rất nhiều, giúp năng suất tăng đáng kể. Tôi muốn nhấn mạnh rằng chỉ riêng việc nhận được câu trả lời nhanh cho các câu hỏi cũng đã làm quá trình học diễn ra nhanh hơn.
Lý do ChatGPT và Gemini có thể đưa ra đáp án đúng là vì chúng đã học từ tri thức vốn đã tồn tại trên web, bao gồm cả Stack Overflow. Nếu mọi người chỉ dùng AI để hỏi đáp, thì cuối cùng các nguồn tri thức công khai đáng tin cậy có thể sẽ cạn kiệt. Điều này giống như sự quay lại của thời đại bách khoa toàn thư, tức thời kỳ thông tin được thu thập và bán với chi phí cao. Ngoài ra, điều tác giả đang phê phán là các công cụ AI coding viết code thay mình, nên cần phân biệt với các công cụ chỉ trả lời câu hỏi.
Trước đây tôi từng bị chương trình crash khi dùng một API không quen thuộc. Tôi đưa stack trace vào Gemini và lập tức có được manh mối về nguyên nhân, chỉ sửa hai dòng là giải quyết xong vấn đề. Chỉ từ trải nghiệm như vậy cũng có thể cảm nhận rõ giá trị của AI. Ưu điểm lớn là không còn phải mắc kẹt quá lâu vì những lỗi ngớ ngẩn trong lĩnh vực mình chưa quen.
Tìm kiếm ngày càng ưu tiên blog spam hơn, trong khi học từ tài liệu chính thức hoặc user guide tốt ngay từ gốc sẽ mang tính giáo dục hơn nhiều. Khi đọc tài liệu API tốt, ta còn tự nhiên hiểu được thiết kế tổng thể và các tính năng bổ sung. Còn ví dụ trên blog hay tutorial thì có thể giải quyết vấn đề trước mắt, nhưng không giúp nâng năng lực thật sự. Nó chỉ giống như làm hộ bài tập, nên tôi không nghĩ ChatGPT thực sự thúc đẩy việc tự học.
Với các vấn đề khó, nhất định phải có bước xác minh kết quả của AI. Lý do tôi tắt tính năng AI autocomplete cũng là vì trên thực tế hiệu quả không cao, trái lại còn phát sinh nhiều chỉnh sửa không cần thiết. Kỳ lạ là ngay cả chỉ với các local model chạy hoàn toàn offline cũng có thể thu được khá nhiều tài liệu tham khảo hữu ích. Kết quả Gemini tích hợp trong Google cũng không có chất lượng tốt. Điều tôi lo nhất là nếu mọi người chỉ dựa vào AI để lấy thông tin, thì các kho tri thức thực sự như Stack Overflow có thể biến mất.
AI hoàn hảo cho các công cụ boilerplate nhỏ. Những thứ đơn giản như browser extension hay Tampermonkey script gần như có thể bắt tay vào làm ngay mà không cần đọc tài liệu. AI cũng khá hữu ích cho autocomplete code không quá phức tạp hoặc các chỉnh sửa vụn vặt. Những dự án nhỏ mà bình thường tôi còn chẳng bắt đầu được thì có thể xử lý rất nhanh.
Lợi ích tiềm năng của việc tự viết code là nó để lại trong đầu bạn một mental model rất mạnh về vấn đề. Sau này khi giải quyết sự cố hoặc tích hợp tính năng mới, hiệu ứng học tập “vô thức” này phát huy tác dụng cực lớn. Chỉ khi tích lũy ký ức tự tay làm thật thì năng lực mới thực sự tiến bộ. Trong các tổ chức tôi từng thấy, kể cả sau khi đưa LLM vào cũng không hề trải nghiệm được mức tăng năng suất thực sự theo kiểu nhân đôi. Tôi nghĩ có thể người ta đang nhầm giữa việc bớt phải động não, thích đi đường dễ, với năng suất thật.
Tôi nghĩ đây là phần tóm tắt rất đúng hiện tượng con người dần quen với việc giải quyết vấn đề bằng ít năng lượng não hơn, rồi cảm nhận sự nhẹ nhàng đó như thể là năng suất. Kết quả thử nghiệm của Google Research năm 2024 về hiệu quả năng suất của LLM cho thấy nhóm dùng LLM lại mất nhiều thời gian hơn nhóm học bằng sách, và chỉ những người mới chứ không phải người đã thành thạo nội dung mới tăng điểm một chút. Tuy vậy, nhiều người tham gia vẫn tự lầm tưởng rằng mình nhanh hơn và chính xác hơn, và nhóm nghiên cứu giải thích nguyên nhân là do “giảm gánh nặng nhận thức”. Link bài báo liên quan: https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Nếu dùng ít năng lượng não hơn mà có thể làm việc lâu hơn, thì chẳng phải trên thực tế sẽ xử lý được nhiều đầu việc hơn sao? Hiện cả công việc khó cũng chỉ làm được 3~4 tiếng là tới hạn. Góc nhìn này cho rằng nếu có thể chạy marathon với tốc độ đi bộ thì tổng sản lượng đầu ra rốt cuộc vẫn có thể tăng.
Tôi đồng ý rằng coding truyền thống và AI coding là hai kỹ năng tách biệt nhau. Bản thân tôi cũng rất hoài nghi với lập luận cho rằng AI sẽ thay thế coding. Nhưng tôi cho rằng ngay cả “AI coding” tự thân nó cũng có một đường cong thành thạo đáng kể, như quản lý prompt hay giữ ngữ cảnh, và nhiều người đang đánh giá thấp giá trị đó. Cũng giống như vẽ tay và chụp ảnh, mục tiêu theo đuổi của hai bên có thể vốn đã khác nhau. Cách làm tôi ưa thích là “AI xử lý những phần việc nặng, còn tôi phụ trách thiết kế tổng thể và điều phối”.
Việc coding dựa trên LLM giống với trải nghiệm thuê ngoài hơn là chỉ autocomplete đơn thuần: lặp đi lặp lại chu trình định nghĩa công việc - phản hồi - lặp tiếp. Khác biệt là tốc độ xử lý thì LLM hơn, còn độ tin cậy thì con người hơn, nhưng về lâu dài ranh giới này có lẽ sẽ ngày càng mờ đi. Điều quan trọng là về bản chất tôi là kiểu người muốn tự mình chạm vào chi tiết công việc. Tôi chọn nghề này vì thích học và đào sâu vào hạ tầng cùng lập trình. Vì vậy tôi tránh vai trò quản lý, và dù kiếm ít tiền hơn vẫn cố chấp muốn trực tiếp làm ra sản phẩm. Có lẽ khi AGI đạt đến mức có thể trở thành đồng nghiệp thì tôi sẽ quan tâm lại. Bản thân cái tên AI về sau cũng có thể sẽ không còn được coi là điều gì quá đặc biệt nữa.
Dù đường cong học AI coding có thể lớn hơn tưởng tượng, nó vẫn khác piano, thứ phải đầu tư vài năm. Những AI coder thành thạo nhất hiện nay cùng lắm cũng chỉ có khoảng 3 năm kinh nghiệm, và model thì cứ liên tục thay đổi nên nhiều kinh nghiệm cũ không còn khớp với thế hệ model hiện tại. Việc không có cấu trúc học từ bậc thầy cũng là một giới hạn.
Kỹ năng AI coding liệu có giá trị lâu dài hay không? Tôi hoài nghi việc bộ kỹ năng của các công cụ AI hiện tại có thể chuyển giao được bao nhiêu sang các thế hệ tương lai. Dù hiệu quả trước mắt có tăng, vẫn phải tính đến khả năng model và công cụ đổi đi là những gì đang biết trở nên vô dụng.
Tôi nghĩ để thành thạo AI coding thì chỉ cần vài phút hoặc một tiếng là đủ. Nói ví von thì đây không phải lĩnh vực để đào sâu từng cuốn sách như GDB hay UNIX. Cũng như tranh vẽ và nhiếp ảnh khác nhau từ nguyên lý nền tảng đến mục tiêu nên không thể lẫn lộn, AI coding cũng là một hoạt động hoàn toàn khác với coding truyền thống.
Tôi không đồng ý với sự tự tin cho rằng việc thích tự code chỉ đơn giản là vì kỹ năng AI coding còn kém. Chỉ riêng ROI từ những lần dùng gói trả phí nhỏ và free trial cho tới giờ cũng đã đủ để đưa ra phán đoán.
Trong thực tế đã xuất hiện văn hóa thay vì AI review code hay kiểm tra kết quả, người ta đưa nguyên code do AI sinh ra vào PR rồi đẩy phần review cho người khác. Trong tình huống như vậy, GenAI không hẳn là thực sự hữu ích mà tác dụng phụ lớn hơn là bị dùng để trì hoãn công việc.
Tôi cũng từng gặp trải nghiệm như vậy. Nếu quản lý kém năng lực thì họ không thể phân biệt được ai là người tạo ra giá trị thực sự. Tôi thực sự nhận được rất nhiều giá trị từ coding agent, nhưng tôi nghĩ việc các tổ chức thiếu năng lực lại tưởng thưởng cho những đầu ra cẩu thả là một vấn đề nghiêm trọng.
Nếu PR của người gửi cứ liên tục là nguyên xi kết quả từ AI, thì phải tích lũy phản hồi và trưởng nhóm nhất định cần nêu vấn đề.
Với tư cách là người thường xuyên dùng Claude Code, tôi đồng ý 100% với ý rằng khi review code do người khác viết thì thời gian gần như chẳng khác gì tự viết. LLM đúng là dùng được, nhưng càng giao quyền kiểm soát thì đến lúc release thực tế lại càng mất thời gian hơn. Nó có giúp giảm triệu chứng RSI, nhưng hiệu quả tiết kiệm thời gian thường bị phóng đại hơn nhiều so với thực tế.
Khi được hỏi có nhất thiết phải review code hay không, thường thì tôi chỉ spot review các kết quả do AI tạo ra, để AI viết tài liệu spec rồi bản thân tôi làm khâu rà soát cuối cùng và test thật kỹ. Thực ra phần lớn code của các thư viện mã nguồn mở tôi cũng đâu review từ đầu.
Ở đây tồn tại tiền đề rằng “code do chính tôi viết thì không cần xem lại dưới một góc nhìn riêng biệt”. Trên thực tế, cả tôi trong tương lai cũng là một người đọc code tiềm năng. AI coding buộc ta phải có mindset như vậy, tức là đặt ra tiêu chí chấp nhận rõ ràng và xác minh bằng test cùng các quy tắc nhất quán. Kết quả là nó thúc đẩy một văn hóa phát triển bền vững hơn và có lưu lại dấu vết hơn.
Với Claude Code, việc debug bug nếu “viết test trước” thì chuyện AI sửa xong trong vài phút đã là bình thường. Sau khi có thêm tính năng tìm kiếm mới, cả những công việc phức tạp cũng có thể xử lý trong 5 phút; khoản tiết kiệm thời gian ở điểm này là điều tôi cảm nhận rất rõ.
Tôi cũng khuyên nên luôn giữ cánh tay ấm như một cách giảm triệu chứng RSI.
Nêu thắc mắc rằng “tôi không muốn xử lý mọi thứ bằng giao diện hội thoại; có ví dụ nào về việc áp dụng UI kiểu hybrid không?”
Công cụ coding dùng Generative AI chỉ làm phần dễ của công việc nhanh hơn, nhưng lại khiến phần khó trở nên còn khó hơn. Thực tế thời gian dành riêng cho việc viết code không quá lớn, nên kể cả phần đó có nhanh hơn 100 lần thì năng suất tổng thể cũng không thay đổi nhiều. Vì vậy tôi không muốn tốn thời gian vào đó.
Nếu đã là kỹ sư nắm rất rõ một stack và một miền bài toán cụ thể, thì thật ra chẳng cần công cụ nào cả, cũng không cần học thêm gì. Nhưng logic này trên thực tế không có nhiều ý nghĩa. Cuối cùng việc chọn công cụ vẫn là tối ưu hóa cá nhân.
Tôi dùng AI để viết thuật toán, giải thích nguyên nhân của code, gọi API, triển khai một hàm cụ thể, v.v. Dù chưa giao cả bộ code hoàn chỉnh, nhưng ngày càng có nhiều lúc tôi dùng nó cùng debugger.
Một câu hỏi đùa kiểu: chẳng lẽ bạn là thợ ống nước à?
Đoạn tác giả nói rằng “review code do người khác viết có thể tốn thời gian ngang hoặc hơn cả tự viết” là điều tôi cũng đồng cảm, vì tôi từng có kinh nghiệm review code tinh vi kiểu audit bảo mật. Tuy vậy, nếu AI thực sự chuyên về các tác vụ routine cực kỳ đơn giản, thì có lẽ chỉ cần kiểm tra bao quát kiểu eBPF verifier mà không cần soi kỹ code cụ thể. Nếu có issue quá phức tạp thì cứ từ chối PR. Với code đơn giản lặp đi lặp lại, con người cũng không cần phải thẩm định quá kỹ.
Nhưng tôi nghi ngờ liệu đó có thật sự là cách hiệu quả không. Nếu mở ra hàng chục PR rồi chỉ cho một cái qua, thì thà code của đồng nghiệp còn đáng tin hơn nhiều. Một cấu trúc chỉ gây lãng phí thời gian, tiền bạc và tài nguyên môi trường như vậy là không đáng mong muốn.
Nếu đúng là một “hàm Go lặp đi lặp lại”, thì tôi còn nghi ngờ liệu việc phải viết đoạn code đó có đáng hay không. Đó là kiểu code kém hiệu quả, ít tái sử dụng; nếu chỉ cần một hai dòng từ một thư viện phổ biến là xong thì tôi không thấy lý do phải dùng AI để tạo ra.
Với người đọc code nhanh hơn viết code thì GenAI hữu ích; ngược lại, người viết nhanh hơn thì chẳng cần dùng mấy.
Nêu câu hỏi vì sao code do AI viết lại phải được kiểm tra khác với code do con người viết.
Nhấn mạnh rằng với các tác vụ lặp lại và đơn giản, IDE template binding và autocomplete biến cũng đã đủ dùng, lại còn miễn phí.
Trong cuộc so sánh giữa thực tập sinh và công cụ hỗ trợ coding bằng AI, thực tập sinh sẽ học code thực tế, nghiệp vụ và lịch sử hệ thống, còn với AI thì vẫn phải giải thích lặp đi lặp lại ngữ cảnh. Giới hạn này vẫn còn nguyên.
Góc nhìn cho rằng nếu lưu ngữ cảnh quan trọng vào file mdc, thì người phụ trách tiếp theo cũng có thể tham khảo thông tin đó, nhờ vậy khả năng tài liệu hóa và duy trì tri thức thậm chí còn tốt hơn.
Với một số LLM, đây cũng là nguyên nhân khiến system prompt dài tới 14k.
Thực tập sinh thì nhiều khi thật sự CARE.
Cũng có thể chỉ cần đưa ngữ cảnh nghiệp vụ quan trọng vào system prompt.
Các model AI hiện tại về bản chất chỉ học các pattern từ dữ liệu sẵn có. Chúng kết hợp các template của các ca thành công, chứ không phải cấu trúc có thể dẫn dắt ra một lời giải mới từ gốc. Khi gặp vấn đề, chúng tìm câu trả lời từ trải nghiệm giống nhất thay vì tiếp cận có nguyên tắc ngay từ đầu. Chuyên gia con người giỏi first-principles, tức cách suy luận từ các nguyên lý nền tảng mà AI khó làm tốt. AI ưu tiên tính tương đồng nên thường đưa ra lời giải rập khuôn; đặc biệt trong các lĩnh vực cần đổi mới hoặc các bài toán nơi thông lệ không còn hiệu lực, giới hạn này hiện ra rất rõ. Ngay cả context poisoning thì con người cũng ứng phó hiệu quả hơn nhiều.
Tôi không kỳ vọng nhiều vào mảng code do AI sinh ra, nhưng với những việc boilerplate lặp đi lặp lại và nhàm chán thì AI nhanh hơn N lần, theo cảm nhận là một mức rất lớn. Kể một trải nghiệm thực tế: tôi ném cho ChatGPT một ví dụ cấu trúc modal dựa trên React Context, và nó lập tức sinh ra cả hook, provider cùng một loạt cấu trúc liên quan. Chỉ riêng vậy đã tiết kiệm khoảng 30 phút; với những việc lặp kiểu này, 20 đô mỗi tháng hoàn toàn không hề phí.
Trong những trường hợp như vậy, nhiều lúc tôi cũng lấy từ ví dụ trong tài liệu thư viện để dùng, và chỉ 5 phút là tự mình hoàn thành phần triển khai cơ bản tối cần thiết. Nhưng code sinh ra chủ yếu thường đưa ra một lời giải tổng thể vừa khít với tình huống hiện tại, nên về sau khi muốn cải thiện cấu trúc dần dần hoặc refactor thì ngược lại lại khá bất tiện.
Bản thân tôi cũng chủ yếu dùng AI cho boilerplate hoặc ad-hoc script. Các vấn đề thực tế phức tạp thì tôi vẫn thấy khó giao hẳn cho AI. Đặc biệt với các bài toán phải đào sâu vào hệ thống, con người vẫn nên trực tiếp làm, và insight thu được trong quá trình đó rất quan trọng. Tôi cảm thấy dự án càng lớn, yếu tố tích hợp càng nhiều thì giới hạn của AI càng lộ rõ hơn.