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

AI makes the easy part easier and the hard part harder

blundergoat.com

Post reply on HN
Print view View original

131–140 of 382 posts

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

#131

Post by airstrike »

wtetzner wrote: post #126
airstrike wrote: post #11

Earlier quoted context omitted.

Illogical. I had Claude read a 2k LOC module on my codebase for a bug that was annoying me for a while. It found it in seconds, a one line fix. I had forgotten to account for translation in one single line. That's objectively valuable. People who argue it has no value or that it only helps normies who can't code or that sooner or later it will backfire are burying their heads in the sand.

This feels like a strawman. Most criticisms of AI for coding are about how overblown the claimed benefits are, not that there are no benefits.

While that may very well be true, it's a valid reply to the GP who made this claim, not to my comment explaining to the parent why their argument was logically flawed.

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

#132

Post by marcus_holmes »

I think the author answers their own question at the end.

The first 3/4 of the article is "we must be responsible for every line of code in the application, so having the LLM write it is not helping".

The last 1/4 is "we had an urgent problem so we got the LLM to look at the code base and find the solution".

The situation we're moving to is that the LLM owns the code. We don't look at the code. We tell the LLM what is needed, and it writes the code. If there's a bug, we tell the LLM what the bug is, and the LLM fixes it. We're not responsible for every line of code in the application.

It's exactly the same as with a compiler. We don't look at the machine code that the compiler produces. We tell the compiler what we want, using a higher-level abstraction, and the compiler turns that into machine code. We trust compilers to do this error-free, because 50+ years of practice has proven to us that they do this error-free.

We're maybe ~1 year into coding agents. It's not surprising that we don't trust LLMs yet. But we will.

And it's going to be fascinating how this changes the Computer Science. We have interpreted languages because compilers got so good. Presumably we'll get to non-human-readable languages that only LLMs can use. And methods of defining systems to an LLM that are better than plain English.

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

#133

Post by phpnode »

AuthAuth wrote: post #54
zjp wrote: 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.

The other day I had an agent write a parser for a niche query language which I will not name. There are a few open source implementations of this language on github, but none of them are in my target language and none of them are PEGs. The agent wrote a near perfect implementation of this query language in a PEG. I know that it looked at the implementations that were on github, because I told it to, yet the result is nothing like them. It just used them as a reference. Would and should this be a licensing issue (if they weren't MIT)?

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

#134

Post by johnbender »

marcus_holmes wrote: post #132

I think the author answers their own question at the end. The first 3/4 of the article is "we must be responsible for every line of code in the application, so having the LLM write it is not helping". The last 1/4 is "we had an urgent problem so we got the LLM to look at the code base and find the solution". The situation we're moving to is that the LLM owns the code. We don't look at the code. We tell the LLM what i…

Compilers don’t do this error free of course BUT if we want them too we can say what it means for a compiler to be correct very directly _one time_ and have it be done for all programs (see the definition for simulation in the CompCert compiler). This is a major and meaningful difference from AI which would need such a specification for each individual application you ask it to build because there is no general specification for correct translation from English to Code.

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

#135

Post by richardw »

sdf2erf wrote: post #129
Nition wrote: post #59

Earlier quoted context omitted.

In a way it shows how poorly we have done over the years in general as programmers in making solved problems easily accessible instead of constantly reinventing the wheel. I don't know if AI is coming up with anything really novel (yet) but it's certainly a nice database of solved problems. I just hope we don't all start relying on current[1] AI so much that we lose the ability to solve novel problems ourselves. [1]…

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!

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

#136

Post by DrewADesign »

seanmcdirmid wrote: post #46
DrewADesign wrote: post #40

Earlier quoted context omitted.

I don’t understand why people are so resistant to the idea that use cases actually matter here. If someone says “you’re an idiot because you aren’t writing good, structured prompts,” or “you’re too big of an idiot to realize that your AI-generated code sucks” before knowing anything about what the other person was trying to do, they’re either speaking entirely from an ideological bias, or don’t realize that other peo…

We don’t know anything about the commenters other than that they aren’t getting the same results with AI as we are. It’s like if someone complains that since they can’t write fast code and so you shouldn’t be able to either?

> We don’t know anything about the commenters other than that they aren’t getting the same results with AI as we are.

Right. You don’t know what model they’re using, on what service, in what IDE, on what OS, if they’re making a SAP program, a Perl 5 CGI application, a Delphi application, something written in R, a c-based image processing plugin, a node website, HTML for a static site, Excel VBA, etc. etc. etc.

> It’s like if someone complains that since they can’t write fast code and so you shouldn’t be able to either?

If someone is saying that nobody can get good results from using AI then they’re obviously wrong. If someone says that they get good results with AI and someone else, knowing nothing about their task, says they’re too incompetent to determine that, then they’re wrong. If someone says AI is good for all use cases they’re wrong. If someone says they’re getting bad results using AI and someone else, knowing nothing about their task, says they’re too incompetent to determine that, then they’re wrong.

If you make sweeping, declarative, black-and-white statements about AI coding either being good or bad, you’re wrong. If you make assumptions about the reason someone has deemed their experience with AI coding good or bad, not even knowing their use case, you’re wrong.

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

#137

Post by thaumasiotes »

BobbyJo wrote: post #102
Nition wrote: post #59

Earlier quoted context omitted.

In a way it shows how poorly we have done over the years in general as programmers in making solved problems easily accessible instead of constantly reinventing the wheel. I don't know if AI is coming up with anything really novel (yet) but it's certainly a nice database of solved problems. I just hope we don't all start relying on current[1] AI so much that we lose the ability to solve novel problems ourselves. [1]…

> In a way it shows how poorly we have done over the years in general as programmers in making solved problems easily accessible instead of constantly reinventing the wheel. I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again. Even high traffic libraries that solve some super common proble…

> I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again.

What kranner said. There was never an accessibility problem for emulators. The reason there are a lot of emulators on github is that a lot of people wanted to write an emulator, not that a lot of people wanted to run an emulator and just couldn't find it.

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

#139

Post by raw_anon_1111 »

socketcluster wrote: post #27

I think AI is just a massive force multiplier. If your codebase has bad foundation and going in the wrong direction with lots of hacks, it will just write code which mirrors the existing style... And you get exactly was OP is suggesting. If however, your code foundations are good and highly consistent and never allow hacks, then the AI will maintain that clean style and it becomes shockingly good; in this case, the p…

I agree completely.

I just did my first “AI native coding project”. Both because for now I haven’t run into any quotas using Codex CLI with my $20/month ChatGPT subscription and the company just gave everyone an $800/month Claude allowance.

Before I even started the implementation I:

1. Put the initial sales contract with the business requirements.

2. Notes I got from talking to sales

3. The transcript of the initial discovery calls

4. My design diagrams that were well labeled (cloud architecture and what each lambda does)

5. The transcript of the design review and my explanations and answering questions.

6. My ChatGPT assisted breakdown of the Epics/stories and tasks I had to do for the PMO

I then told ChatGPT to give a detailed breakdown of everything during the session as Markdown

That was the start of my AGENTS.md file.

While working through everything task by task and having Codex/Claude code do the coding, I told it to update a separate md file with what it did and when I told it to do something differently and why.

Any developer coming in after me will have complete context of the project from the first git init and they and the agents will know the why behind every decision that was made.

Can you say that about any project that was done before GenAI?

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

#140

Post by marcus_holmes »

johnbender wrote: post #134
marcus_holmes wrote: post #132

I think the author answers their own question at the end. The first 3/4 of the article is "we must be responsible for every line of code in the application, so having the LLM write it is not helping". The last 1/4 is "we had an urgent problem so we got the LLM to look at the code base and find the solution". The situation we're moving to is that the LLM owns the code. We don't look at the code. We tell the LLM what i…

Compilers don’t do this error free of course BUT if we want them too we can say what it means for a compiler to be correct very directly _one time_ and have it be done for all programs (see the definition for simulation in the CompCert compiler). This is a major and meaningful difference from AI which would need such a specification for each individual application you ask it to build because there is no general speci…

> there is no general specification for correct translation from English to Code.

that's an interesting point. Could there be?

COBOL was originally an attempt to do this, but it ended up being more Code than English.

I think this is the area we need to get better at if we're to trust LLMs like we trust compilers.

I'm aware that there's a meme around "we have a method of completely specifying what a computer system should do, it's the code for that system". But again, there are levels of abstraction here. I don't think our current high-level languages are the highest possible level of abstraction.

Post reply on HN