guides/custom-software.html

CONSTRUINDO SOFTWARE COM CLAUDE

O fluxo de trabalho brainstorm-to-spec, a toolchain e as decisões que a IA não consegue tomar. A partir de shipping HostList.io, gautamkhorana.com e produtos de clientes da Seahawk.

CONSTRUINDO SOFTWARE COM CLAUDE

← Blog All posts in this topic

Por que este guia existe

Construir software em 2026 com Claude como colaborador de engenharia principal muda a curva de custo e a forma do time, não o ofício subjacente. As partes pesadas em julgamento do software (o que construir, por quê, como deveria se comportar em caso de falha) ainda exigem atenção humana. As partes de execução (escrever o código, refatorar, gerar boilerplate, executar migrações) comprimem dramaticamente. Saber qual é qual é toda a habilidade em 2026.

Este guia é o fluxo de trabalho que realmente uso para fazer shipping de produtos customizados na Seahawk Media e em projetos pessoais como HostList.io, gautamkhorana.com e Deluxe Astrology. Não é um tutorial de Claude, não é um manual de prompt-engineering. A disciplina de processo que produz software shippable com Claude como o engenheiro que carrega o peso.

O fluxo de trabalho brainstorm-to-spec

Etapa 1: brainstorm estruturado

Antes de escrever qualquer código, faço um brainstorm estruturado com Claude. O prompt: descrever o problema em linguagem natural, pedir ao Claude para levantar cinco questões cujas respostas mudariam o design, respondê-las, depois pedir ao Claude para resumir a spec do produto resultante em 200 palavras. Essa fase leva 30 a 60 minutos e produz uma spec escrita a partir da qual o resto do trabalho flui.

Etapa 2: decisões técnicas

Com a spec em mãos, peço ao Claude para identificar as escolhas arquiteturais que têm maior impacto downstream. Forma do banco de dados, superfície da API, estratégia de renderização, modelo de deployment. Para cada uma, Claude propõe duas ou três opções e os trade-offs. Eu escolho. As decisões são anotadas no mesmo documento para que a fase de build tenha uma única fonte de verdade.

Etapa 3: implementação orientada por spec

Geração de código é a última etapa, e é a mais rápida porque a spec já está completa. Claude escreve o schema, as queries, os componentes, as rotas, os testes, grosso modo nessa ordem. Eu reviso cada commit. A maioria das reviews surfaceia um pequeno refactor ou um edge case faltante; rewrites completos são raros quando a spec era clara.

O que Claude é bom e o que não é

Bom em

Código greenfield em padrões bem conhecidos: APIs REST, painéis admin CRUD, fluxos de autenticação, engines de blog, sites de marketing. Refatoração de código existente onde a forma alvo é claramente declarada. Geração de testes para código que tem inputs e outputs claros. Escrita de scripts de migração quando o diff de schema é inequívoco. Redação de documentação. Debug de código onde o sintoma é reproduzível e o trace está em contexto.

Menos bom em

Decisões arquiteturais em domínios desconhecidos. Código de integração onde a API de terceiros é mal documentada ou mudou recentemente. Otimização de performance onde o gargalo é não-óbvio. Geração de código em linguagens ou frameworks obscuros onde os dados de treinamento são escassos. Qualquer coisa onde os requisitos são ambíguos e o LLM vai preencher com defaults que parecem plausíveis mas estão errados para seu caso específico.

A lacuna de julgamento

Claude é consistentemente melhor que o engenheiro mediano em escrever a próxima linha de código. Claude é consistentemente pior que um engenheiro sênior em decidir se a próxima linha de código deveria existir. A camada de julgamento sênior é o que você traz. A velocidade de execução é o que Claude traz. A combinação vence qualquer uma sozinha.

A cadeia de ferramentas que eu realmente uso

Claude Code como a superfície principal

Claude Code é o IDE para desenvolvimento assistido por IA. Contexto do projeto carregado uma vez, acesso ao terminal, acesso ao sistema de arquivos, integração de ferramentas MCP. A ferramenta de maior alavancagem que adicionei à minha stack em 2025. A maioria do trabalho de engenharia agora acontece em Claude Code em vez de diretamente em VS Code ou Cursor.

Cursor para edições diretas no editor

Cursor ainda é a melhor experiência de editor para trabalhar ao lado de IA em um único arquivo. Conclusão por abas, edições inline, diff lado a lado. Uso Cursor quando o trabalho está concentrado em um ou dois arquivos; mudo para Claude Code quando o trabalho abrange o projeto.

Claude Sonnet via API para trabalho em lote

Quando preciso gerar ou reescrever centenas de páginas programaticamente (o pipeline de auto-blog, humanização de conteúdo, geração de schema), chamo a API Claude diretamente via Sonnet. Latência menor que a superfície de chat, custo previsível, scriptável. A ferramenta certa para pipelines de conteúdo especificamente.

OpenAI GPT-4o para engenharia de prompts

Minha descoberta no final de 2025 foi que prompts para Kimi, Minimax ou qualquer outro agente são melhor escritos por Claude ou GPT, não à mão. Eu descrevo o objetivo, peço ao GPT-4o para escrever o prompt, e então executo esse prompt contra o executor. A qualidade do resultado é materialmente melhor do que equivalentes feitos à mão.

Kimi Researcher e Minimax Agent

Pesquisa profunda e mockups de design de aplicativo completo respectivamente. O post /blog/kimi-minimax-deep-research-design-mockups/ cobre o fluxo de trabalho completo. Ambas são ferramentas críticas na Seahawk para pesquisa de clientes e prototipagem rápida.

Disciplina de repositório que sobrevive ao desenvolvimento assistido por IA

Commits pequenos, mensagens descritivas

O desenvolvimento assistido por IA tende a produzir diffs grandes porque é fácil fazer deploy de 800 linhas de código gerado em um único commit. Discipline-se para fazer commits menores. Uma mensagem de commit que diz o que mudou e por quê é o único artefato que você-do-futuro terá para debugar uma regressão. Deixe-a legível.

Testes como contrato

Claude pode escrever código que compila e executa mas viola silenciosamente uma restrição que era implícita na especificação. Testes que codificam essas restrições como contratos executáveis capturam as violações. A disciplina de teste-primeiro importa mais na era assistida por IA do que importava quando humanos escreviam cada linha.

Code review é apenas humano por enquanto

Eu não deixo Claude aprovar seus próprios pull requests. O gate de review é o controle de qualidade mais importante que resta aos humanos, e terceirizar para o mesmo modelo que escreveu o código derrota o propósito. O SDK do Anthropic e os fluxos de Claude Code tornam a review assistida por IA fácil, mas a aprovação final é minha.

Dependências versionadas e arquivos de bloqueio

Fixe todas as dependências. Use arquivos de bloqueio. Execute npm audit em cada build. A superfície de ataque da cadeia de suprimentos é real e o desenvolvimento assistido por IA tende a adicionar mais dependências do que equivalentes escritos por humanos porque adicionar um pacote é rápido. Disciplina de arquivo de bloqueio mantém a superfície auditável.

As decisões de produto que IA não consegue tomar

Cinco categorias de decisão onde Claude é a ferramenta errada:

O que construir afinal. A decisão de produto é pesada em julgamento, depende do contexto do usuário que Claude não possui, e é a decisão mais consequente em qualquer produto. Fundadores e PMs detêm isto; IA auxilia na melhor das hipóteses.

O que lançar e o que cortar. Decisões de escopo durante uma construção sempre se resumem a restrições que o modelo não vê. Pressão de tempo, moral da equipe, relacionamentos com parceiros, posicionamento de marketing. Decida como humano, documente o raciocínio, depois peça a Claude para executar o escopo decidido.

Design de modo de falha. Como o sistema deve se comportar quando as coisas dão errado raramente é especificado antecipadamente e é de onde originam a maioria dos incidentes em produção. Dedique tempo desproporcional aos modos de falha; eles não emergirão naturalmente da geração de código do caminho feliz.

A camada ética. O que você constrói tem implicações. Privacidade, residência de dados, acessibilidade, custo ambiental. Estas são decisões humanas, não saídas de otimização. Faça a pergunta explicitamente no tempo de design.

Manutenibilidade de longo prazo. Futuro-eu lendo futuro-Claude lendo o código de Claude-presente é a versão mais profunda de débito técnico. Otimize o código presente para ser legível por humanos primeiro, IA segundo.

Projetos específicos que enviei desta forma

Exemplos concretos dos últimos doze meses na Seahawk e pessoalmente:

HostList.io (28.000 páginas programáticas em Next.js + Supabase): estruturado com Claude Code em cinco dias, pipeline de conteúdo escrito por Claude com integração de pesquisa Tavily, geração de hero via FAL, markup de schema gerado automaticamente. O tempo de engenharia total foi aproximadamente um terço do que teria estimado há três anos.

gautamkhorana.com (este site, em Astro + Supabase): reconstruído em um fim de semana de 24 horas com Claude Code como colaborador principal. Superfície de editor de site, sistema de blog, camada de schema, i18n, tudo gerado, revisado, refatorado. O custo de construir um site pessoal nesta qualidade caiu para um fim de semana de trabalho focado.

Auto-blog e pipeline de tradução do Deluxe Astrology: o loop Tavily-research-to-Claude-draft-to-Winston-check-to-FAL-hero-to-Supabase-publish é executado diariamente em 30 idiomas em 91.000+ páginas. O pipeline em si tem aproximadamente 800 linhas de código que Claude escreveu em cerca de 12 horas de trabalho focado, muito do que teria levado uma semana com um time somente humano.

Dashboards admin internos na Seahawk: Minimax Agent gera o primeiro protótipo a partir de uma descrição de seis linhas, Claude refina, o resultado é entregável em uma hora. O tempo de "precisamos de uma ferramenta interna" para "estamos usando a ferramenta interna" caiu de dias para menos de um dia de trabalho.

A conclusão

Construir software personalizado em 2026 é um ofício que se comprimiu em uma ordem de magnitude na velocidade de execução e permaneceu aproximadamente constante na complexidade de julgamento. Os times que se adaptam são aqueles que trazem mais julgamento (especificações melhores, escolhas arquiteturais melhores, design de modo de falha melhor) e terceirizam mais execução para IA. Os times que não se adaptam produzem software em velocidade competitiva mas perdem em qualidade, ou vice-versa.

Você não precisa usar cada ferramenta neste guia. Você precisa saber quais decisões são suas e quais podem ser delegadas. A habilidade é o limite, não o conjunto de ferramentas.

Se você quer ajuda para entregar um projeto de software personalizado nesta curva de custo, realizamos product builds na Seahawk Media. A conversa é gratuita; o preço do projeto reflete a realidade de custo assistido por IA, não a realidade de custo horário de 2018.

WHEN YOU ARE READY TO TALK