Lịch sử phần mềm là lịch sử của việc giao công việc cho máy móc. Chúng ta bắt đầu bằng cách đục lỗ các câu lệnh lên thẻ, rồi để trình biên dịch chuyển các ngôn ngữ dễ đọc thành mã máy, rồi để máy ảo quên mất chúng ta đang chạy trên máy vật lý nào, rồi để đám mây quên hẳn sự tồn tại của cỗ máy. Mỗi bước, vào thời điểm đó, trông giống như một sự từ bỏ quyền kiểm soát. Nhưng thực chất mỗi bước đều là một lần đi lên một tầng cao hơn — đánh đổi một lớp công sức lấy một lớp đòn bẩy. Phát triển agentic là bước tiếp theo trong cùng chuỗi dài đó, và đây là một bước lớn hơn hầu hết các bước trước.
Trừu tượng hóa luôn là câu chuyện xuyên suốt
Không có sự chuyển đổi nào trước đây khiến lập trình viên trở nên thừa thãi; chúng chỉ thay đổi việc lập trình viên dành thời gian trong ngày để làm gì. Trình biên dịch không chấm dứt việc lập trình, nó chấm dứt việc viết assembly bằng tay. Đám mây không chấm dứt vận hành, nó chấm dứt việc lắp đặt server vào rack. Mỗi khi máy móc hấp thụ lớp bên dưới, con người lại chuyển lên lớp bên trên — từ quản lý bộ nhớ sang quản lý logic, từ quản lý server sang quản lý hệ thống.
Khuôn mẫu này nhất quán đến mức gần như một quy luật: bất cứ điều gì trở nên rẻ để tự động hóa thì sẽ không còn là nơi chứa giá trị nữa, và giá trị sẽ dịch chuyển sang thứ khan hiếm nhất vào lúc đó. Trong một thời gian dài, thứ khan hiếm là việc triển khai — biến ý định thành mã hoạt động được. Và đó chính xác là lớp mà các agent đang hấp thụ ngay lúc này.
Agent là một đồng nghiệp, không phải một autocomplete nhanh hơn
Sai lầm dễ mắc phải là xếp các coding agent vào nhóm "autocomplete tốt hơn". Chúng là một thứ hoàn toàn khác. Autocomplete hoàn thành câu của bạn; một agent tiếp nhận một mục tiêu và hành động dựa trên đó — quyết định, trong phạm vi các ranh giới bạn thiết lập, cần thay đổi gì và thay đổi như thế nào, rồi thực hiện điều đó. Nó không giống một bàn phím thông minh hơn, mà giống một đồng nghiệp tình cờ sống trong repository: bạn giao cho nó một issue, nó biến mất đi làm việc, rồi quay lại với một merge request.
Đó chính là hình hài mà chúng tôi xây dựng nên TaskGoblin. Nó không phải là một panel trong editor của bạn. Nó là một đồng đội trong chính những công cụ mà nhóm bạn đã và đang sử dụng — được giao issue, được nhắc đến trong các thread, review pull request — thực hiện việc triển khai trong một sandbox rồi trả lại cho bạn kết quả để xem xét. Đơn vị tương tác không phải là một lần gõ phím. Đó là một task.
Một ngày làm việc bắt đầu trông như thế nào
Đi thêm một bước theo hướng đó, hình dạng của ngày làm việc sẽ thay đổi. Những bản cập nhật dependency mà không ai muốn làm sẽ hoàn tất qua đêm. Bài kiểm thử không ổn định (flaky test) sẽ bị loại bỏ trước buổi standup. Một tính năng được đặc tả kỹ càng sẽ xuất hiện dưới dạng một pull request nháp với phần scaffolding và test đã sẵn sàng, chỉ chờ khả năng phán đoán thay vì chờ được gõ ra. Một product manager di chuyển một ticket, và đến khi có ai đó nhìn lại, phiên bản đầu tiên của thay đổi đã được mở sẵn. Băng chuyền của công sức — những công việc cần thiết nhưng không hào nhoáng chiếm phần lớn thời gian trong tuần của một kỹ sư — cuối cùng cũng chậm lại.
Điều còn lại là phần vốn dĩ luôn là công việc thực sự: quyết định điều gì nên được xây dựng, nhận ra khi nào cách triển khai có vẻ hiển nhiên lại sai một cách tinh vi, giữ vững gu thẩm mỹ và bối cảnh mà không lượng năng lực thô nào có thể cung cấp được. Kỹ sư chuyển từ vai trò tác giả sang biên tập viên — từ việc tạo ra từng dòng code sang việc chỉ đạo những gì được tạo ra và phán quyết xem nó có đúng hay không.
Câu hỏi chuyển từ "chúng ta có thể không?" sang "chúng ta có nên không?"
Khi việc triển khai trở nên rẻ và nhanh, ràng buộc mang tính quyết định không còn là liệu bạn có thể xây dựng được thứ gì đó hay không, mà trở thành liệu nó có đáng để xây dựng hay không. Việc lặp lại (iteration) trở nên đủ rẻ để các buổi design review trở nên mang tính khám phá — thử ba phiên bản thay vì tranh luận về một phiên bản. Một đội nhỏ có thể vận hành với sản lượng của một đội lớn hơn nhiều, vì đòn bẩy trên mỗi người đã tăng lên. Và lợi thế cạnh tranh cũng dịch chuyển theo — rời xa câu hỏi ai có thể thực thi, hướng đến ai có gu thẩm mỹ để biết nên thực thi điều gì, có sự đồng cảm để hiểu điều đó dành cho ai, và có sự rõ ràng để diễn đạt vấn đề đủ tốt để một agent có thể bắt tay vào ngay.
Đó là sự tái định hình thực sự ẩn dưới mọi tiếng ồn. "Giờ đây tất cả chúng ta chỉ đang quản lý các bầy junior developer" là phiên bản đầy lo âu; phiên bản gần với sự thật hơn là đòn bẩy đã dịch chuyển, và kỹ năng khan hiếm cũng dịch chuyển theo — đi lên, đến khả năng phán đoán.
Con người vẫn giữ vị trí ở đâu
Một phiên bản trung thực của tương lai này không giả vờ rằng con người sẽ biến mất. Ngược lại là đằng khác: khi máy móc hấp thụ việc triển khai, các quyết định của con người trở nên hệ trọng hơn, chứ không phải ít hơn, bởi vì mỗi quyết định giờ đây định hướng một lượng sản lượng lớn hơn nhiều. Đó là lý do TaskGoblin cố tình giữ một con người ở khâu merge — agent viết code và review thay đổi, nhưng không bao giờ tự approve và không bao giờ tự merge. Khả năng phán đoán về việc liệu điều gì đó có đúng cho hệ thống này, ngay lúc này, chính là lớp không thể tự động hóa, và đó cũng là lớp mà tất cả chúng ta đang tiến lên.
Băng chuyền đang chậm lại. Điều quyết định ai sẽ định hình kỷ nguyên tiếp theo của phần mềm sẽ không phải là ai có thể triển khai — máy móc đang tiếp quản việc đó, như nó đã tiếp quản những lớp bên dưới. Điều quyết định sẽ là trí tưởng tượng, gu thẩm mỹ, và khả năng phán đoán để hướng toàn bộ năng lực này vào những thứ thực sự đáng để xây dựng.
