OS 2 LUGARES ONDE USO I.A.
E o processo que segura cada um.
Quando comecei a usar I.A. pra programar, perdi muito tempo.
Não foi o modelo errado. Não foi prompt mal feito. Foi tamanho de issue.
Eu abria a I.A. e pedia coisas pequenas demais. Issues recortadas em pedaços que não se conectavam direito, e eu ia ali, juntando manualmente o que ela me devolvia. Quando cansava disso, virava pro outro extremo: pedia issues gigantes, com detalhes errados ou faltando. A I.A. entregava. Eu fazia uma revisão por cima, achava que tava certo, e dias depois descobria que metade tinha ido em outra direção.
Os dois jeitos me custaram tempo e dinheiro. E o que eu aprendi não foi sobre a I.A. Foi sobre mim. Eu não tinha controle do que tava sendo entregue.
Aí eu ajustei. Parei de pedir antes de saber o que era pra pedir. Construí um processo que decide o tamanho da issue antes da I.A. abrir a boca, e que revisa o que ela devolve antes de qualquer merge.
Esse processo tem dois lugares. O primeiro é antes do código. O segundo é depois.
POR QUE PROCESSO
A pergunta mais comum que me fazem é qual I.A. eu uso.
É a pergunta errada. Quem responde "modelo X" tá vendendo a ideia de que ferramenta nova resolve sozinha. Não resolve. Eu já troquei de modelo várias vezes nos últimos 12 meses, e a curva de produtividade não foi marcada por upgrade de ferramenta. Foi marcada por mudança de processo.
A crença por trás da pergunta errada é a fórmula mágica: alguém em algum lugar liberou a I.A. que resolve tudo. Não tem. O que resolve é o que vem antes e o que vem depois do código.
Daí os dois lugares.
PLANEJAMENTO — ANTES DO CÓDIGO
Antes da I.A. escrever uma linha, eu valido três coisas com ela.
Arquitetura aguenta o que vou pedir. MVP entrega o ponto sem inflar. Plano respeita o risco do que pode dar errado.
Não são checks burocráticos. São perguntas que separam o feature que vai durar do feature que vai precisar ser refeito daqui a duas semanas. Uso a I.A. nessa parte da mesma forma que usaria um colega sênior: discuto a estrutura antes de bater a mão no editor.
O efeito disso na entrega é o que importa. A issue que chega na fase de execução já está dimensionada. Eu sei o que vai sair dela, e sei o que NÃO vai sair dela. Sem isso, a I.A. só produz mais rápido pra você refazer mais cedo.
CÓDIGO — I.A. ESCREVE, EU REVISO
Quando a issue tá bem dimensionada, a I.A. escreve.
Mas não merge nada sozinha. Trato ela como dev júnior bom: produtiva, rápida, sem contexto histórico. Júnior bom não faz merge sem code review. A I.A. não é exceção.
Meu pipeline é simples: issue, PR, CR, release, deploy.
O ponto de virada é o CR. É onde o humano entra de volta. Eu leio o que ela escreveu, comparo com o plano que validei antes, e decido se vai. Se não vai, volta. Se vai, segue. Não importa quantos benchmarks aquele modelo quebrou esse mês.
Sem CR, não é processo. É roleta.
O FIO CONDUTOR
Olhando os dois lugares juntos, é a mesma coisa. Eu decido o que entra, eu decido o que sai. A I.A. faz o trabalho no meio.
Quem só fica no meio depende de sorte. Sorte de o prompt ter pegado bem, sorte de o modelo ter acertado, sorte da entrega bater com o que o cliente queria. Sorte, como base de carreira, é frágil.
A pergunta não é qual I.A.
A pergunta é:
» Você tem bons processos, ou tá só torcendo pra dar certo?
Se você programa com I.A. e ainda tá no meio sozinho, manda esse texto pra outro dev que precisa ler.
Processo bom resolve mais do que a I.A. nova. Sempre resolveu.