> 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...