Live data from Hacker News

Automatic Programming

antirez.com

41–50 of 257 posts

Re: Automatic Programming

#41
post #23

"I automatically programmed it" doesn't really roll off the tongue, nor does it make much sense - I reckon we need a better term. It certainly quicker (and at times, more fun!) to develop this way, that is for certain.

I coined the term lite coding for this after reading this article and now my chatGPT has convinced me that I am a genius

Re: Automatic Programming

#43
post #26
post #23

"I automatically programmed it" doesn't really roll off the tongue, nor does it make much sense - I reckon we need a better term. It certainly quicker (and at times, more fun!) to develop this way, that is for certain.

You will say I programmed it, there is no longer for this distinction. But then you can add that you used automatic programming in the process. But shortly there will be no need to refer to this term similarly to how today you don't specify you used an editor...

(Yes?) but the editor isn't claiming to take your job in 5 years.

Also I do feel like this is a very substantial leap.

This is sort of like the difference between some and many.

Your editor has some effect on the final result so crediting it/mentioning it doesn't really impact it (but people still do mention their editor choices and I know some git repo's with .vscode which can show that the creator used vscode, I am unfamiliar if the same might be true for other editors too)

But especially in AI, the difference is that I personally feel like its doing many/most work. It's literally writing the code which turns into the binary which runs on machine while being a black box.

I don't really know because its something that I am contradicted about too but I just want to speak my mind even if it may be a little contradicted on the whole AI distinction thing which is why I wish to discuss it with ya.

Re: Automatic Programming

#44
post #34

I have 30+ years of industry experience and I've been leaning heavily into spec driven development at work and it is a game changer. I love programming and now I get to program at one level higher: the spec. I spend hours on a spec, working with Claude Code to first generate and iterate on all the requirements, going over the requirements using self-reviews in Claude first using Opus 4.5 and then CoPilot using GPT-5.…

Waterfall can work great when: 1/ the focus is long-term both in terms of knowing that she company can take a few years to get the thing live but also that it will be around for many more years, 2/ the people writing the spec and the code are largely the same people. Agile was really pushing to make sure companies could get software live before they died (number 1) and to remedy the anti-pattern that appeared with nu…

I spent my career building software for executives that wanted to know exactly what they were going to get and when because they have budgets and deadlines i.e. the real world.

Mostly I’ve seen agile as, let’s do the same thing 3x we could have done once if we spent time on specs. The key phrase here is “requirements analysis” and if you’re not good at it either your software sucks or you’re going to iterate needlessly and waste massive time including on bad architecture. You don’t iterate the foundation of a house.

I see scenarios where Agile makes sense (scoped, in house software, skunk works) but just like cloud, jwts, and several other things making it default is often a huge waste of $ for problems you/most don’t have.

Talk to the stakeholders. Write the specs. Analyze. Then build. “Waterfall” became like a dirty word. Just because megacorps flubbed it doesn’t mean you switch to flying blind.

Re: Automatic Programming

#45
post #23

"I automatically programmed it" doesn't really roll off the tongue, nor does it make much sense - I reckon we need a better term. It certainly quicker (and at times, more fun!) to develop this way, that is for certain.

"Throwaway prototype" - that's the traditional term for this.

Re: Automatic Programming

#46
post #26
post #23

"I automatically programmed it" doesn't really roll off the tongue, nor does it make much sense - I reckon we need a better term. It certainly quicker (and at times, more fun!) to develop this way, that is for certain.

You will say I programmed it, there is no longer for this distinction. But then you can add that you used automatic programming in the process. But shortly there will be no need to refer to this term similarly to how today you don't specify you used an editor...

I like to think that the prompt is dark magic and the outputs are conjured. I get to feel like a wizard.

Re: Automatic Programming

#47
Thank you. I and you can be proud. Yes we can! :)

I posted yesterday about how I'd invented a new compression algorithm, and used an AI to code it. The top comment was like "You or Claude? ... also ... maybe consider more than just 1-shotting some random idea." This was apparently based on the signal that I had incorrectly added ZIP to the list of tools that uses LZW (which is a tweak of LZ78, which is a dictionary version of the back-reference variant by the same Level-Ziv team of LZ77, the thing actually used in Zip). This mistake was apparently signal that I had no idea what I was doing, was a script kiddie who had just tried to one shot some crap idea, and ended up with slop.

This was despite the code working and the results table being accurate. Admittedly the readme was hyped and that probably set this person off too. But they were so far off in their belief that this was Claude's idea, Claude's solution, and just a one-off that it seemed they not only totally misrepresented me and my work, but the whole process that it would actually take to make something like this.

I feel that perhaps someone making such comments does not have much familiarity with automatic programming. Because here's what actually happened: the path to get from my idea (intuited in 2013, but beyond my skills to do easily until using AI) was about as far from a 'one-shot' as you can get.

The first iteration (Basic LZW + unbounded edit scripts + Huffman) was roughly 100x slower. I spent hours guiding the implementation through specific optimization attempts:

- BK-trees for lookups (eventually discarded as slow).

- Then going to Arithmetic coding. First both codes + scripts, later splitting.

- Various strategies for pruning/resetting unbounded dictionaries.

- Finally landing on a fixed dict size with a Gray-Code-style nearest neighbor search to cap the exploration.

The AI suggested some tactical fixes (like capping the Levenshtein table, splitting edits/codes in Arithemtic coding), but the architectural pivots came from me. I had to find the winning path.

I stopped when the speed hit 'sit-there-and-watch-it-able' (approx 15s for 2MB) and the ratio consistently beat LZW (interestingly, for smaller dics, which makes sense, as the edit scripts make each word more expressive).

That was my bar: Is it real? Does it work? Can it beat LZW? Once it did, I shared it. I was focused on the bench accuracy, not the marketing copy. I let the AI write the hype readme - I didn't really think it mattered. Yes, this person fixated on a small mistake there, and completely misrepresented or had the wrong model of waht it actually took to produce this.

I believe that kind of misperception must be the result of a lack of familiarity with using these tools in practice. I consider these kind of "disdain from the unserious & inexperienced" to be low quality, low effort comments than essentially equate AI with clueless engineers and slop.

As antirze lays out: the same LLMs depending on the human that is guiding the process with their intuition, design, continuous steering and idea of software.

Maybe some people are just pissed off - maybe their dev skills sucked beofre AI, and maybe they still suck with AI, and now they are mad at everything good people are doing with AI, and AI itself?

Idk, man. I just reckon this is the age where you can really make things happen, that you couldn't make before, and you should be into and positive. If you are a serious about making stuff. And making stuff is never easy. And it's always about you. A master doesn't blame his tools.

Re: Automatic Programming

#48
post #18

> Pre-training is, actually, our collective gift I feel like this wording isn't great when there are many impactful open source programmers who have explicitly stated that they don't want their code used to train these models and licensed their work in a world where LLMs didn't exist. It wasn't their "gift", it was unwillingly taken from them. > I'm a programmer, and I use automatic programming. The code I generate i…

when you inplement a quick sort, do you credit Hoare in the comments?

No, in the same way that I wouldn't cite Euler every time I used one of his theorems - because it's so well known that its history is well documented in countless places.

However, if I was using a more recent/niche/unknown theorem, it would absolutely be considered bad practice not to cite where I got it from.

Re: Automatic Programming

#49

I have 30+ years of industry experience and I've been leaning heavily into spec driven development at work and it is a game changer. I love programming and now I get to program at one level higher: the spec. I spend hours on a spec, working with Claude Code to first generate and iterate on all the requirements, going over the requirements using self-reviews in Claude first using Opus 4.5 and then CoPilot using GPT-5.…

As it is so often in life, extreme approaches are often bad. If you do pure waterfall you risk finding out very late that your plan might not work out, either because of unforeseen technical difficulties implementing it, the given requirements actually being wrong/incomplete or just simply missing the point in time where you planned enough. If you do extreme agile you often end up with a shit architecture which actually, among other things, hurt your future agility but you get a result which you can validate against reality. The "oh, I didn't think of that" is definitely present in both extremes.

Re: Automatic Programming

#50

I have 30+ years of industry experience and I've been leaning heavily into spec driven development at work and it is a game changer. I love programming and now I get to program at one level higher: the spec. I spend hours on a spec, working with Claude Code to first generate and iterate on all the requirements, going over the requirements using self-reviews in Claude first using Opus 4.5 and then CoPilot using GPT-5.…

I believe the future of programming will be specs so I’m curious to ask you as someone who operates this way already, are there any public specs you could point to worth learning from that you revere? I’m thinking the same way past generations were referred to John Carmack’s Quake code next generations will celebrate great specs.
Post reply on HN