Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Control the Ideas, Not the Code

antirez.com

Post reply on HN
Print view View original

101–110 of 208 posts

Re: Control the Ideas, Not the Code

#101

Post by wongarsu »

qsera wrote: post #72
wongarsu wrote: post #53

Earlier quoted context omitted.

For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction But that does come with tradeoffs, and it's not the right thing for every project. But when it does wo…

>For complex code changes or bigger features I often spend hours with an LLM refining architecture The problem here is that the LLM hallucinates, so * it will tell that something is a bad idea, even when it is not. * it will miss good ideas. But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actuall…

Yes, a better rubber duck is a decent description

The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful.

And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff

Re: Control the Ideas, Not the Code

#102

Post by hollowturtle »

> 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

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.

Re: Control the Ideas, Not the Code

#104

Post by nadzzz »

jgeada wrote: post #47

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

[dead]

Re: Control the Ideas, Not the Code

#105

Post by xpct »

andsoitis wrote: post #49

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

I really don't understand why we feel the need to drop the review aspect. Programming with LLMs is a very non-linear process, there's no prompt-to-code mapping where editing a part of the prompt would produce an identical code construct with just a small part of it changed. LLMs are incapable of ensuring the thing works as expected, and the prompt itself is lossy too. Without review, we have no tangible way to interact with the system being constructed.

Re: Control the Ideas, Not the Code

#106

Post by zozbot234 »

antirez wrote: post #39
kamranjon wrote: post #32

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…

Thanks! And sorry for not yet merging many of those. The problem is, I'm dealing with tensor parallelism for the CUDA and Metal-RDMA fork right now, so was not albe to care about PR / issues for a lot of time.

I don't want to sound overly dismissive, but for quite a few practical cases pipeline parallelism with micro-batches will be a likely win over tensor parallelism. Of course this inherently comes with a requirement to take batched inference seriously for local use, at least in special cases where this doesn't put too much of a requirement on memory capacity. By comparison, tensor parallelism is probably good wrt. making memory- and KV-cache hungry models like GLM 5.2 and perhaps Kimi genuinely viable in a non-trivial local inference scenario.

Re: Control the Ideas, Not the Code

#107

Post by softwaredoug »

brunocalza wrote: post #83

> Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations…

I write 2% of code. And read 5-10%.

I feel like everyone is being too black and white. And everyone has different ways of staying in flow with a software task.

Re: Control the Ideas, Not the Code

#108

Post by noopprod »

qsort wrote: post #74

I'll admit I have a bit of a skill issue here. 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…

[dead]

Re: Control the Ideas, Not the Code

#109

Post by tauroid »

efficax wrote: 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…

> if we build it to be measurable

I.e. if by its structure we can conclude that our test cases are sufficient. Because if we don't know its structure then we don't know there aren't undisclosed sub-partitions of (combinatorially exploded) test space where it breaks.

How do we know its structure? By specifying it. How do we do that in enough detail? Code. Or we use static analysis I guess. Which is harder.

Re: Control the Ideas, Not the Code

#110

Post by davidw »

What I'm curious about is how a young programmer in, say, Sicily or Finland or somewhere who is a student or doesn't have a lot of spare cash, is going to deal with a world where everything is predicated on access to expensive tokens controlled by megacorporations, or where even 'open source' models require fairly expensive hardware to run.
Post reply on HN