Control the Ideas, Not the Code: The Future of Programming with AI

As an experienced programmer, I urge developers to stop obsessing over every line of code generated by AI. Instead, focus on controlling the core ideas, design, and quality assurance of your software. Reviewing thousands of lines is inefficient; your time is better spent defining the vision and testing the logic. The field is evolving, and while this shift is painful, it offers a chance to fix a broken industry by prioritizing mental models over syntax.

I truly believe that many programmers at this point have less impact than they could have because they look at the code.
  1. m_ke

    I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction.

    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.

  2. danceparty

    Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.

  3. jgeada

    Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters.

    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.

  4. gabrieledarrigo

    I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend!

    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.

  5. alexpotato

    For some background on me to set the context for the following opinion:

    - 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 […]

  6. aledevv

    >if you control the ideas of your software, looking at the code itself is suboptimal and often pointless.

    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 :) )

  7. adverbly

    Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example:

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

  8. devin

    The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience).

    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.

More from this day

2026-07-13