Lập trình bằng AI
(geohot.github.io)- AI cho lập trình có cấu trúc vai trò tương tự các trình biên dịch hiện có
- Prompt tiếng Anh với tư cách là một ngôn ngữ lập trình có đặc tính thiếu chính xác và kém hiệu quả
- Hiệu ứng tăng năng suất của AI trên thực tế có xu hướng bị phóng đại hoặc bị nhận thức sai
- Công cụ AI đang thay đổi quá trình phát triển, nhưng đổi mới thực sự có thể xuất hiện từ ngôn ngữ và công cụ tốt hơn
- Việc áp dụng LLM không đồng nghĩa với thay thế lập trình viên, mà đúng hơn phản ánh các giới hạn của môi trường phát triển hiện tại
Sự tương đồng giữa AI và trình biên dịch
- Tác giả cho biết khi lớn tuổi hơn, ông đã từ bỏ việc cố gắng thuyết phục người khác
- Nhấn mạnh hiện tượng nhiều người không quan tâm đến sự thật, mà chỉ đi theo những niềm tin mang lại lợi ích cho bản thân
- Đưa ra phê phán đối với những người cho rằng 'Perception is reality (nhận thức chính là thực tại)'
- Chỉ ra rằng hàng chục tỷ đô la đầu tư vào xe tự lái là sự lãng phí do niềm tin sai lầm
- Góc nhìn tin rằng AI có thể viết code cũng tương tự với quan điểm cho rằng trình biên dịch đang viết code
Lập trình bằng AI là mô hình giống trình biên dịch
- Giải thích lập luận rằng mô hình tối ưu cho AI lập trình là trình biên dịch
- Người dùng nhập prompt (mã), và nhận đầu ra đã được biên dịch như kết quả
- Khác biệt nằm ở việc nhập prompt bằng tiếng Anh, nhưng tiếng Anh có nhiều nhược điểm như thiếu tính rõ ràng, không có đặc tả
- Khi làm việc mới hoặc tác vụ phức tạp, cuối cùng độ dài dòng của prompt vẫn tăng lên
- Đầu ra của AI là phi định tính, và việc thay đổi một phần của prompt có thể ảnh hưởng đến toàn bộ kết quả
Góc nhìn phê phán về lập trình bằng AI
- Lý do khiến lập trình bằng AI trông có vẻ tích cực là vì các công cụ, ngôn ngữ và thư viện hiện nay còn kém
- Nhờ công nghệ "AI", giờ đây có thể tạo ra các công cụ tìm kiếm, tối ưu hóa, trích xuất mẫu tốt hơn trước
- Thực tế người đang viết code vẫn là chính lập trình viên, chỉ là ngôn ngữ của hành vi viết mã đã thay đổi
- Nếu một công ty có thể để LLM thay thế lập trình viên thì điều đó có nghĩa là codebase của công ty và tiêu chuẩn tuyển dụng đang ở mức rất thấp
- AI có thể dần thay thế một phần công việc giống như trình biên dịch hay bảng tính điện tử
AI là công cụ, và rốt cuộc vẫn cần ngôn ngữ·thư viện tốt hơn
- Nhấn mạnh rằng cần nhiều suy nghĩ và sự cẩn trọng từ góc nhìn coi AI là công cụ
- Sự lãng phí hàng chục tỷ đô la đang xảy ra do đầu tư vào những kỳ vọng sai lệch hoặc ảo tưởng
- Đề cập phản ứng thái quá của thị trường đối với các công cụ năng suất giả tạo như “vibe coding”
- Có ảo giác rằng AI thực sự giúp tăng năng suất 20%, nhưng trích dẫn kết quả từ một nghiên cứu (bài báo) cho thấy trên thực tế nó làm chậm đi 19%
- Tiến bộ thực sự có thể đến từ đổi mới trong ngôn ngữ lập trình, trình biên dịch và thư viện
1 bình luận
Ý kiến Hacker News
Tôi gần 50 tuổi và đã viết code chuyên nghiệp từ cuối những năm 90. Trong đầu tôi có thể hình dung ngay dự án và biết chính xác mình cần làm gì. Mức lương cũng thuộc loại khá cao. Nhìn bề ngoài thì có vẻ tôi là hình mẫu điển hình của người phản đối AI, nhưng thực ra không phải vậy. Tôi có thể làm được mọi thứ, nhưng thường rất chán ngán đủ loại công việc cơ bản. Vì thế tôi thực sự thích việc có thể dùng AI để lướt nhanh qua những phần nhàm chán và tập trung vào phần cốt lõi mà tôi yêu thích. Phát triển với AI giống như truyền đạt ý tưởng bằng vài câu cho một lập trình viên ở giữa mức junior và mid-level để họ làm lượng việc bằng một tiếng đồng hồ. Tuy nhiên, việc junior thực sự không còn cơ hội phát triển, khiến nguồn senior developer trong tương lai bị thu hẹp, là một vấn đề cần suy nghĩ nghiêm túc, nhưng đó là chuyện khác
Tôi vừa nói rằng mình dùng AI để xử lý gọn lẹ những phần nhàm chán, nhưng trong số các senior developer giàu kinh nghiệm cũng có người lại sợ những phần khó khăn nên có cái nhìn tiêu cực về AI. Nhiều lập trình viên tìm thấy cảm giác an toàn tâm lý ở những phần dễ và nhàm chán, nhưng khi AI được đưa vào thì công việc có thể biến thành chuỗi khó khăn liên tục. Nếu là một senior chỉ có nhiều năm kinh nghiệm nhưng năng lực không đủ mạnh, thì việc liên tiếp phải gánh các nhiệm vụ đầy thách thức sẽ nhanh chóng làm họ kiệt sức. Các công ty đang đưa AI vào chỉ để tăng tốc bằng mọi giá, nhưng lại bỏ qua thực tế là con người cần nghỉ ngơi về mặt nhận thức. Nếu chỉ để lại những việc quá căng thẳng thì điều đó không tốt cho con người. Tất nhiên, những lập trình viên đã chán ngấy công việc lặp đi lặp lại và dễ dàng có thể được “hồi sinh” cùng AI. Cuối cùng vẫn cần tiếp cận khác nhau tùy từng cá nhân
Tôi cũng trẻ hơn bạn một chút, nhưng suy nghĩ gần như hoàn toàn giống hệt. Thậm chí có thể còn hơn nữa. Tôi cảm thấy điều thú vị không phải là viết code để hiện thực hóa ý tưởng hay, mà bản thân việc nảy ra ý tưởng và thử nghiệm mới là thứ vui nhất. Vì vậy tôi code vì phải code, chứ về bản chất đó không phải việc tôi thực sự muốn làm. Nếu muốn biến ý tưởng của mình thành hiện thực thì tôi đành phải viết code thôi. AI là một đối tác brainstorming cực kỳ xuất sắc. Nếu yêu cầu nó đừng nịnh nọt, nó sẽ thật sự thẳng thắn chỉ ra khi tôi đang over-engineering. Nó cũng debug rất giỏi. Vì thế tôi giải thích bằng lời cho máy tính, brainstorming về kiến trúc và phương pháp, tạo spec rồi giao phần triển khai cho AI. Nếu suy nghĩ của tôi sai, tôi lặp lại và cải thiện rất nhanh cùng AI. Tốc độ lặp nhanh đến mức sai cũng không sao. Trước đây nếu thiết kế sai thì phải sửa cả codebase nên đành sống chung với nó, nhưng nhờ các công cụ Agentic coding, việc thay đổi toàn bộ codebase cũng không còn là vấn đề. Tôi cũng đã bước vào các lĩnh vực công nghệ mới mà mình không phải chuyên gia, nhưng nhờ AI mà có thể tiến vào hiệu quả và nhanh chóng nâng trình. Thành thật mà nói, bây giờ là giai đoạn hạnh phúc nhất trong đời lập trình của tôi. Các công cụ đang tốt lên mỗi tuần, thậm chí có tuần còn tốt lên nhiều lần
Điều này hoàn toàn trùng với trải nghiệm của tôi. Tôi cũng có số năm làm việc tương tự. Tôi dùng AI rất tích cực cho cả dự án cá nhân lẫn công việc công ty. Thứ nhất, AI đóng vai trò như một người trao đổi ý tưởng ít thiên kiến hơn. Vòng phản hồi nhanh và kiểm chứng hướng đi thật sự là điều thiết yếu. Thứ hai, nó tiết kiệm thao tác gõ và thời gian. Các “công việc cơ bản” có thể giao một lần và nó xử lý ít nhất 80% một cách hoàn hảo. Không phải lúc nào cũng đạt 100%, nhưng thời gian tiết kiệm được lớn hơn rất nhiều nên xét tổng thể vẫn lời tuyệt đối. Khi dùng AI, tôi luôn đặt guardrail, cố gắng đưa chỉ dẫn cụ thể và chi tiết nhất có thể, và hình thành thói quen luôn tự mình rà soát sản phẩm đầu ra
Tôi ít kinh nghiệm hơn khoảng 10 năm nhưng lập trường cũng tương tự. Tuy nhiên tôi lại không thấy đồng cảm lắm. Mỗi khi một phần nào đó bắt đầu trở nên nhàm chán thì việc tự động hóa hoặc khái quát hóa nó lại khó và nhiều thách thức đến mức thực tế gần như không còn việc nào thật sự nhàm chán nữa. Ngược lại, chính việc tự tay gõ code lại nhanh hơn với tôi. Khi trực tiếp viết những phần không trung gian, không đơn giản, tôi lại nghĩ ra cấu trúc tốt hơn hoặc ý tưởng tự động hóa mới. Thành ra gần như không có đoạn code nào tôi thực sự muốn giao đi. Và có lẽ tôi chỉ có thể nghĩ như vậy vì đã ở lâu trong một công ty. Nếu cứ phải liên tục làm các phần code mới thì có lẽ tôi đã nghĩ khác
Tôi cũng ở độ tuổi 50 và đã code từ những năm 90, kiếm được nhiều tiền đến mức đủ sống hơn ba đời cũng được. Trong 30 năm kinh nghiệm, có một đặc điểm chung ở những lập trình viên giỏi nhất, đó là “sự lười biếng hoàn hảo”. Nghe có thể hơi lạ, nhưng đặc điểm chung duy nhất của những kỹ sư xuất sắc chính là sự lười biếng. Mức độ mà sự lười biếng dẫn tới năng suất cao thật sự rất đáng kinh ngạc. Lý do là họ tự động hóa mọi công việc lặp lại bằng mọi giá. Nếu làm cùng một việc hai lần thì lần thứ ba nhất định phải tự động hóa — đó là nguyên tắc thép tôi học được. Với sự xuất hiện của AI, chính cấp độ tự động hóa đã hoàn toàn thay đổi. Giờ có thể tự động hóa cả những việc trước đây không thể làm được. Tôi đã tìm ra vô số cách dùng AI, và không chỉ tôi mà cả những đồng nghiệp lười biếng của tôi cũng dùng nó cực kỳ tốt. Giờ tôi không thể tưởng tượng nổi việc làm việc mà không có AI. Không phải vì nó là “phép màu”, mà vì với một người lười như tôi, AI thay tôi làm tất cả những việc có thể tự động hóa
Tôi nghĩ đây là một ví dụ cực đoan về lối tư duy bầy đàn liên quan đến AI vốn rất hay thấy trên Hacker News. Geohot thuộc top 99.999% lập trình viên giỏi nhất, nhưng 99.999% lập trình viên mà anh ấy không hiểu thì vẫn đang làm những công việc cơ bản hơn nhiều. Đây là nghịch lý của chuyên gia. Nếu ai cũng ở trình độ chuyên gia thì họ đã không còn là chuyên gia nữa. Tôi đã thấy nhiều lập trình viên hành xử như AI. Họ thậm chí không giải thích nổi codebase do chính mình tạo ra và cũng không quản lý nó một cách nhất quán. Giống như một kỹ sư hàng không vũ trụ chế giễu người làm đồ chơi Kinder Surprise vì không biết mô phỏng chất lưu vậy
Tôi thấy ngạc nhiên vì bạn cho rằng HN tiêu cực về AI. Theo tôi thấy, nhìn vào bình luận hay các bài nổi bật thì toàn bộ HN có vẻ rất lạc quan về công nghệ
Việc một người đã lập công ty xe tự lái lại có quan điểm như thế này cũng trông khá thiếu nhất quán. Nếu mô hình AI không thể viết code thì tôi nghi ngờ liệu nó có thể thay thế được việc lái xe, vốn khó hơn rất nhiều, hay không
Phần đầu bài viết đã giải thích điều này rồi. Ý chính là nhiều workflow lập trình phổ biến có thể làm được vì chúng quá thông dụng, còn nếu muốn làm việc mới thì phải mô tả chi tiết đến mức như chính ngôn ngữ lập trình
Tôi làm trong lĩnh vực hàng không vũ trụ, và các kỹ sư ở đây cũng chẳng khá hơn là bao. Nhưng không cần quá lo. Trong công ty, những người như vậy thường được chuyển sang các vị trí không gây hại gì, và phần lớn trở thành quản lý
Tôi không chắc Geohot thật sự có phải là top 99.999% lập trình viên hay không. “Mô hình tối ưu cho AI lập trình thực ra là compiler. Bạn đưa prompt (=code) vào, nó trả ra code đã biên dịch. So với việc dùng theo kiểu interactive có feedback như phần lớn IDE hiện nay, thì điều chỉnh prompt → biên dịch lại tốt hơn.” Tôi nghi ngờ không biết điều này có thực sự đúng không
Một trong những điểm cốt lõi của cuộc thảo luận là cần định nghĩa cụ thể hơn về “loại hình lập trình”. Cũng giống như không có ý nghĩa gì nếu chỉ hỏi “robot tốt hay xấu?” trong chuyện robot tạo ra thứ gì đó; muốn thảo luận tiến triển thì phải đặt trước câu hỏi “đối với cái gì?”
Tôi nghĩ có khá nhiều vấn đề với bài viết này. Thứ nhất là lập luận “AI coding là compiler”. Compiler chuyển đổi ngôn ngữ một cách xác định theo đặc tả, còn công cụ lập trình LLM là một bộ tổng hợp chương trình có tính lặp, tìm kiếm, sinh và sửa code dưới các ràng buộc như test/type/linter/CI. Thực tế nó còn giải quyết được trọn gói các issue mã nguồn mở quy mô lớn như SWE-bench Verified. Thứ hai là lập luận “ngôn ngữ lập trình là tiếng Anh”. Thực tế là sự kết hợp của code, test, spec, API, JSON schema, diff, công cụ IDE, v.v.; tiếng Anh chỉ đóng vai trò như chất kết dính mà thôi. Tác giả chọn đúng giao diện yếu nhất để công kích. Thứ ba là lập luận cho rằng tính không xác định là vấn đề. Trong thực tế, fuzzing, SAT/SMT, v.v. đều có nhiều yếu tố xác suất, nhưng tính xác định cuối cùng và độ đúng đến từ đặc tả bên ngoài như test, type system, CI, v.v. Và việc LLM phổ biến là do ngôn ngữ hay thư viện kém cỏi cũng là một nhị nguyên sai lầm. Ví dụ, ngay cả khi ngôn ngữ đã tốt hơn như Rust hay TypeScript, LLM vẫn giúp ích trong việc tra API, lần theo repo, viết code lặp lại, migration, viết test, refactor. Cuối cùng, bài chỉ đưa ra giải pháp là “hãy làm ra ngôn ngữ hoặc compiler tốt hơn”, nhưng trên thực tế các team hiện đại đã thu được giá trị lớn từ sự kết hợp với AI. Vì vậy, thay vì mù quáng xem AI coding và LLM như một “compiler tiếng Anh ma thuật được điều khiển bằng prompt”, cách thực tế hơn nhiều là dùng nó như một “junior pair programmer” hỗ trợ dựa trên các ràng buộc riêng của mình như type, test, CI, v.v.
(Chính tác giả) Tôi đồng ý với ý kiến này. Nếu tôi viết bài blog theo cách đó thì có lẽ nó đã không nổi tiếng. Cách mô tả “công cụ lập trình LLM là bộ tổng hợp chương trình dựa trên tìm kiếm” theo tôi nghĩ thật ra gần như chính là định nghĩa của compiler. Chỉ là phần lớn compiler không tìm kiếm đủ nhiều và phụ thuộc nhiều vào heuristic, đơn giản vì chúng không được tích hợp runtime. Việc “nhiều công cụ kỹ thuật có tính không xác định” là đúng, nhưng ví dụ như với SAT solver, việc đưa yếu tố ngẫu nhiên vào có thể làm thay đổi thời gian giải chứ không ảnh hưởng đến tính đúng đắn của đáp án. Fuzzer là để test nên về bản chất không kỳ vọng sự hoàn hảo. Tôi chưa từng thấy fuzzer được đưa thẳng vào production. Tôi hoàn toàn đồng ý với lập luận rằng “tính xác định đến từ test hoặc spec bên ngoài”. Điều tôi mơ ước là một ngôn ngữ trong đó chỉ mô tả hành vi bằng spec chứ không phải cách triển khai. Kiểu như khái niệm schedule của Halide nhưng được khái quát hóa hơn. Máy tính sẽ tự tìm ra cách triển khai. Tôi nghĩ AI có thể cung cấp công cụ như vậy. Không nhất thiết phải là LLM, nhưng chắc chắn cần có spec nghiêm ngặt. Bản thân điều đó cuối cùng vẫn là lập trình. Theo góc nhìn này, tôi phản đối việc xem AI như một “compiler tiếng Anh ma thuật”. Nếu nhận thức rõ điểm mạnh và giới hạn của công cụ rồi dùng nó như phương tiện hỗ trợ công việc thì đó thực sự là một workflow rất tốt
Một câu trả lời xuất sắc. Hoàn toàn đồng ý
Không có gì ngạc nhiên khi lại viết một bài có những vấn đề như thế này. Tác giả là George Hotz, tức Geohot mà
Tôi dùng cả Openpilot lẫn claude code rất thường xuyên. Tôi xem hai công cụ này gần như ở cùng một mặt bằng. Openpilot lái rất tốt trong nhiều giờ ở các tình huống đơn giản như đường cao tốc. claude code xử lý các công việc lặp lại như refactor trực quan, boilerplate, scaffolding, git bisect mà không cần nhiều đầu vào từ tôi. Nhưng rốt cuộc cả hai đều không thay thế được “người lái”. claude code là kiểu tự lái cấp độ 2 của lập trình
Nghiên cứu của METR nổi đình nổi đám chủ yếu vì cái tiêu đề. Có lẽ ít người thật sự đọc kỹ — vì nó khá dài. Nhưng trong dữ liệu, chỉ có một người có nhiều kinh nghiệm nhất với Cursor hay việc dùng AI là được ghi nhận tăng tốc 50%. Điều đó gợi ý rằng chỉ sau khi quen tay thì hiệu quả mới thật sự nổi bật. Ngoài ra, với mẫu nhỏ thì biến động thống kê cũng lớn. Sau đó còn có đính chính rằng chênh lệch tốc độ của một người khác đã được ghi sai, điều này càng khiến người ta nghi ngờ về ý nghĩa của kết quả. Các yếu tố kém hiệu quả mà nghiên cứu đo được là những thứ hoàn toàn có thể được giải quyết bằng các LLM tốt hơn, agent song song, và các công nghệ tiến bộ hơn. Thời điểm nghiên cứu sử dụng vẫn là thời Claude 3.7 cũ, trước cả Claude Code. Ngay cả cảm giác “hình như mình đã làm ít hơn 20%” trong thực tế cũng đã là một giá trị đủ quan trọng. Làm việc vui vẻ thì thời gian trôi rất nhanh
Vấn đề là đến giờ các AI lab đã bán AI theo kiểu quá cường điệu. Có rất nhiều khẩu hiệu kiểu “AI thật sự suy nghĩ, chứ không chỉ là pattern matching”. Với tư cách là người vừa tạo ra vừa dùng công cụ AI, tôi lại thấy góc nhìn coi nó như một “bộ dự đoán token tiếp theo” dựa trên pattern matching hữu ích hơn nhiều. Nếu nhét quá nhiều thông tin không cần thiết vào ngữ cảnh thì AI thường thất bại trong việc khái quát hóa. Điều này rốt cuộc cũng giống hệt pattern matching, dự đoán token tiếp theo. Tôi tin rằng “công nghệ AI có thể đóng góp vào những công cụ rất tốt ngày nay”, nhưng đó là kết quả của việc tìm kiếm/tối ưu hóa quy mô lớn và tái sử dụng các pattern sẵn có. Ví dụ, nếu bảo Claude code viết một CRUD API đơn giản thì chỉ một phút là xong, tiết kiệm cho tôi cả một tiếng đồng hồ. Nếu yêu cầu một thuật toán đã được triển khai hàng trăm nghìn lần, nó cũng lập tức cho ra đoạn code chính xác. AI hoạt động cực tốt nếu chỉ dùng trong đúng lĩnh vực chuyên môn của nó. Ngoài ra thì kết quả không mấy tốt đẹp
Đây là vấn đề khác biệt về cấp độ intelligence. Không phải khác biệt về kiến thức, mà là khác biệt về năng lực tư duy nền tảng. Chúng ta thường đánh giá thấp nỗ lực nhận thức cần cho một công việc nào đó. Nhưng đôi khi AI cũng thể hiện những hành vi “chu đáo” hơn ta nghĩ. Những lúc như vậy nó thật sự mang lại cảm giác như phép màu
CRUD hay boilerplate thực ra cũng có thể phần nào giải quyết bằng công cụ hóa. Nhưng cũng có nhiều việc chỉ AI mới làm được. Ví dụ, khi tôi phải kiểm thử và phân tích toàn bộ log ở mức trace, nếu tự mắt đọc hàng trăm dòng thì cực kỳ tốn thời gian, nhưng nếu bảo AI “hãy chạy test rồi tìm nguyên nhân”, nó có thể trả về kết quả đủ dùng. Giờ đây đó thường là bước đầu tiên của tôi
Tôi nghĩ trong ý kiến của bạn cũng có phần đúng. Nhưng thế giới kinh doanh có một “khát vọng tái sắp xếp trật tự” rất lớn. Có vô số dòng vốn muốn lợi nhuận mạnh trong thời gian ngắn, và các quỹ đầu tư thì nếu không chạy theo xu hướng sẽ bị sa thải người quản lý. CIO hay CEO cũng vậy. Cuộc đua đưa AI vào giống như cuộc chạy đua vũ khí hạt nhân, một khi đã bắt đầu thì không thể dừng lại. Về bản chất, chuyện này không hẳn tốt cho bất kỳ ai. Nhưng vì ai cũng lao vào nên mình cũng không thể đứng ngoài. Trước khi ô tô xuất hiện, con người vẫn đủ hạnh phúc. Nhưng ô tô xuất hiện rồi thì thành phố bị tái cấu trúc, khoảng cách giữa các tòa nhà ngày càng xa hơn, và đi làm xa trở thành chuyện thường nhật. AI cũng vậy, nó thay đổi chính bối cảnh mà chúng ta làm việc. Giờ đây hình thành kỳ vọng rằng ai cũng phải dùng AI, và đến một lúc nào đó nó sẽ giống như “một điều kiện cơ bản bắt buộc”. Hơn nữa, trong các sản phẩm do khoa học công nghệ tạo ra, hầu như chẳng có gì thực sự là “nhu cầu thiết yếu” của con người. Công nghệ tạo ra vấn đề rồi lại đóng gói giải pháp. Ban đầu vốn không có vấn đề, chỉ sau khi giải pháp xuất hiện thì nó mới trở thành vấn đề. Đó chính là động lực cốt lõi vận hành thế giới kinh doanh
Phần lớn các bài viết quan điểm về AI coding dường như được viết từ góc nhìn của những kỹ sư phần mềm rất dày dạn kinh nghiệm, kiểu “tháp ngà”. (Nghiên cứu đó cũng chỉ nhắm vào “16 nhà phát triển mã nguồn mở giàu kinh nghiệm”.) Nhưng với người không chuyên, các công cụ này cực kỳ có giá trị. Bản thân tôi cũng có chút kinh nghiệm code, nhưng đó không phải nghề chính của tôi — tôi là nghệ sĩ thị giác. Những việc trước kia mất vài ngày thì giờ tôi làm xong chỉ trong nửa buổi chiều. Hai tháng trước tôi đã nghỉ việc để tập trung phát triển game; ngân sách không dư dả, nhưng tôi vẫn nhất định duy trì Claude và ChatGPT. Và cảm giác lúc 1 giờ sáng đang nằm trên giường nảy ra một ý tưởng, ném thẳng cho Codex, rồi sáng hôm sau dậy chạy thử, thật sự rất giống phép màu. Trước đây tôi thường ngại bắt đầu vì lo “liệu đây có thật sự là cách tốt nhất không?”, nhưng giờ việc refactor dễ dàng nên nỗi lo đó biến mất. Không chỉ giúp ở chỗ trực tiếp viết code, nó còn làm giảm rào cản tâm lý rất nhiều. Tất nhiên, tôi hiểu rằng phần lớn chỉ trích thực ra nhắm vào việc marketing phóng đại công cụ này và luận điệu “giờ thì kỹ sư sẽ bị sa thải hết”
Tôi 72 tuổi và đã làm lập trình viên 40 năm. Giờ tôi không còn dễ siêu tập trung như trước, nhưng nhờ AI mà tôi vẫn đang tạo ra mọi thứ. Tôi viết spec cho dự án, còn agent lo phần triển khai và cả test. Giờ tôi code hoàn toàn vì niềm vui