Tại Sao Mã Code Được Viết Bởi Trí Tuệ Nhân Tạo Làm Cho Các Nhà Phát Triển Phàn Nàn — Và Làm Thế Nào Để Giải Quyết Vấn Đề Này

Với hầu hết các công nghệ, càng sử dụng lâu, bạn sẽ càng cảm thấy thoải mái khi依赖 vào chúng. Tuy nhiên, với các công cụ trí tuệ nhân tạo, điều ngược lại đã xảy ra: trong cuộc khảo sát hàng năm của hơn 49.000 nhà phát triển, Stack Overflow đã ghi nhận việc sử dụng tăng lên 84%, trong khi sự tin tưởng vào độ chính xác của các công cụ này đã giảm từ 40% xuống 29% trong vòng một năm.

Hiệu ứng này quen thuộc với tôi. Kinh nghiệm đầu tiên của chúng tôi với các công cụ trí tuệ nhân tạo trong phát triển không có nhiều điểm chung với hiệu ứng “wow” của công việc nhanh hơn và ít nhàm chán hơn mà báo chí công nghệ thường viết về. Các nhà phát triển của chúng tôi đã thất vọng: trí tuệ nhân tạo sản xuất mã trung bình, mất nhiều thời gian để xem xét và cuối cùng phải được viết lại. Đội ngũ dự án mong đợi trí tuệ nhân tạo sẽ tiết kiệm thời gian, nhưng thay vào đó, họ nhận được thêm công việc. Vì vậy, không lâu sau những nỗ lực đầu tiên để tích hợp các công cụ trí tuệ nhân tạo vào quy trình làm việc hàng ngày, đội ngũ đã quay lại cách làm việc truyền thống.

Ngày nay, những công cụ đó đã tăng tốc cả việc viết mã và xem xét mã cho các nhà phát triển của chúng tôi — không phải vì chúng tôi tìm thấy một mô hình tốt hơn, mà vì chúng tôi đã thay đổi cách làm việc với nó. Dưới đây là những gì đã giúp chúng tôi đạt được điều đó.

Tại Sao Mã Code Được Viết Bởi Trí Tuệ Nhân Tạo Làm Cho Các Nhà Phát Triển Phàn Nàn

Trí tuệ nhân tạo dựa trên một khối lượng lớn mã công khai từ khắp internet, và mã đó hiếm khi là mẫu mực: chất lượng của nó là trung bình, và mô hình sẽ tái tạo trung bình đó.

Tuy nhiên, “trung bình” không phải là giới hạn của những gì có thể đạt được — nó chỉ đơn giản là những gì mô hình tạo ra cho đến khi nó biết về dự án của bạn: các quy ước, cấu trúc mã, quyết định kiến trúc. Trong một cuộc khảo sát của hơn 600 nhà phát triển, Qodo đã phát hiện rằng trong số những người không hài lòng với chất lượng mã của trí tuệ nhân tạo, 44% cho rằng nguyên nhân chính là do thiếu ngữ cảnh. Đó là điều khiến đầu ra bị kẹt ở mức trung bình.

Tin tốt là ngữ cảnh mà trí tuệ nhân tạo nhận được là biến số duy nhất mà một đội ngũ hoàn toàn kiểm soát. Việc công cụ hiểu dự án phụ thuộc không vào mô hình, mà vào những gì bạn cung cấp cho nó.

Lý do thứ hai là tâm lý — bản chất của công việc thay đổi. Khi trí tuệ nhân tạo viết hầu hết mã, hành động chính của nhà phát triển không còn là viết mã mà là kiểm tra những gì đã được tạo ra: đọc giải pháp của người khác, cân nhắc các lựa chọn, quyết định những gì sẵn sàng để xuất bản. Đó là một kỹ năng khác với việc viết mã bản thân, và đối với bất kỳ ai yêu thích việc viết mã, nó không dễ dàng.

Trong báo cáo Octoverse năm 2025, GitHub đã mô tả chính xác sự thay đổi này: những nhà phát triển đã đi xa nhất với trí tuệ nhân tạo không còn gọi mình là “tác giả của mã” và trở thành điều gì đó gần giống với “đạo diễn sáng tạo” của nó, nơi kỹ năng chính là điều khiển và xác minh. Nhưng con đường đến vai trò đó đi qua những sai lầm và thất vọng, cho đến khi một người nhìn thấy lợi ích trong công việc của mình.

Điều Gì Chuyển Đổi Trí Tuệ Nhân Tạo Từ Một Nguồn Thất Nhiệm Thành Một Công Cụ Làm Việc

Khi đội ngũ của chúng tôi lần đầu tiên bắt đầu sử dụng trí tuệ nhân tạo, một số nhà phát triển làm việc với Claude Code, những người khác thử OpenAI Codex, GitHub Copilot, hoặc Gemini CLI, và mỗi công cụ cho ra kết quả khác nhau. Vì vậy, khi chúng tôi bắt đầu đưa ra trật tự cho cách đội ngũ làm việc với trí tuệ nhân tạo, điều đầu tiên chúng tôi làm là thống nhất về một công cụ duy nhất.

Đây không chỉ là thực tiễn của chúng tôi. Hãy xem câu chuyện của đội ngũ tại Linear: cho đến đầu năm 2026, họ chạy trên nguyên tắc “hãy để mọi người làm việc theo cách phù hợp với họ”, và vào tháng 1, lãnh đạo đã từ bỏ cách tiếp cận này và chuyển tất cả mọi người sang một cách làm việc duy nhất — thu hẹp lựa chọn xuống hai công cụ trí tuệ nhân tạo và yêu cầu các nhà phát triển viết mã chỉ với chúng, thay vì viết tay. Theo công ty, năng suất trung bình tăng lên 30% trong các yêu cầu hợp nhất và 33% trong các nhiệm vụ được hoàn thành trên mỗi kỹ sư vào tháng tiếp theo.

Điều đó nói lên rằng, một công cụ chia sẻ không cải thiện mã — nó phải được cấu hình: thiết lập quy tắc, giống như một quy tắc.md, quy định cách viết mã — những phương pháp nào cần tuân theo, những gì cần tránh. Sau đó, đến các kỹ năng tùy chỉnh cho các nhiệm vụ điển hình của dự án, để bạn không phải giải thích cùng một điều nhiều lần. Và cuối cùng, đáng để chỉ định cho công cụ phân tích cơ sở mã hiện có: nó phân tích cách dự án được viết và tạo ra mã mới trong cùng một phong cách, thay vì một phong cách chung chung. Càng nhiều ngữ cảnh mà công cụ nhận được, bạn càng không phải viết lại bằng tay sau đó.

Tuy nhiên, phần khó nhất không phải là kỹ thuật. Sự chuyển đổi từ tác giả của mã sang người đánh giá không xảy ra tự nhiên — sự chuyển đổi đó cần sự giúp đỡ. Con đường trực tiếp nhất là đào tạo và chứng nhận. Trong trường hợp của chúng tôi, ví dụ, mười nhà phát triển đang tham gia một chương trình đối tác với nhà cung cấp công cụ, trong khi bên cạnh họ là người phụ trách việc áp dụng, người giải thích tại sao công cụ tạo ra một kết quả nhất định và cách sửa nó.

Một khi đội ngũ đã làm việc theo cách phối hợp, một nút thắt cổ chai còn lại — xem xét — và đáng để tăng cường với trí tuệ nhân tạo. Công cụ đi qua mỗi yêu cầu hợp nhất đầu tiên và thực hiện những việc rõ ràng: lỗi thường xuyên, phong cách, lặp lại, lỗ hổng bảo mật. Người xem xét sau đó không còn nhìn vào mọi thứ một cách vô điều kiện, mà chỉ vào kiến trúc và các quyết định quan trọng. Hiệu ứng này rõ ràng ngay cả trong các công ty xây dựng những công cụ này: tại Anthropic, sau khi giới thiệu một công cụ như vậy, tỷ lệ yêu cầu hợp nhất nhận được xem xét thực chất tăng từ 16% lên 54%, và các kỹ sư không đồng ý với ít hơn 1% bình luận của nó.

Đối với chúng tôi, điều này đã rút ngắn chu kỳ xem xét vốn trước đây kéo dài qua hai hoặc ba ngày qua nhiều vòng, và nó đã giải phóng công việc thường xuyên khỏi các kỹ sư cao cấp, để lại cho họ những điểm khó thực sự. Một khi công cụ cuối cùng bắt đầu tạo ra kết quả không cần phải viết lại, sự tin tưởng vào nó cũng xuất hiện.

Ở Đâu Sự Tin Cậy Vào Các Công Cụ Trí Tuệ Nhân Tạo Đưa Đến Lợi Ích

Trước hết và quan trọng nhất — trong việc viết mã: khi công cụ biết về dự án và công cụ xử lý xem xét đầu tiên, đội ngũ viết nhiều hơn và tốt hơn trong cùng một khoảng thời gian. Trong trường hợp của chúng tôi, các công cụ trí tuệ nhân tạo đã tăng tốc công việc lên khoảng 30-40%.

Bên cạnh đó, trí tuệ nhân tạo đã làm cho việc giới thiệu mới dễ dàng hơn. Khi một người mới tham gia dự án, người có kinh nghiệm thường phải trả lời hàng chục câu hỏi về cách mã của dự án được xây dựng. Giờ đây, công cụ xử lý vai trò đó: nếu dự án được tài liệu hóa tốt, người mới có thể chuyển hướng tới 95% những câu hỏi đó tới công cụ thay vì tới đồng nghiệp.

Câu chuyện tương tự với tài liệu: một bản thảo kiến trúc thô mà trước đây mất nhiều giờ để viết bây giờ được viết chủ yếu bởi công cụ — theo ước tính của chúng tôi, khoảng 80% bản thảo, nếu bạn cung cấp đủ ngữ cảnh. Những gì còn lại cho con người là những gì không có trong kho lưu trữ — quyết định, sự đánh đổi, chuyên môn.

Cũng quan trọng không kém là trung thực về giới hạn của những gì trí tuệ nhân tạo có thể làm, vì chính những kỳ vọng bị thổi phồng đã tạo ra sự thất vọng từ đầu. Trí tuệ nhân tạo không đảm nhận việc tuân thủ — một con người ký vào dữ liệu y tế hoặc tài chính, và công ty, không phải mô hình, chịu trách nhiệm về việc rò rỉ.

Trí tuệ nhân tạo không tăng tốc các tích hợp với đối tác, nơi hàng chục giờ được dành cho các cuộc gọi và phối hợp. Trí tuệ nhân tạo ngoài hộp thật sự rất khó chịu — nhưng chỉ khi nó được sử dụng như một giải pháp hoàn chỉnh. Toàn bộ sự khác biệt giữa thất vọng và lợi ích nằm ở những gì bạn xây dựng xung quanh nó: một tiêu chuẩn chung, ngữ cảnh của dự án, và vai trò mới của nhà phát triển.