Giải quyết các anti-pattern trong phát triển phần mềm định hướng AI

Vào mùa thu hàng năm, AWS Việt Nam tổ chức sự kiện Cloud day tại Hà Nội. Lần trước mình đã đăng ký nhưng không tham dự được vì sự cố bất ngờ, nên năm nay mình rất vui khi được tham gia. Trong sự kiện, mình đã được tham dự nhiều phiên trao đổi khác nhau và đây là phiên trao đổi mình cảm thấy giá trị nhất. Xin phép được chia sẻ với mọi người một số nội dung mình biết được trong phiên “Giải quyết các anti-pattern trong phát triển phần mềm định hướng AI” của anh Toàn Huỳnh, một kiến trúc sư lâu năm tại AWS.

Với sự phát triển rất nhanh của AI thì các kiến thức này có thể không còn đúng vào thời điểm của người đọc. Nhưng mình mong rằng, dù ít hay nhiều, nó sẽ đưa lại thêm cho bạn thông tin để có thể phát triển phần mềm với AI tốt hơn.

Phát triển phần mềm định hướng AI là gì?  Đó là cách làm phần mềm mà AI tham gia như một thành viên chính trong toàn bộ vòng đời phát triển, không chỉ là công cụ gợi ý code thông thường.

1. Tránh vibe coding

Vibe coding chính là ra lệnh cho AI viết code, sau đó chấp nhận luôn mà không đọc lại và không hiểu về nó.

Với các phần mềm cá nhân, làm cho vui hoặc POC thì hoàn toàn có thể dùng Vibe coding để thực hiện.
Nhưng với các phần mềm doanh nghiệp, nơi yêu cầu về chất lượng và bảo mật luôn là ưu tiên cao nhất, điều này hiện tại vẫn chưa thể chấp nhận được.

Vậy làm thế nào để biết mình có đang vibe coding hay không? Hãy dùng các câu hỏi sau:

• Bạn có thể debug từng dòng code không? Hay, nếu có lỗi trên môi trường production và không có AI thì bạn có thể sửa được không?
• Bạn có hiểu code của bạn từ đầu đến cuối không? Bạn có nắm rõ các luồng xử lý, kiến trúc, phụ thuộc, các nợ kỹ thuật hay bug ẩn nằm trong code không?

(Nếu bạn trả lời “không” cho một trong hai câu hỏi thì bạn vẫn đang vibe coding đấy.)

2. Yêu cầu AI làm những task nhỏ và đơn giản

Khi đưa cho AI các yêu cầu phức tạp, chúng thường khó có thể thành công. Kết quả của AI lúc đó có thể đúng hoặc sai và chắc chắn sẽ rất khó để kiểm soát. Task càng lớn, AI càng dễ đoán mò, cho ra kết quả trông rất hợp lý nhưng thực tế lại không chạy được..

Thay vào đó, cần chia các công việc thành các việc nhỏ hơn mà AI chắc chắn hoàn thành  được  và bạn cũng dễ kiểm soát hơn.

Ví dụ:

• Thay: Dựng toàn bộ hạ tầng cho dự án X với 1 web server, 1 database nhé.
• Bằng:
  • Đầu tiên, hãy dựng VPC cho mình tại region tokyo, vpc có 2 subnet public và 2 subnet private. Việc truy cập từ private network sẽ qua 1 Nat-gateway đặt tại public subnet. Trong VPC cấu hình VPC Endpoint với S3 để tối ưu băng thông truy cập
  • Thiết lập Web service với load balance, ec2,…
  • Thiết lập RDS chạy mysql 8.4….

Hoặc đơn giản hơn: Hãy bắt đầu việc phát triển bằng bước plan với các công cụ như Superpowers, trong đó phân tách ra thành các task nhỏ. Bạn review và xác nhận bản plan, sau đó giao cho AI phát triển từng task đấy.

3. Kiểm soát context windows ( cửa sổ ngữ cảnh) cẩn thận

Cửa sổ ngữ cảnh là toàn bộ những gì AI nhìn thấy trong một phiên: Lịch sử chat, file đã đọc, output của lệnh…

Dung lượng dường như không phải là vấn đề với các model hiện đại khi nó có thể chứa đến 1 triệu token. Nhưng điều quan trọng là: Càng nhiều thông tin thì AI càng dễ nhầm lẫn, quên chỉ dẫn và đưa ra output kém chất lượng.

Ví dụ:

• Lần gọi 1: gửi system prompt + câu hỏi 1
• Lần gọi 2: gửi system prompt + câu hỏi 1 + trả lời 1 + câu hỏi 2
• Lần gọi 3: gửi tất cả những thứ trên + trả lời 2 + câu hỏi 3

… cứ thế context windows được tích lũy dần trong quá trình phát triển. Thông tin càng dần trở nên nhiễu loạn.

2 câu hỏi để giúp bạn xác nhận bạn có quản lý đúng không?

• (1). Có bao nhiêu thông tin không liên quan mà bạn có trong context?
• (2). Lần cuối bạn reset hoặc nén nó là khi nào?

4. Đưa cho AI code mẫu có sẵn và yêu cầu nó làm theo, thay vì viết 1 đống chỉ dẫn dài dòng và phức tạp

Lợi ích của điều này: 

• AI rất dễ hiểu sai các chỉ dẫn phức tạp nhưng rất giỏi bắt chước. Do đó, output sẽ tốt hơn
• Code mới đồng nhất với codebase hiện tại.

Ví dụ:

• Thay: Viết API lấy danh sách đơn hàng. Dùng async/await, trả về JSON có field data và error, validate input bằng schema, log lỗi theo format X, đặt tên theo camelCase, xử lý pagination với limit/offset…
• Bằng: Viết API GET /orders giống hệt cách viết GET /users trong file users.controller.ts

5. Viết test đầy đủ để AI tự kiểm tra được kết quả công việc của chính nó

• Thay vì: AI viết code rồi tự “đoán” là đúng và bạn phải kiểm tra thủ công.
• Thì: AI viết code, chạy test, thấy lỗi, tự sửa, chạy lặp lại cho đến khi pass. 

Test lúc này sẽ trở thành tiêu chuẩn đúng/sai khách quan mà AI dựa vào để tự sửa.
Tuy nhiên, hãy cẩn thận vì AI có thể sửa test để cho pass thay vì sửa code. Do đó, bạn nên viết hoặc duyệt test trước, sau đó mới để AI viết code.

6. Dùng đủ nhiều để biết giới hạn của model nằm ở đâu và cẩn thận với kiến thức cũ của model

Đã bao giờ bạn tự hỏi: Với Claude, lúc nào thì dùng model Opus 5.5, lúc nào Fable 5.1?

Cái tốn tiền hơn chắc là cái tốt hơn → Cứ Fable 5.1 mà xài. 

Điều này không đúng, với hầu hết các tác vụ, Opus 5.5 mang lại kết quả tốt hơn, nhanh hơn và chi phí phải chăng hơn Fable 5.1.

Ngoài ra, hãy cẩn thận với dữ liệu bị lỗi thời (Outdated) nhé. 

Ví dụ: Hãy viết Github Action config cho mình sử dụng Action Checkout để clone code nhé. 

→ Claude sẽ đưa bạn phiên bản checkout của 6 tháng đến 1 năm trước. 

Để khắc phục: Thêm vào prompt: “sử dụng phiên bản mới nhất của nhà phát hành nhé”. 

7. Cần bảo vệ các khoảng thời gian liên tục cho đội phát triển

Có AI thì việc phát triển sẽ nhàn hơn? Không, bạn sẽ thấy căng thẳng hơn rất nhiều đấy.
Thay vì phải viết code, bạn sẽ phải review lại output từ AI. Điều này có nghĩa là bạn sẽ cần nhiều khoảng thời gian tập trung hơn để đọc, phân tích, đánh giá thông tin và ra quyết định. Cách tốt nhất: dọn dẹp và tối ưu lại lịch họp của bạn và nhóm của bạn.

Hãy tự mình trả lời 2 câu hỏi:

• Bạn có cần tất cả các cuộc họp ở trên lịch không?
  • Nhiều cuộc họp có thể thay bằng tin nhắn, tài liệu hoặc cập nhật bất đồng bộ
  • Hoặc thậm chí, người tiếp nhận có thể tự có được thông tin qua việc dùng AI truy xuất thông tin trong các công cụ trao đổi và phát triển (Slack, Confluence, Google Doc,…)
• Có thể đặt quy tắc chung cho cả team để dọn lịch không? Một số ví dụ về quy tắc như:
  • Ngày không họp. Ví dụ: thứ 3 hàng tuần.
  • Khung giờ tập trung để phát triển. Ví dụ: 9h-12h sáng.
  • Gom họp vào 1 buổi thay vì rải rác cả ngày.
  • Cập nhật tiến độ bằng văn bản thay vì mất từ 1 đến 2 cuộc daily meeting

8. Cẩn thận khi dùng AI trên codebase có sẵn (chẳng hạn dự án bảo trì hoặc dự án đang vận hành)

Đầu tiên: Đừng đưa cả codebase lớn làm input. Điều này sẽ làm tràn context windows khiến AI bị nhiễu, bỏ sót chi tiết, hiểu sai cấu trúc và đưa ra output kém chất lượng.

Thay vì đó, hãy dựng context trước. Bạn nên dùng AI để làm việc này, và đừng tiếc token, hãy dùng mức effort cao như xhigh hay max cho việc này”. Ví dụ: hãy tạo các tài liệu tóm tắt cho repo:

• Tổng quan kiến trúc
• Tóm tắt từng module
• Bản đồ phụ thuộc giữa các phần
• Quy ước code, các luồng nghiệp vụ.

Với các codebase rất lớn như monorepo chẳng hạn, hãy dùng kỹ thuật phân rã:

• Chia theo domain hoặc module, mỗi lần AI chỉ làm việc trong 1 vùng. 
• Tóm tắt phân cấp: file, module, toàn hệ thống
• Giao việc cho các sub agent hoặc agent team để thực thi.

9. Đo hiệu quả AI bằng kết quả đầu ra và mức tăng năng suất thực tế, không đo bằng số dòng code

Khi AI có thể tạo code rất nhanh thì nhiều code hơn không có nghĩa là tốt hơn, mà thậm chí có thể đồng nghĩa với nhiều nợ kỹ thuật hơn. Các chỉ số truyền thống như số dòng code không còn nhiều ý nghĩa. Các chỉ số khác như số commit, số PR cũng vậy. 

Nên so sánh để thay thay đổi năng suất thực tế:

• Đo toàn bộ quy trình, không chỉ phần viết code.
• Cách làm: So sánh trước và sau khi áp dụng AI hoặc so sánh giữa các team khác nhau.
• Ví dụ, các chỉ số nên đo bằng bộ DORA:
  • Lead time: từ lúc có yêu cầu đến khi lên production.
  • Tần suất deploy
  • Tỷ lệ thay đổi gây lỗi 
  • Thời gian khôi phục khi có sự cố.

Và cuối cùng là: thực hành và dùng AI càng nhiều càng tốt

Không có con đường tắt nào cả. Làm việc với AI đòi hỏi phải đầu tư công sức, thời gian của bạn và tiền AI của công ty ^^. Những kỹ năng như chia nhỏ task, quản lý context, viết prompt gọn, biết khi nào AI sai chỉ có được qua trải nghiệm thực tế.

 Chúc các bạn cộng tác tốt với đồng chí AI nhé.

😀