Code giờ do agent viết. Đây là những gì nghề lập trình viên đã trở thành.

Câu hỏi này xuất hiện ở mọi bàn ăn có một lập trình viên trong nhà: nếu máy viết code, thì còn lại gì?

Câu trả lời thành thật là câu hỏi đang nhắm vào sai phần của cái nghề. Viết code chưa bao giờ là toàn bộ cái nghề. Đó là phần nhìn thấy được, phần trông giống như đang làm việc với bất kỳ ai đi ngang qua bàn. Và hầu hết các tuần, đó cũng là phần nhỏ nhất.

Phần bị tự động hóa chưa bao giờ là toàn bộ cái nghề

Mọi thứ được phát hành đều đi qua sáu mắt xích:

1. Có người muốn một thứ gì đó, và diễn đạt nó rất tệ.
2. Có người quyết định thứ đó đáng làm, và làm khi nào.
3. Có người biến nó thành một bản mô tả đủ chính xác để thực thi được.
4. Có người xây nó.
5. Có người kiểm tra rằng nó không làm hỏng thứ khác.
6. Có người phát hành nó và báo lại cho người đã xin.

Agent đã lấy mắt xích số bốn. Chúng lấy một cách thuyết phục, và chúng sẽ còn giỏi hơn nữa. Điều gần như không ai nói to là hệ quả lên năm mắt xích còn lại: chúng nặng thêm, chứ không nhẹ đi.

Lý do nằm ở thông lượng. Khi xây một thứ mất hai tuần, năm mắt xích xung quanh có hai tuần để diễn ra. Chúng chậm vì khúc giữa chậm, và không ai nhận ra là chúng chậm. Khi xây một thứ chỉ mất một buổi chiều, mọi thứ còn lại đồng loạt trở thành nút thắt.

Một mắt xích đã sụp. Năm mắt xích còn lại giờ gánh phần sức nặng mà mắt xích kia từng che đi.

Đó là toàn bộ câu chuyện, và phần còn lại của bài viết này nói về hình dạng của từng mắt xích trong năm cái đó khi bạn thật sự phải làm chúng mỗi ngày.

Mắt xích 1: nghe xem cần xây gì, mà không đánh rơi mất một nửa

Kiểu hỏng mới thì rất cụ thể và rất đắt: bạn xây được mọi thứ, nên bạn xây nhầm thứ nhanh hơn.

Yêu cầu đến từ khắp nơi. Một tin nhắn trong luồng hỗ trợ. Một câu nói ở cuối cuộc gọi. Một lời phàn nàn trên mạng xã hội. Một bản báo lỗi thực chất là một đề xuất tính năng đang cải trang. Trước đây chuyện đó không quan trọng lắm, vì đằng nào hai tuần bạn cũng chỉ xây được một thứ, và cái hiển nhiên nhất thường là cái đúng. Giờ khi bạn xây được năm thứ một tuần, khoảng cách giữa năm thứ đúng và năm thứ sai chiếm gần hết cả năm của bạn.

Hai việc phải xảy ra, và chúng là hai việc khác nhau.

Thứ nhất, việc thu thập phải rẻ với người đi xin. Nếu người dùng phải tạo tài khoản, tìm một biểu mẫu rồi mô tả vấn đề hai lần, phần lớn sẽ không buồn làm, và những người chịu làm thì không phải một mẫu đại diện. Một bảng phản hồi công khai nơi ai cũng gửi được một yêu cầu, đính kèm ảnh chụp màn hình và theo dõi số phận của nó sẽ xóa đi cái ma sát ấy. Chính những người dùng sản phẩm tự viết yêu cầu, bằng lời của họ, kèm sẵn ngữ cảnh.

Thứ hai, việc phân loại phải tự động, vì phản hồi thô không giữ được giá trị lâu. Hai mươi tin nhắn nói gần như cùng một chuyện trông giống hai mươi vấn đề, cho tới khi có người đọc hết cả hai mươi và nhận ra đó là một. Đó đúng là phần việc không ai có thời gian làm. Idea Radar là câu trả lời của chúng tôi: tín hiệu thô rơi vào nguyên vẹn, tự gom thành các chủ đề, các bản trùng nhau được ghép lại trước khi kịp biến thành hai lần xây, và mỗi ý tưởng mang theo số người khác nhau đã xin nó. Nguyên văn không bao giờ bị viết lại, vì chính những từ mà người ta đã dùng mới là dữ liệu.

Đầu ra của mắt xích này không phải một backlog. Đó là một tập văn bản bạn đọc được.

Mắt xích 2: quyết định, thứ tài nguyên giờ đã khan hiếm

Một bảng ý tưởng không phải một kế hoạch. Biến cái này thành cái kia là phán đoán vốn từng được rải mỏng qua cả một quý và giờ phải diễn ra mỗi tuần.

Hai động tác quan trọng ở đây.

Việc đề bạt là có chủ ý. Một ý tưởng trở thành ticket trong backlog khi có người quyết định nó đáng xây, chứ không phải khi nó được gửi lên. Mọi thứ còn lại vẫn hiện trên radar kèm số người đã xin, và đó là tình trạng thành thật của sự việc: đã nghe thấy, chưa lên lịch. Một backlog mà tám mươi phần trăm số dòng sẽ không bao giờ được làm thì không phải một kế hoạch, đó là một kho lưu trữ được bày biện gây hiểu nhầm.

Việc khoanh phạm vi diễn ra trước khi xây, không phải trong lúc xây. Một phản hồi mơ hồ trở thành bản mockup đã được xác nhận mà chính người đi xin nhìn được và gật đầu. Năm phút xác nhận thắng một buổi chiều xây nhầm màn hình, và phép đổi chác đó trở nên có lợi hẳn từ ngày buổi chiều xây dựng kia biến thành một buổi chiều thời gian agent mà bạn đã có thể tiêu vào việc khác.

Mắt xích 3: ra đề bài, tay nghề đã thay thế việc gõ phím

Đây là chỗ mà kỹ năng thật sự đã chuyển tới.

Agent sẽ không vặn lại một chỉ dẫn mơ hồ theo cách một đồng nghiệp làm. Nó sẽ không nói "khoan đã, ý bạn là luồng thanh toán nào trong hai cái?". Nó lấp chỗ trống bằng một phỏng đoán nghe có lý rồi đưa bạn một thứ mạch lạc nhưng sai. Cái giá của sự mơ hồ trước đây là một cuộc trò chuyện. Giờ nó là một cái diff.

Thứ phân biệt người nhận được kết quả tốt với người vật lộn với agent cả ngày không phải là mẹo prompt. Đó là ngữ cảnh tái sử dụng được. Bốn dạng, xếp theo mức sinh lợi giảm dần.

Ngữ cảnh mà agent đọc trước khi đi dò. Các tệp quy ước đã commit (CLAUDE.md, AGENTS.md) và một bộ nhớ dự án chứa các quyết định kiến trúc, những cái bẫy đã gặp và lý do vì sao mọi thứ lại như hiện nay. Viết một lần, được mọi agent trên mọi máy đọc, mãi mãi. Đó là thứ văn bản sinh lợi cao nhất mà một lập trình viên viết ra ngày nay, và gần như không ai dành thời gian cho nó.

Quy trình, được lưu lại đúng dạng quy trình. Đến lần thứ mười giải thích checklist phát hành của mình, bạn không còn ra đề bài nữa, bạn đang gõ lại. Một thư viện skill biến một quy trình lặp đi lặp lại thành thứ mà agent tự nạp khi công việc khớp, còn một thư viện prompt làm đúng như vậy với chính các đề bài.

Cho xem thay vì mô tả. Một đoạn văn tả cái nút bị lệch thì tệ hơn một tấm ảnh chụp cái nút bị lệch. Hãy gửi thẳng một vùng màn hình, hoặc vẽ lên đó để chỉ đúng thứ bạn đang nói tới. Với một trang web, đưa cho agent DOM đang chạy luôn thắng việc mô tả nó, không trừ lần nào.

Nói thay vì gõ. Một đề bài nói ra trong ba câu mang nhiều sắc thái hơn cái câu duy nhất mà bạn chịu khó gõ. Đọc chính tả bằng giọng nói cho một chỉ dẫn nhanh, chế độ thoại khi bạn muốn trao đổi qua lại mà không chạm vào bàn phím. Nghe thì giống một tiện nghi. Trên thực tế đó là băng thông: người ta nói ra nhiều hơn viết ra, còn agent thì bị giới hạn bởi đúng những gì bạn nói với nó.

Ba cách đầu trả tiền theo từng việc. Cách thứ tư trả một lần rồi thu về mãi mãi.

Mắt xích 4: điều phối công việc, trên đúng cái máy

Một agent là một công cụ. Nhiều agent là một hệ thống, mà hệ thống thì cần người vận hành.

Các câu hỏi thực tế thì chẳng hào nhoáng gì, và chúng chính là cái nghề. Cái gì chạy song song được mà không có hai agent cùng sửa một mô-đun? Việc nào đáng để bạn để mắt trong lúc nó chạy, và việc nào thì không? Cái gì nên chạy trong lúc bạn ngủ?

Câu cuối quyết định nơi công việc được thực thi. Bất cứ thứ gì bạn có thể phải ngắt, chỉnh hoặc bẻ lái giữa chừng đều thuộc về cái máy đang ở trước mặt bạn. Việc dài, được đặc tả rõ, ít chỗ mơ hồ thì thuộc về nơi khác: một máy tính khác của bạn hoặc một máy chủ qua SSH, để một tác vụ hai tiếng không bắt cóc chiếc laptop của bạn. Việc lặp lại theo chu kỳ thì thuộc về một lịch chạy. Câu hỏi quyết định không bao giờ là sức mạnh thô, mà là khả năng bạn sẽ phải can thiệp.

Khi một phần việc có các giai đoạn thật sự khác nhau, một agent đơn lẻ là hình dạng sai cho nó. Một bản dựng phải được kiểm thử rồi mới được duyệt là ba công việc với ba bộ kỹ năng khác nhau, và đội agent cho phép bạn vẽ rõ bước bàn giao đó thay vì phải giải thích lại ngữ cảnh ở từng chặng.

Và vì chẳng có phần nào trong chuyện này bắt bạn phải ngồi tại chỗ, việc điều khiển nó từ điện thoại thôi là một món đồ chơi lạ. Đọc câu hỏi của một agent rồi trả lời trong hai mươi giây từ trên tàu chính là khác biệt giữa một tác vụ đã xong và một tác vụ đã chờ bạn bốn tiếng.

Mắt xích 5: duyệt, nơi trách nhiệm cư trú

Đây là mắt xích không ủy thác được, và lý do không phải kỹ thuật.

Agent đã thay thế phần lớn việc đọc từng dòng. Thứ chúng không lấy được là chữ ký. Trách nhiệm không chuyển sang một mô hình. Khi một migration xóa mất một cột trên sản phẩm thật, "agent viết cái đó" không phải một câu mà ai đó chấp nhận, và đúng ra là không nên chấp nhận.

Thứ thay đổi là hình dạng của việc duyệt, chứ không phải sự tồn tại của nó. Đọc từng dòng không sống sót nổi khi năm agent chạy song song, và một con người lướt qua một cái diff chín trăm dòng lúc sáu giờ tối thì tạo ra một chữ ký mà không tạo ra hiểu biết. Nguyên tắc trụ được là duyệt tương xứng với bán kính vụ nổ: chữ nghĩa và phần trang trí thì lướt qua, còn xác thực, thanh toán, phân quyền, dữ liệu cá nhân và migration thì đọc từng dòng, lần nào cũng vậy, bởi một người lẽ ra đã tự viết được chúng.

Hai thứ khiến điều đó khả thi. Việc xem được diff theo từng agent thay vì một đống đã trộn lẫn cho bạn biết ai đã đổi gì khi ba agent cùng làm trong một kho mã. Còn việc gắn cuộc trò chuyện vào commit trả lời đúng câu hỏi thật sự ngốn thời gian sáu tháng sau, vốn chưa bao giờ là "cái gì đã thay đổi" mà luôn là "vì sao".

Với bất cứ thứ gì có giao diện người dùng, việc kiểm tra không dừng ở cái diff. Một agent lái một trình duyệt thật có thể đi lại toàn bộ luồng mà nó vừa xây rồi kể lại những gì nó thấy, và đó là cách bắt được loại lỗi đọc trong mã nguồn thì thấy rất ổn.

Chúng tôi đã viết hẳn một bài về chỗ nên tiêu sự chú ý đó: bạn có nên vẫn duyệt code của agent AI không.

Mắt xích 6: phát hành, và khép lại vòng lặp

Phát hành là nửa dễ của mắt xích này. Nửa hay bị bỏ qua là báo lại cho người đã xin.

Đó cũng là nửa sinh lợi nhất. Người dùng báo một chuyện rồi sau đó nghe tin nó đã lên sản phẩm sẽ báo tiếp chuyện sau. Người dùng báo vào im lặng thì thôi báo, và bạn mất đi thứ nguyên liệu vốn nuôi mắt xích một. Khi một ticket sinh ra từ một yêu cầu công khai được đóng lại, người đã gửi nó phải biết điều đó mà không cần ai nhớ ra là phải gửi email.

Trước đó, thường có một người cần nhìn thấy nó chạy nhưng không có môi trường phát triển của bạn: một khách hàng, một designer, một đồng nghiệp ở châu lục khác. Một URL HTTPS công khai trỏ về máy của bạn biến chuyện đó từ một lần triển khai thành một đường liên kết, và phản hồi quay về sẽ đi thẳng vào mắt xích một.

Chuỗi khép lại. Đó là thứ khiến nó là một cái nghề chứ không phải một hàng đợi.

Thứ thật sự co lại, và thứ thật sự lớn lên

Đọc bảng đó một cách thành thật thì nỗi lo đổi hình dạng. Những phần co lại là những phần dễ tuyển người nhất. Những phần lớn lên là những phần cần một người hiểu hệ thống, hiểu người dùng và hiểu hậu quả. Đó là một cái nghề khó hơn, không phải một cái nghề nhỏ hơn, và nó cũng bớt cô độc hơn hẳn so với phiên bản ngồi gõ cả ngày.

Chỗ đứng của AgentsRoom trong tất cả chuyện này

Chúng tôi xây công cụ ôm trọn cả chuỗi, vì lựa chọn còn lại là sáu công cụ chẳng cái nào biết cái nào tồn tại.

Cụ thể: yêu cầu rơi vào một cái bảng, tự xếp thành các ý tưởng, được đề bạt thành ticket, được khoanh phạm vi thành thứ mà agent không thể đọc sai, được thực thi bởi một agent hoặc cả một đội agent trên máy của bạn hoặc trên một máy từ xa, được duyệt theo từng agent kèm cuộc trò chuyện đính sẵn, rồi được đóng lại cùng lúc báo cho người đã xin. Một cửa sổ, một chỗ duy nhất mà trạng thái công việc là đúng.

Từng mảnh riêng lẻ thì nơi khác cũng có. Cái không ai chịu làm là các mối nối giữa chúng, và mối nối chính là chỗ công việc rò rỉ.

Những câu hỏi người ta thật sự đặt ra

AI có thay thế lập trình viên không?

Nó thay thế phần gõ phím, không thay thế cái nghề. Viết code là một mắt xích trong một chuỗi còn gồm: nghe xem người dùng cần gì, quyết định thứ gì đáng xây, đặc tả nó thật chính xác, điều phối việc thực thi, kiểm tra lại, và phát hành. Agent làm sụp đổ chi phí của một mắt xích, và điều đó biến năm mắt xích còn lại thành nút thắt. Sẽ có ít người được trả tiền để sản xuất ra các dòng code hơn. Và có nhiều người hơn được trả tiền để quyết định những dòng nào nên tồn tại, rồi chịu trách nhiệm về chúng khi đã lên sản phẩm.

Lập trình viên thật sự làm gì khi agent viết code?

Sáu việc, và chỉ một trong số đó từng hiện ra trên một màn hình đầy code. Bạn thu thập những gì mọi người đang xin, bạn quyết định xây cái gì và theo thứ tự nào, bạn ra đề bài đủ chính xác để một agent không thể đọc sai, bạn chạy song song nhiều phần việc mà không rối, bạn duyệt tương xứng với mức độ mà mỗi thay đổi có thể phá hỏng, rồi bạn phát hành và báo lại cho người đã xin. Tay nghề đã dịch chuyển từ chỗ tạo ra thay đổi sang chỗ đặc tả nó và chịu trách nhiệm về nó.

Có còn cần biết lập trình không?

Có, và cần hơn trước ở khoản đọc. Bạn không còn phải nhớ cú pháp của một ngôn ngữ mỗi năm chạm vào hai lần, vì agent viết nó. Nhưng bạn phải mở được một diff và trong vài giây biết được một migration có hoàn tác được không, một lượt kiểm tra xác thực có bị dời đi không, một truy vấn có trụ nổi khi lưu lượng gấp mười lần không. Người không đọc được code thì không duyệt được agent, và người không duyệt được agent thì không phải đang điều khiển nó, chỉ đang hy vọng thôi.

Thứ gì vỡ đầu tiên khi giao việc viết code cho agent?

Việc sắp thứ tự ưu tiên. Khi xây một thứ chỉ mất một buổi chiều thay vì hai tuần, cái giá của việc xây nhầm thứ biến mất khỏi tầm mắt, nên người ta cứ xây. Các đội kết thúc với nhiều tính năng đã phát hành hơn mà không giải quyết thêm được vấn đề nào. Thứ vỡ tiếp theo là vòng phản hồi: yêu cầu của người dùng đến nhanh hơn tốc độ phân loại của bất kỳ ai, nên chúng chất đống trong các luồng chat rồi thất lạc, và cùng một yêu cầu bị xây hai lần vì không ai để ý rằng đó vốn là một.

Kỹ năng khó nhất trong cách làm việc mới này là gì?

Viết một đề bài mà agent không thể đọc sai. Agent sẽ không vặn lại một chỉ dẫn mơ hồ theo cách một đồng nghiệp làm, nên nó lấp chỗ trống bằng một phỏng đoán nghe có lý rồi giao cho bạn một thứ mạch lạc nhưng sai. Những người nhận được kết quả tốt không phải là những người có prompt khôn khéo, mà là những người luôn duy trì sẵn ngữ cảnh tái sử dụng được: các tệp quy ước đã commit, một quy trình được lưu lại cho mỗi việc lặp đi lặp lại, một bộ nhớ dự án mà các agent đọc trước khi đi dò, và ảnh chụp màn hình hay hình phác thay cho những đoạn văn mô tả một màn hình.

Nên chạy agent lập trình trên máy của mình hay trên một máy từ xa?

Cả hai, chọn theo từng việc. Bất cứ thứ gì bạn muốn nhìn, ngắt hoặc chỉnh giữa chừng đều thuộc về cái máy đang ở trước mặt bạn. Việc dài, được đặc tả rõ, ít chỗ mơ hồ thì thuộc về một máy khác của bạn hoặc một máy chủ qua SSH, để một tác vụ hai tiếng không bắt cóc chiếc laptop của bạn. Câu hỏi quyết định không phải là sức mạnh, mà là khả năng bạn sẽ phải can thiệp.

Phiên bản ngắn gọn

Cái nghề không biến mất. Nó chỉ rời khỏi trình soạn thảo và chuyển vào cái chuỗi bao quanh nó.

Nếu tháng này bạn chỉ đổi được một thứ, hãy chọn mắt xích một. Mọi thứ nằm phía sau nó đều là công sức đổ đi khi nó nhắm vào sai vấn đề, và đó là mắt xích duy nhất mà một giờ chú ý của bạn vẫn thắng một giờ thời gian agent, với một hệ số mà không ai đo nổi.