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

81–90 of 208 posts

Re: Control the Ideas, Not the Code

#81

Post by lantry »

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…

I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use.

So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should be spent curating ideas.

Re: Control the Ideas, Not the Code

#82

Post by justincormack »

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…

No its fine. The problem is trying to read all the code. Reading some is fine. I tend to focus on public APIs, and key areas. But not the thousands of lines which arre tests or will be refactored.

Re: Control the Ideas, Not the Code

#83

Post by brunocalza »

> 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 are broken (do more work than they should, for instance), and so forth.

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.

Re: Control the Ideas, Not the Code

#84

Post by saghm »

simonw wrote: post #80
saghm wrote: post #37

Earlier quoted context omitted.

> All I can say is skill issue. I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express…

I think "skill issue" is often deployed (including here) as a shortcut for what you said - "the only thing stopping them is that no one has helped them understand". (I try not to say "skill issue" myself because it comes across as rude.)

Yes, but with the context that the person saying it is almost always the one who does understand, and is choosing to be snarky instead of helpful.

Re: Control the Ideas, Not the Code

#85

Post by qsera »

>What’s the point of scanning function by function, line by line?

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?

Re: Control the Ideas, Not the Code

#86

Post by skydhash »

efficax wrote: post #67
krupan wrote: post #63

Earlier quoted context omitted.

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

Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome.

That’s why we read code. Because only there the correct and incorrect cases are clearly separated.

Re: Control the Ideas, Not the Code

#87

Post by xpct »

titularcomment wrote: post #51

I believe issues will arive with AI in the near future in terms of their performance. Disagreeing with the author, I think code quality pre-AI, in certain languages, were golden. They all contained bugs but they were written in a way that bug sources would be more or less obvious and most but not all top open source software had linting guidelines, code styles & friends to help make it ingestible. Perhaps these helpe…

I think it's related that we as humans see when something becomes hard to reason about, and decide to refactor it. I'm not sure whether an LLM with full ownership of a codebase could do that, for its own benefit.

I do see a world where models could be trained on it, but I imagine it will be more expensive, because it requires including future rewards about the models' own later efficiency.

Re: Control the Ideas, Not the Code

#88

Post by dionian »

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…

he said he read it though, and check the last line

Re: Control the Ideas, Not the Code

#89

Post by saghm »

logicprog wrote: post #56
saghm wrote: post #37

Earlier quoted context omitted.

> All I can say is skill issue. I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express…

In my experience, because as you say, the flexibility of these tools and how you engage with them is so broad, and how much the nuances of thay engagement can often matter, the only way to teach someone how to do what you do with them is to sit down and pair a program with them. Barring that, any instructions you could give would massively under-determined what they actually try as a result of your instructions, and…

That's a completely reasonable take. I wouldn't have any issue with a nuanced comment like that. My issue with your above comment is that it's a lot more arrogant than nuanced.

Re: Control the Ideas, Not the Code

#90

Post by am17an »

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…

Having looked at his code, I doubt this.
Post reply on HN