[deleted]
Control the Ideas, Not the Code
111–120 of 208 posts
Re: Control the Ideas, Not the Code
#112Ideas 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 b…
Curating ideas requires experience and taste. Can you really develop that without looking at code? Compare Steve Jobs vs Joni Ive curating as a prime example of how taste without practical experience and context can lead things astray. And the worst of it is that it can take a while for the problem to be easily noticeable.
Re: Control the Ideas, Not the Code
#113> 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 genuinely wonder how the above can be accomplished without reading any code. We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way. That's not usually going to be the most efficient way to understand code, but I've found that it's pretty useful to be one of the few empiricists in an organization full of rationalists (software engineers are typically rationalists in…
> We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.
Interesting perspective. Haven't really thought through that lens
Re: Control the Ideas, Not the Code
#114I 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…
[dead]
Re: Control the Ideas, Not the Code
#115I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction. So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages tha…
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…
things you described are not "highly unusual" in the way gp comment is describing. you are just remixing bunch of stuff. Thats the type of thing ai is really good at.
Re: Control the Ideas, Not the Code
#116> 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.
Yeah, totally
Re: Control the Ideas, Not the Code
#117I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend!
Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively.
I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.
Re: Control the Ideas, Not the Code
#118This article feels too black and white
> How are you supposed to review 5k lines of code every day?
Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.
> “how is exactly the design of that part? How does it work?”
Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.
It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.
Re: Control the Ideas, Not the Code
#119Earlier 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 know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study. For all we know, this could just as well be a severe case of Dunning-Kruger.
I've found this to be more consistently the case than not. People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function. They put together a keyword soup post that sounds good on an AI generated resume but falls apart upon investigation.
Re: Control the Ideas, Not the Code
#120Ideas 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…
> 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.
This doesn't strike me as wrong, but where the rubber meets the road. Let me give you an example.
My superior with close to zero programming skills, sat down with Claude and "wrote" a Django backend with SPA React frontend that enables user directory sync from one source to another and then exposes an API for other services to consume. It supports RBAC, 2FA, extensions for directory sources, dashboard with stats and what not. Everything packed into docker containers ready to deploy on the cloud. Again, the person is very skilled as a consultant, but lacks programming skills whatsoever. I did a code review, prepped a list of things to fix and he did fix them with Claude again. Later on, he used Claude to rewrite the Python backend to Go. I did no code review on that part. Fable was used in several iterations to test for security issues before each release.
Long story short, this service is now running in the cloud and the customer uses it to solve their problem. We got a couple of other customers on the line as well.
You tell me what to do with that.