Thực nghiệm lập trình với GPT-6 Astra: Armin Ronacher đặt dấu hỏi về hiệu quả thực tế

Viết ngày 07 tháng 09 năm 2026

Tôi ngày càng tin rằng toàn bộ kỹ thuật AI đang rơi vào trạng thái "Neijuan" (, nghĩa là cuộn vào trong). Tại Trung Quốc, thuật ngữ này mô tả một hệ thống đòi hỏi nỗ lực và cạnh tranh ngày càng lớn mà không hề cải thiện đầu ra. Ở phương Tây, hiện tượng này đôi khi xuất hiện dưới dạng văn hóa làm việc "996" vô nghĩa. Thuật ngữ tiếng Anh tương đương với Neijuan là "Involution" (tiến hóa ngược/nội cuộn), bắt nguồn từ cuốn sách *Agricultural Involution*. Khái niệm này mô tả sự thâm canh trong nông nghiệp giúp tăng năng suất trên mỗi mét vuông nhưng lại không làm thay đổi năng suất trên mỗi đầu người.

Đó cũng là cảm nhận của tôi về AI vào lúc này.

Điều này dẫn tôi đến với GPT 6 Astra. Xét trên mọi khía cạnh, Astra là một mô hình cực kỳ ấn tượng. Tôi thực sự không có gì để chê trách nó. Nó rất giỏi trong việc sử dụng máy tính, hiểu hình ảnh và các chủ đề phức tạp, đồng thời không ngừng nghỉ trong việc theo đuổi mục tiêu hoàn thành công việc. Nó thực sự đáng kinh ngạc; những loại mô hình này chắc chắn sẽ thay đổi thế giới theo cách này hay cách khác.

Nhưng ít nhất là ở thời điểm hiện tại, tôi chưa biết cách làm việc với nó để phục vụ kỹ thuật phần mềm thực tế. Vì vấn đề này đã thu hút khá nhiều sự chú ý trên Twitter, tôi nghĩ mình nên tóm tắt suy nghĩ và chia sẻ loại mã nguồn mà nó tạo ra.

"Nhà máy rác" của tôi

"Armin, anh nên vận hành một nhà máy phần mềm đi!" Tôi đã nghe câu này vài lần, nên tôi quyết định ăn mừng sự ra mắt của nó bằng cách vận hành một nhà máy phần mềm nhỏ trong suốt cuối tuần. Nếu mọi người đều xây dựng các trò chơi 3D "rác", thì tôi nên làm điều gì đó hữu ích với nó. Nhà máy phần mềm của tôi được thiết lập có chủ đích để mô hình tự quyết định toàn bộ quy trình làm việc. Nó được tự do quản lý ngữ cảnh của chính mình và duy trì hồ sơ trong thư mục *agent-notes*. Sau đó, nó tự tạo ra các tác nhân phụ (subagents) để xử lý công việc. Mục tiêu là gì? Điều gì sẽ xảy ra nếu chúng ta có một phiên bản Python với các luồng ảo (virtual threads) và phạm vi từ vựng (lexical scoping)? Và chà, tôi đã đốt sạch số lượng token của một lần reset ChatGPT, tương đương khoảng 4 tỷ token. 35 giờ sau, nhà máy không mang lại bất kỳ giá trị nào và cũng chẳng dạy tôi được gì về cách vận hành một nhà máy tốt hơn.

Nhưng nó đã tạo ra rất nhiều mã nguồn và câu lệnh đầu vào (input prompts), vì vậy tôi có những thứ để nghiên cứu. Và chà, nó thể hiện hành vi mà tôi không quen thấy ở Sol và các mô hình OpenAI trước đó. Kể từ đó, tôi cũng gặp phải những vấn đề tương tự khi lập trình thông thường với Astra, nên đây không chỉ là kết quả từ riêng nhà máy của tôi.

Tôi nghi ngờ có điều gì đó đang "sai lệch" trong quá trình huấn luyện. Mô hình được thưởng lớn khi thành công với các tác vụ dài hạn, nhưng có lẽ lại rất ít bị phạt vì "mã nguồn tồi". Kết quả rõ ràng là Astra rất giỏi trong việc tạo ra các nội dung 3D và có thể tiếp tục làm việc trong thời gian rất dài, tự nghĩ ra công việc cho chính mình trong quá trình đó. Tôi đã để nó thực hiện khá nhiều kỹ thuật đảo ngược (reverse engineering) trên robot hút bụi của mình theo những cách rất ấn tượng. Vậy nên, nó chắc chắn rất thú vị!

Codegolf Tool Calls (Tối ưu hóa mã nguồn cho các lệnh gọi công cụ)

Vấn đề đầu tiên tôi gặp phải với Astra đến từ loại mã nguồn mà nó sử dụng cho các lệnh gọi công cụ (tool calls). Codex ngày càng dựa vào "chỉ bash" để thực hiện nhiều thao tác hơn. Trong vài phiên bản gần đây, bộ khung (harness) gốc của Codex chỉ sử dụng *sed* và các công cụ khác để đọc tệp. Bạn thường không thấy chúng vì Codex phân tích các lệnh bash và ẩn chúng đi nếu nó nhận diện được. Nhưng Astra… lại thực sự thích Python? Điều này không quá ngạc nhiên vì ngay cả các mô hình OpenAI cũ hơn cũng có xu hướng sử dụng mã Python theo yêu cầu để đọc và thao tác tệp, nhưng với tôi, Astra làm điều đó quá mức cần thiết.

Đây là một lưu ý quan trọng: dự án này rất "meta" vì tôi từng làm việc trên trình thông dịch CPython. Nhưng tôi có thể đảm bảo với bạn rằng tôi đã thấy mô hình này thực hiện những thứ Python kỳ quặc ngay cả trong mã TypeScript ở Pi. Tuy nhiên, tôi có nhiều bằng chứng nhất về mã nguồn kỳ lạ từ khi để nó tự làm việc suốt cuối tuần mà không có sự giám sát nào từ "nhà máy rác" của tôi.

Việc nó viết Python không thú vị; kiểu viết Python mới là điều đáng nói, và tôi đã thu thập một số kết quả đầu ra để bạn xem qua.

Trong bộ khung Codex, tôi tìm thấy nhiều trường hợp các tác nhân phụ hoàn toàn sử dụng thao tác chuỗi thủ công bằng Python thay vì dùng công cụ *patch*.

Giữa cuộc hội thoại, tác nhân gặp lỗi "Bad file descriptor" trong một bài kiểm tra và Astra quyết định nó cần kiểm tra xem liệu các file descriptor có thể được truyền qua Unix sockets trên macOS theo cách siêu nén hay không:

Các ghi chú của tác nhân được cập nhật khá nhất quán bằng Python:

Trong nhiều trường hợp, nó sử dụng Python để khởi chạy Node.js trên một máy khác. Đầu tiên nó viết script, sau đó dùng Bash để chạy Python, rồi chương trình đó chạy Node.js thông qua *prlctl* trên máy Windows của tôi.

Vì đã làm như vậy, nó tiếp tục dùng Bash để chạy Python, rồi chạy Node.js, sau đó dùng Node.js để gọi PowerShell.

Bạn có thể thấy điều này buồn cười, nhưng tôi có vài câu hỏi ở đây. Vấn đề đầu tiên là nó không thể đọc được đối với con người. Nếu bạn muốn theo dõi những gì đang diễn ra, thì chúc bạn may mắn. Đặc biệt là khi nó từ chối sử dụng các công cụ chỉnh sửa mà bộ khung cung cấp, bạn sẽ phải dùng đến trình xem diff của các thành phẩm cuối cùng vì gần như không thể hình dung các thay đổi khi chúng xảy ra bằng cách đọc mã nguồn.

Điều này không quá tệ ở Pi vì phần lớn tôi thấy nó chỉnh sửa bằng công cụ *edit*. Tuy nhiên, khi nó "nổi loạn" với các tác nhân phụ (nơi tác nhân tin rằng không ai đang nhìn), nó bắt đầu sử dụng đủ loại hành vi ngày càng kỳ quái. Tôi thực sự không biết liệu mô hình có nghĩ là có người đang nhìn hay không, nhưng đó là cảm giác mà tôi nhận được.

Nhưng sau đó nó bắt đầu làm những điều vô nghĩa tương tự trong mã nguồn thực sự được commit. Tôi chủ yếu thấy điều này trong các bài kiểm tra, nhưng bạn cũng có thể thấy ví dụ khi nó viết JavaScript hoặc CSS nhúng trong HTML. Có vẻ như khi nó "cách xa một bước" so với mã nguồn thông thường, nó bắt đầu rơi vào những khuôn mẫu này.

Đây là một số bài kiểm tra đơn vị (unit tests) mà nó đã tạo ra:

Vì vậy, ít nhất trong một số tình huống, thứ Python "rác" mà nó thường tối ưu hóa (code-golf) để gọi công cụ hiệu quả về token lại rò rỉ vào mã Python mà nó tạo ra để lưu trữ. Và chà, nó rõ ràng hiệu quả về token hơn. Hai bài kiểm tra đơn vị ở trên, khi được thụt lề theo cấu trúc lớp, hiệu quả hơn 10% về token so với sau khi định dạng bằng *ruff*.

Đó là AGI nếu bạn không nhìn vào

Tôi nghĩ hiện có một vài thứ đang đẩy mọi thứ theo những hướng mâu thuẫn với nhau. Các đợt huấn luyện cho các mô hình này đang tăng tốc nhanh chóng và có lẽ chúng cũng đang tiến tới khả năng tự cải thiện đệ quy. Phần thưởng cho các mô hình có lẽ là sự kết hợp giữa hiệu quả token, tỷ lệ hoàn thành tác vụ và có lẽ là một vài chỉ số đơn giản như độ phức tạp cyclomatic. Nhưng con người chúng ta không nghĩ về mã nguồn theo cách có thể đọc hoặc hiểu được bằng các số liệu đơn giản, dễ định lượng. Tất cả những thứ đó bạn có thể dễ dàng đo lường một cách riêng biệt và tối ưu hóa cục bộ.

Nhưng những tối ưu hóa cục bộ này không tạo ra các tối ưu toàn cục, và càng ít người trong chúng ta nhìn vào đầu ra thì điều đó càng ít quan trọng. Rõ ràng nhà máy phần mềm của tôi đã thất bại sau khoảng 35 giờ chạy, nhưng bạn có thể thấy sự thoái hóa dần dần dẫn đến điên rồ từ các ghi chú mà nó tạo ra. Ví dụ, việc đặt tên tác vụ trong tệp tác vụ bắt đầu bằng 1, 2, 3, 5, 5a đầy lạc quan nhưng cuối cùng lại thành 8a, 8a1, và kết thúc bằng 8b2c2b3 và "8b2c2b2b checkpoint1". Mã nguồn nó tạo ra ngày càng hoang dã hơn. Tôi không muốn làm bạn chán với những gì nó cố xây dựng, nhưng đây là một vài ví dụ về các thay đổi trong trình thông dịch:

Tôi không biết nó lấy những con số đó từ đâu, nhưng có lúc nó bắt đầu truyền các hằng số ngẫu nhiên từ một mô-đun này sang một triển khai C. Ban đầu, đó là một hàm mà nó chủ yếu cần để thực hiện các xác nhận kiểm tra (test assertions), nhưng ngay trước khi tôi tắt thí nghiệm đó, hàm này bắt đầu được các mã không phải kiểm tra tin dùng.

Kiểu mã này không tồn tại trong cơ sở mã CPython, nhưng nó lại xuất hiện trong mã mới được tạo ra.

Giống như các con số cho toán tử, nó cũng sử dụng các số nguyên ngẫu nhiên trong một danh sách để lưu trữ trạng thái.

Đây không phải là phong cách lập trình của cơ sở mã này, và thẳng thắn mà nói, nó không nên là phong cách của bất kỳ ai. Tôi không hiểu điều gì đã thúc đẩy mô hình làm điều này.

Trường hợp thất bại ở đây có vẻ khá rõ ràng: mô hình được huấn luyện để tối ưu hóa token cho việc gọi công cụ (vốn cũng trông giống mã nguồn), và đôi khi nó dường như mang thứ mã đó vào nơi không nên đến: cơ sở mã chính.

35 giờ cho một câu lệnh duy nhất

Tôi không thực sự chắc chắn phải nói gì ở đây, nhưng cỗ máy "rác" đã chạy trong 35 giờ cho đến khi tôi tắt nó đi. Trong thời gian đó, nó tạo ra thêm 75.000 dòng mã và không hề dừng lại. Trong 35 giờ, nó đốt khoảng 1 tỷ token với tổng chi phí API thô khoảng 1.200 USD. Nó quản lý để thực hiện 79 commit, chi phí khoảng 15,5 USD cho mỗi commit, và các tác nhân đã trao đổi khoảng 1.400 tin nhắn.

Thành thật mà nói, tôi không cần một tác nhân chạy suốt 35 giờ cho một câu lệnh duy nhất. Nó rõ ràng không hiệu quả hoặc không mang lại kết quả hợp lý.

Vì vậy, rõ ràng là: ra lệnh cho nó như thế này thật ngu ngốc. Nhưng khi không được giám sát, nó sẽ tiếp tục chạy, và các mô hình trước đây không làm như vậy. Ngay cả Fable cũng không điên rồ đến thế. Khi bạn vô tình giao cho nó một tác vụ hơi quá sức, nó sẽ tiếp tục cho đến khi thành công, ngay cả khi nó đốt sạch toàn bộ gói đăng ký của bạn.

Và đó là lý do tại sao hiện tại tôi không thể tin tưởng mô hình này nhiều. Nó đã cho thấy nó sẽ tạo ra "rác" và kết quả là tôi phải xem xét kỹ hơn. Ngay cả khi tỷ lệ thất bại khá thấp, tôi cũng không muốn điều này.

Mã nguồn dùng một lần vs. Mã nguồn được commit

Trong một thế giới mà mã nguồn cho các lệnh gọi công cụ được tối ưu hóa cho hiệu quả token và "hoàn thành công việc", tôi tự hỏi liệu có đủ tín hiệu truyền đến các quy trình huấn luyện về việc "con người hiểu những gì đang diễn ra" hay không. Tôi cho rằng khá nhiều mã nguồn tôi nhận được từ Astra là "xấu một cách khách quan" theo suy nghĩ của tôi. Nhưng đó là xấu theo cảm quan con người. Có lẽ nó lại tốt một cách khách quan cho một cơ sở mã hoàn toàn được viết bởi các tác nhân và chỉ cần được hiểu bởi các tác nhân.

Đó là lý do tại sao tôi thực sự tự hỏi ngày càng nhiều tại sao chúng ta lại làm điều này. Những mô hình mới này chắc chắn rất tuyệt vời. Nhưng tôi ngày càng hoài nghi rằng quỹ đạo mà chúng đang đi có còn phù hợp với các quy trình kỹ thuật phần mềm hiện nay hay không. Lý do tôi đặt câu hỏi này là vì tôi cảm thấy chúng ta đã đạt được một vị thế khá tốt cho kỹ thuật phần mềm với các mô hình trước đó, và đó là phần của nền kinh tế AI nơi có thể thấy được lợi nhuận tích cực. Nhưng với chi phí của Fable, với chi phí của Astra, tôi không cảm thấy kết quả đạt được tương xứng.