Los primeros proyectos de ingeniería aburrida de la IA empiezan con TikZ

Las dos de la madrugada, quedan seis horas para la fecha límite de entrega del artículo. Estás mirando fijamente la tercera figura — el diagrama de arquitectura de la red neuronal — ajustando las coordenadas de \draw por enésima vez. Cambias (4.5,3.2) por (4.6,3.1), compilas, miras el PDF, no está bien, vuelves atrás, compilas otra vez. Recuerdas que tu director de tesis dijo que «las figuras tienen que quedar bonitas para que los revisores se molesten en leer», así que sigues ajustando, y el reloj marca las tres.

Cualquiera que haya escrito un artículo en LaTeX ha vivido esta escena. TikZ es el estándar de facto para dibujar gráficos académicos en el ecosistema LaTeX, pero es un «lenguaje gráfico», no una «herramienta gráfica» — el propio autor Till Tantau lo dejó claro en la documentación: TikZ ist kein Zeichenprogramm (TikZ no es un programa de dibujo). Dibujas con código, y cada microajuste de coordenadas requiere recompilar el documento entero. La academia lleva décadas cargando con esto.

En junio de 2026, un desarrollador llamado Dominik Peters publicó en HN un proyecto: TikZ Editor — un editor WYSIWYG de gráficos TikZ donde puedes arrastrar nodos como en Figma y el código fuente se actualiza sincrónicamente. 293 puntos, 58 comentarios. Lo que de verdad hace que este proyecto merezca debate es cómo fue construido.

«Cosas que ningún humano querría hacer»

Dominik Peters escribió en su post de Show HN una frase que equivale a la tesis central del proyecto:

This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.

Traducido a un lenguaje más directo: para hacer un editor de TikZ con drag & drop necesitas reimplementar la mayor parte de los mecanismos de bajo nivel de TikZ — parser, renderer, sistema de layout, procesamiento de color. Es una tarea de ingeniería con un ROI absurdamente bajo. Nadie en su sano juicio la aceptaría.

Pero Codex la aceptó. El proyecto entero — incluyendo la interfaz frontend, la aplicación de escritorio Tauri, el parser de sintaxis TikZ, el pipeline de renderizado SVG en JavaScript, los múltiples convertidores de formato (SVG/PPTX/IPE → TikZ) y esas «misiones secundarias» casi demenciales — fue generado casi por completo con Codex. Dominik empezó a trabajar en el proyecto en febrero de 2026, consumió unos 700 millones de tokens, lo que a precio de API serían unos 15.000 dólares — aunque él solo pagó unos 500 dólares de suscripción a ChatGPT.

La cadena lógica es clara: cuando el coste de desarrollo tiende a cero, proyectos que antes «no merecían la pena» de repente la merecen. La proposición en sí no es nueva. Pero TikZ Editor ofrece un caso con suficiente precisión como para que podamos desmontarlo y ver qué tipo de trabajo de ingeniería se ha externalizado realmente a la IA — y qué es lo que no se ha externalizado.

Dos categorías de trabajo de ingeniería externalizado

El trabajo de implementación de TikZ Editor se puede dividir en dos categorías. Conviene distinguirlas.

Primera categoría: conversión mecánica de formatos. Esto incluye los convertidores SVG → TikZ, PPTX → TikZ, IPE → TikZ. La complejidad lógica de estos convertidores no es baja — mapear los comandos de trazado de SVG a la sintaxis \draw de TikZ, traducir el modelo de formas de PowerPoint a los nodos y caminos de TikZ — pero en esencia se trata de ingeniería de reglas de mapeo y condiciones de contorno. Las reglas se pueden enumerar, los bordes se pueden cubrir con casos. Puedes imaginar a un ingeniero experimentado haciéndolo en tres semanas y, al terminar, sin sentir que ha ganado ninguna intuición profunda. En este tipo de tareas, las herramientas de codificación con IA funcionan de forma relativamente fiable, porque la verificación es binaria: ¿el TikZ convertido compila? ¿El resultado del renderizado coincide con el formato original?

Segunda categoría: reimplementar algoritmos clásicos en un dominio ajeno. Esta es la categoría más interesante. Dominik mencionó en su post varias «misiones secundarias», dos de las cuales merecen ser desarrolladas:

1. Reimplementar el algoritmo de partición de líneas de LaTeX (Knuth-Plass). Para soportar nodos de texto multilínea, TikZ Editor necesitaba implementar la partición de líneas y la separación silábica correctas en el lado del navegador (entorno JavaScript). Esto implica reproducir el algoritmo de programación dinámica de partición de líneas que Donald Knuth y Michael Plass publicaron en 1981 — un algoritmo que optimiza globalmente la «maldad» (badness) del párrafo, no un simple relleno greedy de líneas. El text-align: justify de CSS solo hace partición greedy línea por línea, con resultado tosco; el algoritmo de TeX calcula el óptimo global, manejando el estiramiento y contracción del pegamento (glue) entre palabras, penalizaciones de guionado y una función de puntuación estética del párrafo completo.

2. Implementar el sistema de mezcla de colores red!20!black. En los artículos LaTeX, los colores se expresan frecuentemente con la sintaxis {color1}!{proporción}!{color2}, por ejemplo red!20!black significa 20% rojo mezclado con 80% negro. Implementar un selector de color en el navegador que soporte esta sintaxis implica hacer ingeniería inversa del modelo de mezcla exacto desde el paquete xcolor, manejando conversiones RGB/CMYK, cálculos de transparencia y anidamiento del operador ! (como red!20!blue!50!green).

Agrupamos estas dos tareas en la misma categoría porque comparten una propiedad: si no las haces, la funcionalidad queda incompleta; si las haces, la capacidad central del producto no se vuelve más clara por ello. Esto es «ingeniería aburrida» en estado puro — no es que no sea importante, es que el ROI es demasiado bajo. La primera reacción de un ingeniero humano ante este tipo de tarea es «¿hay alguna librería que me lo resuelva?». Si no la hay, la funcionalidad suele acabar etiquetada como WONTFIX.

El comportamiento de las herramientas de codificación con IA en este escenario es particularmente revelador. Dominik compartió en los comentarios de HN su flujo de trabajo concreto: primero procesaba el mismo lote de figuras TikZ con el motor LaTeX (dvisvgm) y con el renderer JavaScript, y luego comparaba manualmente las diferencias, indicándole a Codex dónde estaban mal las cosas para que las corrigiera. Intentó usar modelos multimodales para la comparación automática y no funcionó — los modelos «todavía están un poco ciegos; incluso ante dos imágenes claramente distintas las consideran iguales».

Aquí hay un detalle sutil: el papel del humano en el loop es emitir juicio. Juicio sobre qué diferencia de renderizado es un bug, cuál es una desviación normal del renderizado de fuentes y cuál es aceptable. El humano no ha desaparecido; simplemente ha pasado de ser implementador a ser juez de calidad.

La segunda mitad de la frase de Armin Ronacher

El día antes de que se publicara TikZ Editor, Armin Ronacher — autor de Flask y Jinja2 — escribió en su blog «The Coming Loop» un pasaje que dialoga con precisión con este caso:

I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

Y luego gira el argumento:

On the other hand using that same looping methodology to write lasting code does not yet sit well with me.

La preocupación central de Ronacher es: cuando el harness loop gira continuamente, cada iteración añade una defensa local y el código crece sin supervisión humana, el producto final se convierte en un organismo que necesita ser mantenido por sí mismo. Lo llama «el paso del software como máquina determinista al software como organismo» — lo monitorizas, lo estabilizas, pero no lo entiendes.

Pero hay otra frase suya que quizá sea más clave:

Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.

Ronacher sostiene que el loop ya funciona bien en dos escenarios: transformación de código (code transformation: porting, benchmark, escaneo de seguridad) y código que no necesita ser longevo (proof-of-concept, exploración experimental).

Aquí aparece una correspondencia interesante que podemos trazar:

Categoría	Tarea representativa	¿La IA es buena?	Motivo
Transformación mecánica	Portar código, convertir formatos	Sí	Mapeos enumerables, verificación binaria
Ingeniería aburrida	Reimplementar Knuth-Plass, mezcla de colores	Sí	Lógica determinada, interfaz clara, ROI demasiado bajo para humanos
Decisiones de arquitectura	Estructura del proyecto, niveles de abstracción	Incierto	Implica sopesar valores
Decisiones de diseño	Qué dibujar, cómo maquetar	No sustituible	Requiere intención y juicio estético

TikZ Editor cruza exactamente las dos primeras filas. La conversión de formatos está en la primera; la reimplementación de algoritmos, en la segunda. Y la arquitectura del proyecto — Dominik dijo que «primero validé la viabilidad arquitectónica con un parser mínimo → renderer SVG + drag & drop básico» — esa decisión la tomó él. Codex solo intervenía en modo plan para plantearle opciones entre las que elegir.

Qué figura dibujar es decisión del usuario. El editor proporciona la herramienta, no la estética.

«El loop requiere claridad» — esta frase encaja perfectamente sobre TikZ Editor

Ronacher escribió al final de su artículo una frase que releímos tres veces:

Adopting the idea of harness loops means that the harness decides when work is finished.

En el desarrollo de TikZ Editor, «cuándo está arreglado» lo decidió siempre Dominik. Ponía las salidas de los dos renderers lado a lado, examinaba las diferencias y le decía a Codex qué seguía estando mal. La condición de parada del loop la define una persona que sabe qué aspecto tiene el resultado correcto. Esto es lo que Ronacher llama «la premisa del loop es la claridad»: tienes que haber pasado por suficientes versiones mediocres para saber qué es lo correcto. El agente puede acortar la parte aburrida del proceso de ensayo y error, pero no puede definir por ti qué significa «correcto».

La misma lógica se aplica al usuario final de TikZ Editor. Un investigador abre el editor para dibujar la representación de una esfera de Bloch para un estado cuántico, o un diagrama del mecanismo de self-attention de un Transformer — el aspecto que deben tener esas figuras es una intención que ya está en su cabeza. El agente no puede decidir por ti cómo debe maquetarse la figura central de tu artículo, qué flujo hay que enfatizar o si el color debe ser verde o gris. Solo te evita tener que escribir a mano coordenadas como \draw[->] (-0.866,-0.5) -- (0.866,0.5) una vez que ya tienes la idea.

Dicho de otro modo: la ingeniería aburrida se puede externalizar a la máquina; el juicio de significado debe permanecer en manos humanas. Esta es la proyección precisa, sobre el caso concreto de TikZ Editor, de la frontera actual de capacidad de las herramientas de codificación con IA.

La parte optimista, y la parte incierta

No queremos que este análisis se lea como un término medio barato — «la IA tiene su lado bueno y su lado malo». TikZ Editor es algo genuinamente bueno. Resuelve un problema que llevaba décadas sin solución en el mundo académico, y lo hace con código abierto (licencia MIT), multiplataforma (Web + escritorio Linux/Windows/macOS) e incluso permite abrir un archivo .tex completo para editar directamente sus figuras TikZ. Uno de los comentarios más votados en Hacker News fue el de un doctorando alemán: «Todos los estudiantes e investigadores de STEM te lo agradecemos.»

La parte incierta es hasta dónde puede llegar este paradigma.

Dominik consumió 700 millones de tokens para hacer este proyecto. Ronacher teme que la calidad del código generado por los modelos esté empeorando — demasiado defensivo, razonamiento local, evita invariantes. Pero en el caso de TikZ Editor, un observador en GitHub comentó que «la estructura del código parece bastante buena». ¿Dónde está la diferencia?

Nuestra hipótesis es esta: el grado de nitidez de la frontera de la tarea determina la calidad del resultado. El algoritmo Knuth-Plass recibe texto y ancho de línea como entrada y produce posiciones de salto de línea — la corrección se puede verificar visualmente en el resultado del renderizado. La mezcla de colores recibe dos colores y una proporción y produce un color — el acierto o error se ve a simple vista. El parser de TikZ recibe texto y produce un AST — mientras el render no rompa y las coordenadas cuadren, es correcto.

Cuando el criterio de verificación se puede visualizar, el loop es más fiable. Cuando el criterio de verificación requiere juicio experto, el loop necesita al humano.

Esto no es un dilema sobre «creer o no creer» en la IA. Es una proposición de ingeniería: ¿qué tipo de tareas se pueden verificar automáticamente? Si la respuesta es «se pueden verificar automáticamente», el agente es adecuado para encargarse. Si la respuesta es «requieren juicio humano», el valor del agente está en acelerar cada vuelta del ciclo, pero sin poner el punto final por ti.

De «ingeniería aburrida» a «ingeniería que merece la pena»

Volvamos a la frase de Dominik — «este es el tipo de tarea que ningún humano querría hacer». El subtexto más interesante de esta frase es: no es que no se pudiera hacer, es que no se quería hacer.

El algoritmo de partición de líneas de TeX existe desde 1981, la descripción algorítmica en la literatura pública es completa y hay más de una implementación en JavaScript. El modelo de mezcla red!20!black está descrito con claridad en el código fuente de xcolor. El problema no es que «nadie pueda implementarlo», el problema es que «nadie quiere pasarse cuatro semanas haciendo algo que solo contribuye un 2% al valor central del producto final».

Las herramientas de codificación con IA están cambiando este cálculo. Cuando el coste temporal de ese 2% de valor marginal pasa de cuatro semanas a cuatro horas — o incluso cuatro minutos —, la tarea deja de ser «no merece la pena» y se convierte en «de paso, lo hago». Esto no significa que el rol del humano en el desarrollo de software desaparezca — significa que el humano puede concentrarse más en decidir qué hacer, dejando las partes aburridas del cómo hacerlo a la máquina.

La última frase de Ronacher, en cierto sentido, describe la cara negativa de lo mismo: cuando el «qué hacer» también se le entrega a la máquina, corremos el riesgo de perder la capacidad de entender el sistema. Las dos frases juntas se acercan más a la verdad que cualquiera de ellas por separado.

La página de GitHub de TikZ Editor sigue actualizándose. Dominik dice que el siguiente paso quizá sea añadir soporte para pgfplots. No diremos que «la codificación con IA está remodelando el desarrollo de software» — esa formulación es demasiado genérica. Pero sí podemos decir que: cuando un algoritmo de partición de líneas de TeX que ningún humano quería reescribir es implementado por un agente en unas pocas conversaciones y funciona correctamente renderizando nodos multilínea en el navegador, se ha cruzado un cierto umbral. Lo que merece atención a partir de ahora no es «¿puede la IA programar?», sino «¿qué decisiones de ingeniería no deberíamos externalizar nunca y cuáles dan igual?».

Esa propia distinción quizá sea la pregunta que más seriamente merezca ser pensada en la ingeniería de software de los próximos años.