Painel Acadêmico
O sistema que professores usam para lançar o diário de turma
Interface web onde o professor registra frequência, notas e conceitos dos alunos. É o sistema de diário acadêmico usado por todas as faculdades de um grande grupo educacional privado — incluindo os cursos de medicina, que têm as regras de avaliação mais complexas do currículo.
Sistema em produção, multi-instituição, com anos de histórico de dados. Nada aqui é greenfield: cada mudança precisa conviver com o que já está rodando e com o que já foi lançado.
Este é um projeto corporativo. O cliente e os detalhes internos do domínio não são identificados, e o código não é público.
Por que este projeto importa na minha trajetória
Antes dele, tudo que eu sabia sobre estruturar software eu tinha aprendido sozinho, nos meus projetos. O Reboo me ensinou a organizar um projeto do zero — este me ensinou a entregar dentro de um time, que é uma habilidade diferente e que não dá pra treinar sozinho.
Foi meu primeiro ambiente de desenvolvimento corporativo de verdade: squad, tech lead, QA, code review que barra o que não deve subir, pipeline que outras pessoas dependem.
Fase 1 — desenvolvedor na squad
Squad de cinco desenvolvedores, um tech lead e QA dedicado, trabalhando em Kanban com dailies. O código já vinha estruturado com Clean Code, Clean Architecture e DDD — foi a primeira vez que trabalhei dentro de uma arquitetura que eu não desenhei e que precisava respeitar.
O fluxo era: puxar a task refinada, desenvolver com autonomia, subir para code review de alguém da squad, passar por QA e só então ir para a pipeline.
O que eu fazia na prática:
- Endpoints e regra de negócio no backend em .NET 8 / C#
- Acesso a dados em modelo híbrido: Entity Framework Core onde o ORM resolvia bem, e SQL puro onde foi avaliado que o desempenho e a clareza da query compensavam escrever à mão
- Muita coisa em PostgreSQL — construção e ajuste de query fazia parte do dia a dia
- Frontend em Vue quando a task pedia, sem me limitar à camada que eu já dominava
- Code review de código dos colegas
- Acompanhamento e ajuste de pipeline no Azure Pipelines (com o código hospedado no GitLab)
O modelo de trabalho era pegar a task que estava sobrando, aprender o que fosse necessário na hora e entregar. Foi assim que atravessei banco, backend e frontend no mesmo projeto.
O que ficou comigo: trabalhar com gente. Perguntar para o tech lead em vez de travar sozinho, revisar código de outra pessoa com cuidado, receber revisão sem defensividade, e entender que num sistema usado por várias instituições o code review rígido não é burocracia — é o que segura o estrago. Era uma squad genuinamente colaborativa, e boa parte do que aprendi ali veio de outras pessoas, não de documentação.
Fase 2 — liderança técnica de uma entrega experimental
A partir de julho de 2026 assumi a liderança técnica de uma frente do sistema conduzida com desenvolvimento assistido por IA.
O problema: migrar a avaliação de um tipo de currículo de conceito para nota. Parece uma troca simples e não é — mexe no modelo de avaliação de um sistema em produção, com dado histórico, regras específicas por instituição e impacto direto no que o professor vê na tela.
O desafio real era o prazo. A mudança tinha que estar no ar na virada de semestre. Não havia folga e não havia plano B: adiar para o semestre seguinte não era uma opção que existia. Foi exatamente essa restrição que motivou a abordagem experimental — era preciso entregar rápido e com qualidade, e o caminho convencional não cabia na janela.
Ou seja: uma entrega experimental que não tinha permissão para falhar. Foi esse o problema que eu tive que resolver.
A estrutura que eu montei
A aposta foi que IA só entrega bem dentro de uma estrutura rígida. Comecei com o Amazon Kiro e migrei para o Codex, e o trabalho de verdade foi construir os trilhos:
- Documentação viva no Notion como fonte única. Épicos, histórias, tasks, regra de negócio, requisitos funcionais e não funcionais — e também as instruções de como a IA e a squad deveriam trabalhar no projeto.
- A task como contrato de implementação. Essa foi a regra mais importante: o agente não podia fazer nada além do que estava descrito na task, e nada diferente do que estava descrito nela. Escopo fechado, sem iniciativa criativa. É o que impede a IA de sair inventando refatoração ou resolvendo um problema que ninguém pediu no meio de uma entrega com prazo.
- Plano antes da ação, e ação declarada. O agente precisava dizer o que ia fazer antes de fazer — onde ia buscar informação, o que ia alterar, qual o plano. Transparência não é conforto, é o que torna possível interromper cedo quando o caminho está errado, em vez de descobrir no code review.
- De
agents.mdpara hooks. As regras começaram numagents.mde evoluíram para hooks no Codex que consultavam o Notion via API. A diferença é grande: em vez de depender de um arquivo estático estar atualizado, a IA passava a puxar o contexto correto em tempo de execução. - Guardrails de processo. O hook garantia que, em qualquer ponto, o agente soubesse qual era a próxima task, a marcasse como em andamento, buscasse a regra de negócio ligada àquele épico, seguisse o padrão de branch, abrisse o pull request no formato certo e atribuísse revisor.
- Limites explícitos do que não podia ser feito. Banco de produção era intocável. O desenvolvimento acontecia contra um banco local, e o ambiente de dev do cliente ficava reservado exclusivamente para investigação de bug, onde acelerava de verdade.
- Playbooks — na prática, skills. Páginas de instrução versionadas que o agente segue: code review, QA automatizado, automações de frontend. Cada verificação virou um artefato reutilizável em vez de prompt improvisado.
A prova de que os guardrails funcionavam foi eles me barrarem. Em determinado momento precisei investigar um bug localmente em vez de no ambiente de dev — um caminho que simplesmente não estava previsto nas regras. O agente se recusou a fazer. Não era defeito: era a estrutura fazendo exatamente o que foi desenhada para fazer.
A saída foi criar um sudo: um pseudo-comando que permite autorizar explicitamente uma ação fora do contrato, acompanhada da forma correta de executá-la naquele momento. Preferi abrir uma exceção deliberada e visível a afrouxar a regra para todo mundo — porque regra que se dobra sozinha quando incomoda não é guardrail, é sugestão.
Meu papel
Deixou de ser escrever o código e passou a ser garantir que a entrega acontecesse:
- Fechamento de requisito direto com o cliente, transformando regra de negócio ambígua em especificação executável
- Estruturação completa do backlog em épicos, histórias e tasks, para que o refinamento — que normalmente consome boa parte do tempo da squad — chegasse pré-digerido em vez de ser construído do zero em reunião
- Engenharia reversa do código existente com apoio de IA, para mapear o impacto real da mudança num sistema que eu não escrevi
- Desbloqueio de time no dia a dia: destravar refinamento confuso, priorizar correção de bug, garantir que o que foi encontrado fosse corrigido a tempo
Resultado: dois épicos e vinte histórias entregues entre julho e setembro de 2026, definidos e construídos do zero junto ao cliente — dentro da virada de semestre.
O que eu concluí
A parte que mais me marcou foi confirmar que estruturar antes de executar é o que realmente acelera a entrega. Requisito fechado, épico bem recortado, história com escopo claro e guardrail explícito fizeram mais pela velocidade do time do que qualquer ganho de digitação. Velocidade não veio de escrever código mais rápido — veio de reduzir a quantidade de decisão ambígua que chegava na mão de quem estava executando, pessoa ou agente.
Esse método não nasceu aqui. Eu já usava agentes separados por função — QA, code review, research — e backlog estruturado no Reboo, meu projeto pessoal. O que este projeto me deu foi a escala e a pressão para expandir aquilo: a parte de hooks, de documentação viva e de guardrail de processo foi muito além do que eu tinha feito sozinho.
E foi validado onde importa: sistema em produção, várias instituições dependendo dele, prazo que não se move, e um time que não era só eu.