Codar ainda importa? E até quando vai importar?

Até que ponto os humanos vão continuar escrevendo código? Será que essa função será assumida 100% por IAs e automações no futuro?

Você confiaria seu projeto ou seu negócio a um aplicativo totalmente gerado por IA? Essas são perguntas que têm pairado na cabeça de muita gente ultimamente.

A essa altura, você já deve saber: as IAs estão cada vez mais sofisticadas na hora de escrever (ou “gerar”) código. Em várias linguagens, com diferentes estilos, até em formatos específicos para cada stack. E em tarefas repetitivas… às vezes elas mandam até melhor que a gente.

Então a pergunta volta: escrever código ainda é papel do dev? Spoiler: sim. Mas talvez o mais importante agora seja entender como essa tarefa está mudando — e o que isso exige de quem continua codando.

No post anterior, comentei que o papel do engenheiro de software sempre foi muito mais amplo do que apenas programar. Ainda assim, sabemos que “escrever código” é visto por muitos como a função central do dev. E talvez por isso a chegada das IAs tenha deixado tanta gente de cabeça quente.

Em meio a tantas transformações, sigo acreditando que estamos em um ótimo momento para repensar e até valorizar, os vários papéis do dev. Mas não dá pra ignorar o que está acontecendo com a própria prática de codar. Isso tem impacto, sim. E como tudo na vida… vem com vantagens e desvantagens.

⚖️IA ajudando a codar: nem tudo são flores ou bugs

Já não é mais novidade que a IA tem trazido benefícios claros: ganhos de produtividade em diferentes escalas, agilidade para testar ideias, suporte na conversão entre linguagens, e automatização de tarefas repetitivas (muitas vezes chatas), que antes drenavam o tempo e a energia do time. No entanto, junto com tudo isso, vêm alguns alertas que podem se transformar em sérios problemas: dependência excessiva, perda de compreensão sobre o que está sendo implementado, riscos de segurança e a falsa sensação de que tudo está sob controle. Sabemos então que ajudar, ela ajuda, mas deixar a IA assumir sem supervisão adequada é outra história.

🎧 E o tal do Vibe coding?

Tem gente dizendo que é um novo jeitão de programar com IA. Outros já chamam de técnica. Compilando e resumindo: segundo algumas fontes, o termo vibe coding (ou vibe code) já é considerado uma abordagem de desenvolvimento em que o programador (ou vibe coder) descreve o que deseja em linguagem natural para uma IA, geralmente uma LLM, que gera o código automaticamente, sem necessidade de digitar linha por linha.

Nesse aspecto alguns já defendem que o papel do desenvolvedor muda: de codificador para uma espécie de “guia” ou “diretor criativo”, que solicita, testa e valida (em algum nível) o que foi gerado. O termo é bem recente, considerando a data em que escrevo, e foi popularizado por Andrej Karpathy, cofundador da OpenAI.

Como é algo novo, ainda há variações e interpretações. Mas o ponto é claro: a dinâmica mudou, e as possibilidades também. O processo criativo da programação passa a ser influenciado por IA e não é mais algo exclusivo só de devs. Pessoas sem experiência técnica já conseguem gerar código e até construir soluções inteiras, principalmente na criação de sites ou aplicativos mais simples.

Isso já é realidade em muitas frentes. E, como tudo, tende a evoluir. Mas o ponto que quero destacar aqui é: não importa quem ou como está gerando o código — os ganhos em agilidade são evidentes, mas a necessidade de atenção e responsabilidade continua firme. As soluções a serem construídas seguirão exigindo níveis variados de complexidade, o que, por sua vez, continuará demandando competências diferentes e profundidades distintas de conhecimento.

Outro ponto que já é — e deve continuar sendo — um desafio para os vibe coders (pelo menos por enquanto) é o bom e velho debug. Isso vale tanto para erros de compilação quanto de execução dos códigos gerados. E aí fica evidente que a coisa não é tão simples (nem tão colorida) quanto muita gente anda pintando por aí. Afinal, lidar com erros, mesmo os mais simples, geralmente exige algum nível de entendimento sobre o código ou sobre as configurações envolvidas.

🚦Além do hype (ou: filtrando o hype)

Por mais sofisticadas que tenham se tornado as plataformas, e por mais que a IA generativa esteja evoluindo em ritmo acelerado, ainda vamos precisar de um bom nível de conhecimento sobre o código — ou pelo menos sobre boa parte dele — para revisar, testar, corrigir e aprimorar. Pergunte-se: você confiaria uma aplicação crítica do seu negócio a uma IA, sem nenhuma intervenção ou supervisão humana? (Eu, sinceramente, não.)

É importante lembrar — sempre — que, por mais que as LLMs usem contexto e técnicas avançadas, no fim do dia, ainda estamos lidando com modelos que geram texto, e não com agentes que realmente compreendem os problemas em toda sua profundidade. Eles não são totalmente capazes de compreender diversos aspectos dos problemas reais. (pelo menos por enquanto rsr… )

Não se trata de ser contra ou a favor. A questão aqui é adotar um olhar crítico e atento, capaz de filtrar o que realmente importa para criarmos soluções melhores e de modo mais rápido — e não só seguir o barulho do momento.

Em estágios iniciais de projetos, como ideação ou prototipação, essas ferramentas funcionam muito bem: geram versões rápidas, exploram ideias e ajudam a visualizar possibilidades. Muita gente já está usando e abusando disso… Mas em produtos mais robustos e sistemas complexos, o uso ainda tem sido mais pontual e direcionado.

Em sistemas mais complexos — com múltiplos módulos, camadas e integrações —, sempre será necessário garantir que uma alteração feita pela IA não tenha gerado efeitos colaterais além do esperado. Afinal, mudanças aparentemente pequenas, como em uma única função por exemplo, já podem causar grandes estragos (problemas para usuários, prejuízos financeiros, impacto na reputação, brechas de segurança, etc.)

Mas as ferramentas estão evoluindo rápido? Isso pode mudar em breve?

Concordo que está evoluindo rápido… Sobre mudar, talvez… Por isso mesmo, o desafio está em seguir atentos, calibrando nossos filtros e separando o que é valor real do que é só marketing — ou puro hype.

✍️🧠Continue escrevendo (e entendendo) código

Antes de mais nada, independente se você é um dev já com alguma experiência ou se é só um entusiasta de “vibe coding”, em projetos reais, em produção (com pessoas usando de fato) — tenha cuidados extras com qualquer uso de IA ou com qualquer vibe” ou “hype”.

Para os vibe coders “não devs” (entusiastas, empreendedores, “idealizadores”, etc.), a abordagem pode ser “mais light” em relação a compreensão mais profunda do código, mas se for projeto sério, considere fortemente o apoio de um engenheiro de software na produção e/ou revisão do seu código, nem que seja para consultorias esporádicas. Sei que existem diferentes tamanhos de projetos e fases, mas se for algo pra valer, não deixe que seu produto se torne uma bomba relógio, como alguns casos que já vimos por aí.

Agora se o seu objetivo é se desenvolver como engenheiro de software, por favor continue escrevendo código e estudando sobre isso e sobre Engenharia de Software, obviamente. Isso não quer dizer que você não pode usufruir dos benefícios que a IA traz. Encontre um equilíbrio que funcione bem para você e seu time e/ou projeto.

Ao usar qualquer ferramenta para escrever código, não deixe de compreender, de fato, qual problema está resolvendo e como a solução gerada pretende fazer isso.

Reflita: A proposta faz sentido mesmo? Pode gerar efeitos colaterais em algo que já existe? O prompt/pedido pode ser refinado? Tem certeza? Testou? Retestou? Tem time envolvido? Alguém revisou? E por aí vai…

---

🤖 Como você tem usado a IA pra codar?

Estou bem curioso pra saber como você tem usado a IA por aí. Quais são seus casos de uso? Manda nos comentários — bora trocar ideia sobre isso!

Pra começar a brincadeira, vou compartilhar como tenho usado as ferramentas de IA até agora (focando aqui só na parte de escrita de código). Como meu foco nos últimos anos tem sido mais voltado ao backend, meus exemplos acabam refletindo isso — mas vez ou outra também exploro algumas coisas no front, em scripts ou automações.

💡 Alguns usos que tenho feito (relacionados a escrita/revisão de código):

• Gerar funções ou trechos específicos (com revisão posterior, claro);
• Criar classes com propriedades a partir de texto ou histórias de usuário, com ou sem atributos (ou annotations) adicionais (ex: [JsonProperty]y] => aqui usei só com C#);
• Gerar ou revisar testes de unidade com base em métodos existentes;
• Revisar ou explicar trechos de código — também útil como apoio em code reviews e investigações (troubleshooting);
• Sugerir abordagens alternativas para otimização ou manutenção;
• Criar e revisar queries de banco de dados;
• Analisar estruturas de código (camadas, relação entre classes, responsabilidades);
• Gerar script (JS ou Python) para fazer algum processamento local específico;
• Gerar ideias de código alternativos para alguma solução e/ou buscando alguma otimização relacionada a desempenho ou facilidade de manutenção;
• Pesquisas contextualizadas: Embora eu nunca confie 100% nos resultados, usar IA pra buscas mais orientadas ao contexto tem economizado bastante tempo. Uso como complemento à busca tradicional. (Mas, claro… confira as fontes, jovem reflexivo 😄)

Pesquisas contextualizadas:

• Embora eu nunca confie 100% nos resultados, usar IA pra buscas mais orientadas ao contexto tem economizado bastante tempo.
• Uso como complemento à busca tradicional. (Mas, claro… confira as fontes, jovem reflexivo 😄)

🧰 Ferramentas que tenho usado com mais frequência (IDE e web):

• Github Copilot (com e sem chat), ChatGPT, Claude, Perplexity, IntelliCode do VS, StackSpot AI, Gemini;
• Um pezinho no “vibe coding”!? Meu foco não tenho sido muito aqui, mas já testei ferramentas como o Cursor e o Replit pra alguns casos. Agora estou começando a brincar com o Codex da OpenAI (depois conto mais rsrs 😄).

💡Outros itens a explorar

• Design Docs + IAs: Ainda em fase inicial de aprendizado aqui, e com pouco ganho prático no meu contexto atual (sistemas existentes e com padrões bem definidos, mas sigo aberto a explorar… ). O que achei interessante, é que além de melhorar o trabalho do dev (ou do vibe coder) em relação ao prompt de entrada, ajuda a manter o foco da LLM dentro do escopo do projeto, para não alucinar e reduzir alterações indesejadas.
• >_ Ferramentas CLI (terminal de comandos) + IAs: Tenho notado um avanço constante nas ferramentas de linha de comando com suporte de IA, embora eu ainda tenha explorado pouco sobre isso. Acredito que, assim como vem acontecendo com as IDEs a boa e velha “linha de comando” também tende a ganhar cada vez mais reforço. Com a contextualização de projetos locais ou repositórios (como os do GitHub, por exemplo), a tendência é que vejamos um ganho significativo em produtividade e efetividade com o uso assistido.

Pra deixar isso aqui mais interativo: como você tem usado IA na escrita ou revisão de código? Quais ferramentas tem funcionado melhor? Algum caso de uso comum ou diferente? Se já fez algum uso destas abordagens e/ou ferramentas, me conta aí nos comentários — bora compartilhar e aprender juntos!

---

🌊 Aproveite a onda, mas continue pilotando

A essa altura, talvez já concordemos que a IA pode, sim, ser um baita acelerador no desenvolvimento de software — especialmente nos poupando tempo e energia com tarefas repetitivas e chatas.

Se preferir, pense nela como um bom copiloto (aliás, o nome Copilot, escolhido pelo GitHub, foi genial — na minha opinião, um dos mais coerentes com essa nova realidade). E convenhamos: quem não gosta de uma boa ajuda pra acelerar o resultado?

Só não vale entregar o manche por completo. Tenha um copiloto, mas continue pilotando. E mais que isso: continue aperfeiçoando sua habilidade de pilotar — e de criar. A grande sacada aqui talvez seja justamente essa: com menos peso nas tarefas operacionais, ganhamos mais espaço pra criar mais… e melhor.

Ao meu ver, o papel do engenheiro de software na escrita de código continua extremamente relevante. Talvez agora com um olhar ainda mais atento sobre revisão, validação e impacto. Porque, pra melhorar um código, você ainda precisa conhecê-lo em boa medida. E se ninguém está fazendo isso no seu projeto… há um risco considerável no ar. Acredite, na hora que a coisa aperta, só o conhecimento e experiência vão salvar.

Além disso, nesse novo cenário de mercado, também se configura um ótimo momento para olharmos com mais atenção para todas as nossas outras capacidades — como pensamento crítico, análise de requisitos, comunicação, empatia e resolução de problemas, seja com ferramentas novas ou das antigas. Porque, no fim, engenharia de software nunca foi só sobre código. E agora não é diferente.

Link do post anterior:

O dev do futuro… ainda será dev?

Seguimos juntos — pelo código e além! ☕🚀