Agile morreu. E a culpa não é da IA

ENGENHARIA DE SOFTWARE: ENTRE FUNDAMENTOS E PRESSA

Enquanto uma geração de programadores aprende a copiar e colar sem questionar, muitas empresas celebram velocidade como sinônimo de êxito. Mas velocidade sem qualidade tem limite.

A história é clara: passamos por décadas de evolução técnica. Clean Code, SOLID, Domain-Driven Design, Object Calisthenics. Juval Löwy, em “Righting Software”, sintetiza bem: design de software é sobre decisões deliberadas, não acasos. Esses princípios separavam amadores de engenheiros, mas em algum lugar do caminho decidimos que pensar era luxo.

Agora, a indústria optou pela velocidade acima de tudo.

O Agile nasceu como resposta a metodologias rígidas e engessadas. Era para ser flexível, colaborativo, humano. Mas sofreu uma deturpação brutal dentro de muitas empresas. A daily virou interrogatório de progresso. A Sprint virou corrida maluca contra relógios e deadlines. O desenvolvedor virou executor de tickets. Kanban virou ferramenta de microgerenciamento. O que era para libertar virou prisão.

E o pior? Muitos líderes acreditam que estão fazendo Agile certo. Estão apenas sendo rápidos. Agile sem qualidade, sem reflexão técnica, sem propriedade real, não é Agile. É caos. Entrega, só entrega. Se quebrar, consertamos depois. Só que a corrente sempre quebra no elo mais fraco, e no fim do dia essa falta de qualidade costuma recair sobre o engenheiro, não sobre o gerente ou o diretor. Quem paga essa conta primeiro quase sempre é o elo mais fraco. Engenheiros não deveriam cavar a própria cova.

E aí chegou a IA generativa. Ela não é o problema; faz exatamente o que foi desenhada para fazer. O problema é como a usamos. A IA aprende com o que alimentamos nela. Se alimentamos código sem padrão, sem teste, sem arquitetura, ela vai regurgitar exatamente isso. Quem coloca lixo dentro e espera ouro sair é responsável pela mediocridade que colhe.

O resultado é uma geração inteira de programadores que não sabe lógica básica, não entende arquitetura, nunca refatorou nada na vida. Descrevem o problema e esperam a máquina resolver. Terceirizar o raciocínio virou normal.

Virou moda: “Vibe Coding”. Nome bonito para um atalho perigoso. Pensar demais “atrapalha”. Boas práticas viram perda de tempo. Arquitetura vira frescura.

Mas aqui está a realidade: não é possível ter software bom sem pessoas qualificadas de todas as áreas envolvidas. Qualidade não é cara. Qualidade ECONOMIZA. Um código bem feito custa menos do que um código que quebra toda semana e transforma a manutenção em um inferno.Economia de hoje, custo escondido de amanhã. É assim que a velocidade sem qualidade trata engenharia.Economia de hoje, custo escondido de amanhã. É assim que a velocidade sem qualidade trata engenharia.

As empresas estão sacrificando talentos no altar da velocidade. Os melhores saem. Por quê? Porque trabalham em sistemas que ninguém entende, em empresas que pagam bem, mas não valorizam excelência técnica.

O problema não é falta de ferramenta. É falta de responsabilidade. Desde o diretor até o desenvolvedor júnior, há uma relutância em assumir o peso de construir algo duradouro.

O diretor culpa o desenvolvedor pela entrega lenta. O desenvolvedor culpa a metodologia. Mas a verdade é que ninguém está alinhado com real propriedade.

Os times recebem OKRs como top down e são cobrados por “senso de dono”. Não funciona assim. Você não pode pedir senso de dono quando as decisões vêm prontas do topo. Você não pode exigir responsabilidade sobre algo em que ninguém teve voz para opinar. Essa é a receita perfeita para desengajamento.

Os 3 Horizontes de McKinsey não existem por acaso. Horizonte 1 é apagar incêndio e manter o que já existe funcionando. Horizonte 2 é evoluir produto, pagar dívida técnica, preparar a próxima versão. Horizonte 3 é apostar em algo que ainda nem gera resultado hoje, mas pode sustentar a empresa amanhã. Empresas maduras cuidam dos três. As que querem tudo no curto prazo drenam toda a energia para o Horizonte 1, vivem em modo crise permanente e depois culpam o time por não inovar. Quando todo o foco está só no agora, arquitetura, qualidade e experimentação viram luxo. E é justamente aí que a engenharia começa a morrer.

Quando um desenvolvedor copia código sem entender, a responsabilidade vai além. Pessoas e empresas estão confiando seus dinheiros em plataformas financeiras, em sistemas de pagamento, em infraestruturas críticas: hospitais, carros autônomos, aviões, equipamentos que mantêm pessoas vivas. Um bug que ninguém entendeu pode resultar em transações perdidas, fraudes e prejuízos irreversíveis. Clientes inteiros podem ser impactados por uma falha que poderia ter sido prevenida. Isso não é teórico. Acontece.

A profissão de programador não vai ser destruída pela IA. Mas pode ser profundamente prejudicada pelo uso irresponsável dela e pela falta de rigor de quem a utiliza.

Se você chegou até aqui, é porque reconhece que algo precisa mudar.

Você é dos poucos que ainda se importa com qualidade, clareza e responsabilidade. Com engenharia de verdade.

Então, aqui vai a reflexão em forma de ação:

• Como desenvolvedor: estude os fundamentos. Não precisa saber tudo, mas precisa aprender, questionar e ter critério.
• Exija das empresas ferramentas certas, suporte real e reconhecimento da excelência técnica.
• Como líder: dê voz real aos times. Defina OKRs com eles, não para eles.
• Proteja tempo para arquitetura, qualidade e melhoria contínua, mesmo quando a pressão por velocidade aumentar.

Porque a realidade é essa: é possível criar software excelente sem gastar muito mais tempo, desde que você tenha pessoas qualificadas e uma empresa que as valorize de verdade.

A engenharia de software não precisa ser salva por ferramentas ou tecnologias mágicas. Precisa ser salva por rigor, responsabilidade e respeito pelo trabalho bem feito.

E você? Como enxerga o uso de IA e a pressão por velocidade no seu time hoje: potencializador de qualidade ou atalho perigoso?