◂ Bài viết Khi AI làm thay những việc mà chúng ta chưa từng biết cách làm

Khi AI làm thay những việc mà chúng ta chưa từng biết cách làm

Ngày đăng
Thời gian đọc
38 phút
Chủ đề
Mindset

Liệu chúng ta có cần biết cách tạo ra một thứ gì đó, trước khi có thể biến nó thành hiện thực?

Hồi còn nhỏ, tôi từng đọc câu chuyện về Mã Lương và cây bút thần.

Đó là một câu chuyện khá quen thuộc. Mã Lương có một cây bút kỳ diệu, bất cứ thứ gì cậu vẽ ra đều có thể trở thành hiện thực. Vẽ một con chim, con chim sẽ bay. Vẽ một con cá, con cá sẽ bơi. Vẽ một thứ gì đó mà người nghèo đang cần, thứ ấy sẽ xuất hiện ngay trước mắt họ.

Hồi đó, tôi thấy cây bút ấy thật tuyệt vời. Có lẽ đứa trẻ nào cũng từng mong mình sở hữu một thứ tương tự.

Nhưng có một câu hỏi mà tôi thấy khá thú vị khi nghĩ lại câu chuyện này:

Nếu Mã Lương muốn vẽ một thứ mà cậu chưa từng nhìn thấy, liệu cây bút thần có thể tạo ra nó không?

Giả sử Mã Lương chưa từng nhìn thấy máy bay. Cậu có thể vẽ ra một chiếc máy bay không?

Hoặc nếu cậu chưa từng biết đến máy tính, liệu cậu có thể vẽ ra một chiếc máy tính hoạt động được?

Cây bút có thể biến nét vẽ thành hiện thực, nhưng bản thân Mã Lương vẫn phải biết mình muốn vẽ gì.

Và nếu muốn tạo ra một thứ hoàn toàn nằm ngoài hiểu biết của mình, cậu sẽ phải làm thế nào?

Tôi nghĩ đây là một câu hỏi khá hay để bắt đầu nói về AI.

Bởi vì AI ngày nay đang dần giống một cây bút thần theo nghĩa nào đó. Nhưng có lẽ còn thú vị hơn cây bút của Mã Lương ở một điểm: Nó không chỉ giúp chúng ta tạo ra những thứ mình đã hình dung rõ ràng, mà còn có thể giúp chúng ta khám phá những cách thực hiện mà trước đây mình hoàn toàn không biết đến.

Tôi có một trải nghiệm khá cá nhân với điều này.

Trước đây, tôi từng theo học tại Học viện Kỹ thuật Mật mã, nhưng chỉ được một năm.

Mà năm đầu tiên ở đại học thì mọi người cũng biết rồi đấy, phần lớn thời gian dành cho những môn đại cương như Toán cao cấp, Triết học, Tin học văn phòng và một số môn cơ sở khác. Tôi chưa thực sự được học những kiến thức lập trình chuyên sâu, càng chưa có nền tảng tương đương với một kỹ sư phần mềm được đào tạo bài bản.

Nói cách khác, nếu xét về giáo dục chính quy, kiến thức lập trình của tôi khá hạn chế.

Tôi có những người bạn dành năm năm đại học để học kỹ thuật, lập trình và những kiến thức chuyên ngành. Họ phải trải qua rất nhiều môn học, bài tập, đồ án và những đêm ngồi sửa code.

Còn tôi thì không có quá trình đào tạo tương tự.

Nhưng sau vài năm tự tìm hiểu và sử dụng AI, tôi nhận ra mình đã có thể bắt tay vào thực hiện nhiều công việc mà trước đây tôi nghĩ chỉ những người có nền tảng kỹ thuật bài bản mới làm được.

Tôi có thể xây dựng những sản phẩm phần mềm, làm việc với code, kết nối các hệ thống, xử lý những vấn đề kỹ thuật và hoàn thành những đầu việc có kết quả tương tự công việc mà các bạn tôi được đào tạo để thực hiện.

Tất nhiên, điều đó không có nghĩa là tôi sở hữu toàn bộ kiến thức của một kỹ sư đã học năm năm đại học.

Tôi vẫn có rất nhiều lỗ hổng kiến thức. Có những vấn đề mà một người được đào tạo bài bản có thể hiểu ngay bản chất, trong khi tôi phải mất thời gian tìm hiểu, đặt câu hỏi và kiểm chứng.

Và AI cũng không tự động biến một người không biết gì thành chuyên gia.

Tôi nghĩ nếu bản thân không có tính tò mò, không chịu khó học hỏi, không muốn hiểu tại sao một thứ hoạt động hoặc không hoạt động, thì dù có công cụ tốt đến đâu, kết quả cũng sẽ khá hạn chế.

Nhưng điều đáng nói là trước đây, việc thiếu một số kỹ năng nhất định có thể khiến tôi không thể bắt đầu một dự án. Còn bây giờ, nó thường chỉ có nghĩa là tôi sẽ phải tìm cách học và giải quyết vấn đề đó trong quá trình thực hiện.

Đây là hai trạng thái rất khác nhau.

Và nó khiến tôi suy nghĩ khá nhiều về ý nghĩa của chuyên môn trong thời đại AI.

Nếu một người không biết sử dụng Blender vẫn có thể dựng một môi trường 3D, một người không biết sáng tác nhạc vẫn có thể tạo ra nhạc nền, hay một người không được đào tạo bài bản về lập trình vẫn có thể xây dựng phần mềm, thì rốt cuộc điều gì đang thay đổi?

Có phải các kỹ năng ấy không còn quan trọng?

Hay chúng ta đang bước vào một thời kỳ mà khả năng hình dung, đặt câu hỏi, học hỏi và đánh giá kết quả bắt đầu có vai trò khác trước rất nhiều?

Gần đây, tôi đọc bài Made by mechanical means của Felix Rieseberg, xuất bản ngày 27/9/2026, và thấy câu chuyện của anh khá gần với những gì mình đã trải nghiệm.

Felix là một kỹ sư phần mềm chuyên nghiệp, hiện làm việc tại Anthropic. Nhưng trong bài viết này, anh kể về việc thiết kế lại toàn bộ website cá nhân bằng Claude mà không trực tiếp viết hay chạy code, không mở GitHub, thậm chí không sử dụng Claude Code theo cách thông thường.

Anh tạo ra một website 3D mô phỏng căn phòng của một nhà báo người Đức những năm 1990, với máy tính cũ, TV, đầu phát VHS, máy nghe nhạc, ánh sáng tương tác và cả một đoạn phim CGI nhại lại phim tài liệu của Werner Herzog.

Điều thú vị là Felix không biết sử dụng Blender, cũng không biết sáng tác nhạc.

Nhưng anh vẫn tạo ra được cả hai.

Khoảng 60 luồng Claude đã tham gia vào dự án, nhiều luồng hoạt động song song. Một phần đáng kể công việc được anh điều phối ngay trên điện thoại, trong lúc đạp xe hoặc dừng lại uống cà phê.

Quá trình thiết kế lại trang chủ trong 90 giây.

Điều khiến tôi quan tâm không chỉ là website cuối cùng trông như thế nào, mà là cách anh làm ra nó.

Bởi câu chuyện này dường như cho thấy một thay đổi lớn hơn đang diễn ra: Chúng ta đang dần chuyển từ việc trực tiếp sử dụng công cụ để tạo ra sản phẩm, sang việc điều phối những hệ thống có thể sử dụng công cụ thay mình.

Và nếu quay lại với câu chuyện Mã Lương, có lẽ chúng ta đang tiến gần hơn đến một phiên bản cây bút thần mà người sử dụng không nhất thiết phải biết cách vẽ mọi thứ trước khi bắt đầu.

1. Từ sử dụng AI như một công cụ đến giao cho AI quản lý cả dự án

Một trong những điều Felix nhận thấy khi làm việc tại đội ngũ phát triển Claude là mọi người không còn chỉ quan tâm đến những tính năng mới.

Họ muốn biết anh đang sử dụng Claude như thế nào, nên tổ chức công việc ra sao và liệu có những “câu thần chú” nào giúp AI làm được nhiều điều hơn không.

Câu trả lời trong bài viết không thực sự nằm ở một prompt đặc biệt.

Nó nằm ở cách tổ chức công việc.

Felix bắt đầu bằng việc tạo một Claude Project mới. Trong môi trường anh sử dụng, Project đóng vai trò như một lớp điều phối chung cho Chat, Cowork và Code.

Thay vì tự mình quản lý hàng chục cuộc trò chuyện riêng lẻ, anh giao cho một Claude phụ trách toàn bộ dự án. Claude này có thể mở thêm các phiên làm việc, phân chia nhiệm vụ, chia sẻ dữ liệu và bộ nhớ giữa các phiên, rồi theo dõi tiến độ chung.

Đầu năm 2026, Felix vẫn còn đùa rằng mình hoàn thành được rất nhiều việc bằng cách bảo một đống Claude làm việc.

Nhưng đến tháng 9, anh đã thay đổi cách tiếp cận.

Giờ đây, mỗi dự án có một Claude chịu trách nhiệm chính. Claude đó tự quản lý những nhiệm vụ, các cuộc điều tra và những luồng công việc bên dưới.

Nói cách khác, anh bắt đầu nói nhiều hơn về mục tiêu, và ít phải nói hơn về cách thực hiện.

Tôi thấy điều này khá gần với ý tưởng Altitude trong bài viết trước của Felix về việc trở nên tham vọng hơn khi sử dụng AI.

Thay vì giao từng nhiệm vụ nhỏ, chúng ta giao một kết quả cần đạt được và tạo điều kiện để hệ thống tự tìm cách thực hiện.

Ảnh chụp cách Felix tổ chức Claude Project trong bài gốc.
Ảnh chụp cách Felix tổ chức Claude Project trong bài gốc.

Mỗi Claude có một máy tính riêng

Điều làm mô hình làm việc này trở nên khả thi là mỗi luồng Claude có thể sử dụng một máy tính trên đám mây.

Nếu cần dựng hình 3D, nó cài Blender.

Nếu cần xử lý video, nó sử dụng FFmpeg.

Nếu cần kiểm tra website, nó dùng Playwright để điều khiển trình duyệt, chụp ảnh màn hình và đánh giá kết quả.

Các luồng làm việc chia sẻ một thư mục dữ liệu và một bộ nhớ chung. Khi Felix đưa ra một quyết định thiết kế, Claude có thể ghi lại để những luồng được tạo sau đó tiếp tục tuân theo mà không cần anh phải giải thích lại.

Sau mỗi vòng chỉnh sửa, hệ thống xuất bản một bản xem trước riêng tư. Felix có thể mở nó trên máy tính hoặc điện thoại, kiểm tra kết quả rồi đưa ra nhận xét.

Anh kể rằng đôi khi mình đang đạp xe, nghĩ ra một ý tưởng, gửi nhanh cho Claude rồi đến điểm dừng uống cà phê tiếp theo mới mở điện thoại xem kết quả.

Đây là một hình thức làm việc khá khác với cách sử dụng AI mà nhiều người đã quen.

Chúng ta thường ngồi trước máy tính, đưa ra yêu cầu, chờ câu trả lời, sao chép kết quả rồi tiếp tục làm việc.

Trong trường hợp này, AI không chỉ tạo ra câu trả lời. Nó đang vận hành một quy trình sản xuất thực sự.

Và người sử dụng không nhất thiết phải có mặt liên tục để điều khiển từng bước.

2. Bắt đầu bằng ý tưởng, không phải bằng công nghệ

Khi thiết kế lại website, Felix không bắt đầu bằng việc chọn framework, thư viện JavaScript hay công nghệ dựng hình.

Anh bắt đầu như cách mình sẽ làm việc với một nhóm thiết kế: Đặt lên bàn thật nhiều nguồn cảm hứng.

Poster rave những năm 1990, những bộ phim anh thích, các quảng cáo gây ấn tượng, những bức ảnh thường xuyên xem lại, và cả những ý tưởng trừu tượng chưa có hình dạng rõ ràng.

Sau đó, anh để khoảng 10 luồng Claude khám phá các hướng thiết kế khác nhau, gần như song song và với rất ít chỉ dẫn.

Một hướng tạo ra website portfolio cho người yêu thích cắm trại trong các công viên quốc gia.

Một hướng khác tưởng tượng website sẽ trông như thế nào nếu được thiết kế theo phong cách Ghost in the Shell những năm 1980.

Cả hai đều thú vị, nhưng Felix cảm thấy chúng hơi quen thuộc.

Anh không muốn sao chép một thứ đã tồn tại. Anh muốn tạo ra một thứ mới.

Mỗi khi thấy một hướng có tiềm năng, anh yêu cầu Claude tiếp tục khám phá và tạo thêm năm biến thể.

Cuối cùng, có khoảng 25 bản thử nghiệm ý tưởng.

Ảnh ghép 20 trong số 25 phương án thiết kế ban đầu. Góc trên bên trái là hướng VHS sau này được chọn.
Ảnh ghép 20 trong số 25 phương án thiết kế ban đầu. Góc trên bên trái là hướng VHS sau này được chọn.

Tôi thích cách làm này vì nó đảo ngược một thói quen khá phổ biến khi thực hiện dự án cá nhân.

Thông thường, chúng ta có một ý tưởng, nhanh chóng chọn phương án đầu tiên có vẻ khả thi rồi bắt đầu xây dựng. Càng đầu tư nhiều công sức, chúng ta càng ngại thay đổi hướng đi.

Nhưng nếu chi phí tạo ra một bản thử nghiệm giảm xuống đáng kể, tại sao phải cam kết quá sớm?

Thay vì dành một tuần xây dựng một ý tưởng để rồi phát hiện mình không thích nó, chúng ta có thể thử 10 hoặc 20 hướng khác nhau trước khi quyết định.

Điều này không bảo đảm sẽ có ý tưởng tốt. Nhưng nó cho phép chúng ta khám phá nhiều khả năng hơn trong cùng một khoảng thời gian.

Từ băng VHS đến một căn phòng của thập niên 1990

Felix thích những món đồ công nghệ cũ: Game Boy, máy nghe đĩa than, Walkman và những thiết bị điện tử mang cảm giác của một thời đại đã qua.

Khi được giao nhiệm vụ nghĩ ra một cách trình bày portfolio sáng tạo, Claude đề xuất sử dụng băng VHS.

Mỗi dự án trong portfolio sẽ trở thành một cuốn băng.

Bản thử nghiệm portfolio sử dụng các cuốn băng VHS.
Bản thử nghiệm portfolio sử dụng các cuốn băng VHS.

Felix thích ý tưởng đó, nhưng muốn đặt chúng trong một không gian có câu chuyện riêng.

Anh hình dung một căn phòng giống bối cảnh mà một bộ phim Đức những năm 1990 có thể dành cho nhân vật nhà báo: bàn làm việc, máy tính cũ, TV, đầu phát VHS, điện thoại và những đồ vật thường thấy trong thời kỳ ấy.

Claude kết hợp ý tưởng băng VHS với hình dung về căn phòng, rồi sử dụng Blender để tạo ra bản thử nghiệm.

Bản thiết kế thứ hai, đã có hình dáng gần với căn phòng cuối cùng.
Bản thiết kế thứ hai, đã có hình dáng gần với căn phòng cuối cùng.

Điều đáng ngạc nhiên là bản nháp thứ hai, xuất hiện chỉ 39 phút sau yêu cầu ban đầu, đã khá giống với website cuối cùng.

Tất nhiên, sản phẩm được công bố vẫn cần khoảng 60 vòng chỉnh sửa.

Nhưng tôi nghĩ chi tiết 39 phút rất đáng chú ý.

Trước đây, khoảng thời gian đó có lẽ chỉ đủ để một nhóm thiết kế thảo luận ý tưởng và phác thảo vài bản wireframe.

Giờ đây, nó có thể đủ để tạo ra một bản mẫu có thể nhìn thấy và tương tác, dù vẫn còn nhiều vấn đề cần hoàn thiện.

AI không loại bỏ quá trình sáng tạo và chỉnh sửa. Nó khiến chúng ta có thể bắt đầu quá trình đó từ một điểm gần với sản phẩm hoàn chỉnh hơn rất nhiều.

3. Làm việc với Blender mà không biết sử dụng Blender

Đây có lẽ là phần khiến tôi ấn tượng nhất trong toàn bộ câu chuyện.

Felix không biết sử dụng Blender.

Anh không biết cách dựng mô hình 3D, thiết lập vật liệu, ánh sáng hay điều chỉnh các thông số render.

Nhưng điều đó không ngăn anh tạo ra một căn phòng 3D khá phức tạp.

Cách làm rất đơn giản về mặt tương tác: Anh mô tả điều mình muốn, Claude viết code để điều khiển Blender, render hình ảnh, rồi anh đưa ra phản hồi.

Dĩ nhiên, những gì xảy ra bên dưới không hề đơn giản.

Căn phòng cuối cùng được tạo ra bằng khoảng 3.000 dòng Python, sử dụng Blender như một thư viện lập trình thay vì thao tác trực tiếp qua giao diện.

Một số thành phần đáng chú ý gồm:

  • Một cuốn băng VHS với kích thước 187 × 103 × 25 mm, có vỏ rỗng, cuộn băng, dải băng từ, các bộ phận dẫn hướng và nắp chắn bụi.
  • Một bàn làm việc của nhà báo thập niên 1990, với điện thoại có máy trả lời tự động dùng băng microcassette, danh bạ xoay Rolodex, đĩa mềm, máy nhắn tin, máy tính năng lượng mặt trời, Discman và Walkman.
  • Một chiếc PC màu be kiểu cuối thập niên 1980, thuộc thương hiệu hư cấu, với hai ổ đĩa 5,25 inch, khóa vật lý, công tắc màu đỏ, màn hình CRT xanh 14 inch và bàn phím kiểu XT.
  • Phần phía sau căn phòng, vốn chỉ xuất hiện trong hình phản chiếu hoặc khi người xem tự xoay góc nhìn, với cửa bốn tấm, chìa khóa cắm trong ổ, ánh sáng lọt qua khe cửa, công tắc Bakelite và lò sưởi lát gạch.

Claude tự quyết định khi nào nên tìm mô hình 3D có giấy phép sử dụng phù hợp trên Internet và khi nào nên tự dựng từ đầu.

Một số đồ nội thất được lấy từ Poly Haven với giấy phép CC0, nhưng phần lớn những đồ vật chính đều do Claude tạo ra bằng code.

Ngay cả các bề mặt gỗ, thạch cao, nhựa và kim loại cũng không đơn giản là ảnh chụp được dán lên mô hình. Chúng được tạo bằng các thuật toán sinh vật liệu.

Toàn cảnh căn phòng được dựng trong Blender.
Toàn cảnh căn phòng được dựng trong Blender.

Tôi nghĩ đây là một ví dụ rất rõ về việc AI đang làm mờ ranh giới giữa các lĩnh vực chuyên môn.

Một người có thể không biết thao tác với công cụ, nhưng vẫn có thể sử dụng nó thông qua một hệ thống đủ khả năng chuyển ý định thành những thao tác kỹ thuật cụ thể.

Tuy nhiên, điều này không có nghĩa là kiến thức chuyên môn trở nên vô giá trị.

Ngược lại, khi công việc kỹ thuật được tự động hóa nhiều hơn, khả năng nhận ra điều gì chưa đúng, hiểu tại sao một kết quả chưa đạt yêu cầu và hình dung ra phiên bản tốt hơn có thể trở nên quan trọng hơn.

Khi yêu cầu về thẩm mỹ dẫn đến một giải pháp kỹ thuật phức tạp

Felix muốn căn phòng trông chân thực, đặc biệt là ánh sáng.

Anh muốn ánh sáng mềm, có độ phản xạ tự nhiên giữa các bề mặt, giống một căn phòng thực sự.

Nhưng nếu tính toán toàn bộ ánh sáng đó theo thời gian thực trong trình duyệt, website có thể trở nên quá nặng đối với máy tính của người xem.

Claude chọn một phương án khác.

Nó sử dụng Cycles, bộ dựng hình path tracing của Blender, để tính toán ánh sáng trước, sau đó lưu kết quả vào các texture.

Mỗi bề mặt tĩnh có thêm một bộ tọa độ UV để chứa thông tin ánh sáng. Những bản đồ này lưu riêng màu vật liệu, ánh sáng từ đèn bàn và môi trường, ánh sáng từ TV, cùng trạng thái khi đèn bàn tắt.

Khi người dùng phát một cuốn băng có hình ảnh màu xanh, ánh sáng từ TV cũng có thể khiến căn phòng chuyển sang sắc xanh tương ứng.

Các vật thể chuyển động như băng VHS, núm điều khiển, cửa đầu phát, đèn LED và màn hình vẫn được chiếu sáng theo thời gian thực.

Căn phòng được render với TV tắt, thể hiện hệ thống ánh sáng tính toán trước.
Căn phòng được render với TV tắt, thể hiện hệ thống ánh sáng tính toán trước.
Các bản đồ texture và ánh sáng.
Các bản đồ texture và ánh sáng.

Đây là một giải pháp kỹ thuật không hề đơn giản.

Nhưng điều Felix phải làm ở cấp độ ý tưởng chỉ là liên tục yêu cầu căn phòng trông chân thực hơn.

Tất nhiên, AI không phải lúc nào cũng tự chọn được phương án tối ưu. Và với những công việc 3D nặng, Felix vẫn lưu ý rằng sử dụng máy tính có GPU chuyên dụng sẽ giúp render nhanh hơn nhiều so với chỉ dựa vào môi trường đám mây thông thường.

Nhưng việc một yêu cầu thẩm mỹ có thể được chuyển thành cả một quy trình kỹ thuật phức tạp mà người đưa ra yêu cầu không cần trực tiếp viết code vẫn là điều rất đáng suy nghĩ.

4. Không cần biết trước giải pháp nào tốt nhất nếu có thể thử tất cả

Một phần khác của website là khung cảnh thành phố nhìn qua cửa sổ.

Felix có những yêu cầu khá cụ thể: Cảnh vật phải chân thực, có cảm giác sống động, nhưng không được tiêu tốn quá nhiều tài nguyên CPU và GPU của người truy cập.

Có nhiều cách để thực hiện điều đó.

Có thể dùng một bức ảnh tĩnh.

Có thể dựng toàn bộ thành phố bằng Blender.

Có thể tạo các tòa nhà bằng thuật toán.

Hoặc kết hợp hình ảnh thật với những lớp hiệu ứng chuyển động.

Nếu tự làm, có lẽ chúng ta sẽ dành khá nhiều thời gian để nghiên cứu ưu nhược điểm rồi chọn một phương án trước khi bắt đầu.

Felix làm theo cách khác: Anh để Claude thử tất cả.

Bản đầu tiên sử dụng một bức ảnh đường chân trời Berlin của Billie Grace Ward.

Sau đó, anh thử dựng cả đường chân trời bằng Blender. Kết quả khá tốt, nhưng vẫn không đẹp bằng bức ảnh thật.

Vì vậy, anh bỏ hướng đó.

Ảnh so sánh các phương án cảnh ngoài cửa sổ: ảnh thật, đường phố vẽ bằng code, mái nhà sinh theo thuật toán và cảnh dựng bằng Blender.
Ảnh so sánh các phương án cảnh ngoài cửa sổ: ảnh thật, đường phố vẽ bằng code, mái nhà sinh theo thuật toán và cảnh dựng bằng Blender.

Claude sau đó đề xuất một phương án thú vị hơn: Sử dụng mô hình mã nguồn mở Depth Anything V2 để ước lượng độ sâu từ bức ảnh.

Kết quả là một bản đồ độ sâu chỉ khoảng 50 KB, với hai kênh thông tin.

Một kênh tạo hiệu ứng thị sai mềm, khiến các vật thể ở gần và xa dịch chuyển khác nhau khi góc nhìn thay đổi.

Kênh còn lại có ranh giới sắc nét hơn, cho phép những đoàn tàu được vẽ thêm có thể biến mất phía sau các tòa nhà.

Nhờ vậy, website giữ được vẻ chân thực của ảnh chụp, đồng thời có thêm ánh sáng và chuyển động mà gần như không làm tăng tải CPU.

Bức ảnh gốc và hai bản đồ độ sâu được sử dụng để tạo hiệu ứng chuyển động.
Bức ảnh gốc và hai bản đồ độ sâu được sử dụng để tạo hiệu ứng chuyển động.

Tôi thấy đây là một ví dụ rất hay về cách AI có thể thay đổi quá trình ra quyết định.

Trước đây, việc chọn giải pháp thường phải dựa khá nhiều vào kinh nghiệm và khả năng dự đoán, bởi chi phí thử nghiệm quá lớn.

Nhưng nếu có thể tạo ra nhiều bản thử với chi phí thấp, chúng ta không nhất thiết phải đoán đúng ngay từ đầu.

Chúng ta có thể để các phương án cạnh tranh với nhau bằng kết quả thực tế.

Dĩ nhiên, thử tất cả mọi thứ không phải lúc nào cũng hợp lý. Có những vấn đề mà chi phí thử nghiệm vẫn rất lớn, hoặc rủi ro không cho phép làm như vậy.

Nhưng đối với những công việc sáng tạo và kỹ thuật có thể tạo bản mẫu nhanh, đây có thể là một thay đổi đáng kể.

5. Từ một ý tưởng kỳ quặc đến bộ phim CGI hoàn chỉnh

Phần Felix thích nhất trong toàn bộ dự án là một đoạn phim nhại lại cảnh chú chim cánh cụt trong bộ phim tài liệu Encounters at the End of the World của Werner Herzog.

Trong cảnh phim gốc, một con chim cánh cụt rời khỏi đàn và một mình đi sâu vào đất liền, hướng về những dãy núi.

Đó là một hình ảnh khá kỳ lạ, vừa buồn cười vừa mang cảm giác hiện sinh.

Felix muốn tạo ra một phiên bản nhại lại cảnh này, nhưng thêm vào những chi tiết liên quan đến cuộc đời và công việc của mình.

Anh và Claude bắt đầu bằng một đoạn hoạt hình đơn giản, được vẽ hoàn toàn bằng SVG.

Bản đầu tiên trông giống hoạt hình trẻ con, nhưng nó giúp hai bên thống nhất về câu chuyện, nhịp điệu và kiểu hài hước mà Felix muốn.

Bản hoạt hình chim cánh cụt đầu tiên được vẽ bằng SVG.
Bản hoạt hình chim cánh cụt đầu tiên được vẽ bằng SVG.

Khi ý tưởng đã rõ ràng, anh yêu cầu Claude tạo một phiên bản CGI mô phỏng khá sát cảnh phim gốc trước khi bổ sung các thay đổi.

Theo mô tả của Felix, Claude thực hiện công việc gần giống một nghệ sĩ hiệu ứng hình ảnh chuyên nghiệp.

Nó chia cảnh thành tám đoạn quay, bám theo những điểm cắt của bản gốc.

Nó phân tích chuyển động camera theo từng khung hình, cố gắng tái tạo các chuyển động lia máy, phóng to, thu nhỏ và độ rung của camera cầm tay.

Sau đó, nó dựng toàn bộ môi trường bằng Blender thông qua Python: tuyết, núi, sỏi đá và những con chim cánh cụt.

Cuối cùng, Claude render 2.787 khung hình với độ phân giải 640 × 480, tốc độ 23,976 khung hình mỗi giây, tạo ra một video dài khoảng 116 giây.

Ảnh so sánh cảnh phim tài liệu gốc bên trái và bản dựng CGI bên phải.
Ảnh so sánh cảnh phim tài liệu gốc bên trái và bản dựng CGI bên phải.

Sau khi có phiên bản gần với nguyên tác, Felix bắt đầu thêm những chi tiết gây cười.

Một chiếc bàn có máy tính xuất hiện giữa vùng băng tuyết.

Những lá cờ doanh nghiệp nằm dọc con đường của chú chim cánh cụt, mỗi lá đại diện cho một nơi anh từng làm việc.

Và một vài chi tiết tự trào về việc anh có một blog nhưng mỗi năm chỉ đăng bài mới khoảng một lần.

Hình chim cánh cụt trong phiên bản nhại, với những chi tiết liên quan đến nghề kỹ sư.
Hình chim cánh cụt trong phiên bản nhại, với những chi tiết liên quan đến nghề kỹ sư.

Tôi thích ví dụ này vì nó cho thấy AI không nhất thiết phải tạo ra ý tưởng hài hước thay con người.

Điều Felix cần là khả năng thực hiện một ý tưởng mà trước đây có lẽ anh sẽ không bao giờ đủ thời gian và chuyên môn để biến thành phim.

Anh vẫn phải quyết định điều gì buồn cười, điều gì nên giữ lại, điều gì cần thay đổi và mức độ giống nguyên tác đến đâu là phù hợp.

Nhưng thay vì phải tự học dựng hình, hoạt họa, xử lý camera và render video, anh có thể tập trung vào chính ý tưởng đó.

Và cả âm nhạc cũng được tạo bằng code

Website còn có ba bản nhạc được Claude sáng tác và tổng hợp từ đầu.

Nó không chỉ lựa chọn nhạc có sẵn, mà sử dụng Python để viết bản nhạc rồi xây dựng một bộ tổng hợp âm thanh.

Khi Felix hỏi về phương pháp, Claude trả lời bằng những mô tả khá chuyên sâu về hợp âm, cấu trúc bài hát, âm nền và tần số.

Một bản nhạc sử dụng sáu hợp âm, mỗi hợp âm kéo dài bốn ô nhịp, trong giọng C# thứ, trên nền âm C# ở tần số 34,6 Hz.

Một bản khác có cấu trúc AABA dài 32 ô nhịp.

Felix thừa nhận anh chẳng hiểu những điều đó có nghĩa là gì.

Nhưng anh vẫn có thể đưa ra phản hồi.

“Tôi thích cái này.”

Hoặc:

“Không, hãy làm nó bớt hào hứng đi một chút.”

Anh ví cách phản hồi của mình giống phong cách làm việc của nhà sản xuất âm nhạc Rick Rubin.

Tôi nghĩ đây là một chi tiết nhỏ nhưng rất đáng chú ý.

Chúng ta có thể không biết cách tạo ra một thứ gì đó, nhưng vẫn có khả năng cảm nhận xem nó có đúng với điều mình muốn hay không.

Hai năng lực này không hoàn toàn giống nhau.

Và AI đang khiến khoảng cách giữa chúng trở nên dễ vượt qua hơn.

6. Nếu không đọc code, làm sao biết sản phẩm có tốt?

Đây có lẽ là câu hỏi mà nhiều lập trình viên sẽ quan tâm nhất.

Nếu hàng chục luồng Claude đang đồng thời viết code, tạo mô hình, xử lý hình ảnh và xây dựng website, làm thế nào để Felix kiểm soát chất lượng?

Anh có đọc toàn bộ code không?

Câu trả lời là không.

Và Felix không cố che giấu điều đó.

Anh cho rằng những người từng làm cả kỹ sư lẫn quản lý kỹ thuật có lẽ sẽ dễ hiểu cách tiếp cận này hơn.

Khi quản lý một đội ngũ kỹ sư, bạn không thể trực tiếp kiểm tra từng dòng code mà mọi người viết ra.

Thay vào đó, bạn phải thiết lập những quy trình, tiêu chuẩn và cơ chế kiểm chứng để bảo đảm chất lượng mà không cần quản lý vi mô từng thay đổi.

Felix áp dụng tư duy tương tự cho hệ thống nhiều Claude.

Để các AI kiểm tra lẫn nhau

Anh sử dụng nhiều luồng Claude chuyên làm kiểm thử chất lượng (QA).

Những luồng này liên tục mở website bằng trình duyệt tự động, tương tác với các thành phần, tìm lỗi và ghi lại kết quả.

Tổng cộng, chúng tạo ra khoảng 3.000 dòng ghi chép về các vấn đề phát hiện được.

Claude điều phối chính sẽ xác định luồng nào chịu trách nhiệm cho phần có lỗi rồi chuyển thông tin để sửa chữa.

Các tác nhân kiểm thử tìm ra khá nhiều vấn đề:

  • Những cuốn băng VHS có nhãn trống.
  • Một số đoạn tiếng Đức còn sót lại trong giao diện.
  • Những liên kết vẫn có thể bấm dù đã bị thẻ nội dung khác che phía trên.
  • Lỗi tranh chấp trạng thái khi người dùng chuyển băng quá nhanh.

Không có gì đặc biệt kỳ lạ ở những lỗi này. Chúng khá giống những vấn đề thường gặp trong phát triển phần mềm.

Điểm khác biệt là Felix không cần trực tiếp tìm và sửa từng lỗi.

Anh xây dựng một hệ thống trong đó những tác nhân khác nhau có nhiệm vụ phát hiện, báo cáo và khắc phục vấn đề.

Một Claude riêng lẻ không viết ra code hoàn hảo.

Nhưng một nhóm Claude có cơ chế kiểm tra và chịu trách nhiệm lẫn nhau có thể tạo ra kết quả đạt tiêu chuẩn mà Felix đặt ra.

Giao diện kiểm thử tự động của một phiên bản cũ của căn phòng.
Giao diện kiểm thử tự động của một phiên bản cũ của căn phòng.

Tất nhiên, điều đó không có nghĩa là hệ thống chắc chắn không còn lỗi. Những bộ kiểm thử vẫn có thể bỏ sót vấn đề, đặc biệt nếu tất cả cùng chia sẻ những giả định sai.

Nhưng cách tiếp cận này cho thấy một hướng thay đổi quan trọng trong công việc kỹ thuật.

Chất lượng không nhất thiết phải đến từ việc một người trực tiếp kiểm tra mọi chi tiết. Nó có thể đến từ việc thiết kế một quy trình kiểm chứng đủ tốt.

Tối ưu hiệu suất mà không làm giảm chất lượng hình ảnh

Một ví dụ khác là việc tối ưu hiệu suất website.

Claude được giao những mục tiêu cụ thể như tăng tốc độ khung hình, giảm số lệnh vẽ hoặc giảm chi phí xử lý bóng đổ.

Nhưng có một vấn đề.

Nếu giảm chất lượng hình ảnh để tăng tốc độ, website có thể chạy nhanh hơn nhưng trông xấu đi.

Làm sao biết một phiên bản tối ưu vẫn giữ được chất lượng hình ảnh ban đầu?

Claude đưa ra một giải pháp khá thông minh.

Nó chụp ảnh màn hình của hai phiên bản từ cùng góc nhìn, sau đó tính toán mức độ khác biệt giữa các điểm ảnh.

Bằng cách lặp lại phép so sánh ở nhiều góc nhìn, hệ thống có thể phát hiện những thay đổi hình ảnh không mong muốn trong quá trình tối ưu.

Hình ảnh so sánh sự khác biệt điểm ảnh giữa hai phiên bản website.
Hình ảnh so sánh sự khác biệt điểm ảnh giữa hai phiên bản website.

Đây không phải phương pháp hoàn hảo cho mọi tình huống. Nhưng nó biến một yêu cầu tương đối mơ hồ như “giữ nguyên chất lượng hình ảnh” thành một thứ có thể đo lường và kiểm tra.

Tôi nghĩ đây là một bài học khá quan trọng khi làm việc với AI.

Nếu muốn giao cho AI những nhiệm vụ ngày càng lớn, chúng ta cần tìm cách biến kỳ vọng về chất lượng thành những tiêu chí mà hệ thống có thể tự kiểm chứng.

Không phải chỉ yêu cầu “hãy làm thật tốt”, mà phải xác định điều gì chứng minh rằng kết quả thực sự tốt.

7. Khi người không biết làm một việc lại có thể tạo ra sản phẩm của việc đó

Ở phần cuối bài viết, Felix đề cập đến một cảm giác mà tôi nghĩ không ít người đang trải qua khi chứng kiến sự phát triển của AI.

Đó là cảm giác khó chịu khi thấy một người chưa từng trải qua nhiều năm học lý thuyết và thực hành một kỹ năng nào đó bỗng nhiên có thể tạo ra sản phẩm trong lĩnh vực ấy.

Một nghệ sĩ 3D đã dành nhiều năm học dựng hình có thể cảm thấy không công bằng khi ai đó không biết Blender lại có thể tạo ra cả một căn phòng 3D chỉ trong vài ngày.

Một lập trình viên đã mất nhiều năm học kiến trúc phần mềm có thể thấy kỳ lạ khi người khác xây dựng được ứng dụng mà không trực tiếp viết code.

Một nhạc sĩ có thể đặt câu hỏi liệu việc yêu cầu AI sáng tác và tổng hợp âm thanh có thực sự được xem là làm nhạc hay không.

Tôi nghĩ những cảm giác này khá dễ hiểu.

Đặc biệt khi quá trình học một kỹ năng không chỉ tiêu tốn thời gian, mà còn trở thành một phần trong cách chúng ta nhìn nhận bản thân.

Và ở một mức độ nào đó, chính trải nghiệm của tôi cũng nằm trong câu hỏi này.

Tôi không nghĩ việc mình có thể hoàn thành một số công việc lập trình nhờ AI đồng nghĩa với việc năm năm học kỹ thuật của bạn bè trở nên vô nghĩa.

Họ có những nền tảng kiến thức mà tôi không có. Nếu gặp một vấn đề đòi hỏi hiểu biết sâu về hệ thống, thuật toán hoặc kiến trúc, khoảng cách ấy hoàn toàn có thể bộc lộ.

Nhưng tôi cũng không nghĩ việc thiếu một tấm bằng kỹ sư có nghĩa là tôi không nên thử xây dựng phần mềm.

Có lẽ điều cần phân biệt là năng lực thực hiện một công việc cụ thể và mức độ hiểu biết toàn diện về lĩnh vực đó.

AI có thể giúp một người thu hẹp khoảng cách về khả năng thực hiện, nhưng không tự động xóa bỏ mọi khác biệt về kiến thức, kinh nghiệm và khả năng phán đoán.

Felix cũng không phủ nhận rằng sản phẩm của mình có thể chứa những chi tiết kém chất lượng.

Nếu so sánh một căn phòng được AI dựng trong 24 giờ với một tác phẩm được nghệ sĩ 3D tỉ mỉ xây dựng bằng tay trong nhiều tuần, chắc chắn có thể tìm ra những khác biệt.

Nhưng điều đó dẫn đến một câu hỏi khác.

Liệu giá trị của một sản phẩm sáng tạo nhất thiết phải gắn với mức độ khó khăn của quá trình tạo ra nó?

Chúng ta đã từng tranh luận về điều này

Felix liên hệ câu chuyện với lịch sử nghệ thuật.

Anh nhắc đến một triển lãm về Henri Matisse tại Bảo tàng Nghệ thuật Hiện đại San Francisco, trong đó có tái hiện sự kiện Salon d’Automne năm 1905 ở Paris.

Khi ấy, Matisse và những họa sĩ cùng nhóm từng bị một nhà phê bình gọi là “những con thú hoang”, từ đó gắn với tên gọi của trường phái Dã thú (Fauvism).

Những tác phẩm của họ đi ngược lại nhiều chuẩn mực thẩm mỹ đương thời.

Felix cũng nhắc đến những tranh cãi về nhiếp ảnh khoảng nửa thế kỷ trước đó.

Năm 1859, khi nhiếp ảnh lần đầu xuất hiện tại Paris Salon, nhà thơ Charles Baudelaire đã phản đối mạnh mẽ việc xem ảnh chụp là nghệ thuật.

Theo ông, việc coi một quá trình cơ học là sáng tạo không chỉ sai lầm mà còn đe dọa thị hiếu nghệ thuật Pháp.

Ông mô tả nhiếp ảnh như nơi trú ẩn của những người muốn làm họa sĩ nhưng thiếu năng lực hoặc quá lười biếng để hoàn thành việc học.

Ngày nay, cách nhìn ấy có vẻ khá xa lạ.

Chúng ta không còn cho rằng một bức ảnh không thể là nghệ thuật chỉ vì người chụp không tự tay vẽ ra từng chi tiết.

Máy ảnh thực hiện rất nhiều công việc kỹ thuật, nhưng người chụp vẫn có thể đưa ra những lựa chọn sáng tạo về bố cục, ánh sáng, thời điểm, chủ thể và ý nghĩa.

Dĩ nhiên, AI không hoàn toàn giống máy ảnh. Mức độ tự chủ và khả năng tạo nội dung của các mô hình hiện nay đặt ra những câu hỏi mới về tác quyền, dữ liệu huấn luyện và vai trò của con người.

Nhưng sự tương đồng lịch sử vẫn đáng suy nghĩ.

Mỗi khi một công nghệ mới làm giảm độ khó của một kỹ năng, chúng ta lại phải xem xét lại đâu là phần cốt lõi tạo nên giá trị của công việc đó.

8. Có lẽ sáng tạo không nhất thiết phải bắt đầu bằng việc biết cách làm

Sau khi đọc xong bài viết của Felix, tôi lại nghĩ đến Mã Lương.

Trong câu chuyện cổ tích, cây bút thần có thể biến những nét vẽ thành hiện thực.

Nhưng để vẽ, Mã Lương vẫn cần một hình dung nào đó về thứ mình muốn tạo ra.

Còn khi sử dụng AI, đôi khi tôi thậm chí chưa biết chính xác sản phẩm cuối cùng phải trông như thế nào.

Tôi chỉ biết mình muốn giải quyết vấn đề gì, muốn người sử dụng có trải nghiệm ra sao, hoặc muốn một ý tưởng nào đó trở thành hiện thực.

Những chi tiết còn lại có thể được khám phá trong quá trình làm việc.

AI có thể đề xuất những phương án mà tôi chưa từng nghĩ tới, sử dụng những công cụ mà tôi chưa từng học, và đôi khi khiến tôi phải tìm hiểu thêm một lĩnh vực hoàn toàn mới để hiểu những gì nó vừa thực hiện.

Điều này không khiến tôi ngừng học.

Ngược lại, tôi nhận thấy mình có thêm rất nhiều lý do để học.

Trước đây, việc học một công nghệ mới đôi khi là một quá trình khá trừu tượng. Chúng ta học cú pháp, thuật toán, framework, rồi hy vọng một ngày nào đó sẽ có cơ hội áp dụng.

Còn bây giờ, tôi có thể bắt đầu bằng một dự án mình thực sự muốn làm, gặp vấn đề trong quá trình thực hiện, rồi học chính những kiến thức cần thiết để giải quyết vấn đề đó.

Đó là một cách học rất khác.

Tất nhiên, nó không thể thay thế hoàn toàn việc xây dựng nền tảng kiến thức có hệ thống. Nhưng với một người có tính tò mò và sẵn sàng tìm hiểu, tôi nghĩ đây là một cơ hội rất lớn.

Trước đây, nếu có một ý tưởng cần Blender, lập trình đồ họa, thiết kế âm thanh và dựng phim, có lẽ chúng ta sẽ phải chọn giữa ba phương án.

Một là dành nhiều thời gian học tất cả những kỹ năng ấy.

Hai là tìm những người có chuyên môn phù hợp và trả tiền để họ thực hiện.

Ba là từ bỏ ý tưởng.

AI đang tạo ra một phương án thứ tư.

Chúng ta có thể bắt đầu từ điều mình muốn tạo ra, sau đó để hệ thống tìm kiếm và sử dụng những công cụ phù hợp, trong khi bản thân tập trung vào định hướng, đánh giá và chỉnh sửa.

Điều này không khiến chuyên môn trở nên vô nghĩa.

Một người thực sự hiểu về thiết kế 3D có thể nhận ra những vấn đề mà người không có kinh nghiệm sẽ bỏ qua.

Một kỹ sư giỏi có thể xây dựng những tiêu chuẩn kiểm chứng tốt hơn và hiểu rõ những rủi ro mà AI chưa nhận ra.

Một nhạc sĩ có thể đưa ra những chỉ dẫn tinh tế hơn về hòa âm, nhịp điệu và cấu trúc.

Nhưng có lẽ chúng ta không còn cần phải thành thạo mọi công cụ trước khi được phép thử một ý tưởng.

Và tôi nghĩ đó là một thay đổi khá lớn.

Trong bài viết trước, Felix nói về việc chúng ta cần tham vọng hơn khi sử dụng AI, không chỉ làm những việc cũ nhanh hơn mà còn dám theo đuổi những mục tiêu lớn hơn, đi sâu hơn vào vấn đề và kết hợp kiến thức từ nhiều lĩnh vực.

Made by mechanical means gần như là một ví dụ thực tế cho những ý tưởng ấy.

Anh không bắt đầu bằng câu hỏi “Làm thế nào để AI giúp tôi viết code nhanh hơn?”

Anh bắt đầu bằng việc tưởng tượng ra một website mình thực sự muốn có, rồi để AI tìm cách biến nó thành hiện thực.

Và trong quá trình đó, anh đã sử dụng những công cụ và kỹ thuật thuộc nhiều lĩnh vực mà bản thân không trực tiếp thành thạo.

Tôi nghĩ đây cũng là điều đáng để chúng ta thử áp dụng.

Thay vì luôn bắt đầu bằng câu hỏi “Mình có biết làm việc này không?”, có lẽ đôi khi nên bắt đầu bằng câu hỏi:

“Mình có thực sự muốn tạo ra thứ này không?”

Nếu câu trả lời là có, hãy thử xem những công cụ hiện tại có thể giúp mình đi xa đến đâu.

Có thể kết quả đầu tiên sẽ rất tệ.

Có thể AI sẽ mắc lỗi, hiểu sai yêu cầu hoặc tạo ra một sản phẩm đầy những chi tiết chưa hoàn thiện.

Nhưng ít nhất, chúng ta có thể bắt đầu.

Và nếu chi phí thử nghiệm đủ thấp, việc thất bại ở phiên bản đầu tiên cũng không còn là lý do quá lớn để từ bỏ.

Felix kết thúc bài viết bằng một lời tự trào khá thú vị.

Có thể anh thực sự thiếu kỹ năng hoặc quá lười để tự thiết kế lại toàn bộ website từ đầu, đúng như cách Baudelaire từng chỉ trích những người sử dụng nhiếp ảnh.

Nhưng cuối cùng, anh vẫn ngồi đó, khá tự hào về trang chủ mới của mình.

Nó được tạo ra hoàn toàn bằng những phương tiện cơ học, nhưng lại trông đúng như những gì anh hình dung trong đầu chỉ 48 giờ trước đó.

Và anh rất háo hức khoe nó với bạn bè.

Tôi nghĩ cảm giác ấy cũng là một phần quan trọng của sáng tạo.

Không phải niềm tự hào vì đã tự tay thực hiện từng thao tác kỹ thuật, mà là niềm vui khi một thứ trước đây chỉ tồn tại trong trí tưởng tượng cuối cùng đã trở thành hiện thực.

Có lẽ điều khiến tôi thích thú nhất với AI cũng nằm ở đó.

Tôi không biết liệu Mã Lương có thể dùng cây bút thần để vẽ ra một thứ mà cậu chưa từng nhìn thấy hay không.

Nhưng với AI, tôi bắt đầu nhận ra rằng mình không nhất thiết phải biết trước toàn bộ cách làm để bắt đầu tạo ra một thứ gì đó.

Đôi khi, chính quá trình tạo ra nó sẽ giúp tôi khám phá những điều mình chưa biết.

Và có lẽ cây bút thần thú vị nhất không phải là cây bút có thể vẽ ra mọi thứ, mà là cây bút khiến người cầm nó bắt đầu nghĩ đến những điều mà trước đây họ chưa từng dám vẽ.


Bài viết được viết lại và mở rộng từ góc nhìn cá nhân sau khi đọc “Made by mechanical means” của Felix Rieseberg, xuất bản ngày 27/9/2026. Các chi tiết về dự án, công cụ và quy trình làm việc được thuật lại từ bài gốc. Những liên tưởng đến câu chuyện Mã Lương, trải nghiệm học lập trình và suy ngẫm về AI là góc nhìn cá nhân của tôi.

Các vị trí ảnh minh họa được đánh dấu theo trình tự xuất hiện trong bài gốc. Nên sử dụng ảnh từ bài của Felix kèm ghi nguồn và kiểm tra quyền tái sử dụng trước khi đăng lại.

Để lại bình luận