Pular para o conteúdo

Uso o Google Analytics pra entender o que é lido por aqui. Ele só carrega se você aceitar — nada de terceiros roda antes disso. Como o Google usa esses dados

Blog

· #career· Engenharia

Da cloud à IA, com o mesmo crachá.

Um crachá dentro de um porta-crachá plástico transparente, deitado com a face para cima sobre uma mesa de madeira clara e ocupando quase todo o quadro: cartão preto com borda amarela, o nome Luiz Tadeu no topo, uma foto de rosto abaixo e o usuário tadeumen@ na parte de baixo.
O crachá que disparou a conta que este texto faz — e que só chegou seis meses depois da data.

São cinco anos de AWS, e o crachá chegou até mim seis meses depois da data que ele comemora — o marco foi em janeiro; ele só foi impresso agora. Ele é amarelo — você entra na AWS com o azul e troca pelo amarelo aos cinco anos; o vermelho vem aos dez, e esse eu ainda não vi. A cor é a única parte que muda com o tempo; o resto do crachá é o mesmo desde o primeiro dia. Se tivesse chegado em janeiro, eu teria uma resposta pronta. Chegou num dia qualquer, e eu não tinha nenhuma.

Então eu contei. E o que eu quero escrever aqui não são os cinco anos. É a virada embaixo deles.

2021: o que eu fui buscar

Eu tinha acabado de sair da Accenture depois de quase treze anos — a carreira começou lá, em 2008 — e ido para a Globo, para ir para um ambiente onde eu achava que ia aprender muito sobre engenharia de software.

O que eu queria estar fazendo todo dia era cloud AWS e Terraform, e não era isso que o meu dia tinha para mim — na direção que eu queria, o desafio parecia pequeno.

Isso não é decepção, é informação. Entrei numa vaga de DevOps puro e acabei me especializando em observabilidade — fui fundo ali, nos golden signals do livro de SRE do Google. Foi fazendo isso que eu me dei conta de que sentia falta de trabalhar com aplicação.

E o que eu quis da AWS depois disso era específico: trabalhar com cloud AWS e Terraform todo dia, com muito mais exposição do que eu tinha.

Agora a parte menos elegante e mais útil. Quando eu fui para a AWS e para o ProServe, eu não sabia a diferença entre as vagas de Solution Architect e de ProServe Cloud Application Architect. O que eu vi foi uma vantagem: eu tinha anos de business de consultoria nas costas, e dava para perceber que aquilo seria um diferencial para o ProServe.

Se você está lendo isto no meio da sua própria virada, é provável que esteja exatamente aí — olhando portas que você não consegue diferenciar e decidindo pela porta em que você tem chance.

O que eu encontrei

Funcionou. Conhecimentos de AWS finalmente sedimentados, coisas novas construídas, uma prática de Terraform muito maior do que eu tinha antes. Era exatamente o que eu tinha ido buscar na AWS, e era o que me dava prazer naquele momento.

Tudo ali era verdade, e continuou sendo verdade por anos. O que mudou veio depois.

O que mudou, e por que isso é estrutural

Projetos de cloud enablement se parecem muito entre si, e o que determina isso é a posição do cliente, não a empresa dele: quase sempre é um primeiro contato com cloud pública, logo depois que a landing zone da AWS estabiliza. É o mesmo ponto de uma curva, visitado por companhias diferentes. A variação está nas logomarcas e nos organogramas, não no problema que está sendo resolvido. É o que cinco anos nesse tipo de engajamento me deixaram ver.

Trabalhar com cloud AWS e Terraform todo dia entregou exatamente o que eu pedi: profundidade. O que parou de entregar foi problema novo. Depois de um tempo nos tipos de engajamento em que eu geralmente estou envolvido, eu não via mais desenvolvimento técnico ali para mim como application architect, e percebi que precisava de um desafio novo.

Sempre foi assim, e eu só vi agora

Nas três vezes o que eu mudei foi o objeto do trabalho, não a empresa — e eu só vi isso na terceira.

Na Accenture, na transição para digital, eu paguei um pedágio: fiquei alocado num projeto de Siebel CRM, e o que me levava adiante acontecia ao lado dele — Node e Docker, fora do horário. Na Globo o que me levou adiante estava dentro da alocação: não faltou o que aprender, e foi fazendo observabilidade que eu vi que o que eu queria era aplicação. Na AWS está de novo fora dela: o papel não esgotou, acabou o problema novo, e o trabalho que me leva além não é o que eu estou alocado para fazer.

Um padrão que você consegue nomear dá para reconhecer antes de virar ressentimento. Nas três eu reconheci a tempo. Não é um método; é o que acontece quando você presta atenção no que realmente te interessa. Mas ele se repetiu limpo o bastante para eu sugerir a um par que procure por ele no próprio histórico.

O desafio de agora

Eu vejo muitos problemas parecidos ao longo do tempo, e quero continuar me desenvolvendo tecnicamente.

AI engineering é o que está me permitindo ir além, e não é a minha atividade principal em projetos. Os projetos ainda não são totalmente focados em IA: a IA está presente como ferramenta, e as tarefas dentro deles estão sendo reinventadas todo dia com um uso melhor dessas ferramentas. Ainda não é AI Native.

O problema que me pegou é tornar o uso de IA confiável, repetível e observável — observável no mesmo sentido que eu aprendi na Globo, só que apontado para um modelo em vez de para um sistema.

E isso dá para mostrar, porque está no ar. Este site é publicado por um loop de agentes que eu construí e opero: personas que discordam por construção antes de qualquer coisa ser escrita, e um gate de contexto fresco que é o único que pode fazer merge — não por combinado, por mecanismo. Este artigo atravessou esse loop antes de chegar até você.

Na prática, o que me toma tempo é decidir o que o harness barra, o que ele aconselha e o que ele só documenta, e depois provar que essa divisão continua verdadeira quando alguém mexe. Errar isso custa caro nos dois sentidos: uma garantia que só existe na minha memória não é garantia, e um gate que fica verde sem ter verificado nada é pior do que não ter gate. Eu rodo dois harness diferentes sobre o mesmo tipo de trabalho, um interno e este, público — é o que me deixa separar o que é do modelo do que é do setup em volta dele, e melhorar o setup a cada volta.

E o motivo de acontecer assim mesmo é bem mais simples que uma estratégia. Eu estou indo além do horário comercial ao longo de vários dias porque me empolguei com as possibilidades de trabalho com IA. É esse o motor — o interesse indo para onde a alocação não vai, que foi exatamente o que tinha acontecido antes.

O que eu não tenho

Eu não tenho o final. Estou empregado, não estou anunciando nada, e não tomei a decisão que este texto parece estar construindo. É justamente porque nada está decidido que o que resta é imaginar.

Imagina o seu dia se texto deixar de ser a principal forma de falar com a IA: muda quase tudo na superfície, e o problema de fazer aquilo ser confiável, repetível e observável continua exatamente o mesmo. Eu não sei resolver esse problema ainda. É a parte que eu mais quero ver.

O que eu tenho, enquanto isso, é um teto que eu consigo descrever com precisão e uma prática paralela sem glamour, quase sempre fora do horário. Se você está em algum lugar parecido — o papel está ok, o problema parou de variar, e o trabalho interessante está acontecendo ao lado da sua alocação em vez de dentro dela —, vale nomear isso em voz alta antes que vire outra coisa pior. Você não precisa ter decidido nada ainda. Eu não decidi. Imagina comigo.