2

Sou gestor, não programador. Usei IA agêntica para validar (e começar) a virada de uma fábrica de software hospitalar

Contexto rápido, porque pesa no que vem: sou administrador e lidero há ~15 anos a fábrica de software de uma rede hospitalar. Não escrevo código de profissão. Time pequeno, sistema grande (legado de mais de uma década, rodando em 40+ unidades).

Este post é o relato técnico de como saímos do ceticismo para a conversão de módulos reais — e do método que usamos. Não é venda. É relato, e estou aqui para apanhar nos comentários (de preferência com fundamento).

O problema
Manter uma equipe pequena e de alta performance entregando valor num sistema gigante é uma pressão constante. Quando o mundo agêntico ganhou escala em 2025, a pergunta não era "isso é legal?", era: dá pra colocar isso pra trabalhar sem parar a operação?

O método: muitos experimentos pequenos
Em vez de uma grande prova de conceito, abri dezenas de projetos isolados e descartáveis, cada um testando uma hipótese específica:

  • este tipo de módulo a IA dá conta?
  • com qual arquitetura o resultado se sustenta?
  • qual a qualidade real do código gerado? e dos testes?

Cada projeto respondia uma pergunta. O que dava certo virava padrão; o que falhava custava barato. Muitas apostas pequenas e verificáveis no lugar de uma grande aposta cega.

Isso é o oposto de "vibe coding". É método de fábrica aplicado à própria adoção da IA.

Stack e escolhas
Nos experimentos, o padrão que se firmou foi:

Monorepo: Bun + Turborepo
Front: React + TanStack Router + Tailwind/shadcn
Back: Hono + tRPC
Dados: PostgreSQL + Drizzle
Testes: Vitest + Playwright

E a escolha mais controversa (onde quero o debate): não fomos de LangChain/LlamaIndex. Montamos nosso próprio fluxo agêntico sobre Claude Code + Skills, com rastreabilidade e checkpoints de revisão. Aposta deliberada em método e controle em vez de framework genérico.

O que de fato fizemos
Saí dos experimentos e fui para a conversão de módulos do sistema hospitalar real. Já desenvolvi 2 frentes.

Sendo honesto para não inflar: está em andamento, não é "tudo em produção nas 40+ unidades". É construção de verdade, não maquete — mas é processo, não bandeira de vitória.

O que me surpreendeu

  • Velocidade e qualidade bem acima do que eu, cético, esperava.
  • O gargalo deixou de ser "escrever código" e virou especificar bem, revisar e medir.
  • O papel do arquiteto (trabalho lado a lado com o André Lins) ficou mais importante, não menos.
    Onde eu sei que vou apanhar (e quero apanhar)
  • "Gestor não-programador não tem como avaliar a qualidade do que a IA gera." — é uma crítica legítima. Venham com ela.
  • Manutenção de longo prazo do código gerado por agente: é a pergunta em aberto que mais me tira o sono.
  • Onde o método quebra em escala? É o que estou tentando descobrir.

Escrevi uma versão mais "de gestão" dessa virada (um manifesto): https://mdemian1972.substack.com/p/enquanto-a-ia-agentica-e-vendida. Mas aqui no TabNews eu queria o recorte cru e o debate técnico.

Joguem pedra — fundamentada. É assim que eu aprendo.

Carregando publicação patrocinada...
1

Cara, parabéns pela iniciativa! Gestor usando IA agêntica pra realmente validar hipóteses na prática — e não ficar só no hype — é raro de ver. O approach de "apostas pequenas e verificáveis" faz todo sentido, principalmente em healthcare onde erro é caro.

Achei muito certeiro o ponto de "o gargalo deixou de ser escrever código". Passei pela mesma conclusão — o gargalo real agora é a qualidade da especificação que você dá pro agente. Comecei a usar uma estrutura chamada CTRF (Contexto, Tarefa, Restrições, Formato) pra padronizar como comunico com IA e a diferença foi enorme.

Escrevi sobre isso aqui no TabNews: https://www.tabnews.com.br/neuroniosartificiais/descobri-um-metodo-pra-parar-de-receber-respostas-ruins-de-ia-e-quero-a-opiniao-de-voces

Vocês estão usando alguma forma de padronizar a comunicação com os agentes na fábrica?