Live data from Hacker News

What my dad taught me about AI coding in the 90s

askmike.org

41–50 of 91 posts

Re: What my dad taught me about AI coding in the 90s

#41

Earlier quoted context omitted.

> You learn a lot more by reading code than writing it. "You learn a lot more by reading trigonometry than by doing problems" See how ridiculous that sounds?

> See how ridiculous that sounds? For most of us, writing code is the way to carve out intuition into an artifact. But, I have noticed some people are able to read deeply - and by that I mean, reverse the code to understand the intuition that brought it to life. This is a rare skill and I dont have it, but some do. Not just for code, but also for any book - fiction or non-fiction - some are able to deconstruct the sc…

I feel one need to also have developed the intuition by writing lots of code for reading to be really effective.

An an analogy I’m reading a lot of German those days as I’m aiming to become fluent, and it’s very effective to improve only because I spend so much time developing a the intuition by going through the whole grammar, forcing myself to write, forcing myself to speak, etc. Doing only the reading improves your pattern recognition, but doesn’t make you go as deep as one who also writes and speak. If you combine the different aspects they reinforce each other and you progress way faster

Re: What my dad taught me about AI coding in the 90s

#43

Earlier quoted context omitted.

You learn a lot more by reading code than writing it. So reading the output i believe is an immensely big gift by an LLM, because if you actually take note - and of course know your skills - then ot becomes such a great pal to work with. I like reading what the LMM gives me, not always, but a lot of times.

> You learn a lot more by reading code than writing it. "You learn a lot more by reading trigonometry than by doing problems" See how ridiculous that sounds?

Have you heard of the worked-example effect https://en.wikipedia.org/wiki/Worked-example_effect ?

It's quite a surprising result: it turns out that there are cases where seeing someone else work through a worked example is more effective than struggling through the problem yourself.

(Obviously it doesn't apply universally, but your "see how ridiculous that sounds?" suggests to me you may not have heard of this before.)

Re: What my dad taught me about AI coding in the 90s

#44
post #2

I'm not completely convinced by this comparison between blind chess and prompting LLMs. In blind chess you get deterministic information about the state of the board: each mental update to your board model can be precise, and you have the full state at every point in time. LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next. I suppo…

LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next. An LLM can be made to be completely deterministic. I use them in this mode so I can reproduce test cases. Of course it requires complete control over the model, etc. but this myth that a computer program is non-deterministic needs to end. You can 100% predict where the weights “wi…

I think when people say non-deterministic what they mean is closer to chaotic, like https://en.wikipedia.org/wiki/Chaos_theory as in very small changes in conditions can produce completely different output making predictions difficult

Re: What my dad taught me about AI coding in the 90s

#45
post #42

The analogy can be dragged one step further: once the engine is good enough, it’s functionally impractical for a human to play.

I disagree. A chess engine has a very well defined goal and is working its patterns to reach that goal.

In software development, except in a minority of cases, the goal is being set by non-technical people, who have no clue how the resulting system should end up, only what it should look like to a user. I think a well-versed programmer can give the AI direct instructions on how to implement something, and just let the LLM write the code to implement/refactor the infrastructure behind the feature they're developing. For me the plan mode of Claude Code is (anecdote incoming) much faster(TM) and better(TM) if I give it concrete instructions - then it writes the plan, asks questions - and then implements it. Very little complaints after that (I usually don't let Claude do any sort of visual QA)

Re: What my dad taught me about AI coding in the 90s

#46
post #41

Earlier quoted context omitted.

> See how ridiculous that sounds? For most of us, writing code is the way to carve out intuition into an artifact. But, I have noticed some people are able to read deeply - and by that I mean, reverse the code to understand the intuition that brought it to life. This is a rare skill and I dont have it, but some do. Not just for code, but also for any book - fiction or non-fiction - some are able to deconstruct the sc…

I feel one need to also have developed the intuition by writing lots of code for reading to be really effective. An an analogy I’m reading a lot of German those days as I’m aiming to become fluent, and it’s very effective to improve only because I spend so much time developing a the intuition by going through the whole grammar, forcing myself to write, forcing myself to speak, etc. Doing only the reading improves you…

> I feel one need to also have developed the intuition by writing lots of code for reading to be really effective.

This is one of the problems young engineers are going to face who rely excessively on AI to generate code. Their intuitions on what constitutes good code will not sharpen, since they are not exercising the tool that sharpens it which is writing code. Intuitions start fuzzy, and incorrect, and gradually sharpen with precise communication of said intuition in the form of writing code or proofs. Reading alone may delude one into a sense of false mastery where intuitions are actually fuzzy, but one thinks otherwise.

Re: What my dad taught me about AI coding in the 90s

#48

I think I agree. I guess I don't know enough about chess to be sure, but the idea seems to be that although to novices a blindfolded player must reconstruct the board in his mind, that is not actually what is done by the expert. That is something I can agree with, having spent a heck of a long time coding in the trading domain. I've managed to vibe code a trading system. It's a hobby project directed on my phone on m…

[deleted]

Re: What my dad taught me about AI coding in the 90s

#49
it's a Sunday - I don't have time to put things into buckets.

there's coding - writing code to do something could be a game, utility to move files around. what have you. inherently the nature is a closed domain. AI is perfect here - the impact if something goes wrong is close to 0 or null.

then there's software engineering - which is both an art & science. u r dealing with rules of thumb. nothing is ever coded / written down. but a feel to whether something feels right or not. the domain is unbounded. the impact of something going wrong is catastrophic in all dimensions. coding is a delivery mechanism for software engineering. but not the actual work. using A.I here is useless.

but we keep having these pieces - I guess that's just shallow the industry is.

Re: What my dad taught me about AI coding in the 90s

#50
post #14

Earlier quoted context omitted.

LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next. An LLM can be made to be completely deterministic. I use them in this mode so I can reproduce test cases. Of course it requires complete control over the model, etc. but this myth that a computer program is non-deterministic needs to end. You can 100% predict where the weights “wi…

Floating point matrix calculations are non-deterministic. You need to invent new hardware, that doesn't use floating point math, first. [0] [0] https://arxiv.org/html/2506.09501

Floating point math is entirely deterministic. For a given set of inputs, the same outputs come out, every time.
Post reply on HN