100% this. The AI missunderstands and make a mistake? No problem. Clarify and the AI will come back with a rewrite in 30 sec.

A rewrite with another, more subtle mistake. That you must spend energy discovering and diagnosing.

> another, more subtle mistake. That you must spend energy discovering and diagnosing

But this is literally what senior engineers do most of the time? Have juniors write code with direction and review that it isn't buggy?

Except that most of the code seniors review was written with intention, not just the most statistically most likely response to a given query. As a senior engineer, the kinds of mistakes that AI makes are much more bizarre then the mistakes junior engineers make

> Except that most of the code seniors review was written with intention, not just the most statistically most likely response to a given query.

Given the nature of the statistics in question, the line between the two is extremely blurry at this point.

I've worked with many interns and juniors in my life and they've made very bizarre mistakes and had subtle bugs, so the difference in the kinds hasn't made much of a difference in the work I've had to do to review. Whether or not there was intention behind it didn't make a difference.

I’ve definitely seen absolutely bizarre creations from junior devs decades ago (so, well before modern AI). I can also think back to some cringey code I wrote by hand when I was a junior as well.

I mentor high-school students and watch them live write code that takes a completely bizarre path. It might technically be intentional, but that doesn’t mean it’s good or useful.

>not just the most statistically most likely response to a given query.

Some people really are going to hang on until the better end (and beyond) eh?

"AI can't code like me!" people are going to get crushed.

My experience in the UK has been that seniors and principles just write more/better code and occasionally deal with “the business” with (justifiably) greater attention paid to their input. I’d love to see a proper culture of mentoring.

How is that different from working with a n00b except that it only took 30sec to get to the next bug rather than a week?

The junior engineer will grow into a senior engineer

Not as fast as models get better.

And not at all for you, because you're unlikely to retain them for long. Which makes this immaterial - AI or human, you're only going to delegate to n00bs.

(This is distinct from the question of which benefits society more, which is a separate discussion.)

> The junior engineer will grow into a senior engineer

And then quit after accepting a new job that pays them their modified value, because tech companies are particularly bad at proactive retention.

Which has nothing to do with the argument you're responding to.

Only if you take the argument entirely out of context.

.. and because the job and environment weren't that pleasant or rewarding to offset that delta in income offered elsewhere at an equally drab employer

And then they get their own junior engineers and you get fresh new junior engineers.

And potentially trick you into going down a rabbit hole as you try to steer it when it would have been faster to edit the code yourself. The best use is editing code with it instead of purely relying on prompting. Also new contexts for different changes make a huge difference. Seems a lot of devs get stuck in the single context chat stream and it starts to break down as context gets fuzzy.

You’d think that with more context it would get better, but it doesn’t.

My hunches are that the to-and-fro of ideas as you discuss options or make corrections leads to a context with competing “intentions”; and that they can’t tell the difference between positive and negative experiences when it comes across each successive token in the context.

But I don’t make LMMs, so this is pure guesswork.

Quite honestly after using Copilot, Claude Code, Cursor, and Codex extensively for months, I very rarely hand edit code.

The rabbit hole problem is pretty rare. Usually it happens when the model flips into "stupid mode", some kind of context poisoning. If you are experienced, you know to purge the context when that happens.

In personal projects I avoid manual editing as a form of deliberate practice. At work, I only edit when it is a very small edit. I can usually explain what I want more concisely and quickly than hand editing code.

I probably would use more hand editing if I had classic refactoring tools in the IDEs similar to intellij/pycharm. Though cli based tools were a pleasant surprise once I actively started using them.

> The best use is editing code with it instead of purely relying on prompting.

What does this look like in practice?

This can go both ways though. I've had instances where after a long somewhat tedious back and forth with Claude Code what I'm looking for finally "clicks" and it starts one-shotting requests left and right. But then after coming up to the end of the context window, I compact or ask it to update CLAUDE.md with what it learned and it loses the nuanced understanding it built up through trial and error and starts screwing up in the exact same ways again with fresh context.

And then I waste 20 minutes bashing my head against the wall trying to write three paragraphs meticulously documenting all the key gotchas and lessons from the "good" context window with the magic combination of words needed to get Claude back in the right head space to one-shot again.

At least if I pull that off I can usually ask Claude to use it as documentation for the project CLAUDE.md with a pretty good success rate. But man it leaves a bad taste in my mouth and makes me question whether I'm actually saving time or well into sunk cost territory...

LLMs might make you feel faster (which helps with motivation!) and help with some of the very easy stuff but the critical part of your anecdote is that you haven't actually completed the extra work. The projects are only "NEARING" completion. I think that's very telling.

If the easy things are done faster you xan spend more time on the hard stuff. No need to spend 2 hours on making the UI for the MVP when an AI can make a decent UI in 2 min. Means you have 2 hours more to spend on the hard stuff.

Unless, as is often the case in my experience, the hard stuff consists largely of fixing bugs and edge cases in your implementation of the easy stuff. I've seen multiple people already end up forced back to the drawing board because their "easy stuff" AI implementation had critical flaws they only realized after they thought they were done. It's hard to prove counterfactuals, but I'm pretty confident they would have gotten it right the first time if they hadn't used AI, they're not bad engineers.

Congratulations! You repeated my joke? lol

But in all seriousness, completion is not the only metric of productivity. I could easily break it down into a mountain of subtasks that have been fully completed for the bean counters. In the meantime, the code that did not exist 2 months ago does exist.

> I don't need a study to tell me that five projects that have been stuck in slow plodding along waiting for me to ever have time or resources for nearly ten years.

that's the issue in the argument though. it could be that those projects would also have been completed in the same time if you had simply started working on them. but honestly, if it makes you feel productive to the point you're doing more work than you would do without the drug, I'd say keep taking it. watch out for side effects and habituation though.

I don't think that's correct. That could be true if I were primarily a programmer, but I am not. I'm mostly a certified medical physicist working in a hospital. Programming is a skill that is helpful and I have spent my programming time building other tools that I need. But that list is gigantic, the software that is available for purchase is all complete crap, the market is too small for investment, etc. That's all to say the things I am building are desperately needed but my time for programming is limited and it's not what brings home the bacon and there's no money to be made (beyond consulting, essentially these things might possibly work as tools for consultants). I don't have resources for professional programming staff but I have worked with them in the past and (no offense to most of HN) but the lack of domain knowledge tends to waste even more of my time.

You are very fortunately in the perfect slot for where LLM has a lot of bang for the buck.

You've added an implicit assumption that this person spends more time programming now than they used to, rather than continuing to commit time at the same rate but now leading to projects being completed when they previously got bogged down and abandoned.

There are any number of things you could add to get you to any conclusion. Better to discuss what is there.

I've had the same experience of being able to finish tons of old abandoned projects with AI assistance, and I am not spending any more time than usual working on programming or design projects. It's just that the most boring things that would have taken weeks to figure out and do (instead, let me switch to the other project I have that is not like that, yet) have been reduced to hours. The parts that were tough in a creative fun way are still tough, and AI barely helps with them because it is extremely stupid, but those are the funnest, most substantive parts.

> if you had simply started working on them.

The magic of Claude is that you can simply start.

You can also simply start without Claude too!

Yes, but less often.

Yes, because Claude makes you feel more productive and thus you are more eager. I feel like we've covered this further up.