IA no fluxo de desenvolvimento solo em 2026: o que funciona, o que não

Em 2024 eu tinha um Cursor instalado e quase não usava. Em 2025 passei a usar diariamente, mas com desconfiança — boa parte das sugestões era ruim. Em 2026, IA virou parte central do meu fluxo de dev solo. Não substituiu nada. Adicionou uma camada nova.

Esse post é sobre como integrei IA no dia-a-dia, onde ela paga, onde ela atrapalha, e a régua que aprendi a aplicar.

O fluxo que tenho hoje

A combinação que me funciona em projeto pessoal:

• Claude Code ou Cursor como par de programação principal
• GitHub Copilot desligado (acabou virando ruído pra mim)
• ChatGPT/Claude no browser para arquitetura e brainstorm de modelagem
• Linguagens-alvo: TypeScript, Swift, Python ocasional, SQL ocasional

A regra primária: IA é par, não autopilot. Eu reviso linha a linha o que ela escreve. Se eu não entendo o código que ela gerou, eu não comito.

Onde IA me acelera de verdade

Quatro casos onde o ganho é real:

1. Boilerplate previsível. Forms com 10 campos, mapeamento Zod ↔ TypeScript, criação de migrations Drizzle a partir de um schema, escrita de funções utilitárias clássicas (date formatters, parseadores de CSV). Esse tipo de código é repetitivo, tem padrão claro, e eu acerto na primeira em 90% dos casos com a IA.

2. Tradução entre linguagens/formatos. "Pega esse JSON e me dá o tipo TypeScript correspondente." "Converte essa função Python para Swift." "Esse SQL — me escreve em Drizzle." São transformações onde o input e o output são bem definidos, e a IA é cirúrgica.

3. Pesquisar API alheia que eu não conheço. Em vez de abrir 10 abas de docs do Stripe, abro o chat e pergunto: "como crio um Checkout Session com line items dinâmicos?". Em segundos tenho o código de exemplo, e eu adapto. Isso me poupou semanas acumuladas em 12 meses.

4. Refatoração mecânica. "Renomeia todas as ocorrências de userPreferences para settings, mas só dentro de src/app/admin." "Extrai esse bloco em uma função." "Inverte a condição desse if." São transformações com escopo claro e baixo risco. IA faz mais rápido que eu na unha.

Onde IA me atrapalha

Seis casos onde aceitar a sugestão sem checar machucou:

1. Hallucinação de API. A IA inventa funções que não existem em uma biblioteca, ou usa uma versão antiga. Quando você compila, falha — mas só se você compilar. Em código que não compila imediato (como migrations SQL ou config de infra), o erro pode entrar em produção.

Régua: sempre checar nome de função, assinatura e parâmetros contra a doc oficial. Não confiar na memória da IA, principalmente para libs de nicho.

2. Decisões arquiteturais. "Como eu deveria estruturar esse SaaS?" — a resposta da IA é sempre genérica, sempre alguma variação de "Next.js + Postgres + Stripe + Clerk". Pode até ser certa, mas é a mesma resposta para todos. Não substitui pensar.

Régua: decisões de arquitetura eu tomo, IA não. Posso usar IA pra discutir trade-offs, mas nunca para escolher por mim.

3. Código que parece certo mas tem bug sutil. Off-by-one, condição invertida, edge case de null ignorado. A IA escreve código que passa nos testes felizes mas falha em casos extremos. Tipo if (array.length > 0) quando o certo era >= 0 para uma operação que precisa rodar mesmo com array vazio.

Régua: escrever testes antes de aceitar código não-trivial. Se vai ter lógica de cálculo, vou ter caso de teste. IA pode até gerar os testes, mas eu reviso os cenários.

4. Soluções "demais inteligentes". A IA adora usar generics complexos, types condicionais, mapped types em TypeScript. O resultado é código que funciona mas é incompreensível em 3 meses. Em projeto solo, o leitor futuro sou eu, e eu não vou querer decifrar T extends infer U ? K extends keyof U : never.

Régua: se a sugestão usa feature avançada de tipo, eu escolho a versão mais simples mesmo que verbosa. "Boring code wins."

5. Refatorações grandes em um turno só. "Refatora esse arquivo de 400 linhas pra dividir em 4 arquivos." A IA faz, mas no caminho ela frequentemente muda comportamento sem avisar. Funções renomeadas, defaults mudados, edge case removido. Sem testes pra capturar, vira regressão silenciosa.

Régua: refatorações grandes eu faço em passos pequenos, com a IA assistindo um passo de cada vez. Não confio em "faz tudo de uma vez".

6. Código de domínio específico. Lógica de cálculo financeiro, regras de torneio, modelo de previdência — onde o conhecimento de domínio importa mais que o de programação. A IA não sabe que VGBL e PGBL têm tributação diferente no resgate. Ela infere, e às vezes erra silenciosamente.

Régua: código de domínio é eu quem escreve. IA pode formatar, comentar, escrever testes. Mas a lógica é minha.

A régua de quando aceito

Combinando tudo que aprendi, hoje minha régua é:

Aceito sem reler com cuidado quando:

• É boilerplate previsível (form, mapeamento, util clássico)
• O escopo é minúsculo (1-3 linhas)
• Vai ser pego pelo compilador imediato

Aceito relendo linha por linha quando:

• É lógica de negócio mas em padrão que conheço
• É refatoração mecânica não-trivial
• Usa biblioteca que eu conheço

Recuso ou reescrevo quando:

• É lógica de domínio que precisa de conhecimento específico
• A solução parece "engenhosa demais"
• Toca código com efeito colateral perigoso (delete, update, network call não-idempotente)
• Toca arquivo crítico (auth, payments, schema do banco)

A categoria do meio — aceitar relendo — é onde a maior parte do valor mora. É o que faz IA pagar.

A pergunta de produtividade

Estou mais produtivo? Sim, mas não no fator que se vende.

Onde melhorou:

• Boilerplate desaparece — escrita de form mudou de 30 minutos pra 5
• Aprendizado de API nova — onboard em lib desconhecida muito mais rápido
• Refatoração mecânica — saí de "boring chore" pra "comando rápido"
• Documentação — escrever README, JSDoc, comentário não-óbvio

Onde não melhorou tanto quanto se vende:

• Pensar no problema continua igual
• Modelar o domínio continua igual
• Decidir arquitetura continua igual
• Debugar bug obscuro continua igual (às vezes piora — IA dá pista falsa)

Estimativa minha: 30-40% mais rápido em projetos novos, talvez 15% em manutenção de código existente. Não é o "10x" que se prega, mas é real e significativo.

O que mudou no meu fluxo

Algumas coisas que IA mudou em como eu trabalho:

1. Escrever testes primeiro virou hábito. Quando IA pode gerar implementação a partir de teste, ter teste antes vira investimento mais óbvio.
2. Documentação nasceu mais cedo. README do projeto, comentário em função não-óbvia, JSDoc — tudo escrevo antes, porque é conversa direta com IA depois.
3. Sou menos preguiçoso com convenções. Antes eu tolerava arquivo bagunçado. Hoje é "se eu não conseguir ler, IA também não" — então organizo.
4. Rejeito código mais rápido. Quando vejo que a IA está empurrando solução errada por dois turnos seguidos, mudo de abordagem em vez de insistir. Tempo de "burrice acumulada" diminuiu.

A coisa que não mudou

Ainda tenho que entender o sistema que estou construindo. IA não substitui isso.

Em projeto pessoal, eu sou o arquiteto, o dono do produto, o tester e o operador. IA me ajuda a digitar, mas a responsabilidade pelo que está em produção é minha.

A IA não vai me ligar às 3 da manhã quando o app cair. Eu sei que ela me deu 80% do código — mas o débito técnico, o bug, e o user impact são meus. Essa lembrança me mantém com o pé no chão na hora de aceitar uma sugestão.

Se você está começando a usar IA no dev em 2026, o conselho que dou: não tenta ser autopilot. Use como par. Reveja tudo. Confie nos seus instintos quando o código gerado "cheira mal" — geralmente cheira mesmo.