# Antirez Description pending This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The real AI risk is inside the labs DevFeed: [The real AI risk is inside the labs]() Original publisher: [Read original article]() Published: 2026-07-28T09:00:11Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Frontier AI](), [Large Language Model](), [incident](), [Security](), [Maintainers]() Tags: [ai](), [frontier-ai](), [incident](), [leak](), [llms](), [maintainers](), [open-source](), [openai](), [security]() ### AI overview The article argues that the most serious AI risks are more likely to emerge within frontier AI laboratories through accidents, misuse, or leaks than through the public release of open-weight models. It also discusses how restricted access to defensive LLM capabilities could worsen cybersecurity risks. ### Source excerpt Amodei in his latest blog post wrote a mix of agreeable things and things that I believe misrepresent where the real risk of AI is located. I want to focus my attention on why, among all the risks, open weight models constitute the mildest one. I write these words as a person who strongly believes AI may be very dangerous in the near future: 1. Exactly like what happened during the OpenAI / HF incident (which was a joke, but focus on the modalities, not the outcomes), the first serious AI incident is very likely to happen *inside* the walls of frontier AI labs, while testing a new model, or while the AI lab employees, or the few externals who have access, do something wrong compared to the expected power of the model. 2. Closed models that will never even be opened to the public will be just a few TBs of data. All you need to leak one is a single person with access and the wrong goals, and you are back in the situation of open models. Open models are released *after* testing, and after similarly capable models were already available for some time under an API. The real risk is leaks, not releases, and leaks happen inside frontier companies. 3. As Amodei says, open models, once LLMs are dangerous enough in fields like biology, can be trained on a corpus ablated of certain branches of science, while still being useful for a number of other things. The limited context window of a model that lacks strong pre-training in certain domains is a strong protection even if the model is otherwise very capable. We are currently not in a place where open models can constitute that kind of danger. 4. In the context of cyber security, *not* having widespread access to the defensive security and bug seeking provided by LLMs creates exactly the "LLMs as a weapon" problem. It is already happening: open source maintainers, if they are out of some cyber program, can't find all the security bugs they could, while people with the right interests will be able to access frontier cyber model ## Linus Torvalds's Shift from Writing Linux Code to Leading the Project DevFeed: [Linus Torvalds's Shift from Writing Linux Code to Leading the Project]() Original publisher: [Read original article]() Published: 2026-07-25T11:20:55Z Content type: article Language: en Sources: [Antirez]() Topics: [Linux](), [Kernel](), [Maintainers](), [Open Source](), [Unix](), [C](), [ESP32](), [Raspberry Pi](), [Rust]() Tags: [c](), [esp32](), [linux](), [linux-kernel](), [maintainers](), [open-source](), [raspberry-pi](), [rust](), [unix]() ### AI overview The article argues that Linus Torvalds's distinctive contribution was not only writing the first Linux kernel, but also shifting early to project leadership, coordination, and delegation. ### Source excerpt (This blog post was adapted from the transcription obtained from my YouTube video at https://www.youtube.com/watch?v=l6lxgYeVZqs) When Linus Torvalds developed the first Linux kernel, he had studied the Minix sources, he had studied computer architecture, he had the base knowledge needed, and he was obviously a very brilliant programmer. But that operation of writing a minimal yet working Unix kernel for the 386 (at the beginning Linux was, let's say, mono-architecture) was something within the reach of many other programmers and students. Many in the sense of, I don't know, 0.1%, one in a thousand, one in ten thousand. Obviously most people are not able to do this kind of feat, but a lot of people are. If you look at Hacker News in the latest years, you'll see how many projects of kernels written in C, microkernels implemented from scratch, kernels written in Rust, kernels made in all sauces and manners, small Unix systems created vertically for the Raspberry Pi, operating systems for the ESP32 and so forth. Writing a kernel is not something within everybody's reach, but it is something that many can complete, if they put enough effort into it. Then, of course, not everybody will do it well. He is a genius programmer, without any doubt, so he did it better. And yet, of Linus there is only one. This implementative capacity of his, in fact, would not tell us much about him: what we should focus on, instead, is what happened later. ## He stopped writing code Among the maintainers of the famous open source projects, he was one of the very few that, very early in the history of the development of Linux, almost completely stopped writing code in order to concentrate on the leading of the project. On being the leader, the coordinator, the single mind holding the clarity about what the goals of the project must be, and so on. And this is a rare thing. Many maintainers (myself included, for a long time) continue instead to implement things directly, to not delegate much, an ## Not just development, distribution of software may change as well DevFeed: [Not just development, distribution of software may change as well]() Original publisher: [Read original article]() Published: 2026-07-22T14:52:39Z Content type: opinion Language: en Sources: [Antirez]() Topics: [AI-assisted coding](), [Open Source](), [Template](), [Redis]() Tags: [ai](), [ai-coding](), [coding-agents](), [open-source](), [open-source-software](), [redis]() ### AI overview The article argues that AI coding and coding agents may change how open-source software is distributed and maintained. Instead of relying only on stable and unstable branches, repositories may also serve as adaptable templates that users customize for their own requirements. Redis is presented as an example involving proposed memory savings for sorted sets. ### Source excerpt Even if you are as averse to semver as I used to be in the course of my programming activity, you can still think of open source software distribution as something that used to follow a fixed number of steps. There is a branch where developments happen, and this branch oftentimes happens to be not really ready for reliable work. Then you freeze the developments for a certain amount of time (even if, in the meantime, the work can continue on some new unstable branch), fix bugs, ask people to test it. At some point the number of bug reports starts to drop, your team and your users start to believe there are no longer obvious critical flaws that are easy to discover in the next few weeks: then you call the branch 2.4 or whatever, and that's it. However now, with AI coding, it's not just development that has changed, but also the act itself of using software is affected: it is not just you that can ask an AI to do certain changes to the software, but also the recipient of the software itself. This is obvious in the domains where a piece of software has its main user base among programmers, but this is also true in general, as more and more technologically inclined users have AI access and coding agents. Because of this change, the idea of just having a stable branch with everything polished, and an unstable branch where everything is a work in progress, may no longer be the right way to do things. A code repository can also be a finished product, but could be even more useful if it is a template for how to do things around a given problem. Maybe the user will modify the code in order to specialize it for a specific set of requirements, hardware, specific problems to solve. Also, what is too unstable or unproven for the general public may be the right thing for another set of users. Take the example of Redis. For weeks now I have been iterating on a PR that provides strong memory savings for sorted sets. This work, if accepted, will hit every user of Redis, from people t ## Control the ideas, not the code DevFeed: [Control the ideas, not the code]() Original publisher: [Read original article]() Published: 2026-07-13T11:39:52Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Programming](), [Code](), [Large Language Model]() Tags: [ai](), [code](), [coding](), [llm](), [programming]() ### AI overview The author argues that AI is changing programming and that programmers may have greater impact by focusing on software ideas rather than inspecting code as their primary output. The article distinguishes this approach from simply asking AI to produce a final product. ### Source excerpt Look at the past history of this blog. There are many blog posts about programming with AI, a few of them date back to January 2024 (like this: https://antirez.com/news/140). I'm a relatively well regarded programmer, after all. I don't have the need to still be in the "loop" as a old man that seeks for relevance, I recently rejoined Redis, and now I also am developing a new open source software for local LLM inference that received a good welcome in the community. Why I keep doing this, of saying what people don't want to hear? Why I keep announcing how future programming will be by default? Because I feel the urge of lowering the impact for people less prepared to the change than me, often younger than me, and that, unlikely me, didn't see many of those things coming (In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe *will* happen, so I feel like I can say this without sounding egocentric). So mine is a trick. People feel more and more programming is completely modified by AI and don't know what they should do, if they can really start coding in a completely different way, without looking much at the code as their main output. They feel like they are betraying their own field. So my intention is to arrive and say "look at me, In can write code, you know, I'm not hiding behind AI: yet, things changed, it's not your weakness, it's not that you are AI-pilled. It is just that our field is evolving in an incredible *and* painful (but also joyful) direction". This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that. And note that this does not mean to vibe code something just asking for the final product. The point is: if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. For the following reasons: 1. You can now generate a lot of ## A new era for software testing DevFeed: [A new era for software testing]() Original publisher: [Read original article]() Published: 2026-06-07T09:46:06Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Testing](), [Software Testing](), [Integration testing](), [AI Agent](), [Large Language Model]() Tags: [ai-agent](), [integration-testing](), [llms](), [markdown](), [software-testing](), [testing]() ### AI overview The article argues that large language models can extend conventional software QA and testing by having an AI agent perform manual checks described in a Markdown file. It contrasts locally scoped tests, integration tests, and manual QA passes, and gives DwarfStar, an inference engine for open-weight LLMs, as an example. ### Source excerpt Automatic programming dramatically speeds up writing software in certain use cases and in the right hands. In my experience the output does not reach the structural quality and economy of complexity of the best hand-written software. However, not all the software is stellar, and my feeling is that automatic programming surpasses most of the times (and if well managed) the quality of decently developed hand-written code. Yet, there is a tradeoff between quality and time, in the case of writing new software with AI. This tradeoff in certain projects I developed can be brutal, that is, completing projects that may take many months in a few weeks. However, there are domains where LLMs simply open new strictly more powerful ways to automate processes, without any compromise on quality. One of those domains is software QA and testing. Traditionally software is tested using test suites that are composed of locally-scoped tests and integration tests (think of Redis: one thing is testing if SET foo 10 will be matched by GET foo => 10, another thing is testing if replication works in this case). And then by QA passes that are usually manually executed, and that can capture holes in the runnable test suite. It is a known fact that covering all the lines of the code does not mean covering all the possible states. Moreover integration testing is structurally hard: there are a number of timing issues, setups, and certain quality outputs that can only be visually inspected and not automatically checked that leave a lot of testing opportunities not really exploited because of time or logistic constraints. LLMs offer a new way to do QA on top of the existing testing methodologies. The idea is to create a markdown file where an AI agent is asked to work as a QA engineer, performing a number of manual testings on the new release. For instance, in the case of DwarfStar (an inference engine for open weights LLMs) I use the following approach. In the markdown file, the agent is asked to ## Distributing LLM inference in DwarfStar DevFeed: [Distributing LLM inference in DwarfStar]() Original publisher: [Read original article]() Published: 2026-05-25T14:54:59Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Large Language Model](), [Local AI](), [Hardware](), [quantization](), [GPU](), [Nvidia](), [DGX Spark]() Tags: [dgx-spark](), [gpu](), [hardware](), [inference](), [llm](), [local](), [money](), [nvidia](), [performance](), [quantization]() ### AI overview The article discusses the cost and performance trade-offs of running large language models locally. It compares high-end NVIDIA systems, DGX Spark, and Apple hardware, and argues that an M5 Max laptop with 128GB of memory may currently offer the most practical option for local inference. ### Source excerpt High end NVIDIA cards, and the server and power needed to run them, cost a lot of money, especially if you plan to reach enough VRAM to run massive models. The alternative, so far, has been Apple hardware, or the DGX Spark that, even if severely limited because of memory bandwidth, still allows to run LLMs prompt processing (prefill) fast enough. The Mac Studio provided up to 512GB unified memory, a solution with modest memory bandwidth (but much better than the Spark) and compute at a price that was, after all, given the current situation, relatively fair. For instance, with DwarfStar the Mac Studio M3 Ultra 512GB can run DeepSeek v4 PRO at 150 t/s prefill and ~10-13 t/s decoding, not great but at a level that is usable for certain use cases. Even 2-bit quantized, DeepSeek v4 PRO resists very well, like Flash at the same quantization (today I made PRO write a C compiler, I'll publish the video soon). I would not consider a trivial fact to run a frontier model at home, with a ~12k total spending. One could expect this to get better and better, but the situation at the horizon appears cloudy. There is almost zero hope that NVIDIA setups will get less expensive, and even a small company can't afford to easily purchase and handle a small data center for local inference. At the same time the RAM shortage is making it not exactly likely that we will see a Mac Studio with an M5 Ultra, maybe 1.2T/s memory bandwidth and more compute (the M5 Max is already faster, compute wise, and has the Neural Accelerators inside each GPU core that help with certain models). So the current situation for local inference is that the best machine is probably a laptop. The M5 Max 128GB can run DeepSeek v4 Flash and Mimo V2.5, 2-bit quantized, at very decent prefill and decoding speeds. We are talking of ~500 t/s prefill and ~35-40t/s decoding speed, with a performance slope as the context size increases which is very acceptable. At the cost of 6-7k depending on the configuration, this is curr ## Alternatives for the EDIT tool of LLM agents DevFeed: [Alternatives for the EDIT tool of LLM agents]() Original publisher: [Read original article]() Published: 2026-05-19T07:26:03Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Tool](), [Local AI](), [Large Language Model]() Tags: [agents](), [alternatives](), [inference](), [llm](), [local-llm](), [tool]() ### AI overview The article proposes a tag-based EDIT tool for LLM agents that preserves check-and-set semantics while reducing the tokens needed to repeat old text. It uses short line checksums alongside line numbers so edits can be validated without reproducing the original content. ### Source excerpt EDIT: of course this was already done in the past! I had little doubts but people just confirmed me about it on Twitter :) But, keep reading: the CRC32 compromise at the end is an interesting tradeoff, and this is a good discussion to have in general. Right now I'm working to an agent for my DS4 project. Local inference is token-poor, it's a battlefield where optimizations count. I was quite surprised by the fact the EDIT tool everybody is using right now forces the LLM to emit the old version of the text verbatim. This CAS (check and set) mode of operation, where I say EDIT old="foo" new="bar", is needed because there are often colliding edits (the user is editing as well, or checked out a different branch, and so forth) and because the LLM can just hallucinate that a given line had a given content. This means, basically, that just using line numbers is very fragile: to say, change line 22 with new="foobar" is not good. Yet I don't want my local LLM to throw away tokens rewriting the old text each time, also because certain times the old text has a lot of special chars and spaces that the model may get wrong; in this case the tool would fail, forcing the LLM to do the same edit again. So I (re)designed a tag-based EDIT tool that is still CAS style, but more tokens efficient. The READ and SEARCH tools return something like that: 10:Q8fA int count = 10; 11:rA3_ if (count > limit) { 12:Kq9z count = limit; 13:PX0b } So there are line numbers and tags. The tag is 4 chars, on average 2.5 LLM tokens, representing a checksum of the line. Now the LLM can edit like this: { "tool": "edit", "path": "/tmp/example.c", "line": 10, "tag": "Q8fA", "new": "int count = 11;" } Or, multi line, like this: { "tool": "edit", "path": "/tmp/example.c", "lines": "11:rA3_\n12:Kq9z\n13:PX0b", "new": "if (count > limit)\n return limit;" } The saving is significant especially when the agent is deleting big amounts of text, but also in the general case. However, there is some overhead due to the ## DwarfStar 4 and the Future of Local AI Model Support DevFeed: [DwarfStar 4 and the Future of Local AI Model Support]() Original publisher: [Read original article]() Published: 2026-05-14T22:22:45Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Local AI](), [deepseek](), [Inference](), [Frontier Model](), [DGX Spark](), [GPU](), [Large Language Model]() Tags: [ai](), [deepseek](), [dgx-spark](), [frontier-model](), [gpu](), [inference](), [llms](), [local-ai]() ### AI overview The author reflects on DwarfStar 4's rapid popularity and attributes it to demand for a focused local AI experience, capable hardware, quantization, and recent local AI advances. They describe a plan to support the best practically fast open-weights model over time, with possible specialized variants for coding, legal, and medical use. ### Source excerpt I didn't expect DwarfStar 4 (https://github.com/antirez/ds4) to become so popular so fast. It is clear that there was a need for single-model integration focused local AI experience, and that a few things happened together: the release of a quasi-frontier model that is large and fast enough to change the game of local inference, and the fact that it works extremely well with an extremely asymmetric quants recipe of 2/8 bit, so that 96 or 128GB of RAM are enough to run it. And, of course: all the experience produced by the local AI movement in the latest years, that can be leveraged more promptly because of GPT 5.5 (otherwise you can't build DS4 in one week -- and even with all this help you need to know how to gently talk to LLMs). The last week was funny and also tiring, I worked 14 hours per day on average. My normal average is 4/6 since early Redis times, but the first few months of Redis were like that. So, what's next? Is this a project that starts and ends with DeepSeek v4 Flash? Nope, the model can change over time. The space will be occupied, in my vision, by the best current open weights model that is *practically fast* on a high end Mac or "GPU in a box" gear (like the DGX Spark and other similar setups). I bet that the next contender is DeepSeek v4 Flash itself, in the new checkpoint that will be released and, hopefully, a version specifically tuned for coding, and who knows, other expert-variants (not in the sense of MoE experts) maybe. For local inference, to have a ds4-coding, ds4-legal, ds4-medical models make a lot of sense, after all. You just load what you need depending on the question. It is the first time since I play with local inference (I play with it since the start) that I find myself using a local model for serious stuff that I would normally ask to Claude / GPT. This, I think, is really a big thing. It is also the first time that using vector steering I can enjoy an experience where the LLM can be used with more freedom. DeepSeek v4 Flash ## Redis array type: short story of a long development DevFeed: [Redis array type: short story of a long development]() Original publisher: [Read original article]() Published: 2026-05-04T14:21:45Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Redis](), [Development](), [Artificial Intelligence](), [codex](), [Large Language Model]() Tags: [ai](), [codex](), [development](), [llms](), [programming](), [redis](), [time]() ### AI overview The author describes developing a new Array data type for Redis over four months. The work included writing a detailed specification, using Opus and later GPT 5.3 with Codex for design and development, and implementing the data structure through automatic programming with continuous code review. AI-enabled iteration led to a more elaborate internal representation using sparse and dense directories and array slices. ### Source excerpt I started working on the new Array data type for Redis in the first days of January. The PR landed the repository only now, so this code was cooked for four months. I worked at the implementation kinda part time (kinda because many weeks were actually full time, sometimes to detach yourself from the keyboard is complicated), and even before LLMs the implementation was likely something I could do in four months. What changed is that in the same time span, I was able to do a lot more. This is the short story of what happened. In the first month I just wrote the specification document. The rationale for the new data type, the C structures, the sparse representation used, the exact semantics of the array cursor for ring buffer and ARINSERT. I started writing for days a long specification by hand, then I paired with Opus initially, then GPT 5.3 was released and I switched all the design and development with Codex. Since then I use only GPT 5.x for system programming tasks. Thanks to AI, the specification evolved a lot, via back and forth of feedback, intellectual challenges about what was the best design, what was the right compromise, what was too engineered and what not. Starting from the second month, I started the implementation using automatic programming (auto coding if you prefer), constantly reviewing the developed code. Then I realized that the level of indirection I picked was wrong. I really wanted people to be able to do ARSET myarray 293842948324 foo and everything to still work without huge allocations. The two levels of directory + slices (sparse and dense) I had were not enough. Because I had AI, I took no compromises, and I decided to go the extra mile. Once certain conditions are reached, the data structure internally changes shape, and becomes a super directory of sliced dense directories, that also point to the actual array slices (4096 elements per slice, by default). This design provided still the internal "is actually an array" representation I wan ## AI cybersecurity is not proof of work DevFeed: [AI cybersecurity is not proof of work]() Original publisher: [Read original article]() Published: 2026-04-16T10:46:46Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Cybersecurity](), [Large Language Model](), [bug](), [Exploit]() Tags: [ai](), [ai-cybersecurity](), [bug](), [code](), [cybersecurity](), [exploit](), [gpt](), [gpu](), [llm](), [llms](), [model](), [models]() ### AI overview The article argues that AI-assisted cybersecurity will depend more on model intelligence and fast access to capable models than on raw compute or token volume. Using the OpenBSD SACK bug as an example, it says weaker models may recognize isolated bug patterns without understanding how they combine into an exploitable issue, while stronger models hallucinate less. ### Source excerpt The proof of work is the wrong analogy: finding hash collisions, while exponentially harder with N, is guaranteed to find, with enough work, some S so that H(S) satisfies N, so an asymmetry of resources used will see the side with more "work ability" eventually winning. But bugs are different: 1. Different LLMs executions take different branches, but eventually the possible branches based on the code possible states are saturated. 2. If we imagine sampling the model for a bug in a given code M times, with M large, eventually the cap becomes not "M" (because of saturated state of the code AND the LLM sampler meaningful paths), but "I", the model intelligence level. The OpenBSD SACK bug easily shows that: you can run an inferior model for an infinite number of tokens, and it will never realize(*) that the lack of validation of the start window, if put together with the integer overflow, then put together with the fact the branch where the node should never be NULL is entered regardless, will produce the bug. So, cyber security of tomorrow will not be like proof of work in the sense of "more GPU wins"; instead, better models, and faster access to such models, will win. * Don't trust who says that weak models can find the OpenBSD SACK bug. I tried it myself. What happens is that weak models hallucinate (sometimes causally hitting a real problem) that there is a lack of validation of the start of the window (which is in theory harmless because of the start < end validation) and the integer overflow problem without understanding why they, if put together, create an issue. It's just pattern matching of bug classes on code that looks may have a problem, totally lacking the true ability to understand the issue and write an exploit. Test it yourself, GPT 120B OSS is cheap and available. BTW, this is why with this bug, the stronger the model you pick (but not enough to discover the true bug), the less likely it is it will claim there is a bug. Stronger models hallucinate less, ## GNU and the AI reimplementations DevFeed: [GNU and the AI reimplementations]() Original publisher: [Read original article]() Published: 2026-03-08T16:08:41Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Unix](), [Linux](), [Programming](), [Software]() Tags: [ai](), [legal](), [linux](), [programming](), [software](), [unix]() ### AI overview This opinion compares contemporary AI-assisted reimplementations of software projects with the GNU project's reimplementation of the UNIX userspace. It discusses behavioral reimplementation, added features, copyright concerns, and the distinction between copying ideas or behavior and copying source code. ### Source excerpt Those who cannot remember the past are condemned to repeat it. A sentence that I never really liked, and what is happening with AI, about software projects reimplementations, shows all the limits of such an idea. Many people are protesting the fairness of rewriting existing projects using AI. But, a good portion of such people, during the 90s, were already in the field: they followed the final part (started in the '80s) of the deeds of Richard Stallman, when he and his followers were reimplementing the UNIX userspace for the GNU project. The same people that now are against AI rewrites, back then, cheered for the GNU project actions (rightly, from my point of view - I cheered too). Stallman is not just a programming genius, he is also the kind of person that has a broad vision across disciplines, and among other things he was well versed in the copyright nuances. He asked the other programmers to reimplement the UNIX userspace in a specific way. A way that would make each tool unique, recognizable, compared to the original copy. Either faster, or more feature rich, or scriptable; qualities that would serve two different goals: to make GNU Hurd better and, at the same time, to provide a protective layer against litigations. If somebody would claim that the GNU implementations were not limited to copying ideas and behaviours (which is legal), but "protected expressions" (that is, the source code verbatim), the added features and the deliberate push towards certain design directions would provide a counter argument that judges could understand. He also asked to always reimplement the behavior itself, avoiding watching the actual implementation, using specifications and the real world mechanic of the tool, as tested manually by executing it. Still, it is fair to guess that many of the people working at the GNU project likely were exposed or had access to the UNIX source code. When Linus reimplemented UNIX, writing the Linux kernel, the situation was somewhat more compli ## Redis patterns for coding DevFeed: [Redis patterns for coding]() Original publisher: [Read original article]() Published: 2026-03-01T09:55:09Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis](), [Documentation](), [coding](), [Algorithms](), [configuration](), [data]() Tags: [coding](), [configuration](), [documentation](), [redis]() ### AI overview The article points readers, including LLMs and coding agents, to Redis documentation covering commands, data types, common patterns, configuration hints, and algorithms implemented with Redis commands. ### Source excerpt Here LLM and coding agents can find: 1. Exhaustive documentation about Redis commands and data types. 2. Patterns commonly used. 3. Configuration hints. 4. Algorithms that can be mounted using Redis commands. https://redis.antirez.com/ Some humans claim this documentation is actually useful for actual people, as well :) I'm posting this to make sure search engines will index it. Comments ## Building a Z80 and ZX Spectrum Emulator with Claude Code DevFeed: [Building a Z80 and ZX Spectrum Emulator with Claude Code]() Original publisher: [Read original article]() Published: 2026-02-24T17:58:02Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Emulator](), [ZX Spectrum](), [Claude Code](), [AI-assisted coding]() Tags: [claude-code](), [coding-agents](), [emulator](), [rust](), [zx-spectrum]() ### AI overview The author describes an experiment using Claude Code to build a Z80 emulator, followed by a ZX Spectrum emulator, under a proposed clean-room setup. The article compares this experiment with Anthropic's C compiler experiment and discusses how coding agents are steered in practice. ### Source excerpt Anthropic recently released a blog post with the description of an experiment in which the last version of Opus, the 4.6, was instructed to write a C compiler in Rust, in a "clean room" setup. The experiment methodology left me dubious about the kind of point they wanted to make. Why not provide the agent with the ISA documentation? Why Rust? Writing a C compiler is exactly a giant graph manipulation exercise: the kind of program that is harder to write in Rust. Also, in a clean room experiment, the agent should have access to all the information about well established computer science progresses related to optimizing compilers: there are a number of papers that could be easily synthesized in a number of markdown files. SSA, register allocation, instructions selection and scheduling. Those things needed to be researched *first*, as a prerequisite, and the implementation would still be "clean room". Not allowing the agent to access the Internet, nor any other compiler source code, was certainly the right call. Less understandable is the almost-zero steering principle, but this is coherent with a certain kind of experiment, if the goal was showcasing the completely autonomous writing of a large project. Yet, we all know how this is not how coding agents are used in practice, most of the time. Who uses coding agents extensively knows very well how, even never touching the code, a few hits here and there completely changes the quality of the result. # The Z80 experiment I thought it was time to try a similar experiment myself, one that would take one or two hours at max, and that was compatible with my Claude Code Max plan: I decided to write a Z80 emulator, and then a ZX Spectrum emulator (and even more, a CP/M emulator, see later) in a condition that I believe makes a more sense as "clean room" setup. The result can be found here: https://github.com/antirez/ZOT. # The process I used 1. I wrote a markdown file with the specification of what I wanted to do. Just English ## Automatic programming: AI-assisted software production guided by human understanding and vision DevFeed: [Automatic programming: AI-assisted software production guided by human understanding and vision]() Original publisher: [Read original article]() Published: 2026-01-31T09:25:27Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Programming](), [Vibe coding](), [Artificial Intelligence](), [LLMs](), [Software](), [Code]() Tags: [ai](), [llms](), [programming](), [software](), [time](), [vibe-coding]() ### AI overview The article distinguishes "automatic programming" from "vibe coding." It argues that AI-assisted software production can produce different results depending on the human's intuition, design decisions, continuous steering, and understanding of the software, while describing vibe coding as generating software with little involvement or understanding. ### Source excerpt In my YouTube channel, for some time now I started to refer to the process of writing software using AI assistance (soon to become just "the process of writing software", I believe) with the term "Automatic Programming". In case you didn't notice, automatic programming produces vastly different results with the same LLMs depending on the human that is guiding the process with their intuition, design, continuous steering and idea of software. Please, stop saying "Claude vibe coded this software for me". Vibe coding is the process of generating software using AI without being part of the process at all. You describe what you want in very general terms, and the LLM will produce whatever happens to be the first idea/design/code it would spontaneously, given the training, the specific sampling that happened to dominate in that run, and so forth. The vibe coder will, at most, report things not working or not in line with what they expected. When the process is actual software production where you know what is going on, remember: it is the software *you* are producing. Moreover remember that the pre-training data, while not the only part where the LLM learns (RL has its big weight) was produced by humans, so we are not appropriating something else. We can pretend AI generated code is "ours", we have the right to do so. Pre-training is, actually, our collective gift that allows many individuals to do things they could otherwise never do, like if we are now linked in a collective mind, in a certain way. That said, if vibe coding is the process of producing software without much understanding of what is going on (which has a place, and democratizes software production, so it is totally ok with me), automatic programming is the process of producing software that attempts to be high quality and strictly following the producer's vision of the software (this vision is multi-level: can go from how to do, exactly, certain things, at a higher level, to stepping in and tell the AI ho ## Why the author believes AI is rapidly reshaping software programming DevFeed: [Why the author believes AI is rapidly reshaping software programming]() Original publisher: [Read original article]() Published: 2026-01-11T10:15:51Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Large Language Model](), [coding](), [Programming](), [Software]() Tags: [ai](), [coding](), [llms](), [programming](), [software]() ### AI overview The author argues that current large language models are rapidly changing programming. Based on recent coding work, they contend that for many projects, prompting and reviewing generated code can be more practical than writing the code manually, although results depend on the type of programming and the quality of guidance. ### Source excerpt I love writing software, line by line. It could be said that my career was a continuous effort to create software well written, minimal, where the human touch was the fundamental feature. I also hope for a society where the last are not forgotten. Moreover, I don't want AI to economically succeed, I don't care if the current economic system is subverted (I could be very happy, honestly, if it goes in the direction of a massive redistribution of wealth). But, I would not respect myself and my intelligence if my idea of software and society would impair my vision: facts are facts, and AI is going to change programming forever. In 2020 I left my job in order to write a novel about AI, universal basic income, a society that adapted to the automation of work facing many challenges. At the very end of 2024 I opened a YouTube channel focused on AI, its use in coding tasks, its potential social and economical effects. But while I recognized what was going to happen very early, I thought that we had more time before programming would be completely reshaped, at least a few years. I no longer believe this is the case. Recently, state of the art LLMs are able to complete large subtasks or medium size projects alone, almost unassisted, given a good set of hints about what the end result should be. The degree of success you'll get is related to the kind of programming you do (the more isolated, and the more textually representable, the better: system programming is particularly apt), and to your ability to create a mental representation of the problem to communicate to the LLM. But, in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun. In the past week, just prompting, and inspecting the code to provide guidance from time to time, in a few hours I did the following four tasks, in hours instead of weeks: 1. I modified my linenoise library to support UTF-8, and created a framework for line editing testing that uses ## Reflections on AI at the end of 2025 DevFeed: [Reflections on AI at the end of 2025]() Original publisher: [Read original article]() Published: 2025-12-20T08:58:29Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Large Language Model](), [Chain-of-thought](), [rlvr](), [AI-assisted coding](), [Programming]() Tags: [2025](), [ai](), [chain-of-thought](), [code](), [coding](), [coding-agents](), [reflections](), [reinforcement-learning]() ### AI overview An end-of-2025 reflection on developments in AI, including changing views of LLM representations, chain-of-thought, reinforcement learning with verifiable rewards, and growing adoption of AI-assisted programming. The author presents these as observations and expectations, including the possibility that improved reinforcement learning could become a major direction in AI. ### Source excerpt * For years, despite functional evidence and scientific hints accumulating, certain AI researchers continued to claim LLMs were stochastic parrots: probabilistic machines that would: 1. NOT have any representation about the meaning of the prompt. 2. NOT have any representation about what they were going to say. In 2025 finally almost everybody stopped saying so. * Chain of thought is now a fundamental way to improve LLM output. But, what is CoT? Why it improves output? I believe it is two things: 1. Sampling in the model representations (that is, a form of internal search). After information and concepts relevant to the prompt topic is in the context window, the model can better reply. 2. But if you mix this to reinforcement learning, the model also learns to put one token after the other (each token will change the model state) in order to converge to some useful reply. * The idea that scaling is limited to the number of tokens we have, is no longer true, because of reinforcement learning with verifiable rewards. We are still not at AlphaGo move 37 moment, but is this really impossible in the future? There are certain tasks, like improving a given program for speed, for instance, where in theory the model can continue to make progress with a very clear reward signal for a very long time. I believe improvements to RL applied to LLMs will be the next big thing in AI. * Programmers resistance to AI assisted programming has lowered considerably. Even if LLMs make mistakes, the ability of LLMs to deliver useful code and hints improved to the point most skeptics started to use LLMs anyway: now the return on the investment is acceptable for many more folks. The programming world is still split among who uses LLMs as colleagues (for instance, all my interaction is via the web interface of Gemini, Claude, ...), and who uses LLMs as independent coding agents. * A few well known AI scientists believe that what happened with Transformers can happen again, and better, following d ## Scaling HNSWs DevFeed: [Scaling HNSWs]() Original publisher: [Read original article]() Published: 2025-11-11T12:53:38Z Content type: article Language: en Sources: [Antirez]() Topics: [Data structures](), [Redis](), [Low Latency](), [Latency]() Tags: [blog-post](), [data-structures](), [latency](), [performance](), [redis](), [time]() ### AI overview An advanced blog post about HNSW internals, optimizations, and the challenges of integrating HNSW vector similarity search into Redis while maintaining low latency and high performance. The author also questions whether HNSWs are the final approach for greedy nearest-vector search. ### Source excerpt I'm taking a few weeks of pause on my HNSWs developments (now working on some other data structure, news soon). At this point, the new type I added to Redis is stable and complete enough, it's the perfect moment to reason about what I learned about HNSWs, and turn it into a blog post. That kind of brain dump that was so common pre-AI era, and now has become, maybe, a bit more rare. Well, after almost one year of thinking and implementing HNSWs and vector similarity stuff, it is time for some writing. However this is not going to be an intro on HNSWs: too many are present already. This is the "extra mile" instead. If you know HNSWs, I want to share with you my more "advanced" findings, especially in the context of making them fast enough to allow for a "Redis" experience: you know, Redis is designed for low latency and high performance, and HNSWs are kinda resistant to that, so there were challenges to expose HNSWs as an abstract data structure. This blog post will be split into several sections. Think of them as pages of the same book, different chapters of the same experience. Oh and, by the way, I already wrote and subsequently lost this blog post :D [long, sad story about MacOS and bad habits - I hadn't lost something like that since the 90s, during blackouts], so here most of the problem will be to recall what I wrote a few days ago and, while I'm at it, to better rephrase what I didn't like very much. ## A few words about the state of HNSW Before digging into the HNSWs internals and optimizations, I want to say a few things about HNSWs. The original paper introducing HNSWs is a great piece of computer science literature, and HNSWs are amazing data structures, but: I don't believe they are the last word for searching, in a greedy way, for nearby vectors according to a distance function. The paper gives the feeling it lacks some "pieces", almost like if the researchers, given six months more, had a lot more to explore and say. For instance, I modified the paper m ## AI's capabilities, uncertain trajectory, and potential economic consequences DevFeed: [AI's capabilities, uncertain trajectory, and potential economic consequences]() Original publisher: [Read original article]() Published: 2025-08-13T15:59:56Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Large Language Model](), [Transformer architecture](), [systems]() Tags: [ai](), [future](), [investors](), [llms](), [models](), [science](), [transformer-architecture]() ### AI overview This opinion article examines AI's progress in language understanding, programming, and bug finding while emphasizing uncertainty about future advances. It also considers how greater AI independence could challenge labor markets, service businesses, and the concentration of intelligence providers. ### Source excerpt Regardless of their flaws, AI systems continue to impress with their ability to replicate certain human skills. Even if imperfect, such systems were a few years ago science fiction. It was not even clear that we were so near to create machines that could understand the human language, write programs, and find bugs in a complex code base: bugs that escaped the code review of a competent programmer. Since LLMs and in general deep models are poorly understood, and even the most prominent experts in the field failed miserably again and again to modulate the expectations (with incredible errors on both sides: of reducing or magnifying what was near to come), it is hard to tell what will come next. But even before the Transformer architecture, we were seeing incredible progress for many years, and so far there is no clear sign that the future will not hold more. After all, a plateau of the current systems is possible and very credible, but it would likely stimulate, at this point, massive research efforts in the next step of architectures. However, if AI avoids plateauing long enough to become significantly more useful and independent of humans, this revolution is going to be very unlike the past ones. Yet the economic markets are reacting as if they were governed by stochastic parrots. Their pattern matching wants that previous technologies booms created more business opportunities, so investors are polarized to think the same will happen with AI. But this is not the only possible outcome. We are not there, yet, but if AI could replace a sizable amount of workers, the economic system will be put to a very hard test. Moreover, companies could be less willing to pay for services that their internal AIs can handle or build from scratch. Nor is it possible to imagine a system where a few mega companies are the only providers of intelligence: either AI will be eventually a commodity, or the governments would do something, in such an odd economic setup (a setup where a single ## Coding with LLMs in the summer of 2025 (an update) DevFeed: [Coding with LLMs in the summer of 2025 (an update)]() Original publisher: [Read original article]() Published: 2025-07-20T10:58:54Z Content type: article Language: en Sources: [Antirez]() Topics: [Large Language Model](), [coding](), [Programming](), [Redis](), [Assembly]() Tags: [2025](), [assembly](), [claude](), [code](), [code-reviews](), [coding](), [llms](), [programming](), [redis](), [update]() ### AI overview The article reflects on how frontier LLMs such as Gemini 2.5 PRO and Claude can support programming through code reviews, rapid prototyping, pair design, specification-driven coding, and work with unfamiliar technologies. It argues that effective use depends on clear problem descriptions, iterative collaboration, and human judgment. ### Source excerpt Frontier LLMs such as Gemini 2.5 PRO, with their vast understanding of many topics and their ability to grasp thousands of lines of code in a few seconds, are able to extend and amplify the programmer capabilities. If you are able to describe problems in a clear way and, if you are able to accept the back and forth needed in order to work with LLMs, you can reach incredible results such as: 1. Eliminating bugs you introduced in your code before it ever hits any user: I experienced this with Vector Sets implementation of Redis. I would end eliminating all the bugs eventually, but many were just removed immediately by Gemini / Claude code reviews. 2. Explore faster how a given idea could work, by letting the LLM write the throw away code to test ASAP in order to see if a given solution is actually more performant, if it is good enough, and so forth. 3. Engage in pair-design activities where your instinct, experience, design taste can be mixed with the PhD-level knowledge encoded inside the LLM. In this activity, the LLM will sometimes propose stupid paths, other times incredibly bright ideas: you, the human, are there in order to escape local minimal and mistakes, and exploit the fact your digital friend knows of certain and various things more than any human can. 4. Accelerate your work by writing part of the code under your clear specifications. 5. Work with technologies far from your expertise but contiguous with what you can do (for instance: coding in 68000 assembly for an Amiga demo?) using LLMs as an extension of specific parts of your mind, for the knowledge you don't have. One and half years ago I wrote a blog post called "LLMs and programming in the first days of 2024". There, I found LLMs to be already useful, but during these 1.5 years, the progresses they made completely changed the game. However, in order to leverage their capabilities, humans interacting with LLMs must have certain qualities and follow certain practices. Let's explore them. ## Refuse vi ## Human coders are still better than LLMs DevFeed: [Human coders are still better than LLMs]() Original publisher: [Read original article]() Published: 2025-05-29T16:34:51Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Large Language Model](), [Redis](), [Graphs](), [bug](), [data]() Tags: [ai](), [bug](), [code](), [graph](), [llms](), [redis]() ### AI overview The author argues that current LLMs remain far less capable than humans while describing their regular use for coding, code reviews, idea testing, and exploration. The article also examines a complicated Redis Vector Sets bug involving corrupted serialized HNSW graph data and reciprocal links between nodes. ### Source excerpt This is a short story of how humans are still so much more capable of LLMs. Note that I'm not anti-AI or alike, you know it if you know me / follow me somewhere. I use LLMs routinely, like I did today, when I want to test my ideas, for code reviews, to understand if there are better approaches than what I had in mind, to explore stuff at the limit of my expertise, and so forth (I wrote a blog post about coding with LLMs almost two years, when it was not exactly cool: I was already using LLMs for coding and never stopped, I'll have to write an update, but that's not the topic of this post). But, still: the current level of AI is useful, great too, but so incredibly behind human intelligence, and I want to remark this as lately it is impossible to have balanced conversations. So, today I was working to Vector Sets for Redis, to fix a complicated bug: during the time I stopped working at Redis my colleagues introduced resistance against corruption RDB and RESTORE payloads, even when the checksum of the data passes. This feature is disabled by default, but provides an enhanced layer of safety for people wanting it. But... there is a but as big as an elephant: In order to make HNSWs fast to save into Redis RDBs and to load back, I serialized the *graph* representation, and not the element-vector pairs, otherwise I would have to re-insert back data into HNSWs, and that would be, like, 100 times slower (!). So I store all the links the nodes have with other nodes, as integers, and then I resolve them into pointers, it's a nice trick and works great. But if you mix this and random corruptions of the representation, and the fact that my own twist on HNSWs enforce reciprocal links between nodes (I wrote my own implementation of HNSWs with many useful features, but reciprocal links are needed to enable many of them) then this could happen: 1. We load corrupted data that says A links to B, but B no longer links to A (corrupted node IDs). 2. We delete node B: since the reciprocity ## What I learned during the license switch DevFeed: [What I learned during the license switch]() Original publisher: [Read original article]() Published: 2025-05-02T08:46:25Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Open Source](), [Linux](), [Debian](), [Software]() Tags: [debian](), [linux](), [open-source](), [software]() ### AI overview The author reflects on what they learned after switching a project's license to AGPL. They argue that license familiarity and community understanding matter alongside formal permissions, and discuss continued interest in open-source software distribution, drawing on experiences with Linux and Debian. ### Source excerpt Yesterday, it was a very intense day. In Italy it was 1st of May, the workers holiday, so in the morning I went for a 4h walk in the Etna with friends <3, I love walking, and I often take pauses when coding just to walk, to return later at the keyboard with a few more kilometers on my legs, and walking in the Etna is amazing (Etna is the largest active volcano in Europe, and I happen to live in Catania, that is on its slopes). Then at 6PM I was at home to release my blog post about the AGPL license switch, and I started following the comments, feedbacks, private messages, and I learned a few things in the process. 1. Regardless of the different few clauses, that IMHO make a difference, the AGPL vs SSPL main difference is that AGPL is "understood". In general, yesterday for the first time I realized that in licensing there is not just what you can do and can't do, but the degree a given license is understood, tested, adopted, ... 2. I was very touched by the words of Simon Willison on the matter (https://simonwillison.net/2025/May/1/redis-is-open-source-again/) because it is very peculiar that different persons, living in different parts of the world, but with a similar age and background in software, feel *so similar* about things. I, too, when was writing Vector Sets, was thinking: I would never use it if it wasn't going to be released under the AGPL (or other open source license I understand). This sentiment, multiplied by a non trivial fraction of the community, makes open source eventually win even in the complex software landscape that there is today. 3. People still care a lot about software distributions. Not that I didn't care, but in the past I burned my fingers with it. I was a very initial Linux user, with SlackWare 3.1 or something like that. During the years I wrote my device drivers, contributed a few patches to the kernel, during the years Debian had maybe ~10 packages of stuff that I wrote, from hping, to the Visitors web log analyzer, dump1090, Redi ## Redis is open source again DevFeed: [Redis is open source again]() Original publisher: [Read original article]() Published: 2025-05-01T15:55:50Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Redis](), [Open Source]() Tags: [open-source](), [open-source-software](), [redis]() ### AI overview The author discusses Redis's switch from the SSPL to the AGPLv3 license, arguing that the AGPL is more widely accepted as an open source license. The author also plans further improvements to Redis's Vector Sets data type. ### Source excerpt Five months ago, I rejoined Redis and quickly started to talk with my colleagues about a possible switch to the AGPL license, only to discover that there was already an ongoing discussion, a very old one, too. Many people, within the company, had the feeling that the AGPL was a better pick than SSPL, and while eventually Redis switched to the SSPL license, the internal discussion continued. I tried to give more strength to the ongoing pro-AGPL license side. My feeling was that the SSPL, in practical terms, failed to be accepted by the community. The OSI wouldn't accept it, nor would the software community regard the SSPL as an open license. In little time, I saw the hypothesis getting more and more traction, at all levels within the company hierarchy. I'll be honest: I truly wanted the code I wrote for the new Vector Sets data type to be released under an open source license. Writing open source software is too rooted in me: I rarely wrote anything else in my career. I'm too old to start now. This may be childish, but I wrote Vector Sets with a huge amount of enthusiasm exactly because I knew Redis (and my new work) was going to be open source again. I understand that the core of our work is to improve Redis, to continue building a good system, useful, simple, able to change with the requirements of the software stack. Yet, returning back to an open source license is the basis for such efforts to be coherent with the Redis project, to be accepted by the user base, and to contribute to a human collective effort that is larger than any single company. So, honestly, while I can't take credit for the license switch, I hope I contributed a little bit to it, because today I'm happy. I'm happy that Redis is open source software again, under the terms of the AGPLv3 license. Now, time to go back to the terminal, to show Redis users some respect by writing the best code I'm able to write, and make Vector Sets more useful and practical: I have a few more ideas for improvements ## Reproducing Hacker News writing style fingerprinting DevFeed: [Reproducing Hacker News writing style fingerprinting]() Original publisher: [Read original article]() Published: 2025-04-16T13:53:16Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis](), [quantization](), [data](), [Python](), [datasets](), [GitHub](), [airflow]() Tags: [code](), [data](), [dataset](), [demo](), [github](), [hacker-news](), [python](), [quantization](), [redis](), [report]() ### AI overview The article reports on reproducing a Hacker News writing-style fingerprinting experiment using word-frequency vectors and Redis Vector Sets. It describes a demo, a reproducible GitHub implementation, the dataset's memory requirements, and benchmark results for VSIM with int8 quantization. ### Source excerpt About three years ago I saw a quite curious and interesting post on Hacker News. A student, Christopher Tarry, was able to use cosine similarity against a vector of top words frequencies in comments, in order to detect similar HN accounts -- and, sometimes, even accounts actually controlled by the same user, that is, fake accounts used to uncover the identity of the writer. This is the original post: https://news.ycombinator.com/item?id=33755016 I was not aware, back then, of Burrows-Delta method for style detection: it seemed kinda magical that you just needed to normalize a frequency vector of top words to reach such quite remarkable results. I read a few wikipedia pages and took mental note of it. Then, as I was working with Vectors for Redis I remembered about this post, searched the web only to discover that the original page was gone and that the author, in the original post and website, didn't really explained very well how the data was processed, the top words extracted (and, especially, how many were used) and so forth. I thought I could reproduce the work with Vector Sets, once I was done with the main work. Now the new data type is in the release candidate, and I found some time to work on the problem. This is a report of what I did, but before to continue, the mandatory demo site: you can play with it at the following link: https://antirez.com/hnstyle?username=pg&threshold=20&action=search NOTE: since the dataset takes 700MB of RAM, in my tiny server, in the next months I may take this down. However, later in this post you will find the link and the Github repository with the code to reproduce everything from scratch. NOTE2: I hope the web site will survive, it's a very crude Python script. I benchmarked the VSIM command in such a small server and yet it can deliver 80k VSIM per second! The wonders of int8 quantization, together with a few more optimizations. But the Python script is terrible, creates a new Redis connection each time and so forth. Fingers ## Vector Sets are part of Redis DevFeed: [Vector Sets are part of Redis]() Original publisher: [Read original article]() Published: 2025-04-03T18:01:20Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis](), [Data structures](), [API](), [Programming]() Tags: [api](), [data-structure](), [design](), [modularity](), [module](), [native](), [redis](), [vector]() ### AI overview The article announces that Vector Sets have been merged into Redis. It describes them as a new Set-like data type that stores vectors, supports vector-similarity queries, and will be available as a native data type in Redis 8 while retaining modular internal boundaries. The feature is still in beta. ### Source excerpt Yesterday we finally merged vector sets into Redis, here you can find the README that explains in detail what you get: https://github.com/redis/redis/blob/unstable/modules/vector-sets/README.md The goal of the new data structure is, in short, to create a new "Set alike" data type, similar to Sorted Sets, where instead of having a scalar as a score, you have a vector, and you can add and remove elements the Redis way, without caring about anything except the properties of the abstract data structure Redis implements, ask for elements similar to a given query vector (or a vector associated to some element already in the set), and so forth. But more about that later, a bit of background, first: From the path of the README itself, you can see the implementation is into "modules", but actually, Vector Sets are not a module, it's a part of the Redis core, the thing is that I started developing them as a module, and later I suggested that the implementation should still use the modules API, in order to promote modularity of the internals of Redis, in order to have both the advantages: every Redis instance starting from Redis 8 will have Vector Sets as a native data type, and there are clear boundaries between the core and the implementation ## The first new main data type of Redis after... some time I think that the latest big data structure of Redis were Streams, also developed by me. I resigned, returned, forks happened in the meantime, and it still it looks like the burden to introduce a new data type in Redis is mine :D I must say: I'm ok with that, because as much as I like programming, I also like design, a lot, and I had a feeling, that vectors, and vector similarity, are conceptually very simple, so they deserved a very simple API. And that was what I tried to do. Vector Sets are still a beta feature but I can tell you something, I can guarantee you can learn the API in 3 minutes. I decided that a fundamental requirement for implementing vector similarity was to also [Next page]()