Ở ba phần trước, chúng ta đã lần lượt tìm hiểu:

• AI Engineering Coach là gì?
• Microsoft đo lường cách Developer làm việc với AI như thế nào?
• Những AI Engineering Anti-pattern nào có thể làm giảm hiệu quả khi sử dụng AI?

Nếu nhìn lại toàn bộ hành trình, chúng ta đã đi qua ba bước:

Understand
    ↓
Measure
    ↓
Detect

Nhưng sau khi phát hiện vấn đề thì sao?

Nếu AI Engineering Coach phát hiện Prompt chưa tốt, Session quá dài hoặc Developer đang bỏ qua một số Best Practice, bước tiếp theo chắc chắn phải là:

Cải thiện như thế nào?

Đây chính là nơi Context Health và Skill Finder xuất hiện.

Và theo mình, đây cũng là phần thú vị nhất của AI Engineering Coach.

Bởi vì Microsoft không còn chỉ nói về việc:

“Làm thế nào để AI viết code tốt hơn?”

Mà bắt đầu đặt một câu hỏi lớn hơn:

“Chúng ta cần xây dựng môi trường như thế nào để AI có thể làm việc tốt hơn?”

AI Không Chỉ Cần Prompt

Khi mới bắt đầu sử dụng AI Coding Assistant, chúng ta thường tập trung gần như hoàn toàn vào Prompt.

Ví dụ:

Viết REST API quản lý User

Nếu kết quả không tốt, chúng ta sửa Prompt:

Viết REST API quản lý User bằng ASP.NET Core.
Sử dụng Clean Architecture.
Có DTO, Repository và Unit Test.

Kết quả tốt hơn.

Và chúng ta bắt đầu nghĩ:

Prompt càng chi tiết thì AI càng thông minh.

Nhưng trong một project thực tế, Prompt chỉ là một phần rất nhỏ của Context.

AI còn cần biết:

• Project đang sử dụng kiến trúc nào?
• Coding Convention của team là gì?
• Những file nào chứa instruction?
• Có Skill nào đã được chuẩn hóa?
• Có Custom Agent nào không?
• Có Tool hoặc MCP nào có thể sử dụng?
• Cách build và test project như thế nào?
• Những instruction hiện tại còn chính xác hay đã lỗi thời?

Lúc này, bài toán đã thay đổi.

Không còn đơn giản là:

Prompt Engineering

mà trở thành:

Context Engineering

Context Health Là Gì?

Trong AI Engineering Coach, Context Health được xây dựng để đánh giá chất lượng Context của Workspace cũng như cách Context được sử dụng trong các phiên làm việc. Repo mô tả tính năng này thông qua overall context score, agentic readiness checklist, workspace context map và AI-powered instruction-file review.

Có thể hình dung:

                    Workspace
                        │
                        ▼
                  Context Health
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
       Context Quality       Context Usage
             │                     │
             ▼                     ▼
       Agentic Readiness      Session Health

Điều này rất quan trọng.

Bởi vì một project có rất nhiều Context không đồng nghĩa với việc project đó có Context tốt.

Context phải:

• Đúng.
• Đủ.
• Có cấu trúc.
• Có thể tái sử dụng.
• Và quan trọng nhất: còn phù hợp với project hiện tại.

Context Quality – Workspace Đã Sẵn Sàng Cho AI Chưa?

Một trong những câu hỏi quan trọng nhất của Context Health là:

Workspace của bạn đã sẵn sàng để AI Agent làm việc chưa?

AI Engineering Coach kiểm tra nhiều tín hiệu liên quan đến Agentic Readiness, chẳng hạn như instruction files, Skills, Agents, Prompt Templates, Hooks, Dev Container và MCP Servers. Repo cũng kiểm tra tính cập nhật của Context thông qua Context Freshness.

Có thể hình dung Workspace như một nhân viên mới vào công ty.

Bạn không thể chỉ nói:

“Đây là task, làm đi.”

Bạn cần cung cấp:

Company Rules
      ↓
Team Convention
      ↓
Project Architecture
      ↓
Tools
      ↓
Workflow
      ↓
Task

AI Agent cũng vậy.

Instruction Files – Đừng Bắt AI Học Lại Project Mỗi Lần

Một trong những thành phần quan trọng nhất của Context là instruction files.

Ví dụ, Repository của chính AI Engineering Coach cũng sử dụng AGENTS.md để mô tả các quy tắc làm việc của project. File này chứa những thông tin như cách build, test, lint, các quy tắc về Skills và những giới hạn mà Agent phải tuân thủ.

Điều này cho thấy một nguyên tắc rất quan trọng:

Những quy tắc ổn định của project nên được viết thành Context thay vì nhắc lại trong từng Prompt.

Ví dụ thay vì liên tục nói:

Hãy chạy test trước khi hoàn thành.

Hãy sử dụng npm ci.

Không được sửa file generated.

Không được thêm telemetry.

Hãy giữ parser trong worker.

chúng ta có thể đưa những quy tắc ổn định đó vào instruction file.

Khi đó:

Developer
    │
    ▼
Task
    │
    ▼
AI Agent
    │
    ├── Task
    └── Project Instructions

AI có một nền tảng rõ ràng hơn để thực hiện nhiệm vụ.

Context Freshness – Context Cũ Có Thể Nguy Hiểm Hơn Context Thiếu

Đây là một vấn đề rất đáng chú ý.

Giả sử project ban đầu sử dụng:

Repository Pattern

Instruction file cũng ghi:

Always use Repository Pattern.

Sau một thời gian, team chuyển sang:

CQRS + MediatR

nhưng instruction file không được cập nhật.

Khi Developer yêu cầu AI tạo một Feature mới, AI vẫn có thể làm theo instruction cũ.

Vấn đề lúc này không nằm ở AI Model.

Prompt cũng không nhất thiết sai.

Context đã lỗi thời.

Đó là lý do Context Health không chỉ quan tâm việc:

Có instruction file hay không?

mà còn quan tâm đến chất lượng và độ mới của Context. Repo hiện cũng có AI-powered review cho context files.

Một instruction file sai có thể khiến AI làm việc rất “đúng”…

nhưng đúng theo một phiên bản cũ của project.

Workspace Context Map

Một thành phần trực quan khác của Context Health là Workspace Context Map.

Repo mô tả đây là một workspace context map dưới dạng treemap, với màu sắc thể hiện chất lượng instruction.

Điều này giúp chuyển một vấn đề vốn khá trừu tượng thành thứ có thể quan sát được.

Ví dụ:

Workspace A
████████████████████

Workspace B
██████████

Workspace C
████

Nếu một Workspace có lượng AI activity rất lớn nhưng Context Quality thấp, đây có thể là nơi nên được ưu tiên cải thiện.

Thay vì Engineering Manager phải hỏi từng Developer:

“Project của em đã có Context cho AI chưa?”

Dashboard có thể cung cấp một góc nhìn tổng quan hơn.

Context Không Phải Càng Nhiều Càng Tốt

Có một hiểu lầm rất phổ biến:

Nếu Context giúp AI hiểu project thì càng nhiều Context càng tốt.

Không hẳn.

Hãy tưởng tượng bạn đưa cho một Developer mới vào team:

500 trang tài liệu
+
200 file instruction
+
100 quy tắc
+
50 workflow

và nói:

“Đọc hết rồi làm task này.”

Nhiều thông tin hơn không nhất thiết khiến Developer làm việc tốt hơn.

AI cũng vậy.

Mục tiêu không phải:

Maximum Context

mà là:

Useful Context

Context tốt phải cung cấp đúng thông tin mà Agent cần, vào đúng thời điểm.

Context Management – Khi Context Quá Dài Cũng Trở Thành Vấn Đề

Context Health không chỉ quan tâm Workspace có những Context gì.

Nó còn nhìn vào cách Context được sử dụng trong Session.

Một phiên làm việc có thể bắt đầu rất đơn giản:

Fix login bug

Sau đó:

Fix login bug
      ↓
Refactor authentication
      ↓
Add JWT
      ↓
Write tests
      ↓
Fix failing tests
      ↓
Optimize database
      ↓
Update documentation

Một Session ban đầu dành cho một Bug Fix cuối cùng trở thành cả một project.

Khi Context ngày càng lớn, AI có thể phải xử lý lượng thông tin ngày càng nhiều.

Điều đó dẫn tới một Best Practice rất đơn giản:

Một Session nên có mục tiêu tương đối rõ ràng.

Compaction – Dấu Hiệu Session Đã Quá Dài?

Khi Context tiến gần giới hạn, một số AI Coding Assistant có thể phải thực hiện compaction để tiếp tục cuộc hội thoại.

Nếu điều này xảy ra liên tục, đó có thể là tín hiệu Session đang quá dài hoặc workflow đang cần được chia nhỏ.

Ví dụ:

Prompt
  ↓
Context tăng
  ↓
Context tăng
  ↓
Context tăng
  ↓
Compaction
  ↓
Tiếp tục
  ↓
Compaction
  ↓
Tiếp tục

Thay vì cố gắng giữ mọi thứ trong một Session duy nhất, có thể chia thành:

Session 1
Analyze

↓

Session 2
Implement

↓

Session 3
Test

↓

Session 4
Review

Đây không phải là việc “giảm khả năng của AI”.

Ngược lại, nó có thể giúp mỗi Session có Context rõ ràng và tập trung hơn.

Skill Finder – Khi Prompt Lặp Lại Trở Thành Một Skill

Nếu Context Health giúp trả lời:

AI có môi trường tốt để làm việc chưa?

thì Skill Finder đặt một câu hỏi khác:

Có công việc nào chúng ta đang làm lặp đi lặp lại và có thể chuẩn hóa không?

Đây là một trong những tính năng mình đánh giá cao nhất trong AI Engineering Coach.

Repo mô tả Skill Finder là công cụ phân tích các Prompt lặp lại để phát hiện cơ hội tạo Custom Skill, đồng thời tìm các Skill và Agent phù hợp từ Open Source catalog.

Từ Prompt Lặp Lại Đến Reusable Skill

Hãy tưởng tượng Developer thường xuyên yêu cầu:

Generate unit tests for this service.

Một lần.

Không có gì đặc biệt.

Mười lần.

Có thể chỉ là công việc thường ngày.

Nhưng nếu Prompt tương tự xuất hiện liên tục:

Session 1 → Generate tests
Session 2 → Generate tests
Session 3 → Generate tests
Session 4 → Generate tests
Session 5 → Generate tests

thì có một câu hỏi rất đáng đặt ra:

Tại sao chúng ta vẫn phải mô tả lại quy trình này?

Có thể biến nó thành:

Unit Test Skill
        │
        ├── Framework
        ├── Naming Convention
        ├── Coverage Rules
        └── Expected Output

Sau đó:

Developer
    ↓
Task
    ↓
Skill
    ↓
AI Agent

AI không cần được hướng dẫn lại từ đầu mỗi lần.

Skill Không Chỉ Là Một Prompt Dài

Đây là một điểm mình nghĩ rất đáng phân biệt.

Skill không đơn giản là:

Prompt dài 500 dòng

Skill nên đại diện cho một khả năng hoặc workflow có thể tái sử dụng.

Ví dụ:

Code Review Skill

có thể chứa:

1. Analyze changed files
2. Check coding conventions
3. Check security issues
4. Check tests
5. Report findings

Lúc này Skill trở thành một phần của Engineering Workflow.

Nó không còn là Prompt cá nhân nữa.

Skill Finder Và Community Skills

Skill Finder còn có một hướng tiếp cận thú vị khác.

Không phải lúc nào Developer cũng cần tự tạo Skill.

AI Engineering Coach có thể tìm những Skill hoặc Agent phù hợp từ Open Source catalog dựa trên các pattern đã phát hiện trong lịch sử sử dụng AI.

Có thể hình dung:

Your Prompt History
        ↓
Pattern Detection
        ↓
"Bạn thường làm việc này"
        ↓
┌───────────────────────┐
│ Custom Skill          │
│ Community Skill       │
│ Community Agent       │
└───────────────────────┘

Điều này biến AI Engineering Coach từ một công cụ phân tích thành một công cụ gợi ý cải tiến.

Từ Prompt Engineering Đến Context Engineering

Đây có lẽ là điểm quan trọng nhất của Phần 4.

Trong giai đoạn đầu của AI Coding, chúng ta thường tập trung vào:

Prompt Engineering

Câu hỏi là:

“Viết Prompt thế nào để AI trả lời tốt?”

Nhưng khi AI Agent trở nên mạnh hơn, câu hỏi bắt đầu thay đổi:

Project cần cung cấp Context gì?

Instruction nào nên được chuẩn hóa?

Skill nào nên được tạo?

Agent nào phù hợp?

Tool nào cần kết nối?

Context nào cần cập nhật?

Lúc này chúng ta bước sang:

Context Engineering

Và xa hơn nữa:

Agentic Engineering

Có thể hình dung:

Prompt Engineering
        ↓
Context Engineering
        ↓
Agentic Engineering

AI Engineering Coach đang nằm chính giữa quá trình chuyển đổi này.

Từ Cá Nhân Đến Team

Một Prompt tốt thường mang lại lợi ích cho một Developer.

Nhưng một Skill tốt có thể mang lại lợi ích cho cả Team.

Đó là một sự thay đổi rất quan trọng.

Developer
    │
    ▼
Good Prompt
    │
    ▼
Repeated Workflow
    │
    ▼
Reusable Skill
    │
    ▼
Team Knowledge
    │
    ▼
Engineering Standard

Nếu một Developer tìm ra cách tốt hơn để sử dụng AI, mục tiêu cuối cùng không nên là:

“Đây là mẹo của tôi.”

Mà nên là:

“Đây là một workflow mà team có thể tái sử dụng.”

Đây chính là cách AI Engineering bắt đầu mở rộng từ Individual Productivity sang Team Productivity.

Và Đây Là Lúc AI Engineering Coach Hoàn Thành Vòng Lặp

Nếu ghép cả bốn phần của series lại, chúng ta sẽ có một vòng lặp hoàn chỉnh.

Bước 1 – Observe

AI Engineering Coach quan sát hoạt động của AI Coding Assistant.

Sessions
Requests
Workspaces
Harnesses

Bước 2 – Measure

Dashboard đo lường:

Practice Score
Activity
Output
Patterns

Bước 3 – Detect

Anti-Patterns phát hiện những hành vi chưa tối ưu.

Prompt Quality
Session Hygiene
Code Review
Tool Mastery
Context Management

Bước 4 – Improve

Context Health và Skill Finder đưa ra hướng cải thiện.

Better Context
Better Skills
Better Workflow

Toàn bộ vòng lặp trở thành:

        ┌──────────────┐
        │   OBSERVE    │
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │   MEASURE    │
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │    DETECT    │
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │   IMPROVE    │
        └──────┬───────┘
               │
               └──────────────► OBSERVE

Và đó chính là điều khiến AI Engineering Coach thú vị hơn một Dashboard thông thường.

AI Engineering Không Chỉ Là “Dùng AI Để Code”

Sau khi đi qua cả bốn phần, có lẽ chúng ta có thể nhìn lại câu hỏi ban đầu.

AI Engineering là gì?

Nó không đơn giản là:

Developer
    ↓
ChatGPT / Copilot / Claude
    ↓
Code

Một quy trình trưởng thành hơn sẽ giống:

                 Developer
                     │
                     ▼
               AI Engineering
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
     Context       Skills       Agents
        │            │            │
        └────────────┼────────────┘
                     ▼
                AI Workflow
                     │
                     ▼
              Better Engineering

Developer vẫn là người đưa ra quyết định.

AI giúp thực hiện công việc.

Context cung cấp kiến thức.

Skills chuẩn hóa workflow.

Agents mở rộng khả năng.

Tools kết nối AI với môi trường.

Và các hệ thống như AI Engineering Coach giúp chúng ta quan sát và cải thiện cách toàn bộ hệ thống đó vận hành.

Một Điều Quan Trọng Về AI Engineering Coach

Có một chi tiết mình nghĩ cần nói rõ trước khi kết thúc.

AI Engineering Coach không phải là một Microsoft product chính thức.

Repository mô tả đây là một open-source community effort của Microsoft employees, được cung cấp theo giấy phép MIT và không phải một Microsoft service hay support offering chính thức.

Điều này không làm dự án kém thú vị.

Ngược lại, nó khiến repository trở thành một ví dụ rất đáng để quan sát.

Bởi vì chúng ta không chỉ nhìn thấy một sản phẩm hoàn chỉnh.

Chúng ta còn nhìn thấy cách một nhóm kỹ sư Microsoft đang thử nghiệm những ý tưởng xoay quanh:

• AI Coding.
• Agentic Engineering.
• Context Engineering.
• Skills.
• AI Engineering Metrics.
• Developer Workflow.

Kết Luận – Observe, Measure, Detect, Improve

Sau bốn phần, có thể nhìn AI Engineering Coach như một vòng lặp hoàn chỉnh:

Observe → Measure → Detect → Improve

Developer sử dụng AI trong quá trình phát triển phần mềm.

AI Engineering Coach quan sát cách làm việc đó.

Dashboard giúp đo lường.

Anti-patterns giúp phát hiện những hành vi chưa tối ưu.

Context Health giúp cải thiện môi trường làm việc của AI.

Skill Finder giúp biến những workflow lặp lại thành các Skill có thể tái sử dụng.

Và từ đây, một điều khá thú vị bắt đầu xuất hiện.

Câu hỏi không còn là:

“Developer có sử dụng AI hay không?”

Mà trở thành:

“Developer đang sử dụng AI tốt đến mức nào?”

Đây có lẽ mới là vấn đề mà AI Engineering cần giải quyết trong giai đoạn tiếp theo.

Bởi vì khi AI ngày càng có khả năng viết code, debug, review, tìm kiếm thông tin và thực hiện nhiều tác vụ thay cho Developer, lợi thế cạnh tranh sẽ không còn đơn giản nằm ở việc ai có quyền truy cập vào AI.

Gần như tất cả mọi người đều sẽ có.

Lợi thế sẽ nằm ở việc:

Ai biết cách xây dựng một hệ thống để con người và AI cùng làm việc hiệu quả hơn?

Và đó chính là nơi khái niệm AI Engineering trở nên quan trọng.

Không phải chỉ để viết code nhanh hơn.

Mà để thiết kế lại cách chúng ta xây dựng phần mềm trong kỷ nguyên của AI Agents.

Series AI Engineering Coach

Nếu bạn theo dõi từ đầu, toàn bộ series có thể được nhìn lại qua bốn bước:

Phần 1 – Understand
AI Engineering Coach là gì và tại sao AI Coding đang chuyển sang AI Engineering?

Phần 2 – Measure
Dashboard, Practice Score và cách đo lường chất lượng làm việc với AI.

Phần 3 – Detect
45 AI Engineering Anti-patterns và những thói quen có thể làm giảm hiệu quả.

Phần 4 – Improve
Context Health, Skill Finder và cách xây dựng một môi trường tốt hơn cho AI Agent.

Understand → Measure → Detect → Improve

Đây cũng là điểm mình nghĩ nên dừng series tại đây.

Bởi vì đến thời điểm này, chúng ta đã đi từ câu hỏi “AI Engineering Coach là gì?” đến câu hỏi quan trọng hơn nhiều:

“Làm thế nào để chúng ta trở thành một AI Engineer tốt hơn?”

Và câu trả lời không nằm ở một Prompt thần kỳ.

Nó nằm ở cả một quy trình làm việc.