Como o C6 Bank foi de 10 para 2 sprints na entrega de uma plataforma de dados com Kiro

Por Marcelo Oliveira, Arquiteto de Soluções Sênior; Guilherme Enrico Santos, Gerente Sênior de Soluções; Rafael Gottardi, Arquiteto Enterprise; Alberto Silva, Arquiteto Especialista de Cloud e Dados

O C6 Bank precisava de um único ponto de acesso com governança para dezenas de fontes de dados internas. Com o Kiro, a equipe transformou uma ideia inicial em uma plataforma funcional em dois sprints – um projeto que, em uma abordagem tradicional, poderia levar cerca de dez sprints.

O Kiro é um IDE com agentes de IA que apoiam o desenvolvimento de software desde a concepção até a implementação. Ele oferece Specs (especificações iterativas que geram requisitos, design e tasks), Steering Rules (regras que codificam padrões e decisões do projeto) e Hooks (automações event-driven que validam o código durante o desenvolvimento).

Neste post, descrevemos como o C6 Bank usou o Kiro para transformar uma ideia em plataforma funcional. O DataHub foi entregue em dois sprints (aproximadamente oito semanas), ao longo de três releases incrementais. Mostramos o problema, a arquitetura, o modelo de governança e como o fluxo de trabalho iterativo do Kiro permitiu reduzir um projeto estimado em cerca de dez sprints para apenas dois.

Sobre o C6 Bank

O C6 Bank é um dos maiores bancos digitais do Brasil, com milhões de clientes e dados distribuídos em múltiplas fontes, usando tecnologias distintas, diferentes provedores de nuvem, plataformas de eventos e data lakes. Cada time que precisava de dados construía seu próprio conector, gerando fragmentação e riscos operacionais.

Desafios

O cenário antes do DataHub apresentava os seguintes problemas:

• Sem abstração: cada consumidor precisava entender a tecnologia específica de cada fonte de dados.
• Sem controle de acesso: não havia mecanismo centralizado para determinar quem podia acessar quais campos.
• Sem auditabilidade: era impossível responder “quem acessou o quê e quando?”.
• Sobrecarga nas fontes: a ausência de rate limiting fazia com que bancos de dados de produção fossem sobrecarregados por queries de analytics.
• Agentes de IA sem caminho seguro: workloads emergentes de IA não tinham um canal governado para consumo de dados.
• Sem consistência temporal: leituras diferentes no mesmo fluxo poderiam retornar dados de pontos distintos no tempo.

A figura a seguir ilustra o acoplamento direto entre consumidores e fontes de dados, antes da adoção do DataHub.

Figura 1 – Cenário anterior: consumidores conectados diretamente às fontes de dados, sem governança centralizada.

A solução: DataHub com Kiro

O DataHub fornece uma API única, com governança centralizada, por meio da qual os consumidores solicitam os dados de que precisam, recebendo apenas aquilo que estão autorizados a ver, dentro de uma janela temporal consistente.

Visão geral da arquitetura

A figura a seguir apresenta a arquitetura do DataHub, com os consumidores à esquerda, a plataforma ao centro (API Server, Explorer UI e Worker) e as fontes de dados à direita.

Figura 2 – Arquitetura do DataHub: consumidores acessam dados exclusivamente através da plataforma governada.

Princípios de design:

1. O DataHub não produz nem transforma dados; sua função é entregá-los aos consumidores.
2. Agnóstico à fonte: novas origens de dados são plugáveis sem alterar consumidores.
3. Consistência temporal: snapshots imutáveis dentro de cada janela de consulta.
4. Governado e auditável: identidade, políticas de acesso granular e registro de toda operação.

Camadas de governança

O modelo de governança do DataHub opera em camadas complementares. Políticas de acesso são definidas por domínio de dados, com controle granular por campo. Cada consumidor se autentica por meio da identidade corporativa e recebe apenas os campos autorizados pelo responsável (owner) do domínio. A tabela a seguir resume as camadas:

Fluxo do consumidor

Quando um consumidor solicita dados:

1. O consumidor pede ao DataHub os campos X, Y, Z do produto de dados P.
2. O DataHub verifica a identidade e checa as políticas de acesso.
3. A governança responde: campos X e Y são permitidos, Z está bloqueado.
4. O DataHub consulta a fonte apenas pelos campos autorizados.
5. O consumidor recebe dados governados com metadados de paginação.

O consumidor não precisa conhecer a tecnologia que está por trás de cada fonte de dados.

Como o Kiro acelerou o processo

O ponto de partida era um conceito: um único ponto de acesso governado para todos os dados. Não havia arquitetura definida, nenhum contrato de API, nenhuma decisão de tecnologia. Utilizando o sistema de Specs do Kiro, a ideia se tornou uma especificação completa e validada:

1. Ideia: um único ponto de acesso governado para todos os dados.
2. Spec: requisitos, design e tasks iterados conversacionalmente com o Kiro.
3. Código de Produção: implementação guiada por Steering Rules.

Em uma abordagem tradicional (waterfall), muitos problemas de arquitetura só aparecem após o início da implementação, no sprint 3. Com o Kiro, a equipe validou conceitos durante a especificação, antes de se comprometer com qualquer código.

Steering Rules: código enterprise-grade desde o início

Uma preocupação comum com codificação assistida por IA é a falta de padronização: código funcional, mas não pronto para produção. Esse problema foi endereçado com Steering Rules, que atuaram como a memória técnica persistente do projeto:

• Arquitetura: arquitetura hexagonal, separação de camadas, regras de dependência.
• Princípios de design: quando usar interfaces, quando simplificar, quais padrões adotar.
• Glossário de domínio: termos de negócio com definições precisas.
• Tech stack: quais bibliotecas usar, quais evitar, padrões corporativos.
• Quality gates: lint como gate obrigatório, categorias de teste, cobertura mínima.

Também foram referenciados serviços de produção existentes no banco, permitindo que o Kiro absorvesse padrões corporativos reais para logging estruturado, métricas, health checks, graceful shutdown e configuração YAML.

O resultado foi um código alinhado aos padrões corporativos desde o início, reduzindo a necessidade de ajustes posteriores.

Comprimindo a timeline

Em um fluxo ágil tradicional, esta plataforma seguiria um caminho linear:

Com o Kiro, as fases se sobrepuseram e comprimiram:

Entrega incremental

O projeto foi entregue em três releases, cada uma adicionando capacidades:

Onde o Kiro fez a diferença

Especificação como produto, não como burocracia

Com as Specs do Kiro, a especificação não foi um documento que ninguém lê depois. Serviu como ponto de partida para toda a implementação. Requisitos, design e tasks foram repetidos na mesma sessão, e a implementação já estava alinhada desde o início.

Contexto persistente = zero perda de conhecimento

As Steering Rules codificaram todas as decisões do projeto. Cada nova sessão já conhecia a arquitetura, o glossário, os princípios de design e os padrões corporativos definidos anteriormente. Em um time tradicional, isso equivale a eliminar a perda de contexto entre sessões, sprints ou funcionalidades.

Padrões corporativos desde a linha 1

Ao referenciar serviços existentes e codificar padrões em Steerings, o código gerado nasceu em conformidade com padrões corporativos. Não houve fase de alinhamento ou retrabalho de padronização – o código já estava alinhado desde o início.

Exploração técnica a custo quase zero

Decisões de design (estratégia de cache? modelo de consistência temporal? abordagem de governança?) foram exploradas conversacionalmente antes de implementar. O custo de explorar alternativas de arquitetura caiu significativamente, e ideias ruins foram descartadas antes de virar código.

Resultados

Conclusão

Neste projeto, o Kiro foi utilizado não apenas para acelerar a implementação, mas também para apoiar a definição da arquitetura, incorporar padrões corporativos desde o início e reduzir a perda de contexto ao longo do desenvolvimento. No caso do DataHub, essa abordagem permitiu entregar uma plataforma funcional em aproximadamente dois sprints, preservando requisitos de governança, auditabilidade e qualidade de engenharia.

Mais do que reduzir o tempo de desenvolvimento, a experiência mostrou como o uso estruturado de agentes de IA pode apoiar todo o ciclo de engenharia de software, da especificação à implementação.

Para saber mais sobre o Kiro, acesse https://kiro.dev

Sobre os Autores

	Marcelo Oliveira é Arquiteto de Soluções na AWS. Apoia clientes do setor FSI (Financial Service Industry) em sua jornada para nuvem AWS. Tem foco em projetos que envolvam arquiteturas distribuídas e escaláveis, além de grande interesse na área de Infraestrutura, Networking, Segurança e Containers.
	Guilherme Enrico Santos é Gerente Sênior de Soluções para Clientes na Amazon Web Services (AWS), com mais de 10 anos de experiência em gestão de programas e inovação impulsionada pela tecnologia. Sediado em São Paulo, ele atua há mais de 6 anos na AWS ajudando organizações do setor de serviços financeiros a acelerar a adoção da nuvem e a geração de valor em iniciativas de IA, IA generativa e modernização.
	Rafael Gottardi (Fino) é arquiteto de sistemas e líder técnico no C6 Bank, onde ajudou a construir e evoluir a base tecnológica que sustenta o crescimento do banco. Atua com foco em sistemas escaláveis e resilientes, e contribui ativamente para comunidades de educação em engenharia de software.
	Alberto Silva é Arquiteto Especialista de Cloud e Dados no C6 Bank, onde está desde o início do banco. Tem mais de 20 anos de experiência em tecnologia e trabalha com arquitetura de dados e analytics em nuvem.