Kỹ thuật phần mềm

Đội ngũ nhỏ, phần mềm lớn: điều gì thực sự thay đổi khi có AI?

Khi việc viết code không còn là nút thắt duy nhất, một đội ngũ nhỏ có thể đi xa đến đâu? Và phần việc nào vẫn cần con người chịu trách nhiệm?

Trong bài viết này

Một ý chính

AI có thể giúp một đội ngũ nhỏ làm được nhiều hơn. Nhưng quy mô của sản phẩm vẫn được quyết định bởi kiến trúc, khả năng kiểm chứng và cách đội ngũ chịu trách nhiệm với người dùng.

Có một câu hỏi mình nghĩ nhiều trong thời gian này: nếu một nhóm ít người có thể làm ra lượng phần mềm từng cần cả một phòng kỹ thuật, điều gì sẽ trở nên quan trọng nhất?

Có lẽ không còn là tốc độ gõ. Cũng không chỉ là khả năng thuộc một framework. Mình nghĩ đó là năng lực hiểu vấn đề, chia nhỏ sự phức tạp và biết khi nào một kết quả nhìn có vẻ đúng thực ra chưa đủ tốt.

Khi chi phí thử một ý tưởng thấp hơn

Hãy hình dung một nhóm đang xây hệ thống tiếp nhận đơn hàng. Trước đây, chỉ riêng việc dựng giao diện quản trị, kết nối dữ liệu, viết kiểm thử và tài liệu đã chiếm rất nhiều công sức. Với công cụ AI phù hợp, một phần việc ấy có thể được tạo nháp, sửa và lặp lại nhanh hơn.

Đây là một tình huống minh họa, không phải lời hứa rằng mọi đội ngũ đều sẽ tăng năng suất theo cùng một tỉ lệ. Giá trị hấp dẫn nhất, theo mình, là nhóm có thể thử sớm hơn: đưa một luồng nhỏ đến tay người dùng, nhận phản hồi rồi quyết định có nên đầu tư tiếp.

Khi chi phí thử giảm, một doanh nghiệp nhỏ có thêm cơ hội xây công cụ vừa với cách mình làm việc, thay vì luôn phải uốn quy trình để vừa với phần mềm có sẵn.

Viết được nhiều code chưa chắc đã giao được sản phẩm tốt

Trong báo cáo năm 2025, DORA mô tả AI như một yếu tố khuếch đại: những điểm mạnh và điểm yếu sẵn có của tổ chức đều có thể trở nên rõ hơn.1 Mình thấy đây là một cách nhìn hữu ích hơn câu chuyện “cứ dùng AI là nhanh”.

Nếu yêu cầu còn mơ hồ, AI có thể giúp ta hiện thực hóa rất nhanh một điều chưa ai thực sự cần. Nếu kiểm thử yếu, một thay đổi nhỏ có thể kéo theo nhiều lỗi mà không ai nhận ra. Nếu mọi quyết định kiến trúc đều bị bỏ qua để kịp demo, tốc độ hôm nay có thể trở thành chi phí ngày mai.

Phần mềm lớn không chỉ là nhiều dòng code. Nó còn là dữ liệu tồn tại qua nhiều năm, người dùng với những quyền khác nhau, những lần triển khai không được phép làm gián đoạn công việc và những tình huống không có trong bản demo.

Đội ngũ nhỏ cần những ranh giới rõ

Mình sẽ bắt đầu từ một kiến trúc đủ đơn giản để cả nhóm hiểu được. Không nhất thiết phải là một hệ thống nhiều dịch vụ. Một ứng dụng được chia module rõ ràng, có hợp đồng dữ liệu ổn định và kiểm thử tốt thường là điểm xuất phát dễ kiểm soát hơn.

Sau đó, phân biệt những việc AI được tự làm và những việc cần người duyệt. Tạo nháp một bài kiểm thử khác với chạy một lệnh thay đổi dữ liệu thật. Đề xuất sửa code khác với tự quyết định đưa code lên môi trường sản xuất.

Một nhịp làm việc mình muốn hướng tới là: viết tiêu chí chấp nhận trước, giao từng thay đổi nhỏ, yêu cầu bằng chứng kiểm thử, rồi để một người hiểu hệ thống xem lại. Không dùng số dòng code được tạo ra làm thước đo thành công.

Năng suất phải được đo ở cuối quy trình

Một tính năng có thể chỉ mất một giờ để tạo nháp nhưng mất nhiều ngày để làm rõ yêu cầu, sửa lỗi và triển khai an toàn. Vì vậy, mình muốn theo dõi thời gian từ lúc có nhu cầu đến lúc người dùng sử dụng được, số lỗi lọt ra ngoài và chi phí vận hành sau khi ra mắt.

Với một quy trình có AI Agent, còn cần biết số trường hợp phải chuyển cho con người, chi phí mỗi tác vụ hoàn tất và khả năng phục hồi khi công cụ bên ngoài lỗi. Đây là những chỉ số đề xuất cho việc thử nghiệm, không phải một bộ tiêu chuẩn phù hợp với mọi doanh nghiệp.

Điểm khởi đầu cũng không nhất thiết là một agent hoàn toàn tự chủ. Anthropic phân biệt luồng được định nghĩa sẵn với agent tự quyết định các bước, đồng thời khuyến nghị bắt đầu bằng giải pháp đơn giản nhất đáp ứng nhu cầu.2

Ít người hơn không có nghĩa là ít trách nhiệm hơn

Điều khiến mình hào hứng không phải viễn cảnh xóa sạch đội kỹ thuật. Đó là khả năng một nhóm nhỏ có thể dành nhiều thời gian hơn cho vấn đề đáng giải quyết, thay vì mắc kẹt trong những thao tác lặp lại.

Nhưng khi mỗi người có thể tạo ra nhiều thay đổi hơn, khả năng đọc hiểu, phản biện và kiểm chứng cũng phải lớn lên tương ứng. Người chịu trách nhiệm cho sản phẩm không thể là một cửa sổ chat.

Mình tin cơ hội mới nằm ở đây: đội ngũ có thể gọn hơn, nhưng tư duy về hệ thống phải sâu hơn. Và đích đến vẫn rất cũ, theo một nghĩa tốt: làm ra thứ thật sự có ích cho người dùng.

Câu hỏi thường gặp

AI giúp đội ngũ phần mềm nhỏ làm được gì?

AI có thể hỗ trợ tạo nháp giao diện, kiểm thử và tài liệu để đội ngũ thử ý tưởng sớm hơn. Khả năng giao sản phẩm tốt vẫn phụ thuộc vào kiến trúc, yêu cầu rõ ràng, kiểm chứng và người chịu trách nhiệm.

Nên đo năng suất khi dùng AI bằng gì?

Theo dõi thời gian từ nhu cầu đến khi người dùng sử dụng được, số lỗi lọt ra ngoài và chi phí vận hành. Với AI Agent, cần xem thêm chi phí mỗi tác vụ hoàn tất, số lần phải chuyển cho con người và khả năng phục hồi khi công cụ lỗi.

Đọc thêm & nguồn tham khảo

  1. DORA — State of AI-assisted Software Development 2025 ↗
  2. Anthropic — Building effective agents ↗

Các tình huống minh họa trong bài không phải báo cáo về một dự án cụ thể. Những đề xuất triển khai là góc nhìn của người viết, cần được kiểm chứng trong bối cảnh thực tế.

Cảm ơn bạn đã đọc đến đây.

Khám phá thêm một góc nhìn

Một câu hỏi hay là một khởi đầu tốt.

5 bài viết để bắt đầu khám phá ↑ ↓ chọn · Enter đọc · Esc đóng

Chia sẻ bài viết

Trình duyệt chưa cho phép sao chép tự động. Bạn có thể sao chép đường dẫn bên dưới.