A IA exige mais, não menos, disciplina de engenharia
(charitydotwtf.substack.com)- A melhoria na qualidade da geração de código por IA não é um sinal para abandonar code review, e sim para exigir com ainda mais força validação e disciplina operacional em um ambiente no qual o código é regenerado de forma barata e rápida
- Após o Opus 4.5, no fim de 2025, a IA passou a conseguir produzir código, ao menos em padrões comuns, com qualidade próxima à de um engenheiro de software de nível intermediário, de forma mais rápida e barata, e agentic harness, uso de ferramentas, function calling e MCP sustentam essa transição
- À medida que o custo de produzir código se aproxima de zero, linhas de código deixam de ser um ativo valioso a ser preservado e passam a se parecer mais com um cache regenerável que materializa o entendimento atual
- Assim como a immutable infrastructure levou à substituição de servidores em vez de consertá-los em execução, o código de aplicação na era da IA também passa a dar mais importância à validação de comportamento, characterization test, capture/replay, divisão de tráfego e observabilidade do que à mudança em si
- Sistemas não determinísticos exigem disciplina de engenharia como traces, evals em produção e loops rápidos de feedback, em vez de depender de humanos como barreira de qualidade, e a IA não elimina o fato de que software continua precisando de tecnólogos e disciplina
A economia da produção de código virou de cabeça para baixo em 2025
- Durante a maior parte de 2025, a avaliação razoável e dominante era que código gerado por IA era “slop” e provavelmente continuaria sendo
- Após o Opus 4.5, em novembro de 2025, a IA passou a conseguir gerar, ao menos em padrões comuns, código com qualidade semelhante à de um engenheiro de software de nível intermediário, de forma muito mais rápida e barata
- O Opus 4.5 é menos uma causa única e mais um ponto de inflexão
- agentic harness é uma estrutura de código que coloca um LLM em loop com ferramentas
- esses harnesses se tornaram algo viável em meados de 2025, com sinais prévios que remontam ao fim de 2024
- tool use, function calling e MCP foram se acumulando ao longo de 2025 e levaram a uma usabilidade geral no fim do ano
- Na primeira mudança, o ceticismo de “só acredito vendo” podia ser tolerado, mas, quando uma transformação no mesmo ritmo aparece de novo, fica difícil manter a mesma postura
O código deixa de ser um ativo raro e vira um resultado regenerável
- A mudança central de 2025 foi a inversão da economia da produção de código
- gerar código deixou de ser algo difícil, demorado e caro, para se tornar algo praticamente instantâneo e barato
- linhas de código passaram de algo para reutilizar e cuidar para algo descartável e reconstruível
- Também existe a visão de que o verdadeiro resultado de times de engenharia de software é o entendimento compartilhado
- esse entendimento fica armazenado como um cache na cabeça das pessoas e é gravado em disco como commits no GitHub e deploys em produção
- mas a memória humana é falha, se entorpece com repetição e tende a perder pequenos detalhes
- o modelo mental continua se desalinhando do mundo que os usuários realmente encontram
- Do ponto de vista de SRE, o verdadeiro resultado de um bom time de software está em produção
- “Only prod is prod”
- produção não deve ser tratada como um lugar posterior ao desenvolvimento, mas como uma etapa do próprio desenvolvimento
A semelhança entre Phoenix Architecture e immutable infrastructure
- A Honeycomb publicou um AI mandate em agosto de 2025 e entendeu que, como empresa de devtools, precisava enfrentar os problemas difíceis da tecnologia mais recente
- Phoenix Architectures, de Chad Fowler, conecta a era do código por IA à immutable infrastructure
- Chad Fowler é a pessoa que cunhou o termo “immutable infrastructure” em 2013
- Relocating Rigor é um texto citado por Martin Fowler em um resumo de meetup da Thoughtworks
- O ponto central de The Death and Rebirth of Programming é o princípio de não consertar algo em execução, e sim substituí-lo
- immutable infrastructure, serviços stateless, containers, blue-green deployments e infrastructure as code compartilham todos a mesma premissa
- a IA estende essa premissa da infraestrutura para o código de aplicação
- quando o custo de reescrita cai, modificar no lugar se torna arriscado, mutação acumula entropia e substituição reinicia isso
- The Deletion Test propõe imaginar a remoção de toda a implementação
- o medo de apagar vem menos do código em si e mais do fato de não se conhecer o comportamento necessário, as falhas inaceitáveis, os invariantes que sempre devem ser mantidos e os critérios para julgar a correção de uma nova versão
- não saber qual bug corrigia um edge case esquecido é o mesmo tipo de problema
- isso não é um problema de código, e sim um problema de avaliação
- Quando o código é o único lugar onde o conhecimento vive, ele se torna valioso
- no passado, como o trabalho de produzir código era o gargalo, fazia sentido tratá-lo como um ativo durável
- quando regenerar fica fácil, o código passa a funcionar como uma visão materializada do entendimento: útil no presente, mas descartável quando envelhece
O código precisa poder ser regenerado como um servidor
- A transição de servidores artesanais tratados como pets para cattle em immutable infrastructure deixou a lição de que mutabilidade é inimiga do entendimento
- quando se conserta um artefato em execução no próprio lugar, surge drift
- drift torna a manutenção do sistema mais difícil
- Na Honeycomb, um cron roda toda terça-feira para matar o nó de Kafka mais antigo
- isso dá confiança de que os processos de bootstrap e balanceamento são repetíveis
- os dados são regeneráveis, e as promessas importantes vivem em outro lugar
- Se não for possível regenerar código da mesma forma, isso é sinal de que ele não foi entendido o suficiente
- não se sabe quais promessas foram feitas
- não se sabe quais dependências vão quebrar
- a maior parte disso só é descoberta tentando quebrar
- Migrations longas e dolorosas, rewrites, substituição de legacy code e strangler fig são exemplos de casos em que linhas de código acabaram carregando responsabilidade demais
- o código acabava empacotando junto intenção de desenvolvedores, expectativa de usuários, comportamentos implícitos e explícitos e vestígios de bugs antigos
O que precisa ser revisado não são apenas linhas de código
- Como o custo de manter e mudar linhas de código era alto, outros artefatos não conseguiram evoluir o suficiente
- faltam artefatos para entender e discutir como a arquitetura muda
- muitas vezes, a própria arquitetura só pode ser vagamente inferida a partir do código
- A direção ideal se parece mais com discutir e alinhar diagramas de arquitetura e depois regenerar o código a partir dessa mudança
- Não dá para afirmar que todo código passará a ser gerado por IA a partir de especificações, contornando o entendimento humano
- o alcance total dessa possibilidade depende do que é uma spec, ou do que ela pode vir a ser
- quem já passou por migrations dolorosas de banco de dados sabe que é difícil extrair e formalizar expectativas de usuários em uma forma reproduzível e automatizável
- As ferramentas ainda não existem plenamente, mas as ideias relacionadas já existem
- behavioral test, characterization test, capture/replay e traffic splitter, vindos de operações e QA, entram aqui
- essas técnicas se aproximam mais de observar e codificar o que realmente está acontecendo do que de definir o que deveria estar certo
- observability, no melhor sentido, faz parte disso
Humanos não são bons quality gates de validação
- Código não determinístico em produção força a fazer aquilo que já deveria estar sendo feito
- instrumentação de traces
- testes e evals em produção
- tratar produção não como algo posterior ao desenvolvimento, mas como etapa do desenvolvimento
- O cérebro humano não é adequado para validação
- ele é pior que máquinas em verificar repetidamente diferenças pequenas e triviais
- quando o papel humano é reduzido à capacidade de atuar como barreira de qualidade, a qualidade do software se fragiliza
- Humanos ainda podem manter por muito tempo seu papel em criatividade, inspiração e saltos lógicos, mas é difícil colocá-los como quem vence as máquinas em validation
A conclusão da era da IA é o retorno da disciplina
- O motivo de o discurso sobre IA dos últimos dois anos ter soado estranho e assustador para muitos engenheiros é que algumas vozes da IA pareciam dizer que software já não era mais um problema de engenharia
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob é tratado como alguém que prevê grandes mudanças nos empregos de software
- Se 2025 foi o ano do vibe coding, 2026 parece o retorno da disciplina
- com a IA gerando linhas de código no nível de um engenheiro de software intermediário, o leque de futuros possíveis se ampliou de forma instável
- conhecimento que está só na cabeça não pode ser usado pela IA até ser codificado no sistema
- São muito poucos os times de software que trabalham com loops de feedback rápidos e curtos
- a proporção é apresentada como algo em torno de 5%, certamente menos de 10%
- ferramentas de IA podem tornar esse modo de trabalho mais próximo do que antes
- A ideia de que a IA, sozinha e sem disciplina de engenharia, vai gerar enorme retorno sobre investimento no curto prazo não é a principal preocupação
- muitos times vão tentar, mas o que tem valor é sustentado não pela descartabilidade, e sim pela durabilidade
- Usuários não querem que botões e menus no Slack mudem sutilmente todos os dias ao fazer login
- também não querem que transações financeiras sejam concluídas apenas na maioria das vezes
- determinismo não desaparece
- IA não é mágica, e software continua sendo engenharia
- tecnologia precisa de tecnólogos
- os artefatos que precisarão ser revisados no futuro se expandem para além de linhas de código, abrangendo outros tipos de artefatos de engenharia
1 comentários
Comentários do Hacker News
Agora ficou muito mais difícil distinguir entre quem entende o sistema e usa IA de forma eficaz e quem não entende nada e só fica espalhando copia-e-cola de LLM
Antes de 2025, pessoas com baixo desempenho ou que só estavam se arrastando apareciam relativamente fácil porque contribuíam pouco, mas agora todo engenheiro despeja PRs, revisões de código e documentos de design técnico com aparência plausível
Isso também é fortemente influenciado pela pressão da diretoria para usar IA ao máximo, e do ponto de vista de cada engenheiro também é uma resposta de teoria dos jogos produzir o máximo possível
Estamos sendo completamente soterrados por documentos e código que parecem plausíveis, e para lidar com esse volume acabamos dependendo de IA de novo
O efeito colateral deste período provavelmente será uma forma peculiar de dívida técnica, especialmente marcante em escala
LLMs gostam de produzir muito e adicionar coisas, mas engenheiros realmente competentes geram mais resultado de negócio com menos código e menos partes móveis
Ouço com frequência algo como: “quero usar IA para automatizar o processo, mas como a documentação do processo está incompleta, espero que a IA ajude”
Mesmo quando explico que não dá para criar resultado do nada, toda discussão sobre IA acaba voltando para o mesmo lugar
A solução para criar a documentação que entraria nessa automação por IA também vira “vamos usar IA”, então parece um ouroboros em que a IA cria documentos, a IA resume e a IA explica
Com código vai acontecer a mesma coisa: gerar milhares de linhas com IA e depois usar IA para explicar de novo
Hoje, graças aos LLMs, ficou fácil demais parecer trabalhador olhando só para o volume de contribuição
A diferença agora é que uma pessoa incompetente pode literalmente produzir uma saída várias ordens de grandeza maior do que um engenheiro cuidadoso e experiente
PR não é um filtro perfeito, mas é um dos poucos filtros que ainda temos, e é bem claro quem está se esforçando e quem não está
Afinal, as perguntas de algoritmo na entrevista com certeza filtraram completamente quem só finge ter conhecimento de sistemas, não é?
Concordo com a ideia de que “isso não é um problema de código, é um problema de avaliação” e que “código só se torna valioso quando o conhecimento vive apenas dentro dele”
Ler código escrito por IA o dia inteiro é doloroso e é uma forma terrível de derreter o cérebro justamente no momento em que a pessoa mais precisa ser competente
Na programação manual existe um ciclo produtivo e satisfatório de feedback: ler código, escrever, compilar ou executar e corrigir até fazer o que se quer
O código de IA não só substitui metade disso como também torna menos emocionante aquele momento final do “clique”. Porque não dá para ter certeza de que você não trapaceou um pouco em algum ponto para chegar ali
Tratar código gerado por IA como a única saída duradoura da programação é um beco sem saída para a indústria
O que Charity aponta como espaço de trabalho interessante, e o que deve ser descartado corretamente, são diagramas de arquitetura e especificações
Meu palpite é que isso está mais próximo de prompts, planos em Markdown e instruções orientadoras escritos diretamente por humanos
É preciso focar no que foi criado diretamente por pessoas para formar a base do loop central de “a IA seguiu minhas instruções?” e isso também oferece mais alavancagem em revisão de código
Quando se chega ao PR, você provavelmente já deu informação suficiente ao Claude para ele regenerar o código, mas o padrão atual da indústria é jogar fora toda essa sessão e implantar só o código. Isso está invertido
Blocos grandes de código são praticamente impossíveis de revisar por humanos, mas quando entra LLM muita gente parece esquecer isso
Todo dia chega uma pilha enorme de código para revisar, e é realmente exaustivo
Ainda assim, a IA parece melhor, porque se você escreve as regras, pelo menos ela tende a segui-las
Muitos desenvolvedores offshore repetem os mesmos erros todos os dias
Talvez a nossa empresa precise contratar desenvolvedores offshore melhores
Antes, parte do meu modelo mental do sistema era formada ao codificar; agora ele está sendo formado com dependência maior de revisão de código
Está ficando mais difícil entender e lembrar dos detalhes do sistema, o que não é surpreendente se considerar que informações que você próprio “gera” ficam mais gravadas do que informações que você só leu
Estou aplicando às expansões de revisão de código lições tiradas da pedagogia, e se isso fizer sentido para alguém eu gostaria de conversar
Como gambiarra, talvez desse para pedir ao Claude que escrevesse um resumo da sessão como parte da mensagem de commit, mas queria saber se existe alguma ferramenta mais estruturada e de nível mais alto
Se você quer código verificável que siga um plano bem projetado, na prática precisa escrever pseudocódigo e deixar a IA traduzir
Nesse caso, fica a dúvida de por que fazer a IA escrever o código em primeiro lugar
Pessoalmente, acho mais divertido planejar, escrever e depurar por conta própria. Foi exatamente essa parte que me fez gostar de programação para começo de conversa
Tenho pensado muito nisso ultimamente
Boa parte da minha intuição sobre desenvolvimento de software se baseia em 25 anos de experiência acumulada em “quanto tempo leva para escrever determinado código”
Quando penso se devo adicionar validação para um caso de borda que não quebra tudo, mas pode deixar as coisas meio bagunçadas se alguém tropeçar nele, eu talvez pulasse isso se custasse mais algumas horas de código
Mas, se basta um prompt, por que não fazer?
Para tornar um novo recurso mais fácil de entender, seria bom ter um explorador de API dedicado, mas antes isso provavelmente não justificaria o investimento
Só que, se com o Codex isso leva 10 minutos, a história muda, e foi exatamente o que aconteceu: https://tools.simonwillison.net/datasette-extras-explorer#ur... também linkado nas notas de lançamento https://docs.datasette.io/en/latest/changelog.html#extra-sup...
Em uma escala maior, há projetos que antes eu nem considerava. Eu precisava de uma biblioteca personalizada para fazer parsing de consultas
SELECTdo SQLite, mas isso não valia dedicar mais de uma semanaMas agora isso se tornou viável: https://github.com/simonw/sqlite-ast
Quando alguém diz que ser capaz de produzir linhas de código mais rápido tem valor, muita gente fica muito irritada e até desdenha
Claro, medir produção por “número de linhas de código” é uma idiotice
Mas medir número de linhas de código validadas que entregam valor não é idiotice, e agora dá para fazer isso mais rápido
O motivo de o Google ter valor é sugar dados e transformá-los em receita de anúncios, com gastos pequenos em relação à receita
E todas aquelas “apostas”? Engraçado, no que deram?
Engenharia pela engenharia não tem valor nenhum para a economia, ou seja, não significa nada
A verdade dura que ninguém quer ouvir é que, em qualquer momento, só pode existir dentro da economia aquilo que é limitado, valioso e economicamente sustentável, e só isso sobrevive
Muita gente não liga para isso, mas há quem ligue
Gostei deste texto e, como muitos outros comentários aparentemente não gostaram, vou registrar o que penso
Quando começo a trabalhar em uma base de código nova, como faço para me tornar um colaborador útil o mais rápido possível? Vou direto para a documentação escrita por pessoas
Verifico qual problema esse sistema originalmente tentava resolver, qual era o desenho original, quais são os maiores problemas e quem o usa hoje
Saber isso torna muito mais fácil ler o código, porque permite inferir por que ele foi construído daquela maneira
Este post de blog também ganhou popularidade: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Parece que Charity olha para um problema muito antigo e espera que uma nova tecnologia leve a algum tipo de nova solução
Não acho que alguém considere que a geração atual de ferramentas seja o fim da história do desenvolvimento de software com AI
Também não se trata de jogar o documento de design no Claude code e ir embora. Documentos de design também são incompletos, então no onboarding você ainda precisa conversar com pessoas e ler tickets antigos e post-mortems
Em produção, fazemos infraestrutura como código hoje porque não gostamos de não conseguir entender por que a infraestrutura chegou ao estado atual
Uma base de código também tem como estado padrão “é difícil entender por que chegou ao estado atual”, e isso é um problema observado desde antes de “Programming as Theory Building”
Então, de forma parecida com infraestrutura, parece razoável esperar que o desenvolvimento de software também passe a girar em torno de ferramentas que deixem mais claro “por que o código chegou ao estado atual”
Ao entrar em uma base de código nova, faz sentido começar por pessoas e documentação escrita por pessoas, mas muitos times de engenharia simplesmente não têm nada disso
As decisões são tomadas dentro da cabeça de um engenheiro ou em chats que não ficam salvos, e a especificação eram algumas linhas de nota em um ticket que foi apagado durante uma arrumação ou sumiu quando trocaram a ferramenta de rastreamento
Não há mapa da base de código nem das funcionalidades, não há ADRs, e a observabilidade é mínima
Só sobra o código, então você precisa ler o código para descobrir o que está acontecendo e perguntar a algum engenheiro que fez commit recentemente naquela área se ele se lembra por que aquilo foi feito daquele jeito
Quando alguém faz uma mudança, às vezes quebra uma parte completamente diferente do outro lado da base de código que supostamente não tinha nada a ver
É verdade que AI exige mais disciplina, mas, em teoria, essa disciplina é muito mais fácil de aprender do que se tornar um bom engenheiro
Vinte anos atrás, para escrever um bom código C escalável, você precisava ser um gênio ou se dedicar profundamente à tecnologia em si
Era preciso conhecer por completo uma porção de ferramentas como ASan, LSan, UBSan, TSan e GDB, e seria ainda pior se você tivesse de ler arquivos DWARF manualmente
Na prática, era difícil dominar isso em pouco tempo, e ao mesmo tempo ainda era preciso aprender design de sistemas, que é uma competência separada e quase ortogonal
Agora basta conhecer os pontos de risco da linguagem e do framework que você usa, instruir o LLM a testá-los, ter a infraestrutura para verificar se ele testou o suficiente, e então ler os testes e a implementação de fato
Ler e entender Rust é muito mais fácil do que depurar os erros quase mágicos que aparecem ao desenvolver em Rust
Também é mais fácil perceber que um cenário específico precisa de um teste com Loom e criar ferramentas que detectem se ele foi realmente escrito
Mesmo que você continue usando C ou Zig, é muito mais fácil saber quando usar cada ferramenta e detectar isso do que aprender cada uma isoladamente
Ler SQL não é difícil, e quase metade das pessoas de negócios consegue fazer isso. Python é só um pouco mais difícil, e Rust também dá para entender com um guia de leitura de 50 páginas, o que é um custo muito pequeno comparado a passar 10 anos aprendendo por tentativa e erro
O caminho lógico de “LLMs funcionam de maneiras que não podemos conhecer” para “portanto precisamos de mais disciplina” e daí para “então está tudo bem” não me parece claro
Concordo que está tudo bem, mas não acho que essa linha de raciocínio forme um caminho evidente
Na prática, qualquer pessoa disposta a fazer funcionar e a gastar um pouco de tempo entendendo o que faz as coisas falharem consegue realizar coisas enormes usando LLMs
Como LLMs tornam o custo de construir coisas complexas quase gratuito, eles provavelmente vão, na verdade, deixar a situação muito mais complexa
Engenharia sempre foi sobre disciplina e sobre fazer funcionar, mas antes era preciso um conjunto de conhecimentos prévios para ser valioso
A maior parte disso agora desapareceu, e tudo ficou muito mais fácil do que antes
A disciplina continua necessária, mas, comparada a passar 10 anos rolando no fogo, disciplina é barata
Acabei de passar uma semana revisando este PR de cerca de 200 linhas: https://github.com/ncruces/wasm2go/pull/37
Ele foi enviado por um usuário experiente e provavelmente consultou um LLM de ponta
Mesmo assim, parecia haver algo errado. Eu não entendia, e não tinha intenção de fazer merge sem entender
Também suspeitava que estivesse errado de uma forma que causaria problemas no futuro
Então revisei de quatro maneiras: entender e melhorar, fazer com um algoritmo melhor, corrigir o problema upstream para evitá-lo, ou reescrever do zero de um jeito que fizesse sentido para mim
Eu esperava que a resposta fosse a segunda ou a terceira, mas a segunda, embora correta, exigiria refazer o projeto inteiro desde o começo, e a terceira eu realmente queria que funcionasse, mas não funcionou
No fim, acabei misturando a primeira com a quarta, e ainda não tenho certeza absoluta, mas agora entendo o problema e a solução
É natural que eu ache que minha abordagem é melhor
Ainda assim, removi os comentários de ambas as versões e pedi para um LLM revisá-las
O LLM respondeu que o PR original era claramente melhor, e quando expliquei por que não era, respondeu que eu estava certo
Quando tento de novo com comentários, os LLMs dizem que a minha versão é melhor. Isso porque eu realmente encontrei o problema
Mas não sei se eles dizem que a minha é melhor porque ela realmente é melhor ou porque eu os induzi a dizer isso
Lendo o texto, parece que ele esqueceu o ditado “todos os modelos estão errados”
Também é um erro comum de quem gosta de RPGs de “simulação” “realistas”
Se você modela algo de forma abrangente o bastante, o modelo simplesmente vira o próprio objeto
Para criar um modelo de localização que inclua todos os detalhes de um lugar real, você precisaria de um modelo em escala 1:1, e isso no fim é só uma cópia do lugar
Um plano suficientemente detalhado — ou seja, um prompt para o modelo — capaz de reproduzir com confiabilidade 100% das funções de um sistema provavelmente seria o próprio código-fonte desse sistema
Muitas vezes me perguntei se boa parte de TI e programação não é só juntar pedaços bem compreendidos
Oito anos atrás, pensei em por que não seria possível substituir o LLVM por um sistema muito mais simples e trocar otimização manual por um “otimizador” simples de IA
Eu achava que bastaria treiná-lo para transformar código compilado simples em código “otimizado”, mas o consenso na época era que sistemas de IA tinham dificuldade para gerar código correto com confiabilidade suficiente para uso prático
Se a IA não consegue substituir nem esse tipo de código de baixo nível, então problemas de alto nível obviamente deveriam estar ainda mais distantes
Mas as pessoas usam IA para problemas de alto nível
Minha hipótese é que grande parte da engenharia digital moderna é plug and play
Lembro que, antes de 2023, no HN todo mundo exaltava reduzir o número de linhas de código como o indicador sênior mais poderoso
Só que a correnteza do volume de linhas de código geradas por LLM é forte demais para vencer nadando contra ela
E também não concordo com a premissa do texto de que LLM consegue escrever bom código
Ele escreve código que funciona, mas parece que foi escrito por um demogorgon, e isso me dá um certo enjoo quando vejo
É ruim, mas ruim de um jeito que um humano jamais escreveria
É um tipo diferente de incômodo de ler código espaguete escrito por um júnior, mais como a repulsa de sentir ovos de Cthulhu chocando em algum lugar no fundo do estômago
Lembro de um sênior numa empresa em que trabalhei que, desde que entrou até virar gerente, basicamente só removia código
Esse texto não foi divertido de ler
As frases em si e cada parágrafo até eram bons, mas no conjunto tudo pareceu disperso e, ouso dizer, sem sentido
Tinha palavras demais, mas parecia dizer muito pouco de fato
Por exemplo, dizer que em 2025 a economia da produção de código foi invertida não é exato
Antes, se o processo de fabricação era estritamente aditivo como impressão 3D, agora está mais para algo complementado por um processo subtrativo como fresagem CNC
A “forma” exigida quase não mudou e, se você se importa com certas tolerâncias, o esforço humano também não mudou
Ainda é preciso valorizar o produto, reutilizá-lo, mantê-lo e curá-lo na medida em que o mercado exige
Também não concordo com a frase “linhas de código não são um artefato ideal para revisão”
O que “ideal” quer dizer aqui?
Quando eu era criança, em toda prova a regra era “mostre o desenvolvimento”
O motivo é que você não está tentando melhorar só o produto que vai sair amanhã, mas também o modelo mental e o processo de pensamento da próxima geração
A linguagem estava realmente difícil de acompanhar e o ponto central do texto também não se destacava
Quando vejo textos assim, fico ainda mais cético em relação à ideia de que empregos de engenheiro de software vão desaparecer
O trabalho de engenheiro de software em 2026 já é diferente do de 2020 e, mais ainda, do de 1990, então por que eu deveria acreditar nessa falsa dicotomia de que o trabalho em 2026 ou vai permanecer igual ou vai desaparecer por completo?
Quando trabalhei no Google, muito tempo atrás, a ideia de revisar todo código era novidade para mim
Antes disso, na MS, o código era gravado em CD e colocado na caixa, então na maior parte das vezes ele não era revisado até o momento de alto risco no fim do projeto
Entre 2000 e 2004, a forma como engenheiros de software gastavam seu tempo mudou drasticamente, e acho que melhorou porque aumentou o entendimento compartilhado e incentivou a colaboração
Se a IA escrever código e os humanos passarem mais tempo revisando, isso pode não ser algo ruim
Mas, se o código da IA ficar bom o suficiente, revisão rigorosa vai passar a ser vista como opcional
Aí o trabalho do engenheiro de software vai ficar muito diferente do que era antes, e talvez ele nem escreva muito código nem passe muito tempo revisando
As IDEs podem desaparecer como o dodô
O foco pode mudar para definir objetivos e testes que mantenham a equipe de codificação com IA no rumo certo
Engenheiros de software que entendem bem para onde o projeto está indo talvez passem mais tempo em arquitetura, porque não vão querer que a IA reescreva várias coisas quando o destino mudar de forma razoável
Também podem passar mais tempo explorando: fazer de um jeito, depois de outro, depois de outro, comparar e gerar novas ideias a partir de abordagens diferentes
Não tenho previsões melhores do que ninguém, mas sou fortemente contra a ideia de que a função vai desaparecer e a favor da ideia de que ela vai evoluir, como já aconteceu várias vezes até aqui. Só talvez nunca tão rápido quanto agora
Não acho correta a frase “tratávamos código como algo permanente porque o trabalho de produzir código era o gargalo”
Tratávamos código como algo permanente porque o víamos como a fonte da verdade
Computadores não executam documentação, executam código
Se um documento de requisitos contradiz o código, o padrão era assumir que o documento de requisitos estava errado
Não dá para separar código de especificação. O código é a especificação