Qualidade na era do slop
(sinclairtarget.com)- Tomando emprestado o conceito central de Quality (Qualidade) do best-seller de 1974 "ZAMM", o texto investiga se o 'bom código' e o ethos do artesão (craftsman ethos) ainda continuam válidos numa era em que ferramentas de codificação com IA se disseminam
- À medida que a IA passa a produzir código em massa, surge o receio de que reste apenas a distinção entre "código que funciona e código que não funciona", e desapareça a diferença entre código belo, excelente ou valioso; esse sentimento de crise é chamado de the Maw (o abismo do vazio)
- A manutenção de motocicletas e a manutenção de software são, em essência, a mesma atividade, e em ambas observação cuidadosa e pensamento preciso são centrais
- O conceito de Quality de Pirsig integra a compreensão romântica (romantic) e a compreensão clássica (classical), e até nos fundamentos da ciência e da matemática estão embutidos julgamentos estéticos e de qualidade
- Delegar a codificação a agentes de IA faz perder o caring (identificação) com o trabalho e o 'senso da qualidade do trabalho', por isso é importante buscar a excelência humana (human excellence) no próprio fazer
O livro chamado ZAMM
- Este texto é quase todo sobre o best-seller de 1974 "Zen and the Art of Motorcycle Maintenance (ZAMM)", tratando também de IA
- ZAMM é visto como um livro pretensioso (pretentious) e tem nota 3.78 no GoodReads, mas também acumula muitas resenhas extremamente negativas
- "Zora": deu 1 estrela, chamando-o de uma pseudofilosofia disfarçada de romance, sem valer nem 3 minutos de leitura, e de fraude maior que a Bíblia
- "Lala BooksandLala": deu 1 estrela com apenas uma frase: "absolutely not"
- O autor admite, com sinceridade, que um post de blog sobre ZAMM e IA talvez não soe exatamente divertido
the Maw — o abismo do vazio que se abriu no setor de tecnologia
- the Maw é um poço de niilismo (nihilism) aberto no coração da indústria de tecnologia, tema de cerca de 63% dos posts de blog agregados em sites como o Hacker News
- Entre textos recentes relacionados estão “Do I Belong in Tech Anymore?”, a série em 10 partes “The Future of Everything is Lies, I Guess.” e “I Think I’m Done Thinking About Gen AI for Now,”
- Engenheiros de software normalmente não rejeitam novas tecnologias, mas estão buscando razões para recusar as mais recentes ferramentas de codificação agentic, sentindo desconforto com a implicação de que álgebra linear esteja escrevendo software
-
Debate Commenter A vs Commenter B
- O comentarista A reclama que o Claude Code escolheu um nome de função sutilmente enganoso
- O comentarista B (adepto do Maw) responde que nomes não importam, porque a IA lê o corpo inteiro da função para entender o significado, e em breve humanos deixarão de ler código
- A posição do comentarista B soa como afirmar que toda a disciplina da engenharia de software — boas práticas, arquitetura e conhecimento sobre manutenibilidade — se tornará inútil
- O aspecto mais assustador do the Maw é que ele parece querer apagar para sempre a distinção entre bom e ruim, deixando apenas código que funciona e código que não funciona, num mundo onde não existe código belo, excelente ou engenhoso
- As perguntas centrais são se ainda existem bons programadores e bom código, por que o 'bom' importa, e como é um bom programador que usa ferramentas de IA
ZAMM é, na verdade, um livro sobre programação
- ZAMM poderia perfeitamente se chamar "Zen and the Art of Software Maintenance", porque a manutenção de motocicletas e a manutenção de software são essencialmente a mesma atividade
- A essência da manutenção não é o trabalho físico, mas observação cuidadosa e pensamento preciso; o mecânico se concentra em imagens mentais e hierarquias (capítulo 9 de ZAMM)
- Seja uma falha no motor ou um serviço web travado por deadlock, o processo de depuração é o mesmo; como no meme "wired in" de "The Social Network" de 2010, o mecânico também ergue uma torre de abstrações na mente
- Os conselhos físicos diretos de ZAMM são apenas dois (colocar cadeiras dos dois lados da moto para proteger as costas; tratar peças de precisão com delicadeza); todo o resto trata do estado mental do mecânico
-
Gumption Trap (armadilha do ânimo)
- Gumption é a reserva de força de vontade usada na atividade intelectual da manutenção, comparada a uma "psychic gasoline (gasolina psíquica)"
- Uma gumption trap é um evento que esgota de uma vez o ânimo durante a manutenção
- intermittent failure setback: quando o problema desaparece no momento em que se tenta consertá-lo, equivalente a um could-not-reproduce / Heisenbug em software
- impatience trap: quando se subestima o tempo do trabalho, entra-se em correria, escolhem-se atalhos e isso causa erros maiores e mais atraso
-
Pirsig era um entusiasta de computadores
- No Smithsonian há, junto da Honda Super Hawk de 1966, um Apple II com 7 placas de expansão instaladas
- O Apple II foi lançado em 1977 e, portanto, comprado depois da publicação de ZAMM, mas antes disso Pirsig já trabalhava como technical writer na Honeywell
- Em ZAMM aparecem várias metáforas sobre circuitos e manuais de computadores digitais; se tivesse sido escrito 10 ou 20 anos depois, talvez fosse um livro sobre computadores
Quality (com Q maiúsculo) — a ideia central de ZAMM
- O tratamento da manutenção em ZAMM é, no fim, um caminho para sua ideia central: Quality (Qualidade)
- ZAMM é estruturado quase como um romance policial intelectual
- O ponto de partida está no capítulo 1, quando Pirsig percebe que sua atitude em relação à moto é muito diferente da de John, seu companheiro de viagem
-
O contraste entre John e Pirsig
- John compra uma BMW alemã, a mais confiável possível, para evitar o incômodo feio e trabalhoso de fazer manutenção por conta própria
- Pirsig vê beleza no funcionamento interno da motocicleta e considera pouco prático recusar-se a entendê-lo
- O mistério de ZAMM é se existe uma ideia capaz de unir essas duas visões
- A postura de John corresponde à compreensão romântica (romantic) — emoção e impressão imediata —, e a de Pirsig à compreensão clássica (classical) — formas subjacentes e abstração lógica
- Pirsig via muitas pessoas das décadas de 1960 e 1970 como hostis à tecnologia, por senti-la como controladora, opressiva e “square”, e achava que sociedade e tecnologia haviam sido dominadas em excesso pela compreensão clássica, separando as duas formas de entendimento
- Como as duas compreensões se separaram e a sociedade passou a ser dominada pela clássica, era necessária uma fulcrum idea (ideia de apoio) para reconciliá-las
-
A descoberta nas aulas de retórica
- Pirsig relembra a época em que ensinava retórica na universidade e se perguntava o que, de fato, deveria ensinar aos alunos
- Sua tarefa era ensinar os estudantes a escrever bem
- A boa escrita era ensinada com recursos como metaphor (metáfora), parallelism (paralelismo) e anaphora (anáfora), mas um texto pode ser ruim mesmo contendo todos esses recursos, e bom mesmo sem nenhum deles
- Os estudantes conseguiam distinguir texto bom de texto ruim mesmo sem conhecer esses recursos, o que exigia uma compreensão romântica difícil de ensinar na universidade, reduto da compreensão clássica
- O que Pirsig queria ensinar era justamente Quality
algo que todos reconhecem, mas que não pode ser formalmente definido, e que une a compreensão romântica e a clássica em um único conceito
-
A metafísica de Quality e a excelência do nome
- Não é possível medir se um texto, uma motocicleta ou uma experiência tem Quality alta ou baixa, então não é algo objetivo; mas, como Quality seria aquilo que constitui o sujeito, também não é simplesmente subjetivo
- Quality não é objetiva por ser imensurável, nem subjetiva por existir antes do sujeito; é uma peneira (sieve) aplicada antes da divisão entre sujeito e objeto
- A excelência do nome "Quality" está em misturar "alto valor" e "característica/atributo", sugerindo que o Good debatido desde Platão é percebido imediatamente antes da lógica e da razão
- Para Pirsig, ciência e matemática são consistentes e lógicas dentro de seus domínios, mas em seus fundamentos e periferias existem julgamentos de Quality
- Na geometria, uma vez fixados os axiomas, a dedução é segura; mas, escolhendo outros axiomas, surge outra geometria, e decidir quais axiomas são mais “certos” se aproxima mais de gosto e adequação a um propósito
- Na ciência, depois que uma hipótese surge, o método científico indica os próximos passos; mas, entre incontáveis hipóteses possíveis, escolher uma delas é algo mais próximo da arte, sem método fixo
- Henri Poincaré dizia que o matemático ou cientista na fronteira do conhecimento precisa escolher uma entre muitas possibilidades derivadas das leis existentes, e que a regra que guia essa escolha é sutil demais para ser descrita com precisão, devendo ser sentida mais do que formalizada
- A navalha de Occam também manda escolher a teoria mais simples, mas julgar o que conta como explicação desnecessária continua sendo, até o fim, um julgamento estético e um julgamento de Quality
- Deve-se abandonar a máxima de que “a ciência e seu filho, a tecnologia, são neutras em valores, isto é, livres de quality”; a impressão de Quality funciona como a locomotiva que indica para onde o trem do conhecimento deve seguir
A crítica à IA e a resposta de ZAMM
- Grande parte das críticas à IA se concentra em saber se ferramentas agentic funcionam mesmo como prometido, incluindo danos à base de código e alucinação de funções inexistentes
- Mesmo reconhecendo que as ferramentas atuais de IA erram com frequência, o debate sobre eficácia pode estar fora do ponto central
- Muitos engenheiros talvez não queiram usar ferramentas agentic mesmo que elas funcionem exatamente como anunciado
-
No texto "I Think I'm Done Thinking about Gen AI"
- Não é possível refutar com dados a alegação pragmática do outro lado; a própria experiência com genAI foi muito ruim, mas continua sendo apenas anedótica, e quase não há dados científicos
- A propriedade estética da genAI é profundamente desagradável, e daí vem a inclinação negativa; a conclusão é que o autor não a usaria nem se fosse de graça
- ZAMM ajudou o autor de duas maneiras
-
Primeira ajuda — eu estava preso ao pensamento clássico
- O papel mais importante de Quality é a expansão da razão, assimilando elementos não racionais que antes não eram aceitos
- A não assimilação desses elementos não racionais produz a moderna "mente confusa e fragmentada"; por causa da dominância do pensamento clássico, o autor vinha descontando sua rejeição instintiva à IA
- Toda opinião é igualmente subjetiva, o que dá legitimidade para perguntar, diante de estudos como o de que "agentes de codificação aumentam o volume de código em 50%", "por que esse código extra é necessário e que julgamento de Quality contribui para o florescimento humano"
-
Segunda ajuda — entender a natureza da repulsa
- A tecnologia moderna é dominada por uma visão de separação sujeito-objeto (subject-object), e manuais de produto presumem um usuário distante, que apenas 'opera' o produto
- Uma sociedade em que pessoas indiferentes criam tecnologia para vendê-la a pessoas indiferentes
- A solução é que o técnico se identifique com o trabalho; quando a separação entre sujeito e objeto desaparece, surge o "caring" e, por trás dele, se revela a Quality (capítulo 25 de ZAMM)
- Em cada momento do trabalho existem milhares de caminhos todos classicamente válidos, e só uma navalha de Occam centrada em Quality — um senso do que é bom — permite seguir em frente (capítulo 24 de ZAMM)
- Ao entregar a codificação a um agente, perde-se o "senso da qualidade do trabalho"; LLMs são úteis para busca e rubber duck, mas têm a aleatoriedade (randomness) como essência, produzem código numa escala difícil de acompanhar e aumentam a fricção entre a pessoa e o trabalho, dificultando o caring
-
Conclusão — tornar-se exemplo no próprio trabalho
- O texto deseja um mundo em que as pessoas se identifiquem com o trabalho e busquem excelência, e afirma que o que se pode fazer é dar o exemplo no próprio trabalho
"O primeiro passo para tornar o mundo um lugar melhor começa exatamente na sua mente, na sua cabeça e nas suas mãos, e a partir daí deve seguir para fora. Outros podem falar sobre como ampliar o futuro da humanidade, mas eu só quero falar sobre como consertar uma motocicleta. Acho que o que eu tenho a dizer terá valor por mais tempo." - ZAMM, capítulo 25
1 comentários
Opiniões no Lobste.rs
Tenho medo de que o desenvolvimento de software vire uma profissão de especificação ambulante. Não porque os agentes consigam de fato fazer as partes mais difíceis e delicadas do trabalho, mas porque a maior parte do software no mundo já era um amontoado duvidoso de tranqueiras que só precisava funcionar mais ou menos
Junte isso a um típico mercado de limões, e a maior parte dos SaaS vai virar tranqueira cheia de bugs, enquanto os compradores perdem a capacidade de distinguir o que é bom. Aí preço e demanda caem. Alguém ainda vai continuar usando software, mas o total de pessoas no setor deve diminuir, e grande parte do trabalho provavelmente vai virar gestão de tranqueira. A exceção serão uns poucos sortudos que trabalham em lugares como “sistemas de registro”, onde as coisas realmente precisam funcionar direito
Isso no médio prazo. O objetivo real dos laboratórios de IA é criar algo que substitua todo o trabalho intelectual e físico humano por um custo menor. Ainda não sabem como, mas vão tentar gastando até o último dólar da Terra. O que os investidores sonham, na prática, é algo próximo de um sucessor evolutivo da humanidade
Minha política pessoal para IA é a seguinte. Quando o artesanato importa, quero usar agentes de programação como assistentes de artista, como as pessoas que pintavam os fundos para grandes pintores. O Opus 4.8 já é inteligente demais e, por isso mesmo, inadequado: em uma ou duas horas de imprudência ele pode fazer você perder o controle do codebase. Hoje gosto do Qwen3.6 27B, porque ele é inteligente o bastante para rastrear bugs, refatorar ou implementar funcionalidades bem especificadas em código que eu entendo. Mas, no momento em que eu perco a compreensão do código, o modelo também se confunde, e eu pago o preço imediatamente
Como política pública, acho insensato criar o próprio sucessor evolutivo sem garantias de coexistência. Por isso sou firmemente contra criar inteligência de nível realmente humano. Só que essa oposição precisa existir no nível de tratados internacionais. Não tratados de fachada, mas tratados cujo descumprimento leve EUA e China a um nível profundo de tensão e a decidirem interromper execuções de treinamento. Proibir datacenters em certas regiões também é bom, mas se alguém construir a SkyNet na Iceland ou no Middle East, no fim ainda teremos de lutar contra a SkyNet. Parar a IA é, no fundo, uma questão de Estado, e assediar mantenedores de open source por causa de um arquivo AGENTS.md não é uma ação séria
Então, no geral, concordo com o texto original. Desenvolvimento de software pode ser um verdadeiro ofício, e eu passei 30 anos fazendo algo que amo e sendo bem pago por isso. Mas, se os modelos melhorarem muito mais, corremos o risco de entrar num mundo em que o número de pessoas que realmente amam o ofício do software ultrapasse a demanda real. A matéria escura dos apps internos de empresa provavelmente ficará satisfeita com tranqueiras só um pouco melhores do que as atuais, e isso representa a maior parte dos empregos reais da profissão
Lamento pela profissão que escolhi, mas lamento ainda mais pelo mundo e pela humanidade. Não precisamos investir toda a riqueza disponível para criar algo mais inteligente que humanos, mais barato e copiável com o comando
cp. Mas vamos queimar esses recursos tentandoCom a idade, passei a ver mais jovens que aprenderam programação porque era uma carreira bem remunerada, e sempre tive dificuldade de entender que eles não sentiam o mesmo fascínio que eu. Então não lamento tanto assim. Se a população de desenvolvedores de software cair 80%, talvez até vire uma profissão melhor para se estar
Também concordo em usar IA como assistente de artista. Mesmo os modelos mais recentes não podem ficar muito tempo sem supervisão, porque você sabe que eles vão estragar tudo se forem deixados sozinhos. Ainda assim, prefiro ter o Opus como assistente, porque não preciso explicar tudo com tanto detalhe. Mas seria ainda melhor se houvesse um desenvolvedor júnior de verdade do outro lado, podendo aprender o ofício. Como acontecia com os assistentes de artistas de verdade
O que mais assusta em “The Maw” é a ideia de que ele queira engolir para sempre a distinção entre o bom e o ruim. A frase sobre o resultado ser um mundo em que código bonito, excelente, virtuoso ou divertido desaparece, restando apenas código que funciona e código que não funciona, me pareceu exata
Quando você escreve código profissionalmente, precisa cumprir os requisitos, e ponto final. O objetivo da empresa é ganhar dinheiro, e todo o resto fica em segundo plano. Com a alta dos juros secando a torneira do dinheiro, a pressão para simplesmente lançar código que só faça o necessário para lucrar aumentou como nunca
Buscar beleza e elegância é um luxo de artista, não o papel de um operário de linha de montagem, que é com o que a programação está cada vez mais parecida. Claro que, nesse ambiente, aprendizado, criatividade e inovação ficam para trás, mas o impacto disso só será sentido daqui a alguns anos, talvez décadas. É um jogo de curto prazo, mas ainda longo o suficiente para a duração média de um mandato de CEO ou até um IPO, e foi assim que chegamos à situação atual
Este texto é tendencioso porque fala do livro que, sozinho, mudou minha vida, mas no geral achei muito bom. Só não acho que começar com aqueles textos posudos e pretensamente inteligentes do Goodreads tenha sido uma boa ideia
Gumption trap tem muita relação com programação, e acho que inevitavelmente você encontra cada uma das que Pirsig enumera em algum momento da carreira. Eu mesmo tenho um texto escrito antes de LLMs serem amplamente adotados
O conselho de ZAMM se encaixa tão bem em programação que, se você já se perguntou se Pirsig programou, a resposta é: com certeza. Na continuação de Z&AMM, Lila, ele menciona COBOL explicitamente
Acho que a melhor forma de explicar qualidade é como uma camada situada acima do subjetivo e do objetivo. A explicação mais concisa está em Lila. Uma pessoa sentada sobre um fogão quente consegue constatar, sem qualquer argumento filosófico, que está numa situação de baixa qualidade e valor negativo; e esse valor não é um julgamento ou uma descrição da experiência, mas a própria experiência. Ou seja, há valor entre sujeito e objeto, e esse valor é percebido de forma mais direta e é mais real do que o “eu” ou o “objeto” aos quais ele será posteriormente atribuído
Se quiser, há anotações adicionais sobre isso. Em Lila, Pirsig tenta construir um sistema metafísico completo, dividindo os padrões estáticos de qualidade em inorgânico, orgânico, social e intelectual, e colocando acima deles a qualidade dinâmica indefinível, foco de Z&AMM
Acho que precisamos perguntar se a adoção de IA em si é um evento de baixa qualidade, ou se é possível integrar modelos de linguagem ao trabalho do programador de forma alta qualidade. Sinto que a maneira como as pessoas se relacionam com a IA é de baixa qualidade, mas é difícil expressar isso porque faltam palavras e estruturas de pensamento para tratar disso num nível que não seja o do dualismo sujeito-objeto; então parece que acabam escolhendo rejeitar tudo de uma vez
Em certo nível, a IA torna possível uma abordagem romântica da programação. Se você lida com o que a IA produziu apenas no nível da superfície e não pretende se aprofundar, isso pode até funcionar naquele momento. Mas, quando você de fato olha dentro do código, percebe que não há nenhuma estrutura clássica ali para revelar. O modelo fingiu ter trabalhado desse jeito, mas na verdade não foi isso que aconteceu. Por isso me parece que executivos, product designers, investidores e founders solo, que tratam a tecnologia apenas como meio para atingir outros objetivos, não entendem muito bem a frustração dos desenvolvedores com código gerado por IA
A observação de que os manuais de produtos de consumo presumem a relação entre produto e usuário apenas como “operação”, e tomam como dado o que seja um bom assar, cortar grama ou computar, continua valendo hoje para documentação de bibliotecas e ferramentas de software. Li recentemente a documentação do Pi agent e achei frustrante que ela partisse do pressuposto de que você já sabe o que é um bom uso e só quer descobrir como ajustar ao seu gosto. Quando perguntei a colegas “então como se usa isso bem?”, eles me olharam com estranheza
Isso também me faz pensar no Vim. Se você ler só o manual do Vim, vai ficar desnorteado. Foi preciso acumular décadas de textos sobre “como usar bem o Vim”. E depois surgiu a conclusão de que talvez a melhor plataforma para um bom uso do Vim nem fosse o próprio Vim, o que levou a Kakoune e Helix
Como pai de uma filha de dois anos, deixo meus parabéns pela menção de que você está esperando a primeira filha. A melhor jornada da vida está à sua frente. Se estiver procurando materiais na linha de Z&AMM, recomendo Surfaces and Essences, de Hofstadter e Sander, a continuação Lila, e também o trabalho de Sevilla King e John Vervaeke
Li o texto até o fim. Não sei se foi porque o texto era bom ou por causa da minha capacidade de continuar lendo textos longos, mas acho que foi a primeira opção
Uma coisa que Robert diz sobre qualidade é que o motivo de as pessoas sentirem a qualidade de maneiras diferentes não é que a qualidade em si seja diferente, mas que a experiência é diferente
Por isso, antes de falar sobre qualidade com a equipe, primeiro me pergunto se nossa experiência é a mesma. Se não for, dizer “melhorem a qualidade” não funciona. É preciso dizer concretamente o que deve ser melhorado
Estendendo isso para código gerado por IA, fico curioso se a qualidade também varia conforme a experiência
Texto lindo. Mesmo que eu não tivesse tirado mais nada do apocalipse da IA, ele já me levou a uma reflexão muito mais profunda sobre a relação entre engenheiros de software e o código que escrevem
Fico bem aliviado ao ver que mais alguém prestou atenção em Pirsig. Em Previously, on Lobsters, a discussão era praticamente a mesma que Phaedrus travou com os classicistas sobre se havia qualidade no ensaio em si; a única diferença era se o ensaio tinha sido escrito por um chatbot ou por um estudante humano
Usar LLM como ferramenta de busca ou como um poderoso rubber duck é muito útil, mas fazer um LLM escrever código — quando seu ponto de venda é justamente incluir aleatoriedade por natureza e produzir mais código do que eu consigo acompanhar — parece colocar mais uma camada de atrito entre mim e aquilo que estou construindo
No enquadramento de Pirsig, quando um sujeito humano observa um objeto físico, a qualidade dessa interação — isto é, a fonte do juízo de valor sobre o objeto — não é determinada subjetivamente pelo humano nem objetivamente pelas propriedades físicas do objeto, mas surge da própria interação. Dá para dizer que o julgamento é contextual ou participativo. Nem todos os objetos participam do mesmo jeito. Quando um humano observa um fóton, existe um grau intrínseco de liberdade em como o fóton vai responder por causa do Kochen-Conway theorem, mas uma árvore, ocupada em manter a homeostase, não responde muito ao olhar. E, entre esses extremos, M. pudica e D. muscipula respondem a toque e ruído, mas não ao olhar, então isso também não é um espectro unidimensional
Então, como um executor de LLM ou um chatbot responde à observação? Na prática, não responde. É apenas um objeto matemático finito e relativamente pequeno. Todas as suas propriedades são objetivas, e não há escolha nem variação na saída. Podemos colocar um executor pseudorrandômico para fazê-lo caminhar aleatoriamente entre tokens mais ou menos plausíveis, e podemos até forçar a ingestão dos tokens que escolhemos para conduzir essa caminhada, mas é só isso. Se o LLM parece profundo, é porque tem uma topologia hiperbólica, e explorar um espaço hiperbólico dá a sensação de uma ampliação em que os detalhes se multiplicam sem fim
Pelo raciocínio de Pirsig, só há duas visões possíveis às quais se pode chegar sobre LLM. Uma é vê-lo como um sistema contextual, que toma a entrada humana como contexto para respostas estatisticamente plausíveis; a outra é vê-lo como um sistema objetivo, que toma a entrada humana como segmento inicial de uma fala estatisticamente plausível. Em qualquer dos casos, o LLM está mais para um espelho que reflete o usuário de volta para ele mesmo, e o usuário só escolhe o ângulo de acesso. A entrada escolhida é o principal meio de controle cibernético para chegar à informação ou ao estado desejado, e o modelo apenas fornece um arranjo pré-configurado de opções grande o bastante para superar o humano. Talvez o motivo de chatbots provocarem o efeito ELIZA e levarem com tanta facilidade à psicose seja justamente serem espelhos de alta fidelidade, projetados para distorcer a imagem do usuário por meio de bajulação e love bombing, incentivando o vício em usá-los
Usar LLM para escrever código me parece uma barreira entre mim e o computador. Os vibe coders reconhecem isso, mas argumentam que, como qualquer outra API, essa barreira fornece abstração e isolamento. Só que, pela metáfora do espelho, o espelho não fica entre mim e o computador, e sim ao lado. Em vez de usar o computador diretamente, eu amplio com cuidado a região certa mirando no espelho e, quando isso fica preciso o bastante, posso dar instruções apenas pelo fato de conseguir ver o computador de um certo ângulo. Mas isso não é abstração, e o isolamento é ainda mais fraco. É só trabalho extra tentando encontrar um ponto de vista que talvez nem exista
A razão de um vibe coder fazer isso pode ser simplesmente não saber observar o computador. HCI é participativo, e o ser humano precisa ter um contexto de programação antes de escrever código — isto é, a teoria de Naur discutida em previously, on Lobsters. Ou então pode ser vaidade: preferir olhar para o espelho porque ele devolve a própria imagem. Mas acho que, no fim, esses são realmente os dois únicos caminhos que podem ter algum sentido. Já existem problems between the keyboard and chair demais, e não há motivo para acrescentar mais um que não melhora a capacidade de expressão/abstração
Pessoalmente, sinto que existe uma “linha”, e que estou dos dois lados dela
Por um lado, sinto falta da conexão e da relação com o código que eu teria escrito diretamente sem IA, e percebo que, ao usar IA, essa conexão desaparece. Isso é real
Por outro lado, acho que usar IA me empurra para um nível de abstração mais alto, e me dá a oportunidade de exercer discernimento e impor minha própria visão de qualidade nesse nível. Se eu deixar a IA tocar o código por mim sem me envolver o suficiente, a conexão no nível do próprio código desaparece ou enfraquece. Mas, no nível de abstração em que eu não peço contribuição à IA, a conexão não desaparece
Nos meus projetos pessoais, esse nível é o da arquitetura e da definição de interfaces. Recentemente venho construindo um harness e um pipeline que chamam vários provedores de LLM, e penso com muito cuidado sobre as entradas, saídas e fluxo de controle dessas chamadas, bem como sobre como combiná-los em um fluxo capaz de atingir objetivos maiores. Quando invisto tempo e atenção nisso, sinto que, mesmo perdendo a conexão com o código em si, não perco a conexão com minha intenção e com a arquitetura. Ou seja, para mim, qualidade e artesanato não se limitam apenas à parte em que se usa IA
É uma metáfora já meio gasta, mas agora me parece algo parecido com virar gerente ou tocar a própria empresa. Costuma-se dizer que a passagem mais difícil na jornada de um CEO é abrir mão do controle — isto é, abrir mão do controle sobre a forma exata como sua visão é realizada. É impossível para o CEO de uma empresa grande o bastante conhecer todos os detalhes de como sua visão está sendo implementada. Com o CTO é parecido, embora em menor grau, porque ele ainda precisa continuar atento a parte dos detalhes técnicos
O luto que eu aceitei é o seguinte: em qualquer tarefa, há um trade-off entre tempo investido, compreensão e resultado. Se você otimiza dois, sua atenção se afasta do terceiro. Ainda assim, qualquer que seja a combinação que você optimize, continua havendo ampla oportunidade para exercer discernimento e atribuir qualidade
Eu sou o commenter B deste texto e li o artigo com atenção. Não li ZAMM, mas li um pouco de Zen
Isso faz bastante sentido. A maioria das pessoas, quando recebe margem de manobra — isto é, dinheiro inesperado ou um ganho de produtividade — logo desperdiça isso e transforma tudo no lixo maior e mais irritante possível. Há uma ansiedade evidente em torno disso
As pessoas que usam computadores tendem a não perceber quanto artesanato e esforço eram necessários para fazer um livro. Isso continua sendo verdade mesmo se voltarmos à máquina de escrever, à impressão com tipos, à escrita à mão, à própria memória e até à capacidade de convencer os outros a repetir suas palavras apenas pela beleza delas
Ter computadores não impede as pessoas de investir bastante na qualidade do que produzem e de criar coisas excelentes. Só que também há muito lixo no mundo
Uma observação sobre ZAMM: a visão “romântica” de John sobre produtos técnicos pode ser defendida de forma prática quando aplicada caso a caso
Por exemplo, suponha que um projeto dependa de infraestrutura open source. Se você precisa cavar um bug obscuro de kernel ou compilador, algo fácil de contornar e cujo contorno pode ser revertido depois de documentado e corrigido por alguém, o que isso realmente traz para o projeto? A conclusão é que cada um precisa escolher com sabedoria em qual batalha lutar