Proud Tech Summit 2026 揭示原型與正式投產的落差：製作變便宜，理解更費時

Acompanhei a transmissão online do Proud Tech Summit 2026, evento organizado pela Starian e pela Softplan. Foram cerca de oito horas de apresentações focadas em engenharia de software, sistemas legados, uso de agentes em produção e arquitetura de dados.

O evento fugiu do papo genérico de inteligência artificial que domina a internet. Em vez de demonstrações prontas de chat, as palestras mostraram problemas reais: bancos relacionais legados, integrações que quebram, regras fiscais e o trabalho de colocar modelos para rodar com clientes de verdade.

As palestras que acompanhei ao longo do dia:

Carla Souza, Guilherme Brasil e Luis Fausto (Starian e Softplan): abertura e maturidade de IA em empresas.
Lucas Leung (Oracle Brasil): simulações na Fórmula 1 com a Oracle RedBull Racing.
Jean Roloff (Checklist Fácil / Starian): construção do Orbit com Working Backwards e SDD.
Pedro Escobar (Softplan): governança de agentes e o framework Softflow.
Rafael Gomides e Amanda Aragão (1Doc / Softplan): atendimento público via WhatsApp nos municípios.
Diogo Noschang (Starian): governança e segurança de dados corporativos com servidores MCP.
Alexandre Messina (Lovable / VibeLabs): prototipagem rápida e Vibe Coding.

O teste dos três prompts e os 77% empacados

Na abertura, Carla Souza apontou um descompasso claro: a velocidade de construção das ferramentas acelerou drasticamente, mas o tempo necessário para entender regras de negócio e validar sistemas continua sendo humano.

Guilherme Brasil demonstrou isso com um teste no mesmo modelo de LLM. Ele pediu um texto de 32 palavras para a abertura do evento contendo os números 5, 10, 15, 25 e 50. Com o pedido seco, o modelo gerou um chavão corporativo vazio sobre conquistas e futuro. Quando ele forneceu o contexto real - 5ª edição do evento, 10 anos de empresa, 15 anos da filha, 25 de casado e 50 de idade -, a saída virou um texto direto e bem-humorado. O modelo era exatamente o mesmo. A diferença estava apenas no contexto fornecido na entrada.

Luis Fausto trouxe dados do Gartner e da McKinsey sobre o estágio atual do mercado: cerca de 77% das empresas continuam presas a testes iniciais e provas de conceito, enquanto apenas 23% conseguiram colocar sistemas agênticos em produção.

O motivo apontado para esse gargalo é puramente operacional. Para um agente rodar em produção de verdade, ele precisa de um responsável definido, regras claras de nível de serviço (SLA) e mecanismo de rollback para reverter erros em caso de falha.

Orbit: três semanas, PR/FAQ e SDD

Jean Roloff contou como foi o desenvolvimento do Orbit, a plataforma de agentes da Starian, feita em um ciclo de três semanas.

Antes de escrever código, o time usou a abordagem Working Backwards da Amazon: redigiram o comunicado de lançamento (Press Release) e as perguntas frequentes (PR/FAQ) simulando o produto pronto. A ideia era alinhar a dor do cliente e o retorno esperado antes de abrir o editor.

Jean Muller Roloff (Starian) detalhando a metodologia Working Backwards e PR/FAQ no Orbit.

Para a construção com agentes, a equipe adotou Desenvolvimento Orientado por Especificação (SDD). Em vez de prompts abertos, definiram contratos de dados, interfaces e testes unitários antes de acionar a IA para gerar os arquivos. O projeto somou mais de duzentas mil linhas de código com cobertura de testes acima de 90%.

O time também evitou subir de uma vez os quinze microsserviços planejados na arquitetura completa. Eles isolaram uma fatia específica no produto Contato Seguro, voltada à triagem de relatos, colocaram essa parte em produção para colher dados reais e só depois expandiram para outros módulos.

Softflow: 220 desenvolvedores e quatro travas manuais

Na Softplan, o problema não era falta de uso de IA, mas o surgimento de scripts e prompts isolados espalhados entre mais de 220 engenheiros, o que complicava a manutenção compartilhada da base de código.

Pedro Escobar apresentou o Softflow, um framework baseado no padrão Orchestrator-Workers com onze etapas. O ponto central do fluxo são os pontos de parada obrigatórios (gates), onde o processo é travado até que um desenvolvedor valide o que foi gerado.

Pedro Escobar (Softplan) apresentando a divisão de subagentes por contexto a partir da revisão de código.

Etapa / Gate	Automação do Agente / Ação do Worker	Validação Humana (Ponto de Parada)	Status / Papel
Gate 1	Lê o item de trabalho e escreve a especificação técnica formal (SDD)	Aprovação manual da especificação antes de qualquer código	`Especificação`
├── Worker	Gera a implementação e executa a suíte de testes inicial	—	`Execução`
Gate 2	Subagentes analisam o diff atrás de problemas de segurança, desempenho e arquitetura	Desenvolvedor avalia achados e decide o que corrigir ou descartar	`Achados de Revisão`
Gate 3	Cria a branch e executa os testes automatizados de integração	Aprovação manual necessária para merge na main	`Merge Request`
Gate 4	Prepara o fechamento e valida os critérios de negócio	Humano confirma se a demanda de negócio foi atendida	`Fechamento`

Pipeline de desenvolvimento e pontos de parada humanos no Softflow

O fluxo organiza a validação em quatro etapas principais:

Gate 1 (Especificação): O agente lê o item de trabalho e escreve a especificação técnica formal (SDD). Nenhum código é gerado antes da aprovação dessa spec.
Gate 2 (Achados de Revisão): Subagentes dedicados analisam o diff atrás de problemas de segurança, desempenho e arquitetura. O desenvolvedor decide pontualmente o que mandar corrigir ou descartar.
Gate 3 (Merge Request): O agente monta a branch e roda a suíte de testes, mas a aprovação do merge no repositório continua manual.
Gate 4 (Fechamento): Uma pessoa confirma se a demanda de negócio foi atendida antes de encerrar o item.

Na demonstração ao vivo, Escobar mostrou a resolução de um bug em uma integração legada com o IBM Jazz RTC, em que a API retornava campos de responsável vazios. O agente usou chamadas via MCP para inspecionar os work items e aplicou a correção. Antes de abrir o MR, um subagente de revisão apontou que uma linha de log não tinha teste unitário associado. O ajuste foi feito na hora e o merge seguiu com a suíte verde.

1Doc: atendimento público via WhatsApp e controles operacionais

A apresentação de Rafael Gomides e Amanda Aragão tratou do canal de atendimento municipal da 1Doc via WhatsApp (casos da LIA em Limeira e da TIA em Florianópolis).

Colocar serviços públicos no WhatsApp aproveita o alcance do aplicativo, mas impõe desafios práticos de arquitetura:

Rafael Gomides (1Doc) explicando a arquitetura de contratos de leitura sobre sistemas legados.

Em conversas cotidianas, as pessoas mandam mensagens truncadas, áudios e mudam de assunto, o que não encaixa direto na abertura de um processo administrativo. A solução envolveu criar formulários dentro da conversa e programar o agente para encaminhar casos complexos diretamente para os canais presenciais.

Outro ponto é a segurança: número de telefone não identifica cidadão de forma jurídica. Para emissão de certidões ou consulta de débitos, a 1Doc desacoplou o acesso: o cidadão clica em um link temporário para autenticar na plataforma web oficial, sem trafegar senhas ou armazenar dados pessoais na conversa do WhatsApp.

Além disso, a abertura do processo municipal não depende da estabilidade de um aplicativo de mensagens. O registro é salvo de forma transacional no banco antes de enviar qualquer notificação ao usuário.

Para controle de custos e risco, a gestão municipal possui botões para desativar serviços específicos sob demanda e travas com alertas automáticos em 50%, 70%, 90% e 100% da cota contratada. Se atingir o limite, a IA é desativada e as solicitações voltam para a fila de atendimento padrão.

Servidor MCP: conectando IA ao banco sem permissão de escrita

Diogo Noschang abordou o problema de permitir que modelos de IA consultem bases corporativas sem expor dados confidenciais ou arriscar alterações indevidas no banco de dados.

Bancos legados acumulam décadas de regras implícitas e tabelas com nomes abreviados que modelos de linguagem interpretam mal se receberem apenas esquemas crus.

Na Starian, a opção foi colocar um servidor Model Context Protocol (MCP) em Python entre o modelo e as bases da empresa:

Camada da Arquitetura	Componente / Ambiente	Controles de Segurança & Execução	Permissão / Escopo
Camada Cliente	Modelo de IA / Orquestrador LLM	Emite consultas específicas de métricas e contexto sob demanda	`Ferramentas sob Demanda`
├── Camada Lógica	Servidor MCP em Python	Sanitização de parâmetros, prevenção de SQL injection e limites de consulta	`Validação & Filtragem`
└── Camada Física	Banco de Dados Relacional Corporativo	Usuário de conexão estritamente restrito a operações `SELECT`	`Somente Leitura (Sem Mutações)`

Fluxo de segurança em duas camadas com Servidor MCP

A separação opera em dois níveis:

Camada lógica (Servidor MCP): O serviço em Python valida os parâmetros da pergunta, barra tentativas de injeção de SQL e rejeita pedidos excessivamente amplos (como consultas que tentam listar tabelas inteiras sem filtro).
Camada física (Banco de Dados): O usuário de conexão utilizado pelo MCP no banco corporativo tem permissão restrita a SELECT. Não existem concessões de INSERT, UPDATE ou DELETE, o que impede modificações em registros de produção mesmo em caso de erro do modelo.

O servidor também carrega contexto sob demanda: em vez de injetar o esquema completo do banco a cada interação, o MCP disponibiliza apenas as ferramentas necessárias para responder àquela métrica específica. No caso do framework Starian Performance 360, no Projuris Empresa, o sistema unificou consultas cruzando Jira, SonarQube, GitLab e Windsurf, registrando alta de 27,3% na vazão qualificada e taxa de retrabalho de 17,6%.

Red Bull Racing: simulações na OCI

A apresentação de Lucas Leung trouxe o uso de computação de alto desempenho pela Oracle RedBull Racing na Fórmula 1.

Nos finais de semana de corrida, a equipe utiliza clusters com Kubernetes rodando mais de quinhentas CPUs ARM na Oracle Cloud Infrastructure (OCI). Em momentos de bandeira amarela ou safety car, o sistema chega a rodar picos de um milhão de simulações de Monte Carlo por segundo, gerando cerca de seis milhões de cenários para avaliar se vale a pena parar nos boxes.

Essa estrutura respaldou a estratégia de Max Verstappen no GP de Miami, quando o piloto largou em nono lugar com pneus duros e estendeu o stint inicial em ar limpo para colocar médios no fim da prova, vencendo a corrida. A decisão no pitwall foi guiada diretamente por esses cálculos de probabilidade em tempo real.

Lovable e Vibe Coding: protótipos rápidos vs. sistemas legados

Alexandre Messina apresentou a trajetória da Lovable e o fluxo de Vibe Coding, mostrando a criação de interfaces funcionais a partir de comandos em linguagem natural.

Entre os exemplos citados, estava o Amosview na Amicci, um sistema de gestão de amostras montado em dois dias por um profissional de operações para resolver um gargalo interno, sem depender de chamados para a equipe de TI. Para validar ideias de produtos, desenhar provas de conceito ou criar ferramentas departamentais simples, a velocidade dessa abordagem é evidente.

Alexandre Messina (Lovable) apresentando a aceleração de protótipos com Vibe Coding.

A fronteira prática aparece quando o protótipo precisa virar produto mantido em escala corporativa. Uma interface montada em linguagem natural resolve a interação inicial, mas não resolve o banco legado com regras acumuladas ao longo de dez anos, filas assíncronas, auditoria ou controle estrito de sessão. Na Lovable é viável estruturar um SaaS com Supabase e Stripe em questão de horas, enquanto nos cenários da Softplan e da 1Doc, o desafio diário é fazer a automação conviver com sistemas legados onde qualquer falha de integridade impacta processos judiciais ou fiscais.

O que fica

Gerar código virou a parte rápida e barata do processo. O trabalho que continua tomando tempo é o de sempre: entender a regra de negócio, desenhar contratos técnicos antes de implementar e garantir testes que segurem regressões.

Saí de lá decidido a estudar mais a fundo o protocolo MCP e escrever especificações melhores antes de pedir código. O resto é conversa.