GregoriDalzotto
Sistemas, do código à estratégia.
Engenharia, arquitetura, produto e liderança de tecnologia em uma mesma prática, há duas décadas.
03Evolução de escopo
Duas décadas de escopo acumulado.
Nenhuma camada substituiu a anterior. Cada uma ampliou as de baixo, e a construção de software nunca saiu do centro.
01
Construir
Código que precisa funcionar fora da demo. A base de tudo o que veio depois, e a prática que nunca foi abandonada.
02
Sistemas
Entender como as partes se comportam juntas: dados, integrações, APIs, falhas. Software deixa de ser arquivo e vira comportamento.
03
Arquitetura
Decidir limites, contratos e o que pode mudar sem quebrar o resto. Arquitetura como redução de ambiguidade.
04
Plataformas
Infraestrutura, cloud, CI/CD, segurança e operação. O sistema precisa existir, ser observável e continuar de pé.
05
Times
Liderar quem constrói: papéis, autoridade, ritmo, revisão. Produtividade como propriedade do sistema, não do indivíduo.
06
Produto
Transformar capacidade técnica em algo que alguém usa. Priorização, escopo e resultado medido, não entregue.
07
Estratégia
Tecnologia produzindo capacidade para o negócio: o que construir, o que comprar, o que integrar e quando parar.
08
IA
A camada mais recente, construída sobre todas as anteriores: agentes, RAG, workflows de engenharia e verificação automatizada, aplicados com o contexto que as outras camadas fornecem.
04Experiência
Experiência medida em responsabilidade, não em cargos.
O que ficou de cada contexto foi capacidade: de entrar em um sistema que já existe, entender o que está em jogo, decidir e conduzir a execução.
Sistemas corporativos e integração
- Contexto
- Ambientes com ERP, CRM e sistemas legados convivendo com serviços novos, onde cada integração carrega regra de negócio, dado sensível e histórico.
- Responsabilidade
- Desenhar e construir a camada que faz esses sistemas conversarem: APIs, contratos, automações e o tratamento das falhas entre eles.
- Decisões
- Onde fica a fronteira de cada sistema, o que se integra em tempo real e o que se concilia depois, e o que não deve ser automatizado.
Infraestrutura, cloud e operação
- Contexto
- Sistemas que precisam existir em produção com custo, segurança e disponibilidade controlados, em mais de um provedor de cloud.
- Responsabilidade
- Containers, CI/CD, observabilidade, segurança e a rotina de operação que mantém tudo de pé quando ninguém está olhando.
- Decisões
- O que automatizar no pipeline, o que exige gate humano, e quanto de plataforma o time realmente precisa naquele momento.
Transformação digital
- Contexto
- Processos e áreas de negócio que precisavam virar software, com a mudança organizacional que isso exige.
- Responsabilidade
- Conduzir a transição: escolha de plataforma, sequência de entrega, integração com o que já existia e adoção pelas pessoas.
- Decisões
- Construir, comprar ou integrar; o que muda primeiro; e como medir se a transformação produziu capacidade e não só sistemas novos.
Produtos digitais
- Contexto
- Produtos web e mobile levados do problema ao uso real, com arquitetura, construção e evolução contínua.
- Responsabilidade
- Concepção, arquitetura e construção, com escopo definido pelo que o usuário precisa e pelo que o negócio consegue sustentar.
- Decisões
- O que entra na primeira versão, o que fica para depois e quais compromissos técnicos são aceitáveis em cada fase.
Liderança de tecnologia
- Contexto
- Estruturas de tecnologia e equipes multidisciplinares, com prioridades concorrentes e ambientes técnicos complexos.
- Responsabilidade
- Papéis, padrões, ritmo de entrega, contratação e a relação entre tecnologia e o restante da organização.
- Decisões
- Quanta autonomia cada frente recebe, o que é padrão e o que é escolha do time, e onde a liderança técnica desenha os defaults.
Inteligência artificial aplicada
- Contexto
- Produtos e processos de engenharia nos quais LLMs, RAG e agentes passaram a fazer parte do sistema, com os riscos que isso traz.
- Responsabilidade
- Aplicar IA com contexto, limites e verificação: em produtos, e no próprio fluxo de construção de software.
- Decisões
- Que nível de autonomia cada tarefa merece, o que precisa de evidência antes de valer, e onde a arquitetura limita a atuação de agentes.
05Casos de engenharia
Casos de engenharia.
Sistemas apresentados pelas decisões que os formaram, não por captura de tela. Abra um para ver as partes.
Contexto
Onde o produto vive, quem usa, o que já existia antes da IA entrar e por que ela entrou.
Desafio
O que tornava o problema difícil: volume, ambiguidade dos dados, custo por chamada, expectativa do usuário.
Decisão
As escolhas que definiram o sistema: o que a IA decide sozinha, o que passa por verificação, o que fica determinístico.
Arquitetura
Como as partes se organizam: ingestão, recuperação, geração, validação e o que observa tudo isso.
Construção
Como foi construído e evoluído: sequência de entregas, o que mudou no caminho e o que foi descartado.
Resultado
O que mudou para quem usa e para o negócio, medido, e o que ficou aprendido.
Em contextoNext.jsNode.jsPythonbanco vetorialLLMsRAG
Contexto
A empresa, os sistemas envolvidos e a dependência que o negócio tinha da integração funcionar.
Desafio
Dados inconsistentes entre sistemas, regras implícitas no legado, janelas de indisponibilidade e risco de duplicidade.
Decisão
Onde cada sistema é fonte de verdade, o que integra em tempo real e o que concilia depois, e o que ficou manual de propósito.
Arquitetura
A camada de integração: contratos, filas, idempotência, reprocessamento e observabilidade das falhas.
Construção
Como a integração entrou em produção sem parar a operação, e como foi validada contra o dado real.
Resultado
Processos que passaram a fluir sem intervenção, erros que deixaram de acontecer e o que ainda ficou em aberto.
Em contextoERPCRMAPIsNestJSRedisfilas
Contexto
O time, a base de código e o ritmo de entrega antes de a automação entrar.
Desafio
Execução ficou abundante e a fila de revisão, a integração e a verificação viraram o gargalo.
Decisão
Papéis e autoridade de cada agente, o que pode ser automatizado e o que exige gate humano por risco.
Arquitetura
Workflow, artefatos, memória de projeto e as verificações independentes que decidem o que está pronto.
Construção
Como o fluxo foi introduzido em etapas, medido e ajustado conforme o time o usava.
Resultado
O que mudou em lead time, retrabalho e confiança nas entregas, e o que a automação não resolveu.
Em contextoagentes de IAGitHub ActionsCI/CDTypeScriptcontext engineering
06Tecnologia
Ferramentas escolhidas pelo problema.
Nenhuma delas é o ponto. O ponto é saber combinar o que cada camada pede, e o que ela não pede.
Construir
O que vira produto.
- TypeScript
- Node.js
- React
- React Native
- Next.js
- Python
- FastAPI
- NestJS
Sistemas
O que faz as partes conversarem.
- APIs
- Microserviços
- Redis
- Bancos relacionais
- Bancos vetoriais
- Filas e eventos
Plataforma
O que mantém tudo de pé.
- Docker
- CI/CD
- GitHub Actions
- AWS
- Azure
- GCP
- Segurança
- Observabilidade
Corporativo
O que já existe na empresa.
- ERP
- CRM
- Integrações
- Automação de processos
IA
A camada mais recente.
- LLMs
- RAG
- Agentes
- Orquestração
- Context engineering
- Automação de workflows
07IA e engenharia
IA como camada, não como ponto de partida.
Nos últimos anos, o trabalho passou a incluir inteligência artificial aplicada a produtos e ao próprio processo de engenharia.
Não é onde a trajetória começou. É onde a base acumulada em sistemas, arquitetura, operação e liderança passa a fazer diferença: ela dá o contexto para aplicar IA com responsabilidade.
IA em produtos
LLMs, RAG e sistemas inteligentes dentro de produtos reais, com contexto, custo, latência e falha tratados como requisitos, não como surpresa.
Engenharia assistida por IA
Agentes especializados, context engineering, workflows de engenharia e orquestração, com a arquitetura definindo até onde a autonomia vai.
Verificação e evidência
Validação automatizada, gates proporcionais ao risco e memória de projeto. Execução abundante pede mais verificação, não menos.
A IA amplia o que já existe. Sobre uma base sólida, acelera; sem ela, acelera o erro.
08Princípios
Como penso tecnologia.
Um conjunto de posições que vale mais do que qualquer ferramenta, porque sobrevive a todas elas.
Software precisa funcionar fora da demo.
Caminho feliz não define prontidão. Produção é parte do desenvolvimento.
Arquitetura reduz ambiguidade.
Limites claros dizem onde mudar e o que não pode mudar sem conversa.
Velocidade sem qualidade só antecipa problemas.
O que se ganha na entrega se paga na revisão, na integração e no incidente.
Automação precisa de limites.
Autonomia se conquista por risco e verificabilidade. Não se declara.
Sistemas precisam ser observáveis.
O que não se mede não se opera, e o que não se opera não está pronto.
Tecnologia precisa produzir capacidade para o negócio.
Stack não é resultado. Capacidade é.
IA amplifica boas e más práticas de engenharia.
Com base sólida, acelera. Sem base, acelera o erro.
10Sobre
Na interseção, por escolha.
Gregori Dalzotto atua na interseção entre engenharia de software, arquitetura, produto, liderança de tecnologia e inteligência artificial aplicada.
São cerca de duas décadas construindo e evoluindo sistemas: do código à infraestrutura, dos sistemas corporativos aos produtos digitais, da equipe à estratégia. Ao longo desse caminho, a construção de software nunca deixou de ser praticada, mesmo com a responsabilidade se ampliando para arquitetura, operação, produto e pessoas.
Nos últimos anos, parte central do trabalho passou a ser a inteligência artificial aplicada à engenharia e à construção de produtos: agentes, RAG, workflows e verificação automatizada, sempre a partir da base acumulada e não como ponto de partida.
11Contato
Uma conversa costuma ser o melhor começo.
Sistemas, arquitetura, produto, liderança ou IA aplicada. Se o assunto for esse, o canal é qualquer um destes.