Live data from Hacker News

The AI coding trap

chrisloy.dev

291–300 of 424 posts

Re: The AI coding trap

#291

Every day I think to myself: "Just fake it like you want to be here for 30 more years and then you can retire." I have been working in machine-learning for 10 years. I am tired of the computer. I am tired of working. I just want to lay in the grass.

I’ve been grassing for 7 months. That gets old too.

Re: The AI coding trap

#292
post #211

Earlier quoted context omitted.

> 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 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 whatever O'Reilly book gives a good overview, so that you understand the landscape of what's possible with the tool and can spot when the LLM is doing (now) obvious bullshit.

You can't just Yolo it for shit you don't know and get good results, but if you build a foundation first through reading, you will do a lot better.

Re: The AI coding trap

#293
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…

Popular != true. Galileo found that out by spending the last ~decade of his life under house arrest. Thankfully today we mostly just get downvoted.

Re: The AI coding trap

#295
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…

> There's a divide between people who enjoy the physical experience of the work and people who enjoy the mental experience of the work. If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. But if you like the doing, the typing, fiddling with knobs and configs, etc etc, all AI does is take the good part away. I don't know...…

> Usually not intellectually interesting, so why not outsource that to the AI.

Because it still needs to be correct, and AI still is not producing correct code

Re: The AI coding trap

#296

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…

100x is such a crazy claim to me - you’re saying you can do in 4 days what would have previously taken over a year. 5 weeks and you can accomplish what would have taken you a decade without LLMs.

Interesting point.

In most cases I would never have undertaken those projects at all without AI. One of the projects that is currently live and making me money took about 1 working day with Claude Code. It’s not something I ever would have started without Claude Code, because I know I wouldn’t have the time for it. I have built websites of similar complexity in the past, and since they were free-time type endeavors, they never quite crossed the finish line into commerciality even after several years of on-again-off-again work. So how do you account that with a time multiplier? 100x? Infinite speedup? The counterfactual is a world where the product doesn’t exist at all.

This is where most of the “speedup” happens. It’s more a speedup in overall effectiveness than raw “coding speed.” Another example is a web API for which I was able to very quickly release comprehensive client side SDKs in multiple languages. This is exactly the kind of deterministic boilerplate work LLMs are ideal for, and that would take a human a lot of typing, and looking up details for unfamiliar languages. How long would it have taken me to write SDKs in all those languages by hand? I don’t really know, I simply wouldn’t have done it, I would have just done one SDK in Python and said good enough.

If you really twist my arm and ask me to estimate the speedup on some task that I would have done either way, then yeah I still think a 100x speedup is the right order of magnitude, if we’re talking about Claude Code with Opus 4.1 specifically. In the past I spent about a five years very carefully building a suite of tools for managing my simulation work and serving as a pre/post-processor. Obviously this wasn’t full-time work on the code itself, but the development progressed across that timeframe. I recently threw all that out and replaced it with stuff I rebuilt in about a week with AI. In this case I was leveraging a lot of the learnings I gleaned from the first time I built it, so it’s not a fair one-to-one comparison, but you’re really never going to see a pure natural experiment for this sort of thing.

I think most people are in a professional position where they are sort of externally rate limited. They can’t imaging being 100x more effective. There would be no point to it. In many cases they already sit around doing nothing all day, because they are waiting for other people or processes. I’m lucky to not be in such a position. There’s always somewhere I can apply energy and see results, and so AI acts as an increasingly dramatic multiplier. This is a subtle but crucial point: if you never try to use AI in a way that would even hypothetically result in a big productivity multiplier (doing things you wouldn’t have otherwise done, doing a much more thorough job on the things you need to do, and trying to intentionally speed up your work on core tasks) then you can’t possibly know what the speedup factor is. People end up sounding like a medieval peasant suddenly getting access to a motorcycle and complaining that it doesn’t get them to the market faster, and then you find out that they never actually ride it.

I wonder, have you sat down and tried to vibecode something with Claude Code? If so, what kind of multiplier would you find plausible?

Re: The AI coding trap

#297
post #171

Earlier quoted context omitted.

Intellectual property as a concept wasn't designed for the age of LLM. You have to add a bunch of exceptions to copyright (fair use, first sale) to get it to not immediately lead to scenarios that don't make any intuitive sense. LLMs explode these issues because now you can mechanically manipulate ideas, and this forces to light new contradictions that intellectual property causes.

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-scale commercial LLM operators were required to respect licenses and negotiate appropriate usage terms. Okay, maybe with one exception: their investors and shareholders.

And the issue I'm gesturing at is that 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. These are issues can only be conclusively resolved with writing new laws to decide it's going to work, but that will eventually only make the contradictions worse and complicate the hoops that people will have to jump through as the technology evolves in new ways.

Re: The AI coding trap

#298

Effective coding is not code first think later. LLMs aren't effective when used this way. You still have to think. IMO a vibe coder who is speaking their ideas to an agent which implements them is going to have way more time to think than a hand coder who is spending 80% of their time editing text.

A lot of times coding is thinking. It's like sketching out an idea on paper, but with code.

Re: The AI coding trap

#300

Earlier quoted context omitted.

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…

Yeah, it will definitely do dumb stuff if you don’t keep an eye on it and intervene if you see the signs that it’s heading in the wrong direction. But it’s very good at course correcting and if you end up in a truly disastrous state you can almost always fix it be reverting to the last working commit and start a fresh context.
Post reply on HN