No mundo do desenvolvimento de software, existe um meme que nos persegue há décadas: a Dicotomia Pastel-Projeto.

Usamos essa metáfora para explicar aos clientes mais ansiosos que contratar nosso trabalho não é como comprar um pastel na feira.

Pense no pastel. Você entra na pastelaria ou barraquinha, pede pastel, paga barato, escolhe o recheio e recebe na hora. Tem pastel de carne, de queijo, de pizza, de frango com catupiry. Parece que tem muita variedade, mas no fundo é a mesma plataforma: massa, óleo quente, velocidade e satisfação imediata.

Não é assim que fazemos software, certo? CERTO?

Fazer software é trabalhoso, caro, complexo e leva muito tempo. Não é só chegar, pedir, pagar e receber.

Bem, pelo menos essa era a certeza até ontem. Hoje, o problema é outro: e quando a geração de código se torna tão rápida, barata e fácil que o "fritar pastel" passa a ser uma opção real para muitos casos?

Será que a IA pastelizou o desenvolvimento de software?

---

A IA criou a pastelaria do software

Ferramentas como Lovable, v0, Bolt e companhia não são “o fim da engenharia”.

São a pastelaria.

Você chega com um pedido simples, escolhe um recheio visual, e sai com algo funcionando em minutos.

Sinceramente, eu vejo valor nisso. Valor real.

Sejamos sinceros: nem todo problema precisa da dedicação de uma equipe de especialistas seguindo um processo rigoroso.

Veja, eu sou um ferrenho defensor da qualidade do software, da sustentabilidade e da manutenibilidade do código, da importância de arquitetura e testes. Eu me orgulho de ter projetos rodando há mais de uma década. Eu posso passar horas atormentando um ser humano com conteúdo sobre como fazer bom software.

A questão é: eu não sou maluco de achar que todo projeto merece esse nível de cuidado. Por que diabos eu obrigaria um cliente a pagar por um chef estrelado quando tudo o que ele quer é um pastel de carne pra matar a fome da hora?

Sabe aquele site de evento que você precisa pra semana que vem e que só vai acontecer de novo daqui a 3 anos? Pastel! O app de compartilhamento de vídeos que seu candidato flopado vai usar nessa eleição? Pastel! Aquele script maroto que você quer pra não ter que organizar seu álbum com 8000 fotos de seus amigos magricelas vestindo sunga de texugo no carnaval? Pastel! Landing page? CRUD básico? MVP para validar ideia?

TUDO ISSO VIROU PASTEL!

Você já não precisa de uma equipe de engenharia, de trocenta documentação, quatro tomos sagrados e dois arquitetos vestidos de jedi com sabres de luz de brinquedo pra resolver esses problemas.

Você precisa de um código funcional que seja entregue rápido, barato e bom o suficiente.

Nesse tipo de cenário, a pastelaria brilha.

---

O erro é achar que toda fome se resolve com pastel

Pastel mata fome. É bom, claro. Quem não gosta de um pastelzinho com caldo de cana? O problema é que pastel não mata todo tipo de larica.

Você consegue pedir camarão na moranga numa pastelaria? Um rodízio de churrasco? Um buffet pra 800 pessoas? Uma pizza de pneu? Não.

No software é a mesma coisa.

Por mais que o desenvolvimento de software evolua, sempre vai existir contexto em que você precisa de:

• arquitetura que sobreviva a anos de evolução;
• integração com legado cheio de arestas;
• requisitos regulatórios e auditoria;
• performance sob carga real;
• segurança com responsabilidade jurídica;
• decisões de trade-off que afetam negócio, operação e risco.

Isso não sai da chapa da feira em 7 minutos. Isso requer uma equipe de cozinha experiente, uma cozinha equipada, um processo de preparação e um controle de qualidade rigoroso.

Isso é cozinha de verdade.

---

Mas a pastelaria tá virando fábrica

Até aqui, a imagem que eu pintei é a de um tio de avental fritando pastel na chapa, um por um.

Só que não é mais isso.

O que está acontecendo agora é outra escala. Não é uma pastelaria de esquina — é uma operação industrial com cinquenta frigideiras automáticas rodando em paralelo. Agentes autônomos que pegam uma tarefa, montam o ambiente, escrevem código, rodam testes, quebram, pesquisam solução, corrigem, rodam de novo e entregam um pull request pronto pra review.

A pastelaria agora é autônoma. E o pasteleiro?

Ele parou de fritar pastel. Agora tem que projetar a pastelaria.

Ele projeta a receita com precisão cirúrgica — porque se a receita for vaga, cinquenta frigideiras vão errar ao mesmo tempo, cada uma de um jeito diferente. Ele monta a linha de montagem. Ele define o controle de qualidade. E ele decide quando o pastel que saiu da linha tá bom o suficiente pra servir.

É a mesma pastelaria? É. Mas agora é uma franquia de dark kitchen do iFood, com cozinha central e escala industrial. O MVP que antes era artesanal, quase uma colcha de tricô glorificada pelas mãos de várias avós, agora sai de uma linha de produção com testes automatizados, documentação viva, deploy e preview ao vivo.

E isso muda o jogo. Porque "simples" deixou de ser o tio fazendo um pastel na hora — virou uma fábrica cuspindo pastéis personalizados em minutos.

---

O problema não é mais fritar, é provar

No tempo dos antigos egípcios, ali pelos anos 90, codificar era caro, lento e doloroso. Não porque faltasse gente inteligente, mas porque cada mudança custava caro demais. Linguagens menos expressivas, ferramenta pior, feedback lento, deploy arriscado. Nesse cenário, fazia sentido gastar toneladas de energia tentando evitar erro antes que ele nascesse. O cascata era, entre outras coisas, uma tentativa de comprar previsibilidade num mundo em que mudar código ainda era quase um evento diplomático.

Depois o custo de produção caiu um degrau. Linguagens ficaram mais amigáveis, frameworks encapsularam trabalho repetitivo, IDEs deixaram de ser um bloco de notas premium e testes automatizados começaram a baratear o retrabalho. A indústria respondeu puxando o processo para modelos mais iterativos: RUP, espiral, modelos de maturidade, ciclos menores, mais checkpoints. Não porque o mercado tivesse alcançado iluminação transcendental, mas porque já dava pra errar menos caro e corrigir sem incendiar o orçamento inteiro.

Só que esses modelos ainda carregavam muito peso. Documento demais, ritual demais, acoplamento demais entre plano e realidade. O código mudava, o documento apodrecia, e a equipe ficava mantendo duas ficções ao mesmo tempo: a ficção de que o plano original ainda valia e a ficção de que alguém atualizaria o PDF depois.

A resposta seguinte foi puxar o gargalo mais uma vez pra frente. Com automação de build, integração contínua, cloud, deploy frequente e observabilidade melhor, o problema deixou de ser “como evitar qualquer mudança” e passou a ser “como aprender rápido sem quebrar tudo”. Daí vieram o discurso ágil, DevOps, CI/CD e a obsessão por feedback loop curto. Repara na lógica: quando produzir ficou menos caro, o valor saiu do ato de produzir e foi para a capacidade de decidir melhor e corrigir mais rápido.

Agora estamos descendo mais um degrau. Com copilots, LLMs e agentes, escrever código deixou de ser o trecho mais caro de muitos fluxos. Em alguns casos, virou quase a parte trivial. Você pede, o sistema gera, testa, corrige, abre PR, publica preview e ainda te olha com cara de quem fez favor.

Observa aqui um padrão?

Toda vez que a produção fica mais barata, o gargalo sobe um andar. Primeiro o drama era conseguir escrever. Depois virou organizar o trabalho. Depois virou encurtar feedback. Agora, com a produção quase instantânea, o drama passa a ser outro: decidir o que vale ser produzido, descrever isso sem ambiguidade, montar a esteira certa e provar que o resultado presta.

Não é a primeira vez que nós automatizamos trabalho. A mecanização nunca eliminou o problema; ela só deslocou o ponto caro do sistema. Quando a enxada melhora, o gargalo sai do braço. Quando a linha de montagem acelera, o gargalo vai para desenho do processo, coordenação e controle de qualidade. No software, estamos vendo a mesma peça com figurino novo.

Se qualquer agente monta um pastel em minutos, fritar deixou de ser habilidade rara. Raro agora é impedir que a fábrica produza porcaria em escala industrial.

É aí que entram os quatro gargalos que sobraram:

Quem monta a fábrica. Alguém precisa configurar a linha de produção — definir quais agentes rodam, com quais ferramentas, em qual sequência, com qual feedback loop. Isso é orquestração. Se a fábrica tá mal montada, não importa o quão bom é o pedido ou o quanto você sabe provar: o resultado vai sair torto.

Quem desenha o cardápio. Uma coisa é fazer um pastel bem feito. Outra é decidir quais pastéis esse negócio deveria oferecer. Que combinações fazem sentido pro público? Quando vale adicionar um sabor novo? Quando o cardápio inteiro tá errado e precisa ser repensado? No software, isso é arquitetura e visão de sistema. O agente implementa — mas não julga se o design faz sentido. Você pode ter spec perfeita, fábrica montada, verificação rigorosa — e ainda assim estar construindo a coisa errada, da forma errada.

Quem faz o pedido certo. Se a receita for vaga, cinquenta frigideiras vão errar ao mesmo tempo, cada uma de um jeito. O pedido é a spec — e spec em escala não é "descreva o que quer". É decomposição de problema, definição precisa de critérios de aceite, e clareza sobre o que tá dentro e fora do escopo. Pedido ruim não produz pastel ruim. Produz cinquenta pastéis ruins em paralelo.

Quem prova o pastel e diz se presta. Quem olha pra massa e percebe que tá crua por dentro. Quem sente que o recheio não combina com o público. Quem identifica que o pastel tem uma cara bonita mas tá contaminado por dentro — passa no teste visual, mas não sobrevive à primeira mordida de verdade. Isso é paladar treinado. É verificação.

Repara que os quatro importam. Mas provar merece o título do capítulo porque é aí que a pastelização mais engana. Produção em escala cria uma ilusão de competência. Sai muita coisa, rápido, com cara de pronto, com print bonita e pipeline verdinho. Só que volume não é evidência de qualidade. Velocidade não é evidência de aderência ao problema. Código que compila continua podendo estar profundamente errado.

No software, o gargalo dominante deixa de ser digitar código e passa a ser orquestração, arquitetura, especificação e verificação. A máquina ajuda em todos eles. Mas nenhum deles se resolve só com máquina, porque todos dependem de julgamento.

Verificar em escala é especialmente traiçoeiro. Quando saem cinquenta pastéis por minuto da linha, você não pode provar cada um com calma. Precisa de processo. Precisa de critério. Precisa de quem sabe montar a suíte de testes que pega o que importa — e, ainda assim, sabe que o teste não pega tudo, e mantém o olho treinado pra quando a intuição grita mais alto que a automação.

O valor do engenheiro migra de "saber cozinhar" para saber montar a cozinha, desenhar o cardápio, fazer o pedido certo e provar o resultado. De produção para julgamento. De escrever código para avaliar se o código que saiu merece existir.

---

Tem gente que diz: até o restaurante vai virar pastelaria

Até aqui, meu argumento assume uma divisão: pastelaria pra coisa simples, restaurante pra coisa séria.

Mas tem gente no mercado que olha pra essa divisão e diz: "Isso é temporário. Daqui a pouco, até o restaurante vira pastelaria."

O raciocínio funciona assim: se o custo de desenvolver software cair o suficiente, ninguém vai manter um ERP por vinte anos. Vai reescrever do zero. Assim como ninguém mais herda a saia da avó — compra uma nova e joga a velha fora. O software vira fast fashion: usar, descartar, refazer. Por que pagar manutenção de um sistema legado se dá pra ter um novo, sob medida, por alguns milhares de reais na segunda-feira?

Nesse cenário, as grandes empresas de software perdem o monopólio da complexidade. Uma loja de software de esquina monta uma IDE, um Photoshop, um sistema de contabilidade inteiro. O restaurante estrelado fecha porque a fábrica aprendeu a fazer camarão na moranga em escala.

Eu não sei se concordo. Mas eu entendo o argumento.

E a pergunta que fica é de fundir a cuca: o que você faria se o seu camarão na moranga pudesse ser refeito do zero por R$ 5 mil na segunda-feira?

Será que o que você chama de "software complexo" é complexo de verdade — ou é complexo porque foi caro pra fazer e virou caro demais pra jogar fora?

---

Vários modelos convivendo na mesma cidade

A grande sacada é entender que, da mesma forma que continuamos tendo vários tipos de cozinha, a IA é apenas mais um estabelecimento válido:

Tem aquele que vai se resolver com um miojo e um ovo frito (sistema baratinho, de caixinha): industrializado, só pra matar a fome da hora.

Tem quem vá de pastelaria (IA produto-pronto): rapidez, baixo custo, escopo simples.

Tem quem vá de restaurante (engenharia sob medida): sofisticação, profundidade, responsabilidade.

Tem quem vá de comida caseira (faça você mesmo): autonomia total, custo de tempo alto, aprendizado no processo.

Nenhum desses modelos "anula" o outro. Eles atendem fomes diferentes.

Mas aqui vai o detalhe que ninguém gosta de ouvir: os limites entre eles estão se movendo.

O que era restaurante há cinco anos — uma aplicação web com autenticação, dashboard e integração com API de pagamento — hoje sai de uma pastelaria industrial em uma tarde. O prato que justificava um chef dedicado virou receita automatizada.

O problema não é que a pastelaria vai engolir o restaurante. É que a linha do que "precisa de restaurante de verdade" sobe constantemente. O cardápio do restaurante encolhe toda vez que a fábrica de pastéis aprende uma receita nova.

E quem não sobe junto com essa linha fica fritando pastel pelo preço de pastel.

O problema começa quando alguém quer pagar preço de pastel e exigir experiência de restaurante estrelado. Mas o problema de verdade começa quando o restaurante não consegue explicar por que o prato dele vale mais do que o pastel que acabou de sair da fábrica.

---

O que muda para quem desenvolve software

A minha leitura é simples: a pastelização é ótima para o mercado e ótima para quem souber se posicionar.

Eu não quero gastar meu tempo de vida fritando pastel que uma IA entrega em escala.

Eu quero estar no trabalho em que:

• a decisão importa mais do que o código bruto;
• o contexto é mais complexo do que um prompt;
• o risco de errar é alto demais para “deixa que a ferramenta decide”.

Mas "se posicionar" mudou de significado.

Antes, eu me diferenciava por saber cozinhar bem: dominar a linguagem, conhecer o framework, resolver bug obscuro que ninguém mais achava.

Agora, o que diferencia é saber projetar a receita — escrever specs tão claras que cinquenta agentes executam sem ambiguidade. É saber montar a cozinha — orquestrar agentes em paralelo, definir fluxos, manter coerência entre os resultados. É saber desenhar o cardápio — decidir o que faz sentido construir e o que é desperdício de frigideira. E é saber provar o prato — avaliar com rigor se o que saiu da linha de produção realmente serve, se não criou trinca invisível, se não resolve o problema errado.

Spec como produto. Orquestração como competência. Arquitetura como visão. Verificação como craft.

Em outras palavras: quero o cliente que entende quando precisa de camarão na moranga — e paga por isso. Mas, cada vez mais, o camarão na moranga não é o código em si. É o julgamento por trás dele.

---

Essa conversa não acabou

Eu poderia fechar esse texto com uma frase bonita sobre como tudo vai se acomodar. Sobre como a segmentação do mercado vai resolver as coisas naturalmente. Mas seria desonesto.

A verdade é que essa discussão tá longe de ter resposta.

Tem gente séria dizendo que só a camada commodity muda — que engenharia de verdade continua intocada. Tem gente igualmente séria dizendo que até o software mais complexo vai virar descartável em poucos anos. As opiniões são antagônicas. E o mais importante: ninguém tem dados pra bater o martelo. Estamos todos olhando a mesma neblina e enxergando formas diferentes.

Eu tenho minha opinião. E faço questão de marcar como opinião, não como certeza.

Eu acho que os desenvolvedores atuais terão um papel importante nesse futuro. Não porque é reconfortante pensar assim, mas porque as evidências até agora mostram que quem sabe provar o prato, projetar a receita e decidir quando o pastel resolve e quando não resolve continua sendo insubstituível.

O erro de alguns C-levels é achar que "IA faz software" significa "não preciso mais de quem entende de software". É o equivalente a achar que comprar uma fritadeira industrial dispensa quem sabe cozinhar. A fritadeira é boa. Mas alguém precisa saber o que colocar dentro dela — e o que fazer quando o resultado não presta.

Agora, aqui vai a parte que me tira o sono de vez em quando:

O futuro está em aberto. Desenvolvedores terão papel. Mas qual papel?

Não é "vamos ser substituídos?" — essa é a pergunta errada.

A pergunta certa é: "Vamos fazer o quê?"

E quem não estiver se fazendo essa pergunta agora vai descobrir a resposta da pior forma possível: quando alguém já tiver respondido por eles.

---

Se quiser ir mais fundo nas posições que alimentaram esse texto:

• The Factory Model: How Coding Agents Changed Software Engineering — sobre o dev como arquiteto de fábrica.
• The Third Era of AI Software Development — sobre agentes autônomos e o que vem depois.
• Fast Software: More Programmers, Not Fewer — sobre software descartável e o fim do software-patrimônio.