Changing Devtools Is Cheap. Owning Them Isn’t. - Lalit Maganti
In<br>Devtools must be open source1<br>(via), David Crawshaw makes the<br>case that, because of coding agents, we’re now in an era where devtools will be<br>personalized by individual users. Specifically, agents’ ability to jump into new<br>codebases and build whatever we want means we’ll be hacking on the source of the<br>devtools we use day to day (even those without extension APIs) adding features<br>and automatically rebasing our patches across releases.<br>The argument is seductive, especially to a reader who thinks of themselves as a<br>maker or tinkerer: after all, the idea that you can hyper-tune everything you<br>use sounds like a utopia; it means things can work exactly how you want them<br>to.<br>But I’d argue that Crawshaw underappreciates the ongoing cost when he writes<br>“Both the upfront fixed costs and the ongoing costs of personalizing software<br>have disappeared.”
While AI has made the upfront cost of changing software a lot lower, properly<br>personalizing software still requires your attention. And attention in the AI<br>age is scarcer than ever.<br>Having maintained an open-source devtool designed to be modified and forked for<br>nine years now2, I can say that most users don’t want to customize their<br>devtools. They want someone else to make the tool reliable and coherent, so they<br>can focus on the problems they opened it to solve. They reach for source<br>modification only as a last resort, when a change is critical to their workflow<br>and no other route works.3<br>This is not to say that this sort of personalization won’t become more common: I<br>absolutely think it will. I just think it will take the form of strong core<br>systems with well-defined boundaries and extension points.<br>Personalization still needs a person#<br>As a thought experiment, imagine an open-source diff viewer with no extension<br>API. You find most diffs noisy, so you ask an agent to add a “focus mode” that<br>collapses imports, generated files, and other changes you consider mechanical.<br>It works well and becomes part of your normal workflow.4<br>At first, life is good: everything works, and you’ve solved your problem. Then<br>upstream releases a new version that refactors the code you changed. As Crawshaw<br>suggests, you’re clever, so you’ve set up a bot to automatically rebase your<br>changes onto each update. It resolves any merge conflicts and moves your code to<br>the right place.<br>But now suppose a few months pass and upstream makes a more substantial change:<br>it adds syntax-aware move detection. If a function moves between files, the<br>viewer now shows it as a move instead of one large deletion and addition. The<br>agent muddles through, rebases your focus-mode patch, and gets everything<br>compiling without any merge conflicts.<br>But now what should focus mode do if the function has mostly moved but also<br>contains a few meaningful edits? Does it hide the whole block as a mechanical<br>move? Does it show only the edited lines without any surrounding context? Or<br>does it show the whole function?<br>There isn’t an obviously correct answer; it depends on what you want to see in<br>the diff. So what, are you going to interrupt your day to make this decision?<br>There’s a central paradox here: if you’re okay with “let the agent decide”, then<br>you’ve delegated your authority to the agent. For small choices, that may be<br>perfectly adequate. But if you want the tool to work exactly how you want, you<br>need to inspect and direct those choices. Do you really want to have opinions<br>about the design of a devtool you use forever?<br>The key is attention. Any one personalized tool might be unlikely to fail on a<br>given day, but if you do this to every devtool you use, you multiply the number<br>of tools that can unexpectedly demand your attention.5 Worse, those failures<br>are unpredictable: a tool might work for months and then break at the exact<br>moment you urgently need it. Most engineers want to use devtools to accomplish a<br>task; they don’t want their attention diverted to designing and repairing them.<br>Shared tools need a shared reality#<br>All of the above applies to small teams as well. You can share the attention<br>cost, but at the end of the day, the team still has to ask, “How much time do we<br>want to spend on tools versus doing the actual work we’re meant to be doing?”<br>I also want to look beyond Crawshaw’s post and consider how this would work in<br>larger companies: what happens when many teams independently personalize the<br>same shared devtool?<br>I’ve seen this firsthand: another big tech company makes extensive use of<br>Perfetto, and has hit this exact problem. Different teams in that company<br>decided to fork Perfetto and add ad hoc changes for their local needs. Now one<br>of the engineers there is fighting to consolidate them because of how painful it<br>is when every team means something different by “Perfetto”.<br>Imagine the same...