#247 - Engenharia de software na era do piloto automático com Zarathon Viana

Hoje eu vou conversar com o Zara Tomviana, ele atuou como Senior Head de Engenharia no quinto andar. Tudo bem, Zara? Obrigado por aceitar o convite, cara. Muito legal ter você aqui de novo, né? Segunda vez que você aparece por aqui. Bom, sempre um prazer pra mim estar aqui com você, agora falando um pouquinho desse novo mundo que a gente tá indo. Cara, fico felizão, assim, a gente se conhece há muito bom tempo e, putz, é sempre bom estar aqui com vocês e com essa turma. Já me deu bons feedbacks no primeiro papo, espero que ele seja tão bom quanto.

Boa, boa. Vamos lá. Inclusive, eu vou deixar o link para o episódio que a gente... para o outro episódio que a gente gravou aqui nas notas do podcast, para quem tiver interesse e tal, pode acompanhar lá depois de terminar isso aqui. Mas antes da gente começar, de fato, assim, imagino que algumas pessoas que vão passar por aqui acabaram não ouvindo, não acompanhando no primeiro episódio que você gravou. Então, eu queria pedir para vocês apresentar um pouquinho, para a galera te conhecer.

É melhor? Boa. Bom, meu nome é Zaraton, mas quase ninguém me chama de Zaraton. Acho que...

Tudo bem. Eu sou o Zara, a pessoa me conhece mais como o Zara. Tô nessa indústria de software, tem um pouco mais de... Quando passou dos 20 anos eu parei de contar. Passei ultimamente, nos últimos anos, trabalhando nos principais unicórnios aqui no Brasil. Nesse cargo mais de gestão, de alta liderança. E agora tô me preparando pra esse novo mundo de IA, né? Sou uma pessoa que escreve muito, tô escrevendo no meu blog, depois o Matos deixa pra vocês dar uma olhadinha. Tenho uma newsletter também, o blog é meio que uma newsletter também.

tô começando a escrever o segundo livro, já tenho um primeiro livro que eu acho que é esse, acho que quem não leu ainda, fica a dica, se você quiser ser lida em tecnologia, o Matos vai deixar o link aí, e cara, trabalhei com o Matos no passado, foi super da hora, e a gente sempre tem uma dobradinha muito boa de pensar uma coisa parecida, e pensar coisa semelhante, é sempre bom estar aqui contribuindo, então, eu sou só mais uma pessoa em engenharia, falando, e gosto de falar também sobre isso.

Boa. É uma pessoa muito experiente, enfim, conhece muito da área. Inclusive, você falou do teu conteúdo que você produz ali, né? Do teu blog e tal. E foi de lá que, enfim, meio que me deu essa centelha aqui, né? Pra te convidar pra chamar pra essa conversa. Porque foi um texto muito interessante. Inclusive, eu recomendo que todo mundo que tá aqui leia. Porque é realmente muito bom, assim. Viralizou no LinkedIn e tal. Eu vou tentar dar um resumo aqui.

Você me ajuda, Zara? Se eu falar uma besteira, tá? Ajuda sim. Mas, basicamente...

Basicamente você faz ali uma comparação do que pilotos de avião passaram no passado, e como que eles vivem hoje, com justamente essa transição que a gente está fazendo agora. Então, enquanto pilotos de avião hoje, eles acabam usando muito o piloto automático, quando estão voando e tal, a gente está começando a se acostumar a viver essa vida agora. Então a gente está na transição ali e tal, e tem muitas analogias que a gente consegue fazer, né?

olhando ali de como que as coisas aconteceram na área da aviação, para que talvez a gente consiga fazer algumas previsões, inclusive, na área de tecnologia. Então, acho que o grande resumo é esse, se faltou alguma coisa. Bom, que legal. Mas é isso. Quando começou, eu gosto muito de analisar outras áreas, outras disciplinas, outros negócios que passaram por momentos semelhantes a esse nosso.

E aí, eu uso muito IA, tá? Eu uso IA para quase tudo na minha vida. E eu uso muito Perplexity. Para quem não sabe, Perplexity é um tooling que ajuda você a fazer buscas de fontes fidedignas e tal. Eu sempre me questionei, putz, que outras indústrias passaram por esse momento de automatização? Exagerado, porque eu acho que no fim do dia, quando a gente fala de IA para coding...

a gente está falando de um exagero, de um over, né? Exagero não no sentido ruim, mas no sentido de, putz, é tudo, está mudando muito rápido, exageradamente rápido, e a gente precisa se adaptar. Que dúvidas se passaram por isso, né? E aí veio a contabilidade com as calculadoras financeiras, veio o las tudo. Mas a ideia mais legal que me pareceu foi, os pilotos de avião sofreram isso na década de 80. Eu falei, putz, acho que aqui tem mais match do que a matemática.

Acho que a gente pode ir para a matemática também, de certa forma, por exemplo, fazer derivada na mão, a gente consegue.

Mas você pode usar uma calculadora científica e vai ser muito mais rápido. No fim do dia, a gente está numa coisa muito semelhante também. A gente sabe fazer código, mas se a gente usar o IA, vai ser muito mais rápido. Mas quando você olha do ponto de vista de...

do sócio, do emocional, os pilotos naquela época tinham muito mais estudos, e aí foi por isso que eu escolhi, porque tinha muitos mais estudos sérios sobre como as pessoas se sentiram, como é que foi a adoção, o lance da atenção, e aí não a atenção da LLM, não a atenção, mas a atenção que a gente tem que ter com o código versus o que é gerado, versus automações, porque quanto mais automações, mais preguiçoso nosso cérebro fica e aí ele baixa a guarda.

Então, assim, a gente tende a baixar a guarda porque a gente está confiando. Então, quando a gente confia, a gente vai abaixo das nossas guardas. Então, putz, deixa eu entender um pouco como é que essa galera passou por isso e como é que a gente deveria se preparar, então, o que a gente pode aprender com a indústria da aviação que passou por isso na década de 80 e trazer para agora nesse novo mundo, né? Formação de novos pilotos, tem toda uma questão de, tipo, caixa preta, cara, tem muita coisa que a gente pode desembrulhar aqui ao longo desse episódio para falar sobre isso, tá?

Boa. E, sim, baseado nessa analogia que você fez, ou talvez não, talvez até alguma previsão, algo que você olha aí para frente e já está vendo chegando, tem alguma coisa que você consegue enxergar que engenheiros devem começar a encarar num futuro próximo, que talvez hoje eles não estão tão atentos assim, ou talvez até eles venham a ser resistentes em algum momento? Tem, tem, tem, tem. Eu acho que, assim, primeiro não tem rollback, né? Aí ela chega como uma ferramenta tão forte quanto...

Foram as primeiras... Eu acho que o paradigma é muito parecido com mudar a matéria do trabalho, a matéria-prima. Então a gente para de falar mais em código. Eu acho que a gente vai para um outro lugar agora, que talvez seja design de software, que está mais ligado a um nível acima.

Então, para estar a um nível assim, você precisa falar a língua do negócio. Então, hoje, quem é dev, que claramente é só um coder, só um codificador, um mero programador, esse cara vai ter que cada vez mais se aproximar de negócio, para entender o domínio. Então, eu defendo muito que, no fim do dia, o cara vai precisar dominar muito mais sobre DDD e mapear, eu digo que é mapear o mundo real para o mundo virtual através de software.

do que ele saber como é que faz um infiel, você esquece, você acha que isso aí já está dado, a gente não precisa mais nascer com isso. E uma vez que ele tem esse conhecimento do domínio do mundo real, fazer design de software, entender sobre design de software também vai ser tão importante quanto. Acho que tem dois livros que eu sempre falei sobre isso, ultimamente, que é... Essas duas explícitas, eu acho que os novos engenheiros, ou quem não domina ainda, vai ter que masterizar o mais rápido possível, que é Domain Driven Design,

e software design. Acho que essas duas são as duas principais skills que eu acho que quem já está mais afiado, ou seja, quem está mais velho de guerra, quem mais sênior, que consegue já conversar com o negócio, já consegue ser mais produtivo, e quem não, acho que tem que correr atrás disso o quanto antes.

O que faz sentido, porque isso já eram assuntos que a gente já olhava, mas talvez até, eu não sei se por uma pressão por entrega, por velocidade e tal, talvez a gente não desse tanta atenção quanto talvez a gente vai passar da agora, que a gente, entre aspas, ganhou mais tempo para conseguir fazer essas entregas, dado que é parte do código, enfim, a gente não necessariamente precisa escrever mais.

Sim, não, super de acordo, acho que é isso. Acho que a gente não fazia por não ter tempo, tá? E a pressão é essa, cara. Cadê a feature rodando? E aí, de novo, a feature rodando ela implica em você não pensar muito no negócio, em você não se envolver muito, em você não conseguir fazer um...

Um design muito bem do mundo real, porque você tem que chipar o código. E aí isso acarreta em problemas de observabilidade, porque você deprecou, porque você comprou o débito técnico para poder ir mais rápido, você comprou...

o débito de design também, da solução. Às vezes você, tipo, ah, não, mas já tem essa classe, acopla nela também, bota ali, estende ela mais um pouquinho, e aí você tem aquele, eu digo que é o início do Big Ball of Mud, né? É o comecinho, o próprio Kate Beck falava foi isso do Tide First, né? Puts, você deveria fazer isso primeiro, mas não dá, porque tem a pressão do negócio. Então, todos esses problemas que a gente tinha como idealização do software perfeito,

Agora eu acho que a gente não tem mais essa desculpa, tá? Acho que a gente vai cada vez mais agora focar mais em entender os negócios e resolver os problemas do mundo real, agora de fato com o software. Acho que a gente passou por um momento que ele foi de desenrolar algumas coisas. A gente nunca fez o software...

como deveria ter sido feito, tá? Acho que a gente sempre fez o que dava. É o Just Enough. Just Enough Architecture. Você pode até procurar, tem livro sobre isso, mas eu acho que é isso. Então, hoje eu acho que não. Acho que hoje cada vez mais vai ser exigido você fazer software que envelheçam bem, que resolvam problemas do mundo real. De novo, eu advogo muito sobre o Build to Learn e o Build to Learn. Eu acho que a gente já falou isso no episódio passado, mas eu acho que agora você fica muito mais próximo de escrever o código final upfront, já sabe, de primeira.

Tem outros problemas? Tem. Que é o quê? A gente precisa entender aqui o conceito de Greenfield e Brownfield, né? O Greenfield é, putz, fazer coisa nova. E eu acho que se você faz coisa nova e faz cagada, desculpa, você tem que rever os seus conceitos. Você não precisa mais fazer isso. E tem o Brownfield, que eu acho que é 95% da indústria que são códigos legados. E muito provavelmente esse código não está pronto para ganhar, tá?

E aí é que tá. A gente vai passar por um momento que eu chamo de fase de setup. A gente vai ter que fazer um setup do código que a gente tem rodando hoje pra que ele seja AI ready. Sabe, sim. Pronto pra quem é um AI chegue e consiga entender, ser mais assertivo e tudo mais. Eu tenho feito vários experimentos sobre isso e a gente pode falar sobre isso também.

Um dos pontos que você mencionou foi sobre não ter mais holdback. Mas eu queria entender um pouquinho a tua visão no seguinte. A gente vê as empresas que estão provendo esses modelos mais famosos, pelo menos e tal, elas estão subsidiando muito o custo. Então, custa relativamente barato para a gente usar. Apesar de ser caro, mas ainda assim é relativamente barato.

E como é que fica essa questão? Como é que você imagina que vai ficar essa questão de custo quando elas pararem de subsidiar tanto? Ou será que vão continuar subsidiando? Ou será que elas vão conseguir reduzir muito o custo? O que você acha que deve acontecer aí no futuro, sei lá, de um ano, dois anos? Vou jogar o futuro de cinco anos, dez anos, aí depois a gente vem de frente para trás. No futuro, para mim, eu acho que a gente vai ser multi-agente, multi-modelo.

que a gente vai parar de falar de LLM, como Large Language Model, e a gente vai entrar no que eu chamo de SLM, que são Specific Language Models. Esses Specific Language Models, ou Small Language Models, você pode pensar assim também, eles vão ser pequenos o suficiente para rodar na sua máquina. Então, eu acho que cada empresa vai estar apta o suficiente para criar seus próprios SLMs e distribuir internamente. Lógico, isso vai derivar talvez de uma...

Language Model superior, ou de, sei lá, e aí pode ser uma comprada por alguém. Eu já comecei a fazer alguns experimentos nessa linha também, de criar, por exemplo, um específico Language Model pra tatar de códigos Go.

Então ele pega toda a essência do Gol, ele faz um fine tune em cima do Kimi K2.5, eu fiz em cima disso, e ele gera um código já que foi fine tunado para aquilo. E é uma específica language model de 200 megabytes. Você bota para rodar ali, roda fino. Consegui alguns resultados legais, outros nem tanto, então preciso talvez refinar e voltar para... Mas eu acho que a gente vai chegar nesse lugar em algum momento por questões econômicas. E é isso que você falou. Hoje a gente está subsidiado no...

médio prazo, 1, 2 anos, eu acho que a gente vai começar a adotar mais modelos híbridos entre o alto nível e o nível caro de LLMs e LLMs mais open source, que você consegue pagar a infra e rodar ela. Hoje a gente tem como exemplo o Quimica 2.6, a gente tem o DeepSync que saiu agora há pouco, o V4, a gente tem o Quen 3.6. Cara, eu já fiz testes, já fiz benchmarks aqui em mil internos, pedi a mesma tarefa.

e eu faço isso com software, eu pego um desafio que eu tenho, uma tese que eu pego, uma tese que eu pego, uma tese que eu pego do time, que é meio crítico e tal, eu faço ela com o Kimi K2.6, o mesmo prompt, tá? Faço com o Quen, e faço com o Deep Seek. E eu comparo os resultados, e comparo o resultado, por exemplo, com o Soné 4.6, é muito parecido. Então, assim, não tem por que eu gastar cinco vezes mais com o Soné e maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior maior

Você pode usar um quinto desse valor pagando o Kimi, por exemplo.

Então, assim, eu já começo a experimentar esse mundo multimodelos, onde, putz, para determinadas esquias, para determinados agentes, eu uso um modelo mais simples. Para um outro que é mais complexo, que exige um raciocínio mais profundo, e para o raciocínio eu posso plugar esses mais caros, tipo um Gemini 3 Pro, Finkin, o Alpus 4.7 High, o X High, se for o caso, sabe?

acho que o futuro vai ser muito nessa linha, entre saber navegar nesse fluxo de custo, porque, putz...

Eu acho que vai ficar pelo menos uns 10 vezes mais caro do que é hoje. Não tem como, assim, do ponto de vista econômico, para essa galera manter esse nível. Mas eu acho que vai começar a surgir essa outra maçaroca de serviços oferecendo esses modelos open source, que, na minha concepção, e aí de novo a Elzara falando, eu acho que são destilados desses modelos grandes, tá? A galera na Rádio está fazendo isso porque a legislação permite. Então, tudo bem.

E talvez a gente chegue até num nível de... Como talvez esses modelos open source, eles já devem ser bons o suficiente, então tudo bem a gente usar eles por, sei lá, seis meses aqui, enquanto a gente espera sair uma versão nova que é mais potente. A gente não precisa necessariamente correr para pegar mais novo. Exato, exato, cara. Eu tenho me acostumado muito a... O que é que eu tenho no meu workflow? Tudo que é muito thinking, eu uso o Opus, e tudo que é muito implementation, eu tenho usado o Kimi.

Então, assim, é isso. Então, assim, eu discuto muito com o Opus a questão... E aí a gente pode entrar nisso, quais workflows eu acho que estão funcionando, estão se consolidando, né? Eu discuto muito com o Opus as interfaces, o design da solução, mas a implementação eu nem olho mais. Eu deixo para o Kim implementar só o que for de implementar. Então, tá? Depois que eu bato o design com o Opus, a implementação é dois palitos, assim.

E é, de fato, onde você queima mais token, né? Porque você vai escrever o código em si.

E geralmente tem bastante output também, então ele vai consumir um pouco. Cara, consumir um toque em uma boada, sim. Você comenta lá na sua postagem sobre a importância ali da gente ganhar essas horas de voo, da parte prática ali, da gente botar a mão na massa também, para a gente não perder muito contexto de como se faz as coisas e tal. Mas eu queria entender...

Como assim, pensando já num cenário onde a gente já não escreve código ou escreve pouquíssimo código. Já nesse cenário que já é um cenário atual, inclusive. Então, nesse cenário, como que a gente faz pra não perder o contexto do que tá sendo feito, pra que quando eventualmente a gente tem um problema em produção a gente consiga atuar e entender o que a gente precisa fazer pra resolver um problema. Quando a gente põe a mão no código, a gente já sabe mais ou menos até onde tá.

Mas se a gente não escrever, fica um pouco mais difícil. Então, como é que a gente faz nesse cenário?

O que eu tenho feito muito aqui foi... A cada vez que eu fecho um design nessa interação, eu crio um ADR, tá? Então, tudo gera um ADR. E essa ADR, ela vai para uma base de conhecimento que depois, quando eu quiser, quando eu estiver num...

num debugging, por exemplo, eu posso conversar com a LLM que me suporta para me dizer, putz, foi esse dia, nessa PR, nessa feature aqui, aconteceu isso, a gente decidiu isso. Cara, isso é muito perto do instantâneo, tá? Porque, de novo, é basicamente texto, você consulta texto hoje de uma maneira muito fácil. Mas do ponto de vista prático para a gente que é engenheiro, eu acho que, de novo, eu sempre volto para menos base do tipo...

faça alguma coisa craft, assim, na mão mesmo, na munheca. Então, usa menos IA para uns projetivos mais simples. Para você entender onde estão as coisas. Eu acho que no novo mundo que a gente está indo, ele vai ser totalmente assistido por IA, tá? De novo, é esse lance de consultar os ADRs. Talvez você... Hoje eu já vejo muita empresa fazendo isso, de utilizar estratégias de MCPs para observabilidade. Então, o teu MCP já pluga lá no teu questão de log, já pluga na questão do...

dos grafanos, data dog, new relic da vida, então você com poucos pedidos, a LLM sabe onde consultar, quem consultar e te dá um panorama, acho que foi esse dia, essa hora, o problema está aqui, eu peguei o tracing aqui, sabe, o Marti fala, chama isso de sensores.

Tem até um artigo que eu escrevi, não sei se você chegou a ler, que são as três camadas de AI coding. E aí eu falo muito disso, de sensores e guias. Então esse lance dos sensores, tudo isso vai estar automatizado. Assim como foi na aviação. Então antigamente você ia pegar um avião na década de 70, provavelmente ele tem bem menos instrumentos do que o de hoje em dia. Se você vê aquelas fotos que tem 50 botõezinhos, sensores, não sei o que.

Então, assim, cada vez mais a gente vai para esse mundo mais estruturado para que você saiba só utilizar. Você tem que entender o conceito. E eu acho que a prática desse conceito é muito importante. Tanto que quando o pessoal faz o... Lando na aviação faz o teste, faz as aulinhas de brevê, né? Assim, para tirar carteira de piloto. Eles não pilotam num avião muito instrumentalizado. É no menos instrumentalizado. Acho que a gente também tem que ter essa prática de...

Navegar em software menos instrumentalizados, vamos dizer, como os antigos faziam, para ter essa noção de, beleza, para onde é que eu vou? Qual a minha mentalidade de engenheiro, de escavucar? A gente, por exemplo, eu, você, a gente não é uma geração que escovou o beat.

Salva raríssimas exceções. Eu tive um caso, dois casos na minha vida só que eu pensei em escovar bits. Mas via de regra, putz, a gente não precisou escovar bits. Mas na década, provavelmente a galera que fez videogame na década de 80, que fez os primeiros cartuchos lá do Atari, teve que fazer isso.

daily base, assim. Era o cotidiano dos caras. A galera de cartão perforado pior ainda, quer mexer com registro, assim. Então, vê, a gente vai melhorando a nossa camada de... o quão baixo nível a gente chega, né? Provavelmente, o novo mundo, ele não vai chegar mais nesse nível de, putz, eu tenho que abrir um sistema pra ver um log. Eu tenho que entrar no Kubernetes pra ver um log. Como assim? Cara, eu tenho que pedir aqui no meu oráculo de...

E a SRE, ele vai me responder. Entendeu? A gente tá mudando o paradigma. Aí, de novo, quem é velha guarda como a gente, nunca vai deixar de fazer código na munheca. Mas pode ser que a nova geração olha pra gente e diz, caralho, isso é muito antigo. Por que vocês fazem isso?

Aí a gente vai parecer cringe, né? E você falou um negócio que eu achei bem interessante, né? Que você comentou aí, acho que foi o Martin Fowler, né? Que postou sobre a questão até do que a gente vai monitorar e tal. Eu pensei em outra analogia aqui, que é a seguinte.

Para você criar um circuito eletrônico complexo, é bem provável que você vai precisar de um engenheiro para poder projetar aquilo e tal, garantir que está tudo certinho. Mas para consertar, talvez um técnico de eletrônica consiga. Ele saiba ali onde estão os componentes e tal, vai testando, põe lá a provinha de carga, que não sei o quê. Ah, não, aqui não está passando corrente. Beleza, então tem que consertar isso aqui. Tem que tirar esse componente e botar um novo. É isso, são seis pontos. Talvez a gente chegue nesse nível.

A gente vai chegar nesse nível. A gente vai ser basicamente esse operador, tá? A gente é esse operador. A gente coloca... Esses dias eu estava fazendo a aplicação com a galera aqui, meio que fazendo uma live, e, putz, estava muito difícil. Eu senti que o negócio bateu cabeça muito. Eu estava, tipo, na vibe de utilizar o máximo dia possível, não encostar a mão em código, tá? E aí eu senti que ele perdeu muito o feeling da coisa e estava tentando resolver de duas, três maneiras diferentes.

Eu falei, cara, não vai dar certo. Falei, ó, vamos instrumentalizar tudo com log.

E, cara, na primeira vez que ele tentou, o erro está aqui. Ele já corrige muito rápido. Então, assim, esses sensores, esses breadcrumbs, os migalhinhos de pão, que a gente vai ter que deixar, vai ser ótimo de fazer isso agora. De novo, não tem mais por que não colocar...

Log, não tem mais por que colocar um trace, não. Cara, isso não leva mais tempo. Antigamente a gente passava um dia fazendo só isso. Você lembra? Não sei se... Cara, quantas vezes a gente não teve que parar um dia? Não, agora eu vou... Esse é... Tinha um subtest que era adicionar logs. E essa subtest que demorava um dia pra ser implementado. Agora, você já passa com um default do negócio. Ele já instrumentaliza. Tipo, putz, você pode subir coisa, descer coisa muito rápido. Ficou barato, o código ficou barato.

Ou até aquela técnica bem antiga, mas eu já usei e funciona assim, que é o debugging brute force, que você vai comentando o código e vê em que ponto que ele... Passou por aqui, passou por aqui dois, passou por aqui três. É isso, mas é isso.

E até nesse ponto, o que me lembra aqui é que o próprio controle de qualidade como um todo deve mudar. Disso de a gente talvez olhar muito para o baixíssimo nível e talvez olhar para coisas mais alto nível. Obviamente, monitoramento em produção, testes mais alto nível, enfim. Eu não sei até que ponto isso vai mudar, mas alguma coisa ali é provável que a gente olhe muito mais, com muito mais carinho para a parte de testes e observabilidade, monitoramento, do que a gente olha até para código que está sendo produzido.

Withقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقطقط

Exato. Não, eu tô contigo. Eu acho que hoje TDD vira regra, tá? Muito por uma questão de... Pra mim, TDD hoje é muito mais sobre passar um cercado...

para dizer, é esses critérios que você tem que me atender. O AI é muito bom em gerar código. Se é bom ou se é ruim, aí isso é uma questão que... Quando você passa o teste, no fim do dia, no teu processo, o teste diz, é esses critérios que eu aceito que você me ajude a criar dentro desse cercadinho. Então, assim, o teste nada mais é do que... E aí, de novo, a gente pode chamar isso de Harness, Harness Engineering, é outro processo que é...

existe uma camada de software, que é o que eu escrevo no meu artigo, que todo engenheiro precisa masterizar para poder garantir que a IA está controlada dentro do teu contexto do que você quer resolver. E teste, para mim, é a base dessa conversa. De novo, isso implica em quê? Software de muito mais qualidade, software muito mais previsível. Para mim, um codebase que é facilmente testável é um codebase fácil de alterar. É um codebase saudável.

Então, de novo, isso não é a realidade hoje no mercado, tá? Quando a gente pensa em Brownfield, em código legado, 90% não está pronto para AI. Então, provavelmente, o primeiro trabalho de estruturar toda essa camada de QA, vamos chamar assim de QA, porque você vai ter que colocar teste, você vai ter que colocar, talvez, teste mutante para poder identificar, teste que você nem sabe que precisa ainda.

Tem toda uma camada de identificar as fronteiras do negócio. O quanto está corrompido o teu software, o quanto macarrônico é o seu software, ou o quanto bem separado ele está. Tem um livro muito bom que se chama Filosofia dos Design Soft, eu acho. Deixa eu ver se eu tenho ele aqui em algum canto. Acho que é o Filosofia Design, não é esse? É, eu acho que eu tenho ele aqui. Tá, tem ele aqui. É esse mocinho aqui.

Quem não leu ainda, ó. Depois eu vou deixar uma lista de livros que eu tô lendo. Esse aqui, pra mim, eu acho que é a base do conhecimento também, tá? Porque ele te ajuda muito a pensar de uma maneira estruturada, tá? E olha, putz, meu software tá nessa maneira ou não tá? Tem um cara que eu tô fazendo uma mentoreia com ele. Chama Matt Pocock. Não sei se você chegou a ver alguma coisa dele. Ele tem canal no YouTube. Tá, cara, maravilhoso.

Bom de cabeça, assim. Eu acho que a gente tá... Eu tava chegando no mesmo lugar que ele chegou e a gente tem trocado muita figurinha nesse lugar.

Ele recentemente fez um talk no AI Engineering Europa, coisa assim. Cara, maravilhoso. E ele coda, ele mostra o processo dele. Então, depois eu te passo o link pra você ensinar aqui pro pessoal dar uma olhada também. E ele parte muito desse princípio de, putz, fazer o harness com TDD, com teste, pra garantir que vai ficar bem escopado o negócio, tá?

Eu acho que qualidade, ela ganha por efeito colateral, não por intenção. Se a gente fosse falar de intenção, a gente ia para um outro lugar. Eu acho que intenção é um pouco mais... Mas eu acho que ela ganha por efeito colateral.

E um dos pontos que você toca também na tua postagem é sobre os novos engenheiros, como é que a gente faz para formar novos engenheiros e tal. Eu queria entender um pouquinho, até do que você tem visto aí no mercado como um todo, o que precisaria talvez mudar na formação dos engenheiros atuais para eles se adaptarem da melhor forma possível. A um mundo a gente usa mais IA de forma mais frequente. Então, será que é não usar IA no começo? Enfim, é limitar o uso? Até que ponto eles vão usar IA?

De novo, vamos voltar para a aviação, né? Cara, é voar com um avião com menos instrumentos, ou o básico dos instrumentos, tá? Por um período, assim. Pô, aprender a fazer um SaaS, eu sempre dou o exemplo do SaaS, né? Mas, assim, pensa que você vai colocar algo em produção que você tem que aprender a monitorar, que você tem que aprender a observar, que você tem que aprender a fazer um rollout, fazer um deploy, cuida da qualidade, tudo na mão.

Assim como na matemática, eu fiz contabilidade. Minha graduação foi contabilidade. Assim como na contabilidade, você aprende a fazer tudo na munheca. Papel e caneta. Fazer todos os carros. Aí depois o professor disse assim, ó. Agora você pode usar calculadora financeira. A vida muda. Daqui a pouco, agora você pode usar o Excel. A vida melhora mais ainda. Então assim, mas vê, a minha base de contabilidade não perco.

Eu só sei como pegar a minha base que eu tenho sólida e agora ser mais rápido com ela. A nova geração tem que ir exatamente nesse lugar de ter uma base sólida, mas saber que IA joga ela muito mais rápido para frente. A IA, ela catalisa o output. Ela acelera o output. Então, quem não tem base, vai acelerar o output. Eu garanto que para quem não tem base, esse output é ruim.

então assim, você vai colocar merda mais rápido na produção agora pra quem tem base pra quem tem repertório, tipo eu e você a gente tem repertório de anos dessa indústria e eu que estou observando isso as pessoas que são, que tem mais repertório que tem muito mais rodagem estão adorando, vibrando dando mortal de costa com esse negócio de acordar a galera mais nova, que não tem tanto essa essa

esse repertório, vamos chamar de repertório, não tentando esse repertório, precisa criar esse repertório primeiro.

Então, eu acho que a gente terei que revisitar ou pensar na forma nova de formar essa nova geração, tá? E aí, para mim, eu acho que a analogia do ter horas de voo, para mim, se aplica muito aqui. De que, sei lá, a gente tem hoje a Lura, que é uma grande exponencial aqui de educação no Brasil. A gente tem outras grandes players que fazem educação, né? Tem o pessoal do Foo Cycle. Tem uma turma aqui.

trabalha com uma situação de formação de base muito forte, esses caras deveriam muito adotar o que eu chamo de Problem Based Learning. É pegar um problema, dar na mão desse cara e deixar ele resolver na munheca. Nada de IA. Aí depois você pode vir em outra fase do curso, dizendo, ó, agora vamos pegar o mesmo problema e resolver com IA, para ver como a gente resolve muito mais rápido, de maneira muito assertiva. Mas que a pessoa entenda que alguns conceitos mais sólidos

como observabilidade, como design software, como DDD, isso não vai mudar. A base não muda. A base nunca vai mudar, principalmente nesse cenário. Mas o Ways of Work muda. A maneira como você trabalha muda.

E eu lembro até de recentemente estar conversando com um engenheiro júnior, ele comentou comigo, né, assim, cara, falando para mim, né, eu não estou mais usando o IA porque eu cheguei num ponto de eu já não estar mais entendendo o que eu estava fazendo, então eu precisei parar de usar para, enfim, saber de fato o que estava acontecendo ali em cada momento e tal, e faz algum sentido, assim, acho que...

Por um lado, talvez ele estivesse sendo bem menos produtivo, mas por outro, ele estava também se desenvolvendo. Então, conseguir equilibrar isso da melhor forma possível, ou talvez até criar momentos, igual você comenta na postagem, para que a pessoa intencionalmente exercite o ato de estar criando alguma coisa manualmente. Para mim, eu gosto muito do lance do... Eu sou uma pessoa muito social, então...

Principalmente no trabalho. Tem que fazer um per-programa entre alguém super sênior e alguém muito novo. Esses caras têm que ser buddies por um período de tempo grande agora. Onde o sênior ensina o Júnior a fazer na munheca e depois ensina ele como ele pode fazer a mesma coisa e punhar. E repete o processo...

10, 20, 15 vezes, se for o caso. Cara, tem que fazer muito para o moleque pegar esse repertório. Eu acho que o loop de criar esse repertório vai ser muito mais rápido do que foi na nossa época. Isso é um fato. Então, a habilidade de aprender rápido vai ser agora mais exigida ainda. E aí, a questão é...

como é que essas pessoas não vão fritar nesse processo? E aí tem questões agora gerenciais, né? Do ponto de vista de como é que eu protejo a cabeça desse cara que quer aprender rápido, quer aprender muito, mas eu também sei que se eu der muito agora, eu vou fritar esse cara. Então, você fica nessa tipo, eu quero que ele faça, eu quero que ele não faça. Então, aí de novo, eu acho que quando esse movimento vai chegar na camada de gestão. E aí são outros desafios aqui na camada de gestão, pra gente lidar.

E nesse cenário também, onde a gente tem um uso mais massivo de AI e tal, e tem engenheiros, talvez alguns vão ter mais horas de voo do que outros, ou alguns vão ter mais horas de voo manual do que outros, enfim. O que você vê mudando, por exemplo, na avaliação de desempenho dos engenheiros? Como é que a gente vai saber, de fato, quem que está indo bem, quem que não está indo bem? Enfim, como é que a gente consegue diferenciar um do outro?

Engenheiro sempre foi medido por impacto. Impacto, entrega... Eu acho que isso não muda, eu acho que vai continuar mesmo. Só que agora a gente vai para um novo patamar, que é o volume desse negócio. Provavelmente a gente vai ter engenheiros que vão shipar muito mais coisa para a produção. E aí eu acho que querendo ou não, vai dar uma nivelada em todo mundo. Vai ter um cara que vai destoar, o cara que pegou o macete, esse cara tem next engineer, a utopia é o unicórnio. Tudo bem, mérito dele.

Mas eu acho que a gente vai começar a avaliar agora os engenheiros, principalmente na base, sobre o quanto que esse cara se envolve com o negócio. Agora eu digo que é a hora que as soft skills vão contar mais. Como é que esse cara é colaborativo? Como é que esse cara demonstra curiosidade? Como é que esse cara suporta outra pessoa? Como é que esse cara reage a um incidente? Esse tipo de coisa que a gente contava com peso menos do que a entrega, eu acho que isso agora começa a contar tanto quanto ou até mais.

Então, assim, eu acho que a gente vai para uma realidade de times menores, mas são de pessoas altamente colaborativas, curiosas, que trocam, se suportam e estão envolvidos com o negócio, conversam com o negócio de uma maneira rápida, fácil, a comunicação é assertiva, sabe? Eu acho que a gente está indo. E esses esquivos vão ser os esquivos mais desejados no déficit do futuro. O déficit do presente, velho.

É, já é importante, talvez se torne ainda mais importante. Até porque, e faz muito sentido o que você falou, porque assim, se o engenheiro não consegue entender o que ele precisa fazer, ou ele vai fazer errado, ou vai ter que ficar voltando toda hora para entender o problema, ele vai perder tempo no meio do caminho e naturalmente isso vai afetar as entregas também. Então, de alguma forma, a gente vai conseguir ver uma diferença no resultado na ponta, de um engenheiro que consegue fazer entregas consistentes, que resolvem o problema, pelo menos...

Resolve aquilo que se propõe a resolver de outros que talvez, enfim, fiquem indo e voltando, enfim, não resolvam o problema certo. Perfeito, é isso, é isso. Acho que a gente está indo para exatamente esse lugar, tá?

Você acredita que deve surgir alguma prática semelhante ao que surgiu lá na aviação? Por exemplo, checklist, simulação. Vamos pensar, sei lá, numa simulação antes do código entrar em produção e tal. Você vê alguma prática nova surgindo aí por conta até da mudança do fluxo de trabalho dos engenheiros? Tem alguns que eu já comecei a observar que eu estou notando aqui. Eu falei, putz, isso aqui é maravilhoso. Por exemplo, quando acontece um problema na aviação, o avião cai e tudo mais, Tem um...

puta post-morte, né? Os caras puxam a caixa preta, os caras vão olhar o que aconteceu, tem todo um esmero em investigar. Por quê? Porque aquilo volta como uma melhoria pra todo o setor. Né? Esse mesmo padrão, eu já vejo e eu já começo a implementar aqui com meus agentes, que são quando uma coisa não dá bom, quando...

Eu faço assim, todo sábado eu tenho uma rotina aqui no meu Cloud Code que ele roda, ele pega todas as sessões que eu iniciei durante a semana, pega todas as lições aprendidas e refatora o meu set de skills. Adicionando coisa nova, sabe? Melhorando um skill ou outra, trazendo, ah, putz, você fez isso aqui, mas eu não quero que você faça mais, porque o Zara já falou na sessão tal que isso não é legal. Sabe, ele... Lembra do conceito do Kaizen, lá da Toyota, da melhora contínua e tal? Cara, eu estou usando hoje com...

com os meus agentes aqui. Então, assim, eu tenho uma rotina de Kaizen automatizada até. Então, assim, e a coisa da caixa preta, né, tio? Deu merda. Daqui a pouco a gente vai fazer isso em uma escala maior. Tipo, a empresa, a empresa vai pegar os post-mortem do que aconteceu e vai retroalimentar as suas skills próprias, o seu code base, os seus code guidelines e tudo mais. Então, assim, a gente volta no momento de Kaizen também, tá? Agora, provavelmente, tudo mais automatizado.

Quando a gente pensa em post-mortem tradicional, vamos chamar assim, na área de tecnologia, a gente tem ali talvez o time produza o post-mortem e tal, ele às vezes divulga para a empresa como um todo, às vezes não e fica a cargo de cada equipe entender se, enfim, aquilo faz sentido para o próprio projeto, talvez uma nova entrega lembrada, aquilo que aconteceu e tal.

Mas agora, se a gente consegue jogar isso para uma IA, nada impede de, sei lá, um pensamento de cenário simples aqui. Tem uma IA que faz uma revisão só olhando para post-mortem para ver se o código que você abriu lá para revisão não está implementando alguma coisa que pode gerar aquele mesmo problema. É isso, é isso. É exatamente isso, Mestre. E eu vou além. Você falou um pouco de qualidade. Eu acho que a gente pode exercitar, e isso é pouco utilizado no Brasil, eu vi algumas empresas fazendo outras não, que é o cenário de pré-mortem.

Dado que eu estou colocando uma coisa no ar, eu estou fazendo um feature novo, cara, quais são os cenários de pré-morte que eu devo ficar atento? E aí esse negócio pode ajudar a criar os testes da aplicação quando você colocou no ar. E vê, se você usar essa prática, aí eu acho que quando você começa a ser intencional na qualidade, né? Então a gente falou de efeitos colaterais. Eu estou falando agora de ser intencional e proativo.

Se você tem uma prática dessa, se você tem um toolset muito bem elaborado para fazer esses testes up front, você pode subir seu software produção, usar um canário de 1%, ou um canário com uma flag, joga esse fluxo, esses pré-mortem, os casos de pré-mortem, para passar para esse canário, e você vai ter up front o comportamento da massa toda. Bom, beleza, beija-me-voi, qualidade agora intencional e sendo melhorada a cada deploy.

E você pode automatizar isso. Olha que maravilha. Olha que mundo legal que a gente está indo. É, excelente. Acho que tem muitas possibilidades aí. Acho que cada empresa tem feito um negócio um pouco diferente ali. A gente vai aprendendo muito também ao longo do caminho com esses cases. E...

Uma coisa que tem tomado parte do que eu tenho pensado ultimamente é sobre o processo seletivo. Então, o que a gente fazia antigamente? A gente mandava um trabalho, algum projeto para a pessoa fazer em casa, ou então ela participava de uma entrevista de algoritmo, ou de system design, enfim. Continua sendo bastante comum, pelo menos a de system design, continua sendo bastante comum. Eu acho que é até importante ela.

mas aí o que eu reparei é que mais recentemente, sim vou voltar alguns anos, alguns poucos anos coisa de 4 anos atrás mais ou menos, eu lembro que quando a gente mandava isso na empresa que eu trabalhava pelo menos quando a gente mandava um desafio pra pessoa fazer em casa assim, 80% das pessoas não faziam o desafio e ficava por isso mesmo elas saiam do processo seletivo, beleza aí mais recentemente conforme a gente tava mandando desafio e aí e aí

assim, magicamente, todo mundo mandava o que seria a resolução do... O que aconteceu nesse meio tempo? Basicamente, as pessoas estavam usando IA ali para resolver, se não, todo mundo, pelo menos boa parte das pessoas, estavam usando IA. Então, se a gente queria ver como que a pessoa resolvia o projeto, talvez um desafio para casa já não faça mais sentido, tanto sentido quanto fazia antes.

E tem outras coisas, até algoritmo. Será que a pessoa hoje precisa ser muito boa em algoritmo ou vai ser só algo para ver se a pessoa estudou, se ela é capaz de aprender alguma coisa e tal, para ver se ela desenrola sozinha? Então, eu tenho muitas dúvidas ainda de como vai ser o processo seletivo daqui a um ano, daqui a dois anos, quando o IA já se tornar algo que vai fazer parte do dia a dia de 100% dos engenheiros.

Eu queria entender um pouquinho como você enxerga isso também, essa questão até das horas de voo e tal, mas como que isso se encaixa nesse meio? Como é que o processo seletivo deve mudar, se é que ele vai mudar muito nos próximos meses e anos? Eu acho que ele muda. Assim como a gente não pede mais para ninguém esclavar a bit no processo seletivo, que provavelmente já acontecia no passado, agora a gente não vai precisar menos ainda.

E eu acho que a gente cria uma camada assim, mas a gente começa muito mais a identificar.

padrões criativos de resolver problemas. E eu acho que o processo muda muito mais para uma linha mais prática. Tipo, tem um problema, o cara vai abrir um codebase cagado e vai dizer, ó, está aqui a IA que precisa utilizar. Como é que você resolve esse problema? Ou, tipo, esse software tem um problema, descobre quais os problemas que esse software tem. E aí você vai deixar na mão do candidato.

Cavucar, de uma maneira criativa. E você vai entender o quão criativo esse cara é, por onde ele foi, se ele seguiu um padrão habitual, se ele foi fora da casinha, se ele fez uma coisa nada a ver com nada. Se você sabe os conceitos, lembre-se, se você tem uma base sólida, utilizar e ir para investigar um problema é dois palitos. Agora, se você não tem, putz, você vai rodar muito.

E vai ficar claro, assim, quem tem uma base sólida e quem não tem quando você chegar nesses cenários, tá? Acho que cada vez mais, e aí a gente vai falar de LLM, LLM é muito sobre comunicação, né? É muito pedido. Eu peço algo e eu recebo algo de volta. Então a habilidade de se expressar vai ser cada vez mais exigida.

A habilidade de se comunicar, ser direto, tirar ambiguidades da fala, a coisa do harness, como é que você cria um harness na comunicação também. Eu acho que harness não é só tooling, harness também é comunicação. Isso também vai ter que ser exigido de alguma maneira. Eu acho que é critério de avaliação também. Agora, como é que esse cara é token efficient? Porque token é caro.

Então, se esse cara não consegue se comunicar bem, ser direto, ele pode perder muito tempo nesse ping-pong que vai ser live, por exemplo. Então, ele pode dizer, ah, eu quero tal coisa, mas, pô, ele quis dizer que essa tal coisa era X, aí a LLM prendeu Y. A LLM vai fazer Y, pô, depois que faz para desfazer é ruim. Então, eu gosto de dizer que quanto mais perto...

o quanto mais próximo de você declarar a sua intenção legitimamente, diretamente, pragmaticamente, melhor. Se você for muito ambíguo, cara, a LLM vai pra um canto, você vai ter que esperar o negócio rodar pra depois dizer, putz, não era isso, volta, e aí o contexto tá poluído e putz, aí azedou. Então, assim, você tem que entender muito agora sobre o jogo da comunicação, como é que você se comunica com a máquina, né? Então, tem métodos pra você começar a melhorar isso também.

Isso vai ser cada vez mais difícil também, processo seletivo. Porque no fim do dia...

Se o cara vende, vamos supor, que ele vende de uma... E aí eu acho também o lance da... Por onde esse cara passou, por onde esse cara estudou, tudo isso vai começar a contar cada vez mais, tá? Também eu acho que quando a gente fala em processo seletivo, é uma coisa que vai ficar mais sólido, assim.

Eu acho que até a parte do trabalho, a parte importante do trabalho, não só do engenheiro, mas qualquer pessoa, na verdade, que, em qualquer segmento, é a capacidade de julgamento dela. Então, uma coisa é a IA resolver o problema. Mas será que aquela é a melhor forma de resolver? Quais são as alternativas?

Dá até para perguntar para a IA, mas no final das contas quem toma a decisão é a gente. Então, como que a pessoa toma de fato uma decisão ali quando ela tem mais de uma possibilidade? Será que ela só lê o que a IA escreveu e segue pelo que a IA sugeriu? Ela consegue pensar fora da caixa também? Avaliar o trade-off, o lance de avaliar o trade-off. Ele entende que se ele usar um pattern X ou um pattern Y tem implicações.

Ele sabe escolher entre um e outro pra esse determinado desafio? E se ele olha pro Codebase envelhecendo? Como é que isso envelhece? Isso envelhece bem ou mal? Cara, isso cada vez mais vai ser agora...

Pego no... Esquece? Tipo, reordena essa árvore. Cara, esquece. Isso aqui passou. Isso aqui é momento passado de como a gente se avaliava. Sei lá, 26 pra frente vai ser outro, vai ser outro processo relativo. Vai ser muito tipo, putz, ele escolheu esse padrão? Mas esse padrão não... E aí, eu acho que o entrevistador tem que ser safo o suficiente pra dizer, putz, por que você escolheu esse padrão? Esse padrão talvez não é ótimo.

Mas qual é o trade-off? Se o cara for argumentar bem, talvez ele ganhe até ponto por conta disso. Ele pode ter achado a coisa... De novo, o futuro é dos criativos. Por isso que avaliar a criatividade nesse lugar é importante.

Eu já vi muitos times tendo dificuldade, assim, tomando decisões, até tomando decisões muito ruins, assim, ao longo da vida de um projeto e tal. E, infelizmente, a gente só perceber, assim, depois de meses, se não depois de alguns anos do time ali ou da pessoa, talvez o líder da equipe, enfim, o engenheiro mais sênior, tomando decisões ruins ao longo desse tempo todo.

Aqui não interessa tanto se foi por pressão do negócio, se foi porque ele não conhecia tanto. Eu não estou tão interessado nisso nesse momento, mas decisões ruins acabam se acumulando ali até levar o projeto para um ponto que não vai ficar muito legal. Agora, existe também a possibilidade, já existe hoje, na verdade, as pessoas que criam um código ruim porque a IA fez o output, funcionou, ela aceita e vai embora. Ela nem revisa nem nada e segue o jogo.

Então a gente também tem essa possibilidade agora de a pessoa criar o código ruim porque ela não faz um bom trabalho ali, passando um prompt, os padrões que ela quer que a IA siga, por aí vai. Assim, no caso desse, como é que faz para talvez a gente descobrir mais cedo que a gente está tendo esse tipo de problema, dado que talvez a gente esteja caminhando numa direção de revisar cada vez menos código de IA, porque ela já, em tese, já faz um trabalho mais ou menos bem feito, então a gente tende a resolver.

a revisar cada vez menos linha a linha de código. Então, como é que a gente faz para evitar esse problema, os problemas se acumularem ao longo do tempo? Perfeito, perfeito. Eu volto para o lance do... Eu chamo isso de sanity check, tá? É um check de sanidade do teu codebase. O quanto meu código está sadio? Eu acho que isso precisa estar...

dentro de um CI, dentro de um negócio automatizado, que antes de ir para o A, ele faz um check daquela mudança, daquele código novo e tal, e diz, beleza, isso está compliant, isso ainda mantém o código sadio, porque, de novo, eu vou usar a IA contra a IA, e aí, de novo, eu posso brincar de ter multijulgamentos de multimodelos, para saber se...

A interseção de todos esses outputs é o mesmo. E tipo, beleza, estou coeso. Aí tem várias formas de fazer isso. A gente pode brincar de multipoderes, multiagentes. Mas o que é que você... Mas eu acho que você precisa de um sent check. Antes do codebase. Você pode antecipar essa camada lá pra camada de dev ainda. Sem mexer no código. E o cara pode... Lembra que a gente usa o sonar, né? A gente de VEDG a gente usava o sonar. Pra fazer inspeção de código estático.

A gente vai fazer a mesma coisa agora, só que pro codebase inteiro. Porque agora é mais barato fazer isso. Entendeu?

E aí você pode ter esses sanity checks, de novo, que no fim do dia são arreios, são os harness, antes do código para a produção. Então, a proposta... Eu faço isso de certa forma...

Não é intencional quando eu estou, eu, Zara, avaliando a proposta de solução, no nível de design da solução, que o Opus me deu. Então, eu faço esse senti-check, mas acho que isso não envelhece bem. E aí, quando eu tenho dúvida, eu pergunto, isso envelhece bem nesse contexto? Ou isso envelhece mal? Quais são os trade-offs? E isso acaba indo também para a minha ADR, quando eu escrevo ADR. Então, na ADR, eles dizem, a gente está abrindo mão disso, a gente está comprando isso, a gente tem ganho aqui. Na ADR, você também já vai, por velho, usando isso. Se você faz isso,

constantemente, ou seja, constantemente você tem um código que ele tá legal. Se você negligencia isso, você vai dizer, ah, azar, mas é muito frufru. Cara, tudo bem, pago o preço daqui a pouco. Então, assim, você escolhe. Queima mais token, queima mais permanente, você não tem que voltar nesse negócio daqui a seis, três, quatro semestres, entendeu? Porque código azeda. Código azeda, isso é fato, assim. O código de hoje é resultado do problema de hoje.

O código de amanhã provavelmente... O código de amanhã, que provavelmente é um filho do código de hoje, vai levar todos os pecados do pai dele pra lá. Então, assim, pô, não vai funcionar, entendeu?

Existe até um conceito de fitness functions, né? Eu acho que é talvez menos usado no mercado que deveria, mas eu acho que agora vai ficar mais simples a ter. Eu acho que checagem determinística, quando a gente dá pra usar, cara, vamos usar ela, em alguns casos, talvez determinístico não funcione tão bem, então a gente pode fazer algo usando o LLM ou algo nesse sentido, que vai fazer uma checagem pra gente, ah, será que, sei lá, o Model Tau não está conectando com o Model Tau? Porque não pode, por causa disso, a gente tem uma regra.

Então a gente consegue criar talvez algumas regras ali que todo mundo na empresa, em princípio, vai ter que passar por aquilo. E se não passar, tudo bem. Aí vai ter que ter uma justificativa e tal. Mas pelo menos tem alguma chegade. Cada empresa vai ter que ter as suas convenções de arquitetura ou code guidelines. E isso vai precisar estar dentro.

dentro desse circuito, de cheques tanto para construir quanto para avaliar no final. A parte mais importante é a avaliação do final. Sim, o pessoal pensa, ah, engenharia de contexto é legal? É, mas ela é o começo da conversa. O mais importante é, o código que está ainda na camada de dev, ele é mais barato de ser corrigido depois que ele vai para o ar.

Porque, cara, você sabe que quanto mais perto da produção, mais custoso é esse software do ponto de vista de manutenção. Então, assim, quanto antes você conseguir antecipar, melhor. Então, o Marti Fala chama isso de guides, né? O feedford, ele chama de feedford lá. Ele usa feedford, feedback. Então, assim, cara, o feedford é antes. Mas eu acho que a camada de feedback é mais importante ainda, assim. Que é, putz, uma vez que esse código foi produzido pelo IA.

Como é que eu garanto que isso está compliant ou está em consoância com o que a gente definiu no começo? Isso está batendo com o meu Code Architecture? Isso está compliant? Então a gente precisa criar mais isso. Documentação, cara. Documentação ficou muito barato.

Documentação de código hoje, basicamente, é muito barato você criar, manter, evoluir. Até fiz umas skills ultimamente. Tá lá no meu GitHub, quem quiser depois pegar. Mas, cara, é muito barato hoje em dia você ter documentação. Documentação boa, assim. Não tô falando de documentação ruim. Documentação boa mesmo. E manter isso ficou muito mais fácil. Você bota no CI. O CI gera o código, sabe? Gera doc, atualiza doc, faz tudo.

Ficou tão simples fazer documentação ultimamente que talvez até a gente tenha que seguir por um caminho de tomar cuidado para não documentar demais, né? Além do necessário. Exato, exato, exato. Essa é a minha pira agora. Como é que eu não gasto toque demais com um negócio que é easy peasy, tá? E a última pergunta que eu tenho aqui para você é assim.

Qual é o maior risco que você vê que engenheiros ou talvez até líderes de engenharia estão correndo hoje, mas que talvez eles estejam ignorando, não estejam vendo potencial problema para frente?

Eu acho que a gente está numa fase do jogo que está tudo muito rápido, tá? E eu acho que a gente como líder de engenharia tem que começar a botar mais a bola no chão e fazendo com que o time ganhe confiança nesse tipo de ferramenta. Eu vejo gente super empolgada de um espectro.

E eu vejo gente super reticente no outro espectro. Acho que nosso... De novo, esse negócio não tem mais holdback. Como é que eu pego o cara que ele está super reticente, ele não quer nem encostar nesse negócio e trago ele para o jogo de uma maneira saudável. Porque eu posso fazer um top-down e esse cara dizer não e eu demitir ele. Isso é um cenário. Mas eu não quero porque eu gosto desse cara. Esse cara é um cara produtivo, é um cara que agrega para a companhia. Como é que eu faço esse cara ganhar confiança? A gente é muito.

A gente é muito sobre ganhar confiança, né? A gente ganha confiança na ferramenta, a ferramenta vai levar a gente pra frente e a gente vai andar passinhos nessa conversa. Então, a primeira coisa é como é que eu faço o lance da adoção de IA pelos times de desenvolvimento. Segundo é, beleza, tem uma galera super empolgada e as galera super empolgadas, tem que ter cuidado pra eles não fritarem nesse processo.

E aí, eu até escrevi essa semana sobre tédio, né? Acho que eu tava fritando nesse processo, tá? De querer estar na crista da onda, acompanhando tudo no hype. Saiu, eu tô usando. Saiu o caveman de manhã, de tarde, eu já tava usando. Putz, eu parei, tá? Assim, cara, claramente eu tava... Eu tava indo dormir e eu ligava aqui o meu agente com o meu Telegram. E quando ele terminava de rodar o negócio, ele me mandava mensagem. Eu tava na cama, eu voltava pro escritório pra ver como é que tava. Cara, tava pirando. E isso tava começando a fazer mal. Então...

Comecei a parar de fazer isso e eu acho que tem gente que está super empolgada, que eu acho que é legítimo a empolgação, quem é mais velho como a gente, que hoje você consegue produzir código, hoje eu faço mais falando, porque eu uso aqueles whispers da vida, que pode ser sussurra aqui, e o negócio escreve para você, você aperta um enter e vai. Mas a gente tem que cuidar da carga cognitiva para a galera não fritar também.

Pensando em liderança, e aí mais no fazer do líder, do dia a dia, dos managers principalmente, a gente vai voltar a ser mais técnico do que já foi. Esquece, não tem mais como a gente não ser mais tão técnico. Eu arrisco a dizer que a gente vai ser tão técnico quanto o nosso staff engineer. Só que, diferente do staff engineer, que ele é cobrado por código, a gente vai ser cobrado...

por conhecimento técnico do que está indo pro ar. Mesmo sem colocar nem a mão no cloud code da vida pra fazer nada. Mas a gente vai ser cobrado por, tá? E aí, tipo, por que a taxa de erro tá tão alta? E eu acho que, de novo, o manager tem que ser hábil o suficiente. Eu acho que a gente tem um mercado que hoje ainda...

Muita gente ficou mais no people in process e menos no técnico. Eu acho que essa galera vai ter que correr um... dar um sprintzão extra aí pra poder chegar lá. Mas a gente vai ser mais cobrado por isso. E outro, vai ter que aprender a negociar bem, é o que a gente estava falando no começo, com o time de negócio e produto.

utilizando o seu conhecimento agora sobre o seu código, porque agora ficou mais fácil de inspecionar o código, para dizer por que vocês estão lentos, por que esse negócio dá tanto erro. Acho que vai facilitar muito esse diálogo. Então, o líder do futuro vai ter que...

Usar tudo de código para criar um arcabouço de conhecimento para ajudar eles na dissertação, na comunicação com o negócio. E vice-versa, tá? É pegar de negócio e dizer, putz, isso é factível ou não? Hoje mesmo eu fiz isso. Uma pessoa de negócio me pediu para fazer uma coisa aqui no nosso site. Aí eu falei, pô, deixa eu ver se é possível. Aí eu peguei o nosso codebase aqui e perguntei, eu consigo fazer isso hoje sem alterar nenhum endpoint?

Aí ele falou, não. Tem esse tipo de coisa que é o mais perto que você chega, mas isso corrompe a camada de domínio do negócio. E eu falei, cara, maravilhoso. Cara, você pega aquele negócio, você aprendeu, você já conversa com o cara. Matos, eu gastei 15 minutos nessa conversa. Se eu fosse fazer isso, eu ia parar, eu ia ter que abrir o codebase, olhar, inspecionar, depois de um dia que eu ia responder essa pessoa. Por 15 minutos.

O líder do futuro é esse líder mais ágil, que entende como é que ele conversa com o código, entende as capacidades do código agora de uma maneira muito mais suave, muito mais, sabe, sem atrito técnico, porque, de novo, ele é técnico o suficiente para poder conseguir fazer esse tipo de pergunta. Boa, excelente. Daí eu queria abrir o espaço para você, passar a tua mensagem final para a galera, ou fazer teu jabá, e se tiver algum jabá para fazer, pode ficar bom. Boa!

Do último papo pra cá, eu continuo escrevendo ainda. Eu acho que eu tenho gastado uma energia absurda em pensar como é que vai ser esse futuro, fazer esse exercício de reflexão. Estou escrevendo lá no zaratips.substech.com Matos, depois, por gentileza, vai deixar o link pra vocês. Comecei a escrever um outro livro.

esse vai ser bem inspirado no Phoenix Project, vai ser uma novelinha esse está me levando mais tempo não sei quando ele sai mas ele está levando mais tempo para fazer, eu confesso para vocês que eu tenho até estudado sobre o tema de como é que eu posso ser um escritor de aprender a ser escritor de novelas novelas tipo contos e tal esse vai ser muito para vender a coisa do Bill to Learn como framework e aí vai ser o mote do livro spoiler para vocês e aí

Cara, estou sempre pelo LinkedIn publicando coisa nova, então, se vocês quiserem me acompanhar por lá, eu estou sempre por lá. E a mensagem que eu deixo mais para a turma nova é não se desesperem, o mercado está passando por um momento de ruptura, a indústria como o TodoSoft, eu acho que ela se reinventa agora, desde o upstream, né? Eu estava exatamente esses dias conversando com a pessoa que queria fazer um produto para PMs.

Ele queria fazer um toolset de ferramental que o PM entra e ele fica super... É o superpoderes do PM. Eu achei super legal a ideia. Acho que a gente vai ter muita coisa surgindo nessa camada de upstream. Eu acho que a parte de coding, eu acho que a gente está começando a endereçar, está ficando mais sólido.

Se você perguntasse isso seis meses atrás, eu ia dizer que ainda estava muito mole. Agora começa a ficar mais sólido, porque esse negócio do harness, a ideia de você antecipar, você colocar dentro do curralzinho, onde ele vai conseguir correr, tudo isso. Mas isso vai precisar de specs, de especificações bem escritas. A gente fala de spec-driven development, mas essas especificações também na camada de upstream. E eu acho que o upstream, ele precisa talvez ser...

empoderado com o IA também, para que eles fiquem mais assertivos nos pedidos que eles querem. E aí eu já tenho ajudado muito a turma aqui também no Quinto Galá.

Como é que a gente consegue ser mais preciso no upstream para que a spec chegue de uma maneira tão boa, tão boa, que quando jogar para IA vai ser fácil o flow, tá? E aí a gente fala do upstream e downstream até a produção. Tipo, da ideia ou do problema até a produção. Então, esse fluxo vai ficar mais legal. Então, para quem é mais novo, ó, masterize esse livro, famoso livro do macaco.

e esse livro que a gente falou sobre a filosofia do design, eu acho que são dois livros que são necessários nesse novo mundo, quem conseguir comprar, compre, estude, masterize esse tipo de conhecimento, que eu acho que para quem souber mapear o mundo real,

E resolver isso com código, transformar no virtual, não fique desempregado nunca. E eu acho que isso não muda nem com os novos paradigmas que ainda vão surgir de IA, tá? Outro livro que eu estou super recomendando, e esse é mais para a galera que já é mais vé de guerra, é o Design of Design do Fred Brooks. Fred Brooks, para quem não lembra, é o autor do The Mythical Mammoth.

Também são dois livros que eu super recomendo. Ainda mais nesse novo momento de mudança. A gente fala muito de... Os princípios estão mudando e tal. Acho que quando você entende do metamodelo de design, você consegue, principalmente a galera mais velha que tem mais repertório, consegue capturar isso mais fácil. Então, desafio para a juventude nova, masterizar sobre negócio, domínio, driven, design, e focar em filosofia de software.

Entenda. Gente, escrever código é uma coisa, escrever software é outra coisa. Assim.

Software precisa de código, mas nem todo código é software. Então, fiquem atentos a isso.

Boa. E só trazendo os nomes do livro aqui, que eu acho que você não chegou a comentar, os dois primeiros que você mostrou. Vamos ver se eu lembro dos dois. É A Philosophy of Software Design e Aprendendo Domain Driven Design, certo? Isso. O famoso livro do macaco, da Aurelie. A Aurelie é muito bom porque você consegue referenciar os bichos, né? Então tem o livro do javali, tem o livro do macaco, tem... Exato. O outro é o A Philosophy of Software Design.

que eu acho que são dois livros modernos. Se você quiser livro velho, aí você pode pegar Körninger, você pode pegar o Yurdon, o próprio Kent Beck, o Kent Beck tem o Tadiforce, que é um livro pequenininho, rápido de ler, também que são livros bons sobre design e software. No fim do dia a gente vai estar falando sobre isso.

Boa, excelente. Zara, muito obrigado. Vou botar todos os links aqui, inclusive sigam o Zara no LinkedIn, ele posta sempre coisa muito interessante lá. Obrigado pela presença aqui, Zara. Prazer conversar contigo, cara. Abração e até a próxima. Fica bem, mestre.