Os desenvolvedores não se apegam a ferramentas como Vim e Emacs ou a ambientes de desenvolvimento integrados apenas por estarem acostumados a elas, mas porque essas ferramentas se tornam parte da maneira como pensam, escrevem e revisam o código. À medida que o usuário adquire experiência prolongada, os comandos e procedimentos se transformam em conhecimento implícito e memória muscular, fazendo com que a ferramenta pareça uma extensão natural de sua mão. Essa relação explica parte da hesitação em relação às ferramentas de programação agêntica, que conseguem produzir aplicações completas rapidamente, mas são menos precisas, claras e previsíveis.
O artigo relaciona as ferramentas à confiança e ao processo que as cerca. Uma ferramenta confiável não é apenas aquela que executa a tarefa, mas aquela que permite ao desenvolvedor conhecer seus limites e comportamento e prever seus resultados. Já as ferramentas de inteligência artificial agêntica mudam continuamente de capacidade e dependem de comandos em linguagem natural que podem ser ambíguos. De acordo com os dados da pesquisa mais recente com desenvolvedores mencionada pelo artigo, a proporção de uso de inteligência artificial aumentou de 76% para 84%, enquanto a confiança nela caiu de 40% para 29%.
A ferramenta é parte do processo de desenvolvimento
Aprender a trabalhar no terminal, dentro de um editor de texto ou em um ambiente de desenvolvimento integrado não significa apenas aprender um programa separado; significa construir um processo completo para escrever, compreender e aperfeiçoar código. Por isso, a transição do terminal para um ambiente de desenvolvimento integrado pode exigir a reformulação da maneira de trabalhar, e a transição de qualquer um deles para uma ferramenta de programação agêntica representa uma mudança ainda maior.
Tricia Gee, defensora da produtividade dos desenvolvedores, explica que um desenvolvedor pode ser mais rápido usando o ambiente de desenvolvimento que conhece, porque seus dedos se acostumaram ao que deve ser feito. O mesmo se aplica a usuários experientes de Vim e Emacs. Com o tempo, forma-se uma competência inconsciente que ajuda o desenvolvedor a confiar na ferramenta e a utilizá-la para produzir e aperfeiçoar código.
As ferramentas tradicionais, como ambientes de desenvolvimento integrados, ferramentas de contêineres e analisadores estáticos, oferecem ao usuário uma visão clara de seus limites e funções. Já a inteligência artificial penetra em várias partes da cadeia de ferramentas do ciclo de vida do desenvolvimento de software, o que faz com que a redução da confiança nela afete todo o processo. A escrita do código pode se tornar mais rápida, mas verificá-lo e garantir que ele não causará falhas dispendiosas em produção pode levar mais tempo.
As ferramentas não consertam processos defeituosos
As ferramentas de programação agêntica mudaram a natureza do processo de desenvolvimento, o que pode tornar menos adequadas, em sua forma atual, as ferramentas que surgiram em torno do processo anterior, como ferramentas de análise estática, testes unitários, integração contínua e implantação contínua. Mas o artigo distingue entre a ferramenta e o processo que ela incorpora: uma boa ferramenta de integração e implantação contínuas não garante entregas mais rápidas, um ambiente de desenvolvimento integrado poderoso não garante código melhor, e um sistema de rastreamento de problemas não garante estimativas precisas de esforço.
Parte do processo se forma dentro da cultura da organização e do comportamento e dos padrões de seus integrantes. Por isso, novas ferramentas podem falhar, por maiores que pareçam ser suas promessas, se não estiverem alinhadas à cultura e aos processos existentes ou se os desenvolvedores não compreenderem por que devem usá-las. O artigo observa que as ferramentas de programação agêntica ganharam rápida disseminação porque ajudam os desenvolvedores a resolver problemas rapidamente, mas, ao mesmo tempo, revelaram falhas antigas na definição de requisitos, na definição do problema e no significado de resolvê-lo.
A produção de código tornou-se quase gratuita em comparação com o que era antes, mas sua revisão não se tornou igualmente gratuita. Os desenvolvedores podem enfrentar mudanças enormes em solicitações de pull produzidas pelos agentes em instantes, o que aumenta a carga sobre os revisores ou incentiva a adoção de revisões superficiais. Está sendo desenvolvida a utilização de um modelo de linguagem como juiz para ampliar o escopo da revisão, mas construir confiança na capacidade da inteligência artificial de revisar código escrito por inteligência artificial exige trabalho adicional.
A execução do código também tem seus custos. Eles incluem os custos de infraestrutura, os recursos de nuvem — computação, memória e tráfego —, os serviços dependentes e as interfaces de programação hospedadas, além do custo das falhas, como interrupções, violações de segurança e custos de oportunidade. Ferramentas que produzem código sem considerar esses fatores não são necessariamente úteis e podem enfraquecer o processo que antes produzia software confiável.
Construindo confiança por meio da responsabilidade e dos processos
No ciclo de desenvolvimento tradicional, a confiança era distribuída por funções interligadas: os gerentes de produto definiam os requisitos, os arquitetos projetavam as soluções, os engenheiros construíam o software e revisavam as mudanças, a equipe de garantia de qualidade testava os pontos de falha e, depois do lançamento, especialistas de DevOps e SRE monitoravam o desempenho e os recursos. Essa distribuição ajudava a reduzir a probabilidade de que uma pessoa ou ferramenta agisse além dos limites e prejudicasse o sistema.
O artigo considera que o ciclo de desenvolvimento apoiado por inteligência artificial precisa de princípios semelhantes: trabalhar com as pessoas, definir responsabilidade e prestação de contas, compartilhar os processos e aperfeiçoá-los gradualmente e reduzir as oportunidades de erro. Os seres humanos devem continuar sendo as partes responsáveis, com esclarecimento dos pontos em que a inteligência artificial contribuiu.
A responsabilidade não é transferida para o agente simplesmente porque ele criou a mudança. A pessoa que envia a mudança para o repositório é responsável pelo código, e quem aprova a solicitação de pull é responsável pela aprovação. De acordo com a lógica apresentada pelo artigo, se a mudança causar a quebra do ambiente de produção, a culpa não pode ser atribuída ao ambiente de desenvolvimento ou à ferramenta; a responsabilidade recai sobre as pessoas e o processo que permitiram a passagem da mudança.
Essa transformação traz outro desafio relacionado à colaboração. O agente pode permitir que um único desenvolvedor execute tarefas que vão dos requisitos do produto às operações de DevOps, aumentando a probabilidade de que ele se transforme em uma ilha isolada, sem comunicação com o designer ou com o engenheiro especializado em determinada base de código. O artigo alerta que esse caminho pode levar a solicitações de pull enormes, mesmo que a ferramenta pareça capaz de executar o trabalho rapidamente.
A conclusão principal não é que as novas ferramentas sejam inúteis, mas que melhorar apenas as ferramentas não basta para consertar um ciclo de desenvolvimento defeituoso. As organizações precisam de processos que os desenvolvedores compreendam e aceitem, limites claros para o papel dos agentes, revisão humana com responsabilidade efetiva e colaboração que impeça que o desenvolvimento se transforme em uma atividade individual fechada. Assim, as ferramentas e a cultura poderão trabalhar juntas para construir uma nova confiança em um ambiente de desenvolvimento baseado em inteligência artificial.