O generalista e a responsabilidade

Passei boa parte da carreira me sentindo um pato: nada, anda e voa, mas não faz nenhuma das três coisas muito bem. Um pouco de código, um pouco de dados, um pouco de design, bastante de produto. Em um mercado que premiava especialista, isso parecia um defeito.

Deixou de parecer.

O que acontece quando saber fazer fica barato?

Quem deu nome ao que eu vinha sentindo foi Karim Lakhani, que pesquisa como a IA muda o trabalho. A tese que ele repete há anos: o custo marginal da expertise está indo a zero. E emenda uma provocação para as empresas: se uma empresa é, no fundo, um pacote de expertises, o que ela faz quando esse custo despenca?

Eu concordo muito, com um adendo: quando a expertise fica barata, o que passa a pesar é a vontade de fazer. E tem a piada que venho repetindo: antes eu culpava o time por atraso, coisa mal implementada, experiência ruim. Agora descobri que eu é que sou ruim de definir o produto. Dói, mas é verdade.

Não quer dizer que especialistas ficaram inúteis — o capítulo anterior tem um contador salvando a minha pele. Quer dizer que o acesso à execução especializada ficou barato. Eu não tenho mais medo de análise de dados, de código, de design. Não porque virei bom nas três coisas: porque consigo chegar a um resultado decente nas três, rápido, e sei onde chamar alguém.

O que isso valoriza é a pessoa que enxerga o processo inteiro. Quem entende o problema de quem vai usar, sabe o que pedir, percebe quando o resultado não faz sentido e junta as partes. Eu chamei isso de virar uma pessoa “full-service” quando isso ainda era aposta.

Hoje eu tenho uma autonomia que nunca tive. Sempre fui meio lobo solitário; agora consigo ir do problema ao produto funcionando sem esperar ninguém. Isso é poderoso, e tem um preço que merece ser dito em voz alta.

E se a expertise viesse em um formato que eu consigo ler?

Tem um detalhe nessa história que, para mim, é o centro de tudo. Não é só que a execução especializada ficou barata. É que a expertise passou a chegar em linguagem natural — em um formato que eu consigo ler.

Antes, o conhecimento de quem é especialista vinha embrulhado no ofício: o código, o modelo estatístico, o arquivo de design, a cláusula do contrato. Para avaliar, eu precisava dominar o ofício ou confiar de olhos fechados. Hoje, quando peço uma análise, recebo junto o plano, o raciocínio, as alternativas descartadas e a explicação de cada escolha — em português. Eu posso ler, perguntar “por quê?”, pedir o contra-argumento e só então decidir.

É por isso que eu não gosto do termo vibe coding. Ele sugere programar “na vibe”, aceitando o que vier sem olhar. A minha experiência é o oposto.

Eu implico com o termo desde que ele apareceu. No começo o motivo era de identidade: eu não queria ser dev medíocre, queria ser melhor em produto. Depois ficou mais claro que o problema é outro — pensamento crítico. E confesso: várias vezes me pego “vibing”, sem pensar no que estou fazendo. Por isso mesmo eu me vigio.

Então o trabalho ficou mais leve?

A maior mudança no meu dia não foi parar de escrever código. Foi começar a ler o dia inteiro. Cheguei a escrever isso em caixa alta: NUNCA li tanto na minha vida.

O agente mostra o plano: eu leio. Mostra o raciocínio: eu leio. Explica por que escolheu um caminho: eu leio, e às vezes discordo. Entrega o resultado: eu leio antes de aceitar. Meu trabalho virou revisar, decidir e redirecionar.

A pesquisa de Lakhani com profissionais de consultoria dá nome aos jeitos de trabalhar com IA. A maioria age como ciborgue, resolvendo o problema junto com a IA, em vaivém constante; uma parte menor, como centauro, que divide o trabalho (“isto eu faço, aquilo ela faz”) e supervisiona o que volta; e cerca de um quarto, como autoautomatizador, que aperta o play e entrega o que sair. Quem aprende menos é o terceiro grupo — nas palavras dele, porque parou de pensar.

Ele é duro com quem cai nessa. Se tudo o que você faz é servir de interface de carne e osso para o silício, qual é o seu valor? Conta que já demitiu gente que justificou um trabalho ruim com “foi a IA que me deu isso”. E tem uma regra pessoal que vale copiar: nunca aceitar a primeira resposta. Pedir alternativas, mandar o modelo argumentar contra a própria proposta, procurar os sinais de alerta. A primeira resposta é a resposta média; a boa aparece depois que alguém com critério insiste.

Meu pedido de sempre é o mesmo: não seja um proxy de uma IA para outra IA. O trabalho com IA tem dois ciclos, gerar e revisar, e dá para aprender nos dois. Eu entendo muito mais de código hoje por causa de revisão, não de geração.

Quem imagina que usar IA é apertar um botão e ir tomar café está descrevendo o jeito de usar que dá errado. E é essa pessoa, não quem é generalista e presta atenção, que fica fácil de substituir.

Como se ensina isso?

A conversa em que ele defende isso tem a parte que mais me interessa como professor. Em uma das escolas de negócios mais tradicionais do mundo, a disciplina obrigatória de IA mudou de natureza quando o corpo docente percebeu que não dá para só falar de IA — é preciso fazer IA.

O que mudou, na prática:

• Metade do curso virou construção. A turma resolve problemas de negócio construindo ferramentas com IA.
• A prova final acabou. O argumento é simples: como ter um curso de IA em que não se pode usar IA na avaliação? No lugar entraram projetos — a turma inteira teve de entregar soluções funcionando.
• Os casos continuam, com outro papel. A discussão de economia, estratégia e gestão de mudança agora vem depois de a turma ter posto a mão na massa: “consigo fazer tudo isso; e o que isso significa para a minha empresa e para o meu trabalho?”.

Ele resume a mudança pessoal com honestidade: por muitos anos, bastava colocar um caso na frente da turma; agora a sala de aula tem muito “fazer”.

É o convite deste guia, e é o que eu tento praticar: nas minhas turmas de Sistemas de Informação, estudantes entregam produtos de verdade para se formar. Troque o relatório sobre o caso pela solução do caso. Quem constrói descobre onde a ferramenta falha, o que precisa conferir e o que não sabia que não sabia — três coisas que relatório nenhum ensina.

Só mantenho a ressalva sobre o nome. Lakhani chama isso de vibe coding. Eu chamaria de construir lendo.

O que continua sendo humano?

• Saber o que vale a pena fazer. A IA constrói qualquer coisa que você pedir, inclusive a coisa errada.
• Conhecer o contexto. O time que usa aquela tela, a cliente que odeia aquele termo, a regra que ninguém escreveu.
• Julgar o resultado. “Está plausível” e “está certo” são coisas diferentes, e alguém precisa saber a diferença.
• Comunicar. Explicar um problema com clareza para uma pessoa ou para um modelo é a mesma habilidade.
• Responder. Essa não se delega.

De quem é a responsabilidade?

Todo sistema de IA foi desenhado, treinado, configurado e colocado no ar por decisões de pessoas. A responsabilidade moral e prática pelo que ele faz é de quem cria e de quem usa. Nunca do software. Por mais que cresça o tamanho do trabalho que dá para delegar de uma vez, a responsabilidade ainda é sua.

Se você cria — treina um modelo, monta um agente, escreve o prompt que outras pessoas vão usar:

• Cuide de quem está nos dados e de quem ficou de fora (capítulo 4).
• Chame gente diferente de você para tentar quebrar o sistema antes de lançar.
• Escreva onde ele falha. Limite conhecido e documentado é ferramenta; limite escondido é armadilha.
• Proteja os dados: consentimento, mínimo necessário, nada sensível onde não precisa (capítulo 5).

Se você usa — e todo mundo usa:

• Confira quando o que está em jogo é saúde, dinheiro, direito ou segurança de alguém.
• Trate a resposta como estimativa, não como verdade.
• Avise quando encontrar erro ou viés. É assim que melhora.
• Cuide dos seus dados e, principalmente, dos dados dos outros.

Não tem nota de corte. Os itens estão mais ou menos na ordem dos capítulos; o primeiro que você não marcou é um bom lugar para voltar.

O que eu não sei

Um guia honesto precisa de uma seção assim.

Não sei o que acontece com o emprego. Eu vejo, por dentro, times fazendo mais com menos gente, e empresas preferindo investir em ferramenta a contratar. Quem diz que isso não vai afetar ninguém está vendendo alguma coisa. Nem os pesquisadores concordam sobre quem corre mais risco: Lakhani, por exemplo, acha que a questão está longe de resolvida e aposta que o perigo maior está na gerência intermediária, que resiste a mudar — não em quem está começando, que absorve a ferramenta sem medo. Minha estratégia pessoal — meio piada, meio a sério — é tentar estar no último 1% a ser substituído. Isso não é resposta para a sociedade; é só o que está ao meu alcance. A resposta coletiva é assunto para política pública, e por isso eu dou aula onde dou.

Não sei se os preços de hoje se sustentam. Muito do que usamos é subsidiado (capítulo 12). Pode haver uma bolha, e ela pode estourar. Por isso a insistência em não depender de um fornecedor e em guardar o conhecimento em um lugar que é seu.

Não sei quando o agente “faz-tudo” vai ser seguro o bastante. Talvez já seja, e a resistência seja minha. Prefiro errar para esse lado.

O que eu sei: não tem volta. Existem modelos abertos que qualquer um pode baixar e rodar. Se as empresas de hoje sumissem amanhã, a tecnologia continuaria aqui. A escolha que resta não é entre usar e não usar. É entre usar entendendo ou usar acreditando em mágica.