A ilusão da engenharia por prompt

O software ficou mais fácil de escrever. Continuou tão difícil quanto sempre foi entregar.

Há pouco mais de dois anos, desenvolver software deixou de ser uma atividade restrita a profissionais da área. Hoje, qualquer pessoa pode abrir uma ferramenta de Inteligência Artificial, descrever uma ideia em linguagem natural e receber, em poucos segundos, um sistema aparentemente completo. Interfaces modernas, autenticação, banco de dados, painéis administrativos, gráficos, integrações e centenas de arquivos organizados em uma estrutura que transmite uma perigosa sensação de maturidade.

O impacto dessa transformação é inegavelmente positivo. Nunca produzimos tanto em tão pouco tempo. Nunca automatizamos tarefas com tanta eficiência. Nunca foi tão fácil transformar uma ideia em um protótipo funcional.

Mas existe uma diferença que tem sido ignorada por uma parcela crescente do mercado: um protótipo funcional não é um produto pronto para produção.

Essa distinção, que durante décadas foi compreendida por qualquer engenheiro de software, parece ter desaparecido sob o entusiasmo provocado pela Inteligência Artificial. O resultado é um fenômeno preocupante: pessoas sem qualquer formação em desenvolvimento passaram a comercializar sistemas corporativos, acreditando que dominar um prompt equivale a dominar Engenharia de Software.

É uma confusão compreensível.

E extremamente perigosa.

A Inteligência Artificial reduziu drasticamente a barreira para escrever código. Em nenhum momento ela eliminou a necessidade de compreender o que esse código faz, quais riscos introduz, como se comportará sob carga, como responderá a ataques automatizados ou como protegerá os dados confiados por seus usuários.

Escrever código sempre foi apenas uma pequena parte do desenvolvimento de software.

A engenharia começa exatamente onde o código termina.

O cliente enxerga a interface. O profissional enxerga o restante.

Quando uma empresa contrata o desenvolvimento de um sistema, normalmente avalia aquilo que consegue visualizar. O layout é agradável, os menus funcionam, os relatórios são rápidos e o processo de cadastro parece intuitivo. Aos olhos do contratante, o projeto transmite profissionalismo.

O problema é que praticamente nada disso permite avaliar sua qualidade técnica.

O software que realmente importa é invisível.

Está na forma como as permissões são controladas. Na maneira como as senhas são protegidas. Na política de backup. Na segregação entre ambientes de desenvolvimento e produção. Na gestão de sessões autenticadas. No tratamento de erros. No registro de eventos. Na proteção contra ataques conhecidos. Na criptografia das informações armazenadas. Na atualização contínua de dependências. Na revisão de código. Nos testes automatizados. Na observabilidade da aplicação. Nos mecanismos de recuperação após incidentes.

Nenhum desses elementos impressiona durante uma apresentação comercial.

Todos eles passam a ser indispensáveis no primeiro incidente de segurança.

A falsa sensação de competência

Toda tecnologia disruptiva produz um efeito colateral previsível: reduz a percepção da complexidade.

A calculadora nunca transformou alguém em matemático.

Um editor de imagens nunca formou um designer.

Da mesma forma, uma IA capaz de gerar milhares de linhas de código não transforma automaticamente seu operador em engenheiro de software.

Ainda assim, esse é exatamente o cenário que o mercado começou a testemunhar.

Profissionais de marketing passaram a oferecer desenvolvimento de sistemas.

Designers passaram a vender ERPs.

Consultores passaram a construir plataformas financeiras.

Empreendedores descobriram que bastava pedir "Crie um sistema para uma escola" para obter algo suficientemente convincente para fechar contratos.

O cliente, naturalmente, não possui obrigação de distinguir um código seguro de um código apenas funcional.

Quem possui essa obrigação é quem decidiu vendê-lo.

A internet não testa aparência. Testa vulnerabilidades.

Existe uma diferença fundamental entre um software apresentado em uma reunião comercial e um software conectado permanentemente à internet.

Enquanto clientes observam telas, robôs observam portas abertas.

Enquanto usuários navegam pelos menus, ferramentas automatizadas procuram vulnerabilidades conhecidas.

Todos os dias milhões de tentativas de exploração percorrem a internet procurando aplicações desatualizadas, APIs mal protegidas, autenticações frágeis, configurações inseguras e erros que poderiam ter sido identificados durante uma revisão técnica minimamente criteriosa.

Nenhum atacante precisa conhecer sua empresa.

Basta descobrir que seu sistema existe.

Esse é o ambiente para o qual um software precisa ser preparado.

Não para uma demonstração.

Para sobreviver.

O custo da inexperiência

Imagine uma pequena instituição de ensino.

Ela armazena dados de alunos, responsáveis, professores, funcionários, informações financeiras, históricos acadêmicos e documentos pessoais.

Agora imagine que todo esse ambiente foi desenvolvido por alguém cuja experiência consiste, essencialmente, em conversar com uma Inteligência Artificial.

Não houve modelagem de ameaças.

Não houve auditoria de segurança.

Não houve revisão por outro desenvolvedor.

Não houve testes de invasão.

Não houve validação de conformidade com a LGPD.

O sistema entra em produção.

Durante meses tudo parece funcionar perfeitamente.

Até o dia em que um usuário comum descobre que consegue visualizar dados de outra turma.

Ou um backup é publicado inadvertidamente.

Ou uma API expõe registros sem autenticação adequada.

Ou uma biblioteca vulnerável permanece meses sem atualização.

Esses problemas dificilmente aparecem na primeira semana.

É justamente por isso que são tão caros.

Quando a responsabilidade deixa de ser técnica

Existe uma ideia equivocada de que falhas de segurança são apenas problemas tecnológicos.

Não são.

São problemas jurídicos.

São problemas financeiros.

São problemas reputacionais.

Desde a entrada em vigor da Lei Geral de Proteção de Dados, organizações brasileiras passaram a responder com muito mais rigor pela forma como coletam, armazenam e protegem informações pessoais. A Autoridade Nacional de Proteção de Dados vem ampliando sua atuação, instaurando processos administrativos e aplicando medidas relacionadas a incidentes de segurança e ao tratamento inadequado de dados pessoais. Paralelamente, ações judiciais decorrentes de vazamentos tornaram-se significativamente mais frequentes, acompanhando uma tendência observada em diversos países.

Nesse cenário, pouco importa se a vulnerabilidade surgiu porque alguém escreveu o código manualmente ou porque simplesmente aceitou a primeira resposta produzida por uma IA.

A responsabilidade permanece integralmente humana.

A Inteligência Artificial não assina contratos.

Não responde perante clientes.

Não comparece a audiências.

Não indeniza prejuízos.

Ferramentas extraordinárias. Responsabilidades inalteradas.

Seria um erro concluir que a Inteligência Artificial representa uma ameaça ao desenvolvimento de software.

O oposto é verdadeiro.

Ela é provavelmente a ferramenta mais transformadora já incorporada à Engenharia de Software.

Profissionais experientes conseguem reduzir semanas de trabalho para dias, automatizar tarefas repetitivas, produzir documentação com mais qualidade, acelerar revisões, identificar inconsistências e explorar soluções com velocidade inédita.

Mas exatamente por isso continua sendo uma ferramenta.

Nenhum engenheiro civil deixa de calcular uma estrutura porque possui um software de modelagem.

Nenhum piloto deixa de compreender aerodinâmica porque o avião possui piloto automático.

Nenhum cirurgião entrega uma operação a um robô sem compreender cada etapa do procedimento.

Por que deveria ser diferente quando o assunto é software responsável por armazenar milhões de dados pessoais?

A diferença entre utilizar IA e depender dela

Na Tronux, utilizamos Inteligência Artificial todos os dias.

Ela faz parte do nosso processo de desenvolvimento, automação, documentação, testes e análise técnica. Aumenta nossa produtividade, reduz tempo de execução e amplia nossa capacidade de entregar soluções cada vez mais sofisticadas.

Mas existe um princípio que permanece inalterado desde a fundação da empresa, em 2002.

Nenhuma linha de código entra em produção porque uma IA afirmou que ela estava correta.

Ela entra em produção porque profissionais assumiram a responsabilidade de validá-la.

Esse talvez seja o maior equívoco da atual corrida pela Inteligência Artificial.

Muitos acreditam que aprenderam a desenvolver software.

Na realidade, aprenderam apenas a solicitar que outra ferramenta escrevesse código.

Entre essas duas competências existe uma distância enorme.

É justamente nela que surgem os incidentes de segurança, os prejuízos financeiros, os processos judiciais e as crises de reputação que poderiam ter sido evitados.

O futuro do desenvolvimento certamente será construído com Inteligência Artificial.

Mas continuará pertencendo àqueles que compreendem engenharia.