Live data from Hacker News

The AI coding trap

chrisloy.dev

311–320 of 424 posts

Re: The AI coding trap

#311
post #283

Every time I read stuff like this I honestly wonder if the author is using the same tools I am. I can have Claude Code bang out everything from boilerplate to a working prototype to a complex algorithm embedded in a very complex and confusing code base. It’s not correct 100% of the time but it’s pretty damn close. And often times it comes up with algorithms I would have never thought of initially. These things are at…

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.

[deleted]

Re: The AI coding trap

#312
post #211

Earlier quoted context omitted.

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 P…

On vibe coding being self-correcting, I would point to the growing number of companies mandating usage of AI and the quote "the market can stay irrational longer than you can stay solvent". Companies routinely burn millions of dollars on irrational endeavours for years. AI has been promised as an insane productivity booster. I wouldn't expect things to calm down for a while, even if real-life results are worse. You c…

I'm a bit cynical at this point, but I'm starting to think these AI mandates are simply another aspect of the war of the capital class on the labor class, just like RTO. I don't think the execs truly believe that AI will replace their employees, but it sure is a useful negotiation lever. As in, not just an excuse to do layoffs but also a mechanism to pressure remaining employees: "Before you ask for perks or raises or promotions, why are you not doing more with less since you have AI? You know that soon we could replace you with AI for much cheaper?"

At the same time, I'll also admit that AI resistance is real; we see it in the comments here for various reasons -- job displacement fears, valid complaints about AI reliability, ethical opposition, etc. So there could be a valid need for strong incentives to adopt it.

Unfortunately, AI is also deceptively hard to use effectively (a common refrain of mine.) Ideally AI mandates would come with some structured training tailored for each role, but the fact that this is not happening makes me wonder about either the execs' competency or their motives.

Re: The AI coding trap

#313
Honestly whilst I started vibe coding I don’t want ai to touch my codebase anymore.

AI has been insanely helpful for a couple of reasons, but not for writing code.

I discuss my plans with AI and check if I missed out on edge cases I develop to the most common conventions, I ask AI for better naming, ideas for abstractions, to explain me frameworks, find me packages.

But the lease couple of days I’m having sanity problems because there is one AI tool after the other coming up with a new plan on how to use AI efficiently but once you’ve solved a problem is it really much work to type it out?

It shouldn’t be too much code if correctly using orchestration.

It’s almost like all the beautiful conventions and patterns are forgotten.

Good Code is most of the time less code. Yes imho most important is readability or digestibility or even diagnosability like all of these things get completely forgotten when we start talking about AI and I see AI far off in writing such code. Good frameworks and packages will be faster.

AI is a good sparring partner and encyclopaedia especially living in terminal but I just don’t see it should writing a lot of code (except maybe landing pages with css animations) that don’t live in a complex application

Re: The AI coding trap

#314
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 actually didn't really interpret this as anti-AI. In the end it was pretty positive about AI and I pretty much agree with the conclusion.

Though I will also dogpile on the "thankless tasks" remark and say that the stuff that I have AI blast through is very thankless. I do not enjoy changing 20 different files to account for a change in struct definition.

Re: The AI coding trap

#315
post #247
post #110

I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you. I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where…

"learning is maximized is one where the AI doesn't generate any code for me" Obviously you have to work to learn, but to me this is a bit like saying learning is maximized when you never talk to anyone or ask for help — too strong.

I don't think it was that strong of an over-generalization. AI doesn't seem to help out in the same way a human would. My teammates will push back and ask for proof of effort (a PR, some typedefs, a diagram, etc.). And sometimes they'll even know how to solve my problem since they have experience with the codebase.

On the other hand you have AI which, out of the box, seems content to go along with anything and will happily write code for me. And I've never seen it have a single insight on the same level as my teammates. All of which is to say, AI doesn't really feel like something you can properly "ask" something. It's especially far away from that when it's just generating code and nothing else.

Re: The AI coding trap

#316
post #211

Earlier quoted context omitted.

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 P…

> 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. Learning the ropes looks different now. You used to learn by doing, now you need to learn by directing. In order to know how to direct well, you have to first be knowledgeable. So, if you're starting work in an unfamiliar technology, then a good starting point is read what…

Totally agreed, learning the ropes is very different now, and a strong foundation is definitely needed. But I also think where that foundation lies has changed.

My current project is in a technical domain I had very little prior background in, but I've been getting actual, visible results since day one because of AI. The amazing thing is that for any task I give it, the AI provides me a very useful overview of the thing it produces, and I have conversations with it if I have further questions. So I'm building domain knowledge incrementally even as I'm making progress on the project!

But I also know that this is only possible because of the pre-existing foundation of my experience as a software engineer. This lets me understand the language the AI uses to explain things, and I can dive deeper if I have questions. It also lets me understand what the code is doing, which lets me catch subtle issues before they compound.

I suppose it's the same with reading books, but books being static tend to give a much broader overview upfront, whereas interacting with LLMs results in a much more focused learning path.

So a foundation is essential, but it can now be much more general -- such as generic coding ability -- but that only comes with extensive hands-on experience. There is at least one preliminary study showing that students who rely on AI do not develop the critical problem solving, coding and debugging skills necessary to be good programmers:

https://www.mdpi.com/2076-3417/14/10/4115

Re: The AI coding trap

#317
post #297

Earlier quoted context omitted.

I agree that commercially operated LLMs undermine the entire idea of IP, but it is one of the problems with them, not with the concept of intellectual property, which is an approximation of what has been organically part of human society motivating innovation since forever: benefits of being an author and degree of ownership over intangible ideas. When societies were smaller and local, it just worked out and you woul…

> IP is an approximation of what has been organically part of human society and drove innovation since forever: benefits of being an author and degree of ownership over intangible ideas. It is not! It's a very recent invention. Especially its application to creative works contradicts thousands of years of the development of human culture. Consider folk songs. > I doubt anyone would consider it a problem if large-scal…

> Especially its application to creative works contradicts thousands of years of the development of human culture. Consider folk songs.

First, let’s note that creative work includes a lot more than just arts (crucially, invention).

In music, by your logic you may disagree with recognising song composition as IP, but you have to agree that being able to earn royalties from businesses playing your performance (even if it is a cover) serves as a proxy to people coming to listen and express their appreciation to a performer back when audio recording didn’t exist.

Also, let’s distinguish IP in general and its current legal implementation, such as protections lasting longer than author’s life. It should be noted that complexity in art did also grow since then, but it may or may not (I have no strong opinion here) make sense to grant the author post-humous protections.

> you run into different contradicting conclusions about how LLMs should interact with copyright depending on exactly what line of logic you follow, so the courts will never be able to resolve how it should work.

The courts can identify which ways of LLM use follow the spirit of the IP framework, encouraging innovation and creativity. As it is, current commercial LLMs slowly erode it, creating a feeling of “nothing belongs to anyone in particular, so why bother putting in the hard work”, profiting a minority of individuals while harming society over longer term. It is not difficult to see how applying the copyright as is could put an end to this, ensuring authors have control over their work, with the only consequence being slightly worse bottom lines at a handful of corporations with market caps the size of countries.

Re: The AI coding trap

#318

Earlier quoted context omitted.

Here we're really arguing about his first chart, which I agree with, and you do not.

I’m not following. It seems straightforward enough, and consistent with both charts, that a dramatic speedup in coding yields a more modest improvement in overall productivity because typing code is a minority of the work. Is your contention here that the LLM not only documents, but accelerates the thinking part too?

It does, for sure, and I said that in my comment, but no, the point I'm making is that this article isn't premised on thinking being an order of magnitude more work than coding. See: first chart in article.

Re: The AI coding trap

#319
post #65

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.

In 1969 as a newly hired graduate working for the largest construction company in the country, one of my first assignments was to read through a badly formatted COBOL source code listing on paper, line by line, with 2 others. Each of us had a printout of a different version of the software, trying to discover where exactly the three versions were giving different outputs. Plus ça change, plus c'est la même chose

Re: The AI coding trap

#320
post #65

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…

> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?

In my experience, the type of messes created by humans and the type of messes created by genAI are immensely different, and at times require different skill sets to dissect.

Post reply on HN