Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

askmike.org

Post reply on HN
Print view View original

81–90 of 91 posts

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

#81

Post by gridspy »

jbeninger wrote: post #77
youre-wrong3 wrote: post #70

Earlier quoted context omitted.

> However often the best way to handle grunt work is to write better abstractions, something AI sucks at. If you checked out of ai in 2023 then this is true. It’s simply not true anymore. If you struggle then it’s a skill issue not an AI issue

As someone who spends way too much time searching for the best abstractions, absolutely this is still true. I often have a long back and forth with codex to explore the problem space and settle on the best abstractions. Occasionally it will make a suggestion that helps me, but for the most part it's reviewing while I'm in the driver's seat. Contrast this to simply giving it a function name and a vague description of…

That's my experience too. Its unfair to expect current AI to do this - since good abstractions are extremely task specific. Hard to train on that.

What's also annoying is that AI's approach is not consistent within a project, a different sort of complexity.

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

#82

Post by names_are_hard »

ThunderSizzle wrote: post #76
gridspy wrote: post #71

Earlier quoted context omitted.

Impressive, also horrifying. I love what I do and if AI can do it better than that sucks. Anyway the use case for me is to realize a new visual style through graphics programming. It's a lot less measurable for an interative AI agent than "Meet this hardware specification from a device with a discoverable API" I have no doubt AI could create a LOT of variations on "a new visual style" but it's less controllable than…

Right now, at least, I haven't found an AI capable of replacing a software engineer. Ive seen AI that can easily replace basic programmers, however. I also think AI can replace non-coding artitects, and probably most middle management type jobs (my company has 6 levels of management between the CEO and "individual contributors" in my area (8 counting inclusivity)). That's a lot of management levels, and every level h…

Can you explain the fraud disincentive bit? I feel like there's something obvious I'm missing, but why would a manager earning less than their reports make fraud more likely?

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

#83

Post by names_are_hard »

thec0d3 wrote: post #67
simonw wrote: post #40

Earlier quoted context omitted.

Yeah, that's a fair point. I have plenty of older projects where I no longer understand how they work despite having written the code myself. I guess the key thing is that you need to be able to demonstrate to yourself that you understand the code at least once, because that means you should be able to revise how it works in the future. You also can't evaluate if a solution is fit for purpose if you don't understand…

You don't buy the article's position but have forgotten a lot and not known a lot; so no need to care about your opinion I guess This is my beef with modern software engineers; complete detachment from physical reality where entropy is eroding structure (memory, generational churn). Code is just a euphemism for a desired electrical state. No need to dump biz contexts in code. Just make a game engine that efficiently…

This is either incredibly advanced, genius-level insight into the future of software engineering, or absolutely nonsensical gibberish. I'm not smart enough to tell which, I suppose we'll find out.

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

#84

Post by jpollock »

If you can't look at the code, you need to trust interfaces to specify (and constrain) the implementation. The implementation needs to implement the entire interface and can't do anything not in the interface.

Otherwise, you're going to get bit by the Law of Leaky Abstractions.

The number of times I've been bit by systems not adhering to interfaces? Yeah, that's pretty frequent.

For example (from personal experience), the interface allows for race conditions, it's obvious they can happen (distributed systems), but the implementation didn't allow them, resulting in fun times.

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

#85

Post by lelanthran »

simonw wrote: post #75
lelanthran wrote: post #56

Earlier quoted context omitted.

As that link says, this approach is used in Maths textbooks, and yet, as the parent of two kids, I have never come across a single student who is able to pass trig without working the problems. If reality differs from the results of academic studies, it's not the reality that is wrong.

The worked-example effect doesn't say that worked examples replace exercises. It says that worked examples prior to exercises beats exercises alone. There's a section on that page about faded worked examples: > "In order to facilitate the transition from learning from worked examples in earlier stages of skill acquisition to problem solving in later stages, it is effective to successively fade out worked solution ste…

> The worked-example effect doesn't say that worked examples replace exercises. It says that worked examples prior to exercises beats exercises alone.

I'm confused now; you say that reading + doing beats doing alone, which does not conflict with my point that you can't learn by reading alone.

It sounds like we're in agreement that reading alone is insufficient.

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

#86

Post by sshine »

> if a seasoned programmer sits behind Claude Code, the quality output will likely be higher than if a non technical person does it

Anecdotal: I recently rewrote a service in Rust for a much needed 100x performance boost (largely due to architectural changes, somewhat due to better runtime).

My colleague who now maintains the app is not a Rust developer and knows little about threads and tokio. Debugging a problem, he said he’d reach the context window before pinning the problem. I never have that problem and effortlessly find problems in the first 100k tokens without trying.

The difference must be in the wording that initially guides the agent.

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

#87

Post by andai »

thec0d3 wrote: post #67
simonw wrote: post #40

Earlier quoted context omitted.

Yeah, that's a fair point. I have plenty of older projects where I no longer understand how they work despite having written the code myself. I guess the key thing is that you need to be able to demonstrate to yourself that you understand the code at least once, because that means you should be able to revise how it works in the future. You also can't evaluate if a solution is fit for purpose if you don't understand…

You don't buy the article's position but have forgotten a lot and not known a lot; so no need to care about your opinion I guess This is my beef with modern software engineers; complete detachment from physical reality where entropy is eroding structure (memory, generational churn). Code is just a euphemism for a desired electrical state. No need to dump biz contexts in code. Just make a game engine that efficiently…

I often find that what is considered easy in programming is actually hard, and what is considered hard is actually easy, because the "easy" things are designed to have several layers of Rube Goldberg machines between me and what is actually going on.

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

#88

Post by deterministic »

andai wrote: post #26
simonw wrote: 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…

>you're going to end up with a system you don't 100% understand very quickly This has been my experience with all software projects. Even if I wrote all the code, my understanding of how everything works and fits together decays. ( See the Forgetting Curves https://en.wikipedia.org/wiki/Hermann_Ebbinghaus )

I can't remember what I wrote yesterday. So it forced me from an early age to not write spaghetti code. Which is a real advantage it turns out when working on large projects. And an even bigger advantage when using LLM's to code.

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

#89

Post by rsalus »

gridspy wrote: post #68
rsalus wrote: post #64

Earlier quoted context omitted.

what a patronizing response. I'd be embarrassed.

I guess you didn't understand my comment ;) Look, goals can differ. If you don't need to understand and predict every part of the code the AI is generating and you just need it to meet a "sketch" of what you want - by all means use AI. I do use AI in that situation for related or unimportant code. But if you need full understanding, in my experience the only way to get that is to program it yourself. Unless what the…

> I guess you didn't understand my comment ;)

yeah, touch grass buddy.

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

#90

Post by trollbridge »

shakna wrote: post #57
feelamee wrote: post #35

Earlier quoted context omitted.

using which floating point standard? IEEE754 is totally deterministic

The software standard is. GPU matrix calculations, are not. The hardware, has tiny shifts that rarely matter, except in high finance and... AI modeling.

What kind of nonsense is this? Matrix math is entirely deterministic.
Post reply on HN