A primeira vez que sentei e usei o Opus 4.5 de Claude Code para construir software, não pude acreditar como ele era bom.
Meu próximo pensamento foi: isso vai mudar a dinâmica dentro das equipes de software.
O impasse entre os papéis
Marc Andreessen descreveu recentemente o momento como um “impasse mexicano”:
Todo engenheiro agora pensa que pode ser PM e designer.
Cada PM pensa que pode codificar e projetar.
Todo designer pensa que pode fazer os outros dois.
O risco é que muitos contribuidores individuais acreditem que já não precisam dos outros.
No curto prazo, isso será extremamente perturbador para a cultura da equipe.
Quando habilidades raras se tornam mais acessíveis, as pessoas se sentem pressionadas a subir na pilha para provar seu valor.
Kent Beck expressou este sentimento em X:
“O valor de 90% das minhas habilidades caiu para US$ 0. A alavancagem dos meus 10% restantes subiu mil.”
Minha preocupação é que todos estejam se recalibrando para os mesmos 10%. Os contribuintes individuais estão todos correndo em direção à mesma camada de alavancagem.
No artigo de Ben Werdmuller, “A codificação de IA funciona agora”, ele dá conselhos especificamente aos engenheiros. Ele comenta: “A codificação de IA muda o centro de gravidade da implementação para o julgamento” e recomenda que os engenheiros se concentrem nestas quatro habilidades:
Elaborando metas para o produto
Compreender o que os usuários realmente desejam
Ser absolutamente claro sobre a experiência e o valor que você está criando
Projetar, construir e manter uma arquitetura de software robusta
O desafio ao conselho de Ben é que muitas pessoas acreditam eles possuir essas habilidades.
A liderança da empresa deseja possuir objetivos e estratégia.
Os Gerentes de Produto se consideram exclusivamente qualificados para entender o que os usuários desejam.
Os designers querem controle sobre a elaboração da experiência do usuário.
E Marketing e Vendas querem definir como o valor é expresso para o cliente.
Os engenheiros possuem o planejamento e a implementação da arquitetura. Desempenho, escalabilidade, segurança; tudo requer experiência real.
Com a IA, todas essas funções se tornam mais fluidas. À medida que mais pessoas criam software e o tempo de ciclo diminui, elas começarão a absorver lições que seus colegas levaram décadas para aprender.
E, em última análise, mais indivíduos desejarão possuir a identidade de maior aproveitamento: “Na minha função, resolvo problemas e forneço valor aos usuários”.
Se não for verificado, haverá disputa por posição. Pode haver mais animosidade (e ciúme) entre os membros da equipe.
O que estou ouvindo das equipes de software
Comecei a perguntar aos meus amigos que dirigem equipes de software o que eles estão vendo.
Um fundador me disse:
Eu acho que você está correto aqui. Já estamos vendo isso – principalmente em torno de PMs que querem escrever código.
Outro disse:
Estamos sentindo isso em nossa equipe com certeza. Todo mundo sente que pode fazer o trabalho de todo mundo.
O presidente de uma empresa de software estabelecida descreveu uma mudança semelhante:
“Nossa equipe é formada por um chefe de produto e 15 engenheiros. Em projetos menores, ele mesmo envia muitos PRs, sem nenhum desenvolvedor envolvido.”
Mas a maior mudança não foi apenas em quem faz o trabalho. Foi em quem eles estão contratando:
“Onde se vê realmente o impacto nos empregos connosco é nas pessoas que já não contratamos: especialistas. Nesta nova era, os generalistas vencem.”
John O’Nolan, fundador do Ghost, comentou:
É um momento turbulento, com certeza – mas no geral estou bastante otimista.
O que ainda não aconteceu e que espero que aconteça no futuro é que, além de velhos papéis serem comprimidos, novos papéis emergem.
Depois do impasse
Minha esperança (quando a poeira baixar) é que saiamos do outro lado com mais colaboração. Em vez de competir pela vantagem, espero que os colaboradores individuais encontrem novas formas de trabalhar em conjunto.
Por exemplo, e se os gerentes e engenheiros de produto fizessem mais programação em pares baseada em IA? O PM poderia se concentrar no comportamento do cliente e nos objetivos do produto. O engenheiro poderia avaliar arquitetura, segurança e capacidade de manutenção. Eles iterariam juntos em tempo real, usando LLMs.
Meu amigo Matt Stauffer, CEO da Tighten, comentou que eles estão fazendo isso agora:
Eu demonstro o trabalho para meu Biz Dev Manager (o proprietário do produto deste projeto interno), ela pede alterações e então solicitamos o LLM ao vivo, juntos. Sou melhor em solicitar e revisar, ela conhece o domínio melhor do que eu. Esse tipo de programação em pares é ótimo, porque estou me movendo rapidamente e ela pode interromper a chamada mais tarde, quando estou revisando, iterando, etc.
A prescrição de Ben Werdmuller ainda seria relevante: “Todo código deve ter um proprietário humano que assumirá a responsabilidade por ele.” No meu cenário, o PM e o engenheiro seriam coproprietários da solicitação pull.
A 37signals é famosa por ter equipes de duas pessoas (um designer, um engenheiro). Num mundo de IA, talvez um paradigma como esse se torne a norma?
Assim que a turbulência passar, as pessoas precisarão de uma nova visão sobre como trabalhar juntas. Como podemos usar IA e colaborar de maneiras que nos ajudem a construir software melhor?
Saúde,
Justin Jackson
Discuta isso no Hacker News
Conecte-se comigo em:
🦋 Céu Azul
💼 LinkedIn
🐘 Mastodonte
🧵 Tópicos
Fonte: theverge
