DEV Community: Marcelo Palladino "Palla"

Seu time trocou o refinamento pelo plan mode, e ninguém mais precisa se falar

Marcelo Palladino "Palla" — Mon, 10 Aug 2026 01:28:57 +0000

A BruLethy era gerente sênior de dados numa das maiores empresas de tecnologia do mundo, e pediu demissão depois de oito anos lá dentro. Ela gravou um vídeo contando por quê, e faz questão de dizer, no meio da própria história, que não foi culpa da inteligência artificial.

"Eu não quero ser hipócrita em dizer que a minha vida foi destruída pelas inteligências artificiais. Eu vi como o meu trabalho foi potencializado, mas a forma com que isso foi implementado e a cobrança em cima disso foi o que transbordou o meu copo."

BruLethy, aos 10:21

Guarde essa ressalva, porque ela é dela e vai na direção contrária deste texto, que passa daqui em diante falando do que a IA mudou. Eu acho que as duas coisas cabem. A ferramenta é a mesma para todo mundo. O que mudou foi o que ela tornou possível uma gestão fazer.

O que aconteceu com ela foi uma reestruturação. Tiraram os analistas do time e, no lugar de gente, entregaram agentes.

"Ao invés deles me darem pessoas para me ajudar, um time para me ajudar, eles me deram algumas inteligências artificiais que eu podia agora colocar para trabalhar para mim 24 horas por dia, sete dias por semana. Então os limites do que era humanamente possível de ser feito não existiam mais."

BruLethy, aos 09:00

E ela era boa nisso. Como sênior, batia o olho na saída do modelo e via o erro rápido. A recompensa por render bem foi mais área, mais projeto e mais agente, até chegar no ponto que ela descreve como cinco projetos planejados sozinha, com cinco modelos diferentes, para entregar tudo no mesmo dia.

Isso tem nome, e eu venho usando ele há três anos. Só que o nome vem depois. Primeiro a frase.

A IA não destruiu a colaboração. Ela removeu a obrigatoriedade dela.

Colaborar era necessidade estrutural de quem não conseguia segurar o problema inteiro sozinho. Hoje uma pessoa com um agente segura, e entrega. E o que vira opcional deixa de acontecer.

O que dava mais medo era depender de uma pessoa só

Em 2023 eu subi no palco do TDC com uma frase que tinha acabado de escrever para um artigo sobre o que faz o deploy dar menos medo, publicado em inglês no Builder Center da AWS. Nada corrompe mais a cultura DevOps do que o heroísmo. Repeti a sessão várias vezes desde então, e a última gravada é do DevOpsDays Campinas de 2025.

A frase nasceu de um exercício simples. Eu queria entender o que exatamente me dava medo na hora de colocar alguma coisa em produção, depois de descontar ferramenta, automação e testes. Sobrava uma coisa só. Me dava medo subir código sabendo que, se desse problema, existia uma única pessoa capaz de resolver.

O ponto que eu defendo nessa sessão é que herói não é falha da pessoa. É falha de liderança. Ninguém acorda querendo ser o único que sabe mexer em uma parte específica do sistema. A pessoa vai acumulando contexto, os outros vão saindo, a organização não cria mecanismo nenhum para espalhar aquilo, e um dia ela olha em volta e está sozinha segurando um pedaço da empresa. Os dois lados dessa moeda são ruins. Eu já estive nos dois.

O que mudou de 2023 para cá é o tempo que leva para produzir um herói.

Antes o herói se formava por acidente

Reparem na ordem dos acontecimentos no relato dela. Uma decisão de reestruturação, tomada de uma vez, removeu o time e colocou capacidade de máquina no lugar. O desgaste de anos que costuma produzir esse tipo de dependência foi pulado inteiro. E foi apresentada como melhoria de cargo. A frase dela é "voltei a ser uma super analista, super super sênior".

É o herói sendo fabricado e comemorado dentro do mesmo processo.

Ela também viveu os dois lados da moeda ao mesmo tempo, o que eu nunca tinha visto acontecer com a mesma pessoa. Era a única capaz de revisar aquele volume, e dependia inteiramente de um sistema que precisava conferir sozinha. Os dois papéis colapsaram em uma cadeira só.

E o exercício que eu proponho na palestra para justificar tudo isso para a gestão, que é perguntar quanto custa se essa pessoa sair do time, acabou de rodar em público. Ela saiu. Passou por burnout, terapia e medicação antes de sair, e conta no vídeo que, ao conversar com os colegas, descobriu que não era só ela.

As cerimônias não eram amadas, eram obrigatórias

Tem um trecho no vídeo dela que é a descrição mais precisa de mob programming que eu já vi, escrita por alguém que não usa esse nome e que está falando no passado.

"Quando a gente tinha um problema que não conseguia resolver sozinho, o que a gente fazia? A gente chamava pessoas que a gente confiava, que a gente admirava intelectualmente. A gente sentava numa sala, mostrava o problema, todo mundo ali interagia colaborativamente para resolver esse problema e a gente chegava numa solução. E aquilo ali não existia mais, porque agora você só precisava escrever um prompt bem bonito e jogar para a inteligência artificial."

BruLethy, aos 11:41

O Mano Deyvin assistiu e comentou esse vídeo ao vivo no canal dele, e ataca pelo outro lado, o do processo. Ele desenha a esteira antiga inteira no quadro, discovery, kickoff, priorização, planning, pré-refinamento, refinamento, e diz que com IA isso morreu. E aí o Henrique Breim, no chat, fecha o assunto melhor do que os dois.

"Refinamento hj é plan mode do claude"

@HenriqueBreim, no chat do Mano Deyvin, aos 11:26

Ninguém nunca acordou feliz para o pré-refinamento. Aquilo funcionava porque estava no calendário e não dependia de alguém querer, e o efeito colateral de estar no calendário é que uma vez por semana o time inteiro era empurrado para dentro da mesma sala, olhando para o mesmo problema, com as mesmas dúvidas.

O que removeram do processo foi justamente o que mantinha a colaboração de pé sem depender de vontade. E o que sobra quando a sala para de acontecer é o que ela conta no vídeo, semanas seguidas sem falar com ninguém sobre nada que não fosse uma entrega.

60% preferem trabalhar sozinhos, e não estão errados

O Mano Deyvin rodou uma enquete ao vivo durante a transmissão. 60% do chat dele preferem trabalhar sozinhos com IA. 40% preferem trabalhar com pessoas. O chat responde coisas como "somos antissociais" e "solta o Claude Code na minha mão".

É enquete de chat ao vivo, autosselecionada, e sem número de respondentes divulgado. Serve como sintoma, e é assim que eu vou usar.

O sintoma é a outra metade do mecanismo. A preferência por trabalhar sozinho sempre existiu. O que sustentava a sala de pé, mesmo contra ela, era a obrigatoriedade. Some a obrigatoriedade, some a sala. E isso também significa que qualquer proposta que dependa das pessoas passarem a gostar de sentar juntas já nasce morta.

Ele mesmo, que passou o vídeo inteiro defendendo o lado humano, fecha com uma fronteira que eu acho mais precisa do que qualquer coisa que eu tinha formulado antes.

"Quando você tá numa empresa muito grande, tomar decisão sozinho com uma IA é ruim, é bom ter mais gente. Mas agora como um programador entregando task, solta o Claude Code na minha mão."

Mano Deyvin, aos 24:37

Grupo na decisão. Sozinho com o agente na execução.

Isso resolve a tensão inteira, e é exatamente a ordem que a gente acabou seguindo sem ter formulado assim.

A revisão virou o trabalho, e ninguém está formando sênior

A parte mais forte dele é quando desenha o fluxo e mostra onde a IA ajuda e onde não ajuda. Discovery e mão na massa, resolvido. Revisão, não. A frase dele é que você tem muito mais trabalho validando do que criando.

Eu falei uma coisa parecida no DevOpsDays de 2025, e falei de forma absoluta demais. Disse que não faz o menor sentido gerar código com IA e depois botar IA para revisar. A parte que se sustenta é a da responsabilidade, e eu mantenho cada palavra dela. Se eu subo código para produção, eu respondo por aquele código, tendo usado assistente ou não. A parte que envelheceu mal é o absoluto. Revisão assistida como primeira passada, com uma pessoa assinando embaixo do merge, funciona e vai acontecer.

Só que isso parte a revisão em duas, e as duas metades têm destinos diferentes. Ler o diff e apontar o que está estranho é delegável, e cada vez mais. Decidir quando desconfiar do resultado, e em que ponto parar, não é. A máquina assume a primeira. A segunda fica inteira com a pessoa, e é ela que exige repertório.

Só que o Mano Deyvin faz uma observação que fecha a armadilha. Escalar o time não resolve o gargalo de revisão, porque revisão exige alguém sênior. E aí volta o trecho mais grave do vídeo dela.

"Agora era mais fácil pedir para escrever um código SQL do que ensinar o cara que acabou de chegar a escrever e corrigir os erros dele."

BruLethy, aos 12:28

Quem toma essa decisão todo dia fica sem sênior em poucos anos. E sem sênior não existe a revisão que acabamos de estabelecer como o gargalo. Sai barato hoje e cobra caro depois, porque formar sênior leva anos e a conta só chega quando já não dá tempo de formar ninguém.

Mob programming é a resposta que eu tenho aqui, e a primeira versão dela está errada. A primeira versão é colocar quem sabe menos vendo quem sabe mais decidir, o que pressupõe alguém na sala com o repertório pronto.

Não tem. Saber quando desconfiar de um agente é conhecimento novo, e os sêniores de hoje não adquiriram isso em lugar nenhum, porque não havia onde. Eu inclusive.

Então não é transmissão, é construção. E a diferença importa mais do que parece. Quando o grupo constrói o julgamento junto, em cima de um problema de verdade, ele nasce distribuído. Quando uma pessoa constrói sozinha, ele nasce concentrado, e a gente já sabe onde isso termina.

E aqui eu preciso separar duas senioridades que eu vinha tratando como uma. A antiga é repertório de domínio e de código, leva anos, e é ela que a decisão de pedir o SQL ao modelo em vez de ensinar quem chegou está destruindo. A nova é saber desconfiar do agente, e essa se constrói em meses, porque nem existia até outro dia.

Só que a nova depende inteiramente da antiga. Ninguém desconfia de um resultado sem ter repertório para achar estranho o que está ali. E é por isso que destruir a formação da primeira inviabiliza a segunda, mesmo a segunda sendo rápida de construir.

Escrever skill é externalização, e a espiral não fecha

Nonaka e Takeuchi já descreveram isso, e melhor do que eu. Eles descrevem quatro movimentos possíveis entre conhecimento tácito e explícito, formando uma espiral que gira porque o explícito volta a virar tácito no fim, e só um dos quatro dispensa documento.

Tem um detalhe nesse quadro que eu só enxerguei há pouco tempo. Quando a gente escreve uma skill para um agente, que é um documento de instruções que ele carrega e executa sozinho, está fazendo externalização, exatamente como quem escreve um playbook. A diferença aparece depois, em quem lê. Playbook uma pessoa lê, aplica, e aquilo vira reflexo, então a espiral gira. Skill o agente executa, e a volta para o tácito simplesmente não acontece.

Dá para entregar cada vez mais assim, indefinidamente, sem que ninguém tenha aprendido no caminho. É a mesma conta do parágrafo anterior, vista pelo outro lado.

O que a gente fez no Dati Labs, e por que o resultado não foi código

O Dati Labs é a área de IA e modernização da Dati, e o que nos ocupa é entender o que muda no jeito de trabalhar quando agentes entram no trabalho para valer.

Em julho o time inteiro passou um dia em cima de um problema de cliente que ninguém tinha resolvido antes, com voz em tempo real e avatar apresentando ao vivo em palco. Nada parecido com o dia a dia de ninguém ali.

Estamos construindo um time, e eu queria fazer isso com problema real em vez de exercício, porque exercício todo mundo sabe que é exercício e ninguém se compromete de verdade com o resultado. E queria que a gente exercitasse programar com IA em grupo, e não cada um na sua máquina descobrindo sozinho o que funciona.

O formato foi uma sessão longa de sabatina com o agente de IA no meio e com a condução mudando de mão o tempo todo ao longo do dia. A pessoa da vez assume o problema e leva as perguntas da sala inteira até a decisão ficar de pé, e então passa adiante. Todo mundo passou pela cadeira.

A troca de mão tinha um artefato. Virava um documento escrito na hora, endereçado a quem assumia a cadeira, com o estado da discussão e a regra de como continuar. E a regra é a parte que interessa aqui. Se algo já decidido parecer errado, desafie uma vez, em voz alta, e deixe o time decidir, que é antiheroísmo escrito dentro do processo.

Em algum ponto do dia o quadro branco entrou. Não estava planejado e não durou muito, uns cinco minutos, o tempo de desenhar o orquestrador no meio, as peças em volta, e colocar o time todo na mesma página.

No fim do dia não havia código de produção. Havia uma especificação escrita e mais de sessenta tarefas especificadas e prontas para desenvolvimento.

Isso me obrigou a atualizar a minha própria palestra. Nas duas gravações eu descrevo mob programming como gente revezando no teclado, quinze ou vinte minutos cada, resolvendo um problema de código de forma colaborativa. Foi assim que eu aprendi programação funcional nos meus primeiros dias no Nubank, todo torto, sem saber as teclas de atalho direito, e foi o período em que eu mais aprendi lá.

Mob programming já estava na lista de antídotos contra o heroísmo que eu publiquei naquele artigo de 2023, junto com pair programming, game days e sessões de whiteboard. E o quadro branco está naquela lista por um motivo específico, que é impedir que a arquitetura desça pronta da cabeça de uma pessoa só.

O teclado hoje é onde o agente trabalha. Então o que o time produz junto deixou de ser apenas o código e passou a ser aquilo que o agente vai consumir depois. O mecanismo continua o mesmo. Mudou o artefato que sai da sala no fim do dia.

Toda sexta o time inteiro junto

Hoje esse projeto está na mão de um desenvolvedor. Uma pessoa sozinha com um agente é, ponto por ponto, a configuração que quebrou a gerente do vídeo, e é o arranjo que produz herói mais rápido que qualquer outro que eu já tenha visto.

Por isso o time inteiro para trinta minutos toda sexta-feira. E o combinado é explícito quanto ao que aquilo não é. Não é reunião de status de tarefa. Quem está no projeto conta o avanço e, principalmente, o método. O combinado até aqui é escolher um projeto por vez e tornar isso um hábito. Estamos só no começo disso.

A palavra que carrega peso ali é método. Status qualquer um extrai do repositório, de uma ferramenta de tarefas, e um agente extrai melhor e mais rápido do que a gente. Por que a pessoa desconfiou do agente naquele ponto específico, o que ela tentou antes, e o que fez ela mudar de ideia, isso não está em commit nenhum.

Nas minhas sessões eu compartilho uma prática parecida chamada rotação do bombeiro. A ideia original é rodar quem fica de plantão, semana a semana, para que o time inteiro aprenda a apagar incêndio e ninguém acabe sendo o único que sabe. Esta sexta-feira que estamos colocando no Dati Labs é a mesma mecânica aplicada a conhecimento em vez de incidente, e ela entrou na agenda antes de existir um herói para dissolver.

Naquele artigo de 2023 eu escrevi que a organização pronta para fazer deploy na sexta é a que entende que cultura de time vale mais que talento individual. Ironicamente, nossa reunião é às sextas-feiras. Só que agora deployment não é o assunto.

O que ainda não sabemos

Isso foi um dia, num projeto. É anedota, não evidência, e eu não vou fingir o contrário.

O que a anedota ilustra, porém, não é anedota. O relatório da DORA de 2025, com quase cinco mil profissionais ouvidos, achou três coisas que conversam direto com este texto. A adoção de IA passou a ter relação positiva com throughput, o que é uma virada em relação a 2024. Ela continua tendo relação negativa com estabilidade de entrega. E 30% relatam pouca ou nenhuma confiança no código que a IA gera, o que o relatório lê como necessidade de capacidade crítica de validação.

Aceleração expondo fraqueza mais adiante no fluxo, e validação virando a habilidade escassa. É o mesmo mecanismo que eu descrevi aqui, medido em escala que eu não tenho.

Falta dizer o que me faria mudar de ideia, porque admitir que é anedota é honestidade sobre a evidência e não sobre a tese. Em seis meses de sexta-feira eu vou olhar duas coisas. Se alguém de fora do projeto conseguir contar o método em voz alta, funcionou. Se a pauta começar a escorregar para status sem ninguém ter decidido isso, virou mais uma reunião no calendário e eu conto aqui.

Também não vou fingir que é uma prática confortável. Na minha sessão eu conto que já trabalhei com gente que simplesmente não entrava no mob, e a parte irônica é que costumavam ser justamente as pessoas com quem eu mais teria aprendido. Expor o que você não sabe na frente do time é desconfortável, e é legítimo que seja. Sem cultura de confiança construída antes, isso não funciona, vira constrangimento e o time abandona na segunda tentativa.

Créditos

A ideia de que heroísmo é anti-padrão não é minha. Ela está em The Phoenix Project, no personagem do Brent, está no Effective DevOps, de Jennifer Davis e Ryn Daniels, que trata heroísmo entre os anti-padrões culturais.

E está na DORA. O State of AI-assisted Software Development de 2025 achou sete perfis de time por análise de cluster, e um deles é o hero team, que entrega com qualidade e impacto sobre uma fundação instável apoiada em heroísmo individual em vez de processo. Eu escrevi uma frase com superlativo em cima de um problema que a comunidade já tinha nomeado, e a frase é o que eu reivindico, não o diagnóstico.

O quadro dos quatro movimentos tem duas datas, e vale separar. Os quatro padrões de conversão entre tácito e explícito já estão no artigo que o Nonaka publicou sozinho na Harvard Business Review em 1991, onde o tácito para explícito se chama articulação. Os nomes que eu uso aqui, externalização inclusive, vêm do livro de 1995, com o Takeuchi. Vale uma correção que eu preciso fazer em mim mesmo. No artigo de 2023 eu escrevi que revisão de código transfere conhecimento tácito por socialização, com essa palavra. No palco, eu apresento três dos quatro movimentos e deixo a socialização de fora. Escrevi certo e falei errado por dois anos.

Mob programming também não é invenção nossa, e eu usei o termo o texto inteiro sem dizer de onde ele vem. A prática foi nomeada pelo Woody Zuill e pelo time dele, e o desenho original é o time inteiro no mesmo problema, ao mesmo tempo, no mesmo espaço e no mesmo computador. O que eu descrevo aqui, com a sessão terminando em especificação em vez de código, é um desvio desse desenho. O desvio é meu, e a crítica sobre ele também deve vir para mim. Vale dizer que parte da comunidade hoje prefere chamar a prática de ensemble programming.

E o vídeo que abre este texto é da BruLethy, com o comentário ao vivo do Mano Deyvin por cima. Os dois merecem ser assistidos inteiros, e a discordância entre eles é mais interessante do que a concordância.

O detalhe que decide se o seu radar de tecnologia vive ou morre

Marcelo Palladino "Palla" — Mon, 20 Jul 2026 13:26:17 +0000

Em 2022, eu e o Francisco Edilton (Chico, AWS Community Hero) nos encontrávamos todas as terças-feiras, sete da noite no horário do Brasil, para escrever a HeroBuzz. Ele em Lisboa, eu em São Paulo. A newsletter era a desculpa. O que a gente realmente fazia era jogar conversa fora.

A maioria das pessoas olha para uma hora marcada no calendário e pergunta quanto tempo aquilo vai durar. Comigo e com o Chico a pergunta sempre é como aproveitar melhor esse tempo. E era nessa "perda de tempo" que apareciam as histórias que compartilhamos na HeroBuzz. Coisas que a gente tinha visto dar errado, times que quebraram do mesmo jeito em organizações que não tinham nada a ver uma com a outra, decisões óbvias em retrospecto que ninguém tomou na hora. De vez em quando uma delas era boa demais para morrer ali, e um de nós dizia "e se a gente escrevesse sobre isso?".

Foi assim que nasceu a edição #33, em abril daquele ano. Na semana anterior tínhamos falado sobre o Technology Radar da ThoughtWorks e como ele é organizado. Naquela, pegamos o gancho para falar sobre por que uma organização poderia querer criar um radar próprio. Escrevemos sobre conhecimento concentrado em poucas cabeças, sobre o efeito copia e cola entre times, sobre stack que cresce sem gestão até virar problema de segurança. E terminamos com uma pergunta ao leitor:

Nós conhecemos algumas organizações que se beneficiariam muito de um radar próprio. E você, acha que faz sentido para a sua realidade? Quais seriam os anéis e quadrantes do radar para sua organização?

Era muito fácil escrever aquilo. A gente estava olhando de fora.

Há 45 dias assumi a direção de AI & Modernization na Dati e estou liderando as iniciativas do Dati Labs. A pergunta voltou endereçada a mim.

Boas ideias param na máquina de quem as teve

Essa cena eu já tinha visto se repetir em lugares que não tinham nada em comum, e levei tempo para entender que era sempre a mesma cena.

Alguém chega numa conversa e diz que a tecnologia "X" está muito melhor que as outras tecnologias que usamos na empresa. Qual é a prova? Não existe. É uma impressão legítima, formada por alguém competente, que não vira decisão de ninguém porque não tem lastro nem lugar para morar. Ou alguém inicia uma iniciativa que outro time já estava tocando havia semanas. Repare que aí ninguém errou. Os dois times fizeram exatamente o que se esperava deles, com autonomia e velocidade. O desperdício aconteceu do mesmo jeito.

Velocidade individual produz desperdício coletivo quando não existe um canal para as pessoas saberem umas das outras. E o problema é difícil de combater porque nunca se apresenta como falha. Ele se apresenta como movimento. Todo mundo ocupado, todo mundo entregando, e a organização andando menos do que se espera. É um dos sintomas clássicos de falta de coordenação.

Duas formas de escalar engenharia

Para simplificar a discussão aqui, podemos dizer que existem dois jeitos de organizar isso.

O primeiro é o time opinativo. A stack está decidida e o desenvolvedor não gasta julgamento escolhendo ferramenta. Ele gasta julgamento no negócio. Isso escala muito bem e entrega rápido, e quem despreza esse modelo normalmente nunca precisou sustentar cinquenta times ao mesmo tempo.

O segundo é o time onde experimentar é normal e até esperado. Você compra capacidade de descobrir coisas e paga em dispersão. No caso do Dati Labs, é o modelo certo. Nosso trabalho é justamente descobrir, e a gente não descobre nada sem experimentar.

O Dati Labs é a área de AI & Modernization da Dati, e o que nos ocupa é a transformação do trabalho com IA agêntica. A pergunta que a gente quer responder é o que muda no jeito de fazer as coisas quando agentes passam a participar do trabalho para valer, e como isso vai se refletir nas organizações, nos processos e no software.

No Dati Labs, autonomia é uma escolha deliberada. É como acreditamos que se constrói um time que precisa explorar tecnologia em constante mudança. Só que essa escolha tem uma conta, e a conta é transparência.

A conta da autonomia

Autonomia cria imediatamente dois desafios de comunicação que não existiam antes.

O primeiro é para cima. Como comunicar à liderança o que o time está explorando? Se a resposta for uma apresentação que você monta de vez em quando, com o que lembrar na véspera, então a autonomia do time está apoiada na sua memória, e isso não sobrevive a nenhum trimestre difícil. E, principalmente, não sobrevive à sua saída. Líderes vêm e vão, a organização continua. Quem está acima de você não vai retomar decisões por má-fé. Vai retomar porque ninguém consegue defender o que não enxerga.

O segundo é para os lados. Como permitir que seu time aprenda com outros times, e que outros times aprendam com o seu? Colaboração entre áreas não acontece por boa vontade. Acontece quando existe alguma coisa visível para colaborar em cima.

Foi aí que a ficha caiu sobre o que eu mesmo tinha escrito quatro anos atrás. Autonomia sem transparência produz desperdício com aparência de produtividade. E a transparência que resolve isso não é um relatório produzido por alguém, porque relatório tem a assinatura e o recorte de quem o produziu. Tem que ser um artefato que pertence ao time, que qualquer um consegue ler, e que continua existindo independente de quem está na sala.

Transparência morre quando é cara

Essa é a parte que eu subestimei em 2022, e é onde a maioria das tentativas fracassa.

Se contribuir com o artefato exigir ter uma opinião formada, ninguém contribui. A pessoa viu um lançamento interessante numa quinta-feira à noite, não tem tempo de avaliar, não quer ou não tem tempo para se posicionar sobre aquilo depois, e simplesmente não registra. A ideia volta a morrer na máquina de quem a teve, agora com um processo bonito por cima.

O que resolveu isso para o Dati Labs foi separar duas coisas que parecem uma só. Registrar e julgar.

Registrar precisa ser quase gratuito. Nome, categoria, link, data. Ninguém precisa ter opinião para colocar algo na fila, e colocar não significa endossar. Julgar é um passo separado e deliberado, que acontece depois, com calma e critério. Quando você mistura os dois, obriga cada pessoa a chegar com posição pronta, e o custo disso silencia justamente quem tem menos tempo e mais contexto de campo.

Essa separação é o que tenho de mais transferível para oferecer aqui, e ela não depende de ferramenta nenhuma.

Vale dizer o que pode dar errado do meu lado da mesa. Radar interno pode virar cemitério de blips (cada item registrado no radar) com uma facilidade impressionante, e quase sempre pelo mesmo motivo. Alguém confunde o artefato com o processo e começa a exigir campos, revisão e reunião de curadoria. O custo de entrada sobe, o mecanismo passa a servir a si mesmo, e o time volta a decidir por fora mantendo a aparência por dentro. Quando ninguém alimenta, a primeira hipótese que eu tenho que considerar é que eu tornei a entrada ou a avaliação cara demais.

Baixar esse custo de entrada e de avaliação é, por si só, um desafio e tanto. E é exatamente o tipo de coisa que IA agêntica resolve muito bem. No Dati Labs a gente já começou a usar agentes para isso. Mas esse é assunto para outro texto.

O radar começa como espelho

Cheguei imaginando que o trabalho inicial seria montar um mecanismo para decidir o que vem pela frente. Errei a ordem.

Quando você chega a uma organização que já entrega muito, não está diante de uma folha em branco. As pessoas já entregaram projetos, já resolveram problemas difíceis, já formaram opinião sólida sobre um monte de coisa. Já existe postura. Talvez ela só não seja recuperável por ninguém além de quem a formou. Fica viva no julgamento de cada pessoa e invisível para todas as outras ao mesmo tempo.

Descobrir isso não depende de epifania. É conversando com as pessoas e entendendo o contexto. Influência se constrói conhecendo as pessoas e o terreno, e eu passei as primeiras semanas aprendendo bem mais com o meu time do que o contrário. É um time talentoso e eu tenho sorte de trabalhar com eles.

Então o primeiro trabalho de um radar não é decidir nada. É dar nome ao que já é verdade. Você registra a postura que o time já tem antes de começar a triar o que chega de fora, e só depois de existir esse espelho é que faz sentido montar o filtro.

A matriz de fronteira e relevância do Dati Labs

Quando o filtro entra em cena, a tentação é ordenar tudo por novidade. Achamos que essa é a régua errada, e ela é o motivo de tanta gente boa gastar a semana correndo atrás do que está mais barulhento na timeline. O hype pelo hype.

No Dati Labs, a gente usa duas perguntas, e a segunda pesa mais que a primeira.

A primeira é sobre o potencial de mudança: isso muda o teto do que era possível, reabrindo casos que a gente considerava inviáveis, ou melhora muito alguma coisa que já dava para fazer?

A segunda é sobre relevância: isso toca os nossos clientes e/ou a nossa stack, ou é interessante para o mundo e distante do que a gente entrega e da estratégia?

Percebe? No limite, tudo é interessante. Então ter uma régua de relevância é fundamental para não desperdiçar energia.

	Perto do nosso jogo	Longe do nosso jogo
Muda o teto do que é possível	Anel 1: Mergulhar. Testar agora.	Anel 3: Observar. De longe.
Melhora o que já era possível	Anel 2: Acompanhar. De perto, sem correr.	Anel 4: Passar. Registrar e seguir.

A relevância pesar mais é o que muda o resultado, o que é um tanto contraintuitivo, se você pensar bem. Mas vem comigo, uma coisa impressionante que não toca no seu jogo, que não conversa com a estratégia de negócio, merece menos energia do que uma coisa entediante que toca. Faz sentido? Pense nisso como antídoto para o "isso aqui está muito melhor agora" solto numa conversa de corredor, porque a régua nos leva a completar a frase.

"Melhor para quê? Melhor para quem? Melhor quanto?"

Na mesma semana avaliamos duas novidades da mesma categoria, do mesmo fornecedor. As duas eram boas. Mas apenas uma reabria casos de uso que antes eram inviáveis para nós. A outra apenas melhorava uma solução que já funcionava. Pela régua do hype, elas competiriam pela mesma priorização. Pela nossa régua de fronteira x relevância, tiveram destinos diferentes. Uma foi para teste imediato, para o mergulho, enquanto a outra foi para acompanhamento. Nenhum dos dois foi ignorado. Registrar o segundo é o que impede o time de reavaliar a mesma coisa do zero daqui a três meses.

Créditos

Nada disso é invenção nossa. O Technology Radar da ThoughtWorks é a técnica original, e a ThoughtWorks mantém o build-your-own-radar aberto justamente para que qualquer empresa monte o seu.

O que mudou não foi a técnica, foi a pressão. O Technology Radar é um retrato curado e periódico. Ele não foi desenhado para a vazão diária de lançamentos que a gente vive hoje, o que não é defeito nenhum, é escopo. Na prática, quando a entrada acelera desse jeito, você precisa de um lugar separado para o que chegou e ainda não foi julgado. Se a fila de triagem se misturar com a lista de posturas, as duas perdem sentido, porque você deixa de saber o que foi decidido e o que só foi anotado. Foi por isso que acabamos com dois níveis, um para o que está chegando e outro para o que já é postura, com uma ponte entre eles para o que sobrevive ao teste.

O que ainda não sabemos

Estamos bem no começo disso. O que queremos construir é justamente uma forma de fazer com que as pessoas do time da Dati se sintam confortáveis em contribuir, mesmo sem certeza de que aquilo vale a pena. O mecanismo é o meio para que isso aconteça, não o objetivo.

Em 2022 eu e o Chico perguntamos aos leitores quais seriam os anéis e quadrantes do radar da empresa deles. A pergunta continua valendo. Só que hoje eu sei que escolher os anéis é a parte fácil. A parte difícil é alimentar e manter aquilo numa terça-feira comum, com entrega pressionando e ninguém cobrando.

Me pergunte de novo daqui a seis meses.

Se você também está pensando em como a IA agêntica transforma o trabalho e as organizações, entre em contato comigo.

Speech-to-Speech AI: From Dr. Sbaitso to Amazon Nova Sonic

Marcelo Palladino "Palla" — Wed, 09 Apr 2025 14:34:14 +0000

I will never forget a certain night in the 1990s. It must have been around 1992 or 1993 - I was at my friend Junior's house, crowded with a bunch of other kids around his parents' computer. I am pretty sure it was a 386, or maybe a 286? All I knew back then was that it had a fancy multimedia kit. The source of our fascination was a program called Dr. Sbaitso.

Released by Creative Labs, Dr. Sbaitso was one of the first computer chat programs, created to demonstrate the capabilities of the Sound Blaster sound card. The name is actually an acronym for "Sound Blaster Artificial Intelligent Text to Speech Operator" (to be honest, I only learned it while I was writing this article).

The system simulated a digital psychotherapist and became known for its sometimes strange responses and its characteristic robotic voice. It was quite limited in its interactions. One of its most famous phrases was "TELL ME MORE ABOUT THAT”, which it frequently repeated during conversations, back then, with our cluelessness, it felt we were living in a sci-fi movie.

"Can you fall in love?" while everyone laughed beside me.

"TELL ME MORE ABOUT THAT", it would respond with its characteristic artificial voice.

We would not give up. We spent hours making up stories, creating scenarios, trying to convince that digital therapist to fall in love with one of our friends. With each disconnected response, we laughed more and tried even more hard.

It's funny how these memories stick with you. That clunky old PC with its robotic voice seems almost prehistoric now, but it was pure magic to us back then. Three decades later, I'm still amazed every time I think about how far we've come. During this time, the way people and machines interact has changed dramatically. From those first tries with voice synthesis, through different assistant experiments, up to the AI assistants that are now just part of our daily lives. And now here I am, working with Amazon Nova Sonic and Amazon Bedrock, building the kind of natural conversations I could only dream about back then.

Introducing Amazon Nova Sonic

Amazon Nova Sonic is a model that does everything together. Instead of the way where you needed different models and separate steps for STT (Speech-to-Text), processing, and TTS (Text-to-Speech), Amazon Nova Sonic just handles everything in one go, processing audio real-time both ways through complete two-way streaming. This means you can build systems that keep all the important stuff like tone, emotions, and how people actually talk throughout the whole conversation.

Let me show you a quick demo to see how this works. Meet DR ANSMUE (Amazon Nova Sonic Model Usage Example).

Yeah, I know it is not super original. But cut me some slack, ok? In this example, users can submit their code and chat with our "code therapist" about whatever code they sent in.

Under the hood

What I'm going to show you here is based on the Bidirectional Audio Streaming sample (the one using Amazon Nova Sonic and Amazon Bedrock with TypeScript) that you can find in the Amazon Nova Sonic Speech-to-Speech Model Samples. So, instead of getting into all the specific technical details of this sample, I'll focus on walking you through the key things you need to know for build this kind of application.

When the user starts talking, the web frontend gets the audio from the microphone using WebAudio API and sends it to the server through WebSockets. On the server side, we have got the StreamSession class that manages the audio chunks and puts them in line for processing.

socket.on('audioInput', async (audioData) => {
  // Convert base64 string to Buffer
  const audioBuffer = Buffer.from(audioData, 'base64');
  // Stream the audio
  await session.streamAudio(audioBuffer);
});

This works in collaboration with the S2SBidirectionalStreamClient class, which handles the back-and-forth communication using AsyncIterable to create a two-way stream with Amazon Bedrock, using the new capabilities of Amazon Bedrock SDK.

The createSessionAsyncIterable method in S2SBidirectionalStreamClient creates an iterator that feeds into the InvokeModelWithBidirectionalStreamCommand, a new invoke way from the Amazon Bedrock SDK, sending those audio chunks (in base64) to Amazon Nova Sonic. At the same time, processResponseStream handles what comes back from the Amazon Berock, figuring out the audioOutput and textOutput it receives.

private createSessionAsyncIterable(sessionId: string): AsyncIterable<InvokeModelWithBidirectionalStreamInput> {
  return {
    [Symbol.asyncIterator]: () => {
      return {
        next: async (): Promise<IteratorResult<InvokeModelWithBidirectionalStreamInput>> => {
          // Wait for items in the queue or close signal
          if (session.queue.length === 0) {
            await Promise.race([
              firstValueFrom(session.queueSignal.pipe(take(1))),
              firstValueFrom(session.closeSignal.pipe(take(1)))
            ]);
          }

          // Get next item from the session's queue
          const nextEvent = session.queue.shift();
          ...
}

// Actual invocation of the bidirectional stream command
const response = await this.bedrockRuntimeClient.send(
  new InvokeModelWithBidirectionalStreamCommand({
    modelId: "amazon.nova-sonic-v1:0",
    body: asyncIterable,
  })
);

S2SBidirectionalStreamClient keeps track of what is happening using the data structure SessionData, controlling signals, and event handlers. When the model comes back with something, it goes back through the same WebSocket to the frontend, where the browser plays it using WebAudio API.

private async processResponseStream(sessionId: string, response: any): Promise<void> {
  for await (const event of response.body) {
    if (event.chunk?.bytes) {
      const textResponse = new TextDecoder().decode(event.chunk.bytes);
      const jsonResponse = JSON.parse(textResponse);

      if (jsonResponse.event?.textOutput) {
        this.dispatchEvent(sessionId, 'textOutput', jsonResponse.event.textOutput);
      } else if (jsonResponse.event?.audioOutput) {
        this.dispatchEvent(sessionId, 'audioOutput', jsonResponse.event.audioOutput);
      }
    }
  }
}

All of this happens right away. The streamAudioChunk method in StreamSession manages a queue through audioBufferQueue, which avoids things from getting overloaded and keeps all the audio data in the right order, so conversations feel natural and smooth.

private async processAudioQueue() {
  this.isProcessingAudio = true;

  // Process chunks in the queue
  while (this.audioBufferQueue.length > 0 && this.isActive) {
    const audioChunk = this.audioBufferQueue.shift();
    if (audioChunk) {
      await this.client.streamAudioChunk(this.sessionId, audioChunk);
    }
  }
...

To make all of this work smoothly, we are using HTTP/2 to call the Amazon Bedrock. The cool thing is that, unlike HTTP, HTTP/2 lets us send multiple streams over the same connection. That is helpful to keep the audio flowing in both directions
without delays. Another nice thing is performance. it compresses headers and figures out which parts to prioritize, so everything feels quicker and more natural. Especially when there is a lot going on at once.

const nodeClientHandler = new NodeHttp2Handler({
  requestTimeout: 300000,
  sessionTimeout: 300000,
  disableConcurrentStreams: false,
  maxConcurrentStreams: 10,
});

this.bedrockRuntimeClient = new BedrockRuntimeClient({
  credentials: config.clientConfig.credentials,
  region: config.clientConfig.region || "us-east-1",
  requestHandler: nodeClientHandler
});

In a nutshell

It might look complex at first, but in a nutshell, what is happening is:

User => Server: User speaks into their microphone, and their voice travels to the server.
Server => Amazon Bedrock: The server forwards user voice to Amazon Bedrock, but doesn't wait for user to finish speaking.
Amazon Bedrock => Server: As soon as it can, Amazon Bedrock starts sending responses back to the server.
Server => User: The server immediately forwards the responses to user browser, which plays them.

This all happens in near real-time, creating a natural conversation where responses can overlap with user speaking, just like in human conversations.

New possibilities

It opens up a bunch of possibilities that used to feel super hard to achieve. Imagine calling customer support and being able to interrupt and actually fix something mid-sentence, instead of waiting for any pauses to finish. Or think about a virtual assistant joining your team meeting and just keeping up, responding like a real person instead of lagging behind.

This kind of thing could be huge for accessibility too. People with visual or motor impairments could interact with systems more easily. And in classrooms, virtual tutors could actually listen and answer questions like a real conversation. Even live translation could feel smoother, like you’re actually talking to someone, not just waiting for a machine to catch up.

Start building with AWS SDK's bidirectional streaming API, Amazon Nova Sonic and Amazon Bedrock today. Check the resources for developers to build, deploy, and scale AI-powered applications and Amazon Nova Sonic Speech-to-Speech Model Samples to learn more about how to implement it in your own applications.

As I write about these possibilities, I find myself increasingly eager to explore their practical applications. But before diving into new projects, I need to try this one more time with DR ANSMUE:

“Hey Doc, can you fall in love?” 💔

Made with ♥ from DevRel