Nos últimos meses, a inteligência artificial passou a fazer parte do meu dia a dia no desenvolvimento em OutSystems. A adaptação não foi imediata e, no início, nem sempre soube como tirar o melhor partido da ferramenta. No entanto, a evolução foi evidente: hoje desenvolvo com maior rapidez, esclareço dúvidas em tempo real e entrego funcionalidades com menos erros, o que se traduz numa maior eficiência e redução de custos finais para os clientes.
Esta já não é uma realidade isolada. Segundo o relatório “State of Application Development 2025“, da OutSystems, 81% dos programadores já integraram IA generativa na sua rotina. A Gartner vai ainda mais longe e prevê que, até 2028, 75% dos engenheiros de software utilizem assistentes de IA no trabalho, uma evolução muito significativa face aos 10% registados em 2023.
Existe, no entanto, uma diferença relevante entre utilizar IA e saber realmente tirar partido da mesma. Em OutSystems, onde existem regras, limitações e boas práticas muito específicas, essa diferença torna-se ainda mais evidente.
Antes de avançar, deixo uma nota essencial: tudo o que faço é executado num ambiente corporativo de IA, totalmente isolado. Não são introduzidos dados pessoais de clientes nem propriedades intelectuais de projetos. A segurança e o sigilo estão sempre salvaguardados.
Onde a IA falha e onde nós ganhamos
Ao contrário da narrativa que muitos têm vindo a defender, a IA não está a reduzir a relevância do low-code. Na minha experiência, está precisamente a reforçá-la: quanto mais específica é a plataforma, mais importante se torna o conhecimento do programador para transformar sugestões genéricas em soluções que realmente funcionam.
A IA conhece muito melhor linguagens como C# ou Java do que OutSystems. E isso representa uma vantagem competitiva para quem domina a plataforma.
Já perdi conta às sugestões para utilizar funções como ListSlice() ou Math.Clamp(), ou padrões de loop desastrosos para a performance. São funções e abordagens que simplesmente não se aplicam à plataforma.
Um estudo do GitHub revelou que os programadores completam tarefas simples 55% mais rapidamente com IA. No entanto, o conhecido estudo da “METR” identificou um importante gap de perceção: os programadores estimaram que a IA reduzia o tempo de trabalho em 20%, quando, na prática, acabaram por perder tempo a interpretar e corrigir sugestões erradas. Mesmo com as atualizações metodológicas mais recentes, em 2026, o alerta mantém-se: somos maus juízes da nossa própria produtividade quando confiamos cegamente na ferramenta.
A própria documentação oficial da OutSystems alerta para um dos erros mais comuns: executar queries dentro de ciclos, o clássico problema N+1. Como a IA tende a raciocinar de forma genérica, muitas vezes propõe este padrão por ser intuitivo em linguagens tradicionais. Um programador experiente sabe que, nesse contexto, a solução passa normalmente por uma query única, com os joins necessários.
Quando o modelo me propõe algo inviável, a minha resposta é direta: “Atenção, em OutSystems isso não existe. Como faríamos de outra forma?” Com o contexto bem estabelecido, as sugestões tornam-se progressivamente mais adequadas.
O OutSystems Mentor, lançado em 2024, procura precisamente orientar o programador dentro destas boas práticas. Ainda assim, continua a ser indispensável ter alguém experiente ao volante para filtrar o que realmente se aplica.
- Separar por conversas e usar o pin
O meu maior erro, no início, foi misturar tudo no mesmo chat: modelo de dados, integrações, lógica de negócio e decisões técnicas. As respostas começavam bem, mas, a meio do projeto, a IA começava a perder contexto e a qualidade degradava-se.
Hoje utilizo sobretudo o Gemini, pela estabilidade em janelas de contexto longas, mas mudei a estratégia. Quando arranca uma nova fase de desenvolvimento, crio conversas independentes e fixo-as com pin.
Numa conversa sobre modelo de dados, discuto o esquema de tabelas, índices e relacionamentos. Noutra, sobre integrações, concentro-me exclusivamente no mapeamento de REST APIs e no parsing de estruturas JSON. Já numa terceira conversa sobre lógica de negócio, isolo a lógica de negócio, os fluxos e as regras das Server Actions.
Ao alimentar o modelo com contexto específico, a memória operacional torna-se mais focada. Se preciso de voltar a um tema, retomo a conversa certa.
Recentemente vi um developer partilhar no Medium um componente interessante no Forge, o DataModel2Markdown, que exporta o modelo de dados em Markdown para fornecer ao assistente. É uma forma simples e eficaz de acelerar este processo e dar ao modelo um contexto mais estruturado.
- Usar a IA como ferramenta de crítica, não como fonte de respostas prontas
Esta foi, provavelmente, a mudança com maior impacto no meu dia a dia: passei a utilizar a IA para validar a minha solução, e não apenas para me dar uma resposta pronta. É uma espécie de Rubber Duck Debugging avançado.
O processo que melhor funciona comigo é simples: analiso o problema, defino a minha abordagem e explico ao modelo o que pretendo desenvolver. Em vez de lhe pedir diretamente o código, pergunto: “Quais são os inconvenientes ou riscos desta solução?”
Quando o modelo aponta riscos, contextualizo com as condições reais do projeto. Dou um exemplo prático: num erro de produção relacionado com concorrência de acessos, a IA sugeriu uma solução mais sofisticada. No entanto, eu sabia que aquele registo específico estava desenhado para ser utilizado por uma única pessoa de cada vez.
Ao explicar este contexto humano e de negócio, a IA reformulou a abordagem e chegámos a uma solução muito mais simples: bloquear o ecrã enquanto o registo estivesse em edição. Foi uma solução mais rápida, mais adequada à realidade do projeto e perfeitamente alinhada com a plataforma.
- Casos práticos onde isto me deu vantagem real
Conflito de IDs numa entidade estática
Após um deploy, fiquei com um conflito persistente de IDs numa entidade estática. A IA sugeriu uma abordagem que eu nunca tinha testado: remover o item, publicar a aplicação sem esse elemento e só depois reintroduzi-lo. O ID anterior foi limpo e o novo entrou sem conflito. O problema ficou resolvido em minutos.
Documentos EDOC sem dependência da equipa de negócio
Alguns documentos via links EDOC apresentavam erros de visualização. A IA sugeriu extrair o conteúdo em Base64 e convertê-lo localmente para PDF com um pequeno script. Esta abordagem poupou-me horas de dependência da equipa de negócio, a quem antes tinha de pedir apoio sempre que precisava de visualizar os documentos para compreender os erros.
Query em Advanced SQL com timeouts em produção
Uma query em Advanced SQL estava a provocar timeouts recorrentes em produção. Partilhei com a IA o volume de dados e a estrutura envolvida, e o modelo ajudou-me a reestruturar os índices para evitar table scans agressivos. O problema foi resolvido sem necessidade de escalar para DBA.
Decifrar uma Server Action com 40 nós
Deparei-me com uma Server Action com cerca de 40 nós e vários comentários soltos. Em vez de perder tempo a analisar o fluxo passo a passo, tirei três capturas de ecrã, garantindo que não havia dados visíveis, colei-as no chat e pedi um resumo lógico dos pontos de decisão. Em 15 segundos, sabia exatamente por onde começar a refatoração.
Prever regressões antes de acontecerem
Depois de corrigir um formulário, perguntei ao modelo que novos problemas aquela alteração poderia criar. A IA identificou três cenários, incluindo a possibilidade de o utilizador clicar no botão “voltar” do browser após submeter o formulário, algo que me tinha escapado.
Adicionei a validação necessária e, uma semana depois, o cliente reportou exatamente esse comportamento, que já estava mitigado.
Plano técnico aprovado no momento
Precisei de preparar um plano técnico detalhado para alterar o log detail de um serviço exposto em produção para “Full”. Expliquei a situação e os riscos à IA, e o modelo devolveu uma estrutura com passos, responsabilidades e plano de reversão. Ajustei dois pontos ao ambiente real, enviei o plano e o cliente aprovou-o na hora.
O valor não residiu no facto da IA escrever por mim, mas sim em não ter de partir do zero.
Requisitos ambíguos transformados em perguntas concretas
Quando o negócio pediu simplesmente que “o sistema valide se o documento está correto antes de submeter”, coloquei essa frase no modelo e pedi perguntas concretas para fazer ao cliente.
A IA devolveu questões fundamentais: Que tipo de validação deve ser feita? O erro bloqueia ou apenas avisa? Em que estado fica o processo se a validação falhar?
Estas perguntas evitaram que eu começasse a desenvolver com requisitos mal definidos.
- Ter um segundo ponto de vista sempre disponível
Talvez a mudança mais invisível, mas também uma das mais relevantes no meu dia a dia, esteja no fluxo de trabalho. Deixei de ficar bloqueado à espera de que um colega de equipa esteja disponível para discutir uma simples dúvida de lógica.
Expor o raciocínio ao modelo funciona quase como um diário de bordo técnico, onde vou testando caminhos e validando hipóteses. Recebo feedback imediato e avanço com mais confiança.
Isto não substitui, de forma alguma, as discussões de arquitetura com a equipa, que continuam a ser insubstituíveis para decisões complexas. Elimina, no entanto, uma quantidade significativa de bloqueios desnecessários no trabalho individual.
Conclusão
Utilizar IA no desenvolvimento em OutSystems não implica confiar cegamente no que o ecrã devolve, mas sim saber guiar a ferramenta: com o contexto bem delimitado, sentido crítico para filtrar o que não é aplicável e domínio sólido da plataforma para detetar possíveis desvios do modelo.
Para os mais experientes, a IA é um amplificador de velocidade e autonomia. Para quem está a começar, sem a devida supervisão, pode facilmente transformar-se numa muleta perigosa.
No fim, o conhecimento de quem usa a ferramenta marca a diferença.
Nélio D.
Low-Code Software Engineer na Babel
