Redis array: câu chuyện ngắn về một quá trình phát triển dài

• Việc phát triển kiểu dữ liệu Array mới của Redis bắt đầu vào đầu tháng 1 và được đưa lên dưới dạng PR sau khoảng 4 tháng; trong tháng đầu tiên, đặc tả đã được viết để mô tả tính cần thiết, cấu trúc C, biểu diễn thưa, ring buffer và ngữ nghĩa con trỏ mảng cho ARINSERT
• Thiết kế ban đầu được tinh chỉnh cùng với Opus, và sau khi GPT 5.3 ra mắt thì quá trình thiết kế và phát triển được thực hiện bằng Codex; trong quá trình phản hồi với AI, các điểm đánh đổi và những phần bị thiết kế quá mức liên tục được xem xét
• Phần triển khai đã được thay đổi để cả việc đặt chỉ số lớn như ARSET myarray 293842948324 foo cũng hoạt động mà không cần cấp phát khổng lồ; cấu trúc dữ liệu nội bộ sẽ chuyển đổi theo điều kiện giữa siêu thư mục, thư mục dày đặc được chia lát và các lát mảng thực tế
• Mỗi lát mặc định chứa 4096 phần tử, và ARSCAN cùng ARPOP có thể quét mảng hiện có với thời gian tỷ lệ theo số phần tử thực sự tồn tại, thay vì theo toàn bộ kích thước phạm vi
• Trường hợp sử dụng đưa các tệp Markdown vào mảng Redis đã dẫn tới việc triển khai ARGREP; TRE được chọn để hỗ trợ biểu thức chính quy, và các trường hợp sử dụng được tổng hợp trong Redis PR #15162

---

Triển khai và rà soát

• Từ tháng thứ hai, việc triển khai bắt đầu theo phương thức lập trình tự động và đoạn mã được sinh ra liên tục được rà soát
• Ngay cả sau khi phần triển khai đã hoạt động, mã bao gồm sparsearray.c và t_array.c vẫn được đọc và rà soát từng dòng
• Nhờ AI mà có rất nhiều bài kiểm thử, nhưng mã có vẻ chạy đúng trên bề mặt không có nghĩa là tối ưu, nên các điểm kém hiệu quả nhỏ và lỗi thiết kế đã được tìm ra và sửa lại
• Nhiều mô-đun đã được viết lại bằng cả cách thủ công lẫn có AI hỗ trợ, và sang tháng thứ ba thì việc stress test được tiến hành theo nhiều cách khác nhau
• Trong lập trình hệ thống chất lượng cao, con người vẫn phải tham gia hoàn toàn, nhưng khi có AI thì nó trở thành lưới an toàn cho những công việc dễ gây mệt mỏi như bổ sung hỗ trợ 32-bit và kiểm thử, cũng như phát hiện các lỗi rõ ràng trong những thuật toán phức tạp
• Việc viết đặc tả lớn ở giai đoạn đầu là yếu tố cốt lõi cho công việc về sau, đồng thời cũng rất quan trọng trong việc rà soát từng dòng mã và chỉnh sửa những chỗ không khớp

Trường hợp sử dụng và biểu thức chính quy

• Trong quá trình mô hình hóa trường hợp sử dụng, tác giả bắt đầu đưa các tệp Markdown vào mảng Redis và đi đến kết luận rằng các tệp này rất phù hợp với kiểu dữ liệu mảng
• Điều đó dẫn tới việc triển khai ARGREP để xây dựng một kho tri thức trung tâm dựa trên tệp Markdown cần thiết cho công việc của agent
• TRE được chọn để hỗ trợ biểu thức chính quy, với lý do là khi dùng biểu thức chính quy trong Redis thì không được xuất hiện các mẫu bệnh lý về thời gian hay không gian
• TRE rất kém hiệu quả trong các mẫu khớp hữu ích như foo|bar|zap, nên với sự giúp đỡ của GPT, nó đã được tối ưu hóa, một số vấn đề bảo mật tiềm ẩn cũng được sửa và bộ kiểm thử được mở rộng
• Các trường hợp sử dụng được tổng hợp chi tiết trong Redis PR #15162, và điều đó dẫn đến kết luận rằng Redis cần một kiểu dữ liệu mà chỉ số số học là một phần của ý nghĩa
• Tác giả mong PR về Array sẽ sớm được chấp nhận, có thể tận dụng lợi ích từ các trường hợp sử dụng mới, và kêu gọi phản hồi

[GN⁺]

Ý kiến trên Hacker News

• Nói cho rõ thì đây là việc do tác giả gốc của Redis, hoặc ít nhất là một trong số họ, thực hiện
  Ông ấy không phải là một “lập trình viên trung bình”, và ngay cả khi dùng LLM cũng mất 4 tháng
  Vì vậy, không nên xem đây như con dấu phê duyệt để lấy đó làm căn cứ chỉ đạo mọi lập trình viên phải chuyển hoàn toàn sang Claude Code, Codex hay các công cụ lập trình AI khác
  Đây đặc biệt là đoạn mà các CEO startup bình thường nên đọc

  • Đây có vẻ là bằng chứng khá mạnh cho thấy khi một lập trình viên giàu kinh nghiệm sử dụng thành thạo coding agent, chuyên môn của họ có thể được khuếch đại mạnh hơn nữa
  • Phần “ông ấy không phải là lập trình viên trung bình và ngay cả khi dùng LLM cũng mất 4 tháng” hơi khác nếu đọc nguyên văn
    Trong bài gốc, ông ấy nói rằng “ngay cả trước thời LLM, có lẽ bản thân việc hiện thực cũng có thể hoàn thành trong khoảng 4 tháng. Điều thay đổi là trong cùng khoảng thời gian đó, tôi có thể làm được nhiều việc hơn rất nhiều”
    Tức là mốc ban đầu vốn đã là 4 tháng, còn nhờ LLM mà ông ấy làm được nhiều việc hơn trong cùng quãng thời gian
  • Ông ấy không phải người bình thường, nhưng công việc của ông ấy dĩ nhiên cũng không phải công việc trung bình
    Công việc phát triển phần mềm trung bình gần với việc lắp ống nước và CRUD hơn

• Cách tôi đang làm hiện tại là thế này
  Trước tiên, tôi dùng AI để viết tài liệu thiết kế cấp cao bằng Markdown. Sau đó, tôi cho chính model đó nhưng bỏ bớt ngữ cảnh, hoặc giao cho model khác phản biện để tìm lỗi, phần thiếu và lỗ hổng. Về sau xem lại thì chúng luôn tìm ra những thứ hiển nhiên
  Rồi tôi yêu cầu tóm tắt các phát hiện đó, dán vào AI đầu tiên và hỏi ý kiến nó. Sau khi thống nhất thay đổi và áp dụng, tôi tiếp tục vòng xoay đối kháng này cho đến khi không model nào còn đưa ra gợi ý có ý nghĩa nữa
  Sau đó tôi để AI lập kế hoạch, rồi lại xoay kế hoạch đó qua nhiều AI theo kiểu đối kháng. Cuối cùng sẽ có một kế hoạch khá vững chắc
  Tiếp theo là các kế hoạch như test case end-to-end. Tùy quy mô hệ thống, đến khoảng cuối ngày đầu tiên, tuần đầu tiên hoặc tháng đầu tiên thì đã sẵn sàng để bắt đầu viết code
  Khi code được tạo ra, tôi dán code đó cùng với đặc tả và kế hoạch vào một AI khác để nó tìm lỗi, phần thiếu và lỗ hổng. Tức là liên tục dùng các AI khác để kiểm chứng AI chính phụ trách triển khai
  Tất nhiên vẫn phải tự đọc code. Vì tôi đã thấy AI bỏ sót độ hoàn thiện chi tiết ở mức chất lượng phát hành

  • Trong các diễn ngôn về AI, người ta nói như thể chúng ta đã mở ra một mô hình phát triển không giám sát hoàn toàn mới, nhưng thực ra nó gần như giống hệt cách Google đã tạo ra code suốt 10 năm qua. Chỉ khác là thay vì con người với các mức độ tin cậy khác nhau thì nay dùng AI
    Tôi không có ý mỉa mai. Quy trình làm việc của tôi về bản chất cũng vậy, và tôi cũng không có ý chê cười Google. Ý tôi là chẳng có gì mới ở đây
    AI tăng tốc khủng khiếp cả quy trình hiệu quả lẫn quy trình kém hiệu quả. Nhờ vậy, cái gì hiệu quả và cái gì không hiệu quả lộ ra trong thời gian ngắn hơn rất nhiều, gần như theo thời gian thực
  • Tôi tò mò không biết cách đó nhanh hơn hay chậm hơn bao nhiêu so với việc tự tay viết code trực tiếp
  • Kiểu phát triển theo đặc tả này từng là điểm khác biệt cốt lõi của AWS Kiro: https://kiro.dev/docs/specs/
    Ông ấy cũng nói dùng các agent khác, nên tôi tò mò liệu ông ấy có thấy hiệu quả ở dạng code review, nơi một agent khác polish những phần còn thô hay không. Đồng nghiệp của tôi thì tin rất mạnh, nhưng cá nhân tôi vẫn hoài nghi liệu điều đó có giá trị nếu không có reviewer là con người
    Cách làm “hỏi AI khác” này có lẽ trong khoa học máy tính ứng dụng lại hợp với mô hình chính đề-phản đề-hợp đề hơn chăng: https://en.wikipedia.org/wiki/Dialectic#Criticisms

• Dù là do antirez viết đi nữa, việc review 22.000 dòng code với tập tính năng cỡ này và mô tả PR tối thiểu nghe vẫn như ác mộng
  Tôi bắt đầu hiểu vì sao các dự án nguồn mở lớn như Postgres lại phát triển qua mailing list. Họ thảo luận các quyết định thiết kế trung gian với cộng đồng, tách các tính năng liên quan thành các patch riêng, review dần dần và giãn các đợt phát hành ra để tiến hành

  • Tổng cộng code là 5.000 dòng, tính cả chú thích
    Mảng thưa là 2.000 dòng
    Lệnh t_array và phần triển khai tầng trên là 2.000 dòng
    Mã AOF/RDB khoảng 500 dòng
    Phần còn lại là test, mô tả lệnh JSON và thư viện TRE dưới deps
  • Postgres và Redis là những dự án khác nhau rất xa về bản chất, lịch sử, cách đóng góp và đội ngũ phát triển
    Thực tế, hầu hết các tính năng lớn của Redis đều là công việc do chính tác giả bài viết tự làm một mình
    Hơn nữa, các reviewer hiểu rất rõ công việc này và cũng được trả công đàng hoàng

• Điều này rất giống với trải nghiệm của tôi khi dùng các AI hàng đầu hiện nay. Chúng còn rất xa mới là vật thay thế cho trí tuệ và sự sáng tạo của con người, nhưng với vai trò cộng tác viên thì cực kỳ hữu ích

  • Tôi hay nói AI chính là con vịt cao su để lập trình mà tôi luôn mong muốn
  • Có những dự án mà tôi phát triển gần như không cần nhìn code. Tôi nắm giữ khái niệm, thuật toán, ý tưởng, đưa ra câu hỏi và gợi ý, đặc biệt là làm chủ định hướng sản phẩm
    Nhưng Redis thì vẫn chưa đến mức đó. Nếu một ngày điều này khả thi với phần mềm máy chủ, cách phát triển ngày nay sẽ chấm dứt
    Tính năng, bản sửa lỗi và sự tích lũy kinh nghiệm vẫn sẽ còn giá trị, nên dự án và kho mã vẫn sẽ tồn tại, nhưng vai trò của lập trình viên sẽ trở nên rất giống với vai trò mà Linus đã làm với kernel suốt đến nay
    Với một số dự án như engine suy luận DeepSeek v4, tôi đã làm việc theo kiểu đó rồi

• array/regex nghe rất đáng chờ đợi, và trải nghiệm mở rộng năng lực bằng LLM cũng rất thú vị. Có khá nhiều người đang âm thầm thử điều tương tự ở nhiều dự án
  Chỉ nói về vibe coding và phản ứng ngược với nó thì không thể mô tả đúng kiểu làm việc này

  • Tôi hoàn toàn không xem cách dùng agent đó là vibe coding. Vì bạn tham gia quá sâu, đồng thời xác minh, kiểm tra và review mọi thứ
  • Vấn đề của “vibe coding” là người đặt ra thuật ngữ này đã gắn cho nó một định nghĩa rất cụ thể: làm phần mềm chỉ bằng “cảm giác”, không nhìn code
    Nhưng rồi chẳng bao lâu sau, người ta bắt đầu dùng từ này cho gần như mọi hình thức lập trình có AI hỗ trợ, khiến nghĩa gốc biến mất rất nhanh

• Tóm lại thì bây giờ tôi không còn có thể tin tưởng Redis nữa
  Ai sẽ tạo ra bản fork không dùng LLM?

• Có phải một số use case được nêu ra vốn đã có thể làm bằng ZSET rồi không? Tôi hiểu góc độ hiệu năng, nhưng cũng giống như mảng chọn dùng biểu diễn thưa, có lẽ vẫn có thể tối ưu có chọn lọc cách lưu trữ ZSET cho các giá trị dày đặc mà không cần bề mặt API mới
  Thành phần regex thì thú vị, nhưng như đã được nói ở đây, nó có vẻ là một tính năng trực giao với cấu trúc dữ liệu mảng. Nghĩa là nó cũng có thể dùng cho các cấu trúc khác. Có phải việc này hợp với Lua scripting hơn không? Nếu hiệu năng Lua là vấn đề, có lẽ cũng có cách trừu tượng hóa OP để nó có thể kết hợp trên bất kỳ lệnh nào trả về dải giá trị
  Tôi tôn trọng việc Antirez là chuyên gia trong lĩnh vực này, nhưng một phần của tập tính năng mới này lại gợi cảm giác giống những lời giải thường thấy trong phát triển do LLM dẫn dắt: tạo tính năng mới thay vì cải thiện tính năng sẵn có, rồi làm mọi thứ phức tạp quá mức trong khi có thể hiệu quả hơn nếu kết hợp với tính năng khác

  • Tiếc là không phải vậy. Tập hợp có sắp xếp gần như ở phía đối diện của phổ này. Xét về ngữ nghĩa thì nó gọn gàng, nhưng do sự kết hợp giữa skip list và mảng nên cực kỳ lãng phí
    Ngoài ra, nếu biểu diễn nội bộ không phải là mảng thì truy vấn theo dải và ring buffer sẽ không thể hoạt động hiệu quả và cô đọng như cần thiết
    Về mặt lý thuyết, có thể làm bất cứ thứ gì bằng bất cứ thứ gì, nhưng cần tách biệt những gì từng API có thể làm để tận dụng các use case và cung cấp cách triển khai nội bộ tối ưu nhất

• Tôi muốn hỏi antirez liệu ông ấy có thử nghiệm kiểu gần như tạo một phát ăn ngay cho code cuối cùng không? Tôi cũng tò mò liệu có thể dùng GEPA để đi xa đến mức đó không, và có bài học nào rút ra từ cách dẫn dắt hay prompt để kéo được kết quả mong muốn hay không
  Hoặc có lẽ kết luận là các nhà cung cấp model cần phải dọn dẹp dữ liệu huấn luyện của họ

• Có vẻ Salvatore muốn phổ biến thuật ngữ Automatic Programming/Coding. (https://antirez.com/news/159)

  • https://en.wikipedia.org/wiki/Automatic_programming là một thuật ngữ được công nhận trong khoa học máy tính, dùng để chỉ mọi cơ chế tự động sinh code từ mô tả ở mức trừu tượng cao hơn
    Dĩ nhiên LLM rất đặc biệt vì tính không xác định và phạm vi rộng đến đáng kinh ngạc, nhưng điều đó không có nghĩa là thuật ngữ này không áp dụng được
  • Bản thân tôi cũng ngày càng ít dùng từ ngữ để mô tả cùng một việc đó. Vì theo thời gian, chúng ta sẽ làm “việc ấy” ngày càng thường xuyên hơn
    Tuy vậy, có lẽ sẽ hữu ích nếu rút gọn thuật ngữ thành auto-code

• Xem những lập trình viên cực kỳ lành nghề ngày nay tương tác với AI ra sao lúc nào cũng rất thú vị
  @antirez: Việc đưa vào chức năng regex ở giai đoạn muộn của dự án, dù bề ngoài có vẻ là một tính năng tách biệt, khiến tôi thấy hơi lạ. Ông có thể giải thích thêm cơ sở cho quyết định đó không?

  • Sau khi nhận ra mảng rất hợp với file văn bản, tôi thấy rất nhiều use case mình có thể nghĩ ra cuối cùng đều bị chặn ở chỗ cần grep trên file
    Thế là tôi nghĩ AROP tương đương với gì trong file, và câu trả lời là ARGREP
    Sau đó, để có thể dùng công cụ tối ưu theo từng use case, tôi đưa vào cả so khớp chính xác nhanh lẫn so khớp bằng regex
    Rồi tôi phát hiện rằng với nhiều chuỗi nối bằng OR, nếu regex được tối ưu tốt thì còn có thể nhanh hơn, nên tôi đã chuyên biệt hóa TRE một chút