Aider: lập trình cặp với LLM trong terminal, mỗi thay đổi một commit
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Aider là gì, và câu trả lời ngắn cho câu hỏi có nên dùng
Aider là một công cụ dòng lệnh để lập trình cặp với mô hình ngôn ngữ lớn (LLM) ngay trong terminal. README mô tả mục tiêu là giúp bạn bắt đầu dự án mới hoặc phát triển tiếp trên mã nguồn đang có, và nhấn mạnh bốn thứ: kết nối được hầu hết mô hình kể cả mô hình chạy cục bộ, bản đồ toàn bộ kho mã, tích hợp Git tự động commit, và kiểm tra lint, kiểm thử sau mỗi thay đổi [1].
Câu trả lời ngắn: nên thử nếu đội phần mềm của bạn làm việc trên kho Git, chịu được việc gửi một phần mã tới nhà cung cấp mô hình (hoặc dùng mô hình cục bộ), và muốn mọi thay đổi do AI tạo ra đều hiện thành commit để xem lại và hoàn tác. Chưa nên dùng nếu mã nguồn bị cấm đưa ra ngoài mà không có phương án mô hình nội bộ, hoặc nếu bạn kỳ vọng một công cụ tự chạy trọn một dự án mà không cần con người đọc diff.
Một điều cần nói thẳng: README liệt kê các mô hình hoạt động tốt nhất như Claude 3.7 Sonnet, DeepSeek R1, o1, o3-mini và GPT-4o [1]. Danh sách này có thể không phản ánh mô hình mới nhất tại ngày kiểm tra, nên cần kiểm tra bảng xếp hạng và cấu hình hiện hành trước khi chọn mô hình.
Khoảng trống giữa trò chuyện với chatbot và sửa mã trong kho thật
Dán một đoạn mã vào cửa sổ chat rồi chép kết quả về là thao tác ai cũng làm được, nhưng nó vỡ ra khi thay đổi chạm nhiều tệp. Mô hình không thấy các hàm liên quan, người dùng phải tự chọn đoạn nào cần dán, và việc chép tay dễ nhầm.
Aider xử lý bằng ba cơ chế mà tài liệu mô tả. Một là bản đồ kho mã gửi kèm mỗi yêu cầu để mô hình nhìn thấy các lớp, hàm và chữ ký ở khắp nơi [3]. Hai là định dạng chỉnh sửa (edit format) để mô hình trả về thay đổi dưới dạng có thể áp dụng tự động vào tệp [5]. Ba là Git: mỗi thay đổi thành một commit nên có thể xem lại và hoàn tác [4].
Thứ mà công cụ không thay thế được là đánh giá của con người về việc thay đổi có đúng nghiệp vụ không. Một commit đẹp, thông điệp rõ vẫn có thể sai quy tắc tính tiền hay bỏ sót trường hợp biên. Vì vậy, vòng đọc diff và chạy kiểm thử mới là chốt chặn thực sự.
Cách Aider ghép bốn bộ phận: mô hình, bản đồ, định dạng sửa và Git
Hãy hình dung Aider là một người điều phối ngồi giữa lập trình viên, kho Git và mô hình. Người điều phối không tự viết mã; nó chuẩn bị ngữ cảnh, đưa cho mô hình, nhận phản hồi, áp dụng vào tệp và ghi lại bằng commit. Mỗi phần có tài liệu riêng trong kho mã mà bài viết đã đọc [3][4][5][7].
Bản đồ kho mã chứa danh sách tệp cùng các ký hiệu quan trọng như lớp, hàm, kèm dòng mã then chốt của định nghĩa. Với kho lớn, Aider chọn phần liên quan nhất bằng thuật toán xếp hạng trên đồ thị trong đó mỗi tệp là một nút và các cạnh nối những tệp phụ thuộc nhau, rồi cắt cho vừa ngân sách token. Ngân sách này chịu ảnh hưởng của tùy chọn --map-tokens, mặc định 1k token, và có lúc được nới rộng khi chưa có tệp nào trong cuộc trò chuyện [3].
Về chế độ trò chuyện, có code (sửa mã), ask (hỏi đáp, không sửa), architect (hai mô hình) và help (hỏi về chính Aider) [7]. Về định dạng sửa, có whole, diff, diff-fenced, udiff, cùng editor-diff và editor-whole dành cho chế độ architect [5]. Chọn định dạng nào phụ thuộc mô hình; Aider có mặc định cho các mô hình phổ biến và cho phép ép bằng --edit-format [5].
Cuối cùng, tầng Git: Aider hỏi tạo kho nếu thư mục chưa có, commit mỗi khi sửa tệp, và commit trước các thay đổi chưa lưu của bạn để tách việc của người và việc của máy [4]. Ba phần này khớp nhau thành một vòng khép kín, và đó là lý do công cụ làm việc dễ kiểm soát hơn so với dán mã bằng tay.
Theo một yêu cầu đi hết vòng: từ câu lệnh đến commit
Bước một, bạn gõ yêu cầu ở chế độ đang bật. Aider gửi kèm bản đồ kho mã cho mô hình; nếu mô hình cần xem thêm mã, nó dựa vào bản đồ để chỉ ra tệp cần đọc, và Aider đề nghị bạn thêm các tệp đó vào cuộc trò chuyện [3]. Nghĩa là nội dung các tệp đã thêm cùng bản đồ sẽ được gửi tới nhà cung cấp mô hình bạn chọn; đây là suy luận từ cách tài liệu mô tả, và là điều khiến câu hỏi quyền riêng tư không thể bỏ qua.
Bước hai, mô hình trả lời bằng thay đổi theo định dạng đã chọn, ví dụ khối SEARCH và REPLACE giống ký hiệu xung đột merge của Git ở định dạng diff [5]. Ở chế độ architect, yêu cầu đi qua hai lượt: mô hình chính đề xuất cách giải, mô hình biên tập chuyển đề xuất thành chỉnh sửa tệp cụ thể; tài liệu nói cách này tốn thêm một yêu cầu, chậm và có thể đắt hơn [7].
Bước ba, Aider áp dụng thay đổi và commit. Thông điệp commit do mô hình yếu (weak model) soạn từ diff và lịch sử trò chuyện, mặc định theo Conventional Commits, và có thể đổi bằng --commit-prompt [4]. Cuối cùng, bạn xem bằng /diff, giữ lại hoặc dùng /undo để hủy thay đổi cuối [4]. README còn nói Aider có thể tự chạy lint và kiểm thử sau mỗi thay đổi và sửa lỗi phát hiện được; bài viết chưa đọc tài liệu riêng của phần này nên chỉ dựa vào mô tả ở README [1].
Danh mục tính năng có nguồn
Từ README: kết nối đám mây và mô hình cục bộ; hỗ trợ hơn 100 ngôn ngữ lập trình; dùng trong IDE bằng cách thêm bình luận vào mã để Aider xử lý; thêm hình ảnh và trang web làm ngữ cảnh; nhập liệu bằng giọng nói; sao chép, dán qua giao diện web chat của một mô hình [1]. Cách cài là gói aider-install rồi chạy lệnh aider với tham số --model và khóa API của nhà cung cấp [1].
Từ tài liệu Git: lệnh /diff xem thay đổi từ tin nhắn trước, /undo hủy thay đổi cuối, /commit commit các thay đổi còn dang dở và /git chạy lệnh Git thô. Aider đánh dấu commit bằng (aider) ở tên tác giả hoặc người commit, có tùy chọn thêm tiền tố vào thông điệp hoặc trailer Co-authored-by [4]. Nhờ vậy việc truy vết đoạn mã nào do AI tạo ra là khả thi.
Từ tài liệu chế độ: /ask và /code có thể dùng cho từng tin nhắn hoặc chuyển bền bằng /chat-mode; tài liệu khuyên thử luồng ask rồi code, trong đó thảo luận phương án ở chế độ ask rồi chuyển sang code và chỉ cần nói ngắn như go ahead [7].
Dành cho ai: những người ngồi gần terminal
Aider phù hợp nhất với lập trình viên thoải mái trong terminal và Git, đang bảo trì kho mã có sẵn và muốn giao cho mô hình các thay đổi có phạm vi rõ như thêm trường, sửa lỗi, viết kiểm thử, đổi tên, chuyển đổi định dạng. README cũng nói công cụ có thể làm việc từ IDE qua bình luận trong mã, nên không bắt buộc ở lại terminal suốt [1].
Quản lý kỹ thuật và trưởng nhóm sẽ quan tâm đến phần dấu vết: mỗi thay đổi có commit, có thể phân biệt người viết và máy viết, và có thể hoàn tác [4]. Với đội nhỏ chưa có quy trình rà soát chặt, đây là lợi thế nhưng không thay được rà soát mã.
Không phù hợp với người chưa dùng Git, với nhóm không có quyền gửi mã ra ngoài mà cũng không có mô hình cục bộ đủ mạnh, hoặc với người cần giao diện đồ họa đầy đủ. Những nhóm này nên cân nhắc hướng khác hoặc chuẩn bị nền tảng trước.
Tình huống giả định: đội phần mềm của một chuỗi phòng gym
Đây là đề xuất minh họa, không phải trường hợp đã triển khai. Giả sử một chuỗi phòng gym ở Đà Nẵng và Hà Nội có đội sáu lập trình viên, duy trì ứng dụng hội viên, hệ thống đặt lớp, thanh toán gói tập và liên kết với cổng kiểm soát ra vào. Mã nằm trong một kho Git, có kiểm thử đơn vị cho phần tính phí. Yêu cầu mới từ vận hành là cho phép bảo lưu thẻ tập, cộng thời gian bảo lưu vào ngày hết hạn, và áp dụng riêng cho gói tập theo năm.
Một cách dùng hợp lý: người phụ trách mở Aider trong nhánh tính năng, bật chế độ ask để hỏi mô hình về các nơi đang tính ngày hết hạn. Nhờ bản đồ kho mã, mô hình có thể chỉ ra các hàm liên quan [3]. Sau khi đội thống nhất phương án, chuyển sang code để thêm trường dữ liệu, hàm tính ngày mới và các ca kiểm thử, đúng luồng ask rồi code mà tài liệu mô tả [7]. Nếu thay đổi chạm nhiều lớp, thử chế độ architect với hai mô hình, chấp nhận thêm chi phí [7].
Quy trình bắt buộc là người đọc diff từng commit. Quy tắc tính tiền, thuế, hoàn tiền khi hội viên rời chuỗi thuộc trách nhiệm của đội chứ không của mô hình. Các ca kiểm thử do mô hình viết cần được chuyên viên nghiệp vụ xem lại ví dụ, chẳng hạn bảo lưu giữa kỳ, gói đã dùng khuyến mãi, hội viên chuyển chi nhánh.
Có hai điểm cần xử lý trước. Một là dữ liệu hội viên gồm họ tên, số điện thoại, chỉ số cơ thể và lịch sử thanh toán không được nằm trong kho mã hay thêm vào cuộc trò chuyện; dùng dữ liệu giả cho kiểm thử. Hai là tài liệu Git cho biết Aider mặc định bỏ qua hook pre-commit bằng cờ --no-verify và chỉ chạy chúng khi bật --git-commit-verify [4]. Nếu chuỗi dùng hook quét bí mật hay định dạng mã, phải bật cờ này và kiểm tra lại bằng một commit thử.
Đưa vào đội: cài đặt, chọn mô hình, thiết lập quy tắc dùng chung
Cài đặt khá nhẹ: gói aider-install, sau đó chạy aider trong thư mục dự án với mô hình và khóa API của nhà cung cấp [1]. Phần cần thiết kế là cách cấp khóa: khóa riêng của từng người hay khóa chung do công ty quản lý, có giới hạn chi tiêu, và nơi lưu để không bị commit nhầm. Tài liệu cấu hình chi tiết nằm ở mục config của dự án; bài viết chưa đọc phần đó nên không mô tả tệp cấu hình.
Nên thống nhất ba quy ước. Một là chỉ chạy trên nhánh riêng, không trực tiếp trên nhánh chính. Hai là chọn thuộc tính ghi nhận: giữ hậu tố (aider) hay dùng Co-authored-by để thống kê sau này [4]. Ba là mô hình nào được dùng cho loại dữ liệu nào, đặc biệt khi mô hình cục bộ được phép cho mã nhạy cảm còn mô hình đám mây chỉ cho mã không nhạy cảm [1].
Phân tích sử dụng của chính Aider là chủ đề riêng: dự án có thu thập thống kê ẩn danh nếu người dùng đồng ý, chi tiết ở phần bảo mật. Về duy trì, hãy ghi lại phiên bản Aider đang dùng và kiểm tra tần suất cập nhật của dự án trước khi mở rộng; dữ liệu GitHub lúc thu thập cho bản phát hành mới nhất là v0.86.0 ngày 09/08/2025, trong khi commit được ghim là ngày 22/05/2026. Bài viết không suy ra tình trạng bảo trì từ hai mốc này.
Bảo mật và quyền riêng tư: mã đi đâu, thống kê đi đâu
Phải tách hai luồng dữ liệu. Luồng thứ nhất là nội dung gửi tới mô hình: bản đồ kho mã và các tệp bạn thêm vào cuộc trò chuyện [3]. Dữ liệu này đến nhà cung cấp mô hình bạn chọn, nên điều khoản của họ mới là thứ quyết định việc lưu giữ và sử dụng. Chọn mô hình cục bộ, mà README nói Aider hỗ trợ [1], là cách giữ mã trong mạng nội bộ.
Luồng thứ hai là thống kê của chính Aider. Tài liệu nói thống kê chỉ thu thập khi người dùng đồng ý, ẩn danh gắn với UUID ngẫu nhiên, không thu thập mã, tin nhắn, khóa hay thông tin cá nhân; nội dung gồm mô hình dùng, số token, định dạng chỉnh sửa, tần suất lệnh và lỗi. Nếu bạn không chỉ định, Aider có thể bật hỏi ý kiến cho một nhóm người dùng ngẫu nhiên; chạy aider --analytics-disable một lần để tắt vĩnh viễn [6]. Có thể ghi log để kiểm tra bằng --analytics-log, hoặc trỏ tới một PostHog riêng [6].
Rủi ro còn lại là tác động của mã do mô hình sinh ra: lỗ hổng tiềm ẩn, phụ thuộc không cần thiết, hoặc đoạn mã sao chép. Việc bỏ qua hook pre-commit theo mặc định làm tăng rủi ro này nếu đội dựa vào hook để quét bí mật [4]. Bài viết chưa tìm thấy chính sách bảo mật riêng của kho trong các tệp đã đọc, vì vậy đừng giả định có quy trình báo lỗ hổng chính thức.
Giấy phép Apache-2.0 và những gì nó không bao phủ
Tệp LICENSE.txt ở thư mục gốc là văn bản Apache License 2.0, phiên bản 2, tháng 1 năm 2004 [2]. Giấy phép này cho phép sử dụng, sao chép, sửa đổi và phân phối, kể cả thương mại, kèm điều kiện giữ thông báo bản quyền và ghi chú thay đổi, và có điều khoản cấp quyền sáng chế. Bài viết đọc phần văn bản này chứ không chỉ dựa vào trường giấy phép của API GitHub.
Cần nhớ rằng nó chỉ áp dụng cho mã của Aider tại commit đã kiểm tra. Nó không bao phủ mô hình ngôn ngữ, dịch vụ API của nhà cung cấp mô hình, dữ liệu huấn luyện, mã mà mô hình sinh ra cho bạn, hay các thư viện Python phụ thuộc có giấy phép riêng. Quyền sở hữu và rủi ro bản quyền của mã do AI sinh ra phụ thuộc điều khoản của nhà cung cấp mô hình và pháp luật hiện hành, nên cần ý kiến pháp lý riêng.
Danh mục tệp của kho cho thấy có tài liệu thỏa thuận đóng góp và chính sách quyền riêng tư, nhưng bài viết không đọc chúng, nên không nêu nhận định về CLA, nhãn hiệu hay điều khoản riêng.
Chi phí: tiền token, thời gian đọc diff và công cấu hình
Phần mềm không thu phí giấy phép theo Apache-2.0 [2]; khoản chi chính là dịch vụ mô hình. Mỗi yêu cầu gửi kèm bản đồ kho mã và các tệp đã thêm, nên chi phí tăng theo kích thước ngữ cảnh. Chế độ architect dùng hai yêu cầu cho một lượt, và tạo thông điệp commit cũng gọi thêm một mô hình yếu [4][7]. Đơn giá phụ thuộc nhà cung cấp và thay đổi theo thời gian, bài viết không đưa con số.
Nguồn lực cần có gồm: thời gian của một kỹ sư dẫn dắt để đặt quy ước và theo dõi khóa API; thời gian đọc diff của cả đội, thường là chi phí lớn nhất mà ít người tính; hạ tầng nếu chạy mô hình cục bộ, tức một máy trạm hoặc máy chủ có bộ xử lý đồ họa đủ bộ nhớ cho mô hình đã chọn; và người rà soát bảo mật lần đầu.
Một cách tính mà đội có thể áp dụng: ghi lại trong giai đoạn thử số token đã tiêu, số commit do Aider tạo, tỷ lệ commit bị hủy hoặc sửa lại, rồi ước lượng chi phí trên mỗi thay đổi được giữ lại. Đừng dựa vào con số của đội khác.
Aider đứng ở đâu so với những cách làm khác
Có thể chia thành ba nhóm. Nhóm thứ nhất là trợ lý tích hợp vào trình soạn thảo, đưa gợi ý ngay trong giao diện đồ họa. Nhóm thứ hai là các tác tử chạy tự động nhiều bước, tự mở tệp, chạy lệnh và lặp lại. Nhóm thứ ba là dùng chatbot web rồi chép tay. Bài viết không so sánh sản phẩm cụ thể vì chưa đọc tài liệu của chúng.
Đặc điểm nổi bật của Aider theo tài liệu là sự gắn chặt với Git và lựa chọn mô hình linh hoạt [1][4]. Mỗi thay đổi thành một commit nên dễ quay lui, khác với cách chép từ chatbot không để lại dấu vết. Chế độ copy, paste qua web chat cho phép dùng mô hình chỉ có sẵn trên web [1].
Điểm đổi lại: Aider hướng tới người chủ động điều khiển từng bước. Nếu nhu cầu là giao nguyên một việc dài hơi để tác tử tự xoay xở, bạn cần đánh giá riêng. Tiêu chí chọn gợi ý: mức kiểm soát mong muốn, chính sách dữ liệu, môi trường làm việc (terminal hay IDE) và ngân sách cho mô hình.
Hạn chế, cảnh báo và lúc không nên dùng
Một: độ chính xác phụ thuộc mô hình. Tài liệu về định dạng chỉnh sửa thừa nhận mô hình khác nhau hợp với định dạng khác nhau, ví dụ udiff dùng chủ yếu cho họ GPT-4 Turbo để giảm tình trạng lười viết mã, và diff-fenced chủ yếu cho họ Gemini [5]. Cấu hình sai có thể khiến chỉnh sửa không áp dụng được.
Hai: bản đồ kho mã bị giới hạn bởi ngân sách token, nên với kho rất lớn hoặc mã sinh tự động, mô hình có thể không thấy phần quan trọng [3]. Ba: Danh sách mô hình ưa thích trong README có thể đã lỗi thời [1]; hiệu quả thực tế phải được đo lại. Bốn: hook pre-commit bị bỏ qua mặc định [4].
Không nên dùng khi chưa có cơ chế rà soát diff, khi mã hay dữ liệu bị cấm gửi ra ngoài và chưa có mô hình cục bộ được phê duyệt, hoặc khi thay đổi liên quan đến tính toán tài chính, an toàn thể chất, bảo mật mà không có người chuyên môn kiểm tra.
Thử nghiệm cho một nhóm nhỏ trong sáu tuần
Tuần một: chọn kho ít rủi ro, ví dụ công cụ nội bộ cho báo cáo, và một mô hình đã được phê duyệt về dữ liệu. Chạy trên nhánh riêng, bật --git-commit-verify nếu có hook, kiểm tra bằng commit thử [4]. Thiết lập ghi nhận số token và số commit.
Tuần hai đến bốn: giao 15 đến 20 việc nhỏ có tiêu chí hoàn thành rõ, nửa số việc làm theo cách quen thuộc và nửa số việc có Aider. Đo: thời gian từ nhận việc đến khi pull request được chấp nhận, số lần người rà soát yêu cầu sửa, tỷ lệ commit của Aider bị hủy bằng /undo hoặc viết lại, và số lỗi phát hiện sau hợp nhất. Mẫu nhỏ, kết quả chỉ để định hướng.
Tuần năm và sáu: thử chế độ architect trên hai đến ba việc phức tạp và so chi phí [7]; kiểm tra cấu hình thống kê (đã tắt hoặc đã chọn rõ) [6]. Điều kiện dừng: nếu tỷ lệ phải viết lại cao đến mức thời gian rà soát lớn hơn thời gian tiết kiệm, nếu phát hiện dữ liệu nhạy cảm lọt vào ngữ cảnh, hoặc nếu hook bắt buộc không chạy được, thì dừng và xem xét lại. Ngưỡng do đội tự đặt trước khi bắt đầu.
Kết luận
Aider là lựa chọn đáng cân nhắc cho đội phần mềm đã sống trong Git và terminal, muốn dùng LLM như một cộng sự có dấu vết rõ ràng. Giá trị nằm ở bản đồ kho mã, định dạng chỉnh sửa theo từng mô hình và vòng commit, hoàn tác [3][4][5].
Đổi lại là trách nhiệm: bạn quyết định mã đi đâu, mô hình nào được dùng, hook nào phải chạy, và người nào đọc diff. Hãy thử trên phạm vi nhỏ với tiêu chí đo trước khi áp dụng rộng.
Nguồn và phương pháp
Đây là nghiên cứu bàn giấy, không phải bài báo khoa học đã bình duyệt, và không cài đặt, chạy hay đo Aider. Mốc nguồn là commit 5dc9490bb35f9729ef2c95d00a19ccd30c26339c ngày 22/05/2026, kiểm tra ngày 12/10/2026. Các tệp đã đọc: README.md, LICENSE.txt, và bốn tài liệu trong aider/website/docs gồm repomap, git, more/edit-formats, more/analytics và usage/modes [1][2][3][4][5][6][7].
Aider được chọn từ kho lưu trữ GitHub Trending do cộng đồng sao lưu, xuất hiện 3 lần từ 05/03/2026 đến 25/05/2026, thuộc nhóm Phát triển và kiểm thử; trang bằng chứng đầu tiên ghi vị trí 8 trong danh sách Python [8]. Kho chỉ có danh sách Python, Go, JavaScript và Swift, thiếu ngày 03/09/2026 và 12/10/2026, không phải top 100 chính thức. Các tình huống Việt Nam, kế hoạch và ngưỡng đo là đề xuất của bài viết.
Xem mã nguồn Aider trên GitHub