[simonw]

Here's the loop for a successful small refactor (anything beyond a rename that could be handled entirely by an IDE):

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.

[ryandrake]

My point is that all these steps can be done very quickly by even a junior developer who knows emacs or their IDE, in a codebase with existing lint/format/test automation, without even taking their hands off the keyboard. You're already in your IDE, you can probably do it just as fast there. I don't see the cost/benefit of spending tokens and hitting a server for this kind of work.

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.

[simonw]

Those 11 steps would probably take me 15 minutes.

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.

[marcosdumay]

When you make the change on an IDE, you:

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.

[simonw]

Presumably you're talking about statically typed languages? I mainly work in Python and JavaScript.

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

[mhitza]

Shift-F6 (rename refactor) is my goto, and what I miss most in a code editor (maybe LSPs support that today for most languages).

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.

[lanstin]

The point of good names is not just readability but also to sharpen your cognitive model of the solution. That moment when you realize you don’t know what to name a thing is a valuable prompt to deepen your thinking a bit.

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.

[marcosdumay]

Use the Python type hints. You don't need to be specific, they help a lot even when you have some 'anys' inside composed types.

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.

[steine65]

100% agreed

[regexorcist]

I develop with a very custom neovim using only the keyboard. Over the years I've become really fast. And yet I'm doing it less and less myself and ask the LLM even small things. In my case the switch happened naturally as I moved to local AI and fully integrated the coding harness into my tmux + neovim workflow. Neovim becomes more of a project and file explorer, together with lazygit to diff review the changes.