A discussão sobre tecnologias low-code precisa começar reconhecendo a realidade de que elas reduzem de forma muito significativa a curva de desenvolvimento e de entrega de software. Ferramentas desse tipo permitem que aplicações sejam construídas em tempo reduzido, com menor esforço de implementação direta e com um nível de automação que, em muitos contextos, representa um ganho real de produtividade. Esse benefício não deve ser minimizado. O problema não está no fato de essas tecnologias facilitarem o desenvolvimento, mas no que pode ser perdido quando a facilidade de construção vem acompanhada de uma redução do domínio efetivo sobre aquilo que está sendo construído.
A questão central, portanto, não é simplesmente saber se uma determinada plataforma produz aplicações funcionais. É saber em que medida a organização, o analista de sistemas ou o engenheiro de software mantém conhecimento real sobre a solução gerada, sobre sua arquitetura, suas dependências, suas regras de negócio, seus mecanismos de autenticação, suas integrações, sua persistência de dados, seus componentes externos e, principalmente, sobre o comportamento concreto do código que materializa o sistema.
Low-code e o domínio da solução
Esse ponto exige uma distinção importante. Possuir o código-fonte não significa necessariamente dominar o código-fonte. Uma plataforma pode permitir exportação integral do projeto, integração com repositórios externos e continuidade do desenvolvimento fora do ambiente original. Ainda assim, pode existir uma distância significativa entre ter fisicamente o código e possuir conhecimento técnico suficiente para compreender sua estrutura, explicar suas decisões de implementação, manter sua evolução e assumir responsabilidade efetiva por ele.
Esse problema pode ser entendido como uma forma de dependência que vai além do tradicional vendor lock-in, ou seja, a dependência excessiva de um fornecedor específico. Mesmo que não exista aprisionamento formal à plataforma, pode existir um knowledge lock-in, isto é, uma dependência do conhecimento que não foi plenamente internalizado pela equipe responsável. Uma organização pode ter em mãos dezenas de milhares de linhas de código e, ainda assim, não possuir autonomia técnica para evoluí-las, porque o processo de geração da solução ocorreu em um nível de abstração que afastou os responsáveis de sua implementação concreta.
Essa é uma diferença fundamental entre dominar uma ferramenta low-code que produz software e dominar o software produzido por ela. Um profissional pode tornar-se extremamente competente no uso de uma plataforma low-code, conhecer seus componentes, seus prompts, seus fluxos e seus mecanismos de integração. Isso não significa necessariamente que possua o mesmo nível de conhecimento sobre a aplicação resultante que teria alguém capaz de percorrer a arquitetura, identificar a origem de cada regra, compreender as dependências envolvidas e explicar por que o sistema se comporta daquela forma.
Nesse sentido, a crítica ao low-code não é uma crítica à automação em si. Tampouco é uma crítica à inteligência artificial. Ao contrário, a inteligência artificial pode representar uma ampliação extraordinária da capacidade do profissional de software. Pode acelerar análise, geração de código, testes, documentação, revisão, refatoração, diagnóstico e inúmeras outras atividades técnicas. O ponto não é preservar o desenvolvimento manual como valor em si mesmo. O ponto é preservar a compreensão da solução.
A IA pode escrever parte significativa do código sem que isso represente necessariamente uma perda de domínio, desde que exista um profissional tecnicamente responsável capaz de compreender, revisar, validar, explicar e responder por aquilo que foi produzido. A pergunta relevante, portanto, não é quem escreveu o código, se um programador ou uma inteligência artificial. A pergunta é se existe alguém que efetivamente domina o sistema.
Esse domínio é particularmente importante porque o código não é apenas um meio técnico para obtenção de um executável. Em sistemas corporativos, ele materializa conhecimento do negócio. Uma regra como “se o cliente estiver inadimplente há mais de 30 dias, bloquear determinada operação, exceto em uma condição específica” não é simplesmente uma instrução de programação. É uma regra empresarial formalizada.
Quando essa regra está expressa de maneira clara e determinística no código, o profissional consegue responder onde ela está, por que foi implementada daquela maneira, em quais condições é executada, que exceções existem e que efeitos uma alteração produzirá. Isso é parte do conhecimento do sistema e, por extensão, do próprio negócio.
IA probabilística e regras determinísticas
Esse exemplo conduz a um segundo eixo importante da discussão, que extrapola o low-code e alcança diretamente o uso de agentes de inteligência artificial em processos empresariais. Modelos generativos são essencialmente probabilísticos. Eles são extraordinariamente eficientes para interpretar linguagem natural, classificar informações, identificar padrões, resumir documentos, sugerir respostas, extrair significado de dados não estruturados e lidar com situações em que existe ambiguidade.
Entretanto, um processo de negócio determinístico possui outra natureza. Se uma regra estabelece que um cliente com mais de 30 dias de inadimplência deve ser bloqueado, dadas as mesmas entradas, o resultado precisa ser sempre o mesmo. Não existe espaço para interpretação probabilística quando a própria regra do negócio é objetiva.
A diferença, nesse caso, é fundamental. Uma coisa é utilizar inteligência artificial para escrever o código da regra. Outra coisa completamente diferente é utilizar um modelo probabilístico para decidir, em tempo de execução, se a regra deve ou não ser aplicada.
No primeiro caso, a IA atua como ferramenta de produtividade. Pode gerar uma implementação como uma condição lógica tradicional, que depois será compilada, testada, revisada e executada de maneira determinística. No segundo caso, a decisão passa a depender de inferência. O sistema deixa de simplesmente executar uma regra formal e passa a interpretar um contexto para decidir o resultado.
Isso introduz um problema sério quando aplicado a situações que exigem reprodutibilidade. Com as mesmas informações de entrada, um processo empresarial crítico deve produzir a mesma decisão. Crédito, cobrança, bloqueio, cancelamento, concessão de acesso, aplicação de penalidades ou cumprimento de regras contratuais não deveriam depender de uma variação probabilística quando os critérios são formalmente conhecidos.
A inteligência artificial é particularmente adequada para lidar com incerteza. O problema aparece quando ela introduz incerteza em um processo que originalmente não a possuía.
Essa distinção permite estabelecer uma fronteira importante entre IA como camada de interpretação e IA como camada de decisão. Um modelo pode interpretar o e-mail de um cliente, identificar sua intenção, extrair informações relevantes, classificar a solicitação e sugerir o próximo passo. Mas, uma vez que os dados necessários tenham sido identificados e exista uma regra objetiva para decidir o que deve acontecer, a decisão pode e frequentemente deve retornar a uma lógica determinística.
Esse desenho preserva o melhor dos dois mundos. A IA atua onde sua natureza probabilística oferece vantagem: compreensão, classificação, interpretação e geração. O software determinístico atua onde previsibilidade, auditabilidade, invariância e responsabilidade são indispensáveis.
Os agentes de IA tornam essa questão ainda mais relevante porque possuem um grau maior de autonomia. Um agente pode interpretar uma solicitação, escolher ferramentas, consultar sistemas externos, executar operações e decidir o próximo passo. Quanto maior essa autonomia, maior a necessidade de definir fronteiras técnicas claras entre aquilo que pode ser interpretado probabilisticamente e aquilo que deve obedecer a regras formais e invariáveis.
Nesse contexto, o uso responsável da inteligência artificial em software não consiste em transformar todo o sistema em IA. Consiste em saber exatamente onde a probabilística é útil e onde o determinismo precisa prevalecer.
Essa preocupação com responsabilidade, transparência, governança e avaliação de riscos também aparece em referências amplamente utilizadas na área, como o Artificial Intelligence Risk Management Framework (AI RMF), do NIST, que trata da gestão de riscos associados ao desenvolvimento, à implantação e ao uso de sistemas de inteligência artificial.
Quando a abstração esconde a decisão
Essa discussão se conecta diretamente com a crítica ao low-code porque plataformas altamente abstratas podem esconder essa separação. Para o usuário, uma instrução como “automatize o processo de cobrança” pode parecer uma única funcionalidade. Internamente, porém, ela pode envolver regras codificadas, chamadas a modelos generativos, agentes autônomos, heurísticas, serviços de terceiros ou uma combinação de todos esses mecanismos.
Se quem construiu o sistema não domina a implementação, pode inclusive desconhecer qual desses componentes está tomando determinada decisão. Nesse ponto, o problema deixa de ser apenas de manutenção e passa a envolver governança, auditoria e responsabilidade.
Há, portanto, uma distinção essencial entre software funcional e software compreendido. Uma aplicação pode funcionar corretamente durante meses e ainda assim não ser verdadeiramente dominada pela organização que a utiliza. Pode existir uma grande diferença entre “o sistema funciona” e “sabemos exatamente como o sistema funciona”.
Esse problema não é exclusivo do low-code. Sistemas desenvolvidos de forma tradicional também podem ser mal arquitetados, mal documentados, inseguros, excessivamente dependentes de bibliotecas externas ou incompreensíveis para a própria equipe. Não existe qualquer garantia de qualidade simplesmente porque um sistema foi escrito manualmente.
A diferença é que as novas plataformas de automação tornam possível produzir software em uma escala e velocidade muito superiores à capacidade humana de compreendê-lo, revisá-lo e auditá-lo na mesma proporção.
O novo gargalo da engenharia de software
Esse talvez seja um dos principais efeitos da transformação atual do desenvolvimento de software. O custo de produzir código está diminuindo drasticamente. Mas o custo de compreender, validar, testar, proteger, documentar, manter e assumir responsabilidade pelo código não diminui necessariamente na mesma velocidade.
A escassez pode, portanto, estar se deslocando. Durante décadas, grande parte do esforço de engenharia esteve concentrada na capacidade de produzir implementação. Com o avanço da inteligência artificial e da automação, o gargalo tende a migrar cada vez mais para a capacidade de avaliar implementação.
Nesse novo cenário, escrever código deixa progressivamente de ser a única habilidade central. Torna-se igualmente ou ainda mais importante saber julgar se o código produzido está correto, se representa adequadamente o negócio, se é seguro, se é sustentável, se respeita fronteiras arquiteturais, se utiliza dependências adequadas e se poderá ser mantido no futuro.
Por isso, a crítica ao low-code pode ser formulada sem qualquer oposição à inovação tecnológica. Ao contrário, ela nasce justamente da preocupação com a engenharia em um ambiente onde a produção de software se tornou extremamente fácil.
O risco não está em tornar o desenvolvimento fácil demais. O risco está em tornar fácil demais colocar em produção software cuja complexidade deixou de ser percebida por quem o produz e por quem o contrata.
A automação pode e deve ampliar a capacidade do engenheiro de software. O que não deve ser perdido é o domínio técnico. A ferramenta pode gerar, acelerar e sugerir. A inteligência artificial pode participar intensamente de todo o processo. Mas a responsabilidade sobre a solução, suas regras e seu comportamento precisa continuar pertencendo a alguém capaz de compreendê-la integralmente.
Em última análise, talvez a questão central não seja escolher entre desenvolvimento tradicional, low-code ou inteligência artificial. A questão é decidir qual nível de abstração ainda permite preservar conhecimento, auditabilidade e controle.
Software não é apenas aquilo que executa. Software é também conhecimento formalizado sobre processos, regras e decisões de uma organização. Quando esse conhecimento deixa de ser compreendido por quem é responsável pelo sistema, perde-se algo mais importante do que simplesmente o controle sobre o código: perde-se parte do domínio sobre a própria solução.
Ao final deste artigo, fica o convite para que você se inscreva na nossa newsletter, acompanhe-nos no Facebook, Instagram e YouTube e volte sempre para ler outros artigos publicados aqui no nosso Blog. Deixamos também o convite para que você visite o site do Arcádia Host, o nosso provedor de hospedagem de sites, e descubra um leque de possibilidades em serviços de hospedagem e desenvolvimento de sites sob medida para o seu negócio.
Até o próximo post!
