Tốc độ Prototyping trong Kỷ nguyên AI: Khi Ý tưởng Hiện thực hóa Chỉ trong Chốc lát

Công nghệ31 tháng 5, 2026·9 phút đọc

Bài viết chia sẻ những suy ngẫm cá nhân về cách AI đã thay đổi hoàn toàn quy trình làm việc và tốc độ tạo mẫu (prototyping) của một kỹ sư phần mềm. Từ việc tạo dựng khung dự án nhàm chán, tác giả giờ đây có thể nhanh chóng hiện thực hóa nhiều ý tưởng phức tạp, dù vẫn cần cân bằng giữa việc sử dụng công cụ và duy trì kỹ năng lập trình cốt lõi.

Tốc độ Prototyping trong Kỷ nguyên AI: Khi Ý tưởng Hiện thực hóa Chỉ trong Chốc lát

Tốc độ Prototyping trong Kỷ nguyên AI: Khi Ý tưởng Hiện thực hóa Chỉ trong Chốc lát

Vài năm trước, tôi từng viết về niềm đam mê của mình đối với những bản mẫu dùng một lần (throwaway prototypes) — những khái niệm chứng minh (proof-of-concepts) tồn tại chỉ để đưa ý tưởng từ trong đầu ra thành một thứ gì đó hữu hình. Lúc bấy giờ, nút thắt lớn nhất chính là tôi; là khoảng thời gian cần thiết để dựng khung dự án (scaffold), kết nối các phần nhàm chán, và đến được nơi mà những phần thú vị thực sự có thể được kiểm tra. Nhảy đến thời điểm hiện tại, nút thắt đó gần như đã biến mất hoàn toàn.

Tôi hơi do dự khi viết về điều này. Tôi đã chia sẻ một số suy nghĩ thận trọng về AI và vị trí của nó trong quy trình làm việc của mình, và tôi vẫn giữ nguyên quan điểm đó. Tôi vẫn nghĩ ngành công nghiệp này đang tìm ra câu trả lời theo thời gian thực, và tôi vẫn nghĩ việc thận trọng là điều đáng giá. Nhưng thận trọng không có nghĩa là mù quáng, và sự thật trung thực là AI đã thay đổi tốc độ mà tôi có thể đi từ "tôi tự hỏi liệu..." đến "ồ, nó hoạt động" nhanh như thế nào.

Các kho lưu trữ (repos) gần đây

Nếu bạn xem GitHub của tôi gần đây, bạn sẽ nhận thấy một loạt các kho lưu trữ mới xuất hiện. Có Sakoa, một ngôn ngữ hệ thống tiến bộ mà tôi đang thiết kế từ đầu, hoàn chỉnh với hệ thống hiệu ứng, ba chế độ bộ nhớ và MIR với nhiều backend. Có Kato, một ngôn ngữ ký hiệu nằm ở đâu đó giữa JSON, TOML và YAML, nhưng được thiết kế rõ ràng để thân thiện với cả con người và các tác nhân AI. Có Seal, một CLI nhỏ gọn âm thầm "giết chết" file .env bằng cách cất giữ các bí mật trong các kho lưu trữ thông tin xác thực gốc của hệ điều hành. Còn Karabiner, một ứng dụng nhắn tin ưu tiên iOS và gốc cho tác nhân. Và Plim, một trình chỉnh sửa khối có thể nhúng lấy cảm hứng từ Notion dành cho web với lõi không phụ thuộc framework và ràng buộc React. Cùng một vài dự án khác đang ấp ủ nhưng chưa sẵn sàng để ra mắt.

Vài năm trước, danh sách đó sẽ chỉ là ba kho lưu trữ với file README, hai nhánh bị bỏ rơi và một bản mẫu hoạt động mà tôi sẽ âm thầm tự hào. Bây giờ thì sao? Các bản mẫu đó tồn tại. Chúng chạy. Một số có kiểm thử (tests). Một vài cái bắt đầu trông giống như những dự án thực sự. Và mặc dù không phải tất cả chúng sẽ trở thành một cái gì đó nghiêm túc (và đó chính là điểm mấu chốt), nhưng có một điều thực sự thỏa mãn là có thể thực sự thử nghiệm một ý tưởng thay vì chỉ nói về nó.

Nhìn rộng ra

Điều mà ít ai cảnh báo với tôi là AI thay đổi hình thức của công việc kỹ thuật như thế nào, không chỉ là tốc độ. Khi tôi không phải là người gõ từng dòng code, tôi buộc phải suy nghĩ khác đi. Tôi đang suy nghĩ về các ranh giới, hợp đồng (contracts), và cách các mảnh ghép khớp với nhau. Tôi đang viết các câu lệnh (prompts) và thông số kỹ thuật mô tả hệ thống một cách toàn diện, trước khi hệ thống đó tồn tại.

Sự thay đổi đó nghe có vẻ nhỏ nhưng nó đã âm thầm mang tính chuyển đổi. Tôi đang lập kế hoạch ở mức độ trừu tượng hơn, định hình vấn đề trước khi giải quyết nó, và tôi đã trở nên tốt hơn đáng kể trong việc ủy quyền; cả cho các tác nhân AI và cho con người. Hóa ra là kỹ năng "mô tả chính xác sự thành công trông như thế nào, theo cách mà một kỹ sư cấp dưới (hoặc một mô hình) có thể hành động mà không cần bạn ở trong phòng" là một kỹ năng giống nhau ở cả hai hướng. Chia sẻ tầm nhìn, chia nhỏ công việc, dự đoán nơi mọi thứ có thể sai; những điều này là những kỹ năng tôi buộc phải rèn luyện có chủ đích hơn nhiều, và tôi tốt hơn nhờ điều đó.

Về năng suất

Tôi đã theo dõi điều này một cách lỏng lẻo một thời gian, chủ yếu vì tò mò. Dựa trên các nhiệm vụ kỹ thuật hàng ngày của chính mình (được đo lường sơ bộ theo thời gian để tạo Pull Request cho các công việc điển hình), tôi nhanh hơn khoảng 4 lần so với trước đây khi các tác nhân trở thành một phần có ý nghĩa trong quy trình làm việc của tôi. Một số ngày nhanh hơn, một số ngày chậm hơn, và một số ngày tác nhân làm điều gì đó kỳ lạ tốn của tôi một giờ để sửa lại (mà tôi sẽ vui vẻ tính vào mức trung bình).

Nhưng con số đó chưa nói lên hiệu ứng thú vị hơn: loại công việc tôi có thể đảm nhận đã thay đổi. Những thứ tôi từng để dưới danh mục "ý tưởng hay, nhưng không có thời gian" giờ đây lọt vào một buổi chiều. Những việc tái cấu trúc (refactor) mà tôi từng nhăn nhó giờ đây khả thi. Chi phí để thử nghiệm một cái gì đó đã giảm đủ thấp để tôi sẽ chỉ thử những thứ mà nếu không tôi sẽ phải tranh luận trong một tài liệu.

Cái giá của tốc độ

Không phải mọi thứ đều tích cực. Cùng tốc độ đó khiến tôi năng suất cũng có nghĩa là tôi gõ ít code hơn trước, và tôi nhận thấy tôi phải có chủ đích để giữ cho sự nhạy bén kỹ thuật của mình được sắc bén. Nếu tôi để mặc, các công cụ sẽ vui vẻ làm tất cả mọi thứ; và đó thực sự không phải là một giao dịch tôi muốn thực hiện. Tôi vẫn muốn biết những thứ tôi làm việc thực sự hoạt động như thế nào.

Vì vậy, tôi đã bắt đầu dành thời gian cho các phần thủ công một cách có chủ đích. Triển khai thứ gì đó từ đầu đến cuối bằng tay. Đọc mã nguồn thay vì hỏi tóm tắt. Ngồi với trình gỡ lỗi (debugger) thay vì dán stack trace vào một cuộc trò chuyện. Nó chậm hơn, đôi khi gây thất vọng, và có lẽ là cần thiết; cả cho sự tỉnh táo của chính tôi, và vì những khoảnh khắc AI không đủ sức vẫn cần một kỹ sư thực sự biết mình đang làm gì.

Mặt khác của điều này thú vị hơn nhiều: với tốc độ mới, thật đáng ngạc nhiên khi dễ dàng dành thời gian để khám phá, học hỏi và tạo mẫu. Những giờ tôi từng dành cho các phần trung gian không thể tránh khỏi của một dự án giờ đây được giải phóng để chơi với các ý tưởng mới, đào sâu vào những thứ tôi không hiểu đầy đủ, hoặc chỉ xây dựng một cái gì đó kỳ lạ chỉ vì nó vui. Đó là một sự đánh đổi tôi vui vẻ chấp nhận.

Tác động tại công việc

Tốc độ mới này cũng xuất hiện trong công việc chính của tôi. Mà không cần đi vào quá nhiều chi tiết (tôi sẽ để các bài viết thích hợp khi tôi có được sự chấp thuận cần thiết), sự tăng tốc độ đã cho tôi tạo ra tác động trong một vài lĩnh vực khác nhau của vai trò mà tôi sẽ không có băng thông để chạm vào nếu không có nó:

Tôi đã có thể giúp đưa lên một số tự động hóa cung cấp hỗ trợ cho các kỹ sư khác; một công việc tôi thực sự tự hào, và một công việc tôi hy vọng sẽ viết về nó sớm.

Tôi cũng đang đào sâu vào thời gian khởi tạo (bootstrap) codespace nội bộ của chúng tôi và đã quản lý để đưa ra các thay đổi giảm chúng xuống khoảng 50%. Có một bài viết dài hơn về cách chúng tôi đến được đó, nhưng nó sẽ phải đợi.

Cả hai đều là loại thứ mà tôi có thể đã có ý tưởng vài năm trước nhưng sẽ không có đủ sức chứa để thực hiện cùng với công việc cốt lõi của mình. Sự thay đổi về tốc độ không chỉ tăng tốc những thứ tôi đã làm; nó mở rộng bề mặt của những gì tôi có thể làm.

Tôi không phải là người duy nhất nhận thấy điều này

Một vài kỹ sư khác trong lĩnh vực này cũng đã viết về những sự thay đổi tương tự, và việc đọc theo dõi đã rất trấn an (và hữu ích). Hai người tôi đặc biệt giới thiệu:

Mike McQuaid (người dẫn dắt Homebrew, cựu nhân viên Hubber 10 năm) có một bài viết tuyệt vời về thiết lập tác nhân hiện tại của anh ấy, bao gồm việc sử dụng sandboxing và git worktrees để thực sự song song hóa công việc. Khung nhìn của anh ấy về "nhiều token/chi tiêu trực tiếp chuyển thành nhiều tốc độ hơn" là một trong những cách diễn đạt rõ ràng hơn về nơi mọi thứ đang hướng tới.

Cassidy Williams, một nhân viên Hubber hiện tại, đã làm nhiều dự án cá nhân nhỏ nhưng rất thỏa mãn với Copilot CLI, bao gồm một thiết lập nhỏ thú vị kết nối Logitech MX Creative Console của cô ấy để điều khiển đèn Elgato. Đó là một ví dụ đẹp về mức độ thấp của rào cản đối với 'tôi sẽ tự xây cái này'.

Tôi cũng muốn gật đầu với bài viết về siêu năng lực của Simon Willison để cái nhìn rộng hơn về những gì các tác nhân lập trình thực sự có thể làm trong thực tế; rất đáng đọc nếu bạn chưa đọc.

Tôi vẫn không nghĩ AI là phép thuật, và tôi vẫn thận trọng về bức tranh rộng lớn hơn; các câu hỏi về môi trường, tài chính và xã hội vẫn chưa đi đâu cả. Nhưng đối với tôi, ngay lúc này, thực tế hàng ngày là tôi có thể di chuyển nhanh hơn, suy nghĩ lớn hơn, và ship (phát hành) nhiều hơn trước. Và điều đó thực sự thú vị.

Tôi không có một kết luận gọn gàng để kết thúc điều này. Tôi sẽ chỉ tiếp tục tạo mẫu, tiếp tục lăn xả khi cần, và tiếp tục chú ý đến những gì thay đổi và những gì không. Nhiều suy nghĩ hơn khi mọi thứ tiếp tục dịch chuyển.

Hẹn gặp lại… ✌🏽

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗