Trong những năm gần đây, các AI coding assistant ngày càng được sử dụng nhiều hơn trong quá trình phát triển phần mềm, từ sinh code, refactoring cho đến code review.

Một cách sử dụng phổ biến là cung cấp git diff hoặc nội dung của Pull Request cho AI và yêu cầu:

Review this change.

Với những thay đổi nhỏ và độc lập, cách tiếp cận này thường mang lại kết quả khá tốt.

Tuy nhiên, khi codebase trở nên lớn hơn và có nhiều dependency giữa các module, chỉ đọc phần code thay đổi thường chưa đủ để đánh giá đầy đủ tác động của một thay đổi.

Một reviewer có thể cần trả lời thêm những câu hỏi như:

• Function được sửa đang được gọi từ đâu?
• Module nào phụ thuộc vào phần code này?
• Thay đổi có ảnh hưởng tới execution flow nào khác không?
• Test nào liên quan tới đoạn code vừa thay đổi?
• Có dependency gián tiếp nào có khả năng bị ảnh hưởng không?

Đây là một trong những thách thức lớn của AI Code Review: không chỉ cần hiểu code thay đổi, mà còn cần có đủ context về codebase xung quanh thay đổi đó.

Trong bài viết này, chúng ta sẽ tìm hiểu một cách tiếp cận sử dụng Code Graph để hỗ trợ quá trình này, thông qua open-source tool Code Review Graph.

1. Giới hạn của việc chỉ review Git Diff

Giả sử một backend NestJS có use case như sau:

@Injectable()
export class UpdateUserEmailUseCase {
  async execute(userId: string, email: string) {
    const user = await this.userRepository.findById(userId);

    user.changeEmail(email);

    await this.userRepository.save(user);
  }
}

Một Pull Request thay đổi logic thành:

user.changeEmail(email.toLowerCase());

Nếu chỉ nhìn vào diff, một reviewer có thể kiểm tra được:

• xử lý null hoặc undefined;
• validation;
• việc sử dụng trim();
• naming;
• coding convention.

Tuy nhiên, để đánh giá tác động của thay đổi này, chúng ta còn cần biết những phần khác của hệ thống đang sử dụng email như thế nào.

Ví dụ, một flow update email có thể đi qua:

UserResolver → UpdateUserEmailUseCase → User.changeEmail

Trong khi flow đăng nhập lại đi qua:

LoginResolver → LoginUseCase → UserRepository.findByEmail

Nếu email được normalize khi update nhưng không được normalize khi login, hệ thống có thể phát sinh hành vi không nhất quán.

Ví dụ:

Stored email:
foo@example.com

Login input:
Foo@Example.com

Result:
User not found

Đây là loại vấn đề khó phát hiện nếu reviewer chỉ quan sát những dòng code xuất hiện trong git diff.

2. AI cần context về dependency

Khi một developer đã làm việc lâu với một hệ thống, họ thường có sẵn một mental model về codebase.

Ví dụ, trong một backend theo hướng DDD, developer có thể hiểu rằng UseCase đóng vai trò orchestration layer: nhận request từ Resolver/Controller, sử dụng Domain để thực thi business rule và gọi Repository để đọc hoặc ghi dữ liệu.

Các thành phần này không nhất thiết tạo thành một pipeline tuyến tính kiểu:

Resolver → UseCase → Domain → Repository → Database

Thay vào đó, một UseCase có thể phối hợp nhiều dependency khác nhau:

Resolver → UseCase → { Domain, Repository, External Service, Event }

Trong đó Repository implementation có thể truy cập Database, còn Event có thể kích hoạt các Handler khác.

Developer cũng thường biết module nào phụ thuộc module nào, event nào được publish sau một thay đổi và test nào thường liên quan tới một flow cụ thể.

AI coding assistant không mặc định có kiến thức này.

Để xây dựng context, agent thường phải:

• đọc git diff;
• tìm identifier;
• đọc caller;
• follow import;
• đọc service liên quan;
• tìm test;
• đọc thêm source code;
• sau đó mới bắt đầu reasoning.

Các coding agent hiện nay có thể thực hiện quá trình trên bằng các công cụ như grep, ripgrep, filesystem search hoặc language server.

Tuy nhiên, với repository lớn, quá trình khám phá dependency này có thể phải lặp lại nhiều lần.

Một hướng tiếp cận khác là xây dựng sẵn một representation của các relationship trong codebase để AI có thể truy vấn khi cần.

3. Nhìn codebase dưới dạng Graph

Khi mở một repository, chúng ta thường nhìn thấy cấu trúc dạng cây:

src/
├── users/
├── authentication/
├── payments/
└── notifications/

Cấu trúc này rất hữu ích để biết source code nằm ở đâu.

Tuy nhiên, relationship thực tế giữa các thành phần trong hệ thống lại gần với một graph hơn.

Ví dụ, một UpdateUserEmailUseCase có thể đồng thời:

• gọi UserRepository.findById() để lấy dữ liệu;
• gọi User.changeEmail() để thực thi business rule;
• gọi UserRepository.save() để persist thay đổi;
• publish một event sau khi update thành công.

Như vậy relationship không đơn giản là:

UseCase → Domain → Repository

mà có thể là nhiều cạnh xuất phát từ cùng một node UseCase.

Trong graph đó, các thành phần có thể được biểu diễn dưới dạng node:

• Function
• Class
• Module
• File
• Test

Relationship giữa chúng có thể trở thành edge:

• CALLS
• IMPORTS
• INHERITS
• IMPLEMENTS
• TESTS
• DEPENDS_ON

Ví dụ, graph có thể biểu diễn các loại relationship khác nhau:

UpdateUserEmailUseCase --calls--> User.changeEmail

UpdateUserEmailUseCase --uses--> UserRepository

TypeOrmUserRepository --implements--> UserRepository

TypeOrmUserRepository --accesses--> PostgreSQL

Điều này phản ánh codebase chính xác hơn một chuỗi tuyến tính đơn giản.

Khi đã có representation này, nhiều câu hỏi về codebase trở thành bài toán graph traversal.

Ví dụ:

Ai đang gọi function X?

Có thể tìm incoming relationships.

Hoặc:

Nếu function X thay đổi, những component nào có khả năng bị ảnh hưởng?

Có thể traverse dependency graph theo hướng ngược lại.

Đây là ý tưởng nền tảng phía sau Code Review Graph.

4. Code Review Graph là gì?

Code Review Graph là một open-source tool xây dựng một structural graph từ source code của repository.

Source code được parse để xác định các relationship như function call, import, inheritance, test relationship và execution relationship.

Ở mức kiến trúc, có thể xem Code Review Graph như một code intelligence layer nằm giữa source code và AI agent.

Mục tiêu không phải thay thế khả năng đọc source code của AI, mà giúp agent xác định:

Phần source code nào cần đọc cho task hiện tại?

Một điểm đáng chú ý khác là graph có thể được cập nhật incrementally khi codebase thay đổi, thay vì phải rebuild toàn bộ repository cho mỗi lần review.

Điều này làm cho graph trở thành một lớp knowledge có thể tái sử dụng cho nhiều task khác nhau.

5. Ví dụ với Next.js và NestJS

Giả sử một hệ thống sử dụng các thành phần sau.

Frontend

• Next.js
• Apollo Client
• GraphQL

Backend

• NestJS Resolver: entry point của GraphQL;
• UseCase: điều phối application flow;
• Domain Entity / Domain Service: chứa business rule;
• Repository Interface: abstraction để UseCase đọc hoặc ghi dữ liệu;
• Repository Implementation: implementation cụ thể bằng TypeORM hoặc công nghệ persistence tương ứng;
• Database: nơi dữ liệu được persist.

Các thành phần backend trên không tạo thành một pipeline tuyến tính cố định.

Trong ví dụ này, UseCase đóng vai trò orchestration layer:

• gọi Repository để load entity;
• gọi Domain Entity để thực thi business logic;
• gọi Repository để persist trạng thái mới;
• và tùy use case có thể gọi thêm event bus hoặc external service.

Giả sử có requirement:

Khi user thay đổi email, hệ thống phải chuyển email về lowercase trước khi lưu.

Developer thay đổi use case:

async execute(userId: string, email: string) {
  const user = await this.userRepository.findById(userId);

  user.changeEmail(email.toLowerCase());

  await this.userRepository.save(user);
}

Đoạn code này thể hiện khá rõ vai trò của từng thành phần:

• UpdateUserEmailUseCase điều phối flow;
• UserRepository.findById() load entity;
• User.changeEmail() thực thi business logic;
• UserRepository.save() persist trạng thái mới.

Repository giúp UseCase không cần biết dữ liệu phía dưới được lưu bằng PostgreSQL, MySQL hay một persistence mechanism khác.

Nếu chỉ review local code, một AI assistant có thể đưa ra nhận xét như:

Consider trimming the email before converting
it to lowercase.

Nhận xét này có thể đúng.

Nhưng nó chưa trả lời được câu hỏi quan trọng hơn:

Thay đổi này ảnh hưởng tới những phần nào khác trong hệ thống?

6. Từ Changed Code đến Blast Radius

Giả sử User.changeEmail() không chỉ được sử dụng bởi UpdateUserEmailUseCase.

Nó còn có thể được gọi từ:

• RegisterUserUseCase;
• AdminUpdateUserUseCase.

Sau khi thay đổi email, hệ thống có thể publish UserUpdatedEvent, sau đó một EmailSyncHandler đồng bộ dữ liệu sang hệ thống khác.

Ngoài ra còn có các test liên quan tới entity, use case và registration flow.

Đây là khái niệm thường được gọi là blast radius hoặc impact radius.

Thay vì chỉ cung cấp cho AI:

Changed:
User.changeEmail()

graph có thể giúp tạo context gần với:

Changed node:
User.changeEmail()

Direct callers:
- UpdateUserEmailUseCase
- RegisterUserUseCase
- AdminUpdateUserUseCase

Affected flows:
- Profile email update
- Registration
- Admin user update

Related tests:
- user.entity.spec.ts
- update-user-email.usecase.spec.ts
- register-user.usecase.spec.ts

Đây là sự khác biệt giữa:

Review code vừa thay đổi

và:

Review impact của thay đổi.

7. Blast Radius có ý nghĩa gì đối với Code Review?

Một code review thông thường trả lời câu hỏi:

Code vừa thay đổi có vấn đề gì không?

Nhưng trong các hệ thống lớn, reviewer còn cần trả lời:

Nếu thay đổi này sai, những phần nào khác có thể bị ảnh hưởng?

Quay lại ví dụ normalize email.

Graph có thể giúp reviewer chú ý tới một dependency khác:

LoginResolver → LoginUseCase → UserRepository.findByEmail

Từ đó AI có thể nhận ra một vấn đề tiềm ẩn:

Potential inconsistency:

UpdateUserEmailUseCase normalizes the email before
saving, while LoginUseCase passes the raw email to
UserRepository.findByEmail.

Consider normalizing the email consistently at a
shared domain boundary or repository query layer.

Giá trị của graph trong trường hợp này không nằm ở việc graph tự phát hiện bug.

Graph giúp AI tìm đúng context để reasoning về bug.

8. Tại sao không chỉ dùng grep hoặc code search?

Một câu hỏi tự nhiên là:

Các AI coding agent hiện nay đã có grep, ripgrep, filesystem search và language server. Vậy thêm graph để làm gì?

Code Graph không nên được xem là sự thay thế cho code search.

Sự khác biệt nằm ở cách dependency được khám phá.

Không có graph, agent phải lặp lại nhiều bước:

• search identifier;
• đọc file;
• follow import;
• tìm caller;
• tìm test;
• đọc thêm implementation.

Có graph, agent có thể truy vấn dependency đã được index trước để lấy:

• callers;
• related flows;
• related tests;
• affected components.

Sau đó agent vẫn đọc source code thực tế trước khi reasoning.

Có thể tóm tắt sự khác biệt như sau:

Repeated dependency discovery

so với:

Query dependency đã được index trước

Với repository nhỏ, khác biệt này có thể không đáng kể.

Với monorepo hoặc hệ thống có nhiều layer, giá trị bắt đầu rõ ràng hơn.

9. MCP đóng vai trò gì?

Code Review Graph expose code intelligence thông qua MCP.

Điều này cho phép AI agent truy vấn các loại context như:

• minimal context;
• impact radius;
• review context;
• graph traversal;
• affected flows;
• changed components.

Điểm đáng chú ý là LLM không cần nhận toàn bộ repository trong context.

Agent có thể yêu cầu đúng loại thông tin cần thiết cho task hiện tại.

Đây cũng là một pattern có thể áp dụng rộng hơn cho các AI system:

Không cung cấp toàn bộ dữ liệu cho model.
Cung cấp tool để model truy vấn dữ liệu cần thiết.

10. Code Graph và Semantic Search

Code Graph và semantic search đều có mục tiêu hỗ trợ retrieval, nhưng chúng giải quyết những loại câu hỏi khác nhau.

Ví dụ semantic search phù hợp với câu hỏi:

Đoạn code nào có nội dung liên quan tới payment?

Kết quả có thể là:

• PaymentService;
• PaymentController;
• PaymentDTO;
• PaymentDocumentation.

Trong khi graph phù hợp hơn với:

Ai đang gọi PaymentService.capture()?

Kết quả có thể biểu diễn một dependency chain như:

CheckoutController → CheckoutUseCase → PaymentService.capture → StripeClient

Hai cách tiếp cận bổ sung cho nhau.

Semantic search giúp tìm semantic relevance.

Graph giúp tìm structural relationship.

Một hệ thống code intelligence hoàn chỉnh có thể kết hợp cả hai.

11. Test Impact Analysis

Ngoài code review, graph cũng có thể hỗ trợ một use case khác: xác định test liên quan tới thay đổi.

Ví dụ một PR thay đổi:

UpdateUserEmailUseCase

Các test liên quan có thể bao gồm:

update-user-email.usecase.spec.ts
user.resolver.spec.ts
profile.e2e-spec.ts

Với repository có test suite lớn, selective testing có thể trở thành một use case đáng quan tâm.

Tuy nhiên, cần lưu ý rằng affected-test analysis không nên được hiểu là:

Chỉ cần chạy các test graph trả về là chắc chắn đủ.

Độ chính xác vẫn phụ thuộc vào mức độ đầy đủ của relationship trong graph.

Danh sách test nên được xem như candidates cần ưu tiên chạy hoặc kiểm tra.

12. Ưu điểm của cách tiếp cận Code Graph

12.1. Context có cấu trúc

Thay vì cung cấp cho AI hàng loạt source file không có relationship rõ ràng, graph có thể biểu diễn context theo chuỗi:

Changed Function → Direct Caller → Use Case → Entry Point

Điều này giúp model hiểu vì sao một file hoặc function xuất hiện trong context.

12.2. Có thể tái sử dụng knowledge về codebase

Nếu không có index, agent có thể phải khám phá dependency lại cho từng task.

Graph cho phép:

• parse repository;
• lưu relationship;
• update incrementally;
• reuse knowledge cho nhiều task khác nhau.

Điều này đặc biệt phù hợp với repository được AI agent truy cập thường xuyên.

Một lợi ích khác của graph là có thể giữ được loại relationship giữa các thành phần thay vì chỉ biết rằng hai file “có liên quan”.

Ví dụ:

UseCase --uses--> Repository Interface

Repository Implementation --implements--> Repository Interface

Repository Implementation --accesses--> Database

Việc phân biệt các relationship này giúp AI có context chính xác hơn khi phân tích architecture hoặc impact của một thay đổi.

12.3. Phù hợp với Blast Radius Analysis

Blast radius về bản chất là một dependency problem.

Khi một function thay đổi, reviewer thường muốn lần theo:

Function → Caller → Service → API

Graph là một representation tự nhiên cho loại traversal này.

12.4. Giúp AI tập trung vào reasoning

Graph không thay thế việc đọc source code.

Nó có thể giúp giảm thời gian agent dành cho câu hỏi:

File nào cần đọc?

để dành nhiều hơn cho:

Các file liên quan đang thể hiện behavior gì và thay đổi có vấn đề gì?

Một workflow hợp lý là:

Git Diff → Detect Changed Nodes → Impact Analysis → Relevant Execution Flows → Related Tests → Read Actual Source Code → AI Reasoning → Developer Review

13. Những giới hạn cần lưu ý

Code Graph không phải là representation hoàn chỉnh của runtime behavior.

13.1. Static dependency không đồng nghĩa với runtime dependency

Ví dụ:

eventBus.publish(
  new UserEmailUpdatedEvent(),
);

và:

@EventsHandler(UserEmailUpdatedEvent)
export class SyncCRMHandler {
  // ...
}

Runtime flow thực tế là:

UserService → EventBus → UserEmailUpdatedEvent → SyncCRMHandler

Nhưng trong source code có thể không tồn tại direct call:

UserService → SyncCRMHandler

Điều tương tự xảy ra với:

• Kafka;
• RabbitMQ;
• SQS;
• SNS;
• Webhooks;
• Dependency Injection;
• Reflection;
• Dynamic Import.

Các relationship này khó phân tích hơn direct function call.

13.2. Business dependency không nhất thiết xuất hiện trong Call Graph

Giả sử Authentication Service và CRM Sync Service đều phụ thuộc vào:

users.email

Hai service không nhất thiết gọi trực tiếp lẫn nhau.

Chúng cũng có thể nằm ở những application flow hoàn toàn khác nhau.

Tuy nhiên, chúng cùng phụ thuộc vào một business invariant:

Email phải được normalize theo cùng một rule.

Call graph không tự động hiểu được loại dependency này. Dependency này không thể hiện bằng một direct function call hay một chuỗi:

Service A → Service B

Do đó, ngay cả khi structural graph mô tả chính xác quan hệ giữa UseCase, Domain và Repository, graph vẫn chưa chắc hiểu được những business invariant được chia sẻ giữa các flow khác nhau.

Đây là một ví dụ cho thấy structural dependency và business dependency là hai khái niệm khác nhau.

13.3. Kết quả phụ thuộc vào chất lượng của parser

Nếu parser bỏ sót relationship:

A → B

thì blast radius có thể thiếu A.

Ngược lại, nếu graph cố tình theo hướng conservative, kết quả có thể chứa thêm những component thực tế không bị ảnh hưởng.

Do đó output của impact analysis nên được xem là:

Danh sách candidates cần kiểm tra

thay vì:

Danh sách chính xác tuyệt đối các component bị ảnh hưởng

Đây là distinction quan trọng khi áp dụng code graph vào production workflow.

14. Khi nào Code Graph có thể mang lại nhiều giá trị?

Không phải repository nào cũng cần thêm một graph layer.

Một project có:

• 20–30 files;
• architecture đơn giản;
• ít dependency;

có thể chỉ cần:

rg "functionName"

Code Graph bắt đầu đáng cân nhắc hơn khi hệ thống có:

• nhiều module;
• nhiều architectural layer;
• dependency chain dài;
• nhiều developer;
• test suite lớn;
• AI agent được sử dụng thường xuyên.

Trong các hệ thống như vậy, một UseCase thường không chỉ gọi một component theo một chuỗi tuyến tính.

Ví dụ:

Controller → UseCase

sau đó UseCase có thể phối hợp:

• Domain Service;
• Repository → Database;
• Event → Handler;
• external service hoặc các dependency khác.

Một flow xuyên hệ thống cũng có thể đi qua:

Frontend → GraphQL → Backend → Event System → Worker

Trong trường hợp này, impact analysis không còn đơn giản là follow một chuỗi:

A → B → C

mà phải xem xét nhiều nhánh relationship cùng lúc.

Trong những hệ thống như vậy, việc xác định impact của một thay đổi không còn đơn giản nữa.

15. Code Graph nên đóng vai trò Navigation Layer

Một điểm quan trọng khi sử dụng công cụ loại này là không nên chuyển từ:

AI tự search source code

sang:

AI hoàn toàn tin vào graph

Cách tiếp cận phù hợp hơn nằm ở giữa.

Một workflow phù hợp là:

Graph → Tìm vùng có khả năng liên quan → Đọc source code thực tế → Reasoning

Nói cách khác:

Graph nên giúp AI biết nên nhìn ở đâu, chứ không nên thay thế source code như nguồn thông tin cuối cùng.

Developer vẫn cần review kết quả cuối cùng, đặc biệt với các thay đổi liên quan tới:

• business logic;
• security;
• data integrity;
• production-critical flow.

Graph là navigation và context-retrieval layer, không phải single source of truth.

Một ví dụ điển hình là Repository.

Graph có thể cho AI biết rằng:

UpdateUserEmailUseCase sử dụng UserRepository

và:

TypeOrmUserRepository implement UserRepository.

Từ đó agent biết cần đọc cả UseCase, repository contract và implementation khi thay đổi liên quan tới persistence.

Tuy nhiên, graph không nên khiến agent tự suy luận rằng:

UseCase → Domain → Repository → Database

luôn là execution order của hệ thống.

Relationship graph cho biết các thành phần liên quan với nhau như thế nào, còn execution behavior cuối cùng vẫn phải được xác nhận bằng source code thực tế.

16. Một góc nhìn rộng hơn về AI Coding Agent

Ý tưởng đáng chú ý nhất của Code Review Graph không chỉ nằm ở một công cụ cụ thể.

Nó đặt ra một câu hỏi rộng hơn:

Một AI coding agent cần bao nhiêu source code trong context, và quan trọng hơn, nó cần source code nào?

Một model có context window lớn có thể đọc nhiều source code hơn.

Nhưng nhiều context hơn không nhất thiết đồng nghĩa với context tốt hơn.

Có thể hình dung một developer mới tham gia dự án.

Nếu đưa cho họ:

2 triệu dòng source code

và yêu cầu:

Hãy hiểu hệ thống.

Technically, toàn bộ thông tin đã ở đó.

Nhưng đây không phải cách hiệu quả nhất để onboarding.

Thứ họ cần thường là:

• Architecture;
• Modules;
• Dependencies;
• Execution Flows;
• Important Entry Points.

AI agent cũng có thể hưởng lợi từ một structure tương tự.

Theo hướng này, một coding agent có thể sử dụng nhiều nguồn intelligence khác nhau:

• Code Search;
• Code Graph;
• Git History;
• Documentation;
• Issue Tracker;
• Pull Request History;
• Logs;
• Tracing;
• Metrics.

Khi đó LLM trở thành reasoning layer nằm trên nhiều nguồn thông tin khác nhau, thay vì chỉ dựa vào khả năng đọc source code trong context window.

Đây có thể là một hướng phát triển đáng chú ý của AI coding agent trong tương lai.

Kết luận

Khi sử dụng AI trong code review, vấn đề không chỉ là khả năng reasoning của model.

Một yếu tố quan trọng không kém là:

Model đang reasoning trên context nào?

Git diff cho biết:

What changed?

Nhưng một reviewer thường cần thêm:

• What depends on it?
• What can be affected?
• What should be tested?

Code Graph là một trong những cách có thể giúp nối các câu hỏi này lại với nhau.

Quá trình review lúc đó không chỉ dừng ở:

Git Diff

mà có thể mở rộng thành:

Git Diff → Changed Functions → Dependencies → Blast Radius → Affected Flows → Related Tests → Code Review

Cách tiếp cận này đặc biệt đáng quan tâm với:

• repository lớn;
• monorepo;
• hệ thống có nhiều layer;
• dependency chain dài;
• test suite lớn;
• team sử dụng AI coding agent thường xuyên.

Tuy nhiên, Code Graph không phải giải pháp hoàn hảo.

Static analysis vẫn có giới hạn.

Runtime dependency, event-driven architecture và business relationship vẫn là những bài toán khó.

Vì vậy graph nên được sử dụng như một navigation và context-retrieval layer, không phải nguồn sự thật duy nhất.

Cuối cùng, có lẽ câu hỏi quan trọng không phải là:

Làm sao để AI đọc được nhiều source code hơn?

Mà là:

Làm sao để AI biết source code nào đáng đọc?

Thay vì cố gắng đưa thật nhiều code vào context của AI, có thể hiệu quả hơn nếu giúp AI xác định đúng code cần đọc.