Como uso o Claude Code no meu projeto: não como autocomplete, mas como colega de trabalho com acesso real ao sistema · obrenoalvim

A maioria das pessoas usa IA para escrever código. Eu uso de forma diferente, e quero documentar isso porque acho que vale a reflexão.

O projeto é o BloodLink, uma plataforma de doação de sangue. Stack é Next.js, PostgreSQL com Drizzle ORM, deploy na Vercel. Nada exótico.

O que é diferente é como o Claude Code entra no processo.

Não é autocomplete

Autocomplete é quando você começa a digitar e a IA completa a linha. Isso é útil, mas é passivo. O que eu faço é diferente: eu descrevo o problema, dou contexto do projeto, e deixo o Claude navegar nos arquivos, entender a arquitetura existente e propor a solução completa.

A diferença prática: eu não fico no loop de escrever código, ver erro, corrigir, ver outro erro. Eu reviso o que foi feito e decido se faz sentido.

O que eu delego de verdade

Algumas coisas que o Claude fez no BloodLink sem eu escrever uma linha:

Implementou o sistema de notificações por email com Resend
Criou as rotas de FAQ com SEO individual por página
Corrigiu vulnerabilidades de segurança depois de uma revisão
Pesquisou emails de hemocentros e hospitais e enviou apresentação do projeto no meu nome

Esse último caso eu já documentei em outro post. O ponto aqui é que não é só código: é qualquer tarefa que pode ser descrita com clareza.

O que eu não delego

Decisões de produto. O que construir, para quem, por quê. Isso continua sendo meu.

Também não delego revisão final. Tudo que o Claude faz eu leio antes de aceitar. Não porque desconfio, mas porque manter o contexto do que está no projeto é responsabilidade minha.

O que mudou no meu ritmo

O projeto avança muito mais rápido. Mas o mais interessante não é velocidade: é que eu consigo trabalhar em partes do sistema que eu teria evitado por serem chatas ou complexas demais para o tempo que eu tinha.

Funcionalidade de geração de imagem para compartilhamento? Teria ficado para depois. Com esse fluxo, ficou pronto em uma tarde.

Isso não é propaganda de ferramenta. É um relato honesto de como mudou meu processo. Curioso para saber se alguém aqui usa de forma parecida ou completamente diferente.

Estou tentando uma abordagem parecida, mas com uma camada extra: em dezembro, iniciei a escrita de um manifesto sobre a Arquitetura Cristalina (Tekt).

A ideia central é que, para a IA atuar como um colega de trabalho eficiente, o código precisa ser estruturalmente previsível. Não basta dar acesso aos arquivos; o sistema precisa de regras que o agente consiga validar de forma literal.

Minha prática foca nestes pontos:

Fronteiras Rígidas: O código é dividido em camadas estritas (Core, Shell, Infra, Wiring). A IA sabe exatamente onde cada lógica deve ser escrita, pois o manifesto proíbe a mistura de responsabilidades.
Validação Automática: utilizo um linter de arquitetura (tekt-linter) que valida se o agente respeita essas divisões. Se a IA tentar vazar lógica do Core para a Infra, o erro é detectado no momento da escrita.
ADRs (Architecture Decision Records): registra as decisões técnicas para fornecer o contexto do "porquê". Isso impede que a IA sugira soluções que conflitem com a estratégia de longo prazo.

Nesse modelo, o desenvolvedor atua como um gestor de regras e arquitetura. Você deixa de ser o "digitador" para ser o guardião da estrutura que permite a autonomia da IA.

Ainda é uma proposição em teste. Estou tentando provar essa tese por meio da refatoração do projeto Typst, movendo a lógica complexa do compilador para esse modelo cristalino.