Nếu bạn đã từng sử dụng máy in 3D, bạn có thể nhớ cảm giác kỳ diệu khi lần đầu tiên in ra một thứ gì đó mà bạn không bao giờ có thể tự mình tạo hình hoặc xây dựng được. Tải xuống tệp mô hình, nạp sợi nhựa, nhấn nút, và gần như bằng phép thuật, một vật thể ba chiều xuất hiện. Nhưng kết quả không được hoàn thiện và sẵn sàng cho sản xuất hàng loạt, và việc tạo ra một hình dạng mới lạ đòi hỏi nhiều kỹ năng hơn là chỉ nhấn nút. Điều thú vị là, các tác nhân lập trình AI ngày nay cũng mang lại cảm giác tương tự.

Từ tháng 11, tôi đã sử dụng Claude Code và Claude Opus 4.5 thông qua tài khoản cá nhân Claude Max để thử nghiệm rộng rãi việc phát triển phần mềm có sự hỗ trợ của trí tuệ nhân tạo (tôi cũng đã sử dụng Codex của OpenAI theo cách tương tự, mặc dù không thường xuyên bằng). Sau 50 dự án, tôi xin nói thẳng: Tôi chưa bao giờ thấy máy tính thú vị đến thế kể từ khi học lập trình BASIC trên chiếc Apple II Plus lúc 9 tuổi. Ý kiến ​​này không phải là sự chứng thực mà là kinh nghiệm cá nhân: Tôi tự nguyện thực hiện dự án này và tự trả tiền cho cả gói AI cao cấp của OpenAI và Anthropic.

Suốt cuộc đời mình, tôi đã mày mò lập trình với tư cách là một người viết mã thực dụng, viết các công cụ hoặc kịch bản nhỏ khi cần thiết. Trong sự nghiệp phát triển web, tôi đã viết một số công cụ nhỏ từ đầu, nhưng chủ yếu là chỉnh sửa mã của người khác cho phù hợp với nhu cầu của mình. Từ năm 1990, tôi đã lập trình bằng BASIC, C, Visual Basic, PHP, ASP, Perl, Python, Ruby, MUSHcode và một số ngôn ngữ khác. Tôi không phải là chuyên gia trong bất kỳ ngôn ngữ nào trong số này—tôi chỉ học đủ để hoàn thành công việc. Tôi đã phát triển các trò chơi sở thích của riêng mình trong nhiều năm bằng BASIC, Torque Game Engine và Godot, vì vậy tôi có một số hiểu biết về những yếu tố tạo nên một kiến ​​trúc tốt cho một chương trình mô-đun có thể mở rộng theo thời gian.

 

Vào tháng 12, tôi đã sử dụng Claude Code để tạo ra một bản sao trực tuyến nhiều người chơi của Katamari Damacy có tên là “Christmas Roll-Up”. (Nguồn ảnh: Benj Edwards)

 

Claude Code, Codex và Gemini CLI của Google dường như có thể thực hiện những điều kỳ diệu trong lĩnh vực phần mềm ở quy mô nhỏ. Chúng có thể tạo ra các nguyên mẫu bắt mắt của các ứng dụng đơn giản, giao diện người dùng và thậm chí cả trò chơi, nhưng chỉ khi chúng sử dụng các mẫu từ dữ liệu huấn luyện của mình. Giống như máy in 3D, việc thực hiện công việc ở cấp độ sản xuất đòi hỏi nhiều nỗ lực hơn. Việc tạo ra mã sản xuất bền vững, quản lý một dự án phức tạp hoặc tạo ra một thứ gì đó thực sự mới lạ vẫn đòi hỏi kinh nghiệm, sự kiên nhẫn và kỹ năng vượt xa những gì các tác nhân AI hiện nay có thể tự cung cấp.

Tuy nhiên, những công cụ này đã mở ra một thế giới tiềm năng sáng tạo trong phần mềm mà trước đây tôi không thể tiếp cận, và chúng mang lại cho tôi cảm giác tự chủ và mạnh mẽ hơn. Dù vậy, tôi biết đây chỉ là những dự án cá nhân, và những hạn chế của các công cụ lập trình tự động khiến tôi tin rằng các nhà phát triển phần mềm kỳ cựu có lẽ không cần phải lo lắng về việc mất việc vì những công cụ này trong thời gian tới. Trên thực tế, họ thậm chí có thể bận rộn hơn bao giờ hết.

Cho đến nay, tôi đã tạo ra hơn 50 dự án demo trong hai tháng qua, một phần nhờ vào việc bị nhiễm COVID khiến tôi phải nằm liệt giường với một chiếc máy tính xách tay và giới hạn sử dụng Claude gấp đôi mà Anthropic đã thiết lập trong những tuần cuối tháng 12. Trong khi tôi gõ bàn phím lia lịa cả ngày, vợ tôi cứ hỏi: "Anh đang nói chuyện với ai vậy?"

Bạn có thể xem một vài kết quả thú vị hơn được liệt kê trên trang web cá nhân của tôi. Dưới đây là 10 điều thú vị tôi đã học được từ quá trình này.

1. Con người vẫn rất cần thiết.

Ngay cả với những phần mềm lập trình AI tốt nhất hiện nay, con người vẫn đóng vai trò thiết yếu trong quá trình phát triển phần mềm. Các nhà phát triển phần mềm giàu kinh nghiệm mang đến khả năng phán đoán, sự sáng tạo và kiến ​​thức chuyên môn mà các mô hình AI thiếu. Họ biết cách thiết kế hệ thống để đảm bảo khả năng bảo trì lâu dài, cách cân bằng giữa nợ kỹ thuật và tốc độ phát triển tính năng, và khi nào cần phản đối khi các yêu cầu không hợp lý.

Đối với những dự án cá nhân như của tôi, tôi có thể bỏ qua một số lỗi nhỏ. Nhưng đối với công việc sản xuất, việc có người hiểu về kiểm soát phiên bản, sao lưu tăng dần, kiểm thử từng tính năng một và gỡ lỗi các tương tác phức tạp giữa các hệ thống sẽ tạo nên sự khác biệt lớn. Hiểu biết về cách thức phát triển phần mềm tốt hoạt động như thế nào sẽ giúp ích rất nhiều khi hướng dẫn một trợ lý lập trình AI – công cụ này khuếch đại kiến ​​thức hiện có của bạn chứ không phải thay thế nó.

Như nhà nghiên cứu AI độc lập Simon Willison đã viết trong một bài đăng phân biệt giữa phát triển phần mềm chuyên nghiệp có sự hỗ trợ của AI và kiểu lập trình "cảm tính " thông thường : “Các công cụ AI khuếch đại chuyên môn hiện có. Bạn càng có nhiều kỹ năng và kinh nghiệm với tư cách là một kỹ sư phần mềm, bạn càng có thể đạt được kết quả nhanh hơn và tốt hơn khi làm việc với các mô hình học máy (LLM) và các tác nhân lập trình.”

Với sự hỗ trợ của trí tuệ nhân tạo, bạn không cần phải nhớ cách làm mọi thứ. Bạn chỉ cần biết mình muốn làm gì.

 

Card Miner: Heart of the Earth được thiết kế hoàn toàn bởi con người, nhưng được lập trình bằng trí tuệ nhân tạo sử dụng Claude Code. Sản phẩm này là kết quả của khoảng một tháng làm việc lặp đi lặp lại. Nguồn ảnh: Benj Edwards

Vì vậy, tôi thích tự nhắc nhở mình rằng các tác nhân lập trình là công cụ phần mềm được sử dụng tốt nhất để hiện thực hóa ý tưởng của con người, chứ không phải là những nhân viên lập trình tự động. Chúng không phải là con người (và không thể thay thế con người) cho dù các công ty đứng sau chúng có tiếp thị chúng như thế nào đi chăng nữa.

Nếu bạn suy nghĩ kỹ, mọi thứ bạn làm trên máy tính đều từng là quy trình thủ công. Lập trình một máy tính như ENIAC thực sự bao gồm việc tạo ra các bit vật lý (kết nối) bằng dây trên bảng cắm . Lịch sử lập trình là một quá trình tự động hóa ngày càng tăng, vì vậy mặc dù bước tiến được hỗ trợ bởi AI này có phần đáng kinh ngạc, người ta có thể coi những công cụ này như một bước tiến tương tự như sự ra đời của các ngôn ngữ lập trình bậc cao, trình biên dịch tự động và công cụ gỡ lỗi, hoặc các IDE dựa trên giao diện đồ họa người dùng (GUI). Chúng có thể tự động hóa nhiều tác vụ, nhưng việc quản lý phạm vi tổng thể của dự án vẫn thuộc về người hướng dẫn công cụ thực hiện.

Và chúng có thể mang lại lợi ích tích lũy nhanh chóng. Giờ đây, tôi đã sử dụng các công cụ AI để viết ra những công cụ tốt hơn—chẳng hạn như thay đổi mã nguồn của trình giả lập để một tác nhân lập trình có thể sử dụng trực tiếp—và những công cụ được cải tiến đó đã và đang tạo ra những hiệu ứng lan tỏa. Nhưng con người vẫn phải tham gia vào quá trình này để tầm nhìn của tôi được thực hiện tốt nhất. Cách tiếp cận này đã khiến tôi rất bận rộn, và trái ngược với một số lo ngại phổ biến về việc con người trở nên kém thông minh hơn do AI, tôi đã học được rất nhiều điều mới mẻ trong quá trình này.

2. Các mô hình AI dễ bị lỗi khi vượt quá dữ liệu huấn luyện của chúng.

Giống như tất cả các mô hình AI dựa trên kiến ​​trúc Transformer , các mô hình ngôn ngữ lớn (LLM) làm nền tảng cho các tác nhân lập trình hiện nay đều có một hạn chế đáng kể: Chúng chỉ có thể áp dụng một cách đáng tin cậy kiến ​​thức thu thập được từ dữ liệu huấn luyện, và khả năng khái quát hóa kiến ​​thức đó sang các lĩnh vực mới không có trong dữ liệu đó là rất hạn chế.

Dữ liệu huấn luyện là gì? Trong trường hợp này, khi xây dựng các mô hình học máy (LLM) thiên về lập trình, các công ty AI tải xuống hàng triệu ví dụ về mã phần mềm từ các nguồn như GitHub và sử dụng chúng để tạo ra các mô hình AI. Sau đó, các công ty sẽ chuyên biệt hóa chúng cho việc lập trình thông qua các quy trình tinh chỉnh.

Khả năng sử dụng phương pháp thử và sai của các tác nhân AI—thử một việc rồi lại thử lại—giúp giảm thiểu phần nào tính dễ hỏng của LLM. Nhưng nó không hoàn hảo, và thật khó chịu khi thấy một tác nhân lập trình cứ mãi loay hoay thử và thất bại một nhiệm vụ nhiều lần, hoặc vì nó không biết cách làm hoặc vì trước đó nó đã học cách giải quyết vấn đề nhưng rồi lại quên mất do cửa sổ ngữ cảnh bị thu nhỏ (xem thêm tại đây ).

 

Violent Checkers là một phiên bản biến tấu dựa trên vật lý của trò chơi cờ bàn cổ điển, được lập trình bằng Claude Code. Tác giả: Benj Edwards

Để khắc phục điều này, bạn nên cho mô hình AI ghi chép tỉ mỉ về cách nó giải quyết các vấn đề nhất định trong quá trình hoạt động để các phiên bản sau của tác nhân có thể học hỏi từ đó. Bạn cũng cần thiết lập các quy tắc cơ bản trong tệp claude.md mà tác nhân đọc khi bắt đầu phiên làm việc.

Tính dễ bị tổn thương này có nghĩa là các tác nhân lập trình giỏi đến mức đáng kinh ngạc trong những gì chúng đã được đào tạo và tinh chỉnh – các ngôn ngữ lập trình hiện đại, JavaScript, HTML và các công nghệ tương tự phổ biến – và thường rất kém trong các nhiệm vụ mà chúng chưa được đào tạo chuyên sâu, chẳng hạn như lập trình hợp ngữ 6502 hoặc lập trình trò chơi Atari 800 với đồ họa nhân vật trông chân thực.

Tôi chỉ mất năm phút để tạo một bản demo HTML5 khá tốt với Claude, nhưng lại mất cả tuần thử nghiệm và sửa lỗi đầy gian khổ, cộng thêm quá trình thiết kế có hệ thống thực sự từ phía tôi, để tạo ra một bản demo tương tự cho trò chơi Atari 800. Để làm được điều đó, tôi đã phải sử dụng Claude Code để tạo ra một số công cụ, như trình giả lập dòng lệnh và máy chủ MCP , cho phép nó xem xét hoạt động của bộ nhớ và chipset của Atari 800 để có thể bắt đầu thực hiện điều đó.

3. Sự mới lạ thực sự có thể là một cuộc chiến khó khăn.

Do những gì có thể được gọi một cách thi vị là "quan niệm định kiến" được tích hợp sẵn trong mạng lưới thần kinh của mô hình lập trình (chính xác hơn về mặt kỹ thuật, đó là các liên kết ngữ nghĩa thống kê), nên rất khó để các tác nhân AI tạo ra những thứ thực sự mới mẻ, ngay cả khi bạn đã mô tả cẩn thận những gì mình muốn.

Ví dụ, tôi đã dành bốn ngày để cố gắng nhờ Claude Code tạo ra phiên bản Atari 800 của trò chơi HTML " Violent Checkers " của tôi , nhưng nó gặp khó khăn vì trong thiết kế trò chơi, các ô vuông trên bàn cờ không có vai trò gì ngoài vị trí ban đầu của chúng. Cho dù tôi đã nói với chương trình bao nhiêu lần (và ghi chú trong các tệp dự án Claude của mình), nó vẫn cứ cố gắng căn giữa các quân cờ vào các ô vuông, gắn chúng vào đúng vị trí trong ô vuông, hoặc sử dụng các ô vuông làm cơ sở logic cho các phép tính của trò chơi, trong khi thực tế chúng chỉ nên tạo thành một hình nền.

Để khắc phục điều này trong phiên bản Atari 800, tôi đã bắt đầu lại từ đầu và nói với Claude rằng tôi đang tạo ra một trò chơi với một UFO (thay vì một quân cờ hình tròn) bay trên một sân gồm các ô vuông liền kề—mà không hề nhắc đến các từ “cờ caro”, “bàn cờ” hay “quân cờ”. Với cách tiếp cận đó, tôi đã đạt được kết quả như mong muốn.

 

Ảnh chụp màn hình máy Mac của Benj khi anh đang làm việc trên bản chuyển thể trò chơi Violent Checkers cho máy tính gia đình Atari 800, cùng với các dự án khác. Nguồn ảnh: Benj Edwards

Tại sao điều này lại quan trọng? Bởi vì với các mô hình ngôn ngữ học (LLM), ngữ cảnh là tất cả, và trong ngôn ngữ, ngữ cảnh thay đổi ý nghĩa. Hãy lấy từ “bank” (ngân hàng) và thêm các từ “river” (sông) hoặc “central” (trung tâm) vào trước nó, và xem ý nghĩa thay đổi như thế nào. Theo một cách nào đó, các từ hoạt động như những địa chỉ mở khóa các mối quan hệ ngữ nghĩa được mã hóa trong mạng lưới thần kinh. Vì vậy, nếu bạn đặt “checkerboard” (bàn cờ) và “game” (trò chơi) vào ngữ cảnh, quá trình tự chú ý của mô hình sẽ liên kết một mạng lưới khổng lồ các liên kết ngữ nghĩa về cách chơi cờ caro, và những “gánh nặng ngữ nghĩa” đó sẽ làm sai lệch mọi thứ.

Một vài thủ thuật có thể giúp các lập trình viên AI vượt qua những hạn chế này. Thứ nhất, tránh làm ô nhiễm ngữ cảnh bằng thông tin không liên quan. Thứ hai, khi tác nhân bị mắc kẹt, hãy thử câu hỏi này: “Bạn cần thông tin gì để có thể thực hiện điều này một cách hoàn hảo ngay bây giờ? Bạn có những công cụ nào có sẵn mà bạn có thể sử dụng để tìm ra thông tin đó một cách có hệ thống mà không cần đoán mò?” Điều này buộc tác nhân phải xác định (liên kết ngữ nghĩa) những lỗ hổng kiến ​​thức của chính nó, được nêu rõ trong cửa sổ ngữ cảnh và là đối tượng của hành động trong tương lai, thay vì mò mẫm một cách mù quáng.

4. Vấn đề 90 phần trăm

90% đầu tiên của một dự án lập trình AI diễn ra nhanh chóng và khiến bạn kinh ngạc. 10% cuối cùng liên quan đến việc tỉ mỉ hoàn thiện các chi tiết thông qua quá trình thử và sai qua lại với hệ thống. Những nhiệm vụ đòi hỏi sự hiểu biết sâu sắc hơn khả năng của hệ thống vẫn cần con người kết nối và hướng dẫn nó đi đúng hướng. Những hạn chế mà chúng ta đã thảo luận ở trên cũng có thể khiến dự án của bạn gặp bế tắc.

Theo quan sát của tôi trong nhiều năm qua, các mô hình tuyến tính lớn hơn có khả năng tạo ra các kết nối ngữ cảnh sâu sắc hơn so với các mô hình nhỏ hơn. Chúng có nhiều tham số hơn (các điểm dữ liệu được mã hóa), và các tham số đó được liên kết theo nhiều chiều hơn, do đó chúng có xu hướng tạo ra một bản đồ sâu sắc hơn về các mối quan hệ ngữ nghĩa. Dù sâu đến đâu, dường như bộ não con người vẫn có khả năng nắm bắt các kết nối ngữ nghĩa sâu sắc hơn nữa và có thể tạo ra những bước nhảy ngữ nghĩa táo bạo mà các mô hình tuyến tính thường không làm được.

Trong ngữ cảnh này, sự sáng tạo có thể là khi bạn chuyển từ, chẳng hạn, môn bóng rổ sang cách bong bóng hình thành trong màng xà phòng và bằng cách nào đó tạo ra một mối liên hệ hữu ích dẫn đến một bước đột phá. Thay vào đó, các LLM (Learning Learning Module) có xu hướng đi theo các con đường ngữ nghĩa thông thường, bảo thủ hơn và hoàn toàn được định hướng bởi các mối quan hệ đã được vạch ra từ dữ liệu huấn luyện. Điều đó hạn chế tiềm năng sáng tạo của chúng trừ khi người hướng dẫn khai phá tiềm năng đó bằng cách hướng dẫn LLM tạo ra các mối liên hệ ngữ nghĩa mới. Điều này đòi hỏi kỹ năng và sự sáng tạo từ phía người vận hành, một lần nữa cho thấy vai trò của LLM như những công cụ được con người sử dụng chứ không phải là những cỗ máy tư duy độc lập.

5. Việc thêm tính năng tràn lan trở nên khó cưỡng lại.

Khi tạo phần mềm bằng các công cụ lập trình AI, niềm vui khi trải nghiệm những điều mới lạ khiến bạn muốn liên tục bổ sung các tính năng mới thú vị thay vì sửa lỗi hoặc hoàn thiện các hệ thống hiện có. Và Claude (hay Codex) rất sẵn lòng đáp ứng, miệt mài với những ý tưởng mới dễ dàng phác thảo trong một bản demo nhanh chóng và hấp dẫn (lại là vấn đề 90%) thay vì trau chuốt mã nguồn.

 

Flip-Lash ban đầu được hình thành như một trò chơi "Tetris nhưng bạn có thể lật bảng", nhưng việc thêm quá nhiều tính năng đã khiến tôi đưa vào vô vàn thứ linh tinh, dẫn đến mất tập trung. Ảnh: Benj Edwards

Việc sửa lỗi cũng có thể tạo ra lỗi ở những nơi khác. Điều này không phải là mới đối với các tác nhân lập trình – đó là một vấn đề lâu đời trong phát triển phần mềm. Nhưng các tác nhân làm trầm trọng thêm hiện tượng này vì chúng có thể càn quét mã của bạn và thực hiện những thay đổi sâu rộng để theo đuổi những mục tiêu hạn hẹp ảnh hưởng đến rất nhiều hệ thống đang hoạt động. Chúng ta đã thảo luận về tầm quan trọng của việc có một kiến ​​trúc tốt được dẫn dắt bởi trí tuệ con người ở trên, và điều đó cũng đóng vai trò quan trọng ở đây.

6. Trí tuệ nhân tạo tổng quát (AGI) vẫn chưa xuất hiện.

Với những hạn chế mà tôi đã mô tả ở trên, rõ ràng là một mô hình AI có trí tuệ tổng quát—điều mà mọi người thường gọi là trí tuệ nhân tạo tổng quát (AGI)—vẫn chưa thể đạt được. Về mặt lý thuyết, AGI sẽ có khả năng vượt qua những định kiến ​​cố hữu và không cần dựa vào việc huấn luyện hay tinh chỉnh nhiều ví dụ để đạt được kết quả chính xác. Các công ty AI có lẽ sẽ cần một kiến ​​trúc khác trong tương lai.

Tôi đang suy đoán, nhưng trí tuệ nhân tạo tổng quát (AGI) có lẽ sẽ cần phải học hỏi liên tục trong quá trình hoạt động – tức là tự điều chỉnh trọng số mạng nơ-ron của chính nó – thay vì dựa vào cái gọi là “ học tập theo ngữ cảnh ”, vốn chỉ tồn tại cho đến khi ngữ cảnh được lấp đầy và bị nén lại hoặc bị xóa bỏ.

 

Grapheeti là một "game trực tuyến nhiều người chơi" (MMO) chuyên về vẽ tranh, nơi người chơi trên khắp thế giới cùng chia sẻ một bức tranh. Ảnh: Benj Edwards

Nói cách khác, bạn có thể dạy một hệ thống AGI thực sự cách làm điều gì đó bằng cách giải thích hoặc để nó học bằng cách thực hành, ghi nhận những thành công và lưu giữ những bài học đó vĩnh viễn, bất kể nội dung trong cửa sổ ngữ cảnh là gì. Các tác nhân lập trình hiện nay không thể làm được điều đó—chúng quên những bài học từ đầu một phiên làm việc dài hoặc giữa các phiên làm việc trừ khi bạn tự tay ghi chép lại mọi thứ cho chúng. Thủ thuật yêu thích của tôi là hướng dẫn chúng viết một báo cáo dài, chi tiết về những gì đã xảy ra khi một lỗi được sửa. Bằng cách đó, bạn có thể chỉ ra giải pháp đã đạt được một cách khó khăn vào lần tiếp theo khi mô hình AI hay quên mắc phải lỗi tương tự.

7. Nhanh đến mấy vẫn chưa đủ nhanh.

Sau một thời gian sử dụng Claude Code, bạn dễ dàng nhận ra rằng mình đột nhiên có khả năng tạo ra phần mềm mà không cần biết một số ngôn ngữ lập trình nhất định. Ban đầu điều này thật tuyệt vời, nhưng bạn có thể nhanh chóng cảm thấy thất vọng vì quá trình phát triển vốn rất nhanh lại không đủ nhanh. Sự thiếu kiên nhẫn xuất hiện, và bạn bắt đầu muốn nhiều hơn nữa.

Nhưng ngay cả khi bạn biết các ngôn ngữ lập trình đang được sử dụng, bạn cũng không được miễn trừ trách nhiệm. Bạn vẫn cần đưa ra những quyết định quan trọng về cách dự án sẽ diễn ra. Và khi tác nhân gặp sự cố hoặc gây ra lỗi, kiến ​​thức lập trình của bạn trở nên thiết yếu để chẩn đoán vấn đề và đưa nó trở lại đúng hướng.

8. Mọi người có thể trở nên bận rộn hơn bao giờ hết.

Sau khi hướng dẫn quá nhiều dự án cá nhân thông qua Claude Code trong hai tháng qua, tôi bắt đầu nghĩ rằng hầu hết mọi người sẽ không thất nghiệp vì AI—mà họ sẽ bận rộn hơn bao giờ hết. Các công cụ mạnh mẽ cho phép hoàn thành nhiều việc hơn trong thời gian ngắn hơn, và nền kinh tế sẽ đòi hỏi năng suất cao hơn để đáp ứng.

Thực tế, việc tạo ra phần mềm mới gần như quá dễ dàng, và điều đó có thể rất mệt mỏi. Ý tưởng dự án này dẫn đến ý tưởng dự án khác, và chẳng mấy chốc tôi đã dành tám tiếng mỗi ngày trong kỳ nghỉ đông để quản lý khoảng 15 dự án Claude Code cùng một lúc. Phân tán sự chú ý như vậy sẽ ảnh hưởng đến kết quả tốt, nhưng sự mới lạ khi thấy ý tưởng của mình trở thành hiện thực lại rất gây nghiện. Ngoài những ý tưởng trò chơi tôi đã đề cập ở đây, tôi còn tạo ra các công cụ để thu thập và tìm kiếm các bài viết cũ của mình, một trò chơi MUD đồ họa dựa trên ZZT, một loại MUSH (trò chơi văn bản) mới sử dụng các phòng do AI tạo ra, một loại proxy hiển thị Telnet mới , và một ứng dụng khách Claude Code cho Apple II (sẽ có thêm thông tin về điều này sau). Tôi cũng đã đưa hai trình giả lập hỗ trợ AI cho Apple II và Atari 800  lên GitHub. Thật là nhiều việc!

Hãy xem xét sự ra đời của máy xúc hơi nước , cho phép con người đào hố nhanh hơn so với một nhóm người sử dụng xẻng tay. Nó giúp đẩy nhanh tiến độ các dự án hiện có và mở ra khả năng thực hiện các dự án mới. Nhưng hãy nghĩ về người điều khiển máy xúc hơi nước. Đột nhiên, chúng ta có một công cụ không biết mệt mỏi, có thể hoạt động 24 giờ một ngày nếu được tiếp nhiên liệu và bảo dưỡng đúng cách, trong khi người điều khiển nó lại cần ăn, ngủ và nghỉ ngơi.

 

Tôi đã sử dụng Claude Code để tạo ra một giao diện người dùng đồ họa (GUI) mô phỏng cửa sổ của máy Mac hoạt động qua Telnet. Nguồn: Benj Edwards

Trên thực tế, chúng ta có thể cần những biện pháp bảo vệ mới cho những người lao động tri thức sử dụng những cỗ máy thông tin không ngừng nghỉ này để hiện thực hóa ý tưởng của họ, giống như cách các công đoàn nổi lên như một phản ứng trước các dây chuyền sản xuất công nghiệp hơn 100 năm trước. Con người cần nghỉ ngơi, ngay cả khi máy móc không cần.

Liệu hệ thống trí tuệ nhân tạo (AI) có bao giờ thay thế vai trò của con người trong lĩnh vực này? Ngay cả khi các tác nhân lập trình AI cuối cùng có thể hoạt động hoàn toàn tự động, tôi không nghĩ chúng sẽ thay thế hoàn toàn con người vì vẫn sẽ có những người muốn hoàn thành công việc, và các công cụ AI mạnh mẽ mới sẽ xuất hiện để giúp họ làm điều đó.

9. Nhanh khiến mọi người sợ hãi.

Các công cụ lập trình AI có thể biến một dự án cá nhân kéo dài cả năm thành một phiên làm việc chỉ năm phút. Tôi đã đưa cho Claude Code một bức ảnh về trò chơi Tetris hai người chơi mà tôi phác thảo trong sổ tay từ năm 2008, và nó đã tạo ra một nguyên mẫu hoạt động chỉ trong vài phút (yêu cầu: “tạo một trò chơi web đầy đủ tính năng với hiệu ứng âm thanh dựa trên sơ đồ này”). Điều đó thật đáng kinh ngạc, và mặc dù kết quả chưa hoàn hảo, nhưng thật đáng sợ khi hình dung điều này có thể tạo ra một sự thay đổi lớn như thế nào trong ngành phát triển phần mềm.

Từ đầu tháng 12, tôi đã đăng tải một số dự án thử nghiệm thú vị được lập trình bằng AI lên Bluesky để mọi người dùng thử, nhưng tôi nhận ra mình cần phải cố tình giảm tốc độ cập nhật vì chúng diễn ra quá nhanh khiến mọi người khó tiếp thu (và tôi cũng không kịp kiểm tra kỹ lưỡng). Tôi cũng nhận được những bình luận như “Tôi lo lắng bạn đang sử dụng AI, bạn làm game quá nhanh” và vân vân.

 

Ghi chú thiết kế trò chơi viết tay của Benj về ý tưởng trò chơi Tetris hai người chơi từ năm 2007. Nguồn: Benj Edwards

Bất kể thói quen cá nhân của tôi thế nào, dòng chảy phần mềm mới sẽ không chậm lại. Sẽ sớm có một nguồn cung cấp dường như vô tận các sản phẩm truyền thông được hỗ trợ bởi trí tuệ nhân tạo (trò chơi, phim ảnh, hình ảnh, sách), và đó là một vấn đề mà chúng ta phải tìm cách giải quyết. Không phải tất cả các sản phẩm này đều là "hàng nhái AI"; một số sẽ được làm rất tốt, và sự tăng tốc trong thời gian sản xuất nhờ những công cụ mạnh mẽ mới này sẽ làm tăng số lượng sản phẩm lên vượt xa mọi thứ chúng ta từng thấy.