Live data from Hacker News

Control the Ideas, Not the Code

antirez.com

181–190 of 208 posts

Re: Control the Ideas, Not the Code

#181
post #163
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…

I could not disagree more. I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention. Software is exact; its maths. We would not tolerate a machine that operates on the basis pr…

the model does not make the architecture decisions, you make the architecture decisions. you define what success is, including performance characteristics. fuzzing and property based testing ensure correctness. what does it matter what the code looks like if it the machine you've created fulfills the criteria you define?

Re: Control the Ideas, Not the Code

#182
I think this is a possible future, but we are nowhere close with the current tech. It makes too many mistakes currently. I could envision a future where the hallucination and error rate is brought down to a very small number, but trusting your codebase completely to an LLM at this point has a 100% chance of eventually becoming a problem.

Re: Control the Ideas, Not the Code

#183
post #110

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.

I think about that too. Had I grown up thinking that I need to pay a subscription to build software, I wouldn't have tried to get into engineering at all. As a teen I wanted to learn electronics and robotics, but I couldn't afford the parts to build anything so I taught myself programming and CS instead, and that's the only thing that helped me slog through academic education.

I can't imagine making the same choice again today. Nowadays I worry that software engineering is about to become short-lived right after I've entered the workforce, in which case I'll regret the time I spent to get to this point based on a false hope.

Re: Control the Ideas, Not the Code

#184

Earlier quoted context omitted.

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.

Did you actually manually review the 600k lines of code? And the reason LLMs tend to produce such insanely large codebases is partially what the comment you're replying to explained, they duplicate everything all over the place.

"You are violating the DRY principle with code like . Look through the codebase in depth, and identify possible places to consolidate common logic."

Yeah, there's no substitute for taste, but this is not that big of a deal. I infinitely prefer repeated code to crappy, leaky abstractions. Let the model generate some slop, then tighten it up either by hand or with more prompting.

Re: Control the Ideas, Not the Code

#185

... I believe many programmers at this point have less impact they could have because they look at the code. I think my strength is now more in my ability as a mathematician and a writer than as a programmer. Being able to write detailed specs and doing QA by testing is far more productive than looking at code.

Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code

That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!

Re: Control the Ideas, Not the Code

#186
post #179

Earlier quoted context omitted.

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…

> cascading from an assumption that was incorrect I have found including this in my AGENTS.md to be quite transformative in this regard: > Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases…

> It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run.

Is this for llm purposes? In many forms of TDD a compile error is key to the red phase. And you are going from red to green before asserts even exist is part of the process.

Re: Control the Ideas, Not the Code

#187

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…

You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code

"Testing shows the presence, not the absence of bugs"

- Dijkstra

Re: Control the Ideas, Not the Code

#188
post #174
post #151

This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.

Everyone's a prophet now

i use it daily and it's what is trending towards

Re: Control the Ideas, Not the Code

#189

Earlier quoted context omitted.

Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code

That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!

Unimpressive slot machine, it will betray you sooner than later and pay a real price

Re: Control the Ideas, Not the Code

#190
post #179

Earlier quoted context omitted.

> cascading from an assumption that was incorrect I have found including this in my AGENTS.md to be quite transformative in this regard: > Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases…

> It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. Is this for llm purposes? In many forms of TDD a compile error is key to the red phase. And you are going from red to green before asserts even exist is part of the p…

For the TypeScript projects that I work in, if there is value in a compile error phase I am not smart enough to know what it is, heh.
Post reply on HN