A codificação por impulso — descrever o que você quer e aceitar o código gerado por um modelo sem uma análise aprofundada — produz protótipos em horas e sistemas frágeis em meses. Não é uma técnica ilegítima: é uma excelente técnica para explorar uma ideia, mas perigosa para construir algo de que uma empresa dependerá.
A confusão entre os dois é o problema. O que surge de uma sessão de produto gerada pelo usuário se parece muito com um produto: tem uma interface, responde, faz o que foi solicitado na frente da pessoa que solicitou. A diferença em relação a um produto real não está no que ele faz, mas em tudo o que ainda não foi decidido: o que acontece quando ele falha, quem pode ver o quê, como ele será alterado daqui a um ano e quem entende por que ele foi escrito daquela forma.
|
Dimensão |
Protótipo gerado |
Sistema em produção |
|---|---|---|
|
Mirar |
Para demonstrar que a ideia é possível. |
Funcionamento confiável por anos |
|
Erros |
Eles são corrigidos por regeneração. |
Eles são consertados sem danificar o resto. |
|
Dados |
Testado e limpo |
Real, incompleto, contraditório |
|
Segurança |
Fora do alcance |
Permissões, criptografia, auditoria |
|
Manutenção |
Não aplicável |
O 60-70% do custo total |
|
Propriedade do critério |
O modelo determinou a estrutura. |
Alguém tomou essa decisão e sabe porquê. |
A última linha é a que tem maior peso a médio prazo. Quando ninguém define a estrutura, ninguém pode defendê-la ou aprimorá-la. Ela se torna um texto que precisa ser interpretado a cada vez que é alterado, e essa interpretação leva tempo a cada mudança futura.
Isso não é apenas um palpite da indústria. A GitClear, ao analisar 211 milhões de linhas de código entre 2020 e 2024, descobriu que o trabalho de refatoração — reorganizar o código existente para torná-lo compreensível — caiu de cerca de 251 milhões de linhas de código em 2021 para menos de 101 milhões em 2024, enquanto a prática de copiar e colar aumentou de 8,31 milhões para 12,31 milhões de linhas e os blocos duplicados aumentaram oito vezes.
O relatório DORA 2024 do Google Cloud, baseado em uma pesquisa com aproximadamente 39.000 profissionais, mensurou o impacto na entrega: um aumento de 25% na adoção de IA correlacionou-se com uma redução de 1,5% na taxa de transferência e uma redução de 7,2% na estabilidade. No mesmo estudo, 39,2% dos desenvolvedores relataram pouca ou nenhuma confiança no código gerado.
O padrão que ambos descrevem é consistente: produz-se mais, revisa-se a mesma quantidade e reorganiza-se menos. A consequência não aparece na primeira semana; ela surge quando algo precisa ser mudado.
Seria insensato abrir mão de uma ferramenta que aumenta significativamente a velocidade de exploração. Estas são as aplicações em que a codificação intuitiva é claramente a escolha certa:
Nos quatro casos, existe uma característica comum: O resultado não precisa sobreviver.. No momento em que alguém diz "isto está quase a funcionar, vamos pôr em produção", a utilização muda de categoria e os critérios devem mudar em conformidade.
Antes de colocar em produção algo gerado dessa forma, é aconselhável responder a esta pergunta:
Um protótipo que responde a cinco perguntas deixa de ser um protótipo: torna-se um sistema construído rapidamente, que é exatamente o que pretendemos. O problema nunca foi a velocidade.
O padrão que observamos nas auditorias é sempre o mesmo. Uma pequena equipe constrói em três semanas o que levaria três meses. A gerência conclui, com razão, que o desenvolvimento ficou mais barato. Mais iniciativas são aprovadas usando os mesmos critérios.
Seis meses depois, cada alteração demora mais que a anterior, ninguém quer mexer em dois módulos específicos e as estimativas já não são confiáveis. Este é o quadro clínico da dívida técnica, e já o discutimos em detalhes em O gargalo é, mais uma vez, a arquitetura.
O que chama a atenção é que o diagnóstico raramente aponta para a origem, porque a velocidade inicial era real e todos se lembram dela como um sucesso.
O padrão que observamos nas auditorias é sempre o mesmo. Uma pequena equipe constrói em três semanas o que levaria três meses. A gerência conclui, com razão, que o desenvolvimento ficou mais barato. Mais iniciativas são aprovadas usando os mesmos critérios.
Seis meses depois, cada alteração demora mais que a anterior, ninguém quer mexer em dois módulos específicos e as estimativas já não são confiáveis. Este é o quadro clínico da dívida técnica, e já o discutimos em detalhes em O gargalo é, mais uma vez, a arquitetura.
O que chama a atenção é que o diagnóstico raramente aponta para a origem, porque a velocidade inicial era real e todos se lembram dela como um sucesso.
Não é preciso escolher entre gerar rapidamente e construir bem. As duas fases devem ser separadas, e você precisa ser explícito sobre em qual delas você está no momento.
Fase de exploração. Gere o que quiser, sem revisão minuciosa, com dados falsos e sem se preocupar com a manutenção. O objetivo é aprender.
Ponto de decisão. Alguém declara que a ideia é válida. É aqui que se toma a decisão que quase ninguém toma: O que foi explorado é descartado.. O que se preserva é o conhecimento, não o código.
Fase de construção. A arquitetura é definida, o modelo de dados é decidido, os contratos são estabelecidos e, em seguida, utiliza-se a geração assistida, agora dentro de uma estrutura definida por uma pessoa.
Descartar o protótipo parece um desperdício, mas não é: o protótipo já cumpriu seu propósito, que era responder a uma pergunta. Preservá-lo é o que transforma uma ferramenta de exploração na base de um edifício.
Essa separação é a razão pela qual, na arquitetura TCG-SAF™, a construção é precededa. Não por razões cerimoniais: porque é a única maneira de aproveitar a velocidade de geração sem herdar a desordem.
É a prática de gerar software descrevendo o que se deseja e aceitando o código produzido por um modelo sem revisá-lo minuciosamente. É muito eficaz para explorar ideias e construir protótipos, mas problemático quando o resultado é implantado em produção sem reformulação.
Somente se responder a cinco perguntas: alguém consegue explicar por que está estruturado dessa forma? Existem testes que detectam regressões? Está definido quais dados são acessados e quem pode vê-los? Existe um registro e um mecanismo para reverter às operações normais? E existe alguém que possa mantê-lo em funcionamento dentro de um ano?.
Os dados apontam para uma mudança nos padrões, em vez de uma piora direta. O GitClear documentou que a refatoração caiu de aproximadamente 25% de alterações totais em 2021 para menos de 10% em 2024, e que a duplicação aumentou oito vezes. A DORA mediu declínios na taxa de transferência e na estabilidade em 2024, à medida que a adoção de IA aumentou.
Para validar uma ideia antes de investir, explore alternativas de interface, crie ferramentas internas descartáveis ou aprenda um novo domínio. O ponto em comum é que o resultado não precisa ser permanente.
Separe as fases: preserve o conhecimento e descarte o código. Em seguida, defina a arquitetura, o modelo de dados e os contratos, e reutilize a geração assistida dentro dessa estrutura definida por uma pessoa.
Porque a velocidade inicial é real e fica na memória como um sucesso, enquanto o custo se torna aparente quando algo precisa ser alterado: as mudanças demoram cada vez mais, há módulos que ninguém quer mexer e as estimativas deixam de ser confiáveis.
Você tem algum produto em produção que começou como um protótipo? Nossa auditoria técnica informa, em 10 dias úteis e por um preço fixo, o que pode ser mantido, o que precisa ser reestruturado e o que está gerando custos mensais. Solicitar auditoria →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
