O loop que está chegando
(lucumr.pocoo.org)- Fora dos agentes de programação, loops no nível do harness — em que filas de tarefas e o harness gerenciam a repetição — estão surgindo como um novo padrão central da engenharia de agentes
- Quanto mais tempo um modelo opera de forma autônoma, mais fácil se torna acrescentar defesas locais e fallbacks do que impor invariantes fortes, o que pode abalar a compreensão do design e o controle em código mantido no longo prazo
- Em contrapartida, em áreas como portabilidade de código, experimentos de desempenho, varreduras de segurança e pesquisa, onde é fácil validar ou descartar resultados, a iteração mecânica já funciona muito bem
- Quando atacantes e relatores rodam loops, mantenedores também passam a sofrer pressão para usar máquinas em triagem, reprodução e resposta, e o caso do curl mostra a carga criada por relatórios gerados por IA
- O desafio daqui para frente não é se vamos usar loops, mas como manter, dentro deles, o julgamento humano, as regras de engenharia, a supervisão responsável e arquiteturas compreensíveis
Loops que rodam fora do agente de programação
- Dentro de um agente de programação já existe um loop do agente, em que o modelo chama ferramentas, incorpora resultados, lê e modifica arquivos, executa testes e então produz uma resposta
- O novo padrão que vem ganhando destaque é o loop no nível do harness
- Uma tarefa entra na fila
- A máquina pega a tarefa e tenta executá-la
- Depois de parar, o harness decide se ela realmente terminou
- Se não terminou, injeta uma mensagem na mesma sessão, inicia uma nova sessão com contexto ajustado ou repassa a tarefa para outra máquina
- Esse loop externo mantém a tarefa viva mesmo depois do ponto em que o modelo normalmente diria “terminei”
- O loop em si não é novo, mas recentemente começou a aparecer com mais frequência na engenharia de agentes e no debate do Twitter
- Parte desse fluxo também aparece no Pi, e o Pi está no centro desses experimentos justamente por ser um harness
O desconforto que surge em código mantido por muito tempo
- Esse método ainda não parece encaixar bem em código com o qual você realmente se importa em profundidade
- O ponto central é gosto e controle
- Você quer entender o código que coloca em produção
- Em situações de pressão ou em discussões com outras pessoas, precisa conseguir explicar o comportamento do sistema sem antes pedir para a máquina explicar
- Por enquanto, entender o código continua sendo importante
- Código gerado sem supervisão direta, especialmente o que sai desses loops, tende a apresentar problemas recorrentes
- É defensivo demais
- É complexo demais
- Fica preso a raciocínio local
- Evita invariantes fortes
- Em vez de tornar estados errados impossíveis, adiciona fallbacks
- Cria código duplicado e abstrações ruins, cobrindo designs pouco claros com ainda mais mecanismos
- Combinações como Claude Code e Fable conseguem trabalhar em um único problema por mais de 30 minutos sem interrupção, reduzindo mais do que antes o human in the loop
- A sensação é que, no estado atual, a qualidade do código produzido por esse modelo de harness sem intervenção ficou até pior do que no outono passado e, ao menos para esse gosto, quase não houve melhora
O loop amplifica os hábitos do modelo
- Diante de uma falha local, o modelo tende a acrescentar uma defesa local
- Andrej Karpathy já disse que os modelos “temem exceções de forma patológica”
- Em sistemas com invariantes importantes, especialmente formatos de dados persistentes ou infraestrutura central, a abordagem de “tratar todo caso malformed” pode não ser a correção certa
- Um caminho melhor pode ser tornar o caso malformed impossível de representar ou impossível de escrever desde o começo
- Mesmo com muita orientação manual, LLMs têm dificuldade de produzir esse tipo de código de forma natural e podem tentar tratar até erros que já se tornaram impossíveis
- Quando esse hábito é colocado atrás de um loop, o problema é amplificado
- Cada iteração acrescenta mais uma pequena defesa
- O sistema parece mais robusto, mas fica cada vez mais difícil de entender
- Quanto mais você larga a mão, maior essa tendência
- Dar essas ferramentas a alguém júnior sem diretrizes claras pode acabar ensinando práticas ruins
- Se você perguntar o motivo, a pessoa ainda pode defender suas escolhas de modo convincente
Onde os loops se encaixam bem
- O padrão de loop já funciona muito bem em alguns domínios
- Portabilidade de código é um exemplo representativo
- Há casos de grande porte, como a migração de partes do Bun de Zig para Rust
- Também foi usado com sucesso para portar o MiniJinja para Go
- Também combina bem com exploração de desempenho
- A máquina tenta experimentos
- Executa benchmarks
- Descarta falhas
- E continua explorando
- Também se encaixa naturalmente em varreduras de segurança e em quase todo tipo de pesquisa
- É possível explorar espaços de problema complexos e pedir relatórios dos resultados
- Não é necessário necessariamente commitar código que vai permanecer por muito tempo
- O ponto em comum nos casos de sucesso é que o resultado não precisa ser mantido por longo prazo, ou se trata de transformar código existente, ou está mais próximo de proof of concept, ideias, descobertas e transformações mecânicas
- O que o harness precisa não é um sinal totalmente objetivo ou binário, mas um sinal útil o bastante para empurrar a próxima iteração
- Muitos casos de sucesso usam outro LLM como judge ou orchestrator
- Traduções mecânicas podem ser validadas com test cases binários ou julgadas por um LLM
- O Claude Code está ficando cada vez mais capaz de montar e executar fluxos completos de experimentação
- Mesmo que o código gerado fique bagunçado, isso parece ser mais um problema do modelo do que da capacidade de julgamento do harness
A mudança para tratar software mais como organismo do que como máquina
- Ainda não é confortável escrever código que vai durar usando esse mesmo estilo de loop
- O ideal anterior era mais próximo de entender software como uma máquina determinística
- Ao remover uma camada, era possível alcançar uma compreensão mais profunda
- Uma máquina observada de forma não determinística dificilmente seria vista como ideal
- O desejável era que a arquitetura avançasse rumo a mais determinismo
- Bom design era aquilo que permitia até a um novo engenheiro explorar uma base de código complexa
- Em um sistema bem projetado, havia engenheiros que sabiam onde estavam os invariantes, quais partes eram load-bearing e quais mudanças eram seguras
- Softwares grandes já não cabem inteiros na cabeça de uma pessoa, e sistemas distribuídos já têm algo de medicina diagnóstica: observam-se sintomas, levantam-se hipóteses e pedem-se mais testes
- Os LLMs empurram isso ainda mais nessa direção
- Surge um problema em produção e a máquina lê os logs
- Sugere a root cause
- Propõe um patch
- Outra máquina faz review e, às vezes, aplica em
mainsem supervisão humana
- Esse modo de trabalho é poderoso e atraente, mas as pessoas podem deixar de entender o sistema inteiro da forma como entendiam antes
- Elas o operam, monitoram e estabilizam, mas não necessariamente o compreendem
- Nem todo código precisa ser autoria humana, e no passado talvez já se tenha escrito código pior
A pressão da qual é difícil escapar completamente
- Em um futuro totalmente guiado por máquinas, pode ser difícil fazer opt out
- Segurança é o caso mais claro
- Mesmo que você não desenvolva software com loops, outra pessoa pode rodar loops contra o seu software
- Atacantes mantêm máquinas rodando continuamente
- E mesmo sem intenção maliciosa, pesquisadores de segurança executam trabalho automatizado
- Como resultado, chegam juntos problemas reais e ruído
- O relato de Daniel Stenberg sobre o curl, summer of bliss, mostra a pressão que mantenedores já enfrentam
- A IA aparentemente não tem grande papel no desenvolvimento central do curl
- Ainda assim, os mantenedores estão sendo sobrecarregados por relatórios, a maioria deles gerados por IA
- Se atacantes e relatores rodam loops, defensores também acabam tendo de acompanhar
- Talvez não necessariamente para escrever patches diretamente
- Mas pela pressão de triagem, reprodução e resposta, podem precisar usar máquinas
- A pressão competitiva é parecida
- Algumas equipes podem produzir mais do que outras por pura velocidade
- Um grupo pequeno que coordena bem as máquinas pode acelerar um projeto de repente
- Algumas startups podem fazer com 5 pessoas o que antes exigia 50
- Alguém pode rodar loops contra um produto e mandar “faça algo parecido, mas diferente”
- Nem todo software será afetado da mesma maneira
- Algumas áreas punem improvisação e exigem confiança e responsabilidade
- Em muito software, velocidade, experimentação rápida e ampla cobertura são extremamente importantes
A nova dependência criada pelos loops
- Ferramentas baseadas em loops podem criar não um custo pontual, mas uma dependência cognitiva contínua
- No passado, o desenvolvimento de software dependia de ferramentas custosas como compiladores, mas as ferramentas de hoje se parecem mais com sistemas aos quais é preciso ter acesso contínuo
- Se uma base de código é criada por loops, revisada por loops, corrigida por loops e mantida por loops, haverá problemas quando o acesso a sistemas desse nível for interrompido
- Restrições comerciais podem eliminar o acesso aos modelos mais poderosos
- O custo pode se tornar inviável
- A equipe pode perder a última capacidade de entender o código sem a máquina
- Pode surgir uma base de código que não seja apenas difícil demais para humanos manterem, mas que assuma a participação da máquina como parte do próprio modelo de manutenção
- Algumas mudanças já são visíveis
- Mais gente faz merge de código que não consegue explicar completamente
- Relatórios de issues e discussões em chat são reforçados ou reescritos com contexto fornecido por máquinas
- Resumos e contextualização passam a depender de máquinas
- Torna-se mais comum ver pessoas conversando por meio de LLMs
- Não dá para afirmar que isso está necessariamente errado, mas é uma grande mudança em relação ao modo anterior
Os harnesses e ferramentas de que vamos precisar
- Não basta apenas coordenar mais loops
- Mesmo que se visualize melhor mudanças, orquestração e agentes, isso não restaura automaticamente a compreensão
- A direção necessária parece ser uma destas duas
- Encontrar formas de puxar o humano de volta para dentro do loop de maneira forte e tornar as mudanças do loop legíveis no longo prazo
- Ou encontrar formas melhores de compor sistemas cada vez mais complexos
- A visão sobre o Pi também está mudando
- O Pi foi cauteloso, e essa cautela é positiva
- Não se quer um futuro em que toda interação se transforme em mudanças feitas por um enxame de máquinas difícil de acompanhar
- Também não se quer que o Pi vire um caos impossível de manter para vencer uma competição de software que escreve a si mesmo
- Nem que o Pi incentive esse tipo de engenharia
- Ainda assim, o Pi é um harness, e harnesses estão no centro dos novos experimentos
- Filas de tarefas de programação, orquestração de agentes, subagents e durable sessions vão se tornar cada vez mais importantes
- Mesmo quem não aceita loops cegamente precisa começar a experimentar
- Porque é preciso entender como tornar esse futuro suportável dentro de limites
A questão de controlar o loop
- Ao adotar um loop de harness, é o harness que decide quando o trabalho terminou
- No loop do agente, o modelo acaba dizendo “done” e uma pessoa faz review
- Mesmo antes disso, normalmente há intervenção humana ao longo do caminho
- A pessoa participa e aprende no processo
- Em um loop operado pelo harness, o papel humano fica menos claro
- O sinal de “done” também perde significado e vira uma mensagem para outra máquina julgar
- O papel da pessoa pode se aproximar mais do de mensageiro
- Atualmente, boa parte do código produzido dessa forma não agrada, e interagir com software criado com apoio de IA também não parece prazeroso
- Os loops são poderosos, mas removem responsabilidade gradualmente e, por enquanto, parecem incentivar uma rendição às máquinas
- Ainda assim, o futuro dos loops parece estar chegando
- Já existem exemplos de equipes minúsculas construindo em uma velocidade que parecia impossível
- Bases de código estão se tornando organismos mais ambíguos e confusos
- Ao mesmo tempo, essas bases são úteis e bagunçadas
- A pergunta daqui para frente não é “vamos rodar loops?”, mas algo mais próximo disto
- Como não abrir mão do julgamento dentro dos loops
- Como preservar boas regras de engenharia
- Como garantir que humanos responsáveis continuem supervisionando
- Como repensar a arquitetura do código para continuar preservando a sanidade
1 comentários
Comentários do Hacker News
O loop funciona quando você dedicou tempo suficiente para entender de antemão o que quer. O pré-requisito é clareza: você precisa ser capaz de escrever uma especificação cuidadosa o bastante para passá-la a um colega júnior.
Normalmente, leva umas 5 ou 6 versões quebradas e malfeitas até chegar a esse entendimento. Essas 5 ou 6 tentativas e erros não podem ser aceleradas, e nenhuma tecnologia de agentes consegue evitar o tempo que o cérebro humano precisa para pensar. Então, a maior parte do tempo é gasta indo e voltando entre “não sei o que quero, vou ter que ler, escrever e mexer no código” e “agora acho que já passou tempo suficiente para eu saber o que quero”. É muito fácil enganar a si mesmo, mas só dá para usar o loop depois que você realmente sabe o que quer. Muita gente acha que pode passar por cima disso com agentes, mas entendimento e clareza não podem ser simulados, e quem pula essa etapa fica dolorosamente óbvio
Eu não precisei passar muito tempo pensando no que queria, eu simplesmente queria que ele fizesse isso. O resultado ainda é misto e eu ainda não confio o bastante para entregar uma base de código delicada, mas no jogo que estou fazendo o tempo gasto com verificação caiu para 1/5 do que era antes. Isso não é necessariamente bom. Há uma boa chance de eu estar deixando passar boas ideias por estar gastando menos tempo. Mas antes os prompts tinham virado mecanicamente
#now-do-this,#now-review-that, e estavam estagnados num ponto em que 90% das sugestões estavam certas. Agora ele automaticamente lembra “faça primeiro as partes difíceis e organize/refatore enquanto avança” e, depois do primeiro retorno, “reflita sobre o trabalho”, fazendo com que ele exponha os problemas restantes; então eu coloco isso no prompt gerador de guias e distribuo novas tarefasA iteração ficou mais rápida, mas o esforço para passar por essas versões malfeitas continua praticamente o mesmo. Ainda preciso entender quais ideias, princípios e projetos combinam com a solução, o que tentar em seguida e ajustar meu modelo mental. No fim, parece mais que estou gastando mais esforço mental em menos tempo, com uma pequena economia na escrita de código. Quando você já é experiente, digitar código em si nunca foi uma parte tão grande assim. Parece que você “só” está escrevendo prompts e lendo código, mas fica igualmente cansado, ou às vezes até mais cansado por causa do ciclo de iteração comprimido
Tenho passado por isso todos os dias agora, e é desanimador e preocupante. Acho que a razão de estarmos mesclando mais código que não conseguimos explicar completamente é que o modelo mental que antes construíamos ao escrever código e fazer planejamento técnico colaborativo agora está sendo delegado ao code review.
Code review não serve para esse propósito. Ainda assim, acho que dá para equilibrar melhor atrito e entendimento ao acoplar exercícios estruturados, inspirados em pedagogia, ao code review. Estou procurando ajuda para testar esse tipo de exercício
A interface fraca de PR do GitHub também não ajuda. Há poucas ferramentas para explorar o entorno da base de código que não mudou diretamente, mas foi impactado, para encontrar e destacar problemas
O ponto do texto original de que devemos preferir sistemas que tornem condições de contorno erradas impossíveis, em vez de tratá-las com caminhos alternativos, é muito importante. A abordagem de caminhos alternativos leva a implementar caminhos alternativos em cima de caminhos alternativos, e cada um deles aumenta o volume de código exponencialmente e, por algum motivo, sempre cria problemas novos. Dá quase para chamar isso de uma “lei geral do design de sistemas”. Caminhos alternativos reduzem o risco de falha, mas quando a falha realmente acontece, ela se torna mais complexa e mais danosa. Como engenheiro de software, eu gosto do novo ambiente de programação que a IA está criando. Porque as big techs criaram trabalho infinito para mim. O desenvolvedor humano virou um componente central da execução do código e precisa ficar sempre de prontidão para lidar com exceções difíceis, quase infinitas e não tratadas, que inevitavelmente vão ocorrer de vez em quando. Agora o engenheiro de software é menos um trabalhador e mais um segurança que passa a maior parte do tempo sentado à mesa tomando café e só intervém quando raramente surge um problema
Isso bate com o que venho dizendo há meses. LLMs são excelentes em concluir tarefas, mas fracos em estética e gosto.
Existem dois tipos de trabalho. Um é o trabalho orientado a objetivos, em que existe uma meta a alcançar e o modo de chegar lá não importa tanto. Segurança é um exemplo perfeito. Se você quer explorar um sistema, quase não importa se o exploit é bonito; você só quer acessar o plano nuclear ultrassecreto. Pesquisa é parecida: código de “qualidade de pesquisa” já era notoriamente bagunçado antes da era da IA. O outro é o trabalho orientado por gosto. Ao adicionar um recurso a uma grande base de código, você acha que o objetivo é adicionar esse recurso, mas muitas vezes não é isso. Manter a base de código em um estado que aceite bem mudanças futuras é muito mais importante do que esse recurso específico, e isso exige gosto. Manutenibilidade e qualidade de código não são sinônimos, e qualidade de código é apenas um meio; o objetivo é a manutenibilidade
O problema de o LLM tentar lidar de forma natural até com casos em que ele está errado é algo contra o qual muita gente já brigou em reviews de PR. Especialmente depois que já foi escrito, é muito difícil convencer alguém de que verificações de nulo em excesso fazem mal
A menos que haja uma modelagem melhor e uma linguagem que permita tipos soma, ainda não encontrei um contra-argumento universalmente eficaz contra esse tipo de “parsing com escopeta”. Talvez isso nem seja um problema tão grande assim. Mas, ao realmente ler e refatorar um codebase, sempre foi frustrante ter de administrar essas verificações desnecessárias. Depois que entram no código, às vezes é quase impossível removê-las com segurança sem antes adicionar logging ou fazer uma investigação ampla
Esse é justamente o ponto central da ideia de tornar estados indesejáveis impossíveis de representar
Mesmo que hoje nada envie números negativos para esta função, quão difícil seria uma mudança futura no código quebrar essa suposição? Sempre achei que um erro claro fosse o melhor. Assim, mesmo alguém que não conhece o código consegue ver que tipo de suposição existe sobre o intervalo válido de entrada, e deixa de ser necessário considerar outliers impossíveis
Meu gargalo está na especificação. O loop de agentes agora é um problema menos importante para mim
Se eu entender claramente o que quero construir e passar isso como objetivo, escrevendo uma especificação executável no modo de planejamento do Claude Code, o agente em geral produz resultados muito bons quando parte para a implementação. Mas essa estratégia eficaz joga sobre mim uma grande carga de escrever especificações. O agente normalmente lida muito bem com cada especificação, e o trabalho de acompanhamento baseado em review de código costuma levar só 2 ou 3 rodadas, mas logo voltamos a um ponto em que é preciso outra especificação. E, quando estou ausente, mesmo que o agente tenha terminado o trabalho que estava fazendo e possa começar uma especificação já existente que não conflite porque os arquivos não se sobrepõem, ele não sabe que pode criar uma nova branch e começar. Antes de dormir, costumo dizer “faça a tarefa X e, quando terminar e fizer push, comece a tarefa Y”, mas isso raramente vai além disso. Muitas vezes ele começa Y, surge uma dúvida, e então o agente fica parado pelo resto do tempo disponível. O último problema, combinado com o anterior, é a dependência. Por exemplo, hoje escrevi um worker de tarefas em background e, naturalmente, os jobs de tarefas posteriores precisam desse sistema. Isso acontece com bastante frequência. A própria especificação também precisa ser atualizada depois da implementação para refletir detalhes decididos durante a execução. Ainda assim, estamos quase no ponto em que será preciso um loop externo. O gargalo está quase inteiramente na escrita de especificações e no review de PR. Onde esse gargalo não importa, eu quero que o agente continue rodando. Além disso, acredito fortemente que precisamos começar a usar ferramentas que, mesmo sendo piores para nós, sejam melhores para LLMs. Por exemplo, Rust me incomoda porque o compilador é rígido demais, mas para LLMs ele é excelente
Agora que o ato de construir está mais automatizado, especificação e design de sistemas podem voltar a ocupar a dianteira. Talvez engenharia e qualidade voltem junto
A IA é excelente em produzir uma solução aceitável que funciona tecnicamente, mas é bem fraca em ter uma boa visão da solução. Ela continua sendo muito útil para trocar ideias, explorar opções e aprofundar o entendimento, mas escrever uma boa especificação para um LLM implementar não é muito mais fácil do que escrever o código diretamente
https://www.aihero.dev/skills-handoff
/handoffé minha nova skill favoritahttps://www.youtube.com/watch?v=dtAJ2dOd3ko
Com agentes ou sem agentes, com cartões perfurados ou interpretadores, no fim programar continua sendo programar
O maior cheiro de código dos LLMs é que eles tentam “tratar todos os casos errados” e agora até tentam tratar erros impossíveis. Não sei por que têm essa obsessão
Em Python, isso aparece com frequência como adicionar uma verificação
hasattra um tipo em que foi definido que aquela propriedade existe, numa base de código totalmente verificada por tipos. Por que fazem isso? Fico curioso se é por causa do pré-treinamento ou do aprendizado por reforço. Se for o segundo caso, queria que os laboratórios corrigissem issoNo HN se fala muito disso, mas ainda me surpreendo quando vejo bases de código que eu não escrevi — seja open source ou no trabalho — fazendo isso muito bem. A maioria dos programadores, em vez de pensar em impedir que o erro aconteça e fazer os dados refletirem esse fato, pensa em catar os pedaços e consertar no ponto em que a mensagem de erro estoura. Digo “a maioria” porque acho que a IA atual também tem esse problema de mentalidade. É difícil dar à IA, hoje, o nível de entendimento que um humano tem de uma base de código no estágio final, isto é, de entender o fluxo das garantias como um todo. No nível do código bruto, essas garantias muitas vezes se espalham por código suficiente para estourar facilmente a janela de contexto. Tentar resumir isso em arquivos de memória também tem problemas. Só porque existe texto descrevendo as garantias não significa que a IA vá recuperar a informação correta, e com humanos lendo só o código acontece o mesmo. Eu não diria que dar esse entendimento à IA é “impossível”, mas mesmo que você consiga fazer a IA entender, o jeito como ela trabalha muitas vezes age contra esse entendimento. Minha solução em geral foi desistir de fazer a IA entender isso. Normalmente transformo a abordagem do problema em prompts, como as pessoas costumam fazer, e, se quero tornar estados inválidos impossívels de representar, mando a IA fazer o processo de refatoração necessário passo a passo. Se for algo bem pequeno, eu mesmo faço. Se você mandar ela tipar de forma mais rigorosa um código cheio de maps/dicionários, arrays, strings e inteiros, em etapas, ela na prática se sai bastante bem. Mesmo escrevendo tudo em muitos detalhes, raramente consegui uma boa arquitetura em um único prompt. Funciona melhor tratar como duas tarefas separadas. E é preciso olhar as diferenças de tipos com cuidado. A IA adora enfiar às escondidas métodos do tipo
.JustSetItAndIgnoreAllThePreAndPostConditions(string). Imagino que haja muitos dados de treinamento do tipo “um conjunto de tipos bem estruturado para tornar estados de erro impossívels de representar, e depois algum mantenedor adiciona um métodoJustEffingDoIte quebra tudo”. Uma das melhores defesas é colocar esses tipos em arquivos próprios e conseguir revisar facilmente todos os métodos adicionados, para cortar isso imediatamente. Tentei lotar a documentação de avisos sobre não fazer isso e de pré e pós-condições que precisam ser mantidas, mas a mudança foi mínimagetattrem toda dataclass é uma escolha estranhaO código faz parte do entendimento compartilhado e acumulado sobre sistemas de informação
Se esses loops nos mantiverem todos nos movendo em meio à onda constante de software que chega, então, no nível mais alto do projeto lógico de sistemas de informação, tudo acaba sendo julgamento humano e equilíbrio entre requisitos de negócio. Para se ajustar a um nicho específico de uma empresa ou mercado, todo programador terá de virar analista de negócios, pesquisador de mercado e empresário. A exceção são nichos específicos em que as ferramentas de IA não conseguem “chacoalhar” bem, ou quando a era dos tokens de IA subsidiados acabar e todos esses loops ficarem caros demais. Isso parece uma repetição dos sistemas especialistas e das máquinas Lisp da Symbolics. Por um breve momento, o fato que encontramos foi que não era tanto que o código em si não conseguia fazer algo, mas que a estrutura organizacional da empresa acaba sendo carregada para o software; então, se você não pode mudar a organização da empresa, há um limite para a flexibilidade do software. Fluxos de dados e conhecimento de domínio, modelagem de domínio e linguagem ubíqua podem se tornar a metalinguagem com a qual definimos qualidade, funcionalidades e padrões e convenções não funcionais. Precisamos fazer com que os “clankers em loop” cumpram contratos de dados, comportamento e desempenho antes de dizerem “concluído”. Agora “concluído” não significa só código que compila, código que gera build, código que é implantado, nem mesmo código que já foi para produção. Tem de ser código que atenda às exigências dos usuários, dos operadores e dos mantenedores. Então a linguagem usada pode nos tornar a todos mais próximos de analistas de negócios e arquitetos de software do que de pessoas que conhecem sintaxe. Será a vingança da UML e o retorno do design declarativo/lógico e do BDD?
A verificação ortográfica foi feita com gemma4-12b, mas não deixei que mudasse a mensagem
Fico pensando o tempo todo em quando deixarei de precisar estar à força dentro do loop. Como desenvolvedor, eu realmente gosto de lapidar a estrutura do código, torná-lo mais claro, pensar em boas abstrações e dividi-lo em módulos
Eu encontro prazer nisso, mas também entendo que, em algum momento, eu me torno o fator limitante. Se o objetivo do software é beneficiar as pessoas, eu ainda deveria me importar com a aparência do código? No momento acho que a resposta é “sim”, mas e daqui a 3 anos? E daqui a 10?
Se algo exige muito julgamento e é um “código com o qual eu me importo profundamente”, então é difícil concordar com a direção discutida aqui. Não se deve tentar delegar decisões com as quais você se importa profundamente
Gosto da distinção entre loop do agente e loop do harness, mas só se deve delegar aquilo que pode ser especificado com precisão de antemão. No meu caso, geralmente são tarefas repetíveis, por exemplo, “veja como foi feito X e faça o mesmo em Y”, e isso é essencialmente previsível. Se, sem o meu julgamento, o resultado acabaria sendo algo para o qual eu diria “não”, então é melhor descer para colaborar dentro do loop do agente de que Armin fala. Isso é totalmente aceitável. É rápido e seguro. Mesmo antes dos assistentes de programação com IA, às vezes entrava na equipe um engenheiro absurdamente produtivo. Os colegas ficavam com inveja, dizendo “vocês só conseguiram fazer tudo isso porque têm X no time!”. Mas eles não tinham experimentado a maldição de ter uma pessoa assim por perto. Se não estiver perfeitamente alinhada, ela corre na direção errada a uma velocidade enorme
Não sei o que isso quer dizer na prática. Parece só um texto prolixo empilhando conceitos abstratos que parecem ter sido desenhados para sugerir um quadro maior, e no fim é só sobre deixar a IA escrever código
Vai ser assim daqui para frente? Na prática, não estamos virando líderes de pensamento, mas sim uma espécie de pseudoprofessores tentando conduzir uma horda de IAs burras até a resposta certa, e ainda precisamos mistificar esse papel para continuar parecendo líderes de pensamento? Sem deixar transparecer que isso tudo é só pose técnica?
O autor poderia ter editado para ficar mais conciso, mas, no estado atual, o fato de um leitor não entender o conteúdo não significa que haja mistificação
No trabalho e em projetos pessoais, estou vendo exatamente o que o texto original descreve, e me assusta que alguém veja isso como “um texto prolixo empilhando conceitos abstratos”. Fico com a impressão de que a maioria não faz ideia do que está acontecendo agora
Em IA, a validade da técnica de ponta mais recente dura umas 2 semanas. Eu não tinha conseguido acompanhar o loop do Ralph Wiggum, e agora sinto que foi melhor nem tentar
https://news.ycombinator.com/item?id=46682325