Pro-Coding Assistido: Como a IA Multiplica a Produtividade de Programadores Experientes

Uma coisa mudou bastante no desenvolvimento de software nos últimos anos.

Não foi a linguagem. Não foi o compilador. Não foi o surgimento de mais um framework JavaScript.

Foi o custo de transformar uma decisão técnica em código.

A Inteligência Artificial muda essa equação.

Mas existe uma diferença fundamental entre usar IA para programar e simplesmente pedir para uma IA "criar um software".

Essa diferença é o que chamo de Pro-Coding Assistido.

Não é Low-Code. Não é No-Code. E também não é colocar um agente para escrever milhares de linhas enquanto o desenvolvedor torce para funcionar.

É outra coisa.

O desenvolvedor continua sendo responsável pela arquitetura, pelas decisões técnicas, pela escolha das abstrações, pelos limites do sistema, pela análise dos bugs e pela revisão do código. A IA entra como uma camada de aceleração extremamente agressiva sobre esse processo.

O código continua sendo código de verdade.

E, quando o programador sabe exatamente o que está fazendo, a diferença de velocidade pode ser brutal.

O Flux File Manager como estudo de caso

Um bom exemplo disso é o Flux File Manager, um gerenciador de arquivos para Linux desenvolvido em Rust.

A proposta do Flux é relativamente simples na superfície: ser rápido, minimalista e eficiente.

Só que um gerenciador de arquivos moderno deixa rapidamente de ser um projeto simples quando você começa a olhar para aquilo que acontece por baixo da interface.

Isso não é uma aplicação CRUD.

Não é um formulário conectado a uma API.

É um software que precisa conversar com o sistema operacional, filesystem, dispositivos, protocolos de rede, processos, threads, eventos, GPU, bibliotecas nativas e diferentes modelos de I/O.

E é justamente nesse tipo de projeto que a discussão sobre IA fica mais interessante.

Porque gerar código não é o maior problema.

Entender o sistema é.

Seis meses contra uma organização inteira

O Flux foi desenvolvido sozinho em aproximadamente seis meses utilizando o modelo de Pro-Coding Assistido.

Essa informação, isoladamente, não significa que "um desenvolvedor é dez vezes melhor que dez desenvolvedores".

Seria uma conclusão simplista.

A comparação interessante está em outro lugar.

Em uma estrutura corporativa tradicional, antes da popularização desse tipo de assistência por IA, um projeto com essa abrangência poderia exigir uma equipe multidisciplinar envolvendo desenvolvimento de backend, interface, QA e especialistas em sistemas.

Uma estimativa plausível, para o cenário descrito, seria algo próximo de dez pessoas trabalhando durante até dois anos.

Essa é uma estimativa comparativa, não uma medição controlada.

E existe uma razão para a diferença potencial ser tão grande.

O custo de desenvolvimento de software nunca foi apenas escrever código.

Existe o custo de comunicação.

Um desenvolvedor precisa explicar para outro desenvolvedor o que está fazendo. Um especialista precisa explicar para o responsável pela interface como determinada API funciona. QA encontra um comportamento que precisa ser reproduzido. O responsável pelo módulo tenta reproduzir o problema. Alguém altera uma abstração. Outro componente quebra.

E começa a investigação.

É exatamente aqui que a famosa Lei de Brooks continua relevante: adicionar pessoas a um projeto de software complexo não produz uma aceleração linear.

Mais pessoas significam mais canais de comunicação.

Mais contexto precisa ser compartilhado.

Mais decisões precisam ser sincronizadas.

Mais interfaces existem entre componentes.

Mais possibilidade de alguém corrigir um problema enquanto outro introduz outro.

No desenvolvimento assistido por IA existe uma configuração radicalmente diferente.

Um único desenvolvedor pode manter o contexto arquitetural inteiro na cabeça.

Não existe reunião para explicar a arquitetura para outro desenvolvedor.

Não existe handoff.

Não existe "vou perguntar para o cara responsável por esse módulo".

O programador decide.

A IA implementa.

O programador revisa.

A IA ajusta.

O programador testa.

E quando alguma coisa quebra, o mesmo indivíduo possui o contexto necessário para investigar o problema.

Essa redução do atrito de comunicação pode ser tão importante quanto a própria geração automática de código.

Pro-Coding não é Low-Code

Existe uma confusão recorrente quando se fala sobre produtividade com IA.

Muita gente imagina que o futuro será uma espécie de Low-Code com uma caixa de texto no lugar dos botões.

Não é isso.

Low-Code tenta reduzir a quantidade de código que precisa ser escrito através de abstrações visuais e componentes pré-construídos.

Pro-Coding Assistido faz praticamente o contrário.

Ele preserva a possibilidade de descer até o nível mais baixo necessário.

Você continua escolhendo Rust.

Continua escolhendo Tokio.

Continua decidindo onde existe concorrência.

Continua escolhendo quando usar Rayon.

Continua definindo a arquitetura do VFS.

Continua decidindo como os erros devem atravessar as camadas.

Continua olhando para ownership, lifetimes, locks, channels, processos e syscalls quando necessário.

A diferença é que você não precisa necessariamente digitar tudo isso manualmente.

A IA funciona como uma espécie de força de trabalho cognitiva auxiliar.

Ela pode escrever uma implementação inicial.

Pode transformar uma ideia em boilerplate.

Pode gerar testes.

Pode pesquisar rapidamente uma API.

Pode propor alternatives.

Pode refatorar dezenas de arquivos.

Pode analisar logs.

Pode fazer uma primeira tentativa de encontrar a origem de uma falha.

Mas existe uma diferença enorme entre produzir uma implementação e saber se aquela implementação está correta.

Essa diferença continua pertencendo ao engenheiro.

A IA acelera quem já sabe programar

Existe uma característica curiosa da IA para programação.

Ela não distribui produtividade de maneira uniforme.

Um programador iniciante pode pedir:

"Crie um sistema assíncrono para processar arquivos em paralelo."

E receber centenas de linhas de código aparentemente convincentes.

O problema começa quando aquilo apresenta deadlock.

Ou privação de recursos.

Ou race condition.

Ou bloqueia o executor assíncrono.

Ou mantém uma referência viva por tempo demais.

Ou introduz uma chamada bloqueante dentro de uma thread que deveria permanecer responsiva.

Nesse momento, gerar código deixa de ser suficiente.

É preciso entender o que está acontecendo.

Um programador experiente olha para a arquitetura, identifica o modelo de execução, entende as propriedades de concorrência e começa a reduzir o problema.

A IA pode ajudar durante todo esse processo.

Mas ela não elimina a necessidade de alguém saber fazer essas perguntas.

Esse é provavelmente um dos maiores paradoxos da programação assistida por IA:

quanto mais conhecimento técnico o programador possui, mais poderosa a ferramenta se torna.

O conhecimento não desaparece.

Ele muda de função.

Antes, o conhecimento era utilizado principalmente para escrever o código.

Agora, ele também é utilizado para dirigir, avaliar e corrigir o código produzido pela IA.

O programador deixa de ser apenas um executor.

Passa a atuar simultaneamente como arquiteto, Tech Lead, debugger e revisor.

O problema não é gerar código. É julgar código.

Uma IA pode escrever uma função perfeita.

Também pode escrever uma função que parece perfeita.

Essa segunda situação é muito mais perigosa.

Código gerado por IA frequentemente funciona no caso feliz.

O problema aparece no caso que ninguém colocou no prompt.

Um filesystem desmontado no meio da operação.

Uma conexão de rede que desaparece.

Um arquivo sendo removido enquanto está sendo indexado.

Uma thread esperando um recurso que nunca será liberado.

Um canal sendo fechado em uma ordem inesperada.

Um lock adquirido por uma arquitetura e liberado por outra.

Uma operação síncrona escondida dentro de um fluxo assíncrono.

Um erro que aparece apenas em determinada arquitetura.

É aí que experiência faz diferença.

No desenvolvimento do Flux, problemas desse tipo não podem ser resolvidos simplesmente perguntando para a IA:

"Por que isso não funciona?"

A pergunta precisa ser muito mais específica.

Qual thread está executando?

Quem possui esse recurso?

Qual é o ciclo de vida desse objeto?

Onde ocorre o bloqueio?

Qual executor está processando essa tarefa?

Existe back-pressure?

Qual é a ordem possível dos eventos?

O problema é determinístico?

Existe uma condição de corrida?

Qual hipótese foi invalidada pelo teste?

A qualidade da resposta da IA depende, em grande parte, da qualidade da investigação conduzida pelo engenheiro.

A ferramenta acelera a investigação.

Ela não substitui o investigador.

O fim do tempo morto

Talvez essa seja a mudança mais subestimada.

Durante muito tempo, programar significava passar uma quantidade absurda de tempo fazendo coisas que não exigiam necessariamente raciocínio profundo.

Escrever getters.

Criar estruturas.

Montar interfaces.

Adaptar tipos.

Escrever testes repetitivos.

Consultar documentação.

Procurar a assinatura exata de uma API.

Transformar um formato de dados em outro.

Criar código de integração.

Fazer refactors mecânicos.

Não existe nada intelectualmente especial em digitar a mesma estrutura cinquenta vezes.

Mas isso consome tempo.

A IA elimina uma parte significativa desse trabalho.

E existe um efeito colateral importante.

Ela reduz o tempo morto entre uma decisão e sua implementação.

O programador pensa em uma solução.

Antes, poderia passar vinte minutos ou duas horas transformando aquilo em código.

Agora, pode descrever a intenção, receber uma implementação inicial e imediatamente começar a revisar.

O ciclo fica muito mais curto:

pensar → implementar → testar → observar → corrigir.

E isso acontece dentro do mesmo contexto mental.

Não existe a necessidade de transferir a ideia para outra pessoa.

Não existe espera.

Não existe backlog interno de pequenas tarefas que precisam ser feitas antes de chegar no problema realmente interessante.

O desenvolvedor permanece concentrado na arquitetura.

Esse ganho parece pequeno quando analisado tarefa por tarefa.

Quando acumulado durante seis meses, ele se torna enorme.

O verdadeiro multiplicador é o contexto

Existe ainda outro fator.

Um projeto grande possui contexto.

Muito contexto.

Decisões antigas.

Convenções.

Limitações.

Workarounds.

Dependências.

Comportamentos específicos do sistema operacional.

Partes do código que parecem estranhas mas existem por uma razão.

Quando uma equipe cresce, esse contexto precisa ser distribuído.

Documentado.

Explicado.

Repassado.

Atualizado.

E mesmo assim sempre existe perda.

Um desenvolvedor conhece determinada parte do sistema profundamente. Outro conhece outra. Um terceiro conhece o comportamento de uma biblioteca específica.

O conhecimento fica fragmentado.

Em um projeto solo assistido por IA, existe uma possibilidade diferente.

O mesmo engenheiro pode manter a visão global do sistema.

A IA não precisa substituir essa visão.

Ela trabalha embaixo dela.

Esse talvez seja o aspecto mais poderoso do modelo.

A IA não precisa "saber construir o Flux inteiro".

Ela precisa ser capaz de ajudar o engenheiro a construir cada parte do Flux enquanto o engenheiro mantém a visão do todo.

É uma relação assimétrica.

A máquina possui velocidade de produção.

O humano possui responsabilidade arquitetural.

O que muda para a profissão

Isso coloca uma pergunta desconfortável para a indústria.

Se um engenheiro experiente consegue produzir em seis meses algo que tradicionalmente exigiria uma equipe muito maior, o que exatamente estamos chamando de produtividade?

Talvez estejamos medindo a coisa errada.

Durante anos, produtividade em software foi associada a número de desenvolvedores, linhas de código, tickets fechados, story points e quantidade de tarefas entregues.

A IA quebra várias dessas métricas.

Um desenvolvedor pode produzir milhares de linhas em minutos.

Isso não significa que está sendo produtivo.

Pode significar apenas que produziu milhares de linhas.

A produtividade real continua sendo a capacidade de transformar requisitos em software correto, sustentável e funcional.

A diferença é que agora o custo de produção desse software pode cair drasticamente.

Isso favorece justamente quem possui uma base técnica sólida.

O programador que entende arquitetura consegue delegar implementação.

O programador que entende concorrência consegue revisar código concorrente.

O programador que conhece Linux consegue perceber quando a solução da IA não respeita o modelo de execução do sistema.

O programador que conhece Rust consegue identificar quando uma abstração está lutando contra o ownership em vez de trabalhar com ele.

O programador que conhece sistemas consegue olhar para um bug aparentemente aleatório e formular uma hipótese.

A IA fornece velocidade.

A experiência fornece direção.

O próximo programador não será aquele que escreve mais código

Talvez o perfil mais valioso dos próximos anos não seja o programador que consegue produzir código mais rapidamente.

Isso uma máquina já faz muito bem.

O diferencial será aquele que consegue olhar para um sistema complexo e dizer:

"Não. Esse caminho está errado."

E explicar exatamente por quê.

Esse profissional será capaz de definir a arquitetura, dividir problemas, escolher abstrações, antecipar falhas, supervisionar agentes, revisar implementações e investigar bugs que não aparecem nos exemplos bonitos usados nos prompts.

Isso é Pro-Coding Assistido.

Não é entregar o desenvolvimento para uma IA.

É usar a IA para remover o trabalho mecânico que existia entre o pensamento do engenheiro e o software funcionando.

No caso do Flux File Manager, seis meses de desenvolvimento solo mostram o potencial desse modelo quando existe domínio técnico suficiente para conduzir o processo.

A IA não construiu o sistema sozinha.

Ela tornou muito mais barato transformar decisões de engenharia em código.

E talvez essa seja a parte que ainda estamos subestimando.