Hacker News new | ask | show | jobs
by bluegatty 12 hours ago
It's obviously useful - we have to figure out best practices.
1 comments

It is most certainly not obviously useful. To anyone who actually cares about quality and not just turning out slop, you have to spend so much time reviewing the code the machine generated that you wind up not saving any time. There are lots of people who don't give a damn about quality, but those were terrible developers before LLMs and remain so now.
It's delusional for someone to contemplate that millions of developers out there are just churning out 'non usable stuff' and don't care about quality and that somehow you have some 'magic insight' they don't have.

And lacking in self awareness to publicize that.

Obviously some people are using it recklessly, it's the same with everything.

Do you think it's more likely that 'the entire world is wrong and you are right' ... OR ... that you just personally have not figured out how to use the technology in way that makes sense and/or you have a bad sense of of what quality means in most contexts.

AI produces easily 'better than human' code where it has a lot of guardrails, and is probably 10x better than humans at hunting down and fixing bugs.

Software is 90% 'maintenance' , and a well maintained code base provide ample basis for the AI to understand what design and formatting to use for a given solution.

It definitely falls down on it's own architecture, it's not that hard to work along with the AI.

It doesn't matter what we think of Altman or whoever, or whatever or AGI or 'the bubble' - that's all noise. It's literally the most blatantly obvious 'useful' thing to happen to tech since the advent of machines - it takes a 'collapse of intellectual contextualization' to not realize that.

You're watching cars replace horses, they are not the same thing.

> Do you think it's more likely that 'the entire world is wrong and you are right' ... OR ... that you just personally have not figured out how to use the technology in way that makes sense and/or you have a bad sense of of what quality means in most contexts.

Yeah, see, I've seen this movie before. I've seen it with Lisp. "You just haven't used it enough to reach enlightenment! We all have! Keep going; you'll see it too!"

And then with Haskell. Exact same looking down on everyone who doesn't agree as unenlightened, as people who Just Don't Get It.

Both Lisp and Haskell are useful languages. Neither is the future of mainstream programming, not just because the mainstream is unenlightened, but because those languages don't fit the way most programmers think.

People are different. Different languages fit different people. If Lisp fits how you think, when you find it after wandering through procedural languages, it feels incredibly freeing. But if it doesn't fit...

So I get very nervous about "you just haven't figured out how to use it" claims. Maybe it's true. Or maybe it just doesn't fit a bunch of people, and browbeating them with claims that they're unskillful does not make it fit them any better.

Even if you have a moral opposition to a single line of LLM-generated code marring your codebase (not even unit tests!) it can be incredibly useful to assist with reading code.

Take a complex, sophisticated codebase you wrote, that only you have deep understanding of, and throw Codex or Claude at it and ask it questions. How does the Foo work? What happens if the user tries to Frozzle a Bar? Give me a guided tour of how the Baz feature was implemented, top to bottom of the stack.

Personally, I was amazed at how accurate the results were, on a codebase where I knew the answers already. Try to pretend that's not a useful tool to use when you have to fix bugs or add features to a large codebase you aren't already familiar with.

> Try to pretend that's not a useful tool to use when you have to fix bugs or add features to a large codebase you aren't already familiar with.

how will I know the answers are accurate?

You take advantage of the property that verifying / sanity-checking an answer is usually much easier and faster than figuring out the answer in the first place.

It's similar to how Google has been useful for the past few decades despite the internet being full of junk info. Except Google could only provide semi-reliable information about stuff that's public knowledge with lots of people talking about it, whereas Claude can provide semi-reliable information about your own code that nobody else has ever laid eyes on.

A few months ago I used this to re-acquaint myself with code I myself had written back in 2017-2018[1]. I wanted to add some new features, and I did NOT want AI to write them, because the existing codebase was my own sweat and tears and running it through the slop extruder would cheapen that original work. I wanted to write all the code myself with full understanding of what was going on. Now, it had been many years and the codebase did some pretty esoteric stuff. I was the only person in the world who ever knew what that code did, and I didn't know it like the back of my hand anymore. Particularly the stuff with runtime CIL generation for result set processing.

I did a lot of reading my own code and a lot of thinking about it to get that understanding back, but it was a very helpful tool to be able to bounce my questions off an agent during the process and then investigate its answers for accuracy. And greater than 90% of the time its answers turned out to be correct.

[1]https://github.com/fsprojects/Rezoom.SQL

> you have to spend so much time reviewing the code

Why? Unless you foolishly choose to target something like Javascript, or Python, or the like where the training corpus was full of poor quality code then the LLMs stay pretty true to how you'd write the code yourself. LLMs are only as good as what they were trained on, but luckily there was already a strong movement towards "all codebases should be the same" before LLMs, and as long as you hone in on those ecosystems then LLMs trained on those ecosystems can work quite well at producing quality code without the need for heavy oversight.

For bespoke things you 100% have to read the code, and for very straight forward SaaS stacks you still have to read.

It depends on how much 'rails' there are.

More rails, then there is a lot less to examine.

Why? I agree if you have chosen an ill-fitted technology stack where those aforementioned developers who didn't care about quality before LLMs tainted the training data then you do have to carefully read the code to watch for the LLM going crazy, because they will, but if you have chosen a suitable technology stack where the training data is overwhelmingly of high quality, then what need is there to read it? You already know that the quality will be on par with what you would have written yourself.

You might find it to be an interesting read, but the software will be fine if you don't.