O Framework Honey Badger: Gerir Equipas Híbridas Humano-IA em 2026

Praticamente todos os frameworks ágeis em uso em produção hoje foram desenhados antes dos assistentes de IA fazerem parte do fluxo de trabalho diário. Scrum, SAFe, Kanban, PRINCE2 — todos assumem que o trabalho é feito por humanos, com as ferramentas fora do limite da equipa. A IA aparece nesses frameworks como "tooling", no melhor dos casos como uma camada de produtividade.

Essa assunção está a fissurar. Na maioria das organizações de engenharia com que trabalho, o assistente de IA não é uma ferramenta ao lado do programador — faz parte do loop. Pega em tickets, escreve rascunhos de código, resume contexto, executa análises, escreve documentação. Tratá-lo como tooling fora-de-banda produz fricções mensuráveis: artefactos de processo que ignoram onde o trabalho realmente acontece, métricas de performance que não vêem o contributo da IA, lacunas de responsabilidade quando o trabalho produzido pela IA falha.

O Honey Badger Management Framework (HBMF), apresentado por Georgios Fradelos em 2024, adopta a postura oposta: os assistentes de IA são membros formais da equipa. Têm papéis definidos, acesso definido, limites definidos. O framework também integra a conformidade ESG no modelo operacional em vez de a colar como camada de reporting. Vale a pena entendê-lo, mesmo que não o adoptes inteiramente, porque as escolhas de desenho revelam as verdadeiras lacunas dos frameworks ágeis convencionais quando a IA está no loop.

O que distingue HBMF

Tirando a nomenclatura, HBMF é um pequeno conjunto de escolhas com opinião:

Sprints de sete dias canceláveis. Mais curtos que o default de duas semanas do Scrum, com permissão explícita para cancelar um sprint a meio se o objectivo já não vale o trabalho. O argumento económico é real: a teoria das opções reais — os lotes pequenos preservam a opcionalidade, e os sprints longos destroem-na.

Duas sub-equipas em competição dentro de uma mesma equipa. Mesmo problema, duas tentativas em paralelo, julgadas pelo resultado. É competição governada: uma estrutura de torneio dentro do limite da equipa, com governança explícita para evitar o modo de falha (sabotagem, erosão da ajuda, colapso da segurança psicológica).

Integração de IA obrigatória. Cada equipa tem um assistente de IA designado para o trabalho de conhecimento. A direcção usa o mesmo assistente. A IA não tem autoridade de decisão — isso é crítico — mas é tratada como contribuidora cujo output é parte do entregável da equipa, não um truque privado de produtividade de alguém.

Declarações obrigatórias de lacunas de conhecimento. Cada membro da equipa, semanalmente, declara uma força de campo restrito e uma lacuna de conhecimento. Pública, visível no dashboard, não estigmatizada. O sentido é fazer aflorar o que as pessoas ainda não sabem antes que se torne defeito.

Dois papéis de liderança, não um. Um Manager detém os requisitos de produto e as decisões de recursos. Um Guru detém a conformidade de processo, a transferência de conhecimento e a transparência do dashboard, com direito de escalada a nível C. A separação é intencional: separar a autoridade de produto da autoridade de processo evita o conflito de interesse que afecta os frameworks onde uma pessoa faz ambos.

ESG incorporada no modelo operacional. Eficiência energética, transparência e acessibilidade são restrições a nível de sprint, não de reporting de portfolio. O assistente de IA, usado por todos, é parte do argumento ESG em si — reduz o custo energético marginal do trabalho cognitivo em comparação com escalar headcount.

O que HBMF acerta

Algumas destas escolhas são não-óbvias e vale a pena entendê-las uma a uma.

IA como membro de equipa, não como ferramenta

A fronteira importa mais do que parece. Quando a IA é "tooling", ninguém é proprietário da qualidade do seu output, ninguém documenta os seus modos de falha, ninguém planeia as suas quedas. Quando é membro de equipa com papel definido, a equipa planeia em torno: que trabalho é seu, que trabalho nunca é seu, que trabalho redige e um humano assina.

A regra de "sem autoridade de decisão" é particularmente importante. A IA pode analisar, resumir, recomendar, redigir, propor. Não aprova, não envia, não assina, não faz commit. A fronteira de responsabilidade humana é preservada por construção. É o mesmo princípio que aparece no trabalho sério de governança de IA agêntica — fronteiras verificáveis sobre o que a IA pode fazer, defaults fail-close para acções irreversíveis.

Sprints canceláveis

O cancelamento é a parte onde a maioria das equipas hesita. O reflexo ágil padrão é terminar o sprint e aprender com o post-mortem. HBMF inverte isto: se o objectivo deixa de valer o custo a meio do sprint, mata-o. Não é custo afundado.

Isto só funciona se a equipa tratar o cancelamento como resultado normal em vez de fracasso. Isso requer permissão cultural, que requer liderança a apoiá-lo, que requer que o framework o torne explícito. A maioria dos frameworks ágeis cala-se sobre cancelamento de sprint. HBMF torna-o uma característica.

Liderança a dois papéis

A separação Manager + Guru resolve uma disfunção comum: a mesma pessoa que decide o que construir também faz cumprir o processo, o que significa que a conformidade de processo é comprometida sempre que choca com a entrega. Separar em dois papéis, com o Guru a ter direito de escalada a nível C, faz do processo a preocupação estruturalmente protegida.

Na prática, o papel de Guru parece-se com um Engineering Manager sénior focado em operações de entrega em vez da entrega de funcionalidades — mais próximo de um lead técnico com mentalidade SRE do que de um Scrum Master. A disciplina de dashboard (snapshots até três vezes por dia, amplamente visíveis) é o que torna o papel útil em vez de cerimonial.

O que HBMF acerta provisoriamente (e o que tem risco)

O elemento que pede mais escrutínio é a competição governada intra-equipa. Duas sub-equipas a competir, julgadas por output, é uma estrutura de torneio — e a teoria do torneio mostra efeitos claros no esforço, mas também prevê erosão da cooperação, redução da ajuda e aumento do risco de sabotagem sob governança errada.

A resposta de HBMF é o papel do Guru mais sessões de ajuda diárias obrigatórias ("irmão mais velho / irmão mais novo") a uma hora fixa. A intenção é preservar a aprendizagem entre equipas e contrariar o efeito de retenção de ajuda que a competição pura produz.

Se isto funciona depende da execução. O enquadramento honesto — e o próprio enquadramento de HBMF — é que este pilar é contingente. Funciona em contextos com governança forte, métricas transparentes e cultura de segurança psicológica. Pode falhar gravemente em contextos onde qualquer destas é fraca. Os CTO que avaliam HBMF não devem assumir que o pilar de competição é universalmente benéfico.

Onde HBMF não encaixa

O framework não é universal. Alguns contextos onde iria com cuidado:

Equipas pequenas (< 6 pessoas). Dividir uma equipa pequena em duas sub-equipas competidoras produz sub-equipas demasiado pequenas para funcionar. O pilar de competição assume headcount suficiente para suportar duas sub-unidades viáveis.

Ambientes regulados com muita compliance onde o acesso a IA está limitado. HBMF assume que o assistente de IA é amplamente acessível à equipa e à direcção. Em ambientes onde o acesso a IA está restrito por classificação de dados ou fronteira regulatória, o mecanismo central do framework é parcialmente neutralizado. Pode-se adaptar, mas a adaptação não é trivial.

Domínios maduros e de baixa incerteza. O sprint de sete dias cancelável está optimizado para trabalho de alta incerteza e aumentável com IA onde lotes pequenos preservam valor de opções reais. Em trabalho estável e bem entendido, o custo do ciclo pode não compensar.

Organizações sem maturidade DevOps. A disciplina de dashboard e a cadência do ciclo assumem que a infraestrutura de engenharia subjacente pode suportar integração frequente e telemetria visível. Se o teu CI/CD está partido, arranja-o primeiro; o framework não compensará.

As conclusões concretas

Não tens de adoptar HBMF para aprender com ele. As adaptações concretas que a maioria das organizações de engenharia deve considerar em 2026:

1. Trata os assistentes de IA como contribuidores nomeados, não ferramentas. Define o que a IA possui, o que redige, o que nunca possui. Documenta os seus modos de falha ao lado dos papéis humanos.
2. Faz do cancelamento de sprint um resultado normal. Reduz o custo político de parar trabalho que já não vale a pena.
3. Separa a autoridade de produto da autoridade de processo. Mesmo informalmente, garante que uma só pessoa não é simultaneamente decisora de entrega e executora do processo.
4. Torna visíveis as lacunas de conhecimento. Algum mecanismo semanal — escrito, público — para as pessoas declararem o que ainda não sabem. O nudge comportamental importa mais do que o formato.
5. Move o ESG para o modelo operacional diário. Se só vive no reporting de portfolio, não está a fazer o trabalho.

A lição mais profunda é que o vocabulário ágil padrão foi desenhado para uma força de trabalho que já não existe em forma pura. As equipas com que trabalho são híbridas. Os frameworks que o ignoram produzem fricção em cada interface onde a IA está no loop. Os frameworks que o levam a sério — mesmo os com arestas, como HBMF — estão a fazer o tipo certo de trabalho.

---

Fonte: Fradelos, G. The Honey Badger Guide (Versão 1.4, 2024). SSRN 6285978.

Se a tua organização de engenharia opera com uma força de trabalho híbrida humano-IA e as práticas de gestão não se actualizaram, fala com um CTO sobre desplegar squads nearshore que já trabalham assim.