Início Tecnologia A maioria das empresas pensa que está construindo uma fábrica de software...

A maioria das empresas pensa que está construindo uma fábrica de software program. Na verdade, eles estão apenas enviando bugs mais rapidamente.

25
0

As fábricas industrializadas mudaram a forma como o mundo produzia bens físicos: mais produção, custos mais baixos e mais rápido do que qualquer coisa que existisse antes. Agora, uma mudança semelhante está acontecendo com o software program.

Os LLMs reduziram a barreira para escrever código, aumentaram a produção particular person e levaram as organizações a pensar no desenvolvimento de software program como um sistema de produção. O ciclo de vida de desenvolvimento de software program padrão e as práticas de CI/CD que se mantêm há décadas não resistirão a essa pressão. É aí que entra a fábrica de software program – e, assim como as fábricas físicas, ela precisa de mais do que velocidade para realmente funcionar.

A ideia de uma “fábrica de software program” começou a se solidificar no ano passado. “A Era da Fábrica de Software” de Luca Rossi deixou claro: a IA não está apenas mudando a rapidez com que as pessoas escrevem código – está mudando todo o sistema de produção em torno do software program.

O conceito pode significar coisas diferentes: uma coleção de agentes de codificação e arquivos de habilidades; CI/CD mais rápido; melhores sistemas de revisão; ou mais automação na entrega de software program. Um enquadramento melhor é pensar nisso menos como uma categoria de ferramenta e mais como um conjunto de princípios. Uma fábrica de software program não pode ser apenas uma coleção solta de prompts, agentes e plug-ins. Ela precisa de uma plataforma que defina como o trabalho se transfer pelo sistema e como o código é gerado, revisado, testado, rastreado, implantado e melhorado quando algo dá errado.

Caso contrário, tudo o que você fará é colocar mais uma máquina única em uma sala vazia e chamá-la de fábrica.

Por que isso está acontecendo agora?

Existem algumas forças atingindo todas ao mesmo tempo.

As empresas sempre quiseram mais software program do que os engenheiros podem produzir. É por isso que existem ferramentas como o Excel: muitas vezes elas preenchem a lacuna de muitos softwares que muitas empresas gostariam de poder fabricar.

A IA também reduziu a barreira de entrada para a criação de código, e é nesta parte que todos se concentram. A criação de códigos agora é mais fácil, embora nem sempre mais barata ou melhor, como evidenciado por muitas empresas de alto perfil preocupados com suas altas contas de IA. A barreira para escrever código funcional efetivamente entrou em colapso.

Mais importante ainda, um único engenheiro pode gerar mais código do que há alguns anos. Isso muda o gargalo: não é mais “Quão rápido alguém consegue escrever isso?” ou mesmo, em alguns casos, “Alguém consegue entender como codificar?” Em vez disso, torna-se: “Isso deveria ser escrito?”

Mais importante ainda, podemos realmente criar produtos finais que sejam duráveis ​​e confiáveis ​​e não apenas criar dívidas tecnológicas? Ou estamos apenas lançando mais resíduos de IA mais rápido do que nunca? É aí que reside o perigo.

Os perigos da moderna fábrica de software program

Tudo isso parece ótimo. Afinal, as fábricas tornaram a produção mais rápida e consistente.

Eles tornaram possível construir mais carros e produtos, com custos mais baixos, o que fez com que mais pessoas pudessem comprar carros e produtos. Deixando de lado os impactos ambientais, pode-se argumentar que isso foi positivo.

Mas, como muitas coisas na engenharia, sempre existem compensações e, neste caso, existem novos riscos.

Quando você aumenta a produção de uma pessoa com maquinário, digital ou não, você também aumenta os erros que podem ser cometidos pelo indivíduo ou pelo maquinário. A velocidade com que o código pode agora ser divulgado é em escala industrial. Mesmo organizações menores podem repentinamente ter bases de código aumentando até o tamanho das bases de código de empresas de tecnologia de uma década atrás.

Os dados já mostram problemas. A Faros AI descobriu que, embora o rendimento da tarefa por desenvolvedor tenha aumentado 33,7% e a taxa de mesclagem de relações públicas tenha aumentado 16,2%, o A proporção de incidentes por RP aumentou 242,7% e os bugs por desenvolvedor aumentaram 54%. A pesquisa DORA do Google descobriu que uma maior adoção de IA foi na verdade associado a pior estabilidade de entrega.

Como chefe de dados fracionários, fui contratado para corrigir exatamente esses problemas. Só no ano passado, trabalhei em dois projetos nos quais a infraestrutura de dados gerada por IA começou lentamente a se transformar com o tempo.

Entre vários engenheiros tentando agir rapidamente e a falta de padrões, esses projetos tornaram-se indisciplinados. As bases de código tendem a passar por algum nível de evolução, mas à medida que diferentes estilos se misturam, os LLMs, por sua vez, começam a criar suas próprias mutações. As bases de código desenvolveram de cinco a seis estilos diferentes em meses – um processo que antes levava anos. Camada por camadaos engenheiros aos poucos parariam de entender exatamente o que estava acontecendo.

O padrão reflete o que aconteceu há uma década com as ferramentas de autoatendimento: ganhos iniciais de produtividade que mascararam a complexidade posterior.

E é por isso que a fábrica de software program não pode ser apenas uma questão de velocidade.

O que faz uma fábrica de software program funcionar

Existem vários princípios-chave a serem considerados ao construir uma fábrica de software program.

Plataforma sobre ferramentas: Muitas equipes estão lentamente implementando IA em seus fluxos de trabalho de codificação nas bordas – adicionando um agente de revisão de relações públicas ou um arquivo de habilidades em seus repositórios. Mas construir uma fábrica de software program actual requer uma plataforma, não uma coleção de ferramentas nas bordas. Uma plataforma fornece uma base unificada onde as ferramentas não ficam espalhadas em cantos separados. Em vez disso, eles compartilham dados ativamente, conversam entre si e trabalham como um sistema único e coeso – padrões, processos e o próprio trabalho, todos conectados.

Rerunabilidade e rastreabilidade: Uma plataforma actual requer a capacidade de voltar a qualquer execução, identificar o que deu errado e executá-la novamente – e é por isso que agentes pontuais não fazem uma fábrica. O sistema precisa suportar a obtenção de um ID serial, procurá-lo e rastrear exatamente como ele chegou à saída que produziu. É por isso que as máquinas de estado fazem mais sentido do que os loops para fluxos de trabalho de IA: elas tornam muito mais fácil executar novamente um processo e entender o que aconteceu em cada etapa.

Segurança e guarda-corpos: As fábricas não são lugares seguros. Nem é uma fábrica de software program. À medida que mais pessoas desenvolvem nessas plataformas, melhores guarda-corpos e medidas de segurança precisam ser incorporadas. Os testes e o controle de qualidade precisam ser colocados na frente do processo – detectar bugs no estágio mais baixo possível reduz o custo para corrigi-los e limita o raio de explosão.

Padronização: No nível empresarial, cada base de código tem seu próprio sabor. Colocar um assistente de código em camadas sem padrões produz um amálgama de estilos. A padronização deve ser incorporada ao processo desde o início.

Controle de qualidade: Nos modelos de fabricação mais antigos, o controle de qualidade acontecia no ultimate da linha. O produto foi construído, inspecionado, defeitos encontrados e corrigidos posteriormente. A abordagem da Toyota era diferente. A qualidade foi inserida no próprio processo – esperava-se que os trabalhadores parassem a linha quando algo estivesse errado. O objetivo não period detectar defeitos no ultimate; period para evitar que eles fluíssem rio abaixo em primeiro lugar.

O mesmo se aplica à fábrica de software program. O controle de qualidade precisa ser incorporado a todo o processo, começando com a forma como as especificações são escritas. Isso significa integrar a análise estática de código que detecta erros óbvios e fornecer modelos aos LLMs para que eles conheçam a estrutura que o código deve seguir. Sem isso, o gargalo se torna a revisão ultimate – ou as equipes simplesmente lançam mais resíduos de IA.

Velocidade sem qualidade não é produtividade

Melhorar a velocidade da saída do seu código não é produtividade actual se os problemas posteriores não forem gerenciados. Uma empresa não é mais produtiva porque produz milhões de carros, apenas para ver todos eles desmoronarem num raio de 160 quilómetros. Também não será mais produtivo se tudo o que fizer for produzir um fluxo interminável de provas de conceito que nunca entram em produção.

A produtividade actual ocorre quando a fábrica de software program pega tokens efêmeros e os transforma em resultados duráveis. É fácil falar sobre linhas de código e como sua equipe está se movendo mais rápido.

A fábrica de software program vencedora não é aquela que gera mais código. É aquele que gera menos defeitos no downstream.

fonte

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui