Bài học kinh nghiệm khi viết 100.000 dòng code Rust với sự hỗ trợ của AI (2025)

Trong vài tháng qua, tôi đã thực hiện các bài kiểm thử căng thẳng (stress-test) để xem các tác nhân lập trình AI (AI coding agents) có thể đưa chúng ta đi xa đến mức nào trong việc xây dựng các hệ thống phân tán thực tế, chuẩn bị cho môi trường sản xuất (production-grade).

Kết quả là một engine đồng thuận multi-Paxos dựa trên Rust không chỉ triển khai đầy đủ các tính năng của Thư viện Trạng thái Sao chép (Replicated State Library - RSL) của Azure—nằm nền tảng cho hầu hết các dịch vụ chính của Azure—mà còn hiện đại hóa nó cho phần cứng ngày nay.

Toàn bộ dự án mất khoảng 3 tháng, với 100.000 dòng code Rust được viết trong khoảng 4 tuần và tối ưu hóa hiệu suất từ 23.000 hoạt động/giây (ops/sec) lên 300.000 ops/sec đạt được trong khoảng 3 tuần. Ngoài năng suất chưa từng có, tôi đã khám phá ra một số kỹ thuật đóng vai trò then chốt. Bài viết này chia sẻ những bài học quý giá nhất của tôi về: đảm bảo tính đúng đắn với các hợp đồng code (code contracts), áp dụng phát triển hướng đặc tả (spec-driven development) phiên bản nhẹ nhàng, và theo đuổi tối ưu hóa hiệu suất quyết liệt—cộng với danh sách mong muốn cho tương lai của lập trình hỗ trợ bởi AI.

Tại sao cần hiện đại hóa RSL?

Azure RSL triển khai giao thức đồng thuận multi-Paxos và hình thành xương sống cho sự sao chép trong nhiều dịch vụ của Azure. Tuy nhiên, RSL được viết hơn một thập kỷ trước. Mặc dù mạnh mẽ, nó chưa phát triển để phù hợp với phần cứng và khối lượng công việc hiện đại.

Có ba khoảng cách chính đã thúc đẩy dự án này:

• Không có Pipelining (Kỹ thuật đường ống): Khi một phiếu bầu đang được truyền, các yêu cầu mới phải chờ, làm tăng độ trễ (latency).
• Không hỗ trợ NVM (Bộ nhớ bền): Bộ nhớ phi dễ bay hơi giờ đây phổ biến trong các trung tâm dữ liệu của Azure và có thể giảm đáng kể thời gian commit.
• Nhận thức phần cứng hạn chế: RSL không được xây dựng để tận dụng RDMA, hiện nay đã lan rộng trong các trung tâm dữ liệu của Azure.

Loại bỏ các giới hạn này có thể mở khóa độ trễ thấp hơn đáng kể và thông lượng (throughput) cao hơn—điều cực kỳ quan trọng cho các khối lượng công việc đám mây hiện đại và dịch vụ driven bởi AI.

Cho sự quan tâm của tôi đối với Rust và phát triển được tăng tốc bởi AI, tôi đã bắt tay vào xây dựng một bản RSL hiện đại tương đương từ đầu.

Tăng năng suất vượt bậc

Trong khoảng sáu tuần, tôi đã điều khiển AI và triển khai hơn 130.000 dòng code Rust bao gồm toàn bộ tính năng của RSL, bao gồm multi-Paxos, bầu chọn leader, sao chép log, tạo snapshot và thay đổi cấu hình.

Tôi đã sử dụng nhiều tác nhân lập trình AI có sẵn: GitHub Copilot, Claude Code, Codex, Augment Code, Kiro và Trae. Quy trình làm việc của tôi phát triển nhanh chóng, nhưng hôm nay các công cụ chính của tôi là Claude Code và Codex CLI, với VS Code xử lý các thay đổi (diffs) và chỉnh sửa nhỏ.

Tôi nhận thấy rằng lập trình từ CLI tạo ra luồng không đồng bộ hoàn hảo, tối đa hóa năng suất của tôi. Tôi cũng phát hiện ra một mẹo tâm lý đơn giản:

Tôi trả 100 USD/tháng cho gói tối đa của Anthropic. Điều này trở thành một hàm ép buộc (forcing function)—nếu tôi không khởi động một tác vụ lập trình với Claude trước khi đi ngủ, tôi cảm thấy như đang lãng phí tiền.

Khi Codex CLI xuất hiện, tôi đã thêm một đăng ký ChatGPT Plus thứ hai để xử lý giới hạn tốc độ—một đăng ký cho Thứ Ba đến Thứ Tư, đăng ký còn lại cho Thứ Năm đến Chủ Nhật.

Code Contracts — Do AI viết, phục vụ cho AI

Câu hỏi tôi nhận được nhiều nhất là: Làm thế nào AI có thể triển khai một thứ phức tạp như Paxos một cách chính xác?

Kiểm thử (testing) là lớp phòng thủ đầu tiên. Hệ thống của tôi hiện bao gồm hơn 1.300 bài kiểm thử—từ unit test đến các bài kiểm tích hợp tối thiểu (ví dụ: chỉ proposer + acceptor), cho đến các bài kiểm tích hợp đầy đủ với nhiều bản sao (multi-replica) và lỗi được chèn vào.

Bắt lỗi nhờ Contract

Nhưng bước đột phá thực sự đến từ các code contracts được dẫn dắt bởi AI.

Code contracts quy định các điều kiện tiên quyết (preconditions), điều kiện hậu quả (postconditions) và bất biến (invariants) cho các chức năng quan trọng. Các hợp đồng này được chuyển đổi thành các câu lệnh assert runtime trong quá trình kiểm thử nhưng có thể bị tắt trong các bản dựng production để đảm bảo hiệu suất. Mặc dù tôi bắt đầu sử dụng cách tiếp cận này từ lâu với .NET, AI đã làm cho contracts trở nên mạnh mẽ hơn nhiều.

Dưới đây là cách tôi áp dụng chúng ở ba cấp độ:

1. Yêu cầu AI viết contracts. Opus 4.1 viết contracts tốt, nhưng GPT-5 High viết xuất sắc. Tôi tập trung vào việc xem xét và tinh chỉnh.
2. Tạo test từ contracts. Khi các contracts được xác định, tôi yêu cầu AI tạo các trường hợp kiểm thử được nhắm mục tiêu cho từng điều kiện hậu quả. Nó xuất sắc trong việc này, tự động tạo ra các trường hợp ngoại ý có ý nghĩa.
3. Kiểm thử dựa trên thuộc tính (Property-based tests) cho contracts. Đây là sở thích của tôi. AI chuyển đổi contracts thành các bài kiểm thử dựa trên thuộc tính, khám phá một không gian khổng lồ của các đầu vào ngẫu nhiên. Bất kỳ vi phạm hợp đồng nào sẽ kích hoạt panic, lộ ra các lỗi sâu ngay lập tức.

Ví dụ, một contract được tạo bởi AI đã tìm thấy một vi phạm an toàn (safety violation) tinh tế của Paxos:

Contract tìm thấy bug

Hợp đồng đơn đó đã cứu what có thể là một vấn đề nghiêm trọng về tính nhất quán của sao chép—rất lâu trước khi nó từng chạm đến production.

Phát triển Spec-Driven phiên bản nhẹ nhàng

Tôi đã thử nhiều công cụ Spec-Driven Development (SDD). Trên thực tế, các thành phần trước đó (như bầu chọn leader, proposer, acceptor và learner) đều được triển khai theo cách tiếp cận SDD cứng nhắc. Tôi sẽ bắt đầu với một tệp yêu cầu markdown, chuyển nó thành thiết kế markdown, sau đó là danh sách nhiệm vụ markdown. Tuy nhiên, dần dần tôi thấy quy trình này quá cứng nhắc; thực hiện thay đổi dọc đường và đảm bảo tất cả tài liệu vẫn nhất quán trở thành cơn đau đầu.

Tôi đã chuyển sang một cách tiếp cận nhẹ nhàng hơn. Khi tôi làm việc trên một tính năng (ví dụ: snapshotting), tôi sử dụng /specify từ spec kit để tạo một spec markdown. Spec này bao gồm một vài user story và tiêu chí chấp nhận (acceptance criteria).

Dưới đây là một ví dụ về user story cho snapshotting:

Ví dụ User Story

Sau đó tôi sử dụng /clarify để yêu cầu AI tự phê bình và cải thiện các user story và tiêu chí. Tôi cũng yêu cầu nó đề xuất các user story bổ sung không được bao phủ trong spec ban đầu. Tôi dành phần lớn thời gian của mình ở đây.

Khi hài lòng, tôi chuyển sang chế độ plan và yêu cầu AI tạo kế hoạch cho một user story cụ thể. Cho khả năng của các tác nhân lập trình AI ngày nay, một user story đơn lẻ cảm thấy như đơn vị công việc "điểm ngọt" mà chúng có thể quản lý hiệu quả. Dọc đường, chúng ta có thể khám phá các bổ sung hoặc điều chỉnh, dễ xử lý trong cùng phiên lập trình.

Tối ưu hóa hiệu suất một cách quyết liệt

Tối ưu hóa hiệu suất là nơi AI thực sự tỏa sáng. Sau khi đảm bảo tính đúng đắn ban đầu, tôi dành khoảng ba tuần chỉ để tinh chỉnh thông lượng—và AI trở thành đồng phi công của tôi trong kỹ thuật hiệu suất.

Thông qua các chu trình lặp lại, chúng tôi đã tăng thông lượng từ ~23.000 ops/sec lên ~300.000 ops/sec trên một máy tính xách tay duy nhất.

Dưới đây là vòng lặp tôi lặp lại nhiều lần:

• Yêu cầu AI chèn các chỉ số độ trễ trên tất cả các đường dẫn code.
• Chạy kiểm thử hiệu suất và xuất nhật ký dấu vết (trace logs).
• Để AI phân tích sự phân hủy độ trễ (nó viết các script Python để tính toán quantiles và xác định các nút thắt cổ chai).
• Yêu cầu AI đề xuất các tối ưu hóa, triển khai một cái, đo lại, và lặp lại.

Quá trình này làm nổi bật những hiểu biết tôi có thể đã bỏ lỡ—ví dụ, sự cạnh tranh khóa (lock contention) trên các đường dẫn không đồng bộ, sao chép bộ nhớ dư thừa và tạo nhiệm vụ không cần thiết.

Mô hình an toàn của Rust giúp dễ dàng đẩy các tối ưu hóa này một cách tự tin. Các lợi ích chính đến từ việc giảm thiểu phân bổ bộ nhớ, áp dụng các kỹ thuật zero-copy, tránh khóa và loại bỏ chi phí không đồng bộ có chọn lọc. Mỗi cải tiến cảm giác như bóc một lớp độ trễ khác khỏi một động cơ hiệu suất cao—mà không sợ hỏng bộ nhớ.

Danh sách mong muốn cho tương lai của lập trình hỗ trợ bởi AI

Nhìn lại hành trình của mình, tôi tự hỏi AI có thể mang lại nhiều giá trị hơn ở đâu. Dưới đây là một số mục trong danh sách mong muốn của tôi:

• Thực thi User Story End-to-End: Tôi vẫn thích tự định nghĩa các user story. Với tư cách là một kiến trúc sư, tôi cảm thấy mình có sự hiểu biết tốt hơn về những gì tôi đang xây dựng và cách tôi muốn xây dựng nó. Tuy nhiên, việc thực hiện một hoàn hảo là điều tôi tin rằng AI có thể xử lý ngày càng tốt hơn. Ngày nay, tôi vẫn phải dành một lượng thời gian công bằng để điều hướng AI—telling nó để tiếp tục khi nó tạm dừng, đề xuất refactor, xem xét độ phủ test và đề xuất các bài kiểm tra bổ sung. Tôi sẽ thích AI đảm nhận nhiều quyền tự chủ hơn để điều khiển việc này end-to-end.
• Quy trình làm việc Contracts Tự động hóa: Luồng áp dụng contracts dường như có thể tự động hóa phần lớn. Trong khi tôi vẫn muốn xem xét các contracts và đưa ra đề xuất, tôi muốn AI điều khiển phần còn lại: tạo test dựa trên contracts, gỡ lỗi các trường hợp kiểm thử cá nhân, đảm bảo tính nhất quán giữa test và contracts, và viết property-based tests. Khi một bài kiểm tra thất bại, tôi muốn AI gỡ lỗi và sửa các vấn đề nhỏ một cách tự động, chỉ thông báo cho tôi khi có các vấn đề chính xác thực sự trong contracts hoặc việc triển khai.
• Tối ưu hóa Hiệu suất Tự chủ: Điều chỉnh hiệu suất có vẻ chín muồi để tự động hóa hơn. Phần lớn những gì tôi đã làm là lặp đi lặp lại và có thể song song hóa. Các dự án như AlphaEvolve (hoặc OpenEvolve) cho thấy sự hứa hẹn trong hướng này. Lý tưởng nhất, tôi sẽ đề xuất các phương hướng tối ưu hóa tiềm năng và AI sẽ thực hiện các thí nghiệm hoàn toàn một mình. Trong khi các công cụ hiện nay xử lý các phần code nhỏ, việc áp dụng các kỹ thuật tương tự cho các cơ sở code lớn hơn với phép đo end-to-end dường khả thi.

Tình trạng dự án

Hạt giống của dự án là một thiết kế markdown thanh lịch được viết bởi Jay Lorch từ Microsoft Research. Thiết kế này đơn giản hóa rất nhiều tất cả các thành phần trong multi-Paxos, giúp dễ dàng triển khai và lý luận hơn.

Cho đến nay, 2 trong số 3 giới hạn của RSL đã được giải quyết: pipelining và hỗ trợ NVM (Jay đã tích hợp nhật ký tồn tại được xác minh đầy đủ cho NVM được xuất bản trong bài báo PoWER Never Corrupts tại OSDI 2025). Hỗ trợ RDMA vẫn đang TBD (xác định sau).

Đến nay, dự án đã phát triển lên hơn 130.000 dòng code Rust, với hơn 1.300 bài kiểm thử chiếm hơn 65% cơ sở code.

Độ phủ Test