So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages that have the high median quality online.

I started my project with a few simple interface definitions and a short design / architecture doc that I include in the AGENTS.md file, but no matter how hard I try all of the models just end up ignoring it and sprinkled new seeds of variants of the same stuff all over my code base, that with each new session grow new branches.

Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two.

Nothing yet has replaced the curating of ideas that good teams do as a matter of course.

Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively.

I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.

This requires developers to have absolute and unconditional Trust in the LLM. It's not easy to trust it completely to the point of completely ignoring the implementation details of the code.

In one of Salvatore's discussions, he mentioned that he hasn't even opened a single file of DS4. This is a courageous choice.

But the real question is: if the younger generation stops writing code, how are they supposed to develop that "forma mentis" (mindset) that allows them to reason about design and architecture? It's only by *writing* the code that you gradually internalize development and design patterns, specifically by clashing with the "brutality" of bugs and solving implementation problems.

P.S. I read Wohpe. It's fascinating how back in 2022 (I think?) Salvatore already wrote down many insights that have actually come true (including, for instance, the ban on "strong artificial intelligence"...). So I suppose that the future will touch the very development of humanity (like the Genesi project :) )

- been a SRE/DevOps at banks/hedge funds for almost 20 years

- now work in L1 crypto

- have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc).

My thoughts:

The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an issue from partial logs etc etc.

They do still hallucinate. WAY less than they used to but it's still non-zero. In a way that's worse b/c the model will spit out a complex piece of software and say "Yep, no mistakes. I even wrote tests and they all pass!" You might think "Phew, that's great!" but in the same way we've all found bugs in production code written by smart people, there will be bugs here too.

I say this not to imply that you have to read all of the code. I say if only to underline that for big complex systems, the "let's write unit tests for the parts that ABSOLUTELY HAVE TO BE CORRECT" is still just as important as it ever was. I'm thinking of examples like:

- the order and execution handler of a trading system

- avionics flight controls

- healthcare related medical devices

- etc

As an example: I was working on a complex system. I wasn't sure if the LLM code was actually correct so I wrote up a quick script that I checked, line by line, to be 100% sure it was working as I expected. I then used that script to double check the LLM. I didn't read all of the code the LLM created. The sense of "ok, now this works" was astounding.

I'll add, a lot of the developers I work with are going this "hybrid" route too where they will have the LLM write code and tests but then go back in and double check.

In closing, a lot of these big rewrites with LLMs are possible only b/c the devs KNOW, FOR A FACT, that the unit/integration tests are correct. I'm still not convinced that you can have LLMs write all of the code and all of the unit tests and be 100% sure that it's all correct. (I will admit that this has always been difficult and even the pre-LLM days were not a guarantee that all of the code wa s correct)

I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.

> Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.

Why is the attitude here about keeping the floor up rather than raising the bar?

Why can't we have better code with AIs? Its not impossible to do!

When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself.

It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce.

Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.

When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference).

There's recent work into "directional steering"[3] that has made it's way into per-session directional steering overrides thanks to audreyt[4].

There's support for the new Hy3[5] model also thanks to audreyt[6].

There's Pre-M5 optimizations[7] in the queue thanks to ivanfioravanti who also helped with some of the initial M5 optimizations.

I haven't watched a repo like this since llama.cpp and whisper.cpp in the early days (though llama.cpp is pretty exciting right now with the SYCL improvements that are flowing in for the new Intel GPUs).

The DS4 repo is a really interesting place to watch folks who heavily code with agents collaborate together in a way that seems pretty effective. I've been really enjoying it.

[1]: https://arxiv.org/abs/2607.05147

[2]: https://github.com/antirez/ds4/pull/502

[3]: https://arxiv.org/html/2406.00045v2

[4]: https://github.com/antirez/ds4/pull/148

[5]: https://hy.tencent.com/research/hy3

[6]: https://github.com/antirez/ds4/pull/523

[7]: https://github.com/antirez/ds4/pull/555

> How are you supposed to review 5k lines of code every day?

Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.

> “how is exactly the design of that part? How does it work?”

Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.

It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.

IMO there isn’t enough evidence for me to feel comfortable in that judgement.

Anecdotally, I find that pretty often LLMs (even bleeding-edge models) write unidiomatic/unscalable/poorly-abstraced code when working in large codebases.

I agree 100% that AI helps a lot with that. But I feel like there's something missing between "AI helps a lot with that" and "I believe reading code is mostly pointless". I genuinely wonder how the above can be accomplished without reading any code.

The most common arguments against this view seem to arise either from ideological resistance, which I understand given how painful it can be to see one’s job at risk or an important part of one’s identity taken away, or from generalizing a small number of experiences with LLMs to the technology as a whole. In the latter case, those experiences may also be heavily conditioned by the user’s inexperience in working with LLMs, or by the specific use case in which they were applied. There are still certain tasks that not all models can handle reliably as of now, however some can (usually the most expensive), and they will likely continue to improve over time.

yeah I was having a convo with AI about this recently

I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to

and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI

So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding

Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing

    ... I believe many programmers at this point have less impact they could have because they look at the code.

For some reason, the moment those humans are being replaced by fallible, stochastic machines, we decide to just throw the baby out with the bathwater entirely and no longer leverage critical parts of this pipeline? Because it's inefficient and we're bottlenecking the process? The magic of LLMs has quite literally bought us more cycles to do this stuff, not less!

I use the things every day to an extreme degree and still I don't think I will ever quite understand the leaps in logic required to arrive at this position.

This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.

Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.

This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.

Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.

- Coding: Writing instructions in a programming language. Example: writing a function that calculates the total price of an order.

- Programming: Designing a solution, writing the code, testing it, and fixing problems. Example: building a small application that manages orders and payments.

- Software engineering: Creating and maintaining reliable software systems using structured processes, architecture, testing, documentation, and teamwork. Example: designing an online store that can support millions of users and be maintained for many years.

It seems like in the future coding will all be done by machines and we can use our brain for the other 2 things.

I wonder why he HAS TO ("I need to...") review the code even if he thinks it is pointless? Is that because his employer, Redis, requires it?

It all sorta feels like an old guy (he says he's old in TFA) who forgot how he got to where he is today trying to give advice. Be careful what you believe, young programmers.

For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited.

What LLM coding does is generate lots of code from a fairly small English (natural language) prompt.

If you look closely, I think you'll see that this is two processes:

1. Translate from fuzzy English to precise machine-executable language

2. Translate from high-level description to lots of low-level code.

Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them.

But today we cannot.

I still read the code; but I work to make a trustworthy agent, so I can skim read at review.

For a year+ I've been gaining leverage by codifying guardrails. Insanely intricate (and fun to create) lint scripts that catch things like python imports inside functions instead of the top of the file, or dumb use of dict return where the return should be a pydantic model, or the agent dumbly using the ugly default Tailwind color classes instead of my design system colors.

It's fun codifying "how we work around here" and it's been great for keeping dumb AI mistakes off my radar.

Last week I busted out my text editor and typed (typed!) a section into CLAUDE.md on my philosophy - my why. "We do test driven development because we have a computer that can instantly validate your code." "We don't modify code until we have created and witnessed some other thing that durably proves the need for our change." Etc. etc.

Well the agent leveled up suddenly and dramatically. It was a real mind opener. One of those banger realizations. I'd been leaving tons of power on the table.

When backfilling tests, it suddenly started mutating production code and rerunning to witness tests go red - something it calls "teeth". It doesn't just assume tests work and move on! I didn't ask for that, it was latent in the model. I no longer have to remind it to run new eslint rules first to prove they're correct. Sometimes it even proposes new lint rules and checks to tighten its guardrails.

What I learned that maps to what @antirez is saying:

With everything about agents, stop operating at a level of "what". The what is the agent's job.

Stop operating at a level of "how" too!

Just focus on not hoarding your "why". Tell your agent where your ideas come from, why they matter. Do not just think the why in your head. Write it down! Put it in CLAUDE.md. Offload it into the system!

Your tools will level up.

Even if it's not about the harness. Building product features? Tell it what you think the users will do. And why. It might codify the UX closer to how you'd have. Tell it what other UIs you've seen and like - it probably knows about them and can just code that - less detail needed.

And it'll bring the code closer to what you'd have written. And bring you closer to that holy grail, LGTM skim-review.

The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests.

Do not listen to well-known programmers who use their non-AI earned fame to steer you into the unknown future.

The AI stock market is already collapsing as we speak and these recommendations aren't worth much.

I'm letting go of reading every single line, especially within well-scoped modules that don't affect anything else. On the other hand I struggle to form the mental model required to "control the ideas", as it were, without reading at least some critical sections of the code and without grasping how the fundamental data structures relate to each other.

Are we saying that opening the editor is basically a mistake?

> "didn’t you say that you check all the AI generated code for Redis?"... Yes, I do

For important code (Redis) he is still reading the diffs.

> but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working.

Yes, good software still requires engineering today.

Because a critical bug could be anywhere, even in a simple function. Particularly when it is written by an LLM.

Who knows when it chooses to have a bad hallucination?

Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go and build things or read the code? I hope the answer is not “reading mythical man month” or “watching YouTube video tutorials”.

Not egocentric but surely full of himself

> 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.

I have great impact because I own the code and I read it when I generate it not the contrary

> How are you supposed to review 5k lines of code every day?

I have the feeling we will just lose the battle and start to randomly die inside crushing planes or sinking ships thanks to unreviewed code. Or lose money, or whatever you can think of many examples.

> The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA.

Guess what when we hand coded we did all these points every day, now we can't because we need to go 100x faster, understand nothing that came out from the slot machine and, cherry on top, we should focus on QA instead of pushing high quality code first.

I'm really worried by the direction the industry is taking and how dangerous these "influencers" are, especially in Italy where I see he has a big follow up.

We lied on a mountain of slop before LLMs sure but at least some systems were still reliable, today you can already see nothing is reliable not even the simplest service like Spotify, programmers are already not verifying the output.

Genuine question, is redis actually used by competent engineers?

The idea of a separate networked process to store and retrieve variables from memory sounds like something a first year engineer would do when they learn about a hot tech netflix uses before they learn about fundamentals like what a heap and a stack are.