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

The AI coding trap

chrisloy.dev

Post reply on HN
Print view View original

201–210 of 424 posts

Re: The AI coding trap

#201

Post by kjkjadksj »

bikamonki wrote: post #47

Not in my experience. I still spend much of the time thinking before prompting. Then I spend time reviewing the AI written code before using it. Does not feel like a trap. It mostly feels like having a super experienced pair programmer. I may be using it differently than others since I do not have it integrated to my IDE. I use it like I used google + stackoverflow before it.

To be fair you can’t really appreciate if you’ve been trapped unless you test yourself without the ai agent for some time and see if there is a difference in output. If there is, you’ve been trapped.

Re: The AI coding trap

#202

Post by [deleted] »

fzzzy wrote: post #63
didibus wrote: post #51

Earlier quoted context omitted.

> The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt I'm convinced I spend more time typing and end up typing more letters and words when AI coding than when not. My hands are hurting me more from the extra typing I have to do now lol. I'm actually annoyed they haven't integrated their voice to text models inside their coding agents yet.

GitHub copilot already does have speech to text and as my sibling comment mentions, on the Mac, it is globally available. It varies according to typing and speaking speed but speaking should be about five times faster than typing.

[deleted]

Re: The AI coding trap

#203

Post by 6thbit »

Jumping straight into coding is a very junior thing to do.

Using Plan mode in Cline or other agent based workflows is day and night in the outputs.

Alas, at least in Cline it seems plan mode doesn’t read files just works off context which is insane to me and hinders its usefulness, anyone know why that happens?

Re: The AI coding trap

#204

Post by jowea »

Jensson wrote: post #158
jowea wrote: post #142

Earlier quoted context omitted.

We've been on the Electron era long enough to know that developer time is more expensive than CPU time.

That is a myth, cpu time is time spent waiting around by your users as the cpu is taking seconds to do something that could be instant, if you have millions of users and that happens every day that quickly adds up to many years worth of time. It might be true if you just look at development cost, but if you look at value as a whole it isn't. And even just development cost its often not true, since time spent waiting…

Yeah, it's time spent by the users. Maybe it's an inneficiency of the market because the software company doesn't feel the negative effect enough, maybe it really is cheaper in aggregate that doing 3 different native apps in C++. But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software?

Also, why

Re: The AI coding trap

#205

Post by godelski »

danpat wrote: post #65
PessimalDecimal wrote: post #34

Earlier quoted context omitted.

> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. 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. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…

  > We _already_ live in a world where most of us spend much of our time reading and trying to comprehend code written by others from the past.
We also live in a world where people argue endlessly about how we don't need to write documentation or how it's possible to write self documenting code. This is where we spend so much of our time and yet so few actually invest in the efforts to decrease that time.

I bring this up because it's a solution to what you're pointing out as a problem and yet the status quo is to write even messier and harder to understand code (even before AI code). So I'm just saying, humans are really good at shooting themselves in the foot and blaming it on someone else or acting like the bullet came out of nowhere.

  > What's the difference between
More so, I must get misreading because it sounds like you're asking what's the difference between "messy" and "messier"?

If it's the same level of messiness, then sure, it's equal. But in a real world setting there's a continuous transition of people. One doesn't work on code in isolation, quit, and then a new person works on that code also in isolation. So maybe it's not the original authors but rather the original authors are a Ship of Theseus. Your premise isn't entirely accurate and I think the difference matters

Re: The AI coding trap

#206

Post by yoz-y »

tptacek wrote: post #135
swiftcoder wrote: post #70

Earlier quoted context omitted.

ideally there is an order of magnitude difference between, and the latter is trivially delegable (where the former is not)

No there isn't.

This harkens back to the waterfall vs agile debates. Ideally there would be a plan of all of the architecture with all the pitfalls found out before any code is laid out.

In practice this can’t happen because 30 minutes into coding you will find something that nobody thought about.

Re: The AI coding trap

#207

Post by startupsfail »

godelski wrote: post #198
bccdee wrote: post #186

Earlier quoted context omitted.

> the idea that technology forces people to be careless I don't think anyone's saying that about technology in general. Many safety-oriented technologies force people to be more careful, not less. The argument is that this technology leads people to be careless. Personally, my concerns don't have much to do with "the part of coding I enjoy." I enjoy architecture more than rote typing, and if I had a direct way to imp…

(Adding to your comment, not disagreeing) > The argument is that this technology leads people to be careless. And this will always be a result of human preference optimization. There's a simple fact: humans prefer lies that they don't know are lies over lies that they do know are lies. We can't optimize for an objective truth when that objective truth doesn't exist. So while doing our best to align our models they mu…

> There's a simple fact: humans prefer lies that they don't know are lies over lies that they do know are lies.

As an engineer and researcher, I prefer lies (models, simplifications), that are known to me, rather than unknown unknowns.

I don't need to know exact implementation details, knowledge of aggregate benchmarks, fault rates and tolerances is enough. A model is a nice to have.

This approach works, in science (physics, chemistry, biology, ...) and in engineering (including engineering agentic and social sustems- social engineering).

Re: The AI coding trap

#208

Post by indiantinker »

It is an interesting take. I teach programming to designers as a part of a course called "Emerging technologies". Although, it is fun to see what students create, but it is not fun to solve doubts. When you are teaching basics, the students would quickly fire up ChatGPT and make some slop up. In the end, I have to fix their codes. I think, the learning output is reduced as they have not written any code. I am genuinely concerned as an educator. One thing that is missing is differentiating AI output and understanding what to keep and what to ignore. The sheer "aesthetic" of it. I feel, many do not take time to develop this very "human" skill and become very output oriented from the very start. This, IMO, affects learning. These tools are also quite addictive due to the sense of 'manufactured' certainty they offer, which is something that hinders learning. What is the point of learning how to add when you have the cheatsheet next to you?

Re: The AI coding trap

#209

Post by Vegenoid »

reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

I'm not sure if you are insinuating that the article is an anti-AI take, but in case it wasn't clear, it's not. It is about doing just what you suggested:

> Just as tech leads don't just write code but set practices for the team, engineers now need to set practices for AI agents. That means bringing AI into every stage of the lifecycle

The technology doesn't force people to be careless, but it does make it very easy to be careless, without having to pay the costs of that carelessness until later.

Re: The AI coding trap

#210

Post by ewoodrich »

kristianbrigman wrote: post #160
mordymoop wrote: post #91

Broadly the critique is valid where it applies; I don’t know if it accurately captures the way most people are using LLMs to code, so I don’t know that it applies in most case. My one concrete pushback to the article is that it states the inevitable end result of vibe coding is a messy unmaintainable codebase. This is empirically not true. At this point I have many vibecoded projects that are quite complex but work p…

I had the AI implement two parallel implementations of the same thing in one project. Was lots of fun when it was 'fixing' the one that wasn't being used. So yeah, it can definitely muck up your codebase.

Hah today I discovered Claude Code has been copy/pasting gigantic blocks of conditions and styling every time I ask it to add a "--new" flag or whatever in a once tiny now gigantic script I've been adding features to.

It worked fine until recently where I will ask it to tweak some behavior of a command with a flag and it does a diff with like hundreds of lines. So now it's struggling to catch every place it needs to change some hardcoded duplicate values it decided to copy/paste into two dozen random places in the code.

To be fair it is doing a decent job unfucking it now that I noticed and started explicitly showing it how ridiculously cumbersome and unmaintainable it made things with specific examples and refactoring. But if I hadn't bothered to finally sit down and read through it thoroughly it would have just become more broken and inconsistent as it grew exponentially.

Post reply on HN