Một câu hỏi nhỏ, mở ra một thay đổi lớn
Tôi vẫn nhớ lần đầu nhìn thấy Google công bố giao diện dòng lệnh, Command Line Interface, CLI cho Google Workspace. Khi ấy, phản ứng đầu tiên của tôi khá tự nhiên: tại sao phải gõ lệnh để tạo một Google Doc, trong khi chỉ cần vài cú click trên giao diện là xong?
Câu hỏi đó ban đầu nghe rất hợp lý. Nhưng càng đi sâu vào thời đại AI, tôi càng thấy chính câu hỏi ấy lại mở ra một cánh cửa khác, cánh cửa làm thay đổi cách ta nghĩ về software.
Con người cần nút bấm. Nhưng agents thì cần commands.
Khi AI agents trở thành “người dùng” thực sự của software, nghĩa là không còn là một con người ngồi trước màn hình nữa, thì nhiều thứ từng được xem là tối quan trọng bỗng trở nên thứ yếu. Agent không cần màu sắc, không cần hoạt hình (animation), không cần thiết kế đáp ứng các thiết bị (responsive design). Nó không quan tâm nút bấm có đẹp hay không. Thứ nó cần là một lệnh (command) rõ ràng, một đầu vào (input) xác định, và một đầu ra (output) có thể đọc, có thể xử lý tiếp.
Và trong khoảnh khắc ấy, CLI không còn là công cụ cũ kỹ dành riêng cho nhà phát triển (developers). Nó trở thành một dạng giao diện của tương lai.
Câu chuyện bắt đầu từ một file PDF cần chia nhỏ
Mọi chuyện với tôi bắt đầu từ một việc rất nhỏ, nhỏ đến mức nếu kể ra có thể nhiều người sẽ bật cười. Tôi có một file PDF của cuốn From Strength to Strength của Arthur Brooks, và muốn tách nó thành từng chương riêng. Nếu làm theo cách quen thuộc, tôi sẽ mở Adobe Acrobat, kéo thả, chọn vài trang, lưu lại (save), rồi lặp đi lặp lại thao tác ấy nhiều lần.
Nhưng tôi không muốn làm như thế. Tôi muốn có một công cụ mà chỉ cần gõ một câu lệnh, chẳng hạn:
python -m pdf_splitter sach.pdf --prefer-bookmarks
là xong.
Điều tôi cần không phải là một app. Điều tôi cần là một CLI, thứ đơn giản, tự động, lặp lại được, và quan trọng nhất, đủ chuẩn để cả con người lẫn agents đều có thể dùng.
Khi mang dao mổ trâu đi giết gà
Lúc ấy, tôi đã phạm một sai lầm. Đó là mang dao mổ trâu đi giết gà.
Tôi chọn dùng superpowers skills cho project này. Nghe qua thì hoàn toàn hợp lý. Một tool CLI tử tế thì phải được xây cho tử tế. Mà đã tử tế thì phải có quy trình kiểm thử hướng phát triển (Test Driven Development-TDD) nghiêm ngặt, phải có điều phối dùng đa tác nhân (multi agent orchestration), phải có kiến trúc rõ ràng (clean architecture), phải có quy trình (workflow) bài bản.
Nghe rất đúng. Nhưng đời sống, như các nhà Khắc kỷ từng nhắc ta, luôn có thói quen bẻ gãy những ảo tưởng quá đẹp.
Hệ thống phân tích yêu cầu (requirement) của tôi và sinh ra 9 tác vụ (tasks). Mỗi task lại có 4 đến 5 bước theo đúng nghi lễ của TDD: viết kiểm thử (test) trước, để test fail, rồi triển khai (implement), rồi test pass, rồi lại sửa mã (refactor).
Kết quả cuối cùng là gì? Một file PDF splitter đơn giản bỗng biến thành một dự án t chuẩn dành cho doanh nghiệp (enterprise-grade), với 8 modules trong thư mục mã nguồn, 5 file tests, wrapper scripts cho nhiều shell, tài liệu README đầy đủ. Nó chạy rất tốt. Thậm chí có thể nói là chạy quá tốt.
Chỉ có điều, nó hơi thừa.
Cảm giác ấy giống như thuê hẳn một ekip đầu bếp Michelin để làm một ổ bánh mì. Không phải họ làm không ngon. Ngược lại là khác. Nhưng cái giá phải trả, cả về công sức lẫn độ phức tạp, không còn tương xứng với bài toán ban đầu nữa.
CODEX CLI và bài học về xử lý song song (parallelization)
Tôi lại nghĩ mình có thể khôn ngoan hơn một bước. Lần này, tôi chuyển sang CODEX CLI, với kỳ vọng rằng nếu để nhiều subagents chạy song song, 9 tasks kia sẽ được xử lý rất nhanh. Về lý thuyết, đó là một hình ảnh rất hấp dẫn: chia việc ra, song song hóa (parallelization), tăng tốc, hoàn thành trong chớp mắt.
Nhưng thực tế thì khác. Tôi hết hạn mức (quota) sau 5 tasks.
Nguyên nhân không nằm ở chỗ các subagents tạo ra code quá nhiều, mà nằm ở chỗ chúng tạo quá nhiều vòng lặp (iterations). Test fail, fix, test pass, refactor, commit, rồi lại lặp. Mỗi vòng như vậy đều tiêu tốn token. Khi nhân lên theo số lượng agents, số tasks, số iterations, chi phí không tăng tuyến tính mà tăng rất nhanh.
Đó là lúc tôi thực sự thấm một bài học mà nhiều người dùng AI sớm muộn cũng phải học: parallelization không miễn phí. Trong thế giới của LLM agents, token là tiền tệ (currency). Mọi quyết định về kiến trúc (architecture) không chỉ là quyết định kỹ thuật, mà còn là quyết định kinh tế.
Hay nói gọn hơn, phải bắt đầu nghĩ bằng logic của kinh tế token (token economy).
CLINE, Qwen 3.6 Plus, và sức mạnh của sự vừa đủ
Sau cùng, tôi quay về với một lựa chọn tưởng như bình thường nhất: CLINE chạy trên Qwen 3.6 Plus, khi ấy còn đang free. Một single agent. Không cần điều phối (orchestration) cầu kỳ. Không một đội quân tác tử (subagents) chạy song song để đốt thêm context.
Và chính ở đó, điều bất ngờ xảy ra. Nó làm việc tốt.
Cửa sổ ngữ cảnh (context window) đủ lớn để giữ được trạng thái của toàn bộ dự án. Chất lượng code sạch sẽ, đủ chắc để đưa vào sử dụng. Quan trọng hơn, mức tiêu thụ token hiệu quả hơn rất nhiều so với cách tiếp cận multi agent.
Kết quả cuối cùng vẫn là một CLI hoàn chỉnh, có cấu trúc rõ ràng, có entry point, có config, có models, có planner, có loader, có extractor, có reporting, có splitter, cùng hệ thống tests và documentation đi kèm. Nghĩa là đích đến vẫn đạt được. Chỉ khác ở chỗ, con đường đi đến đó bớt phô trương hơn, nhưng hiệu quả hơn.
Và có lẽ, đó mới là điều đáng nói.
Những điều rút ra sau hành trình
Sau hành trình nhỏ này, tôi rút ra vài điều, không chỉ cho việc viết phần mềm (software), mà cho cả cách ta nghĩ về công nghệ trong thời đại AI.
Trước hết, công cụ (tool) mạnh nhất không phải lúc nào cũng là tool phù hợp nhất. Một hệ thống gây ấn tượng (impressive) về mặt kỹ thuật chưa chắc đã là lựa chọn khôn ngoan cho một bài toán nhỏ. Dùng một cỗ máy quá lớn cho một việc quá đơn giản thường tạo ra cảm giác hùng hồn, nhưng ít khi tạo ra hiệu quả thực sự.
Kế đến, chi phí về token (token cost) là một ràng buộc có thật, không phải một chi tiết phụ. Rất nhiều người nói về năng lực của AI agents theo ngôn ngữ của sự phấn khích, nó có thể làm gì, nó tự động hóa được đến đâu, nó thay người ra sao. Nhưng ít người chịu dừng lại để hỏi một câu tỉnh táo hơn: cái đó có đáng làm với chi phí hiện tại không?
Trong thời đại mới, đây không chỉ là câu hỏi vận hành. Nó là câu hỏi chiến lược.
Điều thứ ba, và có lẽ là điều quan trọng nhất với tôi, là tư duy ưu tiên CLI (CLI first) thực ra rất hợp với thế giới của agents. Tool tôi build không chỉ để con người dùng. Bất kỳ agent nào cũng có thể gọi nó qua tiến trình con (subprocess), nhận kết quả, rồi chuyển sang bước tiếp theo trong chuỗi xử lý. Đó không còn là công cụ cho một người dùng. Đó là một điểm nối trong hệ sinh thái từ máy tới máy (machine to machine).
Tương lai của phần mềm có thể sẽ ít nút bấm hơn chúng ta tưởng
Và từ đây, một cánh cửa khác mở ra. Nếu hôm nay ta có thể nghĩ về document processing theo cách ấy, thì ngày mai hoàn toàn có thể nghĩ về data pipelines, deployment automation, monitoring, testing, reporting, tất cả dưới dạng những công cụ CLI được thiết kế để agents có thể dùng trực tiếp.
Nói cách khác, CLI không chết. Nó chỉ đang chờ đúng người dùng (user) của nó xuất hiện.
Người dùng ấy có thể không phải là chúng ta. Mà là agents.
Và nếu điều đó là đúng, thì tương lai của phần mềm sẽ không chỉ được định hình bởi những gì đẹp mắt với con người, mà còn bởi những gì rõ ràng, ổn định, có thể chuyển thành script (scriptable), và có thể gọi được bằng dòng lệnh (command). Tương lai ấy không phải là một thế giới nơi con người biến mất khỏi vòng lặp. Nó là một thế giới nơi con người ra lệnh cho máy, rồi máy tiếp tục ra lệnh cho máy.
Ngẫm cho cùng, đó không chỉ là một thay đổi về giao diện. Đó là một thay đổi về triết lý thiết kế.