Tại sao các đội ngũ kỹ sư cần một chính sách AI rõ ràng và nhất quán

Công việc đầu tiên sau khi ra trường của tôi là tại một văn phòng luật với hàng trăm nhân viên hỗ trợ pháp lý (paralegal). Họ sử dụng một hệ thống quy trình làm việc nội bộ để quản lý các vụ kiện tịch thu nhà và phá sản. Tôi vô tình may mắn khi bước vào một ngành đang bùng nổ ngay khi bong bóng bất động sản vỡ. Đỉnh điểm, chúng tôi xử lý hơn 100.000 vụ mỗi năm.

Công việc được chia nhỏ thành các nhiệm vụ mịn màng. Các nhân viên làm việc từ một hàng đợi các nhiệm vụ, phần lớn có tính chất giống hệt nhau. Đó thực sự là một dây chuyền lắp ráp cho các hồ sơ tòa án; sự áp dụng chủ nghĩa Taylor vào công việc pháp lý.

Trước khi tôi bắt đầu, một giám đốc điều hành mới đã được tuyển về. Một trong những nhiệm vụ của bà là tinh gọn quy trình. Kế hoạch của bà rất đơn giản: bà sẽ đứng sau lưng nhân viên với một đồng hồ bấm giờ và đo thời gian họ hoàn thành nhiệm vụ. Các KPI (chỉ số hiệu suất chính) sẽ được thiết lập dựa trên các phép đo đó.

Kết quả thì cũng như bạn có thể đoán trước. Con người không thực hiện nhiệm vụ theo cách bình thường khi có một giám đốc đứng sau lưng với đồng hồ bấm giờ. Bà ấy nhanh chóng nhận ra sự vô bổ của việc này.

Tất cả những điều trên chỉ là lời dẫn để nói về chỉ số KPI rác rưởi mới nhất trong kỹ thuật phần mềm: Tokenmaxxing, và chính sách AI mà tôi đã viết cho đội của mình.

Tokenmaxxing là cái quái gì vậy?

Tokenmaxxing là trào lưu mới nhất xuất phát từ những nhà quản lý vẫn chưa hiểu — ngay cả vào năm 2026 — rằng mọi chỉ số đều có thể bị "lách luật". Giám đốc với đồng hồ bấm giờ kia không hiểu điều này hơn 20 năm trước, và rõ ràng vẫn có những nhà lãnh đạo ngày nay chưa nhận được thông điệp này.

Ý tưởng là công ty sẽ khuyến khích việc áp dụng các công cụ AI bằng cách tạo ra một bảng xếp hạng ai đang sử dụng nhiều token nhất. Giống như bất kỳ chỉ số ngây thơ nào khác, các kỹ sư ngay lập tức tìm cách lách luật. Chỉ cần tạo một vòng lặp lãng phí token và bắn lên vị trí dẫn đầu bảng xếp hạng. Hoặc lãng phí vừa đủ để cho thấy bạn đang "sử dụng" AI, nhưng không quá nhiều để phải giải thích việc sử dụng đó.

Đây dường như là những gì được gọi là lãnh đạo ngày nay. Tạo ra các chỉ số dễ bị lách luật cho đội ngũ, nhanh chóng tách rời khỏi việc thực sự giúp đỡ mọi người. Bởi vì cuối ngày, chúng ta ở đây để làm gì đó, đúng không? Bạn ở đây để giúp đỡ mọi người. Tôi ở đây để giúp khách hàng đạt được mục tiêu của họ. Tôi không ở đây để sử dụng một lượng token nhất định. Tokenmaxxing là một chỉ số hào nhoáng (vanity metric) giả danh lãnh đạo.

Tại sao cần một chính sách AI?

Tôi quản lý một đội ngũ rất hoài nghi về AI, và điều đó hoàn toàn có lý. Tôi không cần liệt kê các mối quan tâm về đạo đức ở đây. Đã có quá nhiều bài viết suy ngẫm về vấn đề đó.

Tôi cũng không cần liệt kê các mối quan tâm về năng suất. Tùy thuộc vào chiều gió và vị trí của sao Mộc trong cung hoàng đạo, mức độ hữu ích của các công cụ này đối với bạn sẽ khác nhau. Bạn có thể tìm thấy các ví dụ đáng tin cậy ở bất cứ đâu từ 0.1x đến 10x năng suất, tùy thuộc vào cách bạn sử dụng.

Nhưng điều tôi tự tin là thế hệ LLM hiện tại đang gây ra sự xáo trộn lớn nhất trong kỹ thuật phần mềm trong gần hai thập kỷ sự nghiệp của tôi. Và với tư cách là người quản lý một đội ngũ, một phần công việc của tôi là có một lập trường nhất quán về điều này. Vì vậy, sau nhiều thảo luận với đội ngũ, tôi đã nhanh chóng tổng hợp một hướng dẫn mô tả triết lý AI của chúng tôi.

Kể từ khi hoàn thành tài liệu này, tôi đã ngạc nhiên vì có bao nhiêu nhà phát triển tôi đã nói chuyện không có một văn bản như vậy tại nơi làm việc. Mệnh lệnh duy nhất là "hãy dùng AI càng nhiều càng tốt" và hy vọng mọi thứ suôn sẻ.

Tóm tắt chính sách

• Không có mệnh lệnh bắt buộc dùng AI.
• Bạn phải hiểu rõ code do AI tạo ra làm gì.
• Bạn phải có khả năng làm việc của mình nếu công cụ AI biến mất.
• Quan tâm đến đồng đội và khách hàng của chúng ta.

Hãy đi sâu vào chi tiết các điểm này.

Khi nào nên sử dụng công cụ AI

Không có mệnh lệnh bắt buộc sử dụng công cụ AI. Bạn sẽ không được đánh giá dựa trên mức độ bạn sử dụng các công cụ này.

Tuy nhiên, những công cụ này là sự xáo trộn lớn nhất mà ngành của chúng ta thấy trong nhiều thập kỷ. Ngay cả khi bạn không sử dụng chúng hàng ngày, việc bạn nắm bắt được cách chúng phát triển là rất có lợi. Không gian này di chuyển nhanh đến mức kinh nghiệm từ sáu tháng trước có thể không còn phù hợp. Một tác dụng phụ của sự thay đổi kỹ năng lớn này là bất kỳ chuyên môn nào bạn không có được sáu tháng trước có thể đã lỗi thời vào ngày nay.

Các kỹ sư cấp Senior trở lên được khuyến khích sử dụng các công cụ này theo bất kỳ cách nào phù hợp nhất với họ. Điều đó có thể là một phần không thể thiếu trong quy trình làm việc hàng ngày hoặc chỉ là một công cụ thỉnh thoảng dùng cho các bản chứng minh khái niệm (proof of concepts) cho code không sản xuất.

Có một mâu thuẫn vốn có trong những người cổ xúy cho AI:

• Nếu bạn không lên tàu AI ngay bây giờ, bạn sẽ bị bỏ lại phía sau.
• AI di chuyển nhanh đến mức mọi thứ bạn biết hôm nay sẽ vô giá trị trong sáu tháng.

Không thể cả hai điều trên đều đúng. Tại sao tôi không thể đợi đến sáu tháng nữa và sử dụng các mô hình và kỹ thuật tốt hơn? Tôi sẽ không phải bỏ học các kỹ thuật chỉ tồn tại để giải quyết sự non nớt của công cụ hiện tại.

Chúng tôi tuyển dụng những người thông minh và tin tưởng họ làm việc. Tôi không quan tâm họ dùng hệ điều hành nào. Tôi không quan tâm họ dùng trình soạn thảo nào. Tôi không quan tâm họ dùng công cụ AI nào. Tôi quan tâm đến việc họ mang lại giá trị cho khách hàng.

Nhưng như chính sách nói, sự xáo trộn là có thật. Bạn có nghĩa vụ nghề nghiệp cần thử các công cụ này thỉnh thoảng. Công cụ tôi dùng vào tháng 6 năm 2025 tệ hơn nhiều so với công cụ tôi quay lại sử dụng vào tháng 1 năm 2026. Tôi mong đợi công cụ tôi sử dụng vào tháng 6 năm 2026 sẽ còn tốt hơn.

Đó vẫn là Code của bạn

Bất kỳ code nào được tạo ra bởi công cụ AI là code của bạn. Không quan trọng AI đã viết bao nhiêu phần trong PR (Pull Request) của bạn, bạn được mong đợi phải hiểu code đó làm gì. Code đó được mong đợi phải phù hợp với các mẫu hiện có của chúng tôi. Tệp AGENTS.md của chúng tôi nên giúp việc này, nhưng không đảm bảo bất cứ điều gì. Bạn chịu trách nhiệm đảm bảo code bạn gửi để xem xét đạt chuẩn.

Đừng đặt gánh nặng quá lớn lên người xem xét (reviewer). Chúng ta đôi khi đều gửi các PR đáng ngờ. Điều này có thể do áp lực thời gian xung quanh lỗi sản phẩm cấp độ sự cố hoặc vì chúng ta đang ở trong không gian thiết kế mới. Tuy nhiên, vẫn là trách nhiệm của người gửi PR phải chỉ ra điều này. Sử dụng công cụ AI không phải là cái cớ để đánh dấu tất cả các PR của bạn là "đáng ngờ".

Con người cuối cùng đưa ra các quyết định kiến trúc, không phải AI. Khi có sự lựa chọn giữa chấp nhận code giúp máy dễ xử lý hơn so với code giúp con người dễ hiểu hơn, chúng tôi ưu tiên con người. Nếu công cụ AI liên tục tạo ra code không tuân thủ tiêu chuẩn coding của chúng tôi, thì công cụ AI mới là thứ cần thay đổi, có thể bằng cách cải thiện tệp AGENTS.md của chúng tôi.

Những người theo chủ nghĩa tối đa AI (AI maximalists) sẽ đọc phần này và cười nhạo. Họ đang "vibe coding" mọi thứ và ít hoặc không có ý kiến về code được tạo ra trông như thế nào. Nếu chúng tôi là một startup xanh (greenfield startup), tôi có thể cũng sẽ tiếp cận theo cách này. Nhưng chúng tôi không phải. Chúng tôi có một cơ sở mã (codebase) mười năm tuổi đầy rẫy các phong cách mâu thuẫn được đưa vào bởi các đội khác nhau. Đôi khi đó là khảo cổ học code thuần túy để tìm hiểu lý do tại sao một thứ lại theo cách đó.

Cược của người theo chủ nghĩa tối đa AI là các mô hình sẽ cải thiện với tốc độ vượt quá nợ kỹ thuật (tech debt) họ đang tích lũy. Điều này tương tự như cược mà các startup đã đặt trong nhiều năm. Không quan trọng code ban đầu tệ đến mức nào. Trọng tâm là tìm thấy sự phù hợp giữa sản phẩm và thị trường (product-market fit) và lo lắng về tính bền vững sau này. Tuy nhiên, chúng tôi đã có sự phù hợp giữa sản phẩm và thị trường. Chúng tôi quan tâm đến khả năng làm việc trên codebase này trong thập kỷ tới. Khách hàng của chúng tôi quan tâm đến việc các tính năng hiện tại tiếp tục hoạt động.

Nếu bạn là người theo chủ nghĩa tối đa AI, điểm nghẽn đang chuyển dịch sang đâu? Có phải là xem xét code? Có phải là biết khách hàng của bạn thực sự muốn gì? Có phải là tốc độ thay đổi mà khách hàng của bạn có thể hấp thụ? Việc có khả năng viết code nhiều hơn 10 lần về lý thuyết không có nghĩa là bạn đang cung cấp giá trị nhiều hơn 10 lần cho khách hàng.

Nếu Claude ngừng hoạt động vào ngày mai, bạn có thể vẫn làm được việc của mình không? Bạn có thể hiểu code trước mặt mình không? Nếu OpenAI phá sản vào tuần tới, bạn có sẽ nhìn vào những kinh hoàng trong codebase của mình và khóc lóc không?

Tôi đã dành một thập kỷ làm tư vấn. Tôi đã nhảy dù vào những codebase thực sự tồi tệ. Việc LLM bạn chọn không hoạt động vào ngày hôm đó không nên khiến bạn run rẩy sợ hãi khi cố gắng xác định cách sử dụng năm phiên bản khác nhau của các hàm định dạng ngày tháng trong đống rác AI mà bạn đã tạo ra.

Vậy còn Kỹ sư Junior thì sao?

Bất kể bạn nghĩ phong cách học tập của mình là gì, chúng ta đều học bằng cách làm. Trong phần mềm, điều này có nghĩa là viết code. Bạn phải suy nghĩ qua các hệ quả và sắc thái của code bạn đang viết ở nhiều mức độ hiểu biết để thực sự học được. Các công cụ coding AI làm ngắn mạch quá trình học tập này bằng cách tước đi cơ hội thực hành của bạn.

Vì lý do này, các kỹ sư Junior nên sử dụng các công cụ này một cách thận trọng. Dựa vào công cụ AI để viết code giúp bạn sẽ hạn chế sự phát triển lâu dài của bạn. Bạn sẽ không đạt được mức độ hiểu biết sâu sắc cần thiết để thăng tiến sự nghiệp và đảm nhận các dự án lớn hơn.

Điều đó không có nghĩa là các công cụ này bị cấm đối với kỹ sư Junior. Tuy nhiên, nếu công cụ AI của bạn biến mất vào ngày mai và bạn thấy mình không thể đóng góp, đó là một vấn đề.

Đây có thể là phần của chính sách mà tôi cảm thấy mạnh mẽ nhất. Ngành của chúng ta đang nhanh chóng kéo thang lên khỏi tầm với của các kỹ sư Junior. Chúng ta đang lấy đi loại công việc mà bạn cần để học hỏi. Bạn cần thực hành những việc vặt (toil) mà AI xuất sắc trong việc tự động hóa.

Thế hệ AI hiện tại đã nhanh chóng phơi bày rằng hầu hết mọi người không có manh mối về cách học tập hoạt động. Phong cách học tập là một huyền thoại. Bạn có thể có sở thích về cách bạn tiêu thụ thông tin, nhưng bạn học bằng cách làm. Học tập diễn ra trong sự đấu tranh. Bạn phải vật lộn với một khái niệm. Bạn phải bối rối đôi khi. Điều đó không phải là tùy chọn. Nếu bạn dựa vào LLM để viết hầu hết code của bạn, code mà bạn không tự viết thực hành, bạn sẽ không học. Bạn sẽ không đạt được sự hiểu biết sâu sắc.

Việc bạn cảm thấy kỹ sư Junior nên sử dụng các công cụ này bao nhiêu phụ thuộc vào việc bạn cảm thấy vai trò của Junior trong đội của mình là gì và trách nhiệm của bạn đối với sự nghiệp của họ là gì. Tôi không mong đợi kỹ sư Junior năng suất. Tôi mong đợi họ học cách để trở nên năng suất. Tôi mong đợi họ mắc lỗi. Tôi mong đợi họ học cách học một codebase. Tôi mong đợi họ học cách học một lĩnh vực. Và nếu họ thuê ngoài hầu hết việc đó cho một LLM, họ sẽ không học cách tự suy nghĩ về nó.

AI ở dạng hiện tại là một sự trừu tượng rò rỉ (leaky abstraction) quá mức以至于 các chi tiết này không ngừng nổi lên trong bất kỳ codebase hoặc lĩnh vực nào có độ phức tạp hợp lý. Cho đến khi điều đó thay đổi, Junior phải học và học diễn ra bằng cách làm.

Bạn nên có thể diễn đạt theo cách nào đó vai trò của Junior trong đội của bạn và trách nhiệm của bạn cho sự phát triển của họ, nếu có. Vai trò và mục tiêu bạn có cho họ có thể khác với của tôi. Điều đó nên thúc đẩy triết lý của bạn về việc họ nên sử dụng bao nhiêu công cụ.

Chúng tôi quan tâm đến con người

Cuối cùng, chúng tôi giao code để giúp khách hàng của chúng tôi tiếp cận mọi người. Chúng tôi quan tâm đến khách hàng của mình. Đồng thời, chúng tôi làm việc nội bộ như một đội. Chúng tôi quan tâm đến đồng đội của mình.

Hai khán giả này thường xuyên căng thẳng với nhau. Có thể có áp lực để giao nhiều tính năng hơn cho khách hàng để giúp họ tiếp cận mọi người. Điều này ổn trong các đợt ngắn vì lý do chính đáng. Quá nhiều có thể làm tổn thương đồng đội khi nợ kỹ thuật tích lũy.

Điều này có liên quan trong thế giới AI của chúng ta. Có thể rất cám dỗ để đẩy ra càng nhiều code do AI tạo ra càng tốt để làm khách hàng vui hơn. Tuy nhiên, điều đó không thể được thực hiện với cái giá là "rác AI" (AI-slop) trong codebase của chúng tôi. Nó làm tổn thương năng suất và hạnh phúc lâu dài của đội ngũ. Các kỹ sư không muốn dành cả ngày để xem xét các PR rác AI.

Tokenmaxxing tách rời khỏi việc quan tâm đến con người. Tôi quan tâm đến con người, không phải token. Nếu sử dụng token giúp bạn giúp đỡ con người, thì cứ dùng token. Nhưng token không phải là đích đến. Token là phương tiện. Trình soạn thảo của tôi là phương tiện. Ngôn ngữ lập trình tôi chọn là phương tiện.

Đội của tôi là một tập con của danh mục con người. Tôi quan tâm đến con người, do đó tôi cũng quan tâm đến đội của mình. Và điều đó có nghĩa là ép buộc đội của tôi sử dụng các công cụ làm cho họ khó chịu hàng ngày là một Điều Tồi.

Tôi có thể sai về điều này. Có thể AI sẽ tốt đến mức chúng tôi sẽ bị chôn vùi bởi các đối thủ cạnh tranh. Hoặc có thể nó tốt đến mức hệ thống kinh tế hiện tại cũng sụp đổ. Tôi không biết mọi việc sẽ đi về đâu, nhưng tôi biết rằng tôi quan tâm đến con người. AI không phải là con người.

Chính sách này có nên áp dụng cho đội của tôi không?

Mỗi đội và công ty đều khác nhau. Chính sách này hoạt động cho đội của tôi. Nó có thể hoặc không thể hoạt động cho đội của bạn. Chúng tôi có một codebase đã được thiết lập mười năm tuổi đã trải qua rất nhiều biến động qua các năm. Môi trường pháp lý mà chúng tôi làm việc đã trở nên phức tạp hơn nhiều theo thời gian. Chúng tôi có những khách hàng lâu năm sẽ không vui nếu chúng tôi bắt đầu phá vỡ mọi thứ trái phải trong một cơn vội vã áp dụng công cụ AI. Bạn có thể cũng không vui về các công cụ bạn phụ thuộc đang làm điều đó ngay bây giờ.

Các ràng buộc của bạn khác nhau, vì vậy chính sách của bạn có lẽ cũng nên khác nhau. Tôi biết nếu tôi đang làm việc tại một startup xanh với cùng một đội, các ràng buộc sẽ hoàn toàn khác nhau, vì vậy cách chúng tôi sử dụng AI sẽ thay đổi tương ứng.

Nhưng bạn nên có một loại triết lý nhất quán nào đó về những gì bạn đang cố gắng đạt được. Tokenmaxxing không nhất quán. Nó chỉ là đếm dòng code một lần nữa, lần này với đặc quyền trả hàng nghìn đô la cho bên thứ ba cho chỉ số rác rưởi của bạn. Nếu đó là những gì đủ điều kiện để làm lãnh đạo, có lẽ chúng ta có thể thay thế bạn bằng một tác nhân AI tiếp theo? Bạn nợ đội của mình (và chính mình) phải tốt hơn thế.