4 ms·
A rewrite with another, more subtle mistake. That you must spend energy discovering and diagnosing.
by bigfishrunning 1y ago
A rewrite with another, more subtle mistake. That you must spend energy discovering and diagnosing.
- fluidcruft 1y agoHow is that different from working with a n00b except that it only took 30sec to get to the next bug rather than a week?
- bigfishrunning 1y agoThe junior engineer will grow into a senior engineer
- bayarearefugee 1y ago> 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.
- Kirth 1y ago.. 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
- arcanemachiner 1y agoWhich has nothing to do with the argument you're responding to.
- jakimfett 1y agoOnly if you take the argument entirely out of context.
- fluidcruft 1y agoAnd then they get their own junior engineers and you get fresh new junior engineers.
- TeMPOraL 1y agoNot 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.)
- square_usual 1y ago> 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?
- bigfishrunning 1y agoExcept 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
- square_usual 1y agoI'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.
- sokoloff 1y agoI’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.
- TeMPOraL 1y ago> 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.
- itsoktocry 1y ago>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.
- dawnerd 1y agoAnd 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.
- catlifeonmars 1y ago> The best use is editing code with it instead of purely relying on prompting. What does this look like in practice?
- the_other 1y agoYou’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.
- XenophileJKO 1y agoQuite 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.
- ewoodrich 1y agoThis 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...