Ferramentas de IA para programação estão transformando completamente o cenário de desenvolvimento de software. Hoje, desenvolvedores já contam com ferramentas como GitHub Copilot, Amazon CodeWhisperer e ChatGPT para gerar código, corrigir bugs, criar a estrutura de testes e acelerar tarefas rotineiras. Código que antes levava horas para ser escrito agora pode surgir em minutos, às vezes em segundos. Prompting está rapidamente se tornando uma habilidade central para quem desenvolve software.
A IA veio para ficar. A promessa é clara: mais output, entregas mais rápidas e menos trabalho repetitivo. Mas esse salto de velocidade levanta uma questão mais profunda:
Estamos construindo bem, ou apenas rápido?
Este artigo explora essa pergunta sob a ótica do Software Craftsmanship, trazendo uma perspectiva pragmática sobre como adotar IA sem abrir mão dos princípios que tornam um software realmente bom.
Produtividade de verdade em software não tem a ver com quantas linhas de código são produzidas, nem com a velocidade com que são digitadas. Trata-se de quão bem desenvolvedores resolvem problemas relevantes, garantem que suas soluções estejam corretas e deixam o codebase em um estado melhor do que encontraram.
Produtividade é a capacidade de entregar, de forma consistente, software valioso e sustentável, com o mínimo de atrito, retrabalho ou risco. Isso exige muito mais do que output rápido; exige clareza, correção e capacidade de mudança.
A IA nos dá um motor poderoso. Mas produtividade ainda precisa de volante. Quando velocidade é confundida com progresso, times acabam entregando mais código de baixa qualidade, gerando mais retrabalho e acumulando riscos de longo prazo.
Na prática, muitos times já estão vivendo um paradoxo:
Funcionalidades são entregues mais rápido…
…mas bugs, regressões e entropia aumentam.
Isso não acontece porque a IA escreve código ruim. Acontece porque qualidade de código, modularidade, testabilidade e conhecimento do time são fatores sistêmicos que a IA não leva em conta automaticamente.
E esse é o ponto central:
Produtividade em software é uma propriedade do sistema, não da velocidade de um desenvolvedor individual.
Gerar código mais rápido não reduz, por si só, tempo de entrega, esforço de manutenção ou retrabalho. Se o código gerado estiver desalinhado com a intenção do negócio ou mal projetado, o custo aparece depois, e costuma ser alto. Velocidade só é produtiva quando sustenta clareza, correção e adaptabilidade.
Quando combinada com princípios sólidos de engenharia, a IA pode amplificar não apenas a velocidade, mas também a efetividade, ajudando times a entregar software melhor, e mais rápido.
Quando se fala em produtividade no desenvolvimento de software, muitas pessoas ainda pensam em termos de quão rápido os desenvolvedores conseguem escrever código. Mas estudos e a experiência prática mostram um cenário bem diferente.
Um estudo da Microsoft Research, de 2019, mostra que menos de 25% do tempo de um desenvolvedor é gasto escrevendo código. A maior parte do tempo vai para atividades como leitura de código, navegação pela codebase, entendimento do comportamento do sistema, reuniões, refinamento de requisitos etc. Mesmo com ajuda da IA, nada substitui a compreensão profunda da estrutura interna do sistema, do seu design, da intenção e da complexidade do codebase.
Isso deixa uma mensagem clara: o gargalo no desenvolvimento de software não é a velocidade de digitação do código, mas a rapidez com que o desenvolvedor entende o que e onde precisa mudar.
E é aí que a situação se complica.
Mesmo com a IA acelerando a geração de código, o trabalho de entender o sistema continua existindo. Mas quando esse sistema é desorganizado (com limites modulares ruins, nomes inconsistentes, lógica duplicada ou testes ausentes), o custo de entendimento aumenta significativamente.
A IA não elimina esse custo. Em muitos casos, ela o amplifica.
O problema não é quão rápido conseguimos escrever código novo, é quão rápido conseguimos mudar e entender com segurança o código que já existe.
O que torna esse entendimento difícil?
● Modularização ruim: Quando o código está espalhado por domínios mal definidos ou sobrepostos, o desenvolvedor precisa seguir a lógica por vários arquivos ou serviços para entender o comportamento.
● Nomes vagos ou inconsistentes: Nomes ruins em qualquer nível (pacotes, classes, funções, variáveis) aumentam o esforço mental necessário para entender o que o código faz.
● Alta complexidade: Lógica profundamente aninhada, métodos longos ou condicionais complexos aumentam a complexidade ciclomática e cognitiva, tornando o código mais difícil de ler e modificar com segurança.
● Falta de cobertura de testes: Sem testes significativos e atualizados, é difícil entender o comportamento pretendido ou saber se uma mudança vai quebrar algo.
● Testes verbosos: Ironia à parte, testes ruins podem ser piores que nenhum teste. Eles geram ruído e falsa confiança, em vez de clareza e segurança.
● Duplicação: Lógicas copiadas e coladas pela codebase exigem múltiplas alterações para corrigir um único problema, aumentando o risco de regressão e desperdício de esforço.
Esses problemas se acumulam quando vários desenvolvedores, usando IA, geram código rapidamente sem melhorar a estrutura do sistema. Mais código não significa mais valor quando o sistema se torna difícil de entender e evoluir. Esses não são só problemas de higiene de código. São bloqueadores sistêmicos de produtividade. São bloqueadores sistêmicos de produtividade. E se não forem tratados, nenhuma aceleração por IA será suficiente. Na verdade, ela provavelmente só vai enterrar as equipes em mais código que elas não compreendem totalmente.
Nesse contexto, práticas de Software Craftsmanship, como design modular, disciplina de nomenclatura e princípios de código limpo, não são luxos. São mecanismos que economizam tempo. Tais práticas reduzem o atrito cognitivo que os desenvolvedores enfrentam diariamente aumentando o retorno sobre o investimento (ROI) de cada minuto gasto navegando ou modificando uma codebase.
Digitar não é onde os desenvolvedores gastam mais tempo. O tempo vai para ler, entender, corrigir, esclarecer e adaptar código. Quanto mais difícil for ler e raciocinar sobre o código, mais tempo leva para construir algo novo. Acelerar a geração sem melhorar a estrutura só torna o trabalho futuro mais lento e arriscado.
A IA pode reduzir drasticamente o esforço, mas apenas quando ajuda a esclarecer e simplificar, e não a esconder. O Craftsmanship garante que a aceleração não aconteça às custas da compreensão.
A programação é uma das formas mais precisas de comunicação humana. Ao contrário da linguagem natural, que aceita ambiguidades e metáforas, o código-fonte exige clareza absoluta e consistência lógica. Aqui, cada caractere é fundamental.
É por isso que a transição da intenção humana para um software funcional sempre foi desafiadora, e é também onde a IA generativa encontra sua maior fricção.
Modelos de linguagem como Copilot e ChatGPT foram projetados para prever e gerar sequências de texto plausíveis, inclusive código. Contudo, as entradas dos prompts costumam sofrer com a ambiguidade da linguagem natural. Ainda que o desenvolvedor tenha um objetivo definido, os prompts frequentemente falham na entrega de contexto, clareza e precisão necessários para resultados de alta qualidade. E pior: a IA pode estar se baseando em uma codebase já mal estruturada.
Assim, temos agora uma situação em que:
● Desenvolvedores escrevem prompts vagos com base em um entendimento incompleto do sistema ou do código
● O código gerado pela IA pode ser influenciado por padrões de baixa qualidade presentes na codebase ou nos dados públicos de treinamento
● Código gerado é frequentemente incorporado ao projeto antes de ser totalmente compreendido, o que introduz bugs ocultos e dívidas técnicas significativas.
Esse ciclo de feedback degrada rapidamente a qualidade do sistema, especialmente quando a codebase não tem uma estrutura semântica sólida como mostra um estudo da Universidade de Stanford.
Um sistema mal modularizado com limites de domínio fracos, nomes pouco claros e padrões arquiteturais inconsistentes, oferece pouca orientação para um modelo de linguagem. A IA não tem contexto de negócio e sua única referência é o código existente, que pode ser um amontoado de práticas contraditórias.
Sem fundamentos sólidos de design e modularização de software, as ferramentas de IA tendem a amplificar falhas já presentes na base. Por exemplo:
● Uma classe inchada cresce ainda mais
● Um método mal nomeado é copiado e modificado em outro lugar
● Uma abstração que falta continua ausente e repetida em vários arquivos
Nesse cenário, o Software Craftsmanship se torna ainda mais importante, não menos. Código bem modularizado, bem nomeado e bem testado não apenas ajuda humanos a navegar no sistema como também oferece à IA padrões melhores para trabalhar. Isso também foi demonstrado no estudo de Stanford.
Fazer um prompt de alteração dentro de um módulo bem definido, com boa cobertura de testes, tem muito mais chance de gerar código correto e sustentável.
LLMs operam entre a ambiguidade da linguagem natural e o determinismo do código. Se a codebase for frágil e os prompts vagos, nem os modelos mais robustos salvarão o resultado. A mediocridade, quando automatizada, apenas escala o caos.
É o Software Craftsmanship que impõe o rigor necessário à IA. Se a IA é a ferramenta de alta potência, o Craftsmanship é a planta do projeto. Sem ela, não estamos criando software melhor; estamos apenas acelerando a produção de legado técnico.
Uma consequência muitas vezes ignorada da IA generativa no desenvolvimento de software é a aceleração da perda de conhecimento.
Tradicionalmente, quando um desenvolvedor escrevia um trecho de código, ele dedicava tempo a pensar na lógica, fazer escolhas de design, nomear elementos e entender como ele se encaixava no sistema. Embora lento, esse processo ajudava o desenvolvedor a internalizar as regras de negócio, restrições técnicas e os trade-offs do que estava construindo.
Mas quando a IA gera esse código em segundos, o desenvolvedor se torna um editor passivo, e não um autor ativo. A compreensão profunda que surge ao lidar com um problema muitas vezes desaparece.
Em um projeto recente, enfrentamos um pull request de alto impacto, com modificações abrangendo dezenas de arquivos, o que aumentou a complexidade da revisão. Quando questionado sobre a lógica de negócios da atualização ou o tratamento de casos extremos, a resposta foi surpreendente: “Não tenho certeza. Precisaria analisar o código novamente.” E ele tinha acabado de codar. Na prática, a IA havia gerado a maior parte das mudanças, e o desenvolvedor apenas fez o prompt, copiou, colou e editou superficialmente.
Este não é um caso isolado. Estamos vendo um padrão crescente:
● Desenvolvedores já não conseguem explicar o próprio código
● As bases de código crescem mais rápido do que as equipes conseguem compreendê-las
● O conhecimento deixa de ser transferido e passa a ser delegado à ferramenta.
Pior ainda, isso não acontece apenas no nível individual. Nas organizações modernas, os sistemas costumam ser grandes e distribuídos, construídos por vários desenvolvedores, trabalhando em paralelo, muitas vezes em microsserviços distintos. Cada desenvolvedor traz uma compreensão diferente do sistema, do domínio e das boas práticas de design. Os prompts variam, o contexto também, e isso muda completamente o que a IA produz. E a IA se baseia apenas no que vê na codebase, que pode já estar inconsistente ou mal estruturada.
O resultado? Uma bagunça de lógicas sobrepostas, esforços duplicados, implementações divergentes e perda de coerência semântica entre serviços. Uma única alteração gerada por IA, se não for cuidadosamente revisada e compreendida, pode introduzir inconsistências sutis que se espalham pelo sistema. À medida que isso se acumula, as equipes gastam cada vez mais tempo tentando entender a intenção por trás de códigos que nunca compreenderam de verdade.
O Software Craftsmanship oferece um contraponto. Ele valoriza o entendimento compartilhado, clareza semântica e design intencional. Em um mundo cada vez mais acelerado, esses princípios protegem manutenibilidade a longo prazo e a eficácia das equipes. Sem eles, estamos construindo sistemas que não compreendemos totalmente, em uma velocidade que não conseguimos acompanhar.
Quando desenvolvedores geram grandes volumes de código sem domínio do conteúdo ou sem debater a intencionalidade do design, o conhecimento coletivo da equipe se deteriora. O código torna-se uma caixa preta até mesmo para quem o escreveu, levando o sistema a evoluir, com o tempo, de forma errática e arriscada.
O Craftsmanship ajuda as equipes a se manterem próximas do código, garantindo que a IA acelere a entrega sem desconectar os desenvolvedores do que está sendo construído.
"Dependência excessiva de assistência de IA pode erodir competências centrais de engenharia"
Code review sempre foi um dos principais quality gates e uma das atividades mais importantes de compartilhamento de conhecimento em um processo profissional de desenvolvimento de software. Uma boa review identifica falhas de design, bugs e mal-entendidos antes que cheguem à produção. Mas, para que reviews sejam realmente eficazes, as mudanças em análise precisam ser compreensíveis, ter contexto e, de forma crítica, serem pequenas o suficiente para que alguém consiga raciocinar sobre elas.
O código gerado por IA está quebrando esse equilíbrio.
Desenvolvedores, agora munidos de assistentes rápidos e poderosos, conseguem fazer mudanças abrangentes em dezenas de arquivos em questão de minutos. O que antes exigia dias de reflexão cuidadosa, decisões de design e iteração, hoje pode ser gerado com poucos prompts e colado diretamente no codebase. A velocidade é viciante, mas vem acompanhada de custos relevantes:
● O tamanho dos pull requests está crescendo de forma significativa.
● A complexidade das mudanças aumenta, muitas vezes com decisões de design inconsistentes entre os arquivos modificados.
● Reviewers ficam sobrecarregados e deixam de conseguir avaliar, de forma significativa, o que mudou e por quê.
A reação natural a um pull request gigantesco? Passar o olho por cima, ou pior, dar um rubber stamp.
Quando as reviews ficam superficiais, a qualidade cai. Bugs passam. Inconsistências se acumulam. Dívida de design cresce. E, mais grave ainda, a oportunidade de aprendizado coletivo desaparece. Code review não é só sobre aprovar mudanças, é sobre construir entendimento compartilhado dentro do time.
Isso não é apenas um problema de IA. Pull requests grandes e praticamente impossíveis de revisar sempre foram um anti-pattern. A diferença é que as ferramentas modernas de geração de código tornaram esse problema muito mais agudo. Hoje é mais fácil do que nunca pular etapas básicas de disciplina de engenharia em nome da velocidade.
Software Craftsmanship pede outra postura:
● Commits frequentes, pequenos e bem delimitados.
● Decisões de design intencionais, não apenas código que “funciona”.
● Reviews de verdade, nas quais tanto quem escreve quanto quem revisa aprendem e evoluem juntos.
● Pair Programming, onde o compartilhamento de conhecimento e melhores decisões de naming e design surgem naturalmente, reduzindo a necessidade de reviews formais.
A IA pode ajudar nesse processo, gerando boilerplate, sugerindo melhorias e acelerando tarefas mais mecânicas, mas apenas se mantivermos controle sobre o ritmo e a escala das mudanças. Caso contrário, o risco é transformar o desenvolvimento em uma esteira rápida de código não revisado, onde o custo de cada erro só aparece meses depois.
A IA torna mudanças grandes e abrangentes muito fáceis. Revisar e validar essas mudanças, especialmente quando atravessam vários arquivos ou serviços, fica bem mais difícil. Quando as reviews são superficiais ou simplesmente ignoradas, a qualidade do código sofre e bugs inevitavelmente escapam.
Usada com critério, a IA ainda pode apoiar mudanças pequenas e significativas. Desenvolvedores podem iterar com prompts menores, preservando a capacidade de revisão e a modularidade do código.
Nota: estamos avaliando ferramentas de AI code review para revisar PRs com base nas nossas próprias diretrizes de código e qualidade de design. Os testes iniciais são bastante promissores. Mais sobre isso em um próximo post.
No desenvolvimento de software, estrutura é significado.
Nós dependemos de modularização semântica, com fronteiras arquiteturais claras, nomes significativos e responsabilidades bem definidas, para que sistemas sejam compreensíveis e sustentáveis ao longo do tempo. Quando um codebase é semanticamente bem estruturado, desenvolvedores conseguem responder rapidamente perguntas fundamentais:
O que esse módulo faz? Que parte do domínio de negócio ele representa? Onde essa mudança deveria entrar?
Infelizmente, a maioria dos codebases já está longe do ideal. As fronteiras semânticas, ou bounded contexts, para usar a terminologia de Domain Driven Design (DDD), são difusas ou simplesmente inexistentes. A lógica de negócio fica espalhada por camadas e serviços. Os nomes são inconsistentes ou genéricos. Decisões de modularização, quando existiram, estão soterradas sob anos de dívida técnica.
E agora, as ferramentas de IA estão aprendendo e construindo em cima desse caos.
Sem uma base semântica sólida, até o assistente de IA mais avançado tem dificuldade em gerar soluções de alta qualidade. Em vez disso, ele reforça inconsistências existentes, introduz mais duplicação e estica ainda mais classes e métodos que já eram grandes demais. Cada nova mudança vai corroendo um pouco mais a clareza do sistema.
Essa deterioração semântica se acelera com o tempo:
● Mudanças geradas por IA se baseiam no contexto disponível, muitas vezes um codebase mal estruturado.
● Desenvolvedores diferentes usam prompts diferentes, guiados por seus próprios modelos mentais.
● Código gerado por IA em serviços ou repositórios distintos cria colisões de nomes, lógica duplicada e implementações divergentes. Isso leva a um semantic drift que torna sistemas grandes cada vez mais difíceis de evoluir de forma coesa
O resultado é um sistema que funciona tecnicamente, mas é conceitualmente incoerente, um mosaico de ideias, estilos e suposições. A cada nova linha adicionada, entender o sistema fica mais difícil.
Software Craftsmanship segue na direção oposta, colocando a semântica no centro:
● Código deve expressar intenção.
● Módulos devem refletir capacidades de negócio e fronteiras de mudança.
● Nomes devem revelar propósito, não apenas detalhes de implementação.
Quando perdemos semântica, perdemos exatamente aquilo que torna mudanças seguras, rápidas e economicamente viáveis. A IA pode ajudar aqui, mas apenas quando é guiada por desenvolvedores que entendem fronteiras semânticas e sabem promptar com intenção. Combinar a velocidade da IA com a consciência de design do Software Craftsmanship é o caminho para preservar significado e estrutura em escala.
Uma das práticas mais poderosas do Software Craftsmanship é o Test-Driven Development (TDD - desenvolvimento orientado a testes), não apenas para garantir correção, mas para guiar o design. Começar pelo teste ajuda a esclarecer expectativas, quebrar comportamentos complexos e produzir código mais limpo e modular. Bons testes funcionam tanto como documentação quanto como feedback de design.
TDD não é só sobre correção. É sobre escrever código melhor.
A IA está mudando a forma como escrevemos código e, junto com isso, a forma como escrevemos testes. Muitos desenvolvedores hoje geram o código de produção primeiro e depois pedem para a IA criar os testes. É conveniente, mas inverte o fluxo de intenção. Em vez de os testes definirem o comportamento, eles viram um rubber stamp do que o código faz naquele momento, mesmo que esteja errado, ineficiente ou desalinhado com os objetivos do negócio.
Isso vira o teste de cabeça para baixo:
● Os testes passam a se adaptar ao código, em vez de o código se adaptar aos testes.
● Bugs e problemas de design ficam cristalizados, com os testes reforçando o erro em vez de preveni-lo.
● A cobertura de testes pode até parecer ótima, mas o valor real desses testes costuma ser baixo.
● Quando os testes quebram, desenvolvedores pedem para a IA “consertar”, muitas vezes sem entender o problema de fundo.
Estamos vendo cada vez mais suítes de testes cheias de:
● Asserções fracas ou redundantes.
● Muito setup duplicado e repetição de asserções para variações pequenas de comportamento.
● Testes que não deixam clara a intenção nem exploram edge cases.
● Código verboso, difícil de ler e de manter.
Dito isso, a IA pode ser uma grande aliada nos testes, desde que seja bem guiada. Desenvolvedores podem usar a mentalidade de TDD para estruturar melhor seus prompts. Em vez de pedir “um código que faça X”, podem fornecer o contexto geral e avançar em passos pequenos, descrevendo, em cada passo, o comportamento esperado de um módulo específico, as restrições envolvidas e as diretrizes de design relevantes. Dá para ser bastante preciso nos nomes de classes, métodos, parâmetros e tipos de retorno esperados. Também é possível descrever os diferentes cenários de teste desejados, desde o caminho feliz até uma lista de edge cases, e até pedir para a IA avaliar se algum cenário ficou de fora ou se há fragilidades no design proposto.
Mesmo quando a IA gera o código primeiro, o raciocínio por trás do TDD continua sendo valioso. Ele ajuda a formular prompts melhores, chegar a designs mais sólidos e produzir testes realmente úteis.
Alguns times já pedem para a IA escrever o teste primeiro, ou ajudar a refinar um teste existente, antes mesmo de começar a codar. Essa abordagem ainda está amadurecendo, mas aponta para um futuro interessante: a IA como parceira de design, não apenas como geradora de código.
No fim das contas, testar não é só validar correção, é proteger qualidade. Quanto mais tratarmos a IA como uma ferramenta que amplia o julgamento humano, mais conseguimos preservar a essência do Craftsmanship, mesmo construindo software mais rápido e em uma escala cada vez maior.
A IA está revolucionando a forma como escrevemos código, mas, sem orientação, ela pode corroer exatamente as qualidades que tornam o software valioso.
É aí que entra o Software Craftsmanship.
Craftsmanship não tem a ver com resistir à mudança nem com romantizar o passado. Trata-se de sustentar princípios atemporais que garantem que o software continue sendo um ativo, e não um passivo, independentemente de como é construído. Em sua essência, o Software Craftsmanship é um compromisso com:
● Software bem construído: código claro, testável, sustentável e alinhado às necessidades do negócio.
● Profissionalismo: práticas que garantem sustentabilidade no longo prazo, crescimento do time e agilidade para o negócio.
● Parcerias produtivas: entre desenvolvedores e stakeholders, baseadas em confiança e entendimento compartilhado.
Esses princípios são mais importantes do que nunca na era da IA.
Large Language Models (LLMs) não entendem o seu negócio. Não se importam com a sua arquitetura. Não reconhecem os trade-offs que você está fazendo. Sem prompts bem pensados e contexto de qualidade, eles vão gerar código plausível rapidamente. Esse código pode tanto criar progresso de curto prazo quanto fricção significativa no longo prazo.
O Software Craftsmanship ajuda justamente ao:
● Definir o papel da IA: não como um coder autônomo, mas como um assistente poderoso que precisa ser guiado.
● Reforçar a intenção: garantindo que cada mudança fortaleça modularidade, clareza e significado de negócio.
● Proteger a correção: incorporando testes, pensamento de design e code review ao fluxo de trabalho.
● Conter a entropia: por meio de práticas consistentes, convenções de nomenclatura e disciplina arquitetural.
Mais importante ainda, Craftsmanship abraça a IA sem abrir mão de padrões. Reconhece que digitar nunca foi o gargalo; compreensão, tomada de decisão e qualidade sempre foram. A IA pode acelerar a entrega, mas só quando a base é sólida.
Esse é o desafio, e também a oportunidade, para os times de software de hoje:
Use IA para ir mais rápido, mas garanta que você está indo na direção certa.
O Software Craftsmanship assegura que seu código não seja apenas entregue rapidamente, mas que continue valioso ao longo do tempo.
A IA está transformando o desenvolvimento de software. Ela ajuda a codar mais rápido, automatizar o trabalho repetitivo e explorar soluções que talvez não considerássemos sozinhos.
Mas velocidade não é a mesma coisa que produtividade. E volume não é sinônimo de valor.
Se adotarmos IA de forma acrítica, corremos o risco de inundar nossos sistemas com código difícil de manter e desconectado. Código gerado rapidamente, mal compreendido e revisado de forma superficial.
O que precisamos agora é intencionalidade. Uma mentalidade que valorize clareza, estrutura e melhoria contínua. Um compromisso com práticas que preservem a agilidade do negócio, e não apenas acelerem entregas de curto prazo.
Esse é o papel do Software Craftsmanship na era da IA. Não resistir à mudança, mas guiá-la. Fazer perguntas melhores. Definir restrições melhores. Garantir que o software que construímos continue robusto, compreensível e adaptável, mesmo à medida que as ferramentas evoluem.
Craftsmanship transforma a IA em uma aliada poderosa. Não ao entregar o controle, mas ao elevar o padrão do que consideramos bom. Assim, cada linha de código, escrita por IA ou por humanos, contribui para o sucesso no longo prazo.
O futuro do software não será escrito apenas pela IA, mas por quem souber usá-la com craft.
A IA é o motor.
O Craftsmanship é a bússola.