Engenharia de software com IA

Ver no idioma original →

Engenharia de software com IA abrange o uso de modelos e agentes para planejar, implementar, testar, revisar e implantar software. Os vídeos destacam que a velocidade de geração, por si só, não garante qualidade: resultados dependem também de requisitos claros, contexto, ferramentas, verificações e julgamento humano. A escolha de modelos e workflows deve ser avaliada em tarefas reais, considerando qualidade, custo, velocidade e riscos. ↗ ↗ ↗

Especificação e planejamento

O Spec-Driven Development (SDD) ajuda a transformar uma necessidade em histórias de usuário, tarefas e critérios de aceitação que agentes podem executar e pessoas podem revisar. A recomendação é manter PRDs curtos e claros, centrados no problema, na solução, nas restrições e nos critérios de aceitação. Quanto maior a complexidade da tarefa — ou mais difícil for verificar seu resultado — maior a importância de especificá-la e dividi-la. ↗

Entrevistar a pessoa antes de implementar é outra forma de esclarecer requisitos. A skill Grill Me, por exemplo, propõe perguntas detalhadas sobre objetivos e funcionalidades antes de criar uma especificação ou iniciar a implementação. ↗ Diagramas e ilustrações do sistema também podem ajudar desenvolvedores a entender como as partes se relacionam e a explicar o projeto a outras pessoas. ↗

Em projetos reais, o planejamento pode começar antes do primeiro prompt: identificar o caso de uso, avaliar o valor esperado, entender requisitos de segurança e preparar as integrações ajuda a transformar protótipos em aplicações úteis para o negócio. ↗ Em system design, esclarecer requisitos e comunicar decisões técnicas são competências importantes junto com a escolha de arquitetura, APIs, armazenamento e estratégias para escalabilidade e falhas. ↗

Um fluxo de trabalho profissional apresentado para evitar dívida técnica com IA divide o processo em quatro etapas: especificar, projetar, direcionar o agente e revisar o resultado. Protótipos descartáveis podem tolerar menos salvaguardas, mas produtos com usuários, dados reais ou pagamentos exigem práticas de engenharia de software. ↗

Agents, harnesses e workflows

Um agent harness conecta o modelo a ferramentas, contexto e ao ambiente de trabalho. Pode incluir permissões, instruções, memória, hooks, subagents, observabilidade e mecanismos para verificar alterações. A engenharia do harness, portanto, envolve mais do que escolher um ou vários agentes: é preciso estabelecer onde o agente atua, o que pode alterar e como confirmar que o resultado funciona. ↗ ↗ ↗

Os workflows podem dividir planejamento, implementação, revisão e documentação entre modelos diferentes, equilibrando qualidade, custo e velocidade. Harnesses também podem selecionar modelos de acordo com a tarefa, em vez de exigir que a pessoa escolha manualmente um modelo para cada etapa. ↗ ↗ Skills, convenções persistentes no repositório e CLIs para softwares existentes ampliam o que os agents conseguem fazer; ainda assim, comandos, testes e alterações gerados precisam ser revisados, especialmente em tarefas importantes. ↗ ↗

Workshops e demonstrações mostram como agentes podem ser controlados com ferramentas, hooks, skills e instruções de direcionamento, e depois implantados com recursos de sessão e observabilidade. ↗ Skills também podem conectar agents a ferramentas de design, documentação e desenvolvimento mobile: em um exemplo, um agente acessa telas criadas no Stitch por MCP, usa recursos para Android, testa no emulador e executa o app em um dispositivo real. ↗

Uma software factory amplia esse padrão: em vez de supervisionar sessões individuais, a pessoa delega tarefas a um conjunto de agents gerenciados pelo sistema. A factory pode encaminhar trabalho a um agente disponível, aguardar quando todos estão ocupados, executar testes e guardrails e entregar uma alteração ou abrir um pull request. Ela é a infraestrutura que gerencia o workflow, não um agente autônomo sem controle. ↗ ↗ Enxames de agents também podem ser visualizados em um espaço de trabalho compartilhado, com tarefas ligadas a issues e alterações integradas, testadas e verificadas. ↗

Orquestração pode incluir vários repositórios, equipes e etapas do SDLC, reunindo contexto organizacional para orientar planejamento, codificação, revisão e análise de incidentes. Esses workflows ainda precisam lidar com custos, dados desatualizados, padrões de código e revisão humana. ↗ Em automações, plataformas como n8n permitem combinar APIs, modelos, memória e agentes, além de incorporar aprovação humana, tratamento de erros e monitoramento. ↗

A disponibilidade de mais agents e ferramentas não elimina decisões de priorização: delegar tarefas em paralelo pode acelerar a prototipagem, mas também aumenta o trabalho de validar e integrar alterações. ↗ Recursos de gestão de sessões, voz, modelos, servidores MCP e macros podem facilitar o controle de agents, mas são interfaces para o workflow, não substitutos de critérios de conclusão e revisão. ↗ ↗

Implementação, revisão e validação

Agentes podem acelerar a escrita de código, mas a revisão e a verificação podem se tornar gargalos. Em bases de código grandes, mudanças numerosas podem aumentar a duplicação, a inconsistência e a dificuldade de manutenção. Reduzir o escopo das tarefas, explicitar convenções e manter a responsabilidade pelas alterações ajuda a tornar o trabalho mais fácil de entender e revisar. ↗ ↗

Um fluxo de revisão pode combinar verificações estáticas, testes, code review automático e revisão humana final, reservando mais atenção humana para mudanças de maior risco. Essa abordagem busca reduzir a carga cognitiva sem ignorar regressões; a responsabilidade pelo código continua sendo humana. ↗ ↗ A revisão automática também pode ser ajustada para evitar que nitpicks e casos improváveis consumam tempo, deixando a revisão final concentrar-se na abordagem geral. ↗

Ferramentas de verificação visual podem comparar interfaces e fluxos com um design de referência, devolver feedback ao agente e permitir que ele corrija o resultado. ↗ Ferramentas de design também podem ajudar a encontrar referências, conferir responsividade e aplicar estilos, embora materiais promocionais gerados por IA possam mostrar cenas ou interações que não correspondem ao produto real. ↗ Soluções como Impeccable procuram detectar padrões visuais genéricos com regras determinísticas e comandos de auditoria, mas podem exigir várias rodadas de iteração e também sinalizar novos clichês. ↗

Testes, evals, tracing e validação em produção ajudam a fechar o ciclo de melhoria. Um processo de desenvolvimento de agentes pode incluir construção, teste com entradas e resultados esperados, implantação e monitoramento. Os sinais observados em produção podem ser transformados em critérios e conjuntos de avaliação para testar mudanças antes de liberá-las. ↗ ↗ A avaliação de modelos também deve refletir as tarefas reais: benchmarks públicos são referências, mas não substituem testes que considerem conclusão, qualidade, tempo e custo no workflow em questão. ↗

Benchmarks reproduzíveis devem registrar não apenas um score, mas também consistência entre execuções, variação, custo, uso de tokens e traces que permitam entender como o resultado foi obtido. A configuração — incluindo dataset, harness, sandbox, agente, modelo, provedor e parâmetros — influencia a comparação. ↗ Ciclos de AutoResearch podem automatizar propostas de mudanças e medições contra uma métrica, mantendo as alterações que melhoram o resultado; avaliações rápidas, observabilidade e controle humano são partes importantes desse processo. ↗

Testes aleatórios não garantem que uma falha seja encontrada: em uma demonstração, um fuzzer executou 10 milhões de testes sem detectar um erro, enquanto uma prova formal assistida por Claude e CBMC encontrou um caso de falha em cerca de 36 segundos. O método não prova que todo o software está livre de bugs: as conclusões dependem de hipóteses sobre hardware e ambiente e da validade do verificador de provas. ↗

Falhas em produção também mostram a importância de testar condições extremas. Um bug no modo de chuva do controlador de uma unidade de potência da Fórmula 1 afetou carros durante uma volta de formação, levando à interrupção da corrida e à distribuição de uma correção de software. O episódio ilustra que alguns casos podem escapar dos testes e aparecer apenas em produção. ↗ Em sistemas espaciais, a correção remota de uma falha de memória na Voyager 1 exigiu dividir código e atualizar manualmente os pontos que o chamavam, pois não era possível substituir o componente físico. ↗

A supervisão humana continua importante, sobretudo em contextos de maior risco. Em aplicações empresariais, os vídeos recomendam identificar responsáveis por dados, risco, fornecedores e auditoria; começar com a menor autoridade que gere valor; e incluir registros, avaliações e planos de resposta a falhas. ↗ Em workflows automatizados, limites de tentativas, validação em staging e aprovações humanas podem ajudar a conter falhas antes da produção. ↗

Aumentar o volume de contribuições geradas por IA também pressiona a manutenção de projetos open source. Nem todo report ou pull request corresponde a uma vulnerabilidade formal, embora algumas contribuições possam ajudar a robustecer o código. Projetos precisam equilibrar o uso dessas ferramentas sem aceitar alterações indiscriminadamente nem rejeitá-las por completo, mantendo a revisão humana. ↗

O risco de conceder a um agente acesso amplo ao computador é especialmente relevante em tarefas de engenharia reversa ou automação. Os vídeos recomendam cautela, uso de cópias de segurança e consideração dos limites legais ao reconstruir software. ↗ ↗ ↗

Modelos, custos e ambientes de execução

Os resultados variam entre modelos e tarefas. Vídeos de testes práticos mostram modelos que se destacam em certas atividades, mas falham em outras; por isso, desempenho divulgado em benchmarks não basta para decidir se um modelo serve para um uso específico. ↗ ↗ Também há comparações em que modelos mais baratos entregam resultados úteis, mas diferem em velocidade, consumo de tokens ou capacidade de encontrar problemas adicionais. ↗ ↗

Comparações de geração de jogos, sites e aplicações ilustram essas diferenças: um modelo pode terminar mais rápido, outro produzir uma versão mais refinada e outro entregar um resultado visualmente atraente com erros funcionais, como controles invertidos ou colisões incompletas. Resultados de uma única tarefa não bastam para concluir que um modelo é universalmente superior. ↗ Em testes de projetos criados por prompt, modelos econômicos podem produzir aplicações funcionais, mas também falhar em determinadas tarefas ou exigir refinamentos. ↗ ↗ ↗

Os vídeos também relatam demonstrações de modelos capazes de gerar cenas 3D, interfaces, jogos e animações por código. Há exemplos apresentados como resultados expressivos, mas outros testes apontam problemas de acabamento, bugs, desempenho inconsistente ou custos que precisam ser considerados. ↗ ↗ ↗ ↗ Parte das notícias sobre checkpoints, modelos e capacidades futuras é especulativa ou não confirmada; relatos de usuários e vazamentos não equivalem a anúncios oficiais. ↗ ↗ ↗ ↗

A experiência de uso também depende do harness e do acesso ao modelo. Um agregador de APIs não oferece necessariamente a mesma experiência que um aplicativo oficial, que pode incluir instruções de sistema, memória e ferramentas integradas. Hubs podem fazer sentido para quem desenvolve aplicações e precisa personalizar modelos, prompts e custos. ↗ Agentes gerenciados que distribuem trabalho entre vários agents podem aumentar os custos, por isso é importante configurar limites de gastos. ↗

A execução local pode permitir trabalhar offline e manter dados no próprio computador, enquanto opções na nuvem permitem iniciar ou continuar tarefas em diferentes dispositivos e manter trabalhos em execução sem deixar a máquina ligada. ↗ ↗ Harnesses com roteamento entre modelos e limites de orçamento são outra forma de controlar custos sem restringir indiscriminadamente o uso de tokens. ↗ Executar modelos localmente pode favorecer privacidade e experimentação, mas o desempenho depende do hardware e pode exigir muita memória; os testes apresentados não equiparam esses modelos aos melhores serviços na nuvem. ↗ ↗

Ferramentas de publicação para aplicações de IA também podem reduzir o trabalho de infraestrutura, por exemplo, permitindo desenvolver e publicar em GPUs sem configurar Docker, instalar dependências durante a execução e chamar funções hospedadas em diferentes endpoints. ↗ Em qualquer ambiente, custo, latência, limites de contexto e recursos disponíveis devem ser avaliados no fluxo de trabalho em questão. ↗

Uso avançado, manutenção e limites

A experiência com IA varia conforme a ambição do trabalho e o acesso a ferramentas e modelos. Andrej Karpathy descreve uma diferença entre o uso casual de chatbots e o trabalho de usuários que já utilizam agents avançados em programação e matemática. A recomendação prática é propor projetos maiores, dar critérios para verificar resultados e usar ferramentas de agentes; a IA também apresenta desempenho desigual entre tipos de trabalho. ↗

Agentes podem reconstruir software a partir do comportamento observável, inclusive em projetos de engenharia reversa e clonagem de interfaces. Esses resultados podem ajudar a criar alternativas ou personalizar aplicativos, mas não garantem clones completos ou fiéis, e podem exigir prompts adicionais e validação. ↗ ↗ ↗ Os vídeos também destacam que criar uma alternativa é diferente de mantê-la: custos menores de desenvolvimento não garantem vantagem competitiva, que pode depender de dados, efeitos de rede e distribuição. ↗

Projetos open source de editores e aplicativos recriados com auxílio de IA mostram tanto a possibilidade de ampliar alternativas quanto seus limites. Em testes de editores de vídeo, texto e PDF, algumas funções básicas funcionam, mas há limitações de desempenho, recursos ou fidelidade; projetos em alpha não são necessariamente adequados para trabalho profissional com prazos ou documentos reais. ↗ ↗ ↗ A suíte ArtCraft, por exemplo, reúne aplicações open source que buscam oferecer alternativas a ferramentas da Adobe, mas seus aplicativos ainda estão em estágio inicial e não substituem necessariamente ferramentas profissionais. ↗

O mesmo vale para a criação de jogos e aplicativos: IA pode acelerar a produção e permitir trabalhar em tarefas em paralelo, mas conhecimento técnico continua sendo útil para avaliar e corrigir os resultados. ↗ A escolha de tecnologias e motores depende de fatores como tempo, tamanho da equipe e prioridade entre controle artístico e qualidade visual. ↗ Ferramentas experimentais de criação de jogos por linguagem natural também precisam lidar com segurança, infraestrutura e custo, e podem estar limitadas em disponibilidade e geração. ↗

Para desenvolver sistemas de IA úteis, as habilidades incluem fundamentos de programação e ferramentas, técnicas como embeddings, busca vetorial, RAG e agents, além de implantação, observabilidade, monitoramento e segurança. Projetos completos e publicados podem ajudar a demonstrar essas competências. ↗ Em funções que conectam tecnologia às necessidades de clientes, como FDE, também importam descoberta de problemas, comunicação, integração e responsabilidade por resultados mensuráveis. ↗ Em operações, o trabalho de SRE exige definir e medir confiabilidade, responder a falhas e evitar que se repitam; com código e infraestrutura gerados mais rapidamente por IA, a confiabilidade ganha ainda mais importância. ↗ ↗

Finalmente, o uso de agentes não elimina a necessidade de organização e julgamento técnico: em contextos que envolvem dados, serviços e dependências, é necessário definir responsabilidades, avaliar riscos e preparar sistemas para operação. ↗ ↗ Os vídeos não apresentam uma ferramenta, modelo ou workflow universalmente melhor; recomendam experimentar, verificar os resultados e escolher as configurações conforme o contexto real. ↗ ↗