Live data from Hacker News

AI makes the easy part easier and the hard part harder

blundergoat.com

141–150 of 382 posts

Re: AI makes the easy part easier and the hard part harder

#141
> Reading and understanding other people's code is much harder than writing code.

I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it.

For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place.

And obviously, if it took longer to read code than to write it, teams would be spending the majority of their time in code review, but they don't.

So where is this idea coming from?

Re: AI makes the easy part easier and the hard part harder

#142

> Reading and understanding other people's code is much harder than writing code. I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it. For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place. And…

Because to verify something is correct you have to understand the what makes it correct which is 99% of writing the code in the first place.

Re: AI makes the easy part easier and the hard part harder

#143

Earlier quoted context omitted.

Its license washing. The code is great because its already a problem solved by someone else. The AI can spit out the solution with no license and no attribution and somehow its legal. I hope American tech legislation holds that same energy once others start taking American IP and spitting it back out with no license or attribution.

Do you give attribution to all the books, articles, etc. you've read? Everything is a derivative work.

No but for a while we were required to pay amazon when we implemented a way to save payment details on a website.

Re: AI makes the easy part easier and the hard part harder

#144

> Reading and understanding other people's code is much harder than writing code. I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it. For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place. And…

I like to think of it as the distinction between editor and reader. Like you said, it's quite easy to read code. I heavily agree with this. I don't professionally write C but I can read and kinda infer what C devs are doing.

But if I were an "editor," I actually take the time to understand codepaths, tweak the code to see what could be better, actually try different refactoring approaches while editing. Literally seeing how this can be rewritten or reworked to be better, that takes considerable effort but it's not the same as reading.

We need a better word for this than editor and reading, like something with a dev classification too it.

Re: AI makes the easy part easier and the hard part harder

#145

> Reading and understanding other people's code is much harder than writing code. I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it. For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place. And…

Because to verify something is correct you have to understand the what makes it correct which is 99% of writing the code in the first place.

That doesn't make any sense to me.

When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader.

But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works, try integrating with a function from 3 different packages until you find the one that works properly, hunt down documentation on another function you have to integrate with, and make a bunch of mistakes that you need to debug until it produces the correct result across unit test coverage.

There's so much time spent on false starts and plumbing and dead ends and looking up documentation and debugging when you code. In contrast, when you read code that already has passing tests... you skip all that stuff. You just ensure it does what it claims and is well-written and look for logic or engineering errors or missing tests or questionable judgment. Which is just so, so much faster.

Re: AI makes the easy part easier and the hard part harder

#146

Earlier quoted context omitted.

I view LLMs akin to a dictionary - has a bunch of stuff in there but by itself it doesn't add any value. The value comes from the individual piecing together the stuff. Im observing this in the process of using Grok to put together a marketing video - theres a whole bunch of material that the LLM can call upon to produce an output. But its on you to prompt/provide it the right input content to finesse what comes out…

> I view LLMs akin to a dictionary …If every time you looked at the dictionary it gave you a slightly different definition, and sometimes it gave you the wrong definition!

Go look up the same word across various dictionaries - they do not have a 1:1 copy of the descriptions of terms.

Reproducibility is a separate issue.

Re: AI makes the easy part easier and the hard part harder

#147

Earlier quoted context omitted.

Because to verify something is correct you have to understand the what makes it correct which is 99% of writing the code in the first place.

That doesn't make any sense to me. When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader. But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works, try integrating with a function from 3 different packages until you find the one that works properly, h…

> But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works , try integrating with a function from 3 different packages until you find the one that works properly

If you haven’t spent the time to try the different approaches yourself, tried the different packages etc., you can’t really judge if the code you’re reading is really the appropriate thing. It may look superficially plausible and pass some existing tests, but you haven’t deeply thought through it, and you can’t judge how much of the relevant surface area the tests are actually covering. The devil tends to be in the details, and you have to work with the code and with the libraries for a while to gain familiarity and get a feeling for them. The false starts and dead ends, the reading of documentation, those teach you what is important; without them you can only guess. Wihout having explored the territory, it’s difficult to tell if the place you’ve been teleported to is really the one you want to be in.

Re: AI makes the easy part easier and the hard part harder

#148
Don't let AI write code for you unless it's something trivial. Instead use it to plan things, high level stuff, discuss architecture, ask it to explain concepts. Use it as a research tool. It's great at that. It's bad at writing code when it needs to be performant or needs to span over multiple files. Especially when it spans over multiple files because that's where it starts hallucinating and introducing abstractions and boilerplate that's not necessary and it just makes your life harder when it comes to debugging.

Imagine if every function you see starts checking for null params. You ask yourself: "when can this be null", right ? So it complicates your mental model about data flow to the point that you lose track of what's actually real in your system. And once you lose track of that it is impossible to reason about your system.

For me AI has replaced searching on stack overflow, google and the 50+ github tabs in my browser. And it's able to answer questions about why some things don't work in the context of my code. Massive win! I am moving much faster because I no longer have to switch context between a browser and my code.

My personal belief is that the people who can harness the power of AI to synthesize loads of information and keep polishing their engineering skills will be the ones who are going to land on their feet after this storm is over. At the end of the day AI is just another tool for us engineers to improve our productivity and if you think about what being an engineer looked like before AI even existed, more than 50% of our time was sifting through google search results, stack overflow, github issues and other people's code. That's now gone and in your IDE, in natural language with code snippets adapted to your specific needs.

Re: AI makes the easy part easier and the hard part harder

#149
post #24

Earlier quoted context omitted.

I call these "embarrassingly solved problems". There are plenty of examples of emulators on GitHub, therefore emulators exist in the latent spaces of LLMs. You can have them spit one out whenever you want. It's embarrassingly solved. There are no examples of what you tried to do.

Its license washing. The code is great because its already a problem solved by someone else. The AI can spit out the solution with no license and no attribution and somehow its legal. I hope American tech legislation holds that same energy once others start taking American IP and spitting it back out with no license or attribution.

At the end of the day it's up to the publisher of the work to attribute the sources that might end up in some commercial or public software derivative.

Re: AI makes the easy part easier and the hard part harder

#150

Daily agentic user here, and to me the problem here is the very notion of "vibe coding". If you're even thinking in those terms - this idea that never looking at the code has become a goal unto itself - then IMO you're doing LLM-assisted development wrong. This is very much a hot take, but I believe that Claude Code and its yolo peers are an expensive party trick that gives people who aren't deep into this stuff an a…

good take, I wish opus 4.6 wasn't so pricy its great for planning.

I've been using 4.6 to do planning, and then switching to 4.5 for agent/debug.

4.5 sticks to a 200k context window, which is how you keep costs sane.

Post reply on HN