A versão 2.10 marcou uma mudança importante no RadIA. Foi nela que o projeto ganhou uma camada semântica estrutural própria para Object Pascal, aproximando o agente do código real, dos símbolos, dos tipos, da herança e das interfaces presentes em um projeto Delphi.

Depois dessa fundação, surgiu uma pergunta inevitável: como entregar toda essa capacidade sem exigir que o usuário compreenda a arquitetura interna do produto antes de conseguir utilizá-lo?

O desafio não era remover recursos. Também não era transformar o RadIA em um assistente limitado, capaz apenas de gerar pequenos trechos de código. A proposta sempre foi mais ampla: integrar chat, agente, editor, compilação, testes, debugger, Form Designer, terminal, conhecimento local, MCP, extensões e automações dentro do Delphi.

O verdadeiro desafio era reduzir a carga cognitiva sem reduzir o produto.

Esse foi o eixo principal do trabalho realizado entre as versões 2.10 e 2.12.3. Nesse período, o RadIA ganhou uma jornada inicial mais direta, passou a explicar melhor o que está fazendo, deixou escolhas importantes visíveis, organizou sua presença dentro da IDE e recebeu novos testes de integração para situações que só aparecem quando o software encontra a vida real: uma IDE sem projeto aberto, uma janela acoplada, uma troca rápida entre projetos ou um módulo recriado internamente pela Open Tools API.

Simplificar não significa esconder o que o produto sabe fazer

Ao analisar a experiência do RadIA depois da versão 2.10, ficou evidente que a principal ameaça já não era falta de funcionalidade. O produto era completo, mas essa completude podia aparecer cedo demais e de forma dispersa.

Há uma diferença importante entre capacidade e complexidade percebida.

Um usuário pode querer apenas criar uma aplicação, corrigir um erro ou entender um projeto existente. Para começar, ele não precisa tomar decisões sobre cada recurso disponível. Ao mesmo tempo, essas possibilidades não podem desaparecer, porque usuários avançados precisam de controle, personalização e acesso aos detalhes técnicos.

A solução adotada foi trabalhar com divulgação progressiva: começar pelo objetivo do usuário, manter as capacidades visíveis e apresentar os detalhes no momento em que eles se tornam relevantes.

Em vez de reduzir o RadIA, passamos a organizar melhor a forma como ele se apresenta.

RadIA 2.11: uma jornada de criação mais simples

A versão 2.11 foi o primeiro grande passo dessa nova fase.

Uma conversa vazia passou a começar por intenções reconhecíveis, como entender o projeto atual, corrigir um problema, criar algo novo ou depurar uma aplicação. Essas opções não executam ações irreversíveis nem escondem o restante da plataforma. Elas ajudam o usuário a formular o objetivo inicial e a entrar no fluxo certo com menos esforço.

A mesma tela continua mostrando que o RadIA pode trabalhar com código, build, testes, debugger, Form Designer, terminal, MCP e skills. Assim, a entrada ficou mais simples sem transmitir a sensação de que o produto perdeu profundidade.

O projeto primeiro, os adicionais depois

Um dos pontos mais importantes dessa versão foi a revisão da criação de projetos.

Antes, ao receber um pedido para criar uma aplicação, o RadIA podia entregar não apenas o projeto solicitado, mas também uma estrutura DUnitX e outros elementos complementares. Tecnicamente, isso não estava errado. Na verdade, demonstrava uma preocupação positiva com qualidade e manutenção.

O problema estava na expectativa.

Na maioria das vezes, quando alguém pede “crie este projeto”, o resultado esperado é um projeto criado, aberto e compilando. Testes unitários, estruturas adicionais e outras melhorias são desejáveis, mas devem entrar como escolhas conscientes, não como decisões automáticas tomadas em nome do usuário.

Por isso, a criação passou a trabalhar com três perfis:

• essential: cria somente o necessário para que a aplicação exista, seja aberta e compile;
• complete: inclui também a estrutura adicional, como o projeto DUnitX;
• custom: permite escolher explicitamente quais recursos opcionais serão adicionados.

Quando o pedido não menciona adicionais, o RadIA usa o perfil essencial. Depois que o projeto está pronto e compilado, ele pode oferecer ações como adicionar testes DUnitX ou revisar outras extensões possíveis.

O ponto central é que a decisão continua com o usuário.

Essa mudança preserva tudo que já existia. O RadIA não perdeu a capacidade de criar testes ou estruturas completas. Apenas deixou de antecipar uma decisão que pertence ao desenvolvedor.

A janela permanece aberta durante o trabalho

Outro comportamento que prejudicava a percepção de estabilidade era o painel abrir e fechar durante a criação de um projeto. Em alguns casos, ele desaparecia e não retornava automaticamente.

Mesmo quando o processamento estava correto, a experiência transmitia insegurança. O usuário via a interface sumir justamente enquanto a ferramenta modificava o estado da IDE.

A jornada foi ajustada para manter o painel do RadIA aberto durante a preparação, a criação, a abertura e a compilação do projeto. O chat deixa de parecer uma janela descartável e passa a funcionar como a central estável da operação.

Effort visível no compositor

O nível de esforço de raciocínio também passou a ficar visível na linha principal do chat.

Antes, essa configuração estava escondida entre opções adicionais. Isso reduzia a chance de o usuário perceber que podia equilibrar velocidade e profundidade de análise para cada tarefa.

Agora, as opções Low, Medium, High e Extra high aparecem diretamente no compositor, com um controle visual integrado ao tema do chat. Medium permanece como escolha equilibrada, enquanto os demais níveis permitem priorizar rapidez ou análise mais profunda.

É uma pequena mudança de interface, mas representa um princípio maior: opções que alteram materialmente o comportamento da próxima interação devem estar onde a decisão acontece.

Um único menu RadIA dentro do Delphi

À medida que o produto cresceu, suas ações começaram a ocupar várias posições no menu Ferramentas do Delphi. Chat, terminal, onboarding, correção de erros, criação de projetos e extensões apareciam misturados com comandos nativos e itens de outros plugins.

Na versão 2.11, essas entradas foram agrupadas em Ferramentas > RadIA.

O resultado é uma separação visual clara. O usuário identifica rapidamente o que pertence ao RadIA, enquanto o menu principal do Delphi permanece mais organizado. Todos os comandos continuam disponíveis; apenas ganharam uma casa comum.

RadIA 2.12: o usuário passa a acompanhar a operação

Simplificar o início resolveu apenas parte do problema. Durante uma operação longa, especialmente a criação de um projeto, o usuário ainda podia ficar sem saber o que estava acontecendo.

Uma lista técnica de ferramentas executadas é útil para diagnóstico, mas não é a melhor linguagem para comunicar progresso. Saber que PreviewProjectTemplate, CreateProjectFromTemplate ou ValidateCreatedProject foi chamado interessa a quem está investigando os detalhes. Quem pediu a aplicação quer respostas mais diretas:

• o RadIA entendeu meu pedido?
• os arquivos já foram criados?
• o projeto foi aberto?
• está compilando?
• terminou corretamente?

A versão 2.12 introduziu uma visão operacional estável para responder a essas perguntas.

Uma linha do tempo compreensível

Durante a criação de projetos, o RadIA agora apresenta etapas como:

1. preparação da solicitação;
2. revisão da estrutura do projeto;
3. criação dos arquivos;
4. abertura do projeto no Delphi;
5. compilação;
6. projeto pronto.

A etapa atual fica destacada e as etapas concluídas permanecem visíveis. Em vez de interpretar uma sequência de chamadas internas, o usuário acompanha o trabalho na linguagem da tarefa que solicitou.

O cartão também informa explicitamente que DUnitX e outros recursos opcionais não serão adicionados automaticamente. Ao final, ele mostra o resultado esperado e oferece próximos passos sem executá-los por conta própria.

Detalhes técnicos continuam disponíveis

Previsibilidade não significa esconder evidências.

Métricas, riscos, argumentos, ferramentas executadas e resultados detalhados continuam acessíveis em Technical details. A diferença é que esse conteúdo não domina mais a leitura principal.

O usuário que quer apenas acompanhar a operação encontra uma explicação limpa. Quem precisa auditar, diagnosticar ou entender cada passo ainda tem acesso às informações completas.

Essa separação é importante porque atende dois perfis sem criar duas interfaces diferentes: simplicidade para começar e profundidade quando necessário.

Polimento visual e documentação integrada

Essa fase também incluiu uma revisão de detalhes que, isoladamente, parecem pequenos, mas juntos definem a qualidade percebida do produto.

O seletor de esforço foi ajustado para respeitar espaçamento, bordas e tema do chat. Textos das configurações foram revisados para evitar cortes e sobreposições. Labels maiores passaram a usar áreas adequadas e quebra de linha. Links da ajuda integrada foram verificados e corrigidos para que jornadas, comandos, configurações e demais páginas abram corretamente.

A documentação também passou a explicar a diferença entre autenticação do provider, modo de orquestração, CLI externo e bridge MCP sem depender da leitura do código-fonte.

Esse tipo de trabalho não cria uma nova ferramenta agentiva, mas reduz atrito em todas as ferramentas existentes.

RadIA 2.12.1: a janela passa a respeitar o usuário

Depois da reorganização visual, foi identificado um problema clássico de integração com IDE: o estado do painel não era restaurado como o usuário esperava.

Ao abrir o Delphi, o RadIA podia aparecer mesmo que tivesse sido fechado na sessão anterior. Uma janela deixada acoplada podia retornar flutuante. Altura e largura também não eram preservadas de forma consistente.

A versão 2.12.1 corrigiu esse comportamento.

O painel passou a persistir visibilidade, posição, dimensões e estado de docking usando o mecanismo de desktop da própria IDE. Isso evita que o RadIA imponha sua presença a cada inicialização e faz com que o ambiente retorne à configuração escolhida pelo desenvolvedor.

Também foram criados testes específicos para confirmar a restauração do estado no Delphi 12, no Delphi 13 Win32 e no Delphi 13 IDE64.

É uma mudança que comunica respeito. Uma ferramenta integrada à IDE deve se adaptar ao espaço de trabalho do usuário, não reorganizá-lo silenciosamente.

RadIA 2.12.2: criar do zero precisa funcionar de verdade

Uma regressão revelou outra diferença entre testar uma função isolada e testar a jornada real.

O RadIA sempre teve como proposta permitir a criação de uma aplicação quando nenhum projeto está aberto. Entretanto, uma sincronização introduzida no fluxo podia impedir a continuação ou tentar navegar para arquivos antes de a Open Tools API reconhecer o novo projeto como ativo.

Os sintomas apareciam de formas diferentes: mensagens informando que não havia projeto ativo, navegação bloqueada porque o arquivo ainda não pertencia a um projeto aberto ou execução consumindo etapas até atingir o limite configurado.

A versão 2.12.2 corrigiu a corrida de inicialização. Depois de criar e abrir o projeto, o RadIA passou a aguardar a confirmação de que a IDE realmente o reconheceu antes de navegar ou iniciar a validação seguinte.

Mais importante: o cenário ganhou um teste de integração permanente.

O teste cria uma calculadora a partir de uma IDE sem projeto aberto, abre o projeto, navega para seus arquivos e compila a aplicação. Ele é executado no Delphi 12 e no Delphi 13 sempre que essa área é modificada e antes de uma release.

A calculadora se tornou um excelente teste sentinela porque atravessa várias camadas ao mesmo tempo: interpretação do pedido, geração de arquivos Pascal e DFM, criação do .dproj, abertura via OTA, reconhecimento do projeto ativo, navegação e compilação real.

RadIA 2.12.3: estabilidade ao trocar de projeto

O último ajuste desse ciclo surgiu em uma situação comum no uso diário: fechar um projeto e abrir outro.

Durante essa transição, a Open Tools API pode recriar internamente um módulo para o mesmo nome de arquivo, mas com uma nova identidade. O notificador de conhecimento do RadIA mantinha anexos associados aos módulos abertos e podia tentar adicionar novamente uma entrada já existente na coleção.

O resultado era uma Access Violation disparada pelo timer dentro do processo do Delphi.

A versão 2.12.3 estabilizou essa transição em três pontos:

• a atualização dos anexos passou a substituir com segurança o valor associado ao arquivo, em vez de presumir que a chave nunca reapareceria;
• o ciclo de atualização recebeu proteção contra reentrada;
• exceções transitórias passaram a ser contidas e registradas, impedindo que escapem pelo loop de mensagens da IDE.

Além da correção, foi criado um novo gate de integração. Ele abre um projeto, fecha esse projeto, cria e abre outro e navega para uma unit com o notificador de conhecimento ativo. O cenário precisa passar tanto no Delphi 12 quanto no Delphi 13 antes da publicação de uma versão.

Esse teste complementa o teste da calculadora. Um protege o início a partir do zero; o outro protege a transição entre contextos reais de trabalho.

A validação passou a acompanhar a experiência, não apenas o código

Entre a 2.10 e a 2.12.3, 80 arquivos foram alterados, com mais de duas mil linhas adicionadas e quase quinhentas removidas. Entretanto, a mudança mais relevante não está no volume de código. Está na forma como os critérios de qualidade passaram a representar a experiência completa.

Além dos testes unitários e dos testes do frontend, o processo de release agora inclui jornadas executadas dentro das versões suportadas da IDE:

• criação de projeto com a IDE inicialmente vazia;
• geração e compilação da calculadora;
• compilação dos diferentes tipos de projeto suportados;
• abertura e navegação imediata após a geração;
• fechamento de um projeto e abertura de outro;
• persistência de visibilidade, tamanho e docking;
• encerramento da IDE sem processos órfãos;
• validação no Delphi 12 e no Delphi 13, incluindo a IDE64 onde aplicável.

Na release 2.12.3, a suíte DUnitX executou 1.158 testes instrumentados e 8 testes externos em cada versão do Delphi, sem falhas e sem vazamentos detectados. O frontend passou por 131 testes e pelo ESLint. O Quality Gate do SonarQube foi aprovado com 84,5% de cobertura global, 84,6% de cobertura no código novo, zero issues, zero bugs, zero vulnerabilidades, zero hotspots e zero code smells.

Os artefatos também são vinculados ao commit exato que foi validado. O instalador publicado é baixado novamente e seu hash SHA-256 é comparado ao arquivo local. Isso garante que o binário disponibilizado seja o mesmo que passou pelos testes.

O que mudou, afinal?

Se a versão 2.10 deu ao RadIA uma compreensão estrutural mais profunda do código Delphi, as versões seguintes trabalharam para tornar essa inteligência mais fácil de usar e mais segura de acompanhar.

O RadIA continua completo. Ele ainda oferece controle de provider e executor, diferentes níveis de esforço, chat, agente, build, testes, debugger, designer, terminal, MCP, conhecimento, extensões e detalhes técnicos de cada execução.

O que mudou foi a ordem em que essa complexidade aparece.

O usuário começa pelo objetivo. Durante a execução, acompanha etapas compreensíveis. Recursos adicionais entram como escolhas explícitas. Informações avançadas permanecem disponíveis sem poluir a leitura principal. A janela respeita o estado definido na sessão anterior. E os cenários reais que sustentam essa experiência passaram a fazer parte dos gates de release.

Essa é a direção que queremos para o RadIA: não simplificar removendo possibilidades, mas simplificar organizando decisões.

Disponibilidade

O RadIA 2.12.3 está disponível para:

• Delphi 12 Win32;
• Delphi 13 Win32;
• Delphi 13 IDE64.

O código-fonte, a documentação e o instalador podem ser encontrados no GitHub:

github.com/regyssilveira/RadIA-Plugin

A versão mais recente está disponível na página de releases:

RadIA 2.12.3

Se você utiliza Delphi 12 ou 13, experimente criar uma aplicação do zero, acompanhar o fluxo de geração e escolher depois quais recursos adicionais deseja incluir. Esse caminho resume bem a evolução recente do projeto: o RadIA faz o trabalho pesado, mostra o que está acontecendo e mantém o desenvolvedor no controle.