Engenharia de software na era do piloto automático com Zarathon Viana

O que a Engenharia de Software pode aprender com os pilotos de avião

A comparação com a aviação ajuda a entender um ponto importante: automação não elimina a necessidade de conhecimento profundo. Ela muda o tipo de habilidade exigida.

Pilotos modernos utilizam piloto automático durante boa parte do voo. Ainda assim, eles continuam precisando entender profundamente os fundamentos da aviação para tomar decisões em situações críticas.

O mesmo começa a acontecer com software.

A IA acelera drasticamente a implementação, mas isso não significa que o engenheiro pode abrir mão da compreensão do sistema. Pelo contrário: quanto mais automação existe, mais importante se torna a capacidade de julgamento.

Existe um risco real de os profissionais entrarem em um modo de confiança excessiva na ferramenta. Quando isso acontece, o cérebro reduz o nível de atenção. E isso pode gerar problemas sérios, especialmente em sistemas complexos.

Por isso, a grande habilidade do futuro talvez não seja mais escrever código rapidamente, mas entender profundamente o problema que precisa ser resolvido.

O fim do “mero programador”

Durante muitos anos, boa parte da engenharia de software foi baseada em velocidade de entrega. O foco estava em “fazer subir produção”.

Nesse cenário, muitas decisões arquiteturais eram sacrificadas em troca de rapidez. Dívida técnica era aceita como consequência inevitável.

Com IA, essa justificativa começa a perder força.

Se a implementação ficou barata, o diferencial deixa de ser digitar código e passa a ser:

• entender domínio de negócio
• desenhar sistemas
• tomar boas decisões arquiteturais
• mapear o mundo real para software
• criar soluções que envelhecem bem

Isso eleva drasticamente a importância de disciplinas como:

• Domain-Driven Design (DDD);
• Software Design;
• observabilidade;
• modelagem de domínio;
• comunicação com negócio.

O engenheiro do futuro tende a operar em um nível mais alto de abstração.

O código continua existindo, mas deixa de ser o centro da profissão.

Greenfield vs Brownfield: a IA funciona melhor em código saudável

Existe uma diferença enorme entre criar sistemas novos e trabalhar em sistemas legados.

Em projetos novos (greenfield), a IA já consegue acelerar absurdamente o desenvolvimento.

Mas o mercado real é dominado por brownfield: sistemas antigos, complexos e cheios de acoplamento.

E aí surge um ponto importante: a maioria dos codebases atuais não está pronta para IA.

Sistemas com:

• baixa testabilidade
• pouca documentação
• arquitetura confusa
• domínio mal separado
• ausência de observabilidade

acabam dificultando muito o uso eficiente das ferramentas.

Antes de extrair produtividade massiva de IA, muitas empresas provavelmente precisarão passar por uma fase de “AI readiness”, preparando seus sistemas para serem compreendidos pelas ferramentas.

O futuro provavelmente será multimodelo

Hoje existe uma concentração muito grande nos grandes modelos proprietários. Mas isso talvez não dure da forma atual. A tendência é um cenário híbrido:

• modelos grandes para raciocínio complexo
• modelos menores para tarefas específicas
• modelos especializados treinados internamente
• soluções open source rodando localmente

Em vez de um único modelo universal, empresas podem operar múltiplos modelos especializados.

Isso reduz custo e aumenta eficiência.

Na prática, o fluxo de trabalho tende a ficar mais ou menos assim:

• modelos avançados para design e raciocínio
• modelos baratos para implementação
• agentes especializados para observabilidade, QA e documentação

O próprio conceito de LLM talvez evolua para algo mais próximo de SLMs (Small/Specific Language Models), altamente especializados em domínios específicos.

A nova importância da documentação e ADRs

Quando o código deixa de ser escrito manualmente em cada detalhe, o contexto passa a valer muito mais.

Nesse cenário, ADRs (Architecture Decision Records) ganham um papel central.

Registrar:

• decisões
• trade-offs
• motivos arquiteturais
• restrições de negócio
• escolhas técnicas

passa a ser fundamental para que tanto humanos quanto IAs consigam navegar no sistema.

E existe um detalhe importante: documentação ficou barata. Hoje já é possível automatizar:

• geração de documentação
• atualização de guidelines
• extração de decisões
• sincronização entre código e documentação

O desafio começa a mudar de “documentar mais” para “evitar documentar demais”.

Observabilidade vira ainda mais importante

Se antes debugging já era difícil, agora o problema muda de forma.

Com sistemas gerados parcialmente ou talvez até integralmente por IA, observabilidade deixa de ser um luxo e vira requisito básico.

Logs, traces e métricas passam a funcionar como sensores do sistema.

A tendência é que ferramentas de IA se conectem diretamente a:

• Grafana
• Datadog
• tracing
• logs
• sistemas de monitoramento

e consigam identificar causas de incidentes quase automaticamente.

Isso muda até o perfil do trabalho operacional:

• menos busca manual
• mais interpretação
• mais capacidade de investigação
• mais análise sistêmica

TDD e testes automatizados ganham um novo papel

Uma das mudanças mais interessantes é o novo significado dos testes. Antes, testes eram vistos principalmente como validação. Agora eles passam a funcionar também como “cercado” para IA.

O teste define:

• os limites
• os critérios de aceitação
• o comportamento esperado

Ou seja: ele ajuda a controlar a geração automática de código.

Quanto mais claro o sistema de testes, mais previsível fica a geração feita pela IA.

Isso torna:

• TDD
• testes de contrato
• testes de mutação
• fitness functions
• sanity checks arquiteturais

muito mais relevantes.

O novo desafio: formar engenheiros juniores

Talvez um dos maiores problemas da próxima década seja formação.

Se a IA acelera output, quem não possui repertório técnico sólido corre o risco de acelerar erros.

A comparação com a aviação aparece novamente: pilotos aprendem primeiro em ambientes menos automatizados.

O mesmo talvez precise acontecer com engenharia.

Profissionais iniciantes ainda precisam:

• escrever código manualmente
• entender fundamentos
• debugar
• operar sistemas
• criar repertório técnico

A IA pode acelerar aprendizado, mas não substitui a construção da base.

Uma possível direção para educação técnica é:

1. resolver problemas “na munheca”
2. entender fundamentos
3. depois usar IA para acelerar

A habilidade mais importante talvez passe a ser aprender rápido sem perder profundidade.

Soft skills ficam ainda mais importantes

Se implementação ficou mais barata, diferenciação passa a vir de outros lugares.

O mercado tende a valorizar ainda mais:

• comunicação
• colaboração
• curiosidade
• capacidade de julgamento
• clareza
• pensamento sistêmico

Além disso, engenharia de prompt deixa de ser apenas “prompt bonito” e passa a ser comunicação eficiente.

Quem não consegue explicar claramente uma intenção:

• gera contexto ruim
• desperdiça tokens
• aumenta retrabalho
• polui conversas
• perde produtividade

O profissional mais valioso talvez seja aquele que consegue:

• pensar claramente
• estruturar problemas
• comunicar restrições
• avaliar trade-offs

Processos seletivos devem mudar radicalmente

Os formatos tradicionais começam a perder eficácia.

Desafios para casa já podem ser resolvidos quase integralmente por IA.

Perguntas puramente algorítmicas talvez também percam relevância.

A tendência parece caminhar para entrevistas mais próximas da realidade:

• investigação de sistemas quebrados
• debugging
• análise arquitetural
• avaliação de trade-offs
• resolução criativa de problemas
• comunicação técnica

O diferencial deixa de ser decorar algoritmos e passa a ser:

• tomar boas decisões
• entender contexto
• justificar escolhas
• navegar complexidade

O maior risco atual: extremos

Talvez o maior desafio para líderes hoje seja equilibrar extremos.

De um lado:

• pessoas resistentes à IA
• medo de substituição
• rejeição das ferramentas

Do outro:

• hiperempolgação
• excesso de carga cognitiva
• burnout
• obsessão por acompanhar tudo

O problema é que a velocidade das mudanças está extremamente alta.

E isso exige um novo tipo de liderança:

• mais técnica
• mais próxima do trabalho
• mais capaz de orientar adoção saudável
• mais preparada para ajudar times a navegar a transformação

O líder do futuro talvez precise voltar a ser profundamente técnico, não necessariamente escrevendo código diariamente, mas entendendo sistemas, limitações e capacidades das ferramentas.

O futuro da engenharia parece menos sobre código e mais sobre entendimento

Talvez a principal conclusão seja essa: Escrever código está deixando de ser o principal diferencial.

O que ganha importância agora é:

• entender problemas
• modelar domínio
• desenhar sistemas
• comunicar intenções
• avaliar trade-offs
• tomar decisões

Software continua precisando de código.

Mas engenharia de software cada vez mais parece caminhar para algo maior do que apenas programação.