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…
Control the Ideas, Not the Code
181–190 of 208 posts
Re: Control the Ideas, Not the Code
#182Re: Control the Ideas, Not the Code
#183What 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 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
#184Earlier 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.
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
Re: Control the Ideas, Not the Code
#186Earlier 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…
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
#187For 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
- Dijkstra
Re: Control the Ideas, Not the Code
#188This 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
Re: Control the Ideas, Not the Code
#189Earlier 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!
Re: Control the Ideas, Not the Code
#190Earlier 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…