AI, Ashby và Tương lai: Khi chi phí viết mã giảm về 0, kỹ sư cần gì?

Tại Ashby, kể từ tháng 8 năm 2025, hơn một nửa lượng mã nguồn mới được triển khai lên hệ thống sản xuất (production) do AI tạo ra. Tuy nhiên, số lượng vấn đề từ khách hàng vẫn giữ ổn định. Chúng tôi có nhiều khách hàng hơn, nhiều mã do AI viết hơn, và "trời không sập xuống".

Thống kê mã nguồn AI và lỗi

Chúng tôi cũng không ghi nhận sự suy giảm nào về chất lượng mã, tốc độ phát triển hay thời gian hội nhập của các kỹ sư mới (ngược lại, khả năng hiểu codebase còn tăng lên!). Đây không phải là một dự án đồ chơi. Ashby là bộ phần mềm tuyển dụng với hơn 100.000 người dùng hoạt động hàng tuần và hàng triệu đơn ứng viên mỗi tuần.

Tôi là Colin, Trưởng bộ phận Kỹ thuật khu vực EMEA tại Ashby. Tôi muốn chia sẻ cách chúng tôi nghĩ về AI và những thay đổi mà nó mang lại cho công việc của chúng tôi.

Luận điểm: Chi phí sản xuất mã đang tiến về 0

Luận điểm của chúng tôi là: chi phí để viết mã đang hướng về 0. AI không đến để lấy mất việc làm của chúng ta, nó đến để thay thế các phần cơ khí trong công việc: cú pháp, mã kết nối (glue code), và những gõ phím nhàm chán. Những phần ít thú vị và ít thách thức hơn.

Phần quan trọng đối với kỹ sư — phán đoán của bạn, gu thẩm mỹ của bạn, sự hiểu biết về khách hàng của chúng ta — đang trở nên quan trọng hơn, không phải ít hơn. Giá trị của một kỹ sư luôn được đánh giá qua sự phán đoán. Mọi sự cải thiện hiệu quả trong việc tạo ra mã chất lượng cao đều đẩy vai trò của chúng ta hướng về phía đó. AI sẽ là một bước chuyển dịch lớn hơn những gì chúng ta từng thấy.

"Hiện tại hầu hết tất cả các PR (Pull Request) của tôi đều do AI viết hoàn toàn. Tôi đã triển khai toàn bộ quá trình nhập liệu dữ liệu thông qua AI... khoảng 40 PR" — Tom, một trong những kỹ sư của chúng tôi.

Hai nguyên tắc cơ bản

Khi chúng ta sử dụng LLM ngày càng nhiều và thế giới xung quanh thay đổi, chúng tôi tin rằng có hai nguyên tắc cơ bản:

1. Sự thấu cảm không thể bị AI thay thế.
2. Bạn chịu trách nhiệm cho những gì bạn triển khai.

Sự thấu cảm không thể bị AI thay thế

Xây dựng sản phẩm là một nỗ lực của con người. LLM không có gu thẩm mỹ. Chúng không biết khách hàng của chúng ta là ai. Chúng không thể cảm nhận hay hiểu sự thất vọng khi sử dụng một sản phẩm tồi hay niềm vui khi sử dụng một sản phẩm xuất sắc. Điều đó vẫn đòi hỏi sự phán đoán, và trong một thế giới việc xây dựng một sản phẩm chức năng diễn ra cực nhanh, khả năng xây dựng một sản phẩm tuyệt vời càng trở nên quan trọng hơn.

Sự thấu cảm có nghĩa là nhớ viết các tài liệu này dành cho con người sẽ đọc chúng. LLM có thể giúp viết, nhưng nếu không có hướng dẫn, LLM sẽ viết những tài liệu có vẻ thuyết phục nhưng khó đọc cho con người, đầy chi tiết không quan trọng và thiếu niềm vui cũng như trí tuệ.

Đừng giao việc viết tài liệu cho con người cho LLM.

Bạn chịu trách nhiệm cho những gì bạn triển khai

LLM có thể sai một cách kỳ diệu. Tự tin sai lầm. Cẩu thả một cách khó hiểu. Rủi ro lớn nhất với AI không phải là nó sai, mà là nó nghe có vẻ đúng.

"Tôi không có ý định gỡ bỏ gói tar-stream — đó là một tai nạn ngoài ý muốn khi tôi đang chỉnh sửa backend/package.json..." — Claude Code.

Bạn chịu trách nhiệm cho những gì bạn triển khai. Dù từng dòng code được viết tay hay LLM tạo ra toàn bộ PR. Bạn chịu trách nhiệm việc hiểu mã làm gì, tại sao nó làm như vậy, và điều gì xảy ra khi nó bị lỗi.

Khi chúng ta sử dụng LLM nhiều hơn, sự hoài nghi phải tăng lên, không phải giảm đi. Hãy yêu cầu các phương án thay thế. Hãy hỏi về các trường hợp ngoại lệ (edge cases). Hãy yêu cầu nó tự phê bình. Hiểu lý do trước khi chấp nhận kết quả.

Specs (Đặc tả kỹ thuật) là dành cho Con người

Một trong những sự thay đổi chúng tôi thấy là ý định đưa specs cho LLM. Chúng tôi luôn coi trọng specs. Chúng giúp giảm rủi ro phát triển và đảm bảo sự đồng bộ. LLM cũng được lợi từ ngữ cảnh mà specs cung cấp.

Tuy nhiên, những gì con người cần từ một spec và những gì LLM cần là khác nhau. Với tư cách là con người, chúng ta cần một thứ gì đó tôn trọng thời gian của chúng ta, thu hút chúng ta với tư cách là người đọc, và tập trung sự chú ý của chúng ta vào các quyết định quan trọng. Ví dụ, một thứ cho biết tại sao bạn quyết định dùng Redis thay vì Postgres, thay vì một tài liệu liệt kê mọi giá trị có thể có của một enum mới.

Chúng ta cần một thứ thể hiện sự thấu cảm với chúng ta. Chúng ta phải tiếp tục viết specs cho con người. Specs tập trung vào các quyết định tốn kém để thay đổi. Specs giảm rủi ro xây dựng sai thứ. Chúng xác định các sự trừu tượng hóa (abstractions) mà chúng ta sẽ cần.

Hai chế độ làm việc với AI

Tôi thấy hai cách riêng biệt để làm việc với LLM: như một trợ lý (sidekick) hoặc như một người được ủy quyền (delegate). Nhận ra chế độ bạn đang ở và chế độ bạn nên ở là kỹ năng then chốt.

Các chế độ làm việc với AI

Mặc định là chế độ trợ lý. Bạn sử dụng AI để khám phá codebase, tìm và tiêu hóa lượng lớn thông tin, và triển khai các specs chi tiết mà bạn đã viết. Bạn đưa ra hầu hết các quyết định.

Đây là chế độ cho bất cứ thứ gì rủi ro cao: di chuyển cơ sở dữ liệu, xử lý dữ liệu ứng viên, mã nhạy cảm về bảo mật và các quyết định kiến trúc. Đây là những nơi mà "trông có vẻ đúng" là chưa đủ. Bạn cần ngồi vào ghế lái.

Chuyển sang chế độ ủy quyền khi phạm vi ảnh hưởng nhỏ. Bạn xem xét kết quả đầu ra — hoặc đôi khi không. Làm mẫu (prototyping), công cụ cục bộ và công cụ vận hành là những ứng viên tuyệt vời ở đây. Bạn có thể di chuyển nhanh vì chi phí thất bại thấp.

Hầu hết các kỹ sư sẽ ủy quyền quá nhiều lúc đầu. Sau đó họ sẽ điều chỉnh quá mức và ủy quyền quá ít. Câu hỏi không bao giờ là "tôi có nên dùng AI không?" — mà là "tôi nên tin tưởng nó bao nhiêu ở đây?". Hãy nghĩ xem điều gì xảy ra nếu mã sai. Nó có gây xấu hổ không? Tốn kém không? Đe dọa đến sự tồn tại không?

Chúng tôi đang sử dụng AI như thế nào ngay bây giờ

Chúng tôi tích cực khuyến khích kỹ sư sử dụng công cụ AI để hỗ trợ công việc. Chúng tôi không bắt buộc sử dụng AI hay đo lường mức độ sử dụng token. Niềm tin của chúng tôi là việc làm vậy khuyến khích sự cẩu thả.

Khi viết mã trở nên rẻ hơn, an toàn trở nên quan trọng hơn. An toàn phải được xây dựng vào cơ sở hạ tầng, không được áp đặt như một kỷ luật. Chúng tôi nghĩ về an toàn bằng mô hình "Thụy Sĩ" (Swiss Cheese model). Mọi lớp đều có lỗ hổng, nhưng các lỗ hổng nằm ở những nơi khác nhau. Tests bắt những gì review bỏ sót, feature flags bắt những gì tests bỏ sót, và observability bắt những gì lọt qua tất cả mọi thứ.

Chúng tôi cũng sử dụng linters, DangerJS và AI để hỗ trợ review mã. Chúng tôi sử dụng các công cụ bên thứ ba như CodeRabbit để thực hiện lượt xem đầu tiên trước khi con người vào cuộc. Chúng tôi cũng đã xây dựng công cụ review mã của riêng mình tập trung vào việc tìm các lỗi edge case khó xử lý trong môi trường production.

Điều gì tiếp theo?

Chúng tôi tiếp tục đầu tư vào DevEx và công cụ để đảm bảo AI tạo ra mã chất lượng cao trong khi giảm bớt gánh nặng cho con người.

Thay đổi quy trình Review

Tại Ashby, chúng tôi đã review các thay đổi mã. Các review của chúng tôi khá rộng và bao gồm mọi thứ từ bắt lỗi đến cơ hội trừu tượng hóa. Lượng đầu ra gia tăng trong tương lai sẽ vượt quá khả năng review của chúng ta. Chúng ta cần phê phán lý do tại sao chúng ta review mã.

Con người không giỏi bắt lỗi. Kỹ sư không nên dành thời gian để nghĩ xem liệu người khác đã dùng useMemo đúng chưa trong một component hay không. Chúng ta không ở đây để làm linter cho con người. Con người không nên dành nhiều thời gian để xem xét từng dòng mã của người khác. Tự review và các công cụ khác (ví dụ: linting) nên xử lý 90% việc đó.

Vậy chúng ta ở đây để review cái gì?

• Thay đổi đó có hợp lý không?
• Các khu vực rủi ro cao là gì? Làm thế nào để giảm những rủi ro đó?
• Đặc điểm hiệu suất là gì?
• Các sự trừu tượng hóa có hợp lý không? Chúng ta có đang trừu tượng hóa đủ không?

Điểm cuối cùng về sự trừu tượng hóa hợp lý xứng đáng được nhấn mạnh. LLM có thiên hướng tạo mã mới thay vì tái sử dụng những gì đã tồn tại. Nếu không được kiểm soát, chúng sẽ xây dựng cho bạn một codebase hoạt động nhưng không ai điều hướng được. LLM không quan tâm nếu mã chúng tạo ra phức tạp. Đẩy hướng tới sự đơn giản giờ đây là một trong những điều giá trị nhất mà một người review có thể làm.

Xác minh tự động

Trong nhiều năm, viết mã là phần đắt đỏ, và kiểm thử (testing) là điều suy nghĩ sau cùng. AI đã đảo ngược điều đó. Viết mã giờ rẻ. Xác minh là nút thắt cổ chai, và khoản đầu tư của chúng ta cần đi theo đó.

Chúng ta cần nhiều bài kiểm tra tốt hơn: fuzz tests và frontend unit tests. Phân tích tĩnh một lần nữa lại trở nên phù hợp. Chúng ta sẽ cần nhiều AI review AI hơn. Review tự động tập trung vào hiệu suất, xử lý dữ liệu cá nhân (PII), xử lý lỗi và bảo mật.

Lời kết

Codebase của chúng tôi có khán giả mới. Mọi pattern, mọi tên, mọi ranh giới mô-đun giờ đây được đọc bởi LLM cũng như con người — và LLM hiểu theo nghĩa đen những gì chúng tìm thấy. Một codebase lộn xộn không chỉ làm chậm đồng nghiệp của bạn nữa; nó làm suy giảm mọi đoạn mã do AI tạo ra chạm vào nó. Chất lượng mã luôn quan trọng. Giờ đây nó được cộng gộp.

Nếu bạn cảm thấy một chút kháng cự với việc AI tạo ra mã, tôi hiểu. Nhưng hãy nghĩ về những gì bạn thực sự thích — đó là việc gõ mã, hay khoảnh khắc khi sự trừu tượng hóa đúng đắn khớp vào chỗ? AI lấy đi phần đầu tiên. Phần thứ hai sắp quan trọng hơn bao giờ hết. Và bạn không thể xây dựng sự trừu tượng hóa đúng đắn nếu bạn không hiểu vấn đề và người bạn đang giải quyết vấn đề cho đó.

Điều đó khiến việc hiểu khách hàng trở thành kỹ năng kỹ thuật cốt lõi. Vì vậy, các kỹ sư của chúng tôi hiện dành nhiều thời gian hơn cho những việc khác. Xem lại các phiên người dùng. Xem phỏng vấn khách hàng. Trò chuyện với người dùng nội bộ. Đọc các cuộc trò chuyện hỗ trợ. Các kỹ sư hiểu rõ về vấn đề sẽ lãng phí ít thời gian hơn để xây dựng sai thứ và đưa ra các quyết định độc lập, chất lượng cao hơn. Tốc độ triển khai trở thành hệ số nhân cho sự phán đoán âm thanh — và AI sắp làm cho các đội chỉ biết nhận lệnh trở nên lỗi thời trong khi làm cho các đội như chúng tôi mạnh mẽ hơn.