**Esta é uma posição de Tech Lead um pouco diferente das que costumamos publicar por aqui.** Estamos buscando a primeira pessoa que vai liderar tecnicamente nosso primeiro produto próprio. Por isso, tivemos um cuidado especial em explicar o contexto, os desafios, as responsabilidades e o que esperamos dessa posição. Você vai encontrar abaixo uma descrição mais completa do que o habitual. A intenção é que, antes mesmo de se candidatar, você consiga entender bem o desafio que estamos propondo e avaliar se ele faz sentido para você. **O Desafio** Este é o primeiro produto próprio do Lab Secreto — construído com uso intensivo de agentes de IA e um ritmo de execução fora do padrão de mercado, sob a liderança direta do CEO do Lab. Agora chegou a hora de trazer alguém para assumir a propriedade técnica e formar o time que vai levar isso adiante. Se você lê isso e pensa "é esse tipo de desafio que eu quero pegar", continue lendo — o resto da vaga foi escrito para você decidir com informação de verdade, não para parecer bonito. Liderar o Produto e a Equipe Dele, Em Parceria Direta Com o CEO e CTO. Na Prática, Isso Quer Dizer * Fundamentos de arquitetura de software sólidos, cabeça de maker, e capacidade de executar rápido e com precisão usando IA. * Ser dono técnico do produto. Arquitetura, contratos, padrões, qualidade. As decisões estruturais saem de conversa entre vocês, a defesa e a execução são suas. * Traduzir visão de negócio em sequência executável, em ordem, escopo e entrega. * Escrever código e sustentar velocidade. * Formar e liderar o time do produto. Define o perfil, participa da seleção e é o padrão técnico que as pessoas vão seguir. * Estabelecer como se valida trabalho aqui. Como a gente sabe que o que foi produzido está certo — essa pergunta é sua para responder e instrumentar. **O Que Precisamos Que Você Já Tenha** * Fundamentos de arquitetura de software — inegociável, você precisa conversar com propriedade sobre: * Modelagem de domínio de verdade. Separar tipo de instância, identidade estável de identificador temporário, propriedade de sinal de estado de evento. * Contrato versus implementação. Definir o que existe sem vazar como funciona. * Sistemas distribuídos na prática. Idempotência, entrega confiável, reconciliação, compensação, ordenação. Saber que uma chamada bem\-sucedida não prova que a operação terminou. * Dados em tempo real. Estado inicial mais atualizações incrementais, detecção de perda, ressincronização, contrapressão, latência. * Versionamento e compatibilidade. Evolução de contrato sem quebrar quem consome. * Saber quando não abstrair. Generalizar cedo demais, dividir serviços cedo demais e transformar todo dado em objeto são erros que custam caro. * Sobre stack: importa muito menos do que como você pensa. Trabalhamos hoje principalmente com TypeScript/Node e C\#/Unity, mas a lista de linguagens no seu currículo não é critério — a disposição de aprender a que o problema pedir, sim. * Domínio industrial, geoespacial, telemetria, 3D ou vídeo são bem\-vindos, mas nada disso é bloqueante — a gente ensina aqui, inclusive levando você a campo. Fundamentos, não. * Ritmo: O padrão de ritmo desta vaga é o mesmo que aplicamos em outras iniciativas do Lab: entrega rápida, ciclos curtos e uso intensivo de agentes de IA desde o primeiro momento. Dizemos isso porque é a expectativa real de velocidade da vaga. Nosso maior desafio é encontrar quem sustente ritmo executando rápido e com precisão. Velocidade que gera retrabalho não é velocidade. * Execução com IA (e aqui vale uma distinção) \- Usamos IA massivamente. Não como acessório: é o modo de produção. O trabalho hoje não é escrever linha de código, mas sim construir os loops e as ferramentas que validam o que os agentes produzem, revisar planos antes da execução, e interrogar o resultado — fazendo perguntas, não lendo linha a linha. Os agentes não são autônomos aqui; eles operam dentro de um sistema de verificação que alguém precisou projetar. Isso é o oposto de vibe coding. Vibe coding é aceitar o que saiu porque parece funcionar. O que fazemos exige fundamento mais forte, não mais fraco: para especificar bem, para desenhar a verificação, para reconhecer a abstração errada num plano antes que ela vire código, e para saber qual pergunta expõe o problema. Se você lê essa descrição e pensa "isso é preguiça" ou "isso é brinquedo", não vai funcionar. Se você lê e pensa "é assim que eu quero trabalhar, mas ainda não sei fazer direito" — ótimo, vamos conversar. O método é ensinado no processo. O que não dá para treinar em tempo hábil são os fundamentos. **Nossa filosofia de engenharia: output não é outcome** Esta parte da descrição foi escrita com bastante cuidado. Queremos que você entenda como pensamos engenharia, produto e entrega — e que possa avaliar se essa forma de trabalhar faz sentido para você. Por isso, recomendamos que leia esta seção com atenção antes de seguir para as demais partes da descrição. **Entregar não é resolver.** Código