I think I agree with the idea that LLMs are good at the junior level stuff.

What's happened for me recently is I've started to revisit the idea that typing speed doesn't matter.

This is an age-old thing, most people don't think it really matters how fast you can type. I suppose the steelman is, most people think it doesn't really matters how fast you can get the edits to your code that you want. With modern tools, you're not typing out all the code anyway, and there's all sorts of non-AI ways to get your code looking the way you want. And that doesn't matter, the real work of the engineer is the architecture of how the whole program functions. Typing things faster doesn't make you get to the goal faster, since finding the overall design is the limiting thing.

But I've been using Claude for a while now, and I'm starting to see the real benefit: you no longer need to concentrate to rework the code.

It used to be burdensome to do certain things. For instance, I decided to add an enum value, and now I have to address all the places where it matches on that enum. This wasn't intellectually hard in the old world, you just got the compiler to tell you where the problems were, and you added a little section for your new value to do whatever it needed, in all the places it appeared.

But you had to do this carefully, otherwise you would just cause more compile/error cycles. Little things like forgetting a semicolon will eat a cycle, and old tools would just tell you the error was there, not fix it for you.

LLMs fix it for you. Now you can just tell Claude to change all the code in a loop until it compiles. You can have multiple agents working on your code, fixing little things in many places, while you sit on HN and muse about it. Or perhaps spend the time considering what direction the code needs to go.

The big thing however is that when you're no longer held up by little compile errors, you can do more things. I had a whole laundry list of things I wanted to change about my codebase, and Claude did them all. Nothing on the business level of "what does this system do" but plenty of little tasks that previously would take a junior guy all day to do. With the ability to change large amounts of code quickly, I'm able to develop the architecture a lot faster.

It's also a motivation thing: I feel bogged down when I'm just fixing compile errors, so I prioritize what to spend my time on if I am doing traditional programming. Now I can just do the whole laundry list, because I'm not the guy doing it.

> Typing things faster doesn't make you get to the goal faster, since finding the overall design is the limiting thing.

interesting point and that matches my experience quite well. LLMs have been horrendous at creating a good design. Even on a micro scale I almost always have them refactor the functions they write

I certainly get a productivity boost at actually doing the implementation.. but the implementation is already there in my head or on paper. It's really hard to know the true improvement

I do find them useful for brainstorming. I can throw a bunch of code and tests at it and ask what edge cases I might want to consider, or anything I've missed. 9/10 of their suggestions I just skip over but often there's a few I integrate

Getting something that works vs creating something that'll do well in the medium-long term is just such a different thing that I'm not sure if they'll be able to improve at the second

> I had a whole laundry list of things I wanted to change about my codebase

I always have a whole bunch of things I want to change in the codebase I'm working on, and the bottleneck is review, not me changing that code.

A lot of this sounds like Claude is making up for bad tooling?

Machine refactoring has been a thing for decades now but only for mainstream strongly-typed languages in major IDEs. You can do massive refactorings in seconds that always compile perfectly.

LLMs are picking up the slack for js/ts, which is great, but pretty sad that we need this much compute to do something that took seconds 20 years ago in other languages.

The real productivity gain isn't just typing speed but cognitive offloading - though we must be careful this doesn't atrophy our ability to maintain accurate mental models since delegating implementation details can disconnect us from important system nuances.

> plenty of little tasks that previously would take a junior guy all day to do.

But that's also where said junior learns something. If those juniors get replaced by machines and not even get hired any more, who is going to teach them?