Três semanas, uma aplicação: O que a IA pode construir para si e o que absolutamente não pode

Há três semanas, eu tinha um backend .NET com talvez 40% dos serviços conectados, um frontend Vue meio acabado e um plano vago. Hoje, o Rasepi tem um motor de tradução de nível de bloco com gestão de glossário e regras de estilo, um sistema de pontuação de frescura com modelos de expiração e fluxos de trabalho de revisão, pesquisa semântica alimentada por IA com RAG, um SDK de plugin completo com guardas de ação e pipelines de eventos, edição colaborativa em tempo real, um site de marketing completo com páginas de preços, um portal de documentação para programadores, um blogue com 14 posts, traduções automáticas em 7 línguas e um formulário de lista de espera que envia e-mails.

Não fiz isto sozinho. Tinha o Claude a correr no VS Code todas as noites durante horas e, por vezes, até durante todo o dia, e foi verdadeiramente transformador para as partes em que podia ajudar. Mas há um abismo entre "construir uma aplicação" e "ter algo que se possa realmente vender a outro ser humano", e esse abismo está cheio de toneladas de páginas de configuração, configuração manual, definições de capacidade de entrega de correio eletrónico e registos DNS. O Claude ainda não consegue falar com todos esses serviços.

As pessoas raramente falam sobre essa parte.

Eu poderia ter feito isso sem IA?

Olha, eu tenho mais de 30 anos de experiência na construção de software. Será que eu poderia ter feito tudo isso sem o Claude? Provavelmente. Mas não em três semanas. Nem de perto. A IA acelerou tudo o que envolve digitar código em ficheiros, e isso é uma grande parte de qualquer projeto.

Mas há uma coisa que as pessoas não percebem quando falam de "vibe coding" e de construir aplicações inteiras com IA: você ainda precisa saber o que está fazendo. O Claude pode lhe dizer cada passo necessário para implantar um Cloudflare Worker com um banco de dados D1. Ele pode orientá-lo na configuração do OpenIddict. Ele pode explicar os registos DNS e a configuração SPF. O problema é que esse conhecimento está frequentemente desatualizado. As plataformas atualizam seus painéis, mudam as configurações, descontinuam recursos, renomeiam coisas. E o Claude não sabe.

Eu nem sequer utilizei apenas uma IA. Ocasionalmente, o ChatGPT sabia mais sobre serviços específicos, especialmente quando os dados de formação do Claude estavam alguns meses atrasados em relação à documentação de uma determinada plataforma. Em alguns dias, tinha os dois abertos lado a lado, cruzando as suas sugestões com o que estava a ver no painel de instrumentos.

Mas o ponto mais importante é este: para ter uma aplicação vendável, é absolutamente necessário saber como funciona o alojamento. Como funcionam os domínios. Como funcionam os certificados de assinatura de código. Como funcionam as bases de dados. Como funciona a capacidade de entrega de correio eletrónico. Como funcionam os fluxos OAuth2, e não apenas o código que os implementa. É possível criar um aplicativo sem esse conhecimento? Claro. Mas isso vai levá-lo a algum lado? É provável que não. Terá algo que corre em localhost e não impressiona ninguém fora da sua própria máquina.

Os 80% que pareciam mágicos

Deixe-me ser claro sobre o que funcionou, porque realmente funcionou bem. Para produzir interfaces de serviço, implementar controladores CRUD, escrever configurações EF Core e construir componentes Vue, Claude é absurdamente rápido.

Aqui está um exemplo. Quando precisei adicionar o sistema de gerenciamento de glossário, descrevi o requisito: glossários com escopo de locatário, importação/exportação de CSV, CRUD de termo individual e um mecanismo de sincronização com a API de glossário do DeepL. Claude produziu os modelos de entidade, a interface e implementação do serviço, o controlador com atributos de autorização adequados e o armazenamento Pinia. Tudo em cerca de 20 minutos. Ter-me-ia levado quase um dia para escrever tudo isso à mão.

O motor de tradução foi semelhante. A arquitetura ao nível do bloco com hashing de conteúdo SHA256, a deteção de staleness, o orquestrador que coordena entre serviços. O Claude compreendeu o padrão depois de eu o ter explicado uma vez e depois o ter replicado de forma consistente em dezenas de ficheiros. O sistema de pontuação de frescura, os fluxos de trabalho de revisão, o pipeline de notificação de expiração. Serviço após serviço, ligado e a funcionar.

Para o sítio de marketing, Claude construiu páginas HTML inteiras a partir de descrições. "Uma página de preços com um nível gratuito, um nível de equipa e um nível de empresa. Fundo escuro. Use o acento verde." E simplesmente... produziu uma. Incluindo pontos de interrupção responsivos e estados de foco.

Essa é a parte mágica. É real.

Domando a máquina

Mas não é como se eu tivesse simplesmente digitado "construa-me uma aplicação" e ido embora. Trabalhar com o Claude é uma habilidade própria, e passei os primeiros dias a fazê-lo mal.

O resultado inicial é sempre... bom. Tecnicamente correto, razoavelmente estruturado, mas genérico. O Claude escreve código da mesma forma que escreve prosa: competente, previsível e profundamente mediano. Deixado à sua própria sorte, ele produzirá a mesma estrutura de controlador que todos os tutoriais de frameworks usam. O mesmo padrão de serviço. O mesmo layout de componentes. Funciona, mas não é seu.

Então você começa a treiná-lo. Não formalmente, não com ajustes finos, mas através de repetição e correção. "Não, eu quero a interface de serviço separada da implementação." "Utilize sempre este padrão de atributo de autorização." "O contexto do locatário vem do middleware, não do corpo do pedido." Volta após volta após volta. Alguns dias senti-me como se estivesse a programar em pares com um júnior muito entusiasmado que se esquece sempre do que decidimos ontem.

E depois algo faz clique. Depois de correcções suficientes, depois de exemplos suficientes na base de código para ele ler, o Claude começa a acertar à primeira tentativa. Ele pega suas convenções de nomenclatura. Ele sabe onde você coloca seus DTOs. Ele segue seu padrão de tratamento de erros sem ser solicitado. Essa transição de "irritante" para "produtivo" levou talvez quatro ou cinco dias de trabalho consistente.

Os posts do blogue foram uma história semelhante. A voz de escrita padrão do Claude é imediatamente reconhecível. Aquele estilo polido, ligeiramente distante e perfeitamente estruturado que se assemelha a todos os posts de blogue gerados por IA que já viu. Passei por várias rondas a construir um guia de estilo, dando-lhe exemplos de como eu realmente escrevo, apontando cada "vale a pena notar" e cada traço em (a sério, o vício do traço em é real). Acabei por criar um ficheiro de competências, um conjunto de instruções que o Claude carrega antes de escrever qualquer coisa para o blogue Rasepi.

Este post, para que fique registado, é do Claude. Com o meu contributo, as minhas correcções, a minha direção. Descrevi o que queria dizer, apontei para o guia de estilo e depois passei algum tempo a andar para trás e para a frente até a voz parecer correta. Esse é o fluxo de trabalho atual. Não é "a IA escreve-o" e não "eu escrevo-o". É uma conversa que produz algo que nenhum de nós teria escrito sozinho.

Também criei instruções personalizadas para a própria base de código. Um ficheiro de instruções do copiloto que explica a arquitetura, o sistema de tradução, as regras de isolamento dos inquilinos, as convenções de codificação. O Claude lê-o no início de cada sessão, e a diferença é noite e dia. Sem ele, o Claude adivinha. Com ele, o Claude sabe.

A questão é: os ganhos de produtividade são reais, mas não são gratuitos. É preciso investir tempo a ensinar à IA como se trabalha, e esse investimento compensa ao longo de semanas. Se saltar esse passo, passará mais tempo a corrigir os resultados do Claude do que passaria a escrever o código.

Depois é preciso implementar a coisa

É aqui que a história muda.

Você tem uma aplicação funcionando no localhost. Lindo. Agora coloque-a na Internet. Faça-o enviar e-mails. Deixe as pessoas se inscreverem. Aceite pagamentos eventualmente. Proteja-o de bots. Dê-lhe um nome de domínio que resolva corretamente.

O Claude não pode ajudar-te com nada disto. Nem por isso.

Não quero dizer que ele produz sugestões ruins. Quero dizer que, fundamentalmente, não pode interagir com os sistemas que precisa de configurar. E é na configuração que passa o seu tempo, não a escrever código.

Cloudflare: Um estudo de caso em "Descubra você mesmo"

O site de marketing da Rasepi é executado em Cloudflare Pages. A API da lista de espera é um Cloudflare Worker com um banco de dados D1. Parece simples até que se tenha de o configurar.

O Claude nunca viu o seu painel de controlo do Cloudflare. Ele pode dizer-lhe "adicionar um registo CNAME", mas não pode dizer-lhe qual dos 14 separadores contém as definições de DNS para o seu domínio específico. As ligações de bases de dados D1 precisam de um ID de base de dados específico no seu wrangler.toml. Os segredos de ambiente passam pelo wrangler secret put. CORS tem que corresponder às suas origens reais implantadas, não ao localhost. O Turnstile precisa de chaves de mais uma secção do dashboard.

Passei quase um dia inteiro fazendo o Worker verificar corretamente os tokens do Turnstile, aceitar submissões de formulários, armazená-los no D1 e enviar e-mails de confirmação. O Claude ajudou-me a escrever o código do Worker. Mas a implantação, a configuração do wrangler, o gerenciamento de segredos, a depuração da propagação do DNS? Isso foi tudo eu.

OAuth2: O Labirinto da Configuração

A autenticação é o melhor exemplo da lacuna entre "código" e "produto".

O Claude pode absolutamente escrever uma integração OAuth2. Ele conhece a especificação OIDC, pode produzir middleware, entende as declarações JWT. Para o nosso ambiente de desenvolvimento, tenho um DevAuthHandler que cria tokens com as declarações tenant_id e sub a partir de um padrão simples de cadeia de portadores. O Claude escreveu isso em minutos.

Mas autenticação de produção significa OpenIddict, e OpenIddict significa descobrir declarações sub, declarações tenant_id, URLs de retorno de chamada, origens de JavaScript, URIs de logout e todas as outras travessuras que vêm com uma configuração de identidade real. E isso antes mesmo de chegar aos provedores externos.

Porque os seus utilizadores querem iniciar sessão no Google, na Microsoft ou no GitHub. E o Claude não pode fazer login em nenhum desses consoles de desenvolvedor para você. Ele não pode:

Criar um aplicativo OAuth no Console do Google Cloud e gerar um ID e um segredo do cliente
Registrar um aplicativo no portal Microsoft Entra e configurar os URIs de redirecionamento
Configurar um aplicativo OAuth do GitHub e obter as credenciais
Configurar os URLs de retorno de chamada de cada provedor para cada ambiente que você executa
Ligar os âmbitos corretos, ecrãs de consentimento e pontos finais de token

Cada provedor tem seu próprio portal de desenvolvedor, sua própria terminologia, seu próprio fluxo para gerar credenciais. O Google chama-lhe um "ecrã de consentimento". A Microsoft chama-lhe "registos de aplicações". O GitHub chama-lhe "OAuth Apps" (não confundir com "GitHub Apps", que são uma coisa completamente diferente). E cada um deles exige que você copie manualmente um ID de cliente e um segredo na sua configuração.

Claude pode escrever a configuração do servidor OpenIddict, o middleware do provedor externo, a lógica de transformação da reivindicação. Mas a geração real de credenciais, a navegação no portal, a configuração do URL específico do ambiente? Isso é tudo seu, num navegador, clicando nos painéis.

E-mail: Nunca é só "enviar um e-mail"

O código para enviar um e-mail por meio da API de reenvio tem cerca de 15 linhas. O Claude escreveu-o sem problemas. Mas fazer com que os e-mails realmente cheguem à caixa de entrada de alguém? Isso requer um domínio de envio verificado, registos DNS para SPF, DKIM e DMARC, aguardar a propagação e, em seguida, testar a capacidade de entrega, porque o Gmail e o Outlook têm as suas próprias opiniões sobre se o seu domínio é de confiança.

E conceber um modelo de correio eletrónico que não tenha um aspeto horrível em todos os clientes de correio eletrónico. O Outlook no Windows ainda utiliza o motor de renderização do Word em 2026. Deixe que isto lhe chegue aos ouvidos.

A lista completa de coisas que eu fiz sem IA

Olhando para trás, para três semanas de trabalho, comecei a manter uma contagem mental aproximada do que Claude construiu versus o que eu configurei à mão. A lista "à mão" é maior do que eu esperava:

**Infraestrutura de nuvem

Configuração do projeto Cloudflare Pages e configuração do domínio personalizado
Implantação do Cloudflare Worker e provisionamento do banco de dados D1
Registos DNS para o site de marketing, API e envio de correio eletrónico
Configuração do certificado SSL/TLS (maioritariamente automático, mas a depuração quando não é é dolorosa)
Configuração do pipeline de construção para o blogue (Eleventy + tradução + geração de imagens OG)

**Autenticação e segurança

Registo de aplicações Google, Microsoft e GitHub OAuth e geração de credenciais
Configuração do OpenIddict com declarações corretas, URLs de retorno de chamada, origens JS e URIs de logout
Configuração da proteção de bots Turnstile (chaves do site, chaves secretas, configuração do dashboard)
Configuração da política CORS entre front-end, API e origens do trabalhador

Email:

Configuração da conta de reenvio e da chave da API
Registos DNS SPF, DKIM, DMARC
Teste de capacidade de entrega de correio eletrónico e resolução de problemas
Teste de modelos em clientes de correio eletrónico

Integrações de terceiros:

Gestão de contas e chaves da API DeepL
Configuração do Google Analytics com integração de consentimento de cookies

Alojamento no Azure:

Instalação e configuração do Serviço de Aplicações do Azure para o backend .NET
Provisionamento de bases de dados SQL do Azure, regras de firewall e cadeias de ligação
Configuração da Cache do Azure para Redis e configuração de ligação
Provisionamento de recursos do Azure OpenAI para embeddings e RAG

Implantação:

Configuração do Docker para o back-end .NET
Gestão de variáveis de ambiente em três alvos de implantação diferentes
Cadeias de ligação de bases de dados para diferentes ambientes

E, honestamente, estou provavelmente a esquecer-me de algumas coisas. Cada serviço de terceiros tem seu próprio painel de controle, seu próprio modelo de credenciais, sua própria qualidade de documentação (que varia muito) e suas próprias peculiaridades.

Por que isso é mais importante do que as pessoas pensam

Aqui está a dimensão que se perde em todas as conversas sobre desenvolvimento assistido por IA: **As ferramentas de IA não têm nenhum contexto sobre sua infraestrutura.

Sua base de código vive em arquivos que uma IA pode ler. Sua configuração do Cloudflare não. Suas configurações de aplicativo do Google OAuth não. Os seus registos DNS não o fazem. O estado de verificação do seu domínio Resend não o faz. Toda a área de superfície operacional de um produto real é invisível para as ferramentas de IA, e essa área é enorme.

Escrever código é a parte fácil da engenharia de software, e está a ficar cada vez mais fácil. A parte mais difícil é o que se faz com esse código. Operá-lo, compreendê-lo quando algo se avaria às duas da manhã, alargá-lo quando os requisitos mudam e geri-lo ao longo de todo o seu ciclo de vida. A IA torna a parte fácil mais rápida. Não faz nada pela parte difícil.

O site de marketing merece a sua própria secção

Construí todo o site de marketing do Rasepi em cerca de quatro dias. Homepage, página de preços, formulários de inscrição e contacto com proteção de bots, política de privacidade, quatro páginas de aprofundamento de funcionalidades. O Claude fez provavelmente 70% do HTML/CSS.

Mas depois precisei que o blogue existisse de facto na Internet. O blogue é executado no Eleventy com um pipeline de construção de 8 passos: traduzir posts através de DeepL, construir o site, traduzir páginas HTML estáticas, copiar recursos partilhados, gerar imagens OG a partir de SVGs, gerar versões áudio, gerir manifestos áudio, produzir um mapa do site multilingue. O Claude ajudou a escrever partes desse pipeline, mas fazer com que tudo funcionasse em conjunto com os caminhos de ficheiro corretos e as definições corretas de implementação das Páginas Cloudflare levou um dia inteiro de tentativa e erro.

E o site de documentação do desenvolvedor? É um projeto separado do Cloudflare Pages com o seu próprio domínio, a sua própria configuração de compilação e os seus próprios accionadores de implementação. Outro painel de controlo, outro conjunto de variáveis de ambiente, outra ronda de DNS.

O padrão que estou sempre a ver

Para qualquer recurso, o Claude lida com cerca de 80% do trabalho por volume. Linhas de código, ficheiros criados, problemas resolvidos. Mas os 20% restantes são trabalho de configuração totalmente manual: clicar em painéis da Web, copiar chaves entre serviços, depurar problemas de integração que só aparecem em ambientes implantados.

E esses 20% demoram pelo menos tanto tempo como os outros 80%. Por vezes, mais tempo.

Mas eis o que mudou em comparação com a forma como o desenvolvimento a solo costumava funcionar: no passado, ou se escrevia código ou se fazia a configuração. Nunca as duas coisas. Se passava um dia a configurar webhooks do Stripe e a testar fluxos de pagamento no painel de controlo, esse era um dia em que não escrevia código de aplicação. O seu projeto deixava de avançar numa frente enquanto trabalhava na outra.

Com o Claude, isso não é mais verdade. Enquanto eu estava no painel do Stripe a descobrir os pontos finais dos webhooks e os tipos de eventos, o Claude estava a construir a próxima interface de serviço. Enquanto eu estava a clicar pela terceira vez na configuração do ecrã de consentimento OAuth do Google porque me enganei nos âmbitos, o Claude estava a escrever componentes Vue. A minha cabeça estava na terra das configurações, mas a base de código continuava a crescer. Isso é genuinamente novo. Um programador a solo pode agora trabalhar em duas frentes ao mesmo tempo, e essa pode ser a maior diferença prática que a IA faz para as pequenas equipas.

Dito isto, quando se está a escrever código com a ajuda da IA, está-se num ciclo de feedback apertado. Escrever, testar, corrigir, iterar. Quando você está depurando por que seu Cloudflare Worker retorna erros de CORS apenas na produção, você está olhando para capturas de tela do painel, lendo postagens de fóruns da comunidade e tentando alterações de configuração aleatórias na esperança de que uma delas se mantenha.

O que precisa ser mudado

Não acho que essa seja uma limitação permanente. A peça que falta é óbvia: as ferramentas de IA precisam de ser capazes de interagir com APIs de serviços e dashboards de terceiros. Não apenas escrever código que os chame, mas realmente configurá-los.

Algumas destas coisas estão a começar a acontecer. Estão a surgir servidores MCP (Model Context Protocol) para vários serviços. O Anthropic está claramente a pensar na utilização de ferramentas como um conceito de primeira classe. Mas não estamos nem perto do ponto em que eu poderia dizer "configure meu Cloudflare Worker com um banco de dados D1, configure o domínio personalizado e adicione a proteção Turnstile" e isso realmente aconteceria.

Até lá, a história honesta da construção de um produto com IA é esta: A IA é um acelerador incrível para escrever código de aplicação. Mas um produto vendável é apenas metade do código da aplicação. A outra metade é a infraestrutura, as integrações de terceiros, os pipelines de implementação, a capacidade de entrega de correio eletrónico, a configuração do domínio e a configuração da segurança. E para tudo isso, está por sua conta.

(Esta é, aliás, uma das razões pelas quais estamos a construir o Rasepi como uma plataforma alojada e não apenas a enviar código-fonte aberto. Fazer com que o software de documentação funcione não é assim tão difícil. Conseguir que funcione de forma fiável, com autenticação, e-mail e alojamento adequados? Esse é o produto).

Se estás prestes a tentar isto

Algumas coisas práticas que aprendi e que podem poupar-lhe tempo:

Comece com a infraestrutura, não com o código. Configure sua hospedagem, seu provedor de autenticação, seu serviço de e-mail e seus domínios personalizados primeiro. Coloque um "hello world" em produção antes de escrever uma única linha de código de aplicação real. O número de problemas que só aparecem em ambientes implantados é deprimente.
Você terá chaves de API, IDs de cliente, URLs de retorno de chamada, IDs de banco de dados e chaves secretas espalhadas por 8 painéis diferentes. Eu utilizo um ficheiro encriptado local. Você pode usar 1Password ou qualquer outra coisa. Basta ter um único local.
Se o Claude o ajudar a criar o recurso em 2 horas, reserve no mínimo mais 2 horas para implantá-lo, configurar as integrações e testar na produção.
Houve dias inteiros em que escrevi essencialmente zero código, mas fiz progressos críticos: registar aplicações OAuth em três fornecedores, configurar o correio eletrónico, depurar o DNS. Esses dias parecem menos produtivos, mas não são.

Três semanas ainda é muito rápido para o que eu construí. Não me estou a queixar do Claude. Permitiu a um único programador construir algo que normalmente levaria a uma pequena equipa a maior parte de um ano. Mas a história que está a ser contada no ciclo de entusiasmo da IA (prompt, code, ship, done) não tem toda a secção intermédia onde se torna real.

A aplicação é a parte fácil. Torná-la real é que é o trabalho.