Research

Code editors put dozens of automated refactorings a keystroke away. Earlier studies had found that developers still do more than half of their refactoring by hand, and describe the tools as unpredictable and hard to trust. My PhD asked why.

I built three realistic change tasks out of refactorings mined from open-source history, watched 17 developers with professional experience work through them while thinking aloud, and interviewed each one afterwards. A survey of 46 more developers followed. Four results stand out:

• Developers approached the same task in three different ways, and the existing tools fit only one: a tool was used in 9 of 13 workflows that followed the code’s structure, against 4 of 22 that followed compiler errors and 4 of 16 that followed the tests.
• Predictability came up in more than half of the coded interview passages, more than any other factor: could they tell in advance what a tool would do to their code?
• What they wanted from a tool was control and visibility: to steer how it changes the code, to see what it will change beforehand, and to inspect the result afterwards.
• In a scenario where a refactoring tool fit the task, lack of trust was the most prominent reason survey respondents gave for not using it.

From there I proposed stepwise refactoring tools, which split one all-or-nothing transformation into smaller steps a developer can steer and check, and built a proof of concept as an IntelliJ plugin. The study system, the tasks and the data are public; the dataset has been downloaded more than 3,100 times.

I now work on agentic tools. Every change an agent proposes puts the same question to a developer: can I tell what this will do, and can I check it?