Agentic Coding é uma armadilha
(larsfaye.com)- Agentic coding é uma abordagem em que a pessoa define os requisitos e o plano, e vários agentes de programação fazem a implementação, mas sua estrutura amplia continuamente a distância entre o código gerado/commitado e quem o desenvolve
- Essa abordagem só funciona quando desenvolvedores experientes fazem uma revisão crítica em nível de arquitetura, mas o uso excessivo de IA pode enfraquecer as habilidades necessárias para isso e gerar dívida cognitiva (cognitive debt)
- Como no paradoxo da supervisão abordado em uma pesquisa da Anthropic, usar o Claude de forma eficaz exige capacidade de programação para supervisioná-lo, e o uso de agentes de código pode enfraquecer justamente essa capacidade
- LLMs tendem a ser usados para aumentar a quantidade de código gerada em um certo tempo, em vez de priorizar compreensão profunda e concisão, e podem preencher requisitos ambíguos com suposições ou alucinações, criando mais revisão, correções e consumo de tokens
- As falhas do Claude e a variação no custo de tokens expõem a dependência de fornecedor e a incerteza de custos; a IA pode reduzir a dívida de compreensão quando é usada mais como apoio para planejamento, documentação, pesquisa e delegação limitada do que como um orquestrador que substitui a implementação
Trade-offs estruturais
- Agentes de programação são úteis e poderosos, mas já há trade-offs concretos e práticos a considerar
- Mitigar a ambiguidade vinda da não determinismo da IA aumenta a complexidade dos sistemas ao redor
- As habilidades de muitos desenvolvedores podem atrofiar
- Uma falha de um fornecedor específico, como uma indisponibilidade do Claude Code, pode paralisar a equipe inteira
- O custo de funcionários é fixo, mas o custo de tokens pode variar e aumentar continuamente
- Para essa abordagem funcionar, desenvolvedores experientes precisam pensar criticamente em nível de arquitetura e ser capazes de identificar problemas em milhares de linhas de código gerado antes que eles cresçam
- Mas ferramentas de IA podem afetar negativamente o pensamento crítico e a clareza cognitiva necessários para isso, ampliando a dívida cognitiva (cognitive debt)
Não é apenas uma nova abstração
- A interpretação de que isso seria apenas “programadores subindo para uma camada de abstração mais alta” não é suficiente
- Mais ambiguidade não significa automaticamente um nível mais alto de abstração
- Quando surgiram FORTRAN, compiladores e linguagens de alto nível, também houve preocupação com bugs, instabilidade, perda de eficiência e aumento da “mágica”
- No passado, essas preocupações eram em grande parte normativas e teóricas, sobre o que se perderia ao adotar novas tecnologias, mas as ferramentas de IA já estão mostrando efeitos práticos poucos anos após surgirem
- O impacto não se limita a desenvolvedores juniores; também aparece em profissionais com mais de 10 anos de experiência
- Desenvolvedores juniores enfrentam uma curva de aprendizado mais íngreme ao serem empurrados para revisar código gerado em vez de lidar diretamente com o código
- Revisão de código é importante, mas representa apenas metade do aprendizado; quando desaparece o atrito de escrever e depurar código diretamente, a capacidade de aprender enfraquece muito
- Como esse fenômeno leva tempo para ser estudado, evidências anedóticas também são importantes para entender o que está acontecendo em tempo real, mas há materiais que dão suporte a isso, como o relatório do MIT Media Lab e uma reportagem relacionada à Microsoft
Por que esta mudança é diferente
- Quando desenvolvedores de C++ migraram para Java ou Python, eles não passaram a reclamar de “brain fog”, e administradores de sistemas que foram para AWS também não sentiram que estavam perdendo a capacidade de entender redes
- Não é novidade que engenheiros seniores, ao migrarem para funções de gestão, programem menos e com o tempo fiquem “enferrujados”
- No caminho tradicional, engenheiros acumulavam décadas de programação, atrito e resolução de problemas antes de ir para papéis em que tomavam mais decisões de arquitetura do que lidavam com sintaxe
- Agora, mesmo sem essa experiência de longo prazo, desenvolvedores estão sendo empurrados para fluxos de trabalho de nível mais alto, nos quais precisam gerenciar agentes de IA
- O problema é que esses fluxos exigem as mesmas habilidades que antes eram adquiridas com décadas de experiência
- Engenheiros seniores também não são exceção
- Simon Willison afirma que, mesmo com quase 30 anos de carreira, sem um “modelo mental sólido” sobre o que a aplicação pode fazer e como ela funciona, fica mais difícil raciocinar à medida que funcionalidades são adicionadas
O paradoxo do bom orquestrador
- Uma pesquisa recente da Anthropic discute o “paradoxo da supervisão” como um risco do uso frequente de agentes de programação
- O ponto central é que usar Claude de forma eficaz exige supervisão, e supervisionar Claude exige justamente as habilidades de programação que podem ser enfraquecidas pelo uso excessivo de IA
- Sandor Nyako, que gerencia 50 engenheiros no LinkedIn, observou a propagação da atrofia de habilidades dentro da organização e pediu à equipe que não use IA em “tarefas que exigem pensamento crítico ou resolução de problemas”
- Para ele, desenvolver habilidade exige passar por dificuldades e treinar o músculo de pensar profundamente sobre problemas; sem pensamento crítico, fica difícil questionar se a IA está correta
- O critério do que seria “uso excessivo” também é incerto, mas pesquisas baseadas em dados e materiais anedóticos mostram que as habilidades podem enfraquecer rapidamente em poucos meses
- O uso de agentes de programação cria uma contradição: enfraquece exatamente as habilidades necessárias para gerenciá-los bem
LLMs aceleram a parte errada
- Não era obrigatório escrever código mais rápido a qualquer custo
- Principalmente não era necessário produzir mais rapidamente grandes volumes de código que não são totalmente compreendidos ou que não podem ser revisados em um tempo razoável
- Antes da IA, as prioridades de bons desenvolvedores geralmente eram estas
- Entender o código e sua relação com a base de código
- Verificar se ele segue padrões documentados e eficientes
- Minimizar a quantidade de linhas necessária para atingir o objetivo, mantendo a legibilidade
- Considerar o tempo de processamento
- Agentic coding e LLMs praticamente inverteram essa ordem de prioridade
- A capacidade atual e a forma de uso tendem a focar em velocidade, aumentando a quantidade de código gerada dentro de um intervalo de tempo
- Velocidade é um subproduto natural de alta proficiência, mas, quando forçada, leva à queda de precisão
- É possível usar LLMs para aumentar compreensão profunda e concisão, mas adoção forçada e o superaquecimento organizacional medido por uso de tokens mostram que o uso real não está seguindo esse caminho
Programar também é planejar
- Alguns desenvolvedores planejam e pensam melhor por meio do código
- Pensar e trabalhar com código não é trabalho repetitivo sem sentido, mas um processo que leva a refletir tecnicamente sobre segurança, desempenho, experiência do usuário e manutenibilidade
- Em uma entrevista sobre Spec Driven Development, Dax, criador do OpenCode, disse que, ao lidar com tarefas novas ou difíceis, ele descobre o que precisa fazer ao digitar o código diretamente
- Ele prefere formar o conceito mexendo diretamente em tipos, interações entre funções e estrutura de pastas, em vez de começar escrevendo um enorme spec
- O que uma pessoa diz nem sempre corresponde exatamente ao que ela quer dizer, e LLMs preenchem ambiguidades com suposições ou alucinações
- O resultado é mais revisão, mais correções pelos agentes, mais uso de tokens e um distanciamento maior do artefato gerado
- Por outro lado, mesmo com prompts muito claros e estruturados, LLMs podem gerar métodos alucinados
- Como LLMs não são compiladores, mas motores de previsão do próximo token, não dá para substituir sistemas determinísticos por sistemas probabilísticos e esperar ambiguidade zero
- Até desenvolvedores seniores bastante pró-IA começam a ver esse distanciamento como um problema crescente
Dependência de fornecedor e incerteza de custos
- Durante as falhas do Claude, surgiram posts relatando que alguns desenvolvedores e equipes de engenharia simplesmente pararam
- Alguns fluxos de trabalho e habilidades de programação já chegaram a um nível de forte dependência de um fornecedor específico de IA
- Habilidades que antes podiam ser exercidas apenas com teclado e editor de texto passaram a exigir assinatura de um provedor de modelos de IA
-
O custo de tokens é difícil de prever
- Provedores de modelos são fortemente subsidiados, e os próprios modelos seguem mudando sobre uma base instável
- O lançamento de novos modelos repete padrões de benchmarks altos, hype e reclamações de que foram “nerfados” após uso real
- Também surgem reclamações de que a mesma tarefa passa a consumir 2 a 3 vezes mais tokens
- O custo de funcionários é conhecido, mas o custo de tokens é difícil de prever por dia, mês ou ano
- Se a equipe inteira adota agentic coding como padrão, a conta de custos precisa permanecer altamente flexível
- Primeagen diz que, em um workflow totalmente agentic, “o provedor do modelo basicamente possui você”
- Pode surgir uma estrutura industrial em que é preciso pagar pelo consumo de tokens para realizar coisas que antes dependiam de pensamento crítico e capacidade de resolver problemas
- Isso se aproxima menos de uma simples dependência de fornecedor de produto e mais de uma dependência de fornecedor sobre a capacidade técnica de toda uma indústria
- A base financeira e intelectual pode ser abalada a qualquer momento, e LLMs locais ainda não estão prontos para absorver esse nível de uso
- Isso não é teoria; já está sendo reportado, e os próprios provedores de modelos vêm destacando o tema
- Outra pesquisa da Anthropic afirma que habilidades de depuração tiveram queda de 47%
- Se a IA for adotada agressivamente no trabalho, especialmente em engenharia de software, pode-se deixar de desenvolver a habilidade central de depurar quando surgem problemas, em troca de depender da IA para resultados rápidos
Uma abordagem que reduz o papel da IA
- LLMs podem ser ferramentas poderosas para aprendizado e aumento de capacidade
- Eles podem ajudar a explorar conceitos e técnicas com mais profundidade e amplitude, além de permitir experimentar novas ideias com menos esforço do que antes
- Ferramentas de geração de código em si não são novidade
- Emmet, autocomplete e snippets já eram ferramentas para escrever menos código manualmente e gerar mais
- COBOL também buscava expressar mais comandos com menos digitação por meio de palavras em inglês como
MOVEeWRITE - O lema do jQuery também era “write less, do more”
- LLMs podem ser vistos como mais uma adição a essa linhagem de ferramentas de geração de código
- A diferença importante está em usar LLMs e agentes de programação como processo auxiliar
- É possível usar IA no brainstorming da etapa de planejamento sem sacrificar a habilidade individual em nome de produtividade, mantendo envolvimento ativo na implementação
- Delegar só quando necessário permite ganhos de produtividade enquanto reduz a dívida de compreensão
Forma de uso no dia a dia
- Usar LLMs para gerar specs e planos, mas deixar a implementação sob liderança humana
- Isso inverte o workflow de “orquestração”, com 20% a 100% de programação manual dependendo da tarefa
- Mesmo ao usar o modelo, escrever pseudocódigo com frequência reduz a distância entre o pedido e o código gerado
- O modelo é usado para gerar código temporário, documentação conversacional e pesquisa
- Usá-lo como ferramenta de delegação responsável para fazer perguntas, iterar, refatorar e deixar abordagens mais claras
- Não gerar de uma vez mais código do que se consegue revisar
- Se houver código demais para revisar, reduzir o ritmo, quebrar o trabalho em partes e, se necessário, refatorar manualmente para entender o resultado final de forma abrangente
- Não delegar a LLMs ou agentes implementações que a pessoa nunca fez ou não conseguiria fazer sozinha
- A exceção é quando o objetivo é educação ou tutorial, e nesses casos o resultado muitas vezes é descartado depois
- Em resumo, a IA deve ser usada mais como o Computer da nave em Star Trek do que como o Data
Trabalhar melhor, não apenas mais rápido
- O ganho de produtividade dos modelos é real
- Ao mesmo tempo, o atrito e a compreensão que surgem do contato direto e frequente com o trabalho também são reais e importantes
- Tentativas de democratizar a programação sem entender programação fracassaram repetidamente
- Para entender código, é preciso se engajar diretamente com ele
- Se a pessoa deixa de se envolver continuamente com o código e de escrevê-lo, pode perder essa compreensão e conexão
- Ao perder compreensão, também enfraquece a capacidade de gerenciar melhor os agentes, e a fase de programação com IA vira uma transição estranha e desnecessariamente estressante
Isso pode ser mais um grande experimento
- A tendência atual parece mais um novo experimento em larga escala que estamos conduzindo em nós mesmos sem compreender suficientemente seus efeitos de longo prazo
- Quando as redes sociais foram adotadas, também não entendíamos bem suas implicações de longo prazo, e depois surgiram vários problemas, incluindo déficits generalizados de atenção
- Desta vez, o que está em jogo é ainda mais perigoso
- Jeremy Howard, criador da fast.ai, diz que quem aposta tudo em agentes de IA está garantindo a própria inutilidade
- Se todo o pensamento for terceirizado para o computador, o processo de desenvolver capacidade, aprender e se tornar mais competente também para
1 comentários
Comentários do Hacker News
Depois de trabalhar nos últimos anos com codificação agêntica, aprendi mais sobre as linguagens, sistemas e ferramentas que uso do que em 35 anos programando manualmente
Minha capacidade de decidir sistemas, técnicas e abordagens ainda é muito melhor do que a da ferramenta, mas essas ferramentas parecem estagiários extremamente bem informados, que sabem muitos detalhes diversos. Têm pouca experiência e cometem erros com entusiasmo, mas pelo menos no começo aceitam feedback e agem em cima dele. Só que, como não entendem nem internalizam de verdade, esquecem com frequência
A ideia de que você precisa saber tudo sobre tudo em que trabalha é muito ingênua. Se você trabalha em mais de uma ou duas equipes, haverá muitas partes que você não entende por completo, e, em uma base de código antiga, quase tudo pode parecer desconhecido. Em um monorepo gigantesco acumulado ao longo de décadas, você já tem sorte se entender direito até a parte em que todos consideram você o especialista
Quem faz esse tipo de afirmação geralmente parece ser muito júnior, ou trabalhar quase sozinho, ou estar há 20 anos no mesmo projeto. Ninguém que trabalhe em equipe ou em uma organização grande pode dizer que conhece a base de código inteira, e o mesmo vale para quem programa de forma agêntica. Ainda assim, você pode perguntar ao agente e obter respostas, e, como alguém que passou a vida lendo código dos outros, também consigo ler código escrito por LLM. Não me importo nem um pouco se um código ruim foi escrito por máquina ou por humano, e pelo menos a máquina aceita meu feedback e age em cima dele
Já vi muitas equipes de software travarem por não conseguir resolver nem problemas pequenos no momento em que era necessário algum conhecimento extra, como linguagens de baixo nível, assembly, algoritmos menos comuns ou protocolos de rede
Por outro lado, às vezes você trava não por falta de capacidade de interpretar o que vê, mas porque está usando algo caixa-preta, como bibliotecas proprietárias ou sistemas operacionais proprietários, e não pode investigar por dentro nem verificar como aquilo realmente funciona
Por isso, acho que sempre deveria ser possível ter um ambiente em que você consiga descobrir tudo sobre tudo em que trabalha, mesmo que isso só seja necessário muito raramente
O importante é não ter medo de aprender o resto do sistema e manter um índice
Acima de tudo, é preciso conseguir entender qualquer coisa rapidamente. É isso que permite atuar de forma ampla. Quando necessário, você aprofunda; quando necessário, faz uma leitura em nível mais alto, ajustando o nível adequado ao problema
Há muito tempo, na universidade, ensinavam engenharia em geral aos alunos de ciência da computação. Quando perguntei: “Quando vou precisar saber engenharia química ou sistemas de controle analógico?”, responderam: “Provavelmente nunca vai usar isso. Mas você deve conseguir entender rápido o suficiente para programar e depois esquecer. Estamos dando uma base sólida”
Isso se aplica da mesma forma dentro de uma base de código grande
Ferramentas como git-ai [0] capturam a sessão do LLM, associam cada edição de arquivo a ações específicas do agente e permitem que o agente consulte, para um trecho específico de código, a conversa ao redor dele — isto é, o que o usuário pediu no prompt, qual foi o raciocínio do LLM que gerou aquele código etc. Isso pode mudar o equilíbrio, mas ainda não é amplamente usado
[0] https://usegitai.com/
Como desenvolvedor sênior com mais de 25 anos de experiência, recentemente fui jogado numa reunião no estilo “pode entrar por 5 minutos?”, e eu realmente odeio esse tipo de reunião em que você é puxado no meio sem contexto algum
As perguntas vieram rápido, sem introdução nenhuma, e eram sobre uma integração externa entre dezenas de outras. Para piorar, esse lado usava uma terminologia própria diferente da nossa
Como dependi bastante do modelo para criar essas integrações, tive muita dificuldade para entender as perguntas. Era um trabalho extremamente tedioso, e havia uma especificação externa enorme fornecida
Ainda vejo como algo positivo o fato de que, sem usar o modelo, provavelmente essas integrações nem teriam sido concluídas, mesmo com 10 vezes mais tempo. Mas agora estou pensando seriamente em voltar e documentar de novo os pontos de “ahá”, para que momentos desconfortáveis como esse não se repitam
Nunca me senti tão ignorante e envergonhado numa reunião, e tudo o que eu podia dizer era “vou verificar isso e responder”, “isso também”, “aquilo também”
Dívida cognitiva é muito real e, pessoalmente, dói mais do que dívida técnica. Dívida técnica é compartilhada pela equipe, mas dívida cognitiva é pessoal — e, se fui eu quem a criou, eu deveria conhecer melhor
Daqui para frente, vou considerar que o trabalho não acabou se eu não fizer uma lista em Markdown, tipo flashcards de 5 minutos, com termos como “o que é isso” e “o que é aquilo”
Como desenvolvedor sênior, você é a pessoa que deve pisar no freio diante de comportamentos de que não gosta. Você tem autoridade. Pode dizer: “Pergunta interessante. Para dar minha visão, preciso de mais contexto. Você pode me explicar rapidamente a arquitetura do sistema ou qual problema concreto estão tentando resolver com essa abordagem?”
Numa situação dessas, “para responder isso adequadamente, preciso revisar a documentação e o código” é uma resposta totalmente aceitável e bem diplomática
Não são reuniões agradáveis quando a especialização não é vista como algo a ser construído, mas só como um meio de confirmar um viés de confirmação criativo
Para encontrar problemas em código gerado, o desenvolvedor precisa se importar. Muitos desenvolvedores, especialmente em grandes empresas, já estão bem desligados do trabalho e só procuram a forma de fechar tickets e passar a responsabilidade adiante com o mínimo de esforço possível
Mesmo que tenham capacidade, esses desenvolvedores não vão se esforçar para entender código gerado a ponto de encontrar problemas que o agente deixou passar. Especialmente no atual frenesi de velocidade guiado por IA, isso é ainda mais verdade
O código gerado parece linguisticamente plausível, mas muitas vezes imita expressões idiomáticas comuns de forma incoerente sem perceber, então bugs reais podem acabar escondidos por acaso de maneiras que um humano normal — até um programador ruim — dificilmente produziria
Como o LLM não tem avaliação interna, o revisor precisa levar isso em conta, avaliar linha por linha e reconstruir do zero as justificativas ocultas e o conhecimento implícito que o LLM nunca teve. Aí você acaba sendo puxado para não-problemas e gastando um tempo caro
Neste ponto, em muitos casos o investimento acaba sendo maior do que escrever do zero
Talvez agora as empresas estejam comprando IA junk, e na próxima etapa estejam recebendo a promessa da “solução”. O capitalismo está funcionando exatamente como se esperaria
Acho que o texto erra um pouco o alvo
Usar muita IA realmente leva a perda de habilidade
Mas quero reconhecer o elefante constrangedor na sala. A IA está deixando as pessoas rápidas demais. Não no sentido de que produzir rápido seja ruim em si, mas no sentido de que a produção e o código estão ficando à frente do entendimento completo e da experiência que os geraram. Está se recompensando mais quem consegue falar em valor de negócio do que quem constrói tomando decisões seguras com conhecimento profundo
IA pode ser boa e pode produzir boas soluções, mas, no fim, não sabe o que está fazendo e, no melhor dos casos, precisa de um coordenador forte
Estamos no lamaçal do desenvolvimento guiado por negócio, e más decisões não estão sofrendo punição reputacional suficiente
Em outras palavras, não tenho certeza de que perda de habilidade seja um problema tão grande assim. Talvez seja apenas um sinal de que a natureza do nosso trabalho está mudando. Talvez estejamos entrando numa era em que conhecer boa arquitetura será mais valorizado do que decorar o padrão de C++ e usar corretamente centenas de recursos
No desenvolvimento normal, costuma haver mais vai e volta entre “queremos mesmo construir isso?” e “o que pode dar errado se fizermos assim?”, idealmente antes da aprovação do PR ou do merge/deploy. Parte disso está migrando para “vamos ver quem reclama depois”. Como diz o ditado, mais vale uma onça de prevenção do que uma libra de cura
Além disso, o código não seguia o C++ idiomático daquele projeto, e o LLM ignorou completamente APIs já existentes. Dá para corrigir e os maintainers deveriam ter percebido, mas a quantidade de código gerado faz todo mundo gastar energia demais
Esses posts de blog sem dúvida devem ter sido escritos com ajuda de IA, e esse tema já aparece em comentários aqui e pela internet há anos. Atrofia de habilidade é uma preocupação séria, e todo mundo cético em relação à IA vem repetindo isso desde 2022, mas algumas pessoas e alguns lugares simplesmente parecem não se importar
A partir de certo ponto, se você está só puxando a alavanca da máquina de lixo sem ter nenhuma percepção sobre o código, pode ser legítimo seu chefe perguntar por que deveria pagar mais de 50 mil dólares por ano
Usar IA para ir mais rápido é otimizar a coisa errada. Em todo lugar onde trabalhei, “escrever código” em si foi a parte que menos consumiu tempo em comparação com todo o resto necessário para entregar uma funcionalidade
Pegue uma funcionalidade que daria para programar em um dia. Primeiro, é preciso planejar tudo dentro do ritual de planejamento que a empresa usa, seja Agile ou Waterfall, quebrar o trabalho, criar tickets no JIRA e decidir quem vai fazer. Só isso pode levar dias ou semanas. Depois, é preciso escrever um documento de design com a proposta e obter revisão de colegas e do time; se for algo substancial, vai mais uma semana. Se várias equipes estiverem envolvidas, some mais uma semana para conseguir concordância e alinhamento de design. Em alguns lugares, você ainda precisa de aprovação para começar o trabalho, o que pode levar mais alguns dias dependendo da agenda e da disponibilidade de quem aprova
Aí você passa um dia escrevendo o código e fazendo os testes passarem
Depois vem code review, várias idas e vindas com o time, múltiplas rodadas e revisões adicionais. Mais alguns dias ou semanas. Se for uma empresa maior, ainda precisa passar por todo tipo de revisão de outras áreas, como jurídico, privacidade, performance, acessibilidade e QA. Mesmo em paralelo, vamos somar conservadoramente mais 2 semanas. Por fim, você sobe para staging e precisa deixar maturar um pouco entre os dogfooders internos para ganhar confiança no funcionamento. Mais 1 semana. Agora está pronto para ir de staging para produção, mas nenhuma empresa séria manda nada direto para 100% da produção. É preciso aumentar o percentual aos poucos, acompanhar feedback e métricas caso seja necessário rollback. O rollout completo pode levar mais 2 semanas
Então, numa funcionalidade que leva uns dois meses do design ao lançamento, estamos fazendo um escândalo para reduzir de um dia para 5 minutos justamente a parte que levava um dia
Ao construir software, você deve se lembrar de que ele é um instantâneo do entendimento do problema. Ele comunica a todos, inclusive ao seu eu futuro, sua abordagem, sua clareza e o quanto a solução proposta se ajusta ao problema em questão. Então escolha com sabedoria o que quer dizer
A observação de que, numa funcionalidade que leva dois meses do design ao lançamento, estamos tentando reduzir de um dia para 5 minutos foi muito certeira
Esse tipo de trabalho era uma parte nada pequena do dia a dia de todo engenheiro em empresas estáveis. Seja lá se você chama isso de “engenharia de plataforma” ou qualquer outro nome, essa área morreu
Além disso, ideias tecnicamente arriscadas que antes não valiam a tentativa por causa da relação entre risco, esforço e retorno agora estão ao alcance. Não é só “ir mais rápido”; a velocidade com que você consegue testar algo muda a própria natureza do processo de engenharia
Se engenheiros de software ficarem baratos o suficiente, muita da necessidade desses processos desaparece. Empresas que já têm esses processos podem ficar em apuros porque é extremamente difícil quebrar esse tipo de burocracia, mas empresas que nunca tiveram isso ou conseguem remover esses processos ganham uma vantagem competitiva considerável
Isso não é novidade. Startups sempre competiram com empresas estabelecidas na velocidade de execução. A novidade é a capacidade de manter essa velocidade por mais tempo
Revisões de jurídico, privacidade, performance, acessibilidade e QA também estão na mira. Se uma empresa puder transferir a responsabilidade legal dessas revisões para um fornecedor externo, ela vai fazer isso
[0] Vamos ignorar por enquanto a ironia de que boa parte desse processo acaba sendo empurrada justamente para os funcionários cujo tempo ele deveria economizar
Big Tech tem muito desse processo pomposo, mas empresas menores conseguem se mover rápido e de forma mais bruta
No fim, a qualidade do código depende de você
Nada impede que você trabalhe iterativamente com o agente e refine até o código atingir exatamente a mesma qualidade que teria se você o tivesse escrito diretamente
Esses textos são bem frustrantes. Dito isso, o custo de tokens mencionado pelo autor é real e arriscado
Eu uso ferramentas de IA para fazer brainstorming de abordagens e, às vezes, gerar código, mas a digitação de fato faço eu mesmo. Assim, com o tempo, há menos chance de eu esquecer os mecanismos e a linguagem de programação
Sinceramente, se tudo virasse só pedir para um LLM escrever código e depois revisar, acho que eu nem teria vontade de ser maintainer de open source. Não parece nem um pouco gratificante
No trabalho pago de fato, fico curioso sobre como mudaria minha forma de usar LLM. Sou desenvolvedor de software porque amo essa tecnologia em si. Gosto do ato de criar, de usar o cérebro para transformar ideias em código. Se o trabalho passasse a ser só dar prompt para LLM, não sei se eu continuaria. No mínimo começaria a procurar outra carreira
Eu uso isso em código que preciso manter. Mesmo assim, às vezes ainda caio, porque o modelo mistura muita informação errada. Em geral, são coisas que já foram verdade no passado, mas hoje estão erradas
Para scripts descartáveis ou fáceis de validar, eu deixo gerar, mas peço para evitar overengineering ou a tentativa de cobrir todos os edge cases. Em scripts, muitas vezes é melhor deixar falhar e mostrar claramente em que etapa falhou, porque isso é mais fácil de entender
Evito linguagens que considero difíceis de ler, como PowerShell, e prefiro gerar coisas curtas o bastante para caber na tela inteira, de modo que eu possa ler e entender tudo. Python, Bash e Batch são as linguagens de script que mais uso
Eu ainda rejeito mais de 50% das sugestões da IA. Porque são genéricas demais, porque movem código sem motivo, ou porque às vezes estão simplesmente erradas
A parte engraçada é que essa tecnologia parece ser uma de duas coisas
Ou é uma tecnologia para gerentes, em que você pode delegar sem ter expertise, mas não consegue saber se está errado ou se é inviável, ou é uma tecnologia para programadores, que têm expertise, mas vão perdendo essa expertise aos poucos
Então não sei bem para quem isso serve, além dos VCs e acionistas até o próximo trimestre
Um pouco fora do assunto, mas acho engraçado o texto dizer que Spec Driven Development é o futuro
Tecnicamente, nós já fazíamos isso na época em que usávamos Waterfall. Às vezes até sinto falta de quando havia boa documentação. Nos últimos 10 anos, talvez mais, muitas vezes recebi tickets de uma linha no JIRA, que quase não especificavam nada, e eu acabava precisando ligar para as pessoas
Eu ainda estou evitando trabalhar com IA. Quero testar alguns modelos locais por curiosidade, mas me recuso a pagar por algo montado em cima do trabalho dos outros. E, até agora, modelos locais ficaram abaixo das expectativas