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

211–220 of 424 posts

Re: The AI coding trap

#211

Post by keeda »

ZephyrBlu wrote: post #176
halfadot wrote: post #167

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. No it isn't. There's literally nothing about the process that forces you to skip understanding. Any such skips are purely due to the lack of will on the developer's side. This lack of will to learn will not change the outcomes for you…

> No it isn't. There's literally nothing about the process that forces you to skip understanding. Any such skips are purely due to the lack of will on the developer's side This is the whole point. The marginal dev will go to the path of least resistance, which is to skip the understanding and churn out a bunch of code. That is why it's a problem. You are effectively saying "just be a good dev, there's literally nothi…

I don't think that is a problem with AI, it is a problem with the idea that pure vibe-coding will replace knowledgeable engineers. While there is a loud contingent that hypes up this idea, it will not survive contact with reality.

Purely vibe-coded projects will soon break in unexplainable ways as they grow beyond trivial levels. Once that happens their devs will either need to adapt and learn coding for real or be PIP'd. I can't imagine any such devs lasting long in the current layoff-happy environment. So it seems like a self-correcting problem no?

(Maybe AGI, whatever that is, will change things, but I'm not holding my breath.)

The real problem we should be discussing is, how do we convince students and apprentices to abstain from AI until they learn the ropes for real.

Re: The AI coding trap

#212

Post by kjkjadksj »

anotheryou wrote: post #200
kjkjadksj wrote: post #199

Earlier quoted context omitted.

The deep knowledge really isn’t all that deep. A couple years in the weeds and you have it. What this really hurts is outsourced devs. In the past a non coding person could come up with the spec and hire someone from a developing nation to make it on the cheap to that spec. It is still possible to work like this of course, resulting in working code compared to llm that might hallucinate a passing test condition that…

But the feedback cycle wait time and the communication workload is almost eliminated.

Perhaps. Then again, most people aren't working in fields where racing to the finish is a requirement. Corporate work I've found is really slow moving for a lot of reasons. Things getting backburnered and pushed back is pretty standard. It takes time for all the stakeholders to digest information and make feedback. There is also the phenomenon where no one really appreciably works after thanksgiving so for most american corporate workers it is like they are on a 10.5 month year as it is. All this to say that even with diminished feedback cycle wait time and lightened communication workload, I don't think the product is getting out any faster.

Re: The AI coding trap

#213

Post by consumer451 »

6thbit wrote: post #203

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?

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

Agreed. My tool agnostic workflow is to work up a planning/spec doc in the docs/feature-plans folder. I use one chat thread to make that. First it creates the basic plan, then then we pick it apart together, I manually fix bad assumptions, then in a new chat, we implement.

Before and after implementation, I run my /gilfoyle command for a constructive roast, then my /sec command for a thorough security review. After implementing this, and a bit more, the final LLM output quality is much higher.

edit: adding "make sure we are applying known patterns used in our app for our solution, don't reinvent the wheel." helped a ton. I am on mobile atm, and that might not be the exact wording.

Re: The AI coding trap

#214

Post by swiftcoder »

yoz-y wrote: post #206
tptacek wrote: post #135

Earlier quoted context omitted.

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.

In the micro, sure. In the macro, if you are finding architecture problems after 30 minutes, then I’m afraid you aren’t really doing architecture planning up front.

Re: The AI coding trap

#216

Post by cloverich »

rwmj wrote: post #61
jayd16 wrote: post #24

Earlier quoted context omitted.

My take is just that debugging is harder than writing so I'd rather just write it instead of debugging code I didn't write.

I think it's more like code review, which really is the worst part of coding. With AI, I'll be doing less of the fun bits (writing, debugging those super hard customer bugs), and much much more code review.

well to be fair to the argument, reviewing code that you designed.

Re: The AI coding trap

#217

Post by johnisgood »

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…

I use LLMs for coding and I like it the way I am using it. I do not outsource thinking, and I do not expect it to know what I want without giving it context to my thoughts with regarding to the project. I have written a 1000 LOC program in C using an LLM. It was a success. I have reviewed it "line by line" though, I do not know why I would not do this. Of course it did not spit out 1000 LOC from the get go, we started small and we built upon our foundations. It has an idea of my thinking and my preferences with regarding to C and the project because of our interactions that gave it context.

Re: The AI coding trap

#218

Post by strogonoff »

m0rde wrote: post #169
strogonoff wrote: post #121

Earlier quoted context omitted.

I never made a case against LLMs and similar ML applications in the sense that they negatively impact mental agility. The cases I made so far include, but are not limited to: — OSS exploded on the promise that software you voluntarily contributed to remains to benefit the public, and that a large corporation cannot tomorrow simply take your work and make it part of their product, never contributing anything back. Com…

Good points here, particularly the ends not justifying the means. I'm curious for more thoughts on "will drive more and more people out of jobs”. Isn't this the same for most advances in technology (e.g., steam engine, computers s, automated toll plazas, etc.). In some ways, it's motivation for making progress; you get rid of mundane jobs. The dream is that you free those people to do something more meaningful, but I…

It happened before, and it was an issue back then as well.

Mundane job may be mundane (though note that it is sometimes subjective), but it earns someone bread and butter and it is always economic stress when the job is gone and many people have to retrain.

If we were to believe those of us who paint this technology as mind-bogglingly world-changing, that someone is now nearly everyone and unlike the previous time there is no list of jobs you could choose from (that would last longer than the time it takes to train).

If we were not to believe the hype, still: when those jobs got automated back then, people moved to jobs that are liable to be obsolete this time, except there is also just more people overall, so even purely in terms of numbers this seems to be a bigger event.

Re: The AI coding trap

#219

Post by Balinares »

wat10000 wrote: post #172
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 suspect the root of the disagreement is more about what kinds of work people do. There are many different kinds of programming and you can’t lump them all together. We shouldn’t expect an AI tool to be a good fit for all of them, any more than we should expect Ruby to be a good fit for embedded development or C to be a good fit for web apps. My experience with low level systems programming is that it’s like working…

I think this is one of the most cogent takes on the topic that I've seen. Thanks for the good read!

It's also been my experience that AI will speed up the easy / menial stuff. But that's just not the stuff that takes up most of my time in the first place.

Re: The AI coding trap

#220

Post by HiPhish »

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 would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless.

I think this might simply be how the human brain works. Take autonomous driving as an example: while the car drives on its own the human driver is supposed to be alert and step in if needed. But does that work? Or will the driver's mind wander off because the car has been driving properly for the last half hour? My gut feeling is that it's inevitable that we'll eventually just shut out everything that goes smoothly and by the time it doesn't it might be too late.

We are not that different from our ancestors who used to roam the forests, trying to eat before they get eaten. In such an environment there is constantly something going on, some critters crawling, some leaves rustling, some water flowing. It would drive us crazy if we could not shut out all this regular noise. It's only when an irregularity appears that our attention must spring into action. When the leaves rustle differently than they are supposed to there is a good chance that there is some prey or a predator to be found. This mechanism only works if we are alert. The sounds of the forest are never exactly the same, so there is constant stimulation to keep up on our toes. But if you are relaxing in your shelter the tension is gone.

My fear is that AI is too good, to the point where it makes us feel like being in our shelter rather than in the forest.

Post reply on HN