Mudança de devtools é barata; ser dono deles não é

O argumento original

David Crawshaw publicou um texto defendendo que, com agentes de código, entramos numa era em que devtools serão personalizadas individualmente: agentes conseguem entrar em qualquer codebase, adicionar features ao código-fonte das ferramentas que usamos e fazer rebase automático dos patches a cada release. Segundo ele, tanto o custo inicial quanto o custo contínuo de personalizar software teriam desaparecido.

A crítica: atenção é o custo real

Lalit Maganti, co-fundador do Perfetto (ferramenta de tracing open source mantida há nove anos), argumenta que Crawshaw subestima o custo contínuo. A IA reduziu drasticamente o custo de modificar software, mas personalizar de verdade exige atenção humana - e atenção é mais escassa do que nunca.

Maganti ilustra com um experimento mental: você pede a um agente para adicionar um "focus mode" a um diff viewer. Funciona bem. Meses depois, o upstream adiciona detecção de moves entre arquivos. O agente faz o rebase sem conflitos, mas surge uma decisão de design: o que o focus mode deve fazer quando uma função foi movida mas também contém edições? Não há resposta óbvia - depende do que você quer ver. Se você aceita que o agente decida, delegou sua autoridade. Se quer controlar, precisa interromper seu dia para opinar sobre o design de uma ferramenta.

O paradoxo central: qualquer ferramenta personalizada individualmente tem baixa probabilidade de falhar num dado dia, mas se você personaliza todas as suas devtools, multiplica o número de ferramentas que podem demandar sua atenção de forma imprevisível.

O problema em escala

Em empresas grandes, o problema se agrava. Maganti relata que uma big tech usa extensivamente o Perfetto, e diferentes times fizeram forks ad hoc com mudanças locais. Agora um engenheiro luta para consolidar tudo porque cada time entende "Perfetto" de forma diferente. Quando uma devtool media trabalho entre pessoas, ela forma parte da linguagem comum - e personalizações que alteram semântica compartilhada criam caos.

Upstream também fica mais capaz

Maganti aponta que não se deve comparar desenvolvimento upstream pré-IA com forks pós-IA. Mantenedores também usam agentes para investigar reports, prototipar features e adicionar pontos de extensão. O trabalho feito no upstream beneficia todos; um fork pessoal beneficia só você.

A economia de blocos de construção

A visão alternativa que Maganti considera mais provável vem de Mitchell Hashimoto: agentes são bons em compor componentes de alta qualidade. Em vez de forks se tornarem a norma, o futuro seria de blocos bem documentados sobre os quais se constroem artefatos especializados. Como exemplo, ele cita o bb, um IDE agêntico que permite aos usuários adicionar novas superfícies de produto via plugins construídos sobre um core mantido - não via fork direto do projeto.

Conclusão

Sempre haverá quem goste de manter patches customizados (como no ecossistema suckless). Mas a maioria dos usuários quer apenas fazer seu trabalho com ferramentas confiáveis, e o caminho é oferecer experiências sólidas com bons pontos de extensão, não transferir o ônus de manutenção para cada usuário.