El 28 de junio de 2025, a las 22:28, escribí esto:
Ahora genera una guia para yo poder explicar el artifact, hazlo muy simple para que pueda explicarle a una persona técnica lo que le propongo sin que se de cuenta que no entiendo el documento
Tenía un cliente, una propuesta técnica encima de la mesa y una reunión pendiente con alguien que sí sabía de esto. Así que pedí ayuda para disimular.
Nueve meses después entregué el proyecto funcionando en el servidor de ese cliente. Entre esas dos cosas está casi todo lo que sé hacer hoy.
El encargo
El encargo no lo busqué yo. Me lo pasó un amigo que lleva una agencia de comunicación: se lo habían adjudicado y no tenían a quién ponérselo, porque no tenían al especialista. Dije que sí antes de saber si sabría hacerlo, que es la única razón por la que existe este capítulo.
Una entidad pública de Canarias quería un asistente que contestara preguntas sobre su propia web: convocatorias, ofertas de empleo, quién hace qué. Suena pequeño y no lo es. Para que un bot conteste bien hay que leerle la web entera y guardarla de una forma que él pueda buscar. Y después, la parte difícil: conseguir que no se invente lo que no encuentra.
Yo no había hecho nunca nada de eso. No sabía entrar en un servidor ni lo que era un contenedor, y tampoco tenía forma de saber si el plan que proponía se aguantaba de pie. El 10 de julio lo escribí con todas las letras:
Crees que es un plan viable teniendo en cuenta que no tengo experiencia ni con entornos de sistema ni con Llama
La respuesta correcta a esa pregunta era que no, y aun así seguí adelante.
Cambiar de herramienta cada mes no es fracasar, es el temario
En cuatro meses mi archivo recorre un catálogo entero. Empecé en mayo con n8n, que encadena flujos, y en julio me pasé a Flowise, que ya hacía chatbots. A finales de agosto probé Botpress, en septiembre ya estaba enganchando un rastreador de páginas por mi cuenta —Cheerio primero, Crawlee después—, y en febrero acabé metiéndolo todo en contenedores con Docker.
Visto desde fuera parece un tipo que no se aclara, y en parte lo era. Pero cada cambio venía de haberme comido un techo concreto: esta no lee PDF, esta se rompe al actualizar, esta necesita una máquina más grande de la que hay. Eso no se aprende leyendo comparativas, se aprende cuando te estrellas contra ello un martes a las once de la noche con una fecha encima.
Ese fue el temario, y no había otra forma de darlo.
El 4 de agosto a las nueve de la noche
Ese día escribí la pregunta más importante de todo el año, y no me di cuenta:
Como uso Claude Code?
Venía de generar flujos que luego no funcionaban al pegarlos, así que pregunté lo obvio: si con la versión de siempre no me bastaba. Me bastaba para hablar. No para que alguien mirase mis archivos, los cambiara y comprobara si aquello arrancaba.
Todo lo que he construido desde entonces sale de esa pregunta de una línea.
«Funciona!!! No vuelvas a proponer cambios»
El 5 de agosto, a las 23:12, después de horas peleando con la instalación de n8n en un servidor, escribí esto:
Funciona!!! No vuelvas a proponer cambios que puedan afectar a la integridad del proyecto. Nunca mas!!
Dos semanas más tarde ya no era un enfado, era una norma de la casa:
recuerda nuestra maxima de asegurar que no afectaremos otros servicios ya funcionando
Y a partir de ahí, antes de cada cambio, la misma pregunta: ¿esto puede tocar algo de lo que ya funciona?
Esa frase la había escrito antes. Fue en una terminal de Las Palmas, después de que una hoja de Excel mía calculara mal una mezcla y hubiera que arreglarlo en el tanque. La lección de entonces fue que la herramienta amplifica el error igual que amplifica el acierto. Por eso hay que poner un freno humano delante de lo que no tiene vuelta atrás.
Quince años después se lo estaba explicando a una máquina, a las once de la noche y a gritos. Es la misma lección de siempre, y solo ha cambiado quién tiene las manos.
El día que dejé de creérmelo
El 25 de agosto por la mañana, revisando un despliegue, me dio por comprobar una ruta que me acababa de dar por buena, y resultó que ni la ruta era esa ni el puerto tampoco.
flowise corre en puerto 3000!!!
Cinco signos de exclamación, que cuento porque marcan un antes y un después.
Hasta ese día copiaba lo que me decía y lo pegaba en la consola. Desde ese día compruebo primero. No porque la máquina mienta, que no miente, sino porque afirma con la misma seguridad lo que sabe y lo que se está imaginando. Desde fuera las dos cosas se ven idénticas.
Ese es para mí el primer requisito de trabajar así. No es escribir mejores instrucciones: es no creerte la respuesta hasta que la has visto funcionar.
La primera demo duró una pregunta
Cuando por fin lo tuve presentable se lo enseñé al cliente, y a la primera de cambio alguien de la casa le hizo un jailbreak: le dio la vuelta y me lo emborrachó.
Lo cuento porque en su momento fue un mal rato y hoy es de las cosas que más agradezco. Yo venía de veinte años de hojas de cálculo, donde el peor usuario posible es alguien con prisa. Aquí el peor usuario posible es alguien con curiosidad y cinco minutos libres, y lo tienes dentro de tu propio cliente. Eso no viene en ninguna guía: lo aprendes cuando te tumban la demo.
Lo reforcé, seguí probando, y ahí empezó la parte larga.
La noche de los trescientos noventa mensajes
El 28 de agosto probé la demo yo solo, por si acaso, y a la primera pregunta contestó cualquier cosa.
Esa conversación tiene 390 mensajes y casi doce mil palabras mías, y empezó a las nueve y media de la noche. El bot encontraba los documentos pero contestaba como si no los hubiera leído. Así que fuimos hacia atrás: la respuesta, el buscador, la base de datos, lo que se había guardado al leer la web y lo que la web decía de verdad.
No arreglé nada esa noche, pero aprendí a mirar, que es distinto y a la larga vale más.
Nadie aprende a buscar la avería de un sistema leyendo sobre cómo se buscan las averías: se aprende una noche en que aquello no funciona y no te puedes ir a la cama.
Tardé semanas en poder decir la avería en una frase, y cuando pude, era vergonzosamente simple: le estaba pidiendo a la máquina que encontrara una aguja en un pajar. Yo me había traído la web entera en bruto, sin ordenarla ni etiquetar qué era cada cosa, y luego le pedía que encontrara un dato concreto ahí dentro. A la pregunta «¿quién dirige esto?» —el dato más fácil de la casa, que está en su propia página— el bot no era capaz de contestar.
Esa fue mi lección más cara del proyecto, y va contra lo que se dice por ahí. La parte lista no arregla un almacén desordenado. Antes de pedirle nada hay que decidir qué se guarda, cómo se trocea y qué etiqueta lleva cada trozo. Eso no lo hace el modelo: lo haces tú, y si lo haces mal, no hay instrucción que lo salve.
Lo que se me quedó de mi propio oficio
El 2 de septiembre abrí la sesión de trabajo así:
Continuamos implementación […] Bot - Day 2. Ejecutar context recovery: ./context-recovery.sh
Me había escrito un guion que, al empezar el día, le contaba a la máquina dónde lo habíamos dejado. Qué estaba instalado, qué había fallado y cuál fue el último comando. Lo hice por pereza: cada mañana perdía media hora explicando lo mismo.
Tardé meses en darme cuenta de lo que era en realidad. Es el traspaso de turno.
Años atrás pasé noches enteras montando una tabla para que lo que sabía un turno llegara entero al siguiente, sin depender de que alguien se acordara de contarlo. Estaba haciendo exactamente lo mismo, en una carpeta, para una máquina que se olvida de todo al cerrar la ventana.
Lo que hoy llamo memoria, contexto o traspaso entre sesiones no lo aprendí en ningún curso. Lo aprendí en una terminal de combustible, y aquí solo lo reconocí.
La relación de trabajo
Tampoco fue idílico, ni conviene contarlo como si lo hubiera sido. El 18 de septiembre, después de una tarde entera dando vueltas al mismo fallo, le escribí que así no íbamos bien y que esperaba más de él. Al día siguiente, ya con la cosa resuelta:
Por fin, eres maravilloso casi siempre pero cometes unos errores que me desesperan. Continuemos
Leídas hoy me hacen gracia y me sirven. Le hablo a una máquina como le hablaría a alguien de mi equipo: le digo qué espera de él, le señalo el fallo, y sigo. No me disculpo por eso. Es la única manera que conozco de trabajar bien con nadie, tenga cuerpo o no.
El nombre llegó el último
El 14 de octubre de 2025, cinco meses después de empezar, escribí por primera vez cómo se llamaba lo que llevaba medio año haciendo:
define como implementar esta logica en el proyecto mediante el uso de vide coding
Con la errata incluida, y esa misma noche pregunté si el proyecto entero se podría haber hecho así desde el principio.
Me gusta que fuera en ese orden. Primero nueve meses de servidor, de errores, de noches y de una entrega de verdad. Después, la palabra que lo nombra.
Tirarlo entero y volver a empezar
Para entonces los modelos habían dado un salto y por primera vez se podía construir así de verdad: no pedir un trozo de código y pegarlo, sino trabajar con alguien que abre tus archivos y los cambia. Miré lo que tenía —un flujo de n8n, cajas y flechas parcheadas por todos lados— y decidí tirarlo y hacerlo otra vez desde cero, esta vez escribiendo el proyecto entero con Claude Code.
Ahí salió completo. Y aun así no me gustó.
El bot funcionaba pero era rígido, robótico, sin nada de la soltura que tienen estas máquinas cuando hablas con ellas. Como no había conseguido ordenar bien la información, lo compensé a base de reglas: un guion que miraba la pregunta, decidía si iba de algo que cambia todos los días o de algo fijo, y según eso tiraba por un camino o por otro. Funciona, se entrega, y no engaña a nadie que sepa mirar: cada regla que añades para tapar un agujero de diseño se paga después.
Lo entregué así, para bien o para mal. Dije que estaba listo y que lo probáramos cuando quisieran.
Entregado no es lo mismo que puesto en marcha
Y no pasó nada. Ni una semana ni dos: meses.
Esa espera es una parte del oficio que no sale en ningún sitio. Uno termina, avisa, y al otro lado hay gente con su propio trabajo, sus prioridades y su calendario, para quien tu proyecto es el punto catorce del orden del día. No es desprecio. Es que entregar y poner en marcha son dos cosas distintas, y la segunda no depende de ti.
Cuando por fin dijeron «vamos a ponerlo en marcha», había cambiado todo: la tecnología y yo. Así que volví a hacerlo. Y esta vez sí. Esta vez sabía qué guardar, cómo trocearlo y qué etiqueta ponerle a cada trozo; sabía distinguir lo que cambia cada día de lo que no; y el resultado no se parecía en nada al anterior.
Después vino la parte de la que nadie habla y que también es el trabajo: un dosier, la documentación final, una reunión, mover el proyecto a sus servidores, y otra reunión más con la gente que lleva su página web para autorizar el sitio por donde el bot iba a entrar. Todo eso, que no se ve, es la mitad de un proyecto entregado.
Quedó una sola cosa pendiente, un certificado de seguridad que solo podían emitir ellos, y ahí volvió a pararse otros cuantos meses.
El día que mi propio sistema auditó mi primer proyecto
Hace una semana volvieron a escribirme, y esta vez no abrí el proyecto yo: le pedí a mi propio sistema que lo auditara.
Es la escena que cierra el capítulo mejor de lo que yo sabría escribirla. El proyecto que empecé sin saber entrar en un servidor lo revisó, línea a línea, algo que construí yo mismo con lo que aprendí haciéndolo. Encontró cosas, y la mayor la había puesto yo: una instancia entera de OpenClaw metida dentro del proyecto, 3,6 GB de contenedor. De ahí salían los tres fallos más feos de la auditoría, y lo único que hacía era llevar el recado entre el bot y el modelo: sin herramientas, sin memoria propia, sin carácter de agente. Matar moscas a cañonazos. La quitamos y escribimos ese mismo recado en ciento cincuenta líneas dentro del propio programa, con el carácter del bot en un fichero que se lee de una sentada. Dos tardes.
Está terminado y listo para entregarse. Un año y pico después de empezarlo.
Lo que aprendí
Que el vibe coding no es que la máquina escriba el código por ti. Es saber qué pedirle, qué no creerte y cómo evitar que se pierda entre una sesión y la siguiente. Lo primero es criterio, lo segundo desconfianza y lo tercero método. Ninguna de las tres la pone la máquina.
Que la única escuela que me ha funcionado tiene una fecha y a alguien esperando al otro lado. En el capítulo anterior monté ocho ideas en ocho semanas y no terminé ninguna. Aquí terminé una, porque no podía no terminarla.
Que veinte años quitando de en medio el trabajo de mono valían más de lo que yo creía. Sabía lo que es un traspaso de turno, por qué hay que frenar antes de tocar lo que ya funciona, y cómo documentar para que otro pueda seguir. Lo que no sabía era la parte técnica, y esa resultó ser justamente la que se puede delegar.
Y que aquel encargo pequeño de una entidad pública canaria acabó siendo el suelo de todo lo que vino después. Cuando meses más tarde me puse a construir un sistema que fabrica sistemas, no partía de cero. Partía de nueve meses estrellándome con permisos, con rutas equivocadas y con un bot que contestaba cualquier cosa a la primera pregunta.
Y que lo que me llevé de aquí no estaba en ningún presupuesto, literalmente: de este proyecto no he cobrado todavía un euro, por lo que cuento en el capítulo anterior. Un año y medio, tres versiones, dos reconstrucciones enteras y cero facturado. Si lo miro con la calculadora, es el peor trabajo de mi vida. Si lo miro con lo que sé hacer hoy, es la mejor escuela a la que he ido nunca. Y las dos cosas son verdad a la vez.