Các tác nhân mã hóa đang gây ra sự mệt mỏi trong việc ra quyết định cho mọi người.

Ngày 21/5/2026 Các tác nhân mã hóa đang gây ra sự mệt mỏi do phải đưa ra quyết định cho mọi người. Với phần lớn thời gian của kỹ sư phần mềm chuyển từ viết mã sang cấu trúc lời nhắc và xem xét mã, ngày làm việc đang trở nên dày đặc và căng thẳng hơn. Liệu AI có thể giải quyết các vấn đề mà nó đang gây ra? Tín dụng: Alexandra Francis Không còn nghi ngờ gì nữa, các tác nhân mã hóa đã thay đổi cách phần mềm được xây dựng. Trong khoảng ba năm qua, các trình tạo mã đã phát triển từ tính năng tự động hoàn thành thông thường thành các công cụ có thể tạo ra toàn bộ ứng dụng trong khi bạn chờ đợi. Các kỹ sư có kiến thức về các phương pháp hay nhất, cạm bẫy và ngôn ngữ phần mềm có thể cùng tạo mã mà không cần phải bận tâm đến dấu chấm phẩy và dấu ngoặc chưa đóng. Điều đáng nghi ngờ là liệu sự thay đổi này có mang lại năng suất, hiệu quả chi phí hay có lợi cho các nhà phát triển hay không. Mã dễ tạo đã gây áp lực lớn hơn lên các giai đoạn sau của vòng đời phát triển phần mềm (SDLC): đánh giá mã, DevOps/SRE, bảo mật và cơ sở hạ tầng. Nó cũng gây áp lực lớn hơn lên chính các nhà phát triển. Theo nghiên cứu từ Smartsheet, cường độ tự động hóa đối với người dùng doanh nghiệp của họ đã tăng 55% so với cùng kỳ năm trước và tổng hoạt động đã tăng 46%. Điều đó có nghĩa là ngày làm việc không kéo dài hơn; nó chỉ trở nên dày đặc hơn với công việc khi các hệ thống tự động hóa tạo ra nhiều hơn mà không làm giảm nhu cầu con người phải quyết định thế nào là tốt. Tôi đã nói chuyện với CPTO của Smartsheet, Pratima Arora, về ý nghĩa của sự tăng cường công việc này đối với các kỹ sư phần mềm, tại sao nút thắt cổ chai SDLC mới là sự phán đoán và làm thế nào chúng ta có thể bắt đầu cấu hình lại cách phần mềm được xây dựng để giảm bớt gánh nặng cho những người phải chịu trách nhiệm về năng suất mới. Mã rẻ, đánh giá mã thì không Trong kỷ nguyên tiền AI, mã đắt đỏ vì các kỹ sư đắt đỏ. Họ có rất nhiều kiến thức về các ngôn ngữ, quy trình và mô hình tạo ra phần mềm tốt. Điều đó dẫn đến một số thước đo năng suất tồi tệ: số giờ làm việc, số dòng mã được viết, số lần commit mỗi ngày. Những điều này dễ đo lường và chắc chắn trông giống như một ước tính khá tốt về kết quả. Trên đường đi, các tổ chức bắt đầu xem xét kết quả, với các kế hoạch như DORA cố gắng định lượng chúng. Những thước đo tồi tệ đó đang quay trở lại một cách mạnh mẽ, bất chấp định luật Goodhardt. Không chỉ các lập trình viên tác nhân khoe khoang về số liệu thống kê dòng mã của họ, mà các tổ chức còn khoe khoang về tỷ lệ mã mới được viết bởi AI. Các kỹ sư có thể được xếp hạng theo mức sử dụng token của họ. Xu hướng công nghệ mới này phù hợp với việc tối đa hóa token và bị "nghiện" AI. Bên cạnh việc đây là một thước đo lãng phí, Arora đã đưa ra một ví dụ về lý do tại sao nó lại tồi tệ đối với một tổ chức phần mềm: "Chúng tôi có một kỹ sư phần mềm tạo ra lượng mã gấp 7 lần so với bất kỳ ai trong nhóm của cô ấy. Một siêu sao. Không chỉ vậy, mà còn là mã chất lượng cao. Các lần kiểm tra và đánh giá đều tuyệt vời. Nhưng sáu người khác trong nhóm đã dành phần lớn thời gian để xem xét mã của cô ấy [thay vì] viết mã." Đánh giá mã đòi hỏi chuyên môn rộng trong một cơ sở mã, đặc biệt nếu việc đánh giá đó có hiệu quả và hữu ích. Các đánh giá mã tốt nhất xem xét sự thay đổi trong bối cảnh của hệ thống lớn hơn, điều này đòi hỏi phải nắm giữ và hiểu bối cảnh của hệ thống lớn hơn. Yêu cầu phải đưa ra phán đoán về một commit mã có thể gây ra rất nhiều căng thẳng cho người đánh giá. "Bạn về cơ bản được yêu cầu đóng góp chuyên môn của mình," Carol Lee, Tiến sĩ, hiện đang làm việc tại Intuit, cho biết. "Vì vậy, có một yếu tố là, 'Nếu tôi làm hỏng đánh giá này, tôi là người gác cổng của mã này. Và nếu tôi làm hỏng nó, đó có thể là lỗi của tôi.' Vì vậy, có rất nhiều áp lực ở đó." Hãy nghĩ về nhưng các nhà phát triển ghét phải xử lý mã cũ đến mức nào. Tôi đã suy đoán rằng một trong những lý do khiến các ngôn ngữ mới hơn như Rust được yêu thích hơn trong khảo sát hàng năm của chúng tôi là vì chúng xuất hiện trong các dự án mới, nơi nhà phát triển viết mã từ đầu. Arora cho biết: “Bất cứ khi nào một nhóm kỹ thuật tiếp quản một cơ sở mã cũ, họ muốn viết lại nó trước khi muốn sửa chữa nó”. “Bắt đầu từ đầu và viết nó để bạn hiểu nó dễ dàng hơn nhiều, và khó hơn nhiều khi xem xét mã và đưa ra phán đoán về nơi xảy ra lỗi, bởi vì bạn không viết mã đó.” Mọi nhà xây dựng đều là người ra quyết định Nghiên cứu của Smartsheet cho thấy 80% nội dung do AI tạo ra được chỉnh sửa trước khi hoàn thiện. Những chỉnh sửa đó đến từ việc hiểu bối cảnh của mã đó (hoặc nội dung khác). Đối với mã do AI tạo ra, không ai viết mã gốc, vì vậy bối cảnh bạn cần thu thập lớn hơn. Bạn có thể xem xét các lời nhắc, thông số kỹ thuật và bất kỳ bối cảnh nào khác mà tác nhân của bạn sử dụng, nhưng đó là một công việc khó khăn để đưa ra phán đoán. Nếu chúng ta chuyển phần lớn công việc phần mềm từ viết mã sang đưa ra quyết định, mọi người sẽ cảm thấy căng thẳng vì mệt mỏi khi phải ra quyết định. Trước các quy trình kỹ thuật phần mềm được hỗ trợ bởi AI, các nhà phát triển đã dành một tỷ lệ đáng kể thời gian trong ngày của họ (con số chính xác thay đổi rất nhiều tùy thuộc vào người bạn hỏi) để làm những việc khác ngoài viết mã. Giờ đây, AI viết mã, có nhiều thời gian hơn cho các công việc khác của một kỹ sư. Trên thực tế, bạn có thể đã thấy sự trỗi dậy của nhà xây dựng, mà Arora định nghĩa là “bất kỳ ai hiểu vấn đề hoặc sự cố của khách hàng, có ý tưởng có thể tạo mẫu và xây dựng phần mềm nhanh chóng để thử nghiệm hoặc vận chuyển”. Các kỹ năng cốt lõi của nhà xây dựng là hiểu bối cảnh và đưa ra các quyết định. Smartsheet và những người khác đã phát hiện ra rằng sự thay đổi này không làm cho cuộc sống của các nhà phát triển dễ dàng hơn; nó làm cho họ căng thẳng hơn. Nhiều tác nhân AI chạy trong nền trong khi nhà phát triển xem xét mã, tham dự các cuộc họp và viết tài liệu. Họ cảm thấy năng suất hơn, nhưng không phải lúc nào cũng vậy. Arora nói: “Giờ làm việc không thay đổi, nhưng mật độ công việc đã thay đổi, phải không?” “Số lượng quyết định chúng ta đưa ra trong một ngày, lượng thông tin chúng ta thu thập và cố gắng đưa ra quyết định từ đó đã thay đổi.” Có một lý do khiến những người đưa ra nhiều quyết định, như tổng thống và CEO, mặc cùng một thứ mỗi ngày: bớt đi một quyết định. Họ xây dựng các quy trình xung quanh việc thu thập thông tin, sử dụng nhiều lớp chuyên gia và sự tin tưởng, hy vọng xây dựng nhiều kiểm tra và