Ở hai phần trước, chúng ta đã tìm hiểu về AI Engineering Coach, cũng như cách Microsoft sử dụng Dashboard và Practice Score để phản ánh chất lượng cộng tác giữa Developer và AI.

Tuy nhiên, Dashboard chỉ là phần nổi của tảng băng.

Điều thực sự tạo nên giá trị của AI Engineering Coach lại nằm ở khả năng phát hiện các AI Engineering Anti-patterns – những thói quen làm việc tưởng chừng vô hại nhưng lại khiến AI Coding Assistant hoạt động kém hiệu quả.

Đây cũng là điểm khác biệt lớn giữa AI Engineering Coach và nhiều công cụ thống kê AI khác.

Thay vì chỉ ghi nhận bạn đã gửi bao nhiêu Prompt hay AI đã sinh bao nhiêu dòng mã, AI Engineering Coach cố gắng trả lời một câu hỏi quan trọng hơn:

Điều gì đang cản trở AI phát huy hết khả năng của mình?

Anti-pattern Là Gì?

Trong phát triển phần mềm, thuật ngữ Design Pattern được dùng để chỉ những giải pháp đã được kiểm chứng cho các bài toán phổ biến.

Ngược lại, Anti-pattern là những cách làm tưởng như hợp lý nhưng về lâu dài lại dẫn đến nhiều vấn đề.

Microsoft áp dụng khái niệm này vào AI Engineering.

Một AI Engineering Anti-pattern không phải là lỗi cú pháp, cũng không phải lỗi lập trình.

Đó là những thói quen làm việc với AI khiến chất lượng phản hồi giảm, thời gian xử lý kéo dài hoặc tạo ra nhiều công việc sửa chữa không cần thiết.

Ví dụ:

• Prompt quá mơ hồ.
• Context thiếu hoặc không nhất quán.
• Một phiên làm việc kéo dài quá lâu.
• Sao chép kết quả từ AI mà không kiểm tra.
• Liên tục lặp lại cùng một Prompt thay vì chuẩn hóa thành Skill.

Đây đều không phải lỗi của AI.

Chúng là những vấn đề trong quy trình cộng tác giữa con người và AI.

Microsoft Không Đếm Lỗi, Microsoft Quan Sát Hành Vi

Một điểm mình khá thích khi đọc tài liệu của AI Engineering Coach là Microsoft không xây dựng hệ thống theo hướng “bắt lỗi”.

Thay vào đó, công cụ quan sát hành vi.

Có thể hình dung quá trình này như sau:

Developer

↓

Prompt

↓

Context

↓

AI Response

↓

Developer Review

↓

Session

↓

AI Engineering Coach

↓

Behavior Analysis

↓

Anti-pattern Detection

Điều AI Engineering Coach quan tâm không phải là một Prompt duy nhất.

Nó quan sát toàn bộ phiên làm việc để tìm ra những mẫu hành vi lặp lại.

Chính vì vậy, Anti-pattern phản ánh thói quen chứ không chỉ là một sai sót đơn lẻ.

Nhóm 1 – Prompt Anti-patterns

Prompt là điểm bắt đầu của mọi cuộc hội thoại với AI.

Một Prompt càng rõ ràng thì AI càng có nhiều khả năng tạo ra kết quả chính xác.

Tuy nhiên, trong thực tế, nhiều lập trình viên thường sử dụng những Prompt quá ngắn hoặc quá chung chung.

Ví dụ:

Viết API quản lý người dùng.

Với Prompt này, AI không biết:

• Sử dụng ngôn ngữ lập trình nào?
• Framework gì?
• Kiến trúc dự án ra sao?
• Chuẩn coding nào cần tuân theo?
• Có cần Unit Test không?

Kết quả là AI phải tự suy đoán, dẫn đến phản hồi thiếu nhất quán.

💡 Best Practice

Một Prompt tốt thường cung cấp đầy đủ bối cảnh.

Ví dụ:

Viết REST API bằng ASP.NET Core 9.

Áp dụng Clean Architecture.

Database sử dụng PostgreSQL.

Authentication bằng JWT.

Sinh đầy đủ DTO, Repository và Unit Test.

AI càng hiểu rõ yêu cầu, chất lượng phản hồi càng cao.

Nhóm 2 – Context Anti-patterns

Nếu Prompt là câu hỏi thì Context chính là phần nền giúp AI hiểu dự án.

Đây cũng là một trong những chủ đề được Microsoft nhấn mạnh nhất.

Hãy tưởng tượng AI được yêu cầu sửa lỗi trong một dự án hoàn toàn mới.

Nếu không có bất kỳ tài liệu hướng dẫn nào, AI sẽ phải tự đoán:

• Convention đặt tên.
• Kiến trúc hệ thống.
• Coding Style.
• Quy tắc review.

Điều này làm tăng đáng kể khả năng tạo ra mã nguồn không phù hợp.

Một ví dụ điển hình là Repository không có các tệp hướng dẫn như:

• AGENTS.md
• copilot-instructions.md
• CLAUDE.md (nếu sử dụng Claude Code)

Khi thiếu những tài liệu này, AI gần như phải bắt đầu lại từ đầu ở mỗi phiên làm việc.

Đó cũng là lý do AI Engineering Coach có tính năng Context Health, chúng ta sẽ tìm hiểu chi tiết ở Phần 4.

Nhóm 3 – Session Anti-patterns

Một sai lầm khác khá phổ biến là cố gắng giải quyết quá nhiều vấn đề trong cùng một phiên làm việc.

Ví dụ:

1. Thiết kế Database.
2. Sinh API.
3. Viết Unit Test.
4. Review Code.
5. Tối ưu hiệu năng.
6. Sửa Bug.

Tất cả đều diễn ra trong một cuộc hội thoại kéo dài hàng trăm Prompt.

Ban đầu AI vẫn hoạt động tốt.

Nhưng càng về cuối, Context càng dài, khả năng ghi nhớ giảm và phản hồi bắt đầu thiếu ổn định.

Đây là lý do Microsoft khuyến khích chia công việc thành các phiên nhỏ với mục tiêu rõ ràng thay vì duy trì một cuộc hội thoại kéo dài nhiều giờ.

Nhóm 4 – Code Review Anti-patterns

AI có thể tạo ra mã nguồn rất nhanh.

Điều đó cũng khiến nhiều người vô tình hình thành một thói quen nguy hiểm:

Generate Code

↓

Copy

↓

Paste

↓

Commit

Nếu bỏ qua bước kiểm tra, những lỗi nhỏ như:

• Sai naming convention.
• Logic chưa tối ưu.
• Thiếu kiểm thử.
• Không tuân thủ kiến trúc.

sẽ dễ dàng lọt vào hệ thống.

AI Engineering Coach khuyến khích xem AI như một lập trình viên hỗ trợ, chứ không phải nguồn chân lý tuyệt đối.

Mọi đoạn mã do AI tạo ra vẫn cần được đánh giá như bất kỳ Pull Request nào khác.

Nhóm 5 – Tool Usage Anti-patterns

Ngày nay, AI Coding Assistant không chỉ biết sinh mã nguồn.

Chúng còn có thể:

• Đọc Repository.
• Chỉnh sửa nhiều tệp.
• Chạy lệnh.
• Phân tích lỗi.
• Tương tác với các công cụ hỗ trợ.

Tuy nhiên, nhiều lập trình viên vẫn làm việc theo cách cũ.

Ví dụ:

Tạo Model

↓

Tạo Controller

↓

Tạo DTO

↓

Tạo Repository

Mỗi bước lại gửi một Prompt riêng.

Trong khi đó, AI hoàn toàn có thể xử lý toàn bộ tác vụ trong một quy trình thống nhất nếu được cung cấp đầy đủ Context.

Việc chưa khai thác đúng khả năng của công cụ cũng được xem là một Anti-pattern trong AI Engineering.

Nhóm 6 – Repeated Workflow Anti-patterns

Một trong những ý tưởng mình đánh giá cao nhất của AI Engineering Coach là Skill Discovery.

Trong quá trình làm việc, nhiều Developer thường xuyên lặp lại cùng một quy trình.

Ví dụ:

• Tạo CRUD API.
• Review Pull Request.
• Sinh Unit Test.
• Phân tích Log.
• Viết tài liệu.

Ban đầu, điều này không có gì bất thường.

Nhưng nếu cùng một Prompt được lặp lại hàng chục lần, điều đó cho thấy quy trình này hoàn toàn có thể được chuẩn hóa.

Có thể hình dung như sau:

Prompt

↓

Lặp lại

↓

Lặp lại

↓

Lặp lại

↓

Skill Discovery

↓

Reusable Skill

Thay vì để từng cá nhân tự viết lại Prompt mỗi ngày, tổ chức có thể đóng gói chúng thành các Skill dùng chung.

Đây là bước chuyển từ Prompt Engineering sang Knowledge Engineering.

Anti-pattern Không Có Nghĩa Là Bạn Đang Làm Sai

Một điều rất đáng chú ý là AI Engineering Coach không dùng Anti-pattern để đánh giá lập trình viên.

Việc phát hiện một Anti-pattern không đồng nghĩa với việc bạn là một AI Engineer kém.

Nó chỉ cho thấy còn tồn tại những điểm có thể cải thiện.

Điều này cũng tương tự như Static Analysis.

Việc xuất hiện một cảnh báo không có nghĩa hệ thống thất bại, mà là cơ hội để nâng cao chất lượng.

Đó cũng là lý do Microsoft lựa chọn tên gọi Coach thay vì Auditor hay Analyzer.

Mục tiêu của công cụ là hỗ trợ học tập và cải thiện liên tục, không phải chấm điểm hay phê bình người dùng.

Continuous Improvement – Triết Lý Đằng Sau AI Engineering Coach

Nếu quan sát kỹ, có thể thấy toàn bộ AI Engineering Coach được xây dựng dựa trên một vòng lặp rất quen thuộc trong phát triển phần mềm:

Observe

↓

Measure

↓

Detect

↓

Improve

↓

Observe

Dashboard giúp quan sát.

Practice Score giúp đo lường.

Anti-pattern giúp phát hiện vấn đề.

Skill Finder và Context Health giúp cải thiện quy trình.

Sau đó chu trình lại bắt đầu từ đầu.

Đây chính là tư duy Continuous Improvement được Microsoft đưa vào AI Engineering.

Thay vì kỳ vọng AI sẽ thay thế lập trình viên, AI Engineering Coach giúp lập trình viên từng bước xây dựng những thói quen làm việc hiệu quả hơn với AI.

Kết Luận

Khi nhắc đến AI Coding Assistant, nhiều người thường quan tâm đến khả năng sinh mã nguồn hay tốc độ phản hồi của mô hình. Tuy nhiên, AI Engineering Coach lại đặt trọng tâm vào một khía cạnh khác: hành vi của con người khi cộng tác với AI.

Các AI Engineering Anti-pattern không phải là danh sách những lỗi cần tránh bằng mọi giá, mà là những tín hiệu giúp chúng ta nhận ra các thói quen chưa tối ưu trong quá trình làm việc. Từ Prompt, Context, Session cho đến cách sử dụng công cụ và chuẩn hóa quy trình, tất cả đều ảnh hưởng trực tiếp đến chất lượng của AI.

Trong Phần 4, chúng ta sẽ tìm hiểu sâu hơn về Context Health và Skill Discovery – hai tính năng thể hiện rõ nhất triết lý “AI không chỉ cần Prompt tốt, AI còn cần một môi trường làm việc tốt”. Đây cũng là bước chuyển quan trọng từ việc sử dụng AI như một công cụ sang xây dựng một quy trình Agentic Engineering bài bản cho cá nhân và doanh nghiệp.