ArtCraft: haz que la IA trabaje por ti

Vistas: 1
0:00 / 0:00
ArtCraft: haz que la IA trabaje por ti

Llevo más de veinte años usando GIMP e Inkscape para todo lo que hago, y en ese tiempo he visto pasar la misma conversación un montón de veces: que si esta herramienta va a acabar con Photoshop, que si aquella va a acabar con Word, que si la de más allá va a acabar con AutoCAD. Nunca ha pasado. Y no ha pasado por una razón muy sencilla: la gente no cambia de herramienta por ideología, cambia cuando el flujo de trabajo le encaja. GIMP es libre, es maduro y hace cosas que Photoshop no hace, pero quien lleva quince años con Photoshop delante no se pasa a GIMP porque se lo pida un artículo.

Así que cuando salió ArtCraft y medio internet empezó a titular que si los clones libres de Office, que si el fin de Adobe, me quedé frío. Primero, porque las alternativas libres ya existían y seguían ahí. Segundo, porque el titular se equivoca de sujeto. La cosa no va de que ArtCraft sustituya a Photoshop. Va de que tú dejas de ser quien se sienta delante de Photoshop.

Ese es el cambio de enfoque del que quiero hablarte hoy, y es el único que me parece interesante de verdad.

La IA no sustituye al programa: te sustituye a ti en el programa

Piénsalo un momento. Cuando alguien dice «esta herramienta va a acabar con Word», está imaginando a una persona delante de Word, con el mismo ratón y los mismos menús, pero con otro logo en la esquina. Eso no ha funcionado nunca, ni con LibreOffice, ni con OnlyOffice, ni con nada. La gente que necesita Word sigue necesitando Word porque necesita el formato, las macros, la plantilla de la gestoría o el control de cambios que todo el mundo entiende.

Lo que sí puede cambiar es quién está sentado ahí. Y eso es exactamente lo que ofrecen estas aplicaciones: no un Word mejor, sino un Word al que le puedes decir «hazme el documento». Tú escribes la petición, el agente redacta, aplica estilos, mete las secciones, mueve los gráficos y guarda el fichero. Tú lo abres después, lo revisas y lo corriges, igual que cuando le pides una presentación a un compañero de trabajo.

La diferencia con un compañero es que este no se queja, no tiene agenda y no se cansa a las once y media de la noche. La diferencia con un modelo de lenguaje suelto es que este tiene manos: puede tocar el documento de verdad, no solo escribir texto en un chat que luego copias y pegas a mano.

Y ahí está la clave de todo el episodio. Un modelo que escribe texto te ahorra mecanografía. Un modelo que maneja la aplicación te ahorra el trabajo.

Veinte años con GIMP y el argumento que no me vale

Antes de seguir, una aclaración, porque me parece honesta. Yo no necesito ArtCraft para mi trabajo diario. Mi documentación está en Markdown, mis presentaciones en Typst, mis imágenes las saco con GIMP y mis vectores con Inkscape. Con eso llevo años y me va bien. He trabajado con organismos oficiales con LibreOffice y plantillas propias, y te puedo asegurar que la mayoría de la gente que usa Word lo usa como si fuera una máquina de escribir: sin estilos, sin índices, sin referencias cruzadas.

Dicho eso, hay dos cosas que sí me interesan, y son las que me han hecho grabar este episodio.

La primera es que hay muchísima gente que no es como yo. Gente que lleva toda la vida con Photoshop y que no va a aprender GIMP a estas alturas, no porque GIMP sea peor, sino porque su cabeza ya está cableada a otra cosa. Para esa gente, una herramienta con la que hablar en lugar de una herramienta con la que pelear es una salida real.

La segunda es más de fondo: si el que maneja la aplicación es un agente, el formato deja de importar tanto. Da igual que la app sea un clon de Word o un editor de texto plano, porque el que va a sufrir los menús es el modelo, no tú. Ahí se abre una puerta que no existía, y esa puerta es la que me interesa.

Qué es ArtCraft, y por qué el nombre de la organización no es el que dije

ArtCraft es el nombre visible de una organización de GitHub que se llama storytold, en https://github.com/storytold. En el audio digo «story town», que es como me suena al leerlo rápido, pero el slug real es storytold. Su descripción es bastante clara: herramientas y modelos de código abierto para gente que fabrica cosas, para constructores y para creativos. La web del proyecto es https://getartcraft.com.

Dentro de esa organización hay dos mundos que, según el propio proyecto, no se mezclan. Por un lado está el estudio de creación con IA, que es un producto aparte, de pago por créditos, disponible en la nube, macOS y Windows, pero no en Linux. Por otro lado está la suite de aplicaciones de escritorio, las Crafting Apps, que es de lo que vengo a hablar y que sí es libre.

Los datos de la organización, consultados el 11 de noviembre de 2026 directamente en GitHub: 80 repositorios públicos, de los cuales 5 están archivados, unos 69.500 seguidores y 6 miembros públicos. La fecha de creación de la organización no la he podido verificar, así que no te la voy a inventar.

La licencia es doble, MIT o Apache 2.0, a elección tuya. Y aquí hay un matiz que conviene contar porque despista: la API de GitHub muestra solo Apache-2.0 como licencia del repositorio, porque su detector se queda con una. Los ficheros LICENSE-MIT y LICENSE-APACHE están ahí, y los README lo dicen con todas las letras. En la práctica, con MIT puedes hacer prácticamente lo que quieras, incluido empaquetar y vender.

Una suite de diecisiete apps, no trece

Y llegamos al primer punto que conviene ajustar. En el audio hablé de 13 aplicaciones: era la cifra que manejaba cuando preparé el material, y también la que repiten muchos medios. La web oficial, sin embargo, dice literalmente «Seventeen apps. One craft.» y lista diecisiete. El README de WordCraft lista dieciséis más una comunitaria, y el lanzador de la suite añade otra más.

Mi hipótesis es que esa cifra sale de contar las apps que ya tenían publicado su docs/mcp.md, no las que existen, y de ahí pasó a los medios.

Así que quedamos en 17 aplicaciones verificadas. Y con 17, el número de herramientas del que hablo más abajo se queda todavía más corto de lo que ya era.

La suite, app por app

Esta es la tabla que me habría gustado encontrar cuando empecé a mirar. La columna del equivalente es orientativa: qué programa propietario imita o sustituye, no una promesa de paridad. La columna de MCP dice si el repositorio publica documentación de servidor MCP y qué herramientas expone.

AppEquivalente orientativoQué haceMCP
WordCraftMicrosoft WordTextos, .docx nativo, exporta PDF422 comandos; execute, batch, inspect_document
GridCraftMicrosoft ExcelHojas de cálculo, .xlsx con estilos y gráficosread_range, write_range, insert_chart, create_table
DeckCraftMicrosoft PowerPointPresentaciones .pptx, exporta PDF200+ comandos; add_slide, insert_chart, export
PhotoCraftAdobe PhotoshopImagen por capas, PSD realesdoc_open, doc_save, doc_export, command_run
VectorCraftAdobe IllustratorIlustración vectorialDocumentado, tools no detalladas
FilmCraftAdobe PremiereVídeo no lineal, color y sonidoNo verificado
LightCraftAdobe LightroomBiblioteca y revelado RAWDocumentado, tools no detalladas
PdfCraftAdobe AcrobatCombinar, dividir, proteger PDFdoc_combine, doc_optimize, comments_summarize
EffectCraftAdobe After EffectsMotion graphics y VFXDocumentado, tools no detalladas
AniCraftAdobe AnimateAnimación vectorial 2DDocumentado, tools no detalladas
DesignCraftAdobe InDesignMaquetación editorialDocumentado, tools no detalladas
FigCraftFigmaDiseño de interfacesDocumentado, tools no detalladas
CADCraftAutoCAD / DraftSightCAD y dibujo técnico 2Dlist_commands, save, screenshot y dibujo
SoundCraftPro Tools / AuditionAudio: grabación, edición, mezclaDocumentado, tools no detalladas
TextureCraftSubstance 3D PainterTexturas 3DNo verificado
MaterialCraftSubstance 3D DesignerMateriales proceduralesNo verificado
Craft Anything—Explorador y constructor de softwareNo verificado

Fuera de esas diecisiete quedan el estudio de imagen y vídeo, el lanzador de la suite y dos apps comunitarias: SolidCraft, de CAD paramétrico 3D, y MailCraft, de correo y calendario. Esas no las cuento como parte de la suite.

Rust nativo, egui y un binario por app

Lo técnico importa más de lo que parece, así que te lo cuento rápido. Cada aplicación es un programa en Rust con interfaz propia sobre egui y wgpu. No hay Electron, no hay Tauri, no hay vistas web metidas dentro de una ventana. Eso se nota en el arranque, en el consumo y en el tamaño.

Los paquetes que publican son de los que gustan en Linux: AppImage para x86_64 y aarch64, Flatpak desde un remoto OCI propio, .deb, .rpm, repositorio para Arch y tarballs. WordCraft publica además para riscv64. En macOS hay .dmg universal firmado y notarizado; en Windows, MSI y portátil para x64, arm64 y también x86 de 32 bits; y en FreeBSD, tarballs para x86_64 y aarch64.

Y luego está la parte que casi nadie comenta: la compilación a WebAssembly. La web del proyecto afirma que 16 de las 17 apps corren en el navegador. La excepción es FilmCraft, que es justo la que más potencia necesita. Con el catálogo actual son 16 de 17, y la excepción sigue siendo la misma.

MCP en dos minutos, para quien llegue nuevo

MCP son las siglas de Model Context Protocol, el protocolo abierto para conectar aplicaciones de IA con sistemas externos. La documentación oficial lo explica con una analogía que funciona muy bien: es el USB-C de las aplicaciones de IA. Un conector estándar para enchufar cosas distintas.

Por debajo es JSON-RPC con mensajes UTF-8 y dos transportes. Uno es stdio: el cliente lanza el servidor como subproceso y habla por la entrada y la salida estándar, con los logs aparte, en stderr. El otro es Streamable HTTP: un único endpoint que acepta POST y GET, con streaming opcional por SSE. La versión de referencia que documentan estas apps es la 2025-06-18, con compatibilidad hacia atrás con clientes de 2025-03-26 y 2024-11-05.

Si has oído hablar de MCP en los últimos meses y te ha parecido humo, te entiendo. Yo también he visto mucha presentación con flechas y poca cosa que funcione. La diferencia aquí es qué hay al otro lado del conector.

El detalle que lo cambia todo: todo es un comando

La decisión de diseño que hace útil esta suite no es «hemos añadido MCP». Es que toda la aplicación está construida sobre comandos con identificador estable. La misma orden que dispara un botón de la cinta, un atajo de teclado o el buscador de comandos se puede invocar desde la línea de comandos, desde un canal de control JSON o desde el servidor MCP.

Eso convierte el servidor MCP en una capa fina sobre el motor, y tiene tres consecuencias muy prácticas.

La primera: no hay un «ArtCraft MCP» que instalar aparte. Cada app trae el suyo dentro del binario de línea de comandos. Se arranca con wordcraft-cli mcp, gridcraft-cli mcp, deckcraft-cli mcp, y así con todas.

La segunda: hay dos modos de trabajo. En modo headless el servidor trabaja sobre un fichero, sin ventana. En modo remoto se conecta a la aplicación que ya tienes abierta, arrancada con --control PUERTO y enganchada con --connect PUERTO. En remoto el agente puede además hacer clic, teclear y capturar pantalla, porque está manejando la interfaz de verdad.

La tercera: el aislamiento de ficheros es homogéneo en toda la suite. --automation-read-root y --automation-write-root funcionan igual en todas las apps, de modo que una sola configuración de cliente te sirve para varias.

Registrarlo en Claude Code es una línea, la que da el propio README:

claude mcp add wordcraft -- wordcraft-cli mcp

Y hay detalles de robustez que denotan que esto no se escribió en una tarde. La salida estándar solo lleva mensajes MCP válidos, los logs van a stderr. Un UTF-8 inválido devuelve un error JSON-RPC -32700 sin tumbar el servidor; argumentos malos, -32602. Y las mutaciones con resultado incierto no se reintentan solas: se devuelve outcome unknown y se pide inspeccionar antes de repetir. Eso es justo lo que quieres cuando el agente está guardando un documento de treinta páginas.

Verificar sin mirar píxeles

Hay una herramienta que me parece la más importante de todas y que casi nunca se menciona: la inspección. inspect_document en WordCraft o inspect_workbook en GridCraft devuelven el estado del documento como datos estructurados. El agente puede comprobar lo que ha hecho sin depender de una captura de pantalla ni de que tú mires.

Piensa en lo que eso significa. Un agente que escribe a ciegas y luego te pide que mires tú no es un ayudante, es un pasante. Un agente que puede leer el documento que acaba de generar, contar secciones, comprobar estilos y corregir lo que ha quedado mal, eso sí es otra cosa.

La demo de los dinosaurios

Vamos a lo práctico, que es lo que importa. Le pedí a mi agente, que en mi caso es OpenCode, un documento de Word sobre la desaparición de los dinosaurios: qué desapareció, cuándo, cómo y por qué. Nada más. No le di plantilla, no le di estilo, no le di estructura.

El agente se conectó al servidor MCP de WordCraft y montó el documento él solo: título, encabezados, secciones, un par de páginas de texto. Y aquí viene lo interesante: se inventó una sección final sobre por qué importa hoy la extinción de los dinosaurios, con una reflexión sobre la fragilidad de los ecosistemas. No se lo pedí. Lo consideró oportuno.

Eso tiene dos lecturas. La buena es que el modelo aporta criterio y no se limita a rellenar. La mala es que si no acotas, decide por ti. Y como el documento se genera en segundos, corregir es barato: le dices que quite esa sección y punto.

Después le pedí que aplicara «un estilo espectacular», con esas palabras, sin más detalle. Eligió una paleta, tamaños de título, tamaños de subtítulo, espaciados. No es lo que yo habría elegido, pero el documento dejó de parecer un borrador. Y si tienes una plantilla de estilos propia, se la das y la usa; ahí es donde esto se vuelve serio para un trabajo profesional.

Luego, dos órdenes en la misma frase: desarrolla con más profundidad las posibles causas y quita el apartado de por qué importa hoy. Hizo las dos. Añadió el impacto del asteroide, el invierno de impacto, las secciones de consecuencias; eliminó la que sobraba; me preguntó si quería una conclusión de cierre y, como dije que sí, la escribió. El resultado final tenía línea temporal, causas, quiénes sobrevivieron y conclusión.

Y todo eso sin abrir la aplicación ni una vez. Yo la abrí solo para grabarla en el vídeo, porque quería que vieras cómo había quedado. Para trabajar, no hace falta ventana: el fichero se genera, se guarda y se abre cuando a ti te apetezca.

El cuadro de mando en GridCraft

Con la hoja de cálculo hice otra prueba. Le pedí un cuadro de mando con datos mensuales de las plataformas donde publico: YouTube, Spotify, RSS. Con seguidores, con cuota, con gráficos, ordenado por trimestres y con una previsión al final.

Lo montó. Y quedó resultón, con sus gráficos y todo. Ahora la parte honesta: los datos eran inventados, porque no le di acceso a ninguna fuente real. El modelo rellenó los huecos con lo que le pareció plausible, que es exactamente lo que hace un modelo cuando le pides números y no le das datos.

Con eso en mente, la demo deja de ser una demo y se convierte en un patrón. Conectas el modelo a la fuente real —tu analítica, tu base de datos, tus ficheros— y conectas el modelo a GridCraft. Le pides el informe. Él extrae, cruza, monta la tabla, inserta los gráficos y te lo deja listo para exportar. Y cuando alguien te lo pida otra vez al mes siguiente, no lo rehaces: le dices que actualice y ya está.

Ese es el cambio de fondo. No es «una hoja de cálculo con IA dentro». Es una hoja de cálculo que otro maneja por ti mientras tú decides qué historia cuentan los números.

El clon de atareao.es en FigCraft

La demo que más me sorprendió fue la de FigCraft, que es la alternativa a Figma. Le dije que mirara cómo estaba hecha atareao.es y que me hiciera un modelo igual.

Lo hizo. Y no solo eso: lo hizo en modo claro y en modo oscuro. La maqueta reproducía la estructura de la web, con sus bloques y su jerarquía, sin que yo tocara nada.

Aquí hay dos usos que me parecen muy valiosos. El primero es el camino inverso: una vez tienes la maqueta, vas modificando las partes que quieras y las conviertes a HTML para llevarlas a tu web. El segundo es para quien no programa: si sabes cómo quieres tu página pero no sabes montarla, generas el boceto, lo ajustas y se lo pasas a alguien que lo programe. O se lo pasas al propio modelo para que lo programe.

Y sí, el resultado hay que revisarlo. Una maqueta generada se parece mucho a tu web hasta que la miras de cerca. Pero de eso a empezar con un lienzo en blanco hay un trecho.

La presentación en DeckCraft

Con DeckCraft, el equivalente a PowerPoint, fui aún más escueto. Le pedí una presentación y no le di nada más: ni número de diapositivas, ni esquema, ni plantilla.

Me montó una presentación completa, con la secuencia de diapositivas que contarían el tema de principio a fin, del tipo de las que se pasan en una charla. Exportable a PDF, con notas y handouts, y en .pptx si la quieres abrir en PowerPoint.

Yo no intervine prácticamente nada. Y ahí está la gracia y el peligro a la vez: cuando no intervienes, el resultado es correcto pero genérico. Cuando le das tu plantilla, tus colores y tu estructura, deja de ser genérico. La diferencia entre las dos cosas es la misma que entre pedirle a alguien «hazme algo sobre esto» y darle el guion.

EffectCraft, o cuando el que no sabe de diseño soy yo

También probé EffectCraft, que es el equivalente a After Effects: motion graphics y VFX.

Le pedí una presentación animada, un corto pequeño, sobre atareao con Linux, con su música. Salió. Y salió regular, todo hay que decirlo. Le fui pidiendo cambios —esto de otra manera, aquello más grande— y fue mejorando, pero el punto de partida era flojito.

La razón no es la herramienta. La razón es que yo no tengo el lenguaje para pedir diseño en movimiento. Con WordCraft o con GridCraft sé exactamente qué pedir porque llevo años haciendo documentos y hojas. Con animación no tengo vocabulario: no sé decir «dale más aire», «baja el ritmo del corte», «suaviza la entrada». El modelo hace lo que puede con lo que le dices, y si le dices poco, hace poco.

Eso me parece un aviso útil: estas herramientas amplifican tu criterio. Si lo tienes, el resultado sube. Si no, el resultado es el que sería tuyo, solo que más rápido.

Las 795 herramientas y la factura en tokens

Ahora la parte que casi nadie cuenta y que a mí me condiciona el uso diario: el coste de tener todo enchufado.

Las aplicaciones que probé suman 795 herramientas. Ese número es mío, de la grabación, y no lo he podido contrastar con ninguna fuente oficial, así que tómalo como orden de magnitud y no como dato. Lo que sí está verificado, app por app, apunta en la misma dirección: WordCraft expone 422 comandos, DeckCraft más de 200, GridCraft tiene 513 funciones de hoja de cálculo en su inventario de paridad. Con 17 aplicaciones, la suma real es mayor que 795.

¿Y qué supone eso? Cada herramienta que anuncias a un modelo ocupa contexto: su nombre, su descripción, su esquema de argumentos. Antes de que escribas la primera palabra, ya has pagado. Y no solo en dinero: también en calidad, porque un modelo con 795 opciones delante elige peor que uno con doce. Es el mismo problema que tienes tú con un menú de restaurante de cuatro páginas.

Por eso lo que hago es conectarlas de una en una. Tengo el listado de servidores MCP y voy activando el que toca: si voy a escribir, WordCraft; si voy a tocar un PDF, PdfCraft; si voy a montar una hoja, GridCraft. Las demás, apagadas.

No es una limitación del proyecto, es física del contexto. Y es una decisión de diseño que tú tomas: montas un perfil pequeño por tarea y lo cambias cuando cambias de tarea. Si trabajas con un cliente que solo usa documentos, tienes un perfil de un solo servidor y vas sobrado.

El estado real: alfa, y bien alfa

Aquí es donde hay que bajar el entusiasmo, y prefiero hacerlo yo antes de que lo descubras tú.

Todas las apps están por debajo de la versión 1.0. El 11 de noviembre de 2026, WordCraft iba por la 0.18.0, GridCraft por la 0.19.0 y DeckCraft por la 0.18.0. AniCraft, la de versión más baja, por la 0.2.0. Las releases salen varias veces por semana en el conjunto, y eso no es señal de madurez: es señal de obra.

Lo mejor es que el propio proyecto cuantifica su madurez, que es de agradecer porque casi nadie lo hace. WordCraft dice cubrir el 97 % de los comandos de su catálogo, pero estima que está en torno al 60 % de lo que hace falta para trabajo real, un 55 % para el trabajo semanal de un profesional y un 63 % para el día a día. GridCraft se queda en el 89 % de los comandos estándar y en torno al 50 % de preparación real. DeckCraft declara un 84 % de amplitud y un 92 % de su núcleo.

Y hay cosas que simplemente no están. WordCraft no tiene impresión nativa; el camino que soporta es exportar a PDF. La importación de .xls, XLSB y ODS en GridCraft es solo de datos, sin formato ni objetos. La compatibilidad con ficheros reales de Office es «rough», en palabras del propio README. En Windows hay problemas de arranque por el backend gráfico: DirectX 12 por defecto y crashes documentados con ciertos drivers de AMD e Intel, con la variable WGPU_BACKEND para forzar Vulkan u OpenGL.

Y luego está el volumen de trabajo pendiente. WordCraft tiene 17.800 estrellas, 4.900 forks y 1.486 issues abiertas; GridCraft, 7.400 estrellas y 942 issues. Eso significa dos cosas a la vez: mucha gente usándolo y mucha superficie sin pulir. El propio proyecto avisa de que la paridad de comandos no equivale a implementación funcional, que es una frase que deberían leer todos los que tuitean «clon de Word».

PhotoCraft es el fenómeno: 78.700 estrellas. No he podido verificar en cuánto tiempo llegó ahí, así que me quedo con el dato actual y con la evidencia de que el interés es real.

La parte CAD: DraftSight, CADCraft y el OpenCat que no existe

Hay un tema que arrastro de hace años y que aquí vuelve a salir: el CAD en Linux.

Durante mucho tiempo, la respuesta fue DraftSight. Lo conté en varios episodios y para mí fue una revelación: era AutoCAD con otro nombre, con los mismos comandos y el mismo flujo, y corría en Linux. Quien venía de AutoCAD no tenía que reaprender nada. Eso es exactamente el argumento del que hablaba al principio: el flujo de trabajo manda.

DraftSight ya no es una opción. La beta de Linux terminó el 31 de diciembre de 2019 y la FAQ oficial de Dassault dice que no está soportado en Linux. No es que vaya mal: es que no existe.

En la suite, la pieza equivalente es CADCraft, que va por la 0.20.0 y expone list_commands, save, screenshot y acciones de dibujo, aunque el catálogo completo no está enumerado en la documentación. Lo he probado y no he conseguido nada que merezca la pena enseñar. No digo que no funcione; digo que en mis pruebas no salió nada interesante. Seguiré insistiendo.

Y aquí hay un nombre que conviene aclarar. He buscado OpenCat como herramienta de CAD y no existe ninguna aplicación de diseño o de ofimática con ese nombre. Lo que existe es OpenCat, el framework de firmware para robots cuadrúpedos de Petoi, con licencia MIT, que no tiene nada que ver con esto. Lo más probable es que estuviera mezclando nombres con OpenCASCADE, que es un kernel geométrico de CAD, o con OpenSCAD, que es CAD programático. Así que dejémoslo en: OpenCat como alternativa a ArtCraft, no verificado.

Y ya que estoy con las correcciones: en el audio llamo «FitCraft» a la app de diseño y «CatCraft» a la de CAD. Los nombres reales son FigCraft y CADCraft. El resto del contenido se sostiene; los nombres me los comí.

Las alternativas libres siguen ahí

Para poner esto en contexto, esta es la foto del escritorio libre en Linux hoy. Ninguna de estas herramientas tiene servidor MCP de serie, y eso es precisamente lo que hace distinta a la propuesta de ArtCraft.

NecesidadAlternativa libreLicencia¿MCP?
Textos, hojas, presentacionesLibreOfficeMPL-2.0No
Alta fidelidad con OfficeOnlyOffice Desktop EditorsAGPL-3.0No
Imagen rasterGIMPGPLv3No
VectorialInkscapeGPL-2.0+No
CAD 2D paramétricoFreeCADLGPL-2.1No
MaquetaciónScribusGPL-2.0+No
PDFOkular, pdftk, qpdfGPL / GPL / Apache-2.0No

Fíjate en lo que no estoy diciendo. No estoy diciendo que ArtCraft sea mejor que LibreOffice. LibreOffice tiene décadas de filtros, de compatibilidad y de casos raros resueltos; ArtCraft tiene 0.18. Lo que estoy diciendo es que son cosas distintas: una es una suite para que la uses tú, la otra es una suite para que la use un agente. Y hoy solo una de las dos tiene esa segunda puerta.

Por qué sigo con Markdown y Typst

Antes de cerrar, la pregunta que me han hecho varias veces: si esto es tan potente, ¿por qué no lo usas para tu trabajo?

La respuesta corta: porque mi trabajo no es el deliverable, es el contenido. Y para el contenido, el formato plano gana.

Mi documentación sigue en Markdown. Markdown es texto plano, no depende de ningún fabricante, no depende de ninguna versión y se lee dentro de veinte años sin instalar nada. Un .docx generado por una app en versión 0.18 es un fichero que depende de esa app, de esa versión y de que el round-trip de estilos se porte bien. Markdown no tiene round-trip. Markdown es.

Mis presentaciones siguen en Typst, que es un lenguaje de marcado tipográfico mucho más sencillo que LaTeX y con un formato que Markdown no tiene. Yo le doy el guion al modelo y él monta la presentación sobre una plantilla mía. No aprendo Typst para hacer diapositivas: lo uso para que las diapositivas sean texto que puedo versionar.

Y hay una razón de fondo, que es una conversación que recuerdo y que me marcó: si haces una presentación muy espectacular, la gente se pierde en la presentación y no en el contenido. Yo no quiero que la diapositiva compita con lo que estoy contando. Quiero que sea el guion.

Eso no quita que ArtCraft tenga su hueco. Lo tiene, y es grande: el día que un cliente te pida un .docx con su plantilla, o un .pptx para su departamento, o un PDF maquetado, tú mantienes la fuente en Markdown y Typst y le entregas el formato que pida. La IA hace la conversión y las horas de maqueta. Tú revisas y firmas.

Ahí está el cambio de enfoque del que hablaba al principio, y ahora se ve entero. No es que la herramienta sustituya a Word. Es que tú dejas de ser el que pelea con Word.

Lo que me llevo

Resumo, que llevamos mucho rato.

ArtCraft es una organización real y activa: 17 aplicaciones, 80 repositorios y un slug, storytold, que conviene escribir bien. Es Rust nativo, sin Electron, con paquetes para todas las distribuciones y 16 de las 17 apps corriendo en el navegador. Doble licencia MIT o Apache 2.0, que en la práctica es barra libre.

La idea que la hace distinta no es la licencia ni el lenguaje. Es que cada acción de cada app es un comando con identificador estable, y que ese comando se puede invocar desde un servidor MCP que viene dentro del propio binario. Eso es lo que convierte una suite de escritorio en un conjunto de manos para tu agente.

Las demos funcionan: el Word de los dinosaurios con estilos, el cuadro de mando, el clon de la web en modo claro y oscuro, la presentación exportable. Funcionan lo bastante bien como para enseñarlas y lo bastante mal como para no ponerlas en producción sin revisar.

El estado es alfa, y bien alfa. Paridad del 50-60 % en las apps de oficina, sin impresión nativa, con importaciones parciales y miles de issues abiertas. Y un coste en tokens que te obliga a conectar servidor a servidor, no todos a la vez.

Yo sigo con Markdown y Typst para lo mío, y usaré esto para lo que es: una fábrica de entregables y un laboratorio para ver hasta dónde llega un agente cuando le das manos.

Porque de eso va todo esto, en realidad. No de que la IA acabe con Photoshop. De que tú dejas de estar delante de Photoshop.


Más información

Deja una respuesta