Como usar IA pra acelerar o desenvolvimento de software

LLMs são a ferramenta que mais aumentou minha produtividade desde o lançamento do Cursor. Hoje, explico todos os casos onde são relevantes pra mim e como exatamente faço para usá-las.

Há um tempo, um amigo desenvolvedor me viu criando uma projetos relativamente complexos rapidamente usando o Cursor. Ele ficou chocado: "Como você fez isso tão rápido?"

A resposta: saber conversar com a IA do jeito certo.

Se você já tentou usar Cursor, Windsurf ou outros editores AI e ficou frustrado com respostas genéricas ou código que não funciona, este artigo é pra você. Vou compartilhar exatamente como transformo essas ferramentas em verdadeiros parceiros de programação.

Um detalhe crucial antes de começar: sempre faça seus prompts em inglês. Por quê? Os modelos foram treinados principalmente em inglês. Quando você usa português, eles "traduzem" internamente, gastando tokens extras e gerando respostas menos precisas. É como pedir para alguém pensar em português e responder em mandarim - funciona, mas não é o ideal.

✨ O que esperar do artigo

• As 5 situações onde editores AI mais aceleram seu trabalho (com exemplos práticos)

• A técnica do "Plan then Execute" que dobra a qualidade das respostas

• Como transformar a IA em seu parceiro para decisões técnicas

Criando features novas: dominando o "Plan then Execute"

Exemplo real: implementei um sistema de pagamento único pro site do Dev na Gringa.

A maioria das pessoas pediria direto: "Create a payment system with Stripe". O resultado? Código genérico que você vai refatorar por horas.

Vou mostrar como fiz diferente.

Por que planejar primeiro faz toda diferença

Quando você pede código direto, a IA tem que tomar dezenas de micro-decisões enquanto escreve. Ela escolhe estruturas de dados, padrões de código e arquitetura "on the fly". O resultado? Código funcional mas não necessariamente bem pensado.

Ao separar planejamento de execução, você força a IA a:

• Pensar na arquitetura antes de codificar

• Considerar edge cases antecipadamente

• Propor uma estrutura coerente

• Identificar dependências e integrações necessárias

Exemplo real: Sistema de pagamento único para conteúdo

❌ O que a maioria faria:

"Create a one-time payment system for my Next.js site using Stripe"

Resultado típico: Um checkout básico do Stripe sem considerar gerenciamento de acesso, integração com sistema existente, ou expansibilidade futura.

✅ Como eu fiz com "Plan then Execute":

Passo 1 - Compartilhando o contexto e pedindo um plano:

Let's not do any code for now. I want you to help me plan something.  
I need to implement a one-time payment system for content access. Here's my PRD summary:

I want to release a book in my website, which will be formed by many markdown pages. This book will be available to those who are paid subscribers, or the who will make a one-time payment. For the one-time payment, we'll need to support both PIX payments (brazilian instant transfer), and normal credit card with Stripe. 

Current setup:
- Next.js 15 with App Router
- Convex for database
- Already have Substack integration for subscribers
- MDX content structure in place

Create a detailed implementation plan (NO CODE YET) covering:
1. Database schema for purchases and access control
2. Stripe integration architecture
3. How to merge this with existing Substack subscriber checks
4. Access control logic for both systems
5. Future extensibility for credit-based products
6. Security considerations

A IA respondeu com um plano detalhado:

## One-Time Payment System Implementation Plan

### 1. Database Schema Design

#### New Tables:
- `purchases`
  - id (uuid)
  - user_id (references users)
  - product_id (string) 
  - product_type (enum: 'book', 'ai_credits', 'course')
  - stripe_payment_intent_id
  - amount (integer - cents)
  - status (enum: 'pending', 'completed', 'failed', 'refunded')
  - metadata (jsonb)
  - created_at, updated_at

- `products`  
  - id (string - slug)
  - name
  - price_cents
  - type (enum: 'one_time', 'credit_pack')
  - active (boolean)
  - metadata (jsonb - for future fields)

- `access_tokens` (for unified access checking)
  - user_id
  - resource_type ('book', 'ai_service')
  - resource_id
  - access_type ('subscription', 'purchase', 'credit')
  - expires_at (nullable)
  - source ('substack', 'stripe', 'manual')

### 2. Stripe Integration Architecture

[... plano continua com diagramas e fluxos ...]

Perceba como o plano considera arquitetura, não só código. Isso é crucial.

Passo 2 - Refinando aspectos críticos:

Great plan! Let's clarify some critical points:

1. For the access_tokens table - should we handle the case where a user has BOTH Substack subscription AND purchased the book? Which takes precedence?

2. What happens if a Substack subscriber cancels but previously purchased content?

3. For the checkout flow - should we support both logged-in and guest checkout?

A IA iterou no plano, adicionando lógica para casos edge que eu nem tinha pensado.

Passo 3 - Criando a especificação técnica:

Based on our refined plan, create a technical spec file (payment-system.spec.md) that includes:
- API endpoints needed with request/response examples
- Detailed user flows (with error states)
- Integration points with existing code
- Migration strategy for existing Substack-only users

Isso gerou uma spec de 300+ linhas que virou a referência pra toda implementação.

Passo 4 - Implementação incremental:

Perfect spec. Let's implement this incrementally. Our checkpoints:

1. Database schema and models
2. Stripe webhook handlers  
3. Purchase API endpoints
4. Access control middleware
5. Frontend checkout flow
6. Migration scripts

Start with checkpoint 1 - create the Convex schema based on our plan.

O poder dos checkpoints com validação

Após cada checkpoint, eu validava:

Checkpoint 1 complete. Before moving to checkpoint 2:
- Review the schema for any missing indexes
- Confirm it handles all the edge cases we discussed
- Suggest any optimizations for query performance

Isso garantiu que cada parte estava sólida antes de continuar.

Técnica avançada: Prompts de implementação contextualizados

Com o plano em mãos, cada prompt de implementação ficou cirúrgico:

Implement the Purchases feature based on our spec.
Key requirements from our plan:
- Include idempotency for Stripe webhooks  
- Handle the multi-source access we discussed
- Use the error codes we defined in section 3.2

Follow our existing service pattern (example attached).

A IA tinha todo contexto necessário pra gerar código alinhado com a arquitetura.

Por que isso muda o jogo

• Menos surpresas: Todos os edge cases foram pensados ANTES de escrever código

• Código coeso: Cada parte foi implementada sabendo como se conecta ao todo

• Documentação grátis: A spec virou documentação técnica do sistema

• Revisão mais fácil: Pude compartilhar o plano com outros devs antes de implementar

O plan-then-execute não é só uma técnica - é uma mudança de mentalidade. Você para de usar a IA como "autocompletar glorificado" e começa a usá-la como um verdadeiro parceiro de arquitetura.

Usando IA como parceiro para decisões de arquitetura

Use a IA pra validar ideias antes de implementar. É como ter um arquiteto de software disponível 24/7.

Técnica: Faça a IA te questionar

I need to design a real-time notification system for our app. 
Requirements:
- 10k concurrent users
- Notifications for: mentions, likes, system alerts
- Must work on web and mobile

Ask me questions ONE AT A TIME to better understand the requirements. 
Prefer yes/no questions when possible.

O modelo irá fazer perguntas como:

• "Do notifications need to persist if user is offline?"

• "Is there a priority system for different notification types?"

• "Should users be able to customize what notifications they receive?"

Cada resposta sua refina o entendimento. No final, peça:

Based on our discussion, create a technical design document (design_doc.md) with:
- Architecture overview
- Technology choices with justifications  
- Implementation phases
- Potential challenges and solutions

Resultado: Um design doc completo que você pode compartilhar com o time ou usar como guia de implementação.

Entendendo codebases novas: seu guia turístico pessoal

Entrar numa codebase nova é como explorar uma cidade desconhecida sem mapa. A IA pode ser seu guia.

Abordagem sistemática:

I'm new to this codebase. Help me understand the architecture by:
1. Analyzing the folder structure and explaining the organization pattern
2. Identifying the main entry points
3. Mapping the data flow for the main user journey: [describe specific flow]
4. Highlighting any unusual patterns or potential tech debt

Start with point 1. Here's the folder structure: [paste]

Para entender código específico:

Explain this function like I'm a mid-level developer who understands React but is new to this codebase:
[paste function]

Focus on:
- What problem it solves
- Why it's implemented this way
- Any implicit assumptions or side effects
- How it fits in the larger system

A chave: Seja específico sobre seu nível de conhecimento. Isso evita explicações muito básicas ou muito avançadas.

Debugging: transforme a IA em Sherlock Holmes

Debugging com IA é uma arte. O segredo é dar contexto suficiente pra ela raciocinar.

❌ Prompt ruim:

"This function doesn't work, fix it"

✅ Prompt investigativo:

My React component is causing infinite re-renders. Here's the code:

[paste component code]

Expected: Fetch user data once when userId changes
Actual: Component re-renders infinitely
Error: "Maximum update depth exceeded"

Walk through the code execution step-by-step and identify where the render loop happens.

Técnica avançada: Múltiplas hipóteses

This API endpoint returns 500 intermittently. Here's the code: [paste]

Give me 3 potential causes ranked by likelihood, considering:
- It works 70% of the time
- Errors happen more during high traffic
- Logs show "connection timeout" occasionally

A IA vai analisar e sugerir causas como pool de conexões, rate limiting, ou timeouts mal configurados.

Resolveu o erro? Não esqueça da dica do livro Pragmatic Programmer: um bug deve acontecer apenas uma vez. Escreva testes que ele nunca mais aconteça. O que nos leva a próxima sessão.

Refatoração e testes: o mordomo do código limpo

Testes e refatorações devem ser um dos casos que eu mais uso no dia a dia. LLMs são particularmente boa em reformular e criar coisas a partir de algo que já existe.

Além disso, devido ao imenso conhecimento dentro delas, é possível pedir por virtualmente qualquer padrão que você seja familiarizado.

Vamos aos prompts.

Para refatoração:

Refactor this function with these specific goals:
1. Extract duplicate logic into helper functions
2. Improve variable names for clarity
3. Add proper TypeScript types
4. Maintain the exact same behavior

The current code is attached on the context.

Explain each change and why it improves the code.

Para testes:

Generate comprehensive tests for this function: [paste code]

Include:
- Happy path cases
- Edge cases (empty inputs, nulls, extreme values)
- Error scenarios
- A describe block for each logical group

Use Jest and React Testing Library. Follow AAA pattern (Arrange, Act, Assert).

⭐ Dica de ouro: Depois que a IA gerar os testes, peça:

What other test cases might I be missing? Consider security, performance, and integration concerns.

Outras técnicas relevantes

1. Crie artefatos para a IA usar

Para tarefas grandes, faça a IA criar arquivos de apoio:

We need to migrate from Enzyme to React Testing Library. 

First, create two files:
1. migration_checklist.md - list all files that need migration
2. patterns_guide.md - common patterns and their RTL equivalents

Update these files as we progress through the migration.

2. Use exemplos do seu próprio código

Here's how we typically structure our API endpoints: [paste example]

Now create a new endpoint for user preferences following the same patterns.

A IA vai manter consistência com seu estilo.

3. Iteração rápida com contexto

Numa sessão de chat, você pode refinar continuamente:

• "Good, but make the error handling more specific"

• "Now add logging using our Winston setup"

• "Extract the validation into a separate middleware"

Cada iteração melhora o código sem precisar repetir todo o contexto.

Limitações e quando NÃO usar IA

Evite usar IA para:

• Código sensível/proprietário - Nunca compartilhe segredos, chaves de API ou lógica proprietária crítica

• Lógica de negócio complexa sem supervisão - A IA pode não entender nuances do seu domínio específico

• Quando o contexto é complexo demais - Se você precisa explicar 10 arquivos diferentes, talvez seja melhor resolver manualmente. Especialmente se você estiver no meio de um incidente em produção 😅

Use com cuidado em:

• Código de segurança - Sempre revise minuciosamente

• Algoritmos de performance crítica - A IA pode não otimizar para seu caso específico

• Integrações com sistemas legados - A IA pode sugerir padrões modernos incompatíveis

Cheat Sheet: Plan → Execute → Validate → Iterate

Para cada situação:

🐛 Debugging:

• Contexto: código + erro + comportamento esperado

• Pergunte: "Walk through step-by-step"

• Extra: "Give me 3 potential causes"

🏗️ Arquitetura:

• Comece com: "Ask me questions to understand requirements"

• Depois: "Create a design doc with trade-offs"

• Valide: "What could go wrong with this approach?"

✨ Features novas:

• Plan: "Create implementation plan (NO CODE YET)"

• Execute: "Implement checkpoint 1 based on our plan"

• Validate: "Review for edge cases we discussed"

🔧 Refatoração:

• Seja específico: "Improve readability and reduce duplication"

• Peça explicações: "Explain why each change improves the code"

• Mantenha comportamento: "Ensure exact same functionality"

🧪 Testes:

• Comece com: "Generate comprehensive tests including edge cases"

• Depois pergunte: "What test cases am I missing?"

• Considere: "Add tests for security and performance"

Para você que é assinante pago, veja também o novo documento Prompts para Engenheiros de Software. Compilei todos os prompts do artigo e mais alguns que estou sempre usando.

🌟 Resumo

• Use o método "Plan then Execute": Sempre peça um plano antes do código. Isso melhora drasticamente a qualidade

• Dê papéis específicos à IA: "Think like a senior engineer" carrega anos de boas práticas pro contexto

• Para debugging, forneça o trio sagrado: código + erro + comportamento esperado

• Faça a IA te questionar: Para arquitetura e features complexas, deixe ela guiar a descoberta de requisitos

• Sempre em inglês: Os modelos funcionam melhor na língua em que foram treinados

Lembre-se: a IA é como um desenvolvedor júnior muito inteligente mas literal. Quanto mais contexto e direção você der, melhores serão os resultados.

Essas técnicas transformaram completamente minha produtividade. Features que levavam dias agora saem em horas. Bugs que me travavam por dias são resolvidos em horas.

E o melhor? Você não precisa ser um "prompt engineer" profissional. Basta seguir esses padrões e iterar. Com o tempo, vai virar segunda natureza. Aos poucos, vamos desenvolvendo certa intuição sobre isso.

Eu tentei, nesse artigo, passar tudo que eu aprendi desde que comecei a usar essas ferramentas. Mas o melhor que você pode fazer ainda é testar você mesmo. Apenas ler não será suficiente.

Aqui uma sugestão pra você: Escolha uma feature pequena do seu projeto e tente o método Plan then Execute hoje mesmo. Compartilhe seus resultados no Discord da comunidade ou nos comentários aqui.

📚 Referências e leituras adicionais

• AI Engineering: Building Applications with Foundation Models. Especificamente o capítulo 5 Prompt Engineering

• The Prompt Engineering Playbook for Programmers

• Claude 4 prompt engineering best practices. Esse é o guia da Anthropic pois os modelos que mais uso são do Claude. Se você usa a família do OpenAI ou Google, use o guia deles

---

Fico feliz que você leu o artigo até o final! 🙏

Você também pode clicar no botão de curtir ❤️ e compartilhar este artigo com outras pessoas que se interessem. Me ajuda muito!