Hacker News Reader

After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty.

Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively.

Not to say the LLMs are not useful, especially in agent mode. But the temptation is always to trust and task them with more than they can handle. maybe we need an agent that limits the scope of what you can ask it to do, to keep you involved at the necessary level.

People keep thinking we are at the level where we can forget about the nitty gritty of the code and rise up the abstraction level, when this is nothing close to the truth.

[1] Source: me last week trying really hard to work like you are talking about with Claude Code.

> After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty.

You're assuming that I haven't. Yes, sometimes you have to do it yourself, and the people who are claiming that you can replace experienced engineers with these are wrong (at least for now, and for non-trivial problems).

> Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively.

Disagree. There's not a single piece of code I've written using these that I haven't carefully curated myself. Usually the result (after rounds of prompting) is smaller, significantly better, and closer to my original intended design than what I got out of the machine on first prompt.

I still find them to be a significant net enhancement to my productivity. For me, it's very much like working with a tireless junior engineer who is available at all hours, willing to work through piles of thankless drudgery without complaint, and also codes about 100x faster than I do.

But again, I know what I'm doing. For an inexperienced coder, I'm more inclined to agree with your comment. The first drafts that these things emit is often pretty bad.

You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code.

Similar to the differences between an art collector and a painter. One wants the ends, the other desires the means.

I think I could be happy switching between the two modes. There's tasks that are completely repetative slop that I've fully offloaded to AI with great satisfaction. There's others I enjoy that I prefer to use AI for consultation only. Regardless, few people liked doing code review before with their peers and somehow we've increased one of the least fun parts of the job.

That's not fair, and not what I am saying at all.

I enjoy writing code. I just don't enjoy writing code that I've written a thousand times before. It's like saying that Picasso should have enjoyed painting houses for a living. They're both painting, right?

(to be painfully clear, I'm not comparing myself to Picasso; I'm extending on your metaphor.)

You would rather debug the low quality LLM code that you know you could write better, a thousand times?

Well, I don't write bugs in my code, of course, but let's just say that you were the type of person who does: having a bot that writes code 100x faster than you, that also occasionally makes mistakes (but can also fix them!), is still a huge win.

> occasionally makes mistakes

Well. Maybe we have to agree to disagree but I think it makes mistakes far more frequently than I do

Even if it makes mistakes exactly as often as I do, making 100x as many mistakes in the same amount as time seems like it would be absolutely impossible to keep up with

I love programming, I just don't like CRUDing, or API'ing...

I also love programming behaviours and interactions, just not creating endless C# classes and looking at how to implement 3D math

After a long day at the CRUD factory, being able to vibe code as a hobby is fun. Not super productive, but it's better than the alternative (scrolling reels or playing games)

I love coding, do it for fun outside of my job, and find coding with an LLM very enjoyable.

I've been experimenting with LLM coding for the past few months on some personal projects. I find it makes coding those projects more enjoyable since it eliminates much of the tedium that was causing me to delay the project in the first place.

Exactly the same for me...now whenever I hit something like "oh god, I want to change the purpose of this function/variable, but I need to go through 500 files, and see where it's used, then make local changes, then re-test everything...", I can just tell the bot to do it.

I know a lot of folks would say that's what search & replace is for, but it's far easier to ask the bot to do it, and then check the work.

> "oh god, I want to change the name of this function/variable, but I need to go through 500 files, and see where it's used, then make local changes, then re-test everything..."

Forgive me for being dense, but isn't it just clicking the "rename" button on your IDE, and letting it propagate the change to all definitions and uses? This already existed and worked fine well before LLMs were invented.

Yes, that particular example modern editors do just fine. Now imagine having that for almost any rote transformation you wanted regardless of complexity (so long as the change was rote and describable).

Yeah, sorry...I re-read the comment and realized I wasn't being clear. It's bigger than just search/replace. Already updated what I wrote.

The far more common situation is that I'm refactoring something, and I realize that I want to make some change to the semantics or signature of a method (say, the return value), and now I can't just use search w/o also validating the context of every change. That's annoying, and today's bots do a great job of just handling it.

Another one, I just did a second ago: "I think this method X is now redundant, but there's a minor difference between it, and method Y. Can I remove it?"

Bot went out, did the obvious scan for all references to X, but then evaluated each call context to see if I could use Y instead.

(But even in the case of search & replace, I've had my butt saved a few times by agent when it caught something I wasn't considering....)

I really like working with LLMs but one thing I've noticed is that the obvious transformation of "extract this functionality into a helper function and then apply that throughout the codebase" is one I really actually enjoy doing myself; replacing 15 lines of boilerplate-y code in a couple dozen places with a single helper call is _really_ satisfying; it's like my ASMR.

Hah, well, to each their own. That's exactly the kind of thing that makes me want to go outside and take a walk.

Regardless of what your definition of horrible and boring happens to be, just being able to tell the bot to do a horrible boring thing and having it done with like a junior level intelligence is so experience enhancing that it makes coding more fun.

I find elimination of inertia and preservation of momentum to be the biggest wins; it's just that my momentum isn't depleted by extracting something out into a helper.

People should try this kind of coding a couple times just because it's an interesting exercise in figuring out what parts of coding are important to you.

> You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code.

Yeah this is for sure true, but it's probably true in degrees.

I think there was even a study or something (from GitHub maybe) about the frequency of languages and how there were far more commits in say Rust on weekends than weekdays (don't quote me on this).

Plenty of people like programming but really don't find yet-another-enterprise-CRUD-with-React-front-end thing to be thrilling, so they will LLM-pasta it to completion but otherwise would have fun hacking away in langs/stuff they like.

I identify with that (hypothetical) crowd.

Same. After doing this for decades, so much programming work is tedious. Maybe 5% to 20% of the work is interesting. If I can get a good chunk of that other 80%+ built out quickly with a reasonable level of quality, then we're good.

Your use case seems relatively well-suited to AI. Even an unreliable technology like LLMs could be useful for automating a task that is mundane, well-defined, and easy to review for accuracy.

> After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today.

If this is your experience of programming, then I feel for you, my dude, because that sucks. But it is definitely not my experience of programming. And so I absolutely reject your claim that this experience represents "99% of programming" -- that stuff is rote and annoying and automate-able and all that, no argument, but it's not what any senior-level engineer worth their salt is spending any of their time on!

People who don’t do 1)API connecting, 2)Web design using popular frameworks or 3) requirements wrangling with business analysts have jobs that will not be taken over by AI anytime soon. I think 99% of jobs is pushing it, but I definitely think the vast majority of IT jobs fit into the above categories. Another benchmark would be how much of your job is closer to research work.