Control the Ideas, Not the Code • Hacker News Board

Re: Control the Ideas, Not the Code

#91

Post by rapind » Mon, Jul 13, 2026, 2:56 PM UTC

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…

I just finished an LLM assisted Rust rewrite of a production project after a couple months. It's around 150k LOC, mostly Rust, excluding generated code and tests. Around 200k if I include tests. I'm also now starting to extract / refactor some of it's code into their own reusable crates, so my LOC isn't going to grow and might even shrink a bit. I can't speak to 1M LOC, but I'd imagine that takes a lot of human context to reason about too, and you probably want to break it up into manageable chunks if possible.

LLMs have been a boon. I have a lot of guardrails in place though to keep the LLMs focused and producing correct and ergonomic code. A lot of effort and review has gone into creating these guardrails (choice of language, linting, forced conventions, tests, etc.). A lot of these practices will be useful in future projects. I highly recommend this approach. Don't just copy skills or processes that others publish. Figure it out yourself so the lessons stick. Human in the loop, especially one that has learned through practice and failure, is still immensely valuable IMO. It's a fine line between getting stuff done and yakshaving over your tooling... but that's always been the case, as proven by my vim dotfiles. :)

It's worth noting that the AI industry is filled with tons of snakeoil and BS. You don't need to take someone's course in "21 steps to be productive with AI" or w/e. Just like learning a new programming language, dig right in and try to build something that scratches an itch. Pick a project you have complete autonomy over instead of that "spend all the tokens" crap managers were pushing until recently (this has corrected now right?).

Parent saying "Skill issue" though... What a jackarse.

Re: Control the Ideas, Not the Code

#92

Post by simonw » Mon, Jul 13, 2026, 2:57 PM UTC

andsoitis wrote: post #49

> Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but i…

I also got a hint from this that he worries the community would reject features in Redis (and Redis itself) if they expected that the code has not been human-reviewed.

I'm facing this with some of my own open source projects: I feel a responsibility to manually review the code because I don't want to damage the reputation of those projects by shopping code I haven't looked at myself, even where I'm confident that it works and is well structured already.

Re: Control the Ideas, Not the Code

#93

Post by noopprod » Mon, Jul 13, 2026, 2:57 PM UTC

logicprog wrote: post #25

m_ke wrote: post #20

Earlier quoted context omitted.

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…

I haven't hit nearly a million lines, that's true, these projects are "only" 20k and 45k lines of code or so, respectively; however, I do have directed acyclic graphs of worker agents, managed asynchronously by the agent I chat directly with, do huge architectural refactors (the most recent, was to update everything in the codebase that used the sychronous Lua standard library `io` functions to use the asynchronous,…

[dead]

Re: Control the Ideas, Not the Code

#94

Post by adverbly » Mon, Jul 13, 2026, 2:59 PM UTC

Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example:

> Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.

Why is the attitude here about keeping the floor up rather than raising the bar?

Why can't we have better code with AIs? Its not impossible to do!

When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself.

It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce.

Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.

Re: Control the Ideas, Not the Code

#95

Post by zozbot234 » Mon, Jul 13, 2026, 2:59 PM UTC

kamranjon wrote: post #32

Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game. When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a g…

> speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference

This is somewhat of a nitpicking point, but AIUI speculative decoding is worthwhile if (1) you have viable unexploited parallelism that can speed up the "verify" step compared to plain decode, and (2) it's profitable for you to load complete model layers into memory in bulk, not just a tiny fraction of active parameters. (2) tends to be true for large hosters, but not only, e.g. if you're running inference on a large dense model (think Mistral Medium) with SSD streaming and a single session (no concurrent batching), speculative decoding can be quite great.

It's also a spectrum, e.g. some MoE models are not very sparse and comparatively few concurrent requests might already span most of the experts, such that loading a complete set of layer parameters and doing speculative decoding to increase compute intensity actually becomes worthwhile.

Re: Control the Ideas, Not the Code

#96

Post by devin » Mon, Jul 13, 2026, 3:00 PM UTC

The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience).

I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.

Re: Control the Ideas, Not the Code

#97

Post by devin » Mon, Jul 13, 2026, 3:02 PM UTC

craigmart wrote: post #76

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…

"coding is largely solved" and "self-driving is largely solved" smell exactly the same to me.

ETA: I bristle deeply at your idea that anyone who doesn't agree with you is letting their emotions get the better of them. Perhaps the world is not as black and white as you're painting it?

Re: Control the Ideas, Not the Code

#98

Post by xpct » Mon, Jul 13, 2026, 3:04 PM UTC

craigmart wrote: post #76

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…

What does it mean for coding to be solved, and software engineering to not have been solved? If it implies there's now a set protocol that can be followed to reach good results, how has that not been the case before? If it means that we can reach better results than before, then how do we know that can't be improved further? Or does that mean we should know how English language, instead of computer code, maps to computer instructions?

Re: Control the Ideas, Not the Code

#99

Post by noopprod » Mon, Jul 13, 2026, 3:08 PM UTC

saghm wrote: post #89

logicprog wrote: post #56

Earlier quoted context omitted.

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.

[dead]

Re: Control the Ideas, Not the Code

#100

Post by __MatrixMan__ » Mon, Jul 13, 2026, 3:11 PM UTC

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…

> 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 my experience). I wouldn't propose that we dispense with rationalism altogether, but it does seem that the we'll benefit by achieving a better balance than we've traditionally had.