{"id":23155,"date":"2026-08-09T13:53:00","date_gmt":"2026-08-09T13:53:00","guid":{"rendered":"https:\/\/scannn.com\/changing-devtools-is-cheap-owning-them-isnt\/"},"modified":"2026-08-09T13:53:00","modified_gmt":"2026-08-09T13:53:00","slug":"changing-devtools-is-cheap-owning-them-isnt","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/changing-devtools-is-cheap-owning-them-isnt\/","title":{"rendered":"Changing Devtools Is Cheap. Owning Them Isn\u2019t."},"content":{"rendered":"\n
\n

In
\nDevtools must be open source<\/a>
\n(via<\/a>), David Crawshaw makes the
\ncase that, because of coding agents, we\u2019re now in an era where devtools will be
\npersonalized by individual users. Specifically, agents\u2019 ability to jump into new
\ncodebases and build whatever we want means we\u2019ll be hacking on the source of the
\ndevtools we use day to day (even those without extension APIs) adding features
\nand automatically rebasing our patches across releases.<\/p>\n

The argument is seductive, especially to a reader who thinks of themselves as a
\nmaker or tinkerer: after all, the idea that you can hyper-tune everything you
\nuse sounds like a utopia; it means things can work exactly<\/em> how you want them
\nto.<\/p>\n

But I\u2019d argue that Crawshaw underappreciates the ongoing cost when he writes<\/p>\n

\n

\u201cBoth the upfront fixed costs and the ongoing costs of personalizing software
\nhave disappeared.\u201d<\/p>\n<\/blockquote>\n

While AI has made the upfront cost of changing<\/em> software a lot lower, properly
\npersonalizing software still requires your attention. And attention in the AI
\nage is scarcer than ever.<\/p>\n

Having maintained an open-source devtool designed to be modified and forked for
\nnine years now, I can say that most users don\u2019t want<\/em> to customize their
\ndevtools. They want someone else to make the tool reliable and coherent, so they
\ncan focus on the problems they opened it to solve. They reach for source
\nmodification only as a last resort, when a change is critical to their workflow
\nand no other route works.<\/p>\n

This is not to say that this sort of personalization won\u2019t become more common: I
\nabsolutely think it will. I just think it will take the form of strong core
\nsystems with well-defined boundaries and extension points.<\/p>\n

Personalization still needs a person#<\/a><\/h3>\n

As a thought experiment, imagine an open-source diff viewer with no extension
\nAPI. You find most diffs noisy, so you ask an agent to add a \u201cfocus mode\u201d that
\ncollapses imports, generated files, and other changes you consider mechanical.
\nIt works well and becomes part of your normal workflow.<\/p>\n

At first, life is good: everything works, and you\u2019ve solved your problem. Then
\nupstream releases a new version that refactors the code you changed. As Crawshaw
\nsuggests, you\u2019re clever, so you\u2019ve set up a bot to automatically rebase your
\nchanges onto each update. It resolves any merge conflicts and moves your code to
\nthe right place.<\/p>\n

But now suppose a few months pass and upstream makes a more substantial change:
\nit adds syntax-aware move detection. If a function moves between files, the
\nviewer now shows it as a move instead of one large deletion and addition. The
\nagent muddles through, rebases your focus-mode patch, and gets everything
\ncompiling without any merge conflicts.<\/p>\n

But now what should focus mode do if the function has mostly moved but also
\ncontains a few meaningful edits? Does it hide the whole block as a mechanical
\nmove? Does it show only the edited lines without any surrounding context? Or
\ndoes it show the whole function?<\/p>\n

There isn\u2019t an obviously correct answer; it depends on what you<\/em> want to see in
\nthe diff. So what, are you going to interrupt your day to make this decision?<\/p>\n

There\u2019s a central paradox here: if you\u2019re okay with \u201clet the agent decide\u201d, then
\nyou\u2019ve delegated your authority to the agent. For small choices, that may be
\nperfectly adequate. But if you want the tool to work exactly how you want, you
\nneed to inspect and direct those choices. Do you really want to have opinions
\nabout the design of a devtool you use forever?<\/p>\n

The key is attention<\/em>. Any one personalized tool might be unlikely to fail on a
\ngiven day, but if you do this to every devtool you use, you multiply the number
\nof tools that can unexpectedly demand your attention. Worse, those failures
\nare unpredictable: a tool might work for months and then break at the exact
\nmoment you urgently need it. Most engineers want to use devtools to accomplish a
\ntask; they don\u2019t want their attention diverted to designing and repairing them.<\/p>\n

Shared tools need a shared reality#<\/a><\/h3>\n

All of the above applies to small teams as well. You can share the attention
\ncost, but at the end of the day, the team still has to ask, \u201cHow much time do we
\nwant to spend on tools versus doing the actual work we\u2019re meant to be doing?\u201d<\/p>\n

I also want to look beyond Crawshaw\u2019s post and consider how this would work in
\nlarger companies: what happens when many teams independently personalize the
\nsame shared devtool?<\/p>\n

I\u2019ve seen this firsthand: another big tech company makes extensive use of
\nPerfetto, and has hit this exact problem. Different teams in that company
\ndecided to fork Perfetto and add ad hoc changes for their local needs. Now one
\nof the engineers there is fighting to consolidate them because of how painful it
\nis when every team means something different by \u201cPerfetto\u201d.<\/p>\n

Imagine the same pattern with a company-wide bug tracker. Do you want every team
\nto use a version with subtly different meanings for status, priority,
\nassignment, and resolution? What happens when a bug moves between teams?
\nDifferent layouts and personal filters are harmless; the problem begins when
\npersonalization changes the shared semantics or workflow.<\/p>\n

When a devtool mediates work between people, it also forms part of their common
\nlanguage. Teaching, auditing, reproducing investigations, and verifying that
\npeople are talking about the same thing all depend on a shared baseline.<\/p>\n

Upstream gets more malleable too#<\/a><\/h3>\n

We should also not compare pre-AI upstream development with post-AI forks.
\nMaintainers can use the same agents to investigate reports, brainstorm ideas,
\nand prototype new features. I can certainly attest to how useful AI has been for
\nboth implementing small feature requests from users and prototyping larger ones
\nto determine feasibility.<\/p>\n

In my opinion, upstream maintainers can, and should, spend the time saved on
\nimplementation making their tools more adaptable: implementing broadly useful
\nfeatures, adding configuration knobs where they make sense, and creating
\nextension points for recurring needs. AI lowers the cost of doing all of this,
\nincluding deciding where customization makes sense, adding more elaborate tests
\non creative uses of your tools and verifying backwards compatibility as these
\ninterfaces evolve.<\/p>\n

Upstream has a natural advantage here: any work done there benefits everyone<\/em>,
\nwhile a change to your personal fork benefits only you. By relying on upstream,
\nthe attention required to build good software shifts from people who don\u2019t<\/em>
\nwant to spend it to maintainers who have chosen to care.<\/p>\n

The building-block economy#<\/a><\/h3>\n

In my opinion, there\u2019s an alternative view that is much more likely to come
\ntrue, one described well in Mitchell Hashimoto\u2019s article on the
\nbuilding-block economy<\/a>.<\/p>\n

Concretely, it accepts the same premise: agents can write lots of code and build
\nniche applications, tools, integrations, forks, and so on. But instead of
\nassuming that forks will become the norm, Hashimoto argues that high-quality,
\nwell-documented building blocks will power this world.<\/p>\n

I tend to agree: agents are very good at composing high-quality components. If
\nmaintainers provide those components alongside a focused application, makers can
\nbuild specialized artifacts on top while accepting the costs. This model also
\ncreates an easy feedback loop for ideas to flow upstream because the product was
\ndesigned to be extended.<\/p>\n

I see signs that the world is already heading in this direction. For example,
\nbb<\/code><\/a> is a
\nvery interesting agentic IDE that I\u2019ve been playing around with recently. It has
\na very nice experience that lets users add substantial new product surfaces
\nthrough self-modification. But the key is that those features are plugins built
\naround a maintained core and extension system, not changes made by forking the
\nproject directly.<\/p>\n

bb<\/code> is also only a few weeks old at the time of writing, so we cannot draw any
\nfirm conclusions from it, but it\u2019s an interesting sign of the future, IMO.<\/p>\n

Wrapping up#<\/a><\/h3>\n

I care deeply about both the world of devtools and open source, so this is
\nsomething I feel very passionate about. Having been immersed in this world for
\nalmost a decade now, I think the future of well-built tools with thoughtful
\ndesign and well-designed extension points is bright.<\/p>\n

Sure, there will always be folks who want to fork and make ad hoc changes. These
\nare the same people who already maintain custom builds of their window manager
\nor terminal emulator, carrying a stack of patches to get everything exactly how
\nthey want it. For them, the tinkering is part of the enjoyment and craft.<\/p>\n

But I think most users just want to get their work done with devtools, and we
\nowe it to them to give them a strong, dependable experience instead of asking
\nthem to take on the burden of maintaining the product themselves.<\/p>\n<\/div>\n

Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

In Devtools must be open source (via), David Crawshaw makes the case that, because of coding agents, we\u2019re now in an era where devtools will be personalized by individual users. Specifically, agents\u2019 ability to jump into new codebases and build whatever we want means we\u2019ll be hacking on the source of the devtools we use […]<\/p>\n","protected":false},"author":16,"featured_media":23156,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23155","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23155","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23155"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23155\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23156"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}