Blade Para Raku: Uma Renomeação de Sábado Através da Base de Código

Um nome é uma promessa. Raku — facilidade, conforto, o toque humano — é a promessa por trás de um runtime construído para que experiências de IA pareçam humanas, não mecânicas. Este é o fim de semana em que isso se tornou real.

O runtime tinha um nome quando comecei a construí-lo. O nome era provisório, do tipo de provisório que te deixa parar de se preocupar com nomenclatura e começar a escrever código. Eu sabia que era provisório quando o escolhi. O nome de verdade estava esperando algumas coisas se assentarem.

Neste fim de semana o provisório saiu. O runtime agora é Raku.

Por que agora

Três razões.

O alvo do produto se estabilizou. Quando o runtime era AR1+ e depois AR2 Gen1 e depois talvez um de três caminhos de hardware diferentes, nomeá-lo em função da família de dispositivo não fazia sentido. Agora que a mudança de RA está resolvida, o motor pode ter seu próprio nome que não depende de em qual dispositivo é lançado.

As conversas de parceria estão ficando sérias. Uma conversa de parceria que fica séria não sobrevive a um nome provisório na base de código. Fornecedores não fazem parceria com código que se chama “BladeRuntime” em alguns arquivos e “AR1+Runtime” em outros. A renomeação é uma precondição para essas conversas irem além.

A marca precisa significar algo. Raku em japonês significa facilidade, conforto, prazer. É também o nome de uma tradição de cerâmica de chá japonesa que valoriza a irregularidade e o toque humano acima da precisão mecânica. Ambos são sinais sobre para que o motor serve: experiências fáceis de criar e que parecem humanas, não mecânicas. O kanji 楽 aparece na logo. A escolha do nome não é arbitrária. É a primeira peça da identidade da empresa.

O que o rebranding envolveu

Uma varredura pela base de código. Dois PRs entregaram a maior parte dela em execuções de agente consecutivas. Os agentes fizeram o trabalho repetitivo, o que é bom porque o trabalho repetitivo era enorme. Aproximadamente:

• Toda referência a “ar1-runtime” em código, documentação e CI mudou para “raku-runtime”
• Toda referência a “Blade” em branding e empacotamento mudou para “Raku”
• A biblioteca nativa do runtime renomeada de ar1plus para raku
• Todos os prefixos de símbolos exportados atualizados
• Todos os nomes de alvo do CMake atualizados
• Todas as referências de caminho de include atualizadas
• Todas as referências cruzadas de documentação atualizadas
• Todos os readmes de apps de exemplo atualizados
• Logo e assets de marca trocados

Dois PRs. Aproximadamente cento e dez arquivos tocados entre os dois. Ambos entraram sem quebrar o build, que era a métrica que importava.

O que aprendi ao fazer dessa forma

Três coisas, cada uma útil para qualquer um planejando uma varredura por uma base de código construída por agentes.

O agente faz a renomeação mais rápido do que eu, mas só se a issue for precisa. A issue que produziu a maior parte da renomeação dizia exatamente quais símbolos mudam, quais caminhos mudam, quais documentos mudam, e quais padrões deixar intocados (entradas de changelog, registros históricos de decisão, branches arquivados). O agente seguiu as instruções. O resultado foi uma renomeação limpa. A versão da issue que tentei dois dias antes era menos precisa, e a renomeação voltou com trinta lugares em que o agente tinha renomeado de forma agressiva demais, incluindo referências em mensagens de commit antigas que deveriam ter permanecido por motivos arqueológicos.

PRs de renomeação querem ser pequenos mesmo quando tocam em tudo. Os dois PRs que fizeram a renomeação não eram sutis. Cada um tocou dezenas de arquivos. Eram pequenos no sentido de que faziam apenas uma coisa. Cada PR era só-renomeação, sem mudanças funcionais misturadas. Misturar uma renomeação com mesmo que uma pequena mudança funcional torna o PR irrevisável, porque o revisor humano tem que ler cada linha para garantir que a mudança funcional é só a mudança funcional. Renomeações puras podem ser revisadas em quinze minutos.

A marca precisa estar pronta antes de a renomeação ser lançada. Metade do trabalho deste fim de semana não estava na base de código. Estava em escolher o novo nome, registrar domínios, garantir handles, acertar o kanji, projetar a logo. A renomeação da base de código é o último passo, não o primeiro. Se você faz a renomeação da base de código e depois percebe que a marca não está pronta, você fica preso a outra rodada de renomeação.

O que não mudou

A arquitetura não mudou. A API C não mudou. O roadmap não mudou. O alvo do produto não mudou. Qualquer um lendo a base de código no fim de semana anterior à renomeação e no fim de semana seguinte veria o mesmo motor fazendo as mesmas coisas.

Essa foi a renomeação certa. Foi uma troca de rótulo, não um redirecionamento.

O que parceiros e construtores tiram disso

Se você é um integrador olhando para o runtime agora: onde quer que você veja “raku-runtime” nos nossos repositórios e empacotamento, é o mesmo motor que se chamava outra coisa no fim de semana passado. Não há quebra de compatibilidade. A API C está inalterada. Os bindings do SDK estão inalterados. Os apps de exemplo continuam funcionando.

Se você está buscando parceria em um produto que vai ser lançado sobre este motor, o nome agora está estável. A conversa não precisa começar com “estamos chamando assim por enquanto, mas.” Pode começar com “aqui está o que a Raku é e para que ela foi construída.”

Se você está dentro de um time de dispositivo AR2 pensando em qual runtime mirar na sua plataforma, a mudança de nome também é uma declaração sobre onde o motor está posicionado no mercado. Raku não é “o runtime AR1+ que cresceu.” É a sua própria coisa, com sua própria tese, disposta a ser lançada em qualquer parceiro de hardware que seja o melhor encaixe. A renomeação faz parte dessa declaração.

Fim de semana tranquilo, no sentido de que nada funcional mudou. O tipo certo de tranquilo.