Phát triển phần mềm bằng AI đã vượt qua giai đoạn chỉ đơn thuần hoàn thành một dòng code hoặc tạo một method. Ngày nay, chúng ta có những công cụ có thể phân tích toàn bộ dự án, tạo file mới, viết unit test, hỗ trợ refactoring và thậm chí tham gia vào những nhiệm vụ phức tạp trong Solution. AI là người đồng hành, KHÔNG phải người cầm lái chính.
Và cùng với đó, những cuộc so sánh bắt đầu xuất hiện. Trong bài viết này, tôi sẽ so sánh hai công cụ tôi yêu thích sử dụng hàng ngày: OpenAI Codex và Claude Code — đặc biệt trong bối cảnh phát triển .NET.
Codex hay Claude Code? Công cụ nào tốt hơn cho công việc .NET? Sau trải nghiệm thực tế với cả hai, tôi nhận thấy câu trả lời không đơn giản như nhiều người nghĩ.
Trước khi bài viết này biến thành cuộc tranh luận cuồng nhiệt trong phần bình luận: không có người thắng tuyệt đối ở đây. Mỗi công cụ có cách tiếp cận khác nhau, và tùy vào vấn đề cần giải quyết, tôi thường chọn một trong hai.
Hãy cùng tìm hiểu nhé!
Mục lục
Thứ nhất: Hai công cụ hoạt động hoàn toàn khác nhau
Một trong những điều đầu tiên tôi nhận ra khi sử dụng cả hai công cụ trong môi trường phát triển .NET là: dù cùng mục tiêu — hỗ trợ phát triển phần mềm — nhưng cách chúng đến được giải pháp lại khác nhau hoàn toàn.
Codex
Với tôi, Codex mang lại cảm giác kiểm soát tuyệt đối đối với những gì đang xảy ra.
Bạn có thể làm việc theo cách có cấu trúc, phân tích những gì sẽ thay đổi và điều hướng việc triển khai từng bước một.
Đặc biệt khi tôi đang chỉnh sửa code có sẵn và muốn thực hiện một thay đổi cụ thể, đây là điều tôi rất thích.
Bạn biết đấy, kiểu:
“Sửa ở đây, nhưng vì Chúa, đừng phá hủy, ý tôi là, đừng tự ý đổi 35 thứ khác mà tôi không yêu cầu.”
Với các dự án lớn hoặc legacy, điều này tạo ra sự khác biệt rất lớn.
Hệ sinh thái .NET có những đặc thù riêng. Chúng ta có kiểu dữ liệu mạnh (strong typing), Dependency Injection, nhiều project trong cùng một Solution, NuGet, file .csproj, cấu hình, interface và vô số dependencies giữa các class.
Vì vậy, việc kiểm soát những gì đang được thay đổi là vô cùng quan trọng.
Claude Code
Trong khi đó, Claude Code mang lại trải nghiệm theo phương thức agent hơn rất nhiều.
Nó chủ yếu làm việc thông qua terminal và cảm giác không phải là “giúp tôi viết đoạn code này” mà nhiều hơn là:
“Đây là vấn đề. Hãy điều tra và xem cần làm gì.”
Claude Code có thể điều hướng qua các file, phân tích dependencies, thực thi lệnh và theo dõi vấn đề qua nhiều phần khác nhau của ứng dụng.
Với các nhiệm vụ lớn, điều này rất thú vị.
Tất nhiên, trao quyền truy cập terminal cho AI tùy ý sửa đổi dự án của bạn nghe có vẻ như tập 1 của một bộ phim sẽ kết thúc với việc Skynet ra đời…
Nhưng với các quyền hạn phù hợp và review kỹ lưỡng, nó hoạt động rất tốt.
So sánh công cụ mà không đưa vào một vấn đề thực tế thì cuối cùng lại trở thành cuộc thảo luận kinh điển:
“Công cụ của tôi tốt hơn vì tôi thích nó hơn.”
Vậy nên hãy cùng đi qua một số tình huống nơi tôi cảm nhận được sự khác biệt giữa hai công cụ.
1. Tạo API và cái “cơm rang”
Ai làm việc với ASP.NET Core sẽ hiểu ngay.
- Controller
- DTO
- Interface
- Service
- Mapping
- Cấu hình
- Thêm một DTO nữa
- Thêm một DTO nữa vì DTO đầu tiên không đúng loại DTO chúng ta cần…
Trong tình huống như thế này, Codex hoạt động rất tốt.
Khi mục tiêu rõ ràng, nó có thể sinh ra code C# khá gọn gàng, hoạt động tốt với các cấu trúc như:
- Controllers
- DTOs
- Records
- Nullable Reference Types
- Services
- Interfaces
- Mapping với AutoMapper hoặc Mapster
Với các nhiệm vụ được xác định rõ, tôi đánh giá cao tính dự đoán được của Codex.
Còn Claude Code thì sao?
Ở đây xuất hiện một khác biệt thú vị.
Claude Code có xu hướng nhìn vượt ra ngoài file bạn đang làm việc. Ví dụ, trong quá trình tạo API, nó có thể phân tích file .csproj, nhận ra các dependencies cần thiết và làm việc thêm với cấu trúc bao quanh triển khai đó.
Nghĩa là:
- Codex nhiều lần giải quyết rất tốt phần triển khai.
- Claude Code có xu hướng điều tra thêm môi trường mà triển khai đó cần hoạt động.
Và tùy vào việc bạn đang làm, điều này tiết kiệm khá nhiều công sức.
2. Refactoring và Dependency Injection
Tại đây, chúng ta bắt đầu bước vào tình huống tôi cho là thú vị nhất để so sánh hai công cụ.
Hãy tưởng tượng một service được đăng ký là:
services.AddScoped<IMyService, MyService>();
Nhưng sau khi phân tích ứng dụng, chúng ta nhận ra đáng lẽ nó nên là:
services.AddTransient<IMyService, MyService>();
Nó có vẻ như một thay đổi đơn giản.
Và nhiều lúc cũng đúng.
Cho đến khi bạn phát hiện ra service đó được sử dụng bởi năm class khác, mỗi class có dependencies riêng của nó, và ai đó ba năm trước đã quyết định tạo một dependency kỳ lạ trong project thứ ba.
Ai chưa từng gặp chuyện này?
Codex
Nếu tôi cô lập vấn đề và làm rõ những gì muốn thay đổi, Codex thường rất chính xác.
Để refactoring methods, đơn giản hóa code, cải thiện LINQ hoặc tái tổ chức một class cụ thể, tôi đánh giá cao kết quả của nó.
Nó hoạt động gần giống như phẫu thuật:
“Chúng ta cần sửa đúng chỗ này.”
Claude Code
Claude Code thường cố gắng hiểu tác động của thay đổi.
Vì vậy nó có thể tìm kiếm phần đăng ký trong Program.cs, xác định nơi interface đó được sử dụng, tìm các constructor liên quan và làm việc với các class bị ảnh hưởng khác.
Nghĩa là, khi thay đổi bắt đầu lan truyền qua nhiều file trong Solution, hành vi agent bắt đầu tạo ra sự khác biệt đáng kể.
Điều đó không có nghĩa là chúng ta chỉ cần ra lệnh:
“Đi và thay đổi tất cả.”
rồi đi uống cà phê.
Review code của bạn. Luôn luôn.
3. Bug và Unit Test
Đây có lẽ là nơi tôi nhận thấy sự khác biệt rõ nhất về cách tiếp cận giữa hai công cụ.
Nếu tôi có một quy tắc được xác định rõ và muốn tạo test với xUnit hoặc NUnit, Codex hoạt động rất tốt.
Đặc biệt khi tôi có thể thông báo rõ ràng:
- Đầu vào (input)
- Kết quả mong đợi (expected output)
- Các tình huống lỗi (error scenarios)
- Edge cases
Nó có thể nhanh chóng sinh ra một nền tảng test tốt.
[Fact]
public void CalculateTotal_ReturnsSumOfItems()
{
var items = new List<OrderItem>
{
new OrderItem { Price = 100, Quantity = 2 },
new OrderItem { Price = 50, Quantity = 1 }
};
var result = OrderCalculator.CalculateTotal(items);
Assert.Equal(250, result);
}
Bây giờ đến với cái bug “vui” đó…
Bạn chạy:
dotnet test
Và một stack trace khổng lồ hiện ra, khiến bạn tự hỏi một số quyết định mình đã đưa ra trong sự nghiệp.
Trong tình huống này, Claude Code trở nên rất thú vị vì quy trình có thể hoàn chỉnh hơn nhiều. Nó có thể hoạt động theo một chuỗi gần giống:
dotnet test- Test thất bại.
- Phân tích stack trace.
- Tìm code liên quan.
- Áp dụng thay đổi.
- Chạy test lại.
Khả năng điều tra vấn đề theo vòng lặp này có lẽ là một trong những đặc điểm tôi thích nhất trong mô hình làm việc agent.
Không chỉ là sinh ra code. Mà là tham gia vào quá trình tìm hiểu tại sao code đó không hoạt động.
Bảng so sánh tổng hợp
Dĩ nhiên đây không phải benchmark khoa học, cũng không phải chân lý tuyệt đối. Đó là nhận định của tôi dựa trên trải nghiệm thực tế khi sử dụng.
Là cảm nhận cá nhân khi sử dụng hai công cụ trong các tình huống .NET.
| Tình huống | Codex | Claude Code |
|---|---|---|
| Code C# xác định rõ ràng | Rất tốt | Rất tốt |
Làm việc với .csproj / NuGet |
Tốt, đặc biệt khi được chỉ định rõ | Rất tốt nhờ luồng tích hợp với CLI |
| Refactoring đa file | Kiểm soát hơn | Rất tự nhiên nhờ hành vi agent |
| Chính xác trong thay đổi điểm | Rất tốt | Rất tốt |
| Debug điều tra | Rất tốt | Rất tốt |
| Đường cong học tập | Đơn giản hơn | Cần hiểu rõ quyền hạn và luồng qua terminal |
| Cách làm việc | Trực tiếp và có kiểm soát | Tự chủ và điều tra |
Và dòng cuối cùng có lẽ là khác biệt chính:
Kiểm soát × Tự chủ
Ít nhất đó là cảm nhận của tôi khi làm việc với cả hai.
Tóm lại: Codex hay Claude Code?
Câu trả lời mà mọi kiến trúc sư đều yêu thích:
Phụ thuộc.
Nhưng ở đây, thực sự phụ thuộc.
Tôi sẽ dùng Codex khi…
Tôi đang làm việc trong một codebase lớn hoặc legacy và muốn có nhiều kiểm soát đối với những thay đổi.
Đặc biệt là cái Solution tồn tại 10 năm, có 47 project, và mọi người đều sợ sửa class đó mà “luôn hoạt động”.
Bạn biết class đó là gì.
Tôi cũng đánh giá cao khi cần làm việc với:
- Thuật toán
- Method cô lập
- Refactoring cụ thể
- Boilerplate code
- Tạo API
- Quy tắc nghiệp vụ xác định rõ ràng
Trong các trường hợp này, trực tiếp hơn có thể chính xác là điều chúng ta cần.
Tôi sẽ dùng Claude Code khi…
Tôi cần điều tra một vấn đề lan truyền qua nhiều phần của dự án.
Ví dụ:
- Bug liên quan đến nhiều project trong Solution
- Thay đổi Dependency Injection
- Tạo cấu trúc hoàn chỉnh
- Chạy test và build
- Migration database
- Phân tích dependencies phức tạp
Tôi cũng thấy khá thú vị khi dùng trong các dự án greenfield.
Khi bạn đang bắt đầu một microservice hoặc ứng dụng mới, việc có một agent có thể hỗ trợ cả về môi trường, cấu trúc và CLI có thể tiết kiệm rất nhiều thời gian.
Kết luận: Cả hai công cụ
Tôi biết, đây là câu trả lời dễ dàng. Nhưng thực sự đây là kết luận tôi đã rút ra.
Tôi không thấy ý nghĩa lớn khi biến các công cụ AI thành lựa chọn tín ngưỡng.
“Tôi là Team Codex.”
“Tôi là Team Claude.”
Bình tĩnh mọi người…
Chúng là công cụ.
Và công cụ khác nhau có thể giải quyết vấn đề khác nhau.
Với tôi:
- Codex hoạt động rất tốt như một công cụ chính xác và có kiểm soát, đặc biệt khi tôi biết chính xác mình muốn sửa ở đâu.
- Claude Code nổi bật khi tôi muốn tiếp cận theo cách điều tra, đặc biệt khi vấn đề phân bố khắp nhiều file hoặc project.
Một công cụ hoạt động rất tốt khi tôi nói:
“Tôi muốn thay đổi chỗ này.”
Công cụ kia hoạt động rất tốt khi tôi nói:
“Tôi có vấn đề này. Hãy cùng tìm ra nguyên nhân.”
Và tôi nghĩ sự khác biệt đó tóm gọn khá tốt trải nghiệm của tôi.
AI không loại bỏ nhà phát triển ra khỏi phương trình
Dĩ nhiên, tôi không thể kết thúc bài viết này mà không nói điều này. Luôn nhấn mạnh rằng AI là người đồng hành, không phải người cầm lái.
Dù bạn dùng Codex, Claude Code hay bất kỳ công cụ nào xuất hiện ngày mai, có một điều không thay đổi:
Bạn vẫn là người chịu trách nhiệm về code.
- Không quan trọng AI đã tạo một method.
- Không quan trọng nó đã thay đổi 15 file.
- Không quan trọng nó đã chạy toàn bộ test và hiện ra màu xanh đẹp đẽ nói mọi thứ đều ổn.
Review. Hiểu. Test. Đặt câu hỏi.
Bởi vì việc sử dụng tốt nhất những công cụ này, ít nhất với tôi, không phải là thay thế nhà phát triển.
Là tăng cường năng lực của anh ấy.
Một AI với một nhà phát triển giỏi có thể tăng năng suất đáng kể.
Một AI chạy mọi thứ mà không được review chỉ có thể sinh ra vấn đề nhanh hơn.
Cuối cùng, Codex và Claude Code là hai công cụ xuất sắc và tôi dự định tiếp tục sử dụng cả hai tùy theo vấn đề cần giải quyết.
Và có lẽ tháng sau sẽ xuất hiện công cụ khác, và chúng ta sẽ phải thảo luận lại toàn bộ câu chuyện này. Vì tôi vẫn muốn nói về Gemini và Copilot.
Hy vọng bài viết này hữu ích cho bạn!
