Live data from Hacker News

Control the Ideas, Not the Code

antirez.com

61–70 of 208 posts

Re: Control the Ideas, Not the Code

#61
post #46
post #38

I think the gist of what the author is saying is, AI is not good enough to just give one vague prompt to and let it go, but it's good enough for you to give it a "design" and then not worry about the actual code it writes. But you need to do a lot of QA still. And you still need to learn to code and write some code, I guess so you can give the LLM good instructions? But if giving good enough instructions requires som…

Never comment till you read the whole post, since your question is exactly addressed at the end.

The end is where you said people should still learn to program, I wouldn't know that you said that without reading to the end.

Re: Control the Ideas, Not the Code

#62
post #57

> Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but i…

Because Redis is not "my project", it is a piece of software many relies upon, so I use, for that software, what the community at large agrees to be ok: AI-assisted coding with human careful reading and evaluation of every line.

One thing I've been thinking about is what a new SDLC ought to look like in the age of agentic engineering, since the "old" workflows are likely suboptimal (e.g. PR reviews). Have you given it some thought?

Re: Control the Ideas, Not the Code

#63
post #55

Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is me…

This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages

Re: Control the Ideas, Not the Code

#64
post #40

Earlier quoted context omitted.

I do highly unusual, off the beaten path projects with AI. For instance, a game engine written entirely in LuaJIT, but allocating almost all data structures using CFFI, a very unusual, custom object-orientation DSL I designed myself, and that uses SDL3's SDL_gpu library to do all rendering, a ton of GLSL 4.6 compute shaders cross compiled to SPIR-V and Metal (which constraints what GLSL can be written), and is a hybr…

> All I can say is skill issue I know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study. For all we know, this could just as well be a severe case of Dunning-Kruger.

Not specifically about the comment you replied to, but there has been an absolute Cambrian explosion of plausible sounding projects that use really complicated words that are just AI psychosis. Recently there was someone who posted a huge Lean proof on GitHub supposedly of proving P=NP. The problem is AI is really good at deluding people if that person doesn't have domain specific knowledge. AI severely makes dunning Kruger worse

Re: Control the Ideas, Not the Code

#65
I agree that not having to read the code is the future but I struggle to get there because the AI, like humans, can make mistakes (not follow instructions). For example, I might ask the AI to render a scene using a physical model, and we might come to an agreement at the plan stage, but then it will go off and cut some corner in implementation. So the question is how to reliably verify compliance. If you merely tell another AI to check it properly implemented the plan it too can miss bugs, so you need to put all your effort in making the acceptance tests foolproof, and this is easier said than done. You need a defense in depth approach, using the type system, unit tests, formal verification (if you can), linting, etc. It is an open question how to optimally allocate your correctness efforts for a given budget but, as models get smarter, it is clear to see that the amount of human diligence needed to achieve likely correctness for a given task (say, in LOC) is going to tend to zero (https://metr.org/time-horizons/)

Re: Control the Ideas, Not the Code

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

Re: Control the Ideas, Not the Code

#67
post #63
post #55

Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is me…

This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages

You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.

Re: Control the Ideas, Not the Code

#68
I agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?

Re: Control the Ideas, Not the Code

#69

Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game. 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 g…

The ability to use steering vectors seems really powerful. I know you can build your own, but are there any collections of prebuilt steering vectors? Or even just mentions of what kinds of steering vectors people are building for their own use?
Post reply on HN