Porque o organograma de tecnologia nunca mais será o mesmo

O organograma de tecnologia passa por um momento de transição para  um mapa de arquétipos.

Entender este movimento deixou de ser assunto de RH – virou critério para montar time, escolher parceiro e prever se um projeto de IA vai sobreviver ao segundo ano

Em 2026, 15% das organizações já operam com times pequenos de engenharia de software em escala. A Gartner projeta que serão 60% até 2029. Num horizonte mais distante, a mesma consultoria prevê que, até 2030, as plataformas de desenvolvimento nativas de IA terão levado 80% das organizações a transformar grandes equipes de engenharia em times menores e mais ágeis, ampliados por IA.

A Gartner chama esses grupos de tiny teams. Na prática, são de quatro a cinco pessoas. Alguns operam com dois ou três.

A mudança não é de orçamento. Aliyah Camacho, analista principal da consultoria, é direta: “times minúsculos não são uma tática de otimização de custo. É uma reestruturação dos times para aproveitar melhor as forças humanas e as da IA.”

Números como esses costumam ser lidos como uma questão de ferramenta. Qual plataforma adotar, quanto orçar e quando começar. Mas eles descrevem outra coisa: quando quase metade do software de uma empresa nasce de uma colaboração entre pessoas e máquinas, o que muda não é o estoque de tecnologia, é a definição do que significa ser um profissional de tecnologia. E, por consequência, a forma como se monta, se contrata e se avalia um time.

A pergunta que interessa a quem decide, portanto, não é qual IA vamos usar. É outra, e bem mais incômoda: quem, dentro da empresa, consegue transformar essa tecnologia em produto? Que tipo de gente faz isso funcionar? E como se reconhece essa pessoa antes de contratá-la?

Uma das respostas mais úteis que apareceram até agora não veio de um relatório de consultoria. Veio de um post de rede social publicado em junho de 2026.

Cinco arquétipos, nenhum cargo

Em 28 de junho de 2026, Boris Cherny, criador do Claude Code, a ferramenta de desenvolvimento assistido por IA da Anthropic, publicou uma observação que passou de três milhões de visualizações. Ele não estava lançando produto nem defendendo tese de mercado. Estava descrevendo o que enxergava ao olhar para o próprio time. (Acesse aqui).

“À medida que engenharia, produto, design e ciência de dados se fundem em um novo tipo de papel, eu estava refletindo sobre como as funções vão se parecer no futuro.”

E então listou cinco arquétipos:

• Prototipador. Gera ideias novas em volume. A maioria não chega à produção, e tudo bem. O produto do trabalho dele é o aprendizado, não o entregável.
  
• Construtor. Transforma protótipo em produto real. É quem responde pela pergunta “isso aguenta o mundo lá fora?”.
  
• Simplificador / Varredor. Enxuga o que ficou complexo demais, otimiza o que ficou lento e, principalmente, desliga o que não deveria mais existir. É o único dos cinco que cria valor removendo coisas.
  
• Cultivador. Pega o que já foi construído e itera para melhorar o encaixe com o mercado.
  
• Mantenedor. Cuida do sistema maduro. Segurança, confiabilidade, desempenho e custo em escala.

A lista, sozinha, já seria um instrumento razoável de leitura de equipe. Mas o que Cherny escreveu logo depois é o que a torna consequente para quem decide.

A virada: o crachá deixou de prever o comportamento

Cherny fez duas observações adicionais. A primeira: “muitas pessoas cobrem dois papéis, às vezes três.” Os arquétipos não são caixas onde cada pessoa se encaixa uma única vez, são tendências que se combinam.

A segunda é mais desconcertante: “esses papéis não estão realmente atrelados à função. Alguns designers se encaixam na categoria 1, alguns na 2, alguns na 3. O mesmo vale para engenheiros, gerentes de produto e cientistas de dados.”

Isso desmonta uma premissa silenciosa que sustenta organogramas há décadas, a de que o cargo prediz o comportamento. O designer desenha, o engenheiro constrói, o gerente de produto prioriza. E que, sabendo o crachá, você sabe o que esperar da pessoa.

Não sabe mais. Existem designers cujo instinto é prototipar dez ideias antes do almoço. Existem engenheiros que são, no fundo, cultivadores, só ficam realmente engajados refinando algo que já existe e funciona. O crachá não conta essa história. O arquétipo conta.

Para quem contrata, monta squads ou avalia parceiros, a implicação é direta: a composição de um time deixa de ser uma conta de senioridade e especialidade e passa a ser uma conta de arquétipos. O próprio Cherny sugere proporções conforme o estágio do produto. Um produto novo, que ainda busca seu encaixe de mercado, precisa de força nos arquétipos 1, 2 e 3. Um produto em crescimento pede 2, 3 e 4. Um produto maduro pede 3, 4 e 5.

Um time inteiro de Construtores excelentes vai executar com maestria a ideia errada. Um time só de Prototipadores vai acumular demonstrações encantadoras que ninguém consegue colocar em produção. Na prática, o erro de composição sai mais caro que o erro de contratação individual, e é muito menos visível.

Em uma equipe de trinta pessoas, um arquétipo ausente passa despercebido por meses. Em um time de cinco, não existe folga. Cada arquétipo que falta é um buraco que aparece na primeira entrega.

O novo nome: AI Product Builder

Em paralelo a essa discussão, o mercado começou a nomear um profissional específico, o AI Product Builder. É um rótulo que corre o risco de inflar rápido, como tantos outros. Vale, então, defini-lo pelo que ele faz, não pelas ferramentas que domina.

O AI Product Builder é quem leva um problema de negócio do enunciado até a solução funcionando, orquestrando pessoas e sistemas de IA no caminho. Ele não se define por saber escrever bons comandos para um modelo ou por dominar determinada plataforma. Essas competências envelhecem em meses. Define-se por quatro habilidades que, segundo o Gartner, ganham valor à medida que a IA avança, em vez de perder.

A IA gera resultados plausíveis que estão errados. Não obviamente errados, plausivelmente errados, que é bem pior. Olhar para uma saída convincente e desconfiar dela na hora certa virou uma competência escassa e cara. Essa é a habilidade de julgamento.

Os sistemas de IA são tão bons quanto o contexto que recebem. Alguém precisa estruturar o conhecimento da empresa, as regras, as restrições, as decisões passadas, o que já foi tentado e falhou, de modo que a máquina consiga usar. A habilidade de definir o contexto é essencial. Esse trabalho se parece mais com curadoria e arquitetura de informação do que com programação.

A recomendação do Gartner é direta: parta do princípio de que o resultado gerado por IA não é correto nem seguro até prova em contrário, isso é ceticismo disciplinado. E há um detalhe revelador nessa recomendação. Essa postura mental pesa mais na qualidade final do que a escolha do modelo de IA.

Gerar dez versões de uma solução custa quase nada, o gargalo deixa de ser a produção e passa a ser a escolha. Por isso é tão importante o entendimento do  negócio. Saber qual problema merece ser resolvido, e por quê, se torna a habilidade mais valiosa da cadeia.

Nenhuma dessas quatro é uma habilidade técnica de nicho. Todas são habilidades de julgamento. É exatamente esse o ponto. O profissional que essa transição valoriza não é o mais especializado, é o mais capaz de decidir bem com informação incompleta.

O contraponto: as duas dívidas que ninguém vê chegando

Vale interromper o otimismo aqui, porque a parte mais consequente dessa transição é também a menos comentada. O Gartner descreve dois passivos que se acumulam em silêncio nas organizações que aceleram sem contrapeso.

O primeiro é a dívida de compreensão. O volume de sistemas gerados por IA, cresce mais rápido do que a capacidade humana de entendê-los, e ninguém na empresa sabe explicar inteiramente por que aquilo funciona. O sintoma aparece tarde e dói. A correção de problemas fica lenta, a manutenção vira engenharia reversa, e cada mudança nova carrega o risco de quebrar algo que não deveria. É o equivalente organizacional a construir um prédio cuja planta ninguém guardou.

O segundo é a dívida de experiência. Profissionais em início de carreira que apenas revisam saídas de IA não passam pela experiência formativa que os torna sêniores confiáveis. E profissionais sêniores que só supervisionam perdem o envolvimento criativo que os mantém na empresa. A conta chega em três a cinco anos, na forma de uma liderança técnica que simplesmente não se formou.

As duas dívidas têm a mesma origem, velocidade sem contrapeso. E é justamente por isso que a resposta à pergunta “que tipo de gente faz isso funcionar” não pode ser, simplesmente, “gente rápida”.

Leia também: Dívida técnica de gente – o que é e como evitar

O centro de gravidade está em dois arquétipos

Voltando ao mapa de Cherny com essa preocupação em mente, dois arquétipos se destacam para o AI Product Builder. Não como exclusividade, mas como centro de gravidade.

A mente do Prototipador é o que torna a velocidade possível. É a disposição de tratar uma ideia como descartável, testar cinco caminhos em uma tarde e matar quatro sem apego. Numa era em que a métrica de sucesso migra de volume de entrega para velocidade de experimentação, ou seja, a rapidez com que um time gera, testa e refina ideias, esse instinto deixa de ser traço de personalidade e vira competência econômica. Foi o que permitiu à PepsiCo comprimir um ciclo de desenvolvimento de produto de seis a nove meses para seis semanas.

A mente do Construtor é o que impede que essa velocidade vire passivo. É a virada de chave entre “isso funciona na minha demonstração” e “isso aguenta usuário real, custo real, falha real e auditoria real”. É o arquétipo que responde pelas duas dívidas antes que elas se acumulem.

Nenhum dos dois entrega sozinho. O Prototipador solitário produz encantamento sem consequência. O Construtor solitário produz robustez para perguntas que já não importam mais.

O profissional, e o parceiro, que vale a pena ter é quem sustenta a tensão entre os dois. Quem sabe em qual modo está a cada momento e tem a honestidade de trocar de modo na hora certa. Essa é uma habilidade rara. E porque é uma habilidade de julgamento, e não de ferramenta, ela não é ameaçada pela próxima geração de modelos. É precisamente o que a próxima geração de modelos torna mais valiosa.

Contudo, isso não anula os outros três arquétipos. Um produto maduro precisa desesperadamente de Simplificadores, Cultivadores e Mantenedores, e um time que só sabe ir de zero a um nunca chega a dez. Mas para a fase em que a maioria das empresas está agora, descobrindo o que a IA permite que elas façam de novo, o eixo é Prototipador e Construtor.

Três perguntas para o seu time

O valor prático deste mapa não está em rotular pessoas. Está em três perguntas que podem ser feitas sobre qualquer equipe, interna ou contratada:

1. Quais arquétipos esse time realmente tem? Não pelo cargo descrito no contrato, mas pelo comportamento observável nos últimos seis meses.
2. Esse mix corresponde ao estágio atual do produto, ou é herança de um estágio que já passou?
3. Quem, nesse time, é a contraparte do Prototipador? Se não houver uma resposta clara e com nome, a dívida já está sendo contraída.
   
   

Na Framework, temos observado que é essa conversa, e não a escolha de plataforma, de modelo ou de arquitetura, que decide o resultado de um projeto de IA. Tecnologia se contrata, composição se projeta. Os projetos que entregam não são os que começaram com a ferramenta mais avançada. São os que tinham, desde o primeiro dia, alguém encarregado de ir rápido e alguém encarregado de garantir que o rápido durasse. Com frequência, essas duas pessoas eram a mesma.

Cherny encerrou seu post com uma pergunta, e não com uma afirmação: “Talvez os papéis de produto do futuro se pareçam mais com isso, e menos com os papéis específicos de domínio de hoje?”

Se ele estiver certo, a pergunta que as empresas vão fazer umas às outras daqui a alguns anos deixa de ser quantos engenheiros vocês têm. Passa a ser: qual é o seu mapa?

Fontes

• Boris Cherny (@bcherny), publicação no X, 28 de junho de 2026. (Acesse aqui).
• Gartner. “Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029”, 7 de julho de 2026. Disponível em: gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029
• Gartner. “Gartner Identifies the Top Strategic Technology Trends for 2026”, 20 de outubro de 2025. Disponível em: gartner.com/en/newsroom/press-releases/2025-10-20-gartner-identifies-the-top-strategic-technology-trends-for-2026
• Gartner (acesso restrito). Emerging Tech: AI-Native Software Engineering Disrupts and Transforms Product Development; Emerging Developer Skills for Agentic Coding; Guard Against the Risks of AI Dependence in Software Engineering; How to Ensure Quality in AI-Generated Code; Creativity, Not Productivity, Drives Software Engineering Excellence.