Live data from Hacker News

The AI coding trap

chrisloy.dev

411–420 of 424 posts

Re: The AI coding trap

#412
post #379

Earlier quoted context omitted.

The difficulty is we skeptics have read claims like yours tens of times, and our response is always, "please share a repo built this way and an example of your prompts," and I at least have never seen anyone do so. I'd love for what you say to be possible. Comments like yours often cause me to take another crack at agentic workflows. I'm disappointed every time.

I can back that claim up. Unfortunately, I've only worked on proprietary codebases and I can't share them. However before I left my previous gig at PermitFlow I was primarily using Claude Code for all of my work. I don't view LLMs as ways of foregoing the responsibility of writing code and rather see it as my "really smart keyboard". With enough context priming and a well structured codebase I no longer need to spend…

If you do wrote that blog, I'd love to read it! My email is in my bio if you get time to start it.

Re: The AI coding trap

#413

Earlier quoted context omitted.

> I have written a 1000 LOC program in C using an LLM. > I have reviewed it "line by line" though, I do not know why I would not do this. 1k LOC is not that much. I can easily do this in a day's project. But it's pretty rare you're going to be able to review every line in a mature project, even if you're developing that project. Those can contain hundreds or even thousands of files with hundreds (hopefully not thousa…

So when people talk about safety, it does matter in Rust, right? Because "1k LOC is not that much. I can easily do this in a day's project.". Why should we choose Rust over anything below 100k LOC if it is nothing? I am just asking. Everyone says 1k LOC is nothing, yet they want to replace 1k LOC in C with 1k LOC in Rust. You can do it in day. You are a professional! Or what is your point? That 1k LOC projects are us…

  > when people talk about safety, it does matter in Rust, right?
I'm not sure I would make this about languages. Different languages have different advantages, but there's always a trade-off, right? For example, this `cp` issue is a bit of a problem for the coreutils rewrite[0]. I think you gotta ask the question: what benefit does rewriting in rust provide? Potentially more safety, but also something like coreutils has been heavily investigated for the past few decades. Rewriting also comes with the chance of introducing new bugs. So is it safer? Hard to say, right? Especially since Rust is still new and there's not a lot of major software written in it.

  > Everyone says 1k LOC is nothing
  > Or what is your point?
The point we're trying to make is that lines of code are not the bottleneck. Probably one of the big problems with our industry right now is an over reliance on metrics (KPIs). But what can you measure in coding? Lines? Commits? Tickets? Is any of that meaningful?

I said in another comment[1] that I've spent hours or days to write /one line/ of code, or even partial. Does that mean I was doing a bad job? Was I just slacking off? I think this is something many developers have experienced. Were we all lazy? Dumb?

I'd argue that you can't answer that question from the information alone. Sometimes a single line of code is crazy hard to figure out. If you haven't seen this before, allow me to introduce you to some old coding lore[2]

  //When I wrote this, only God and I understood what I was doing
  //Now, God only knows
The thread has other examples of where people have wasted time trying to understand some "magic". Or maybe you know Carmack's Fast Inverse Square Root Algo[3]. Look at that one. It's 7 LOC (5?) yet those lines are so powerful. That is not the type of code someone writes in a flow state, off the top of their head. That is the type of code you write because you used a profiler[4], found the bottleneck, and optimized the crap out of it. Writing 7 lines takes no time, but I'm sure that code took at least a week to write.

The point here is that it is really hard to measure the quality and effectiveness of a programmer. The context of the problem is not something that can be abstracted away when evaluating them. Unfortunately, this means to evaluate them you also need to be an expert programmer AND have meaningful context to understand the specific problems they are working on. There's not a thing you can do from a spreadsheet. The truth is that if you optimize from the spreadsheet you'll only introduce more Jira tickets. There's a joke that there's 2 types of 10x programmers. The other one is the programmer that introduces 100x the jira tickets while completing them 10x as fast. The problem is that that programmer doesn't see the bigger scope and makes mistakes that leads to new tickets. This might be like your new rockstar junior dev. They fill out tickets but are solving the problems in isolation, not in context of the codebase. This leads to more complexity and bugs later on, but that lag in effect is hard to measure/identify so it is easy to think they are a rockstar but actually a problem.

  > I start small, I can review just fine.
Yes, and this is how you should do it. I mentioned Unix Philosophy[5] previously. But the thing is that projects continue. Scope expands. If you want to keep writing small programs and integrate them together then you actually need to think quite carefully about the design and implementation of them (again, see Unix Philosophy).

So the point is that everything is highly context driven. That's what matters. You need nuance and care. It is not easy to say what makes good code or even identify it. So... LGTM

[0] https://github.com/uutils/coreutils/issues/7092

[1] https://news.ycombinator.com/item?id=45409430

[2] https://stackoverflow.com/questions/184618/what-is-the-best-...

[3] https://betterexplained.com/articles/understanding-quakes-fa...

[4] https://news.ycombinator.com/item?id=45060059

https://news.ycombinator.com/item?id=44416817

https://news.ycombinator.com/item?id=45060059

[5] https://en.wikipedia.org/wiki/Unix_philosophy

Re: The AI coding trap

#415

Earlier quoted context omitted.

> The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. Why? Code has always been the artifact. Thinking about and understanding the domain clearly and solving problems is where the intrinsic value is at (but I'd suspect that in the future this, too, will go away).

Code is the final artifact after everything is shipped. But while the development is active, it is more than that (at least for now), as you need to know implementation details even if you are really proficient at the domain knowledge. Although I do agree that there is a possibility that we'll build a relatively reliable abstraction using LLMs at some point, so this issue will go away. There probably be some restrict…

Binaries (or their equivalent) are the final artifact. Source code can (and has been) lost.

Re: The AI coding trap

#416

Earlier quoted context omitted.

So when people talk about safety, it does matter in Rust, right? Because "1k LOC is not that much. I can easily do this in a day's project.". Why should we choose Rust over anything below 100k LOC if it is nothing? I am just asking. Everyone says 1k LOC is nothing, yet they want to replace 1k LOC in C with 1k LOC in Rust. You can do it in day. You are a professional! Or what is your point? That 1k LOC projects are us…

> when people talk about safety, it does matter in Rust, right? I'm not sure I would make this about languages. Different languages have different advantages, but there's always a trade-off, right? For example, this `cp` issue is a bit of a problem for the coreutils rewrite[0]. I think you gotta ask the question: what benefit does rewriting in rust provide? Potentially more safety, but also something like coreutils h…

In that case, I agree with you with everything and I do actually try to do it the way you mentioned.

And I am expert programmer (I would like to believe) and I use LLMs just to get some refresher of my options and whatnot, and I choose where the project goes, with my knowledge. All my prompts are very specific, which requires knowledge.

Re: The AI coding trap

#417
post #396

Earlier quoted context omitted.

> You want something that requires an engineering breakthrough. Basically, yes. I know the way LLMs currently work wouldn't be able to provide what i want, but what i want is a different way that does :-P (perhaps not even using LLMs).

What you want is actual AGI/ASI, which is a different can of worms and likely has a whole list of different existential problems that come with it.

No, an LLM not forgetting stuff discussed minutes ago wouldn't make it AGI.

Re: The AI coding trap

#419
post #382
post #371

Earlier quoted context omitted.

LLMs can code - different products. The plural of "It" is "They". Lol.

I didnt know, I am not native and have never seen it before Like for example nobody says: They cars can be fast. People usually say: The cars are fast. Or sometimes: Them cars are fast. But never: They cars are fast.

It's all good friend. I don't think I said "they LLMs" anywhere though? I think I just said "They can code .." etc.

Re: The AI coding trap

#420
Maybe I haven't worked on tricky enough problems, but I swear people massively hype-up the difficulty of coding. The vast majority of the time there is little difficult problem solving
Post reply on HN