IA Autônoma na Engenharia de Software: Um Experimento para Desvendar o Futuro do Desenvolvimento
Um head de TI com 22 anos de experiência em fintech lança um experimento audacioso: entregar o desenvolvimento de um produto real a um pipeline de IA autônomo. O objetivo é analisar o impacto no produto, na base de código e no débito técnico, sem revisão humana antes do deploy.
MundiX News·16 de junho de 2026·15 min de leitura·👁 7 views
Olá, Habr! Meu nome é Alexey Fyodorov, tenho 40 anos e nos últimos quatro anos atuei como Head of IT em uma fintech em rápido crescimento. Tenho 22 anos de experiência em desenvolvimento e duas trajetórias completas de Junior a CIO: primeiro como desenvolvedor 1C em negócios de produção, depois, aos 27 anos, comecei como Junior em fintech e cresci para CIO novamente. Para que fique claro de onde venho ao discutir 'IA escrevendo código em produção': desenvolvemos um custodiante para gerenciamento híbrido de carteiras quentes e frias, que em seus primeiros dois anos foi integrado por três das dez maiores exchanges de criptomoedas por volume; em 2015, lançamos um terminal web para Freedom Finance (então NetTrader), que permaneceu praticamente inalterado desde então; e fomos um dos primeiros na Rússia a lançar um aplicativo móvel de corretora simultaneamente em web, iOS e Android com uma única base de código. Ou seja, não sou um evangelista nem um caçador de hype. Sou alguém que, por vinte anos, foi responsável por garantir que o código de terceiros não derrubasse a produção onde o dinheiro está. E é exatamente por isso que me interessei em realizar o seguinte experimento.
O que está acontecendo ao nosso redor é compreensível. Todos já experimentaram o 'vibe coding' – alguns por diversão no fim de semana, outros seriamente. E os gerentes de nível C, após verem as demonstrações, agora exigem 'integrar IA ao desenvolvimento de todas as formas possíveis', de preferência para ontem. Familiar? Para mim, muito. O problema é que entre 'IA montou um protótipo em uma hora' e 'IA gerencia o desenvolvimento real de um produto com usuários ativos' existe um abismo sobre o qual há poucos dados honestos. Quando a tarefa é maior que um 'hello-world', o interessante começa: duplicação de lógica, débito técnico se espalhando, regressões, revisões que consomem todo o tempo economizado. Há muitas declarações grandiosas sobre crescimento exponencial de produtividade. Observações independentes e cuidadosamente medidas são poucas. Por isso, decidi não discutir nos comentários, mas montar um ambiente e ver com meus próprios olhos: como um pipeline autônomo de SDLC nativo de IA afeta tanto o produto quanto a base de código – incluindo o débito técnico – quando um fluxo real e vivo de requisições de pessoas externas passa por ele. E convido vocês a participarem deste experimento para descobrirmos os resultados juntos.
Para ser concreto, veja o que está acontecendo agora. Tenho um jogo de navegador – uma tática top-down sobre a invasão de um prédio por uma pequena unidade (no estilo Door Kickers). Ele está ativo: você abre o link e joga. Qualquer pessoa pode acessar um bot do Telegram e pedir para mudar algo no jogo: 'faça os inimigos mais atentos ao barulho', 'adicione uma espingarda', 'conserte o bug da porta', 'novo mapa com esta geometria'. Em seguida, a requisição é capturada por um pipeline autônomo. Ele esclarece a tarefa com o autor, a formula, projeta, escreve o código, executa testes, realiza revisões – e, se tudo estiver verde, implementa a mudança no build geral em produção, que todos os outros jogadores veem instantaneamente. O detalhe chave, pelo qual estou escrevendo este texto: a barreira final antes do release é a verificação automática de políticas, sem revisão manual de código. Eu, um ser humano, não leio os diffs antes do merge. O código gerado por solicitação de um estranho vai para a produção geral, e nenhum ser humano o viu. Soa, eu sei, como a descrição de um desastre. 'Código arbitrário de estranhos em produção ativa' – esse é exatamente o cenário que faz qualquer um responsável pela produção ter um tique nervoso. Eu também. Mas é sobre isso que trata o próprio experimento.
Agora, honestamente sobre o escopo, porque isso não é uma apresentação de produto acabado. Este é um experimento com foco em pesquisa, um estudo de caso n-of-1, com um horizonte de cerca de 60 dias. N-of-1 é um termo da metodologia de pesquisa: 'amostra de tamanho um'. Um pipeline, um jogo, um fluxo de tarefas, um mantenedor. Disso decorre imediatamente o que eu não posso e não farei: tirar leis universais do tipo 'o desenvolvimento com IA se degrada após N tarefas'. Isso não pode ser provado com uma única execução. Os mecanismos – 'o que exatamente quebrou e por quê' – podem ser descritos de forma justa e interessante a partir de um estudo de caso. Frequência e generalizações – apenas como hipóteses, com um convite explícito para refutá-las. O jogo aqui não é o objetivo, mas uma plataforma: é necessário para obter um fluxo barato e claro de requisições reais e diversas de pessoas reais. O objetivo é observar o próprio pipeline. O que estou medindo (desde o início, a partir da linha de base t0 = jogo inicial): Para onde a carga humana se desloca ao longo do tempo e pelas fases. Não 'quantas horas-homem são necessárias' – essa é justamente a questão em aberto que não me proponho a fechar com um número – mas em que direção se move: em quais fases sou necessário no início, em quais após um mês, minha participação cresce ou diminui e onde exatamente. O que acontece com a saúde da base de código: churn, duplicação, complexidade, cobertura, defeitos e incidentes. Degrada, se mantém ou evolui – e após quantas tarefas isso é visível. A vazão: tarefas por dia, taxa de sucesso, em quais fases o pipeline mais tropeça, o custo por tarefa. O que eu NÃO prometo: conclusões. Ainda não há – o experimento está apenas começando. Não vou forçar um caso único em uma tendência. Cada mudança de modelo, instrução ou verificação será versionada em um diário de decisões com justificativa e timestamp – caso contrário, seria um post de blog 'me pareceu', e não uma observação que pode ser verificada. A única coisa concreta que me comprometo a apresentar ao final é um catálogo de pontos problemáticos do SDLC nativo de IA: onde exatamente e como esse método de desenvolvimento quebra, ancorado em métricas registradas e um diário, e não em impressões. E sim – espero antecipadamente que muitas coisas quebrem. Isso não é um risco do experimento, é o seu conteúdo.
Se removermos os detalhes, a requisição passa por um pipeline de fases, e cada uma é visível em um quadro público em tempo real: Requisição – o jogador cria a requisição no bot. Moderação da Requisição – eu, como mantenedor, a aprovo. Este é o primeiro filtro de intenção: olho a entrada antes que a IA a veja. Esclarecimento com o autor – o pipeline faz perguntas se algo não estiver claro. Coleta de respostas. Moderação das respostas – um filtro semelhante, agora para as respostas do autor. Formulação final da tarefa – e esta é a fronteira de confiança. Daqui para baixo no pipeline, apenas a formulação aprovada vai, e nunca a história bruta da conversa. Esta é a proteção chave contra prompt injection: texto não confiável do jogador não entra no contexto do modelo como instrução. Análise – análise de sistema e de testes, além de verificação de conflito com a direção do jogo. Implementação – o agente escreve código seguindo TDD. Revisão. Teste – executa CI, não o agente. Done – merge no main e deploy contínuo. Entre as fases, existem loops de feedback (refinamento, re-esclarecimento, cancelamento pelo autor), e as tarefas são executadas estritamente uma por vez, em um único fluxo. Isso não é uma limitação da abordagem em si – pode-se paralelizar –, mas uma limitação consciente de orçamento e infraestrutura: uma pequena tentativa de controlar os gastos. Um benefício colateral: não há conflitos de merge, e cada mudança é facilmente atribuível de forma honesta. Separadamente sobre os papéis do modelo: cada fase (esclarecimento, formulação, análise, implementação, revisão) mantém seu prompt em um arquivo de template separado e versionado. O código apenas insere parâmetros – não há 'lógica de prompt' no código. Isso é necessário para que, posteriormente, seja possível dizer honestamente qual instrução específica em qual etapa levou a quê.
O código do jogo em si eu mantenho fechado, e isso é intencional – para a pureza do experimento. A ideia é que as modificações venham como requisições em linguagem natural, e não como diffs prontos: eu meço o trabalho do pipeline, não os pull requests de terceiros. Se o código fosse aberto, o fluxo se transformaria em desenvolvimento open-source comum, e não haveria nada para observar. Mas 'fechado' não significa 'caixa preta'. O bot tem o comando /ask: você faz uma pergunta sobre a estrutura do jogo ou um pedaço específico da lógica – e o assistente de IA (apenas leitura, sem acesso à infraestrutura interna e segredos) explica como funciona. Quer entender como a linha de visão é estruturada ou por que o inimigo reagiu exatamente assim – pergunte, sem abrir o repositório.
Já que este é um experimento, e não uma publicidade, aqui está minha lista pessoal de apostas sobre o que quebrará primeiro (verificaremos juntos): O débito técnico aumentará mais rápido do que se imagina. Suspeito que as primeiras dezenas de tarefas passarão bem, e depois começará o 'por que existem três módulos quase idênticos aqui'. A questão é: em qual tarefa e se isso é visível nas métricas com antecedência. A carga sobre o ser humano não desaparecerá, mas mudará de lugar. Provavelmente, deixarei de ser necessário na codificação e serei necessário na formulação e na resolução de conflitos. É interessante em qual estágio meu tempo irá vazar. A maioria das falhas ocorrerá nas junções, e não dentro das fases – no esclarecimento de requisições vagas e na formulação. Alguém definitivamente tentará quebrar a sandbox ou injetar algo através da requisição. Eu conto com isso – para isso servem o isolamento e a contenção. Se você leu esta lista e pensa 'mas você também terá problemas aqui', ótimo, escreva nos comentários, adicionarei à lista de apostas.
O experimento precisa de um fluxo de requisições real e realista – caso contrário, não há nada para medir. Portanto, o convite é específico: Pontos de entrada: bot com modos 'desenvolvimento' e 'perguntas', jogo e chat 🎮 Apenas jogar – abrir o build ativo: ✅ https://tacticops.gitlab.io/ 🤖 Enviar uma modificação no jogo – o principal que dá combustível ao experimento: bot ✅ @ai_pipeline_request_bot. Escreva o que adicionar, consertar ou mudar – e acompanhe como sua requisição passa pelo pipeline. ❓ Entender o jogo sem abrir o código – comando /ask no mesmo bot: o assistente de IA explicará a lógica e a estrutura do jogo (apenas leitura). 📋 Ver o pipeline em tempo real – quadro público com todas as tarefas e fases (somente leitura): ✅ https://gitlab.com/tacticops/public 💬 Acompanhar e discutir – grupo do Telegram do experimento: ✅ @ai_native_pipeline_chat O que me comprometo a dar em troca do seu tempo: honestidade. Todas as requisições, toda a correspondência sobre elas, todos os status e todo o changelog – são públicos por design. Ao final de aproximadamente 60 dias, apresentarei um catálogo do que quebrou e por quê, com números e um diário de decisões. Sem 'revolução', sem 'IA substituirá desenvolvedores' – apenas um n-of-1 cuidadosamente medido sobre o que realmente acontece com o produto e a base de código quando o desenvolvimento é conduzido por um pipeline autônomo. Venham quebrar. É o mais útil.
P.S. Esta não é uma receita de produção e muito menos um convite para fazer isso no seu trabalho. Para um único desenvolvedor, toda essa infraestrutura é um exagero, e isso faz parte do sentido: eu não construí o 'método ideal de codificar com IA', mas um ambiente mensurável onde se pode ver onde o desenvolvimento autônomo falha. Se, no decorrer, descobrir que falha em tudo e imediatamente – isso também é um resultado, e escreverei honestamente sobre isso.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, Habr! Meu nome é Alexey Fyodorov, tenho 40 anos e nos últimos quatro anos atuei como Head of IT em uma fintech em rápido crescimento. Tenho 22 anos de experiência em desenvolvimento e duas trajetórias completas de Junior a CIO: primeiro como desenvolvedor 1C em negócios de produção, depois, aos 27 anos, comecei como Junior em fintech e cresci para CIO novamente. Para que fique claro de onde venho ao discutir 'IA escrevendo código em produção': desenvolvemos um custodiante para gerenciamento híbrido de carteiras quentes e frias, que em seus primeiros dois anos foi integrado por três das dez maiores exchanges de criptomoedas por volume; em 2015, lançamos um terminal web para Freedom Finance (então NetTrader), que permaneceu praticamente inalterado desde então; e fomos um dos primeiros na Rússia a lançar um aplicativo móvel de corretora simultaneamente em web, iOS e Android com uma única base de código. Ou seja, não sou um evangelista nem um caçador de hype. Sou alguém que, por vinte anos, foi responsável por garantir que o código de terceiros não derrubasse a produção onde o dinheiro está. E é exatamente por isso que me interessei em realizar o seguinte experimento.
O que está acontecendo ao nosso redor é compreensível. Todos já experimentaram o 'vibe coding' – alguns por diversão no fim de semana, outros seriamente. E os gerentes de nível C, após verem as demonstrações, agora exigem 'integrar IA ao desenvolvimento de todas as formas possíveis', de preferência para ontem. Familiar? Para mim, muito. O problema é que entre 'IA montou um protótipo em uma hora' e 'IA gerencia o desenvolvimento real de um produto com usuários ativos' existe um abismo sobre o qual há poucos dados honestos. Quando a tarefa é maior que um 'hello-world', o interessante começa: duplicação de lógica, débito técnico se espalhando, regressões, revisões que consomem todo o tempo economizado. Há muitas declarações grandiosas sobre crescimento exponencial de produtividade. Observações independentes e cuidadosamente medidas são poucas. Por isso, decidi não discutir nos comentários, mas montar um ambiente e ver com meus próprios olhos: como um pipeline autônomo de SDLC nativo de IA afeta tanto o produto quanto a base de código – incluindo o débito técnico – quando um fluxo real e vivo de requisições de pessoas externas passa por ele. E convido vocês a participarem deste experimento para descobrirmos os resultados juntos.
Para ser concreto, veja o que está acontecendo agora. Tenho um jogo de navegador – uma tática top-down sobre a invasão de um prédio por uma pequena unidade (no estilo Door Kickers). Ele está ativo: você abre o link e joga. Qualquer pessoa pode acessar um bot do Telegram e pedir para mudar algo no jogo: 'faça os inimigos mais atentos ao barulho', 'adicione uma espingarda', 'conserte o bug da porta', 'novo mapa com esta geometria'. Em seguida, a requisição é capturada por um pipeline autônomo. Ele esclarece a tarefa com o autor, a formula, projeta, escreve o código, executa testes, realiza revisões – e, se tudo estiver verde, implementa a mudança no build geral em produção, que todos os outros jogadores veem instantaneamente. O detalhe chave, pelo qual estou escrevendo este texto: a barreira final antes do release é a verificação automática de políticas, sem revisão manual de código. Eu, um ser humano, não leio os diffs antes do merge. O código gerado por solicitação de um estranho vai para a produção geral, e nenhum ser humano o viu. Soa, eu sei, como a descrição de um desastre. 'Código arbitrário de estranhos em produção ativa' – esse é exatamente o cenário que faz qualquer um responsável pela produção ter um tique nervoso. Eu também. Mas é sobre isso que trata o próprio experimento.
Agora, honestamente sobre o escopo, porque isso não é uma apresentação de produto acabado. Este é um experimento com foco em pesquisa, um estudo de caso n-of-1, com um horizonte de cerca de 60 dias. N-of-1 é um termo da metodologia de pesquisa: 'amostra de tamanho um'. Um pipeline, um jogo, um fluxo de tarefas, um mantenedor. Disso decorre imediatamente o que eu não posso e não farei: tirar leis universais do tipo 'o desenvolvimento com IA se degrada após N tarefas'. Isso não pode ser provado com uma única execução. Os mecanismos – 'o que exatamente quebrou e por quê' – podem ser descritos de forma justa e interessante a partir de um estudo de caso. Frequência e generalizações – apenas como hipóteses, com um convite explícito para refutá-las. O jogo aqui não é o objetivo, mas uma plataforma: é necessário para obter um fluxo barato e claro de requisições reais e diversas de pessoas reais. O objetivo é observar o próprio pipeline. O que estou medindo (desde o início, a partir da linha de base t0 = jogo inicial): Para onde a carga humana se desloca ao longo do tempo e pelas fases. Não 'quantas horas-homem são necessárias' – essa é justamente a questão em aberto que não me proponho a fechar com um número – mas em que direção se move: em quais fases sou necessário no início, em quais após um mês, minha participação cresce ou diminui e onde exatamente. O que acontece com a saúde da base de código: churn, duplicação, complexidade, cobertura, defeitos e incidentes. Degrada, se mantém ou evolui – e após quantas tarefas isso é visível. A vazão: tarefas por dia, taxa de sucesso, em quais fases o pipeline mais tropeça, o custo por tarefa. O que eu NÃO prometo: conclusões. Ainda não há – o experimento está apenas começando. Não vou forçar um caso único em uma tendência. Cada mudança de modelo, instrução ou verificação será versionada em um diário de decisões com justificativa e timestamp – caso contrário, seria um post de blog 'me pareceu', e não uma observação que pode ser verificada. A única coisa concreta que me comprometo a apresentar ao final é um catálogo de pontos problemáticos do SDLC nativo de IA: onde exatamente e como esse método de desenvolvimento quebra, ancorado em métricas registradas e um diário, e não em impressões. E sim – espero antecipadamente que muitas coisas quebrem. Isso não é um risco do experimento, é o seu conteúdo.
Se removermos os detalhes, a requisição passa por um pipeline de fases, e cada uma é visível em um quadro público em tempo real: Requisição – o jogador cria a requisição no bot. Moderação da Requisição – eu, como mantenedor, a aprovo. Este é o primeiro filtro de intenção: olho a entrada antes que a IA a veja. Esclarecimento com o autor – o pipeline faz perguntas se algo não estiver claro. Coleta de respostas. Moderação das respostas – um filtro semelhante, agora para as respostas do autor. Formulação final da tarefa – e esta é a fronteira de confiança. Daqui para baixo no pipeline, apenas a formulação aprovada vai, e nunca a história bruta da conversa. Esta é a proteção chave contra prompt injection: texto não confiável do jogador não entra no contexto do modelo como instrução. Análise – análise de sistema e de testes, além de verificação de conflito com a direção do jogo. Implementação – o agente escreve código seguindo TDD. Revisão. Teste – executa CI, não o agente. Done – merge no main e deploy contínuo. Entre as fases, existem loops de feedback (refinamento, re-esclarecimento, cancelamento pelo autor), e as tarefas são executadas estritamente uma por vez, em um único fluxo. Isso não é uma limitação da abordagem em si – pode-se paralelizar –, mas uma limitação consciente de orçamento e infraestrutura: uma pequena tentativa de controlar os gastos. Um benefício colateral: não há conflitos de merge, e cada mudança é facilmente atribuível de forma honesta. Separadamente sobre os papéis do modelo: cada fase (esclarecimento, formulação, análise, implementação, revisão) mantém seu prompt em um arquivo de template separado e versionado. O código apenas insere parâmetros – não há 'lógica de prompt' no código. Isso é necessário para que, posteriormente, seja possível dizer honestamente qual instrução específica em qual etapa levou a quê.
O código do jogo em si eu mantenho fechado, e isso é intencional – para a pureza do experimento. A ideia é que as modificações venham como requisições em linguagem natural, e não como diffs prontos: eu meço o trabalho do pipeline, não os pull requests de terceiros. Se o código fosse aberto, o fluxo se transformaria em desenvolvimento open-source comum, e não haveria nada para observar. Mas 'fechado' não significa 'caixa preta'. O bot tem o comando /ask: você faz uma pergunta sobre a estrutura do jogo ou um pedaço específico da lógica – e o assistente de IA (apenas leitura, sem acesso à infraestrutura interna e segredos) explica como funciona. Quer entender como a linha de visão é estruturada ou por que o inimigo reagiu exatamente assim – pergunte, sem abrir o repositório.
Já que este é um experimento, e não uma publicidade, aqui está minha lista pessoal de apostas sobre o que quebrará primeiro (verificaremos juntos): O débito técnico aumentará mais rápido do que se imagina. Suspeito que as primeiras dezenas de tarefas passarão bem, e depois começará o 'por que existem três módulos quase idênticos aqui'. A questão é: em qual tarefa e se isso é visível nas métricas com antecedência. A carga sobre o ser humano não desaparecerá, mas mudará de lugar. Provavelmente, deixarei de ser necessário na codificação e serei necessário na formulação e na resolução de conflitos. É interessante em qual estágio meu tempo irá vazar. A maioria das falhas ocorrerá nas junções, e não dentro das fases – no esclarecimento de requisições vagas e na formulação. Alguém definitivamente tentará quebrar a sandbox ou injetar algo através da requisição. Eu conto com isso – para isso servem o isolamento e a contenção. Se você leu esta lista e pensa 'mas você também terá problemas aqui', ótimo, escreva nos comentários, adicionarei à lista de apostas.
O experimento precisa de um fluxo de requisições real e realista – caso contrário, não há nada para medir. Portanto, o convite é específico: Pontos de entrada: bot com modos 'desenvolvimento' e 'perguntas', jogo e chat 🎮 Apenas jogar – abrir o build ativo: ✅ https://tacticops.gitlab.io/ 🤖 Enviar uma modificação no jogo – o principal que dá combustível ao experimento: bot ✅ @ai_pipeline_request_bot. Escreva o que adicionar, consertar ou mudar – e acompanhe como sua requisição passa pelo pipeline. ❓ Entender o jogo sem abrir o código – comando /ask no mesmo bot: o assistente de IA explicará a lógica e a estrutura do jogo (apenas leitura). 📋 Ver o pipeline em tempo real – quadro público com todas as tarefas e fases (somente leitura): ✅ https://gitlab.com/tacticops/public 💬 Acompanhar e discutir – grupo do Telegram do experimento: ✅ @ai_native_pipeline_chat O que me comprometo a dar em troca do seu tempo: honestidade. Todas as requisições, toda a correspondência sobre elas, todos os status e todo o changelog – são públicos por design. Ao final de aproximadamente 60 dias, apresentarei um catálogo do que quebrou e por quê, com números e um diário de decisões. Sem 'revolução', sem 'IA substituirá desenvolvedores' – apenas um n-of-1 cuidadosamente medido sobre o que realmente acontece com o produto e a base de código quando o desenvolvimento é conduzido por um pipeline autônomo. Venham quebrar. É o mais útil.
P.S. Esta não é uma receita de produção e muito menos um convite para fazer isso no seu trabalho. Para um único desenvolvedor, toda essa infraestrutura é um exagero, e isso faz parte do sentido: eu não construí o 'método ideal de codificar com IA', mas um ambiente mensurável onde se pode ver onde o desenvolvimento autônomo falha. Se, no decorrer, descobrir que falha em tudo e imediatamente – isso também é um resultado, e escreverei honestamente sobre isso.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
