It's not unlike some managers who tell their teams to do something trivially easy that they could have done themselves.
(I'm not saying this is ideal and I'm not defending my laziness. It's just the current state of things.)
Even the doFoo to performBar is tedious because you need to catch all instances and your find/replace script strategy might have unintended victims.
In this case indeed, it's just much more convenient.
Even harder would be to update your setters from `void setFoo(Foo f) { this.foo = f; }` to fluent-style `Parent foo(Foo f) { this.foo = f; return this; }` - I'd be surprised if there's an LSP action for that at all. (I'd love to be proven wrong though)
I actually had better luck asking codex to write temporary sed scripts based on the requirements then apply them.
And instantly, certainly when compared to AI.
Ruby would be the one exception I’ve worked on in my head, and for they language, ctrl+f *usually* (but not always) finds the rest.
Ruby is particularly magical with being able to evaluate methods from dynamic strings into running, production code[0]; but otherwise, languages and capable IDEs, like IntelliJ and Visual Studio just support that. I don’t happen to use VS Code, but I assume it has basic refactor, too.
[0] Devise. https://github.com/heartcombo/devise/blob/main/lib/devise/co...
Like you said, it's basically instant.
1. Find the code you want to change
2. Run the tests to confirm that test coverage is good for the starting point
3. Track down everywhere else that might call or interact with that code
4. Update the tests (red/green TDD)
5. Alter the code
6. Update the things that call the code
7. Run the tests again
8. Apply linters/formatters
9. Address any feedback from linters
10. Check to see if any documentation needs updating and do that
11. Land a commit with a descriptive commit message
I can get all of that done with a coding agent with a single sentence prompt - especially if it's already in a session where it knows that I do "red/green TDD".
... and then I can work on something else while the agent is churning through those steps.
I guess the difference may be in people's mode of AI working: Do you primarily develop in your IDE or a bunch of terminals running vim, and occasionally fire up claude to do more complex things? Or do you primarily develop in a long-lasting claude terminal, and occasionally tab over to the IDE to watch/codereview? In other words: What dev tool is on your primary monitor and what's on your secondary monitor? It's getting hard for developers in one camp to discuss coding and see eye-to-eye with developers from the other camp.
There are a lot of small refactorings that I wouldn't consider to be worth 15 minutes of my time, so I wouldn't do them.
Outsourcing those to an agent means I don't have to make that tradeoff, which means I can get better quality code.
But yes, for a lot of my work I'm now a Claude Code / Codex first developer. I run Zed so I can navigate the code and occasionally make small edits.
1 - Find the code
4 - Move the code
10 - Change the documentation
You don't do the other steps because it's deterministic and always correct.
I don't trust any refactors until I've seen the test suite pass.
(OK, sure, "rename method" might be OK, but most of my refactors and design changes are more interesting than that.)
It also takes away the mental tax burden of thinking up good names for things when writing out code quickly on the first pass.
Works very well with PHP (in PHPStorm), and I'd expect somewhat similar reliability in PyCharm on a Python project with some type annotations (or maybe even with none?).
With the advent of LSPs and treesitter parser approach I wished to see higher level refactorings possible by now, but innertia in tooling space died down as most focus switched to LLMs.
And I sometimes prefer searching for the method names and changing them one by one (find-grip-dired followed by query replace) just to see where all the code is being used, if anything looks bad, if there is some opportunity for code reduction, etc. not that I don’t also prompt Claude to rename things, or better yet make sure all the SQL commands log enough etc.
Anyway, Python tools are usually capable of refactoring any code that isn't reflective or self-rewriting. There are places for those two, but those are very few and the AI won't have any idea how to work at those places either.
JavaScript is a problem.
Because it's often not just Ctrl-C/Ctrl-V. It's Ctrl+C/Ctrl+V, except today paste is Shift+Insert, and in the other project it's usually C-y, and you actually need to check one more place for full list of things to copy, and then you discover one case needs a minor transformation, ...
LLMs can handle such annoying details intelligently.
> What's next? "Claude, rename the function doFoo() to performBar()"?
Yes. Such prompt can be issued in many equivalent ways, and works across environments, contexts and tool stacks. I can issue it from the phone, in form of "also doFoo -> perform... reame", and it will work even on Lisp code inside Word documents it accesses through Google Drive.
And even with small things, it's just toil. You can start a small update and then realize with all the back and forth of edit/test/edit/test that you've been stuck in the OODA loop for 40 minutes you will never get back.
As an engineer: of course not, keyboards are more efficient.
Also as an engineer: of course, “tea, Earl Grey, hot”, or what are we even working for?
My son loves the always ready hot water.
Secondly, no, it's not even comparable with AI basically delaying electricity decarbonization on entire continent-sized countries, requiring entire coal-fired power stations and stealing all the ram and storage of the planet to build specific and short-lived hardware that will last few years and will be thrown away very fast.