Os riscos da programação caixa preta com IA

Em QA e testes, é comum falar sobre testes de caixa preta ou testes de caixa branca. Os testes de caixa preta são realizados quando você não conhece o funcionamento interno do sistema e testa a sua funcionalidade. Os testes de caixa branca são realizados quando você conhece o funcionamento ou a estrutura interna do sistema, e os testes são configurados para verificar os diferentes casos possíveis cobertos pelo código.

Com as ferramentas de inteligência artificial, está surgindo o que poderíamos chamar de programação de caixa preta. O usuário especifica à IA o que deseja funcionalmente de um aplicativo, e a IA o gera.
O usuário não sabe como o seu aplicativo funciona internamente, não se importa ou não é capaz de compreender as implicações de como essa solução foi implementada.
Este seria um caso de uso típico de ferramentas como Lovable e algumas outras que estão começando a surgir, mas aceitar código gerado por IA sem qualquer revisão e compreensão também poderia ser considerado caixa preta.

Em oposição à programação caixa preta, existe também a programação caixa branca com IA. Neste caso, há um responsável técnico que decide a arquitetura, como implementar a solução e se apoia na IA para codificá-la mais rapidamente. Dependendo do contexto e da capacidade de compreensão, os fragmentos delegados à IA são maiores ou menores.
O papel do desenvolvedor de produto muda: em vez de escrever linhas de código, ele projeta/dirige, orquestra e revisa, sendo totalmente responsável pelo "como". Por isso, minha recomendação é que os fragmentos solicitados à IA sejam pequenos e concisos para que possam ser revisados, compreendidos e mantidos no futuro (minha recomendação: nada maior do que um pull request que sejamos capazes de revisar e entender). Embora o conhecimento completo seja inalcançável e existam vários tons de branco, a programação caixa branca consiste em compreender a solução o mais completamente possível; não se trata de dividir uma grande caixa preta em uma multidão de caixas pretas menores.

Embora eu obviamente tenha a minha preferência, não é que uma modalidade seja boa ou ruim por si só, simplesmente é necessário compreendê-las, ver os seus prós e contras e, acima de tudo, entender os seus riscos.

No caso da programação caixa preta, os riscos que a meu ver deveriam ser avaliados são:

Risco 1: A falta de responsabilidade. Como mencionei em um artigo anterior, a IA não pode resultar em uma diluição da responsabilidade. Se o software gerado não funcionar corretamente, apresentar problemas de desempenho, segurança, estabilidade ou efeitos colaterais imprevistos, o responsável deve estar claro. Não compreender o como nem o porquê desses problemas torna a assunção de responsabilidade mais complicada.
Risco 2: A perda de controle da qualidade. Não saber como o software foi gerado nos impede de saber se foi gerado um produto de qualidade ou não. Isso não é novidade, a maioria dos stakeholders quer apenas que o software funcione, independentemente de ter sido gerado com critérios de qualidade. Mas quem trabalha com arquitetura de software e entende do assunto sabe que, se faltar qualidade e houver dívida técnica, no final isso se paga: dificuldades de manutenção, erros, lentidão, complicação e, em última análise, a necessidade de refazer todo o software do zero.
Risco 3: Desconhecimento da arquitetura de software: Desconhecer a arquitetura do software implica desconhecer os seus pontos fortes e fracos, ignorar qual parte precisará ser reforçada ou até mesmo para onde ela pode ou deve evoluir. Também significa ignorar quais são as suas dependências e potenciais vulnerabilidades.
Risco 4: Desempenho: O desempenho de um aplicativo está intimamente ligado à sua arquitetura. Podemos falar de problemas de escalabilidade ou "simplesmente" de um uso ineficiente de recursos, mas sem entender como um aplicativo é construído, é impossível não apenas agir, mas até mesmo propor otimizações.
Risco 5: Conhecimento implícito: Quando definimos e implementamos, existe um contexto e um conhecimento implícito de cada um dos atores que agrega valor. Por exemplo, um arquiteto ou desenvolvedor de software trará conhecimentos sobre arquitetura, padrões de projeto, segurança de dados e também aspectos funcionais baseados em experiências e implementações anteriores. Como grande parte desse conhecimento é implícito, ele não é transferido nem exigido da IA, resultando em uma solução de menor qualidade do que se vários atores com conhecimentos diversos tivessem intervindo na sua geração.
Risco 6: Evolução vs revolução (refactor vs replatform): Devemos ter em mente que o desenvolvimento de software é um processo iterativo. Não se faz um aplicativo e pronto. Ele precisa evoluir, ser corrigido, melhorado, etc. Não conhecendo o "como" foi feito, não é possível especificar a evolução de determinados aspectos, mas sim adicionam-se novas especificações de alto nível, com um risco muito grande de que a IA refaça o existente para cumprir as novas especificações, deixando de cumprir as anteriores, voltando a cometer erros e, em geral, trazendo à tona todos os problemas decorrentes de refazer o software em vez de refatorá-lo.
Risco 7: Perda de oportunidades por falta de conhecimento: Existem casos em que o conhecimento de como algo é feito e o domínio das capacidades tecnológicas geram oportunidades de negócio, novas opções funcionais, etc. É o chamado desenvolvimento de produto "bottom-up". Ao ocultar esse conhecimento e esses atores que sabem como o software é feito, perde-se essa capacidade criativa.

Conhecendo esses riscos, é preciso ter cuidado com as implicações da programação caixa preta. No entanto, como dissemos antes, não é que seja uma modalidade ruim por si só; existem casos em que esse tipo de programação pode ser interessante, pois implica um menor consumo de recursos humanos (não entrarei no mérito do consumo de tokens aqui).

Por exemplo, para provas de conceito, pilotos ou protótipos, pode ser interessante, já que são casos em que o desempenho e a estabilidade em produção não são tão necessários quanto a velocidade e a capacidade de testar conceitos, além de não haver a intenção de gerar um software que permaneça ao longo do tempo, melhore e evolua.

Em resumo, quando programamos com IA, assim como quando encomendamos software a uma consultoria, devemos nos questionar sobre as implicações de ignorar esse código, quais riscos isso acarreta e como pretendemos mantê-lo. Devemos nos perguntar se estamos encomendando o software para resolver um problema ou se queremos implementá-lo nós mesmos.