Uma fábrica de software é um ciclo repetível em torno do trabalho de software. Se você está construindo uma fábrica de software, código bom o suficiente para ser lançado ainda precisa de gosto humano e responsabilidade. Vamos discutir isso, incluindo se você precisa de uma fábrica agora.
Se sim:
- Você provavelmente precisará de humanos no início para decidir sobre a intenção do produto, o design do sistema (se isso importa) e seu padrão de qualidade.
- Faça revisão de código (fábrica com luzes acesas), mas seja intencional sobre onde ela é mais necessária. Descobri que você precisa ficar de olho em onde a pressão automatizada falha. Ou onde compensações de manutenibilidade precisam ser feitas.
- Busque que as verificações de qualidade aconteçam o mais cedo e continuamente possível. Nem todas precisam ser assim, mas isso inclui sistemas de tipos, testes automatizados, testes de mutação, scanners de segurança e linters para regras de arquitetura.
- Número de verificações != qualidade. Você provavelmente precisará experimentar quais verificações lhe dão a melhor relação sinal-ruído. Esteja pronto para apertar ou relaxar suas restrições deliberadamente.
Você quer construir sua fábrica para que alguns aspectos do gosto humano sejam codificados no ambiente, o agente lhe forneça evidências de que seu trabalho está correto e onde um humano ainda "é dono" do que vai para produção.
Você realmente precisa de uma fábrica de software?
Na minha experiência, você pode ir surpreendentemente longe com seu harness de codificação padrão! i.e. Claude Code ou Codex, múltiplas sessões, boas especificações com verificação embutida e restrições. Você pode até jogar um lote de issues do GitHub neles com critérios de implementação e envolvimento humano. As rotinas do Claude Code e os agentes em nuvem do Copilot/Codex já lhe dão um loop agendado ou orientado a eventos sem infraestrutura personalizada.
Uma fábrica vale a pena quando você precisa de execuções consistentes e repetíveis, passar trabalho entre agentes, impedir que duas sessões peguem a mesma issue, manter evidências e pausar a produção quando as revisões estão atrasadas.
Então, comecei dizendo que uma fábrica de software é um ciclo repetível em torno do trabalho de software. Podemos, na verdade, olhar para um prompt que demonstra um ciclo de fábrica muito pequeno aqui:
Leia a issue #123 do GitHub e as instruções do repositório antes de alterar o código.
Implemente apenas os critérios de aceitação declarados. Não modifique autenticação, cobrança, migrações ou asserções de teste existentes. Trabalhe em um branch e mantenha o diff revisável.
Execute npm run lint, npm test e npm run build. Se uma verificação necessária não puder ser executada, pare e explique o porquê. Abra um pull request rascunho com as verificações que você executou, os riscos restantes e qualquer decisão que um humano ainda precise tomar. Não faça merge.
Um objetivo pode manter isso em movimento até que as verificações passem e possamos consultar as issues do GitHub em busca de labels específicos ou revisar pull requests abertos a cada manhã. A proteção de branch poderia impor um limite de merge e o humano pode permanecer no loop escolhendo o que fica pronto, revisando e tomando as decisões finais de merge, etc.
Adicione uma fábrica de software quando você precisar de uma fila de trabalho orientada a eventos (ex.: gatilhos do Slack, issues do GitHub, Linear, um backlog) para ser executada em um ambiente de nuvem isolado para lidar com triagem, implementação e testes com alguma supervisão humana explícita. Alguns terminam seu loop com um agente monitor que observa a produção e abre issues que são triadas novamente.
Na minha experiência, a fábrica se torna útil quando a parte difícil é fazer suas diferentes execuções se comportarem de forma consistente, passar o trabalho entre agentes e evitar que diferentes sessões reivindiquem a mesma issue, preservando evidências e parando a produção quando a revisão humana está atrasada.
O que resolve isso pode parecer um pouco chato. Por exemplo, a Warp menciona triar cada issue recebida em um de quatro estados - pronto-para-implementar, pronto-para-especificar, precisa-info, esperar-para-implementar - e o label é o que dispara o próximo agente.
Este label faz alguns trabalhos de uma só vez: é a fila, o bloqueio e, como uma sessão só pega o que está marcado como pronto, é onde um humano pode estacionar coisas sem dizer não permanentemente.
Em termos de fluxo de trabalho, existem algumas semelhanças e diferenças em relação a apenas usar Claude/Codex:
- Direcionamento: o agente precisa de correção de curso, você pode dar entrada e redirecioná-lo
- Notificações: como a fábrica diz que está bloqueada. Isso pode ser porque um requisito era ambíguo, começou algo arriscado ou precisa de entrada humana (direcionamento)
- Handoff: mover a tarefa, seu estado e contexto entre a fábrica em nuvem/outro agente/revisor humano. Bons handoffs manterão o controle do que aconteceu, o que falta ser feito e por que o handoff é necessário.
Em uma boa fábrica, o humano não se limita apenas a revisar e aprovar o diff final no final. Eles podem moldar o trabalho no início, direcioná-lo durante a implementação, passá-lo por um handoff ou impedi-lo de ser enviado para produção.
A verificação é onde uma fábrica responsável gasta muito do seu tempo. Vamos cobrir isso mais adiante.
Se você decidir que precisa de uma fábrica de software, construí-la não é a única opção. Montar a infraestrutura para escalar uma fábrica pode dar muito trabalho e você pode querer considerar comprar vs. construir. Factory.ai, Devin, Warp e HumanLayer todos vendem partes desse ciclo.
Onde eu realmente concentro minha atenção
Minha experiência diária de desenvolvimento de software mudou muito no último ano. Tenho falado cada vez mais sobre fazer muito trabalho paralelo com agentes, caminhando para ter uma fábrica de software com luzes acesas. E muitas pessoas têm me perguntado: o que essas coisas realmente significam? O que você está construindo? Que tipos de projetos você está usando essas coisas? É muito disso:
Então, em um dia bem comum, tenho uma fábrica de software com luzes acesas mais simples. Posso ter tarefas sendo executadas na nuvem. Metade dessas tarefas pode estar trabalhando em aplicativos clientes de produção com empresas menores com as quais estou trabalhando. Eles terão usuários reais. Eles terão autenticação real, pagamentos, assinaturas, riscos reais e pesados com os quais você precisa ter cuidado. Você não pode simplesmente dizer: "ah, agente, vá e faça essas coisas" sem ter testes, restrições e verificações de qualidade em vigor.
Posso trabalhar em meus projetos de código aberto. Posso estar construindo sites complementares para meus livros. Posso estar trabalhando em ferramentas. Posso estar construindo meus próprios aplicativos. E esses são todos tipos muito, muito diferentes de aplicativos nos quais estou trabalhando. E às vezes tudo o que eles têm em comum é a ferramenta que estou usando para trabalhar neles, certo? Talvez eu esteja trabalhando em uma migração. Outras vezes, posso estar fazendo trabalho pesado de funcionalidades. E o raio de explosão do trabalho também pode ser muito, muito diferente.
Então, ao começar a pensar em chegar a um lugar onde estamos cada vez mais fazendo muito trabalho paralelo, tentando melhorar a velocidade, tentando melhorar a produtividade e tentando melhorar a autonomia, o que significa levar o sistema a um lugar onde confiamos mais nele, você tem que pensar sobre quais são os lugares que absolutamente exigem revisão de código humana, entrada humana.
E muito disso será necessário no início, certo? Quando você está definindo sua especificação, seus requisitos, como será o design do produto? Como será a intenção do produto? E então, como você está verificando se os agentes realmente fizeram o trabalho corretamente? Como você está verificando se eles não quebraram o sistema existente que estava em vigor? Como você está garantindo que está atendendo ao seu padrão de qualidade?
E assim, gerar código não é necessariamente a parte com a qual você mais precisa se preocupar. Com contexto suficiente, os agentes podem escrever a implementação, executar os testes, inspecionar falhas e revisar o código para nós. Precisamos chegar a um lugar onde sintamos que há gosto humano suficiente codificado no ambiente para que possamos confiar no que está sendo construído, para que nossa atenção humana possa ser focada nos lugares onde é mais necessária.
Agora, há resistência de pessoas que dizem: "ei, bem, não acredito que você pode simplesmente automatizar grande parte disso." Não é para dizer que estamos automatizando tudo, certo? Mas dado o volume de código que está sendo gerado, não acho que seja realista para os humanos lerem tudo, especialmente quando não estamos construindo foguetes na maioria das vezes, certo? Estamos construindo UI, estamos construindo aplicações full stack.
Nosso julgamento, nosso gosto é melhor focado nos lugares onde é mais necessário. Tipo, quais são as partes mais arriscadas dos sistemas? Onde precisamos aplicar o gosto humano? E isso pode ser no front-end. Pode ser em como o sistema funciona. Não precisa ser 100% dele.
Minha largura de banda cognitiva não escala com os agentes
A realidade é que, sim, podemos agora iniciar dezenas, centenas, milhares de agentes em paralelo, mas sua própria largura de banda cognitiva não escala da mesma forma. Isso pode alimentar uma dívida cognitiva ou de compreensão, sobre a qual já falei antes.
Se você se lembra de apenas cinco, dez anos atrás, havia muita discussão na comunidade de engenharia sobre mudança de contexto e seu custo. Falávamos sobre como as pessoas odiavam quando um colega ou alguém se aproximava da sua mesa quando você estava no meio de uma tarefa. Levava muito tempo para você voltar ao seu estado de fluxo, porque você tinha que se atualizar: onde eu estava? O que eu estava fazendo? Mesmo que houvesse um pouco de resíduo, ainda levava tempo.
Agora estamos mudando de contexto ainda mais do que antes. Em qualquer dia, se estou trabalhando fora de uma fábrica de software, posso estar trabalhando em cinco ou dez projetos diferentes com agentes ao mesmo tempo, ou cinco ou dez funcionalidades diferentes em um único projeto por vez. Posso ter cinco ou dez sessões diferentes, pode-se dizer.
Isso significa que tenho que ser capaz de acompanhar pelo menos algumas delas. É possível que eu consiga aumentar a autonomia que dou a algumas tarefas se confiar que defini a tarefa bem o suficiente, defini o resultado, como ela vai verificar se foi bem feita. Mas então haverá tarefas onde talvez eu não me sinta necessariamente assim e haja mais risco envolvido ou mais nuances. Vou ter que prestar atenção.
Considere otimizar a fábrica de software para seu revisor. Dado que cada uma dessas abordagens ainda direciona sua saída para a atenção de uma pessoa, você deve perguntar o quanto a fábrica está barateando as decisões que você ainda precisa tomar.
Um erro de projeto errado
Lembro-me de quando trabalhei em vários projetos paralelos com meus agentes, e houve momentos em que acidentalmente fiz coisas como: talvez eu estivesse trabalhando em um aplicativo web onde queria adicionar um modo escuro, e então eu tinha em minha cabeça: "ok, bem, é assim que a forma disso precisa ser". Mas acidentalmente fui para a sessão de um projeto diferente e comecei a colocar o mesmo prompt.
Então, comecei a implementar o modo escuro para algo que absolutamente não precisava. E então posso cometer esse erro. Não quero que minha fábrica de software cometa esse tipo de erro.
Você precisa pensar sobre isso realmente em termos de um sistema. Você está efetivamente tentando codificar uma cultura de engenharia de software, uma cultura de equipe, em um sistema para que ele tenha os mesmos tipos de comportamentos, para que tenha uma responsabilidade que pertença a algum lugar, para que alguém ainda seja responsável pelo que acontece, e você está sendo muito explícito sobre como pensa sobre essas coisas.
Quando o verde é enganoso
Mesmo nesses sistemas, você quer ter muito cuidado, certo? Muitos de nós já vimos que, quando você pede à IA para ajudá-lo a passar em um teste, como um teste de programação, um teste unitário, ela pode alterar o teste unitário para satisfazer essa condição, ou pode alterar a lógica do código para passar nessa condição. Isso não significa que ela realmente seguiu sua intenção para alinhar tanto o comportamento funcional quanto o que o teste deveria testar, certo?
Só porque uma fábrica de software está mostrando que tudo está verde não significa que está realmente verde, especialmente no início, quando você está configurando essas coisas. Você precisa prestar muita atenção para garantir que suas verificações, suas validações, todas elas estejam moldadas da maneira correta. Elas estão fazendo o que você espera que façam. Você não quer que elas sejam enganosas.
Você não quer uma situação em que você tinha testes que diziam: "ei, na verdade, eu fui e mudei quais provedores de autenticação são suportados. Você me pediu para adicionar o GitHub, por exemplo, como um provedor de autenticação, mas ei, minha UI só tinha espaço para três, então eu fui e removi um dos outros. E ei, a propósito, esse acabou sendo um que seus clientes realmente queriam." Então você só precisa ser muito explícito sobre como quer que esses sistemas funcionem.
A propósito, a segurança é super importante também, e se sua fábrica lê entrada não confiável, como uma issue do GitHub/mensagem do Slack, ela pode ser adversária e incluir problemas como ataques à cadeia de suprimentos. Alguns produtos em torno de fábricas de software, como o Vercel Sandbox/AI ADK Factory, executam seus agentes em sandboxes isolados que contêm apenas os segredos que uma tarefa precisa. Dessa forma, uma execução comprometida não pode alcançar o que o trabalho não precisa. Sua defesa acaba sendo em camadas.
Quais projetos antigos merecem outra vida?
Eu também acho que uma grande parte de como trabalhamos hoje em dia é decidir o que deve existir. Se você se lembra de muitos anos atrás, antes da IA, havia tantos projetos de engenharia de software abandonados, tantos projetos de fim de semana abandonados, projetos pessoais que simplesmente não eram lançados porque não tínhamos tempo para terminá-los. Não tínhamos largura de banda para priorizar colocá-los para fora porque não eram tão importantes para nós ou não conseguíamos encontrar tempo.
Agora é bastante trivial para nós completarmos esses projetos, mas a mesma questão de julgamento humano aparece. Esses projetos merecem existir? Eles devem ser lançados? Porque você os coloca no mundo e, mesmo que tenha apenas cinco usuários, talvez você tenha que mantê-los. Talvez você tenha um padrão de qualidade agora que deseja manter.
Eu sei que tive tantos projetos no GitHub ao longo dos anos que agora que tenho um agente, a primeira coisa que faço é fazer a coisa compilar. Porque, claro, você clona e agora não compila porque todas as dependências mudaram. Metade das coisas está desatualizada ou tem vulnerabilidades de segurança por toda parte, então você tem que atualizar isso.
Então você tem que adicionar testes se não tinha testes, para saber que o comportamento pelo menos estará lá se você estiver atualizando o projeto de alguma forma, ou se estiver migrando para uma linguagem ou framework mais moderno ou algo assim.
Então você começa a se perguntar: bem, talvez, um exemplo bobo, mas talvez eu tenha usado o Twitter Bootstrap antigamente para isso, mas agora todo mundo está usando Tailwind e shadcn, então tenho que reimplementar a UI. E o que você notará é que, de repente, isso está tomando mais tempo, certo? Sim, o agente pode fazer grande parte disso mais rápido, mas agora você tem que considerar o senso de produto e o gosto e todas essas coisas.
Você ainda questiona: bem, para quem é isso? Tem mercado? É para mim? É para outras pessoas? Se estou colocando no mundo, ainda será tão interessante, dado que agora qualquer um pode montar essas coisas tão rapidamente?
Então eu acho que essa questão humana de "essas coisas merecem existir?" e "como consideramos nosso gosto e julgamento?" Eu sinto que essas coisas continuam sendo extremamente importantes. É aí que esse recurso escasso da atenção humana realmente entra. Antigamente, tínhamos apenas um número finito de horas no dia. Tínhamos reuniões. Tínhamos que orçar tempo para design e codificação e assim por diante.
Agora que temos agentes para nos ajudar, acho que você realmente tem que ser muito explícito sobre onde está gastando seu tempo e por quê.
O que aconteceu quando construí um exemplo
Então, vou falar sobre a execução da fábrica de 82 minutos. As pessoas têm me perguntado há algum tempo: "Como eu construo uma fábrica de software?" Ou: "Estou acostumado a usar Claude Code ou Codex. Como eu evoluo minha configuração para usar uma fábrica de software?"
Então, a primeira coisa que tenho dito é: "Você pode estar bem. Seu trabalho pode estar totalmente bem sem precisar de uma fábrica." Mas eu queria dar às pessoas uma configuração de referência que elas pudessem conferir. Então, o que montei é um repositório chamado Factory que você pode ir conferir. Também montei um aplicativo de demonstração e um workshop.
Agora, nos últimos dois anos, meu aplicativo de demonstração padrão para muitas coisas tem sido um aplicativo de filmes. Sou um grande fã de filmes. Adoro assistir filmes. Assisto filmes o tempo todo, e então tenho um aplicativo de demonstração, que realmente começa como um aplicativo de filmes muito simples. E o que eu quero que a fábrica seja capaz de fazer é implementar uma série de funcionalidades. Existem algumas funcionalidades diferentes. Quero uma funcionalidade de favoritos. Quero que ela seja capaz de talvez fazer pesquisa, e talvez também queira um tema escuro lá também, esses tipos de coisas.
Então, minha fábrica vai e começa a trabalhar com essas coisas. Você pode conferir a implementação. Um dos benefícios disso foi realmente pegar problemas reais. Esses problemas podem não ter sido coisas que eu teria pego se tivesse apenas pedido uma implementação única.
Talvez por volta dos 60 minutos, eu estava pensando: "Uau, isso está indo excepcionalmente devagar." Perguntei ao meu harness usando a fábrica: "Por que as coisas estão lentas?" Ele disse: "Isso é totalmente normal. Todos os verificadores ainda estão em execução."
Você pode ter esperado que tarefas individuais levassem 10 minutos, 15 minutos, 20 minutos, mas elas podem levar de duas a quatro vezes mais tempo quando você começa a incluir verificação, repetições, verificações de navegador, revisão humana, qualquer um desses atrasos extras.
Acredito que isso pode resultar em melhor qualidade e melhor confiança no sistema. De uma perspectiva de medição, você pode olhar para métricas como custo por PR mesclado e vida útil do código como métricas de dívida de compreensão.
Você também precisa pensar sobre o que é atraso útil versus sobrecarga da fábrica. Os verificadores, no meu caso, pegaram alguns problemas reais. Um pouco do tempo foi talvez gasto produzindo evidências que eu queria. Parte disso foi sobrecarga na execução da fábrica. Não gastei tempo otimizando-a, mas uma fábrica que apenas executa muitas verificações que você não considera valiosas não significa que seja de alta qualidade.
Você quer estudar como, para quaisquer verificações repetidas, elas são irrelevantes? Elas são ruidosas? Elas estão realmente tornando o sistema mais seguro?
A verificação precisa de um orçamento
A maneira como penso sobre o orçamento para verificação é basicamente sobre o que estamos falando. Estamos falando de um orçamento de verificação. Penso nisso da mesma forma que historicamente pensei em orçamentos de desempenho.
Haverá certos tipos de verificações que você pode executar no início do seu ciclo de vida de desenvolvimento de software, e haverá algumas coisas que são tão pesadas, mas oferecem tanto valor, que você vai querer executá-las mais tarde. Existem alguns tipos de verificações rápidas, como linting, por exemplo, verificação de tipos. Essas são verificações relativamente rápidas que você pode executar no início.
Nossa suíte completa de testes pode ser executada mais perto de antes de um PR rascunho ser montado ou depois disso. Isso pode incluir testes de mutação, testes de navegador, verificações de segurança, qualquer coisa assim.
Acho que você não quer necessariamente substituí-los por apenas resumos. Você quer testes reais, mas só precisa garantir que está orçando para eles nos lugares certos, porque você não quer desacelerar seu ciclo de desenvolvimento. Certamente nunca quero desacelerar meu ciclo de desenvolvimento. Ter um ciclo de iteração rápido é importante para mim, mas também quero ter esses freios e contrapesos.
Quando uma execução não é enviada
Muito do que escrevi acima diz respeito às verificações.
Em sua fábrica de software, a Vercel marca cada execução de agente como "sucesso", "falha", "bloqueada" ou "manual" e apenas "sucesso" é enviado para produção. O resto reentra no sistema. Tenho pensado em execuções em termos semelhantes.
"Falha" aqui significa que a coisa errada foi implementada ou talvez não tivesse contexto completo, então isso tem que ser corrigido. Bloqueada significa que o ambiente pode estar faltando uma credencial, então você tem que fornecê-la. Manual é um limite que a fábrica ainda não pode cruzar.
Duas das três coisas aqui podem ter correções mecânicas e a última é sobre confiança.
Embora isso seja ótimo, o que a classificação não mostra é o custo. Voltando à minha implementação de fábrica com o aplicativo TMDB, o localizador rápido sem rejeições levou 7 minutos. Favoritos, com duas rejeições e uma decisão humana no meio, levou 56. Mesma fábrica. Então, eu combinaria a taxonomia com o tempo por estágio, caso contrário, você sabe que uma execução voltou com falha sem saber quanto custou descobrir. A outra coisa que eu corrigiria é o handoff no limite: minha fábrica de exemplo parou a primeira issue e a moveu para factory:needs-info, o que estava certo, mas eu não sabia onde colocar minha resposta. Uma execução manual não termina quando a fábrica para, mas quando o humano sabe o que fazer a seguir.
Autonomia não é uma configuração única
Escrevi há algumas semanas um artigo sobre autonomia agentiva e como pensar sobre autonomia, porque a autonomia não será uma configuração única para todos os projetos.
A verificação lhe compra confiança e compra a capacidade de conceder mais autonomia aos seus agentes. Então, se, por exemplo, estou trabalhando em uma alteração não trivial, mas tenho uma série de verificações em vigor, tudo é verificado corretamente, e talvez eu mesmo tenha verificado manualmente. Da próxima vez que for fazer uma tarefa como essa no mesmo projeto, talvez me sinta confortável em dar um pouco mais de autonomia ao agente.
Isso é o que você pensa ao construir essas fábricas de software. Sua verificação vai mudar com o risco. Seu objetivo é a melhor relação sinal-ruído. Você não quer apenas ter uma grande lista de verificação que está executando.
A funcionalidade que tive que reaprender
Houve uma funcionalidade que venho adiando em um dia em que estava usando várias sessões com o Claude, e estava trabalhando em alguns projetos diferentes ao mesmo tempo, algumas funcionalidades diferentes por projeto. E então o Claude havia implementado a funcionalidade em que eu estava trabalhando. Parecia que os testes estavam passando. Não tinha pensado muito em verificação, mas os testes passaram, e então pensei que funcionava. Fiz o merge.
E então esta era uma funcionalidade de favoritar. Pensei que estava realmente boa. Tentei verificar no navegador. Parecia que estava ok, mas alguns dias depois, voltei ao código porque pensei em fazer alguns ajustes.
Eu não queria simplesmente pedir ao meu agente para fazer as alterações, porque era apenas uma forma sutil de funcionamento. Você tocava no ícone e ele não mostrava o efeito correto ao tocar, então eu queria apenas ajustar isso. Queria entender como funcionava para poder orientar meu agente corretamente.
Voltei ao código e não conseguia explicar como o recurso funcionava. Esse repositório era meu, certo? Eu havia aprovado a alteração. Entendia como grande parte dele funcionava, como grande parte do repositório funcionava, mas meu entendimento não havia acompanhado o ritmo de todo o código que estava sendo acumulado.
O que não consegui absorver foi como esse recurso que havia sido adicionado realmente funcionava, como a interface do usuário funcionava, como o efeito nele funcionava. Tive que refazer esse recurso e, de fato, ir passo a passo: "Como isso funciona? Como posso entender isso?"
O que o trabalho paralelo faz com o entendimento
Quando você está fazendo trabalho paralelo, isso amplifica esse problema geral, e fica ainda mais amplificado quando você está fazendo isso em uma fábrica de software. Quando você está fazendo cinco ou dez sessões, elas criam muito mais do que apenas um problema de volume de revisão. Elas criam vários modelos mentais que podem acabar esfriando enquanto você trabalha em outro lugar.
Historicamente, falamos sobre os desafios da alternância de contexto e, assim que o chat é compactado, você rejeita algumas abordagens, experimenta coisas diferentes, está emparelhando com o agente, terá dificuldade em lembrar de tudo o que aconteceu na sua sessão.
Você pode rolar para cima e, como a compactação está acontecendo, não terá tudo ali e não conseguirá armazenar tudo na sua cabeça. O código geralmente preserva uma decisão que foi tomada, mas não o motivo pelo qual a decisão foi tomada.
Isso é algo que acho que pode ser um aprendizado útil para você, onde é importante considerar pedir ao seu agente para realmente armazenar informações sobre sua trajetória, ou lições interessantes sobre como ele abordou um problema, para que você possa consultá-las mais tarde.
Isso pode ou não ser algo que você decida comprometer em um repositório. Você pode mantê-lo localmente se quiser, pode compartilhá-lo com uma equipe se quiser, mas isso pode ser algo que pode ser consultado posteriormente. Em vez de você confiar que talvez esteja em uma sessão, ou que talvez se lembre disso mais tarde.
O que realmente é produzido?
@threepointone e @bentlegen publicaram algumas opiniões sobre fábricas de software com as quais concordei plenamente:
É fácil se fascinar pela maquinaria do fazer, otimizar a maquinaria e esquecer o que ela deveria produzir. Se sua fábrica produz principalmente uma fábrica melhor, você construiu um software cujo produto é ele mesmo.
Acho que investir no ciclo é bom e ele se acumula. A falha ocorre quando o ciclo se fecha, quando tudo o que a fábrica produz é consumido pela fábrica e ninguém lá fora notaria se você a desligasse. O teste que eu aplicaria é a demanda. Algo externo tem que estar pedindo a melhoria. Se você não consegue nomear quem está demandando, você está apenas polindo.
A propriedade não desaparece
Há um princípio mais amplo por trás de tudo isso.
A porcentagem de código fisicamente digitado por humanos pode cair drasticamente. Não acho que a propriedade humana precise cair junto com isso.
- Alguém ainda escolhe o problema.
- Alguém ainda escolhe a arquitetura.
- Alguém ainda define o padrão de qualidade.
- Alguém decide quais sinais de verificação merecem confiança.
- Alguém decide quando as evidências são suficientes para lançar.
E quando o sistema resultante falha, "o agente escreveu" não é desculpa. É por isso que não acho que o futuro da engenharia de software seja melhor descrito como humanos saindo do ciclo. Em vez disso, o julgamento humano está sendo realocado.
Devemos remover as pessoas das partes do ciclo onde as máquinas podem produzir sinais mais fortes, mais rápidos e mais determinísticos. Ao mesmo tempo, devemos concentrar as pessoas nos lugares onde contexto, bom gosto, risco e propriedade de longo prazo são mais importantes.
As melhores fábricas de software não serão definidas por quão completamente eliminam o envolvimento humano.
Elas serão definidas por quão inteligentemente elas o posicionam.
Mantenha o julgamento humano a montante na intenção, na forma do sistema e no padrão de qualidade. Revise o código onde a pressão automatizada se torna fraca ou as consequências se tornam subjetivas. Empurre cada sinal determinístico o mais cedo e continuamente possível para o ciclo. Aperte e relaxe as restrições deliberadamente à medida que o sistema ganha ou perde confiança.
Um humano ainda precisa ser dono do que o código finalmente entrega. Código bom o suficiente para ser entregue ainda começa com alguém que se importa se ele deveria existir.
