Machikoba no Techo

Solo quien sabe escribirlo puede ver el peligro.

Septiembre. La temporada de pesca nocturna del calamar espada (Kensaki), una de las señales del verano por aquí, toca a su fin. Quienes salían de noche con sus barcas van pasando poco a poco al que llamamos budouika, el «calamar uva». Les agradecemos sinceramente su continuo apoyo.

Y septiembre tiene otra cara: es la temporada en la que se juntan los calamares de arrecife (Aori). Cuando la temperatura del agua baja desde su máximo de verano, los peces cebo se animan de golpe. Los calamares cambian con ellos y los bancos de calamares jóvenes entran en las zonas someras: las cañas se doblan a lo largo de los espigones en las breves ventanas del amanecer y del atardecer. Puede que sea la época más emocionante del año. Para quien esté pensando en iniciarse en el eging, es además la estación más agradecida para empezar.

Este mes vuelvo a escribir sobre la trastienda del taller. El mes pasado conté que, aunque lo escriba la IA, detenerse a comprobar es tarea de una persona. Esto es la continuación. Durante el último año, empleando a fondo en el taller el llamado «vibe coding», he sentido tanto su potencia como un peligro exactamente del mismo tamaño. Y me topé con la pregunta que sospecho que muchos se están haciendo: ¿se puede llevar al taller, como una caja negra y sin mirar dentro, el código que ha producido una IA?

■ Dices «quiero algo así» y funciona

El vibe coding consiste en saltarse la especificación detallada: describes en lenguaje corriente lo que quieres, dejas que la IA lo escriba y te llevas algo que funciona. Durante el último año hemos construido así unas cuantas herramientas pequeñas para el taller. O más bien, generamos herramientas como quien respira.

Diré antes que nada que esto es realmente potente. Lo que antes quedaba aparcado con un «me gustaría, pero no hay tiempo para investigarlo» hoy funciona el mismo día en que se te ocurre. Lo que habría empezado por pedir presupuesto a una empresa externa toma forma en una pausa para comer. Para un taller pequeño como el nuestro no hay cambio más bienvenido.

■ Que funcione y que sea correcto son cosas distintas

Y, sin embargo, lo más temible de este año ha sido precisamente que sí funciona. Lo que sale suele funcionar. La pantalla se ve limpia, los números aparecen. Y como funciona, desde fuera no se distingue si es sólido o peligroso.

Un redondeo que en un punto es sutilmente distinto. Comportamiento indefinido cuando llega un valor fuera del rango previsto. Errores tragados en silencio, de modo que todo sigue como si nada hubiera pasado. Nada de esto se ve mirando una pantalla que funciona. Solo lo ven quienes han escrito ese tipo de código con sus propias manos y se han quemado con él.

Al final uno no se queda tranquilo hasta haber seguido todo el código que ha salido. El tiempo que se suponía ahorrado al delegar vuelve íntegro en forma de lectura. El listón para construir bajó enormemente; el listón para advertir el peligro, no. Esa asimetría es lo más claro que he aprendido este año. Dicho en nuestros términos, sería como plantarse ante un centro de mecanizado de 40 millones de yenes y decir «ha funcionado, así que vale». Eso no se permite jamás.

■ En un taller pequeño no existe la pieza ideal

¿Es entonces una herramienta inservible? En absoluto. En algunas partes de nuestro trabajo encaja mejor que ninguna. Pero para explicarlo tengo que dar un rodeo por la realidad de un taller pequeño.

En mi caso hago habitualmente algo un poco raro: genero NC —el lenguaje de la máquina— mediante vibe coding. Para escribir código que produzca NC se elige automáticamente Python casi siempre; en la mayoría de los casos yo lo sustituyo por Ruby. Es mi estilo.

Las máquinas herramienta NC modernas son extraordinariamente precisas. Dales un material ideal, una forma ideal y unas dimensiones ideales y sacarán un acabado que asombra. Pero en nuestro taller esos ideales casi nunca se dan. Hay que sacar el trabajo adelante con lo que se tiene a mano. El material es irregular; la forma y el tamaño cambian cada vez. La premisa misma del «según plano» no está delante de nosotros.

Yo lo llamo «el espíritu de apañárselas con lo que hay». Es la fuerza de un taller pequeño y nuestro orgullo, pero desde el punto de vista de quien escribe un programa resulta una verdadera molestia. Como las dimensiones cambian cada vez, no se puede escribir un procedimiento con números fijos en el código. En lugar de «corta esta forma a esta medida», hay que reescribirlo como «mide lo que tienes delante y deriva el corte de ese valor». Dicho de otro modo, hay que elevar bastante el nivel de abstracción. Esa es la parte más difícil de programar en un taller pequeño.

■ Perfecto para ajustarse a la pieza y para la ingeniería inversa

Y esta forma de trabajar —ajustarse a la pieza real— se parece al vibe coding en un grado sorprendente. No hay una especificación perfecta de partida; te vas acercando al objeto que tienes delante, cortando y probando, probando y volviendo a cortar. Haces que produzca algo que funcione, señalas lo que está mal, pides que se corrija y lo intentas otra vez. Como puedes mover las manos antes de que la especificación esté cerrada, encaja notablemente bien con un taller que se apaña con lo que hay.

Sobre todo, el vibe coding complementa bien la parte más difícil: elevar el nivel de abstracción. Le enseñas una versión con los números fijos y le pides algo que siga funcionando cuando cambien las dimensiones, y señala qué debería convertirse en variable. La parte de la generalización que a una persona le llevaba días —encontrar el ángulo de ataque— se despeja de un golpe. Es justo la capacidad que le faltaba a nuestro taller de apañárselas con lo que hay.

El otro buen encaje es la ingeniería inversa: hurgar desde fuera en un mecanismo que no entiendes y reconstruir la lógica que hay detrás. Para leer formatos de datos desconocidos, o código largo que alguien escribió hace mucho, y averiguar qué hace, resulta asombrosamente fiable. Es un terreno que de entrada no entendíamos, así que un error cuesta poco. Una vez que tienes el ángulo, una persona puede verificar el resto.

Un caso cercano: los programas NC que sacan los propios fabricantes de máquinas. Sinceramente, no me gustan mucho. Sin sangrado, con comentarios inútiles, sin manera de leer qué están haciendo. Un programa que no se puede leer es un programa que no se puede detener y comprobar. La IA cubre ese hueco. Le pides que añada sangrado y comentarios porque el código es difícil de leer, y vuelve exactamente así. Le dices que la abstracción es demasiado baja y le pides que lo divida en subrutinas, y reparte el código en bloques con sentido. El mismo comportamiento, ordenado en una forma que una persona puede leer: puede que sea el uso al que más recurrimos ahora mismo.

Lo que más nos fastidia es que en ninguna parte está escrito sobre qué variables tiene efectos secundarios una subrutina. La llamas y algo cambia. Pero qué cambia no se sabe hasta haberlo leído todo. Haces que la IA lo lea y le pides que enumere, en un comentario al principio, las variables que se escriben dentro, y las saca. Eso era trabajo de media jornada para una persona.

Un ejemplo concreto. A menudo hacemos que la IA rehaga los programas NC de nuestra máquina de electroerosión por hilo. Es tan cómodo que casi me sangra la nariz. En el mundo NC, aunque todos lo llamen «G-code», cada fabricante tiene sus propias costumbres de escritura: dialectos, en la práctica. Este modelo se escribe así; aquel necesita esta instrucción. Para una persona es cuestión de comparar manuales y aprender en el taller.

La IA lo deduce del estilo del programa que le entregas. Percibe las convenciones que sigue el código y escribe los añadidos con esas mismas convenciones. Dale además el manual del fabricante y empieza a usar macros propias de ese modelo sin que nadie se lo diga. Lee que «esta máquina ofrece esta instrucción» y la escribe sin inmutarse. Que ese conocimiento tácito, acumulado durante largos años en los talleres, pueda extraerse así, sinceramente, me dio escalofríos.

Pero un programa producido así no lo mandamos nunca directamente a la máquina. Depuramos. Siempre se prueba en la máquina real, línea a línea, comprobando con la vista los valores de las variables y el movimiento del hilo. Aquí es donde se gana el sueldo el M01 (parada opcional) del que escribí el mes pasado. Por bien que parezca el trabajo, si no se tiene la capacidad de depurarlo en la máquina real, no se puede usar esta herramienta. O mejor dicho, creo que no se debe. Usada como herramienta para producir respuestas correctas es peligrosa; usada como herramienta para encontrar el ángulo de ataque es formidable. Pero confirmar ese ángulo es siempre cosa de la persona.

■ ¿Debe ser una caja negra?

Con lo que volvemos a la pregunta del principio. ¿Se puede llevar al taller, sin mirar dentro, el código que ha producido una IA? Sinceramente, distinguimos entre los casos en que se puede y aquellos en que no. Por ahora la línea que trazamos es la del lugar que ocupa. Donde un error se puede advertir y corregir después, donde lo único que se pierde es tiempo, lo usamos sin seguirlo entero. Donde se mueve una máquina, se fijan dimensiones y se consume material —donde no hay segundo intento—, una persona lo lee todo, por largo que sea el rodeo.

Lo incómodo es que la caja negra no es solo la parte que escribió la IA. El software de hoy se construye llamando a gran cantidad de componentes: bibliotecas publicadas por alguien, en algún sitio, en GitHub y otros lugares. Hace muy poco hubo un incidente grande en el mundo de JavaScript. (De hecho, parece que aparecen puertas traseras casi a diario.) Una biblioteca sobre la que se apoya muchísimo software fue tomada por asalto y se le incrustó un mecanismo que se ejecutaba al instalarla y se propagaba al siguiente paquete. Al parecer, cientos de paquetes quedaron contaminados en cuestión de horas. Poco antes hubo casos de interceptación en tránsito para cambiar el destino de un pago; es decir, manipulación de la parte que maneja el dinero.

Le pides a una IA «algo así» y, naturalmente, elegirá e incluirá componentes cómodos. Parte de su rapidez viene de que no escribe ella misma esos componentes. Lo que recibimos, por tanto, es una estructura doble: dentro de la caja que escribió la IA se está llamando a la caja de otro. Ningún artesano corta un material sin saber qué lleva mezclado. Creo que con el software pasa lo mismo.

Esta pregunta —si se puede confiar en la caja de otro— no es nueva. A mediados de los años noventa, D. J. Bernstein, autor del programa de transferencia de correo qmail (nosotros mismos lo usamos hace más de diez años), no se fiaba ni siquiera de la biblioteca estándar de C, los componentes que vienen con el lenguaje y que todo el mundo emplea sin cuestionarlos. Dejó escrito en sus notas de diseño que había renunciado en buena medida a la biblioteca estándar y que había sustituido las partes donde más fácilmente ocurren los accidentes, como el manejo de cadenas y la gestión de memoria, por pequeños componentes propios desarrollados a lo largo de años. No llegó al extremo de rehacer el sistema operativo, pero en un punto fue tajante: pon bajo tu propio control las partes peligrosas.

Lo que recorre qmail es la idea de reducir al mínimo posible aquello en lo que hay que confiar. Además de escribir sus propios componentes, dividió el interior del programa en partes pequeñas por función, construidas de modo que ni siquiera sus propias partes se fiaran entre sí. Si una de ellas es tomada, no puede ir más allá. Alguien pensó todo esto hace treinta años. Por supuesto, no podemos imitarle escribiendo nosotros cada biblioteca. Pero la idea —traza tus fronteras dando por hecho que se colarán cosas poco fiables— vale igual hoy.

Y lo temible es que, si la caja es demasiado grande, no hay vuelta atrás. Si tomas como un único bloque grande algo que no entiendes por dentro, no podrás separarlo cuando ocurra algo. Así que la contramedida hay que tomarla en el diseño: mantenlo en una forma que siempre puedas sustituir. Esta parte se puede reemplazar por otra cosa; quita este componente y el conjunto sigue funcionando. Constrúyelo así y, el día en que pase algo, podrás tirar solo esa caja.

Lo que eso exige es capacidad de diseño en el sentido de la orientación a objetos. ¿Qué tratas como una unidad, qué expones al exterior, cuánto del interior ocultas? ¿Dónde trazas la frontera? Lo que antes se veía como «escribir con elegancia» se ha vuelto una necesidad práctica para no meter dentro cosas peligrosas. Precisamente porque la IA escribe el contenido, lo que hace falta es la capacidad de decidir la frontera.

Y esa línea se mueve si la dejas sola. Después de una racha en la que todo va bien, uno acaba queriendo hacer la caja más grande. Peor aún: la capacidad de advertir el peligro se embota en proporción exacta a lo poco que escribes tú mismo. Esta herramienta tiene la propiedad de que cuanto más la usas, menos capaz eres de ver a través de ella. Así que la línea hay que volver a trazarla del lado humano, no del lado de la herramienta.

■ Ingeniería de sistemas, más que programación

Mirando el año hacia atrás, esto es lo que más ha cambiado mi impresión: lo que de verdad será imprescindible a partir de ahora no es programar en sí, sino la ingeniería de sistemas.

Decidir qué construir y qué no construir. Trazar la línea entre lo que se delega en la máquina y el punto en el que toma el relevo el juicio humano. Preparar, antes de construir, cómo se vuelve atrás cuando deje de funcionar. Decidir dónde residen los datos y quién es responsable de ellos. Por lista que se vuelva, la IA no decidirá esto por ti, porque decidirlo exige conocer el trabajo del taller.

A medida que bajaba el tiempo dedicado a escribir código, empezamos a dedicar tiempo al diseño, a la explotación y a juzgar cuándo parar. Irónicamente, al desaparecer el esfuerzo de escribir se ve mucho mejor el peso del trabajo que viene antes de escribir.

■ Todos los procesos en casa, en Arita

En una empresa pequeña, quien lo construyó lo usa, y cuando se rompe lo arregla esa misma persona. Por eso importa mucho menos «¿podemos construirlo?» que «¿está esto dentro de lo que podemos mantener nosotros mismos?». Mantenlo a una escala que puedas restaurar por tus propios medios el día en que se pare. No es vistoso, pero creo que esto es lo que significa una DX hecha a tu medida.

Es exactamente la misma historia que fabricar egi. Los prototipos salen mucho más rápido que antes. Pero el paso de confirmarlos en el mar no se puede acortar de ninguna manera. Lo que decide al final si algo es bueno o malo es siempre el mar. Cuanto más rápido podemos construir, más tiempo dedicamos a confirmar: ese es el uso que hemos elegido.

En un pequeño pueblo de provincias —Arita, en la prefectura de Saga, Japón— seguimos fabricando egi en casa en todos sus procesos, desde el diseño hasta el corte de los moldes, la producción en serie y la venta. Eso es lo que me ha hecho pensar agosto. Componentes escritos por alguien en algún lugar del mundo se ejecutan dentro de nuestro propio taller, y una IA lee los dialectos de nuestras máquinas. En medio de todo eso, ¿qué debe quedar en manos humanas? La respuesta no está ni a medias, pero no pienso dejar de pensarlo.

■ Al mar este mes

Septiembre nos trae una tanda de colores y productos nuevos. Akazamurai Meteor Glow Orange es un naranja que cambia de expresión entre el brillo fosforescente y la iluminación UV; está previsto que salga este mes. JetChaser Purple Edition, pensado para el tip-run desde orilla, también es de este mes. Además, JetChaser size 3.0 y size 3.1 salen a la venta general, con envíos previstos para finales de septiembre.

Este año se cumplen además quince años desde que nació el color «Akazamurai» de EgiSharp. A finales del mes pasado publicamos las imágenes de un color conmemorativo del decimoquinto aniversario. Que se haya seguido eligiendo durante quince años no es mérito de nuestra confianza: es la respuesta que han dado quienes lo han usado.

Por listas que se vuelvan las herramientas, quien juzga al final es una persona, y lo que decide si algo es bueno o malo es el mar. Lo tendremos presente y seguiremos fabricando, paso a paso. Gracias de nuevo por su apoyo este mes.

Septiembre de 2026
KeyStone Corporation
Nobuhide Kanagawa, Director Representante