Machikoba no Techo

O perigo só é visível a quem o sabe escrever.

Setembro. A época da pesca noturna da lula-de-ponta-de-espada (Kensaki) — um dos sinais do verão por aqui — aproxima-se do fim. Quem tem saído de barco à noite vai passando, discretamente, para aquilo a que chamamos budouika, a "lula-uva". Agradecemos sinceramente o vosso apoio contínuo.

E setembro tem ainda outra coisa: é a época em que a lula-de-barbatana-grande (lula Aori) se junta. À medida que a temperatura da água assenta depois do pico do verão, o peixe-isco ganha vida toda de uma vez. As lulas mudam com ele, e cardumes de lulas jovens entram nos baixios — ao longo dos quebra-mares as canas dobram-se nas curtas janelas do amanhecer e do anoitecer. Talvez seja a altura mais entusiasmante do ano. Para quem pensa em começar no eging, é também a estação mais generosa para dar os primeiros passos.

Este mês volto a escrever sobre os bastidores da oficina. No mês passado escrevi que, mesmo quando é a IA a escrever, parar para verificar continua a ser trabalho de gente. Isto é a continuação. Ao longo do último ano, usando a fundo no chão de fábrica aquilo a que se chama "vibe coding", senti tanto a sua força como um perigo exatamente do mesmo tamanho. E dei de caras com a pergunta que suspeito estar hoje à frente de muita gente: pode o código que a IA produziu entrar no chão de fábrica como uma caixa negra, sem que se olhe lá para dentro?

■ Diz-se "quero uma coisa deste género" e aquilo funciona

Vibe coding é saltar a especificação detalhada: descreve-se em linguagem corrente aquilo que se quer, deixa-se a IA escrever e recebe-se de volta algo que corre. No último ano construímos assim várias ferramentas pequenas para o chão de fábrica. Ou melhor: geramos ferramentas como quem respira.

Comece-se por dizer que isto é genuinamente poderoso. Aquilo que antes ficava na prateleira como "gostava, mas não há tempo para estudar o assunto" está hoje a funcionar no próprio dia em que nos lembramos dele. O que teria começado por um orçamento pedido a uma empresa de fora ganha forma durante uma pausa para almoço. Para uma pequena oficina como a nossa, não há mudança mais bem-vinda.

■ Correr e estar correto são coisas diferentes

E, no entanto, o mais assustador deste ano foi precisamente que aquilo corre. O que sai costuma funcionar. O ecrã tem bom aspeto, os números aparecem. E é por correr que, de fora, não se consegue distinguir se é sólido ou perigoso.

Um arredondamento subtilmente diferente num ponto. Comportamento indefinido quando chega um valor fora do intervalo previsto. Erros engolidos em silêncio, para que tudo siga como se nada tivesse acontecido. Nada disto se vê a olhar para um ecrã que funciona. Quem o vê são apenas as pessoas que já escreveram código desse género e se queimaram com ele.

No fim, só se fica descansado depois de ter seguido todo o código que saiu. O tempo que se julgava poupar ao delegar volta, tal e qual, sob a forma de leitura. A barreira para construir baixou enormemente; a barreira para dar pelo perigo não baixou. Essa assimetria é a lição mais nítida deste ano. Traduzido para a nossa linguagem, seria como estar diante de um centro de maquinação de 40 milhões de ienes e dizer "correu, logo está bem". Isso nunca é admissível.

■ Numa pequena oficina não há peça ideal

Então é uma ferramenta inutilizável? Longe disso. Em certas partes do nosso trabalho não há nada que assente melhor. Mas, para o explicar, tenho de dar uma volta pela realidade de uma pequena oficina.

No meu caso faço com regularidade uma coisa um pouco estranha: gero NC — a linguagem da máquina — por vibe coding. Para escrever o código que produz NC, é normalmente escolhido Python de forma automática; na maioria dos casos substituo-o por Ruby. É o meu estilo.

As máquinas-ferramenta NC modernas são extraordinariamente precisas. Dê-se-lhes um material ideal, uma forma ideal e dimensões ideais e obtém-se um acabamento que espanta. Mas na nossa oficina esses ideais quase nunca estão reunidos. Tem de se resolver com aquilo que se tem à mão. O material é irregular; a forma e o tamanho mudam de cada vez. O próprio pressuposto do "conforme o desenho" não está à nossa frente.

Chamo-lhe "o espírito de resolver com o que se tem". É a força de uma pequena oficina e o nosso orgulho, mas, do ponto de vista de quem escreve um programa, é um verdadeiro incómodo. Como as dimensões mudam de cada vez, não se pode escrever um procedimento com números fixos no código. Em vez de "cortar esta forma nesta dimensão", é preciso reescrever para "medir o que está à frente e derivar o corte a partir desse valor". Por outras palavras, o nível de abstração tem de subir consideravelmente. É a parte mais difícil de programar numa pequena oficina.

■ Perfeito para ajustar à peça e para engenharia inversa

E esta maneira de trabalhar — ajustar à peça real — assemelha-se ao vibe coding a um ponto surpreendente. Não há primeiro uma especificação perfeita; vai-se cercando o objeto que está à frente, cortando e experimentando o encaixe, experimentando o encaixe e voltando a cortar. Pedir que produza algo que corra, apontar o que está mal, mandar corrigir e tentar de novo. Como se pode mexer as mãos antes de a especificação estar fechada, assenta notavelmente bem no chão de fábrica do "resolver com o que se tem".

Acima de tudo, o vibe coding é um bom complemento para a parte mais difícil: elevar o nível de abstração. Mostra-se-lhe uma versão com os números fixos no código e pede-se algo que continue a funcionar quando as dimensões mudam — e ele escolhe o que deve passar a variável. A parte da generalização que antes levava dias a uma pessoa — encontrar o ângulo de ataque — fica despachada de uma assentada. É exatamente a capacidade que faltava ao nosso chão de fábrica do "resolver com o que se tem".

O outro bom encaixe é a engenharia inversa: espicaçar por fora um mecanismo que não se compreende e reconstruir a lógica que está por detrás. Para ler formatos de dados desconhecidos, ou código longo que alguém escreveu há muito tempo, e perceber o que faz, é espantosamente fiável. É terreno que, à partida, não compreendíamos, pelo que um erro custa pouco. Encontrado o ângulo, o resto uma pessoa consegue verificar.

Um exemplo próximo: os programas NC que os próprios fabricantes de máquinas produzem. Sinceramente, não gosto muito deles. Sem indentação, com comentários que não ajudam, sem maneira de perceber o que estão a fazer. Um programa que não se consegue ler é um programa que não se consegue parar e conferir. A IA preenche essa falha. Pede-se-lhe que acrescente indentação e comentários porque o código é difícil de ler — e vem exatamente assim. Diz-se que a abstração está demasiado baixa e pede-se que seja partido em sub-rotinas — e ele divide o código em blocos com sentido. O mesmo comportamento, arrumado numa forma que uma pessoa consegue ler: talvez seja hoje o uso a que recorremos com mais frequência.

O que mais nos incomoda é que em lado nenhum está escrito sobre que variáveis uma sub-rotina tem efeitos secundários. Chama-se e alguma coisa muda. Mas o que muda é desconhecido até se ter lido tudo. Manda-se a IA lê-la e pede-se que enumere, num comentário no topo, as variáveis escritas lá dentro — e ela apanha-as. É trabalho em que uma pessoa gastava meio dia.

Um exemplo concreto. Mandamos muitas vezes a IA retrabalhar os programas NC da nossa máquina de eletroerosão a fio. É tão cómodo que quase me deu uma hemorragia nasal. No mundo do NC, embora toda a gente lhe chame "G-code", cada fabricante tem os seus hábitos de escrita — dialetos, na prática. Este modelo escreve-se assim; aquele precisa deste comando. Para uma pessoa, é comparar manuais e aprender no chão de fábrica.

A IA lê isso a partir do estilo do programa que lhe entregamos. Pressente as convenções de quem o código segue e escreve os acrescentos nas mesmas convenções. Dê-se-lhe também o manual do fabricante e começa a usar, sem que lho digam, macros específicas daquele modelo. Lê que "esta máquina oferece esta instrução" e escreve-a sem pestanejar. Que o conhecimento tácito, acumulado nos chãos de fábrica ao longo de muitos anos, se possa extrair assim — sinceramente, deu-me um arrepio.

Mas nunca enviamos um programa assim produzido diretamente para a máquina. Depuramos. Vai sempre para a máquina real, percorrido linha a linha, com os valores das variáveis e o movimento do fio conferidos a olho. É aqui que o M01 (paragem opcional) de que escrevi no mês passado ganha o seu lugar. Por muito bom que o trabalho pareça, quem não tiver a capacidade de o depurar na máquina real não pode usar esta ferramenta. Ou melhor: acredito que não deve. Usada como ferramenta para produzir respostas certas, é perigosa; usada como ferramenta para encontrar o ângulo de ataque, é temível. Mas confirmar esse ângulo é sempre o lado humano.

■ Deve ser uma caixa negra?

O que nos traz de volta à pergunta do início. Pode o código que a IA produziu entrar no chão de fábrica sem que se olhe lá para dentro? Honestamente, distinguimos os casos em que pode dos casos em que não pode. Por agora, a linha que traçamos é pelo sítio onde ele fica. Onde um erro se pode dar por ele e corrigir depois, onde o único bem perdido é tempo, usamo-lo sem seguir tudo. Onde uma máquina se move, as dimensões ficam definidas e o material é consumido — onde não há segunda tentativa — uma pessoa lê tudo, por mais longo que seja o caminho.

O incómodo é que a caixa negra não é só a parte que a IA escreveu. O software de hoje constrói-se chamando um grande número de componentes — bibliotecas publicadas por alguém, algures, no GitHub e noutros sítios. Houve há bem pouco tempo um incidente grande no mundo do JavaScript. (Na verdade, parece que aparecem backdoors quase todos os dias.) Uma biblioteca sobre a qual assenta muitíssimo software foi tomada e teve embutido um mecanismo que corria na instalação e se propagava por si ao pacote seguinte. Ao que parece, centenas de pacotes ficaram contaminados em poucas horas. Pouco antes disso houve casos de interceção em trânsito para trocar o destino de um pagamento — ou seja, adulteração precisamente da parte que trata do dinheiro.

Peça-se a uma IA "uma coisa deste género" e ela escolhe e inclui, naturalmente, componentes cómodos. Parte da razão por que é rápida é não escrever ela própria esses componentes. O que recebemos, portanto, é uma estrutura dupla: dentro da caixa que a IA escreveu, está a chamar-se a caixa de outra pessoa. Nenhum artesão corta um material sem saber o que lhe está misturado. Penso que com o software é igual.

Esta pergunta — se se pode confiar na caixa de outra pessoa — não é nova. Em meados dos anos 90, D. J. Bernstein, que escreveu o programa de transferência de correio qmail (nós próprios o corremos há mais de dez anos), não confiava sequer na biblioteca padrão do C — os componentes que vêm com a linguagem e que toda a gente usa sem questionar. Nas suas notas de conceção afirmou ter praticamente desistido da biblioteca padrão e ter substituído as partes onde os acidentes acontecem com mais facilidade, como o tratamento de cadeias de caracteres e a gestão de memória, por pequenos componentes seus, desenvolvidos ao longo de anos. Não foi ao ponto de reconstruir o sistema operativo, mas num ponto foi minucioso: pôr as partes perigosas sob controlo próprio.

O que atravessa o qmail é a ideia de reduzir, tanto quanto possível, aquilo em que se é obrigado a confiar. Para além de escrever os seus próprios componentes, dividiu o interior do programa em pequenas partes por função, construídas de modo a que nem as suas próprias partes confiem umas nas outras. Se uma delas for tomada, não consegue ir mais longe. Alguém pensou nisto até ao fim há trinta anos. Claro que não podemos imitá-lo escrevendo nós todas as bibliotecas. Mas a ideia — traçar as fronteiras partindo do princípio de que coisas em que não se pode confiar se vão misturar — transporta-se tal e qual para hoje.

E o assustador é que, se a caixa for demasiado grande, não há volta atrás. Tome-se como um único bloco grande algo que não se compreende lá no fundo e, quando acontecer alguma coisa, não se consegue separá-lo. Por isso a contramedida tem de ser tomada na conceção: mantê-lo numa forma que se possa sempre substituir. Esta parte pode ser trocada por outra; retire-se este componente e o conjunto continua a correr. Construa-se assim e, no dia em que algo acontecer, pode deitar-se fora apenas aquela caixa.

O que isso exige é capacidade de conceção no sentido da orientação a objetos. O que se trata como uma unidade, o que se expõe para fora, quanto do interior se esconde? Onde se traça a fronteira? Aquilo que antes se via como "escrever com elegância" tornou-se uma necessidade prática para não trazer coisas perigosas para dentro. Precisamente porque é a IA que escreve o conteúdo, o que é preciso é a capacidade de decidir a fronteira.

E esta linha desloca-se se a deixarmos entregue a si mesma. Depois de uma série de coisas a correrem bem, dá inevitavelmente vontade de aumentar a caixa. Pior: a capacidade de dar pelo perigo embota-se na exata proporção do pouco que se escreve por si. Esta ferramenta tem a propriedade de, quanto mais se usa, menos se conseguir ver através dela. Por isso a linha tem de ser traçada de novo do lado humano, e não do lado da ferramenta.

■ Engenharia de sistemas, mais do que programação

Olhando para trás, para este ano, é aqui que a minha impressão mais mudou: o que daqui para a frente será verdadeiramente indispensável não é a programação em si, mas a engenharia de sistemas.

Decidir o que construir e o que não construir. Traçar a linha entre o que se delega na máquina e onde entra o juízo humano. Preparar, antes de construir, como se regressa quando aquilo deixar de funcionar. Decidir onde ficam os dados e quem responde por eles. Por mais inteligente que se torne, a IA não decide isto por nós — porque decidi-lo exige conhecer o trabalho no chão de fábrica.

À medida que o tempo passado a escrever código diminuiu, começámos a gastar tempo na conceção, na operação e no juízo sobre quando parar. Ironicamente, o desaparecimento do esforço de escrever tornou muito mais visível o peso do trabalho que vem antes de escrever.

■ Todos os processos em casa, em Arita

Numa empresa pequena, quem construiu é quem usa e, quando avaria, é a mesma pessoa que repara. Por isso "conseguimos construir?" importa muito menos do que "isto cabe dentro daquilo de que conseguimos tomar conta?". Manter uma escala que se consiga repor pelos próprios meios no dia em que parar. Não é vistoso, mas acredito que é isto que significa DX à medida de cada um.

É exatamente a mesma história do fabrico de amostras de lula (egi). Os protótipos ficam prontos muito mais depressa do que antes. Mas o passo de os confirmar no mar não se encurta por meio nenhum. Quem decide entre bom e mau, no fim, é sempre o mar. Quanto mais depressa conseguimos construir, mais tempo pomos na confirmação — foi este o uso que escolhemos.

Numa pequena vila de província — Arita, na prefeitura de Saga, Japão — continuamos a fazer as nossas amostras de lula (egi) em casa, em todos os processos, do desenho ao corte dos moldes, à produção em série e à venda. Foi nisto que agosto me pôs a pensar. Componentes escritos por alguém, algures no mundo, correm dentro da nossa própria oficina, e uma IA lê os dialetos das nossas máquinas. No meio disso, o que deve ficar em mãos humanas? A resposta não está sequer a meio caminho, mas tenciono não parar de pensar nela.

■ Ir ao mar este mês

Setembro traz-nos uma série de novas cores e produtos. A Akazamurai Meteor Glow Orange é um laranja que muda de expressão entre o brilho fosforescente e a iluminação UV; o lançamento está previsto para este mês. A JetChaser Purple Edition, pensada para o tip-run de costa, é também deste mês. Além disso, a JetChaser size 3.0 e a size 3.1 passam a venda geral, com expedição prevista para o final de setembro.

Este ano assinala também o décimo quinto ano desde que nasceu a cor "Akazamurai" da EgiSharp. No final do mês passado divulgámos as imagens de uma cor comemorativa do décimo quinto aniversário. O facto de continuar a ser escolhida durante quinze anos não é confiança nossa — é a resposta dada por quem a usou.

Por mais inteligentes que as ferramentas se tornem, quem julga no fim é uma pessoa, e quem decide entre bom e mau é o mar. Teremos isso presente e continuaremos a fazer as coisas, um passo de cada vez. Mais uma vez, obrigado pelo vosso apoio neste mês.

Setembro de 2026
KeyStone Corporation
Nobuhide Kanagawa, Diretor Representante