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

71–80 of 208 posts

Re: Control the Ideas, Not the Code

#71

Post by aerodexis »

aledevv wrote: post #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 choi…

We're all project-managers now. The trust required of the LLM is no different than that that required when a PM trusts a dev-team to implement correctly. As a PM, you need to understand testability and write that into the requirements.

Re: Control the Ideas, Not the Code

#72

Post by qsera »

wongarsu wrote: post #53
danceparty wrote: post #35

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…

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 actually just doing a slightly better rubber ducking...

Re: Control the Ideas, Not the Code

#73

Post by sibeliuss »

danceparty wrote: post #35

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…

I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?

I'm sitting here working and just caught a handful of really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?

Re: Control the Ideas, Not the Code

#74

Post by qsort »

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 opening the editor is basically a mistake?

Re: Control the Ideas, Not the Code

#75

Post by Tade0 »

inigyou wrote: post #48
Tade0 wrote: post #15

Earlier quoted context omitted.

To be honest until today I thought Kafka was the popular go-to Redis replacement, as almost none of my employers used Redis for its original, intended purpose, namely being an in-memory key-value store. What they really wanted was RabbitMQ.

Kafka does a completely different thing than Redis.

Indeed. Doesn't change the fact that people have been using Redis where they could well have used Kafka.

Hell, I did that in a previous project.

Re: Control the Ideas, Not the Code

#76

Post by craigmart »

I strongly agree with antirez. I believe that an intellectually honest programmer should recognize where their knowledge and experience is mostly beneficial, and at this point (and we've seen clear signs for some time) coding is largely solved. Which doesn't mean that you can just prompt at a very high level, but that iterating with the LLM over decisions, designs and tests, will essentially allow you to not write a single line of code by hand. Software engineering is not just coding, and it involves a whole set of other tasks requiring direction and creativity that can greatly influence the quality and impact of the software.

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.

Re: Control the Ideas, Not the Code

#77

Post by cyphar »

wongarsu wrote: post #53
danceparty wrote: post #35

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…

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…

But the CPU is not executing the textual description of your architecture. It executes code.

Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.

Re: Control the Ideas, Not the Code

#78

Post by skydhash »

wongarsu wrote: post #53
danceparty wrote: post #35

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…

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…

> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,

Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.

I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.

Re: Control the Ideas, Not the Code

#79

Post by justincormack »

m_ke wrote: post #20
logicprog wrote: post #11

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…

It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things sta…

At 600k lines of Rust, not finding those issues yet. You can search for different versions of same concepts, I mean you need to refactor a lot anyway.

Re: Control the Ideas, Not the Code

#80

Post by simonw »

saghm wrote: post #37
logicprog wrote: post #11

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

Post reply on HN