¿Cómo trabaja?

Un cambio que "debería dar lo mismo" no da lo mismo hasta que algo lo comprueba. Cada vez que he movido algo de sitio he dejado detrás el verificador, no la intención.

Lo que decide si un sistema sirve diez años no es su interfaz: es si los conceptos del negocio existen dentro. Un vocabulario prestado obliga a traducir en cada interacción, y funde en una sola cosa las que el negocio distingue.

Defender un modelo contra su propio uso es el modo más caro de tener razón. La corrección se documenta con la evidencia que la obligó, no se disimula en un commit.

No todo el código merece el mismo cuidado. Lo que merece decisión es saber dónde se invierte y poder defenderlo, no aplicar un estándar uniforme que nadie sostiene.

Un informe que solo dice lo que funcionó no informa de nada. Los míos listan los fallos, y eso es lo que los hace utilizables por otro.

Sin cajas negras, sin dependencias por moda, sin cadena de construcción que caduque. Lista blanca de librerías y evaluación previa obligatoria.

Si una acción se implementa dos veces, divergen. La capa de servicios de dominio es lo que permite añadir un canal nuevo sin tocar el núcleo — y es lo que hizo que web, Telegram, email, MCP y multimodal salieran sobre la misma base.

La adopción no es un problema de formación: es de diseño. Quien alimenta el dato tiene que recibir más de lo que da, o no lo alimenta. Y si mantenerlo al día es trabajo adicional, no se hace.

Escribo el porqué en el momento, no al final. Un cambio de rumbo es una entrada nueva, no un borrado — el error también es documentación.

Cuando un agente con permisos de escritura procesa algo que no escribió el usuario, la respuesta correcta no es un prompt más estricto: es impedir las escrituras hasta que la persona las apruebe.

Cada pieza de infraestructura que añado es una pieza que hay que administrar, respaldar, actualizar y entender cuando falla a las tres de la madrugada. En equipos de una persona ese coste no es teórico. Así que la pregunta no es si una herramienta es buena, es qué problema mío resuelve — y si no resuelve ninguno todavía, no entra. La contrapartida es honesta: el día que el problema aparezca, la herramienta entra sin discusión.

Cuando empiezo algo lo pienso para que crezca: un contrato entre las partes, una capa de servicios, una costura donde encajará lo siguiente. Pero la siguiente fase se diseña, no se construye: lo que aún no hace falta no tiene tablas, campos ni servicios esperándolo. La arquitectura puede anticipar; el código, no.

Con agentes de código, el cuello de botella no es escribir sino entender. Trabajo en rebanadas: se explica, la apruebo, se construye solo eso y la ejecuto yo antes de seguir. Un código correcto que quien lo mantiene en solitario no puede evaluar es peor que uno más modesto que sí.

Un agente que genera aumenta el código que entiendo menos; uno que lleva la contraria o lee en frío aporta independencia. En los dos casos, lo que propone es una hipótesis que se comprueba contra el código antes de aplicarla.

Un modelo de lenguaje sirve para entender lo que alguien quiso decir, no para autorizar, calcular ni redactar lo que una plantilla ya sabe decir. Lo ambiguo —texto libre, nombres con erratas, la salida de un LLM— se convierte en la frontera en algo estructurado y revisable; dentro, todo es reproducible.

Lo que alguien pide suele ser su primera idea de solución. Antes de construir busco el problema real, en los datos y en cómo se trabaja: a menudo se resuelve con menos, o con algo distinto y mejor, y hay requisitos que nadie pide y no se negocian.

Un dato guardado en dos sitios acaba diciendo dos cosas el día que alguien corrige uno. Cada dato tiene un dueño que lo escribe y los demás lo leen sin poder tocarlo; y lo que vive en otro sistema se enlaza, no se copia.

Un valor derivado que se teclea se desfasa en cuanto cambia aquello de lo que deriva, y nadie se acuerda de actualizarlo. Se guarda el hecho y se calcula lo demás; el usuario no tiene por qué hacer de calculadora.

Una política que cada pantalla repite a mano se acaba olvidando en una de ellas. Lo que no debe escribir, no puede escribir; lo que sale hacia fuera sale de una lista explícita; y la forma segura tiene que ser también la más cómoda.

Un error silencioso se descubre cuando alguien se queja; uno ruidoso, en el momento. Cuando dos errores posibles no pesan lo mismo, diseño para que el que ocurra sea el que se ve, y el silencio nunca vale como respuesta.

Un test que nunca ha fallado no prueba nada, una copia que no he restaurado no es una copia y una vuelta atrás que no he ensayado es una esperanza. Cada red se prueba rompiendo algo a propósito.

Una convención que depende de que alguien se acuerde dura hasta el primer cansancio. Si una regla importa —confidencialidad, enlaces, accesibilidad, coherencia entre capas—, la comprueba algo que se ejecuta, y un hueco deliberado se declara con su motivo.

Borrar algo que ocurrió es perder la explicación. Cada tipo de dato tiene su política: lo que cuenta la historia cambia de estado y se corrige con un movimiento que compensa; los errores y los duplicados sí se borran. Nada de «borrado lógico de todo».

Prefiero un hueco a un valor inventado, y una marca de provisional a un dato que parece definitivo. La procedencia y la certeza son parte del dato, y lo que no está validado no sale hacia fuera como si lo estuviera.

Reemplazo piezas manteniendo el contrato: mismas respuestas, mismo esquema, mismo resultado. Los cambios son aditivos, los valores por defecto reproducen lo que el dato significaba antes y un cambio de diseño nunca debería parecer una avería.

Hacerlo a medida no es el punto de partida. Lo es cuando ningún producto cubre lo esencial del dominio, cuando los datos tendrían que salir de casa o cuando el coste no se justifica; si algo ya tiene dueño y encaja, se enlaza o se usa.

Cuando una sola persona sostiene muchos sistemas, la uniformidad no es estética: es lo que los hace mantenibles. Cada proyecto nuevo arranca del molde del anterior, y apartarse de la convención tiene que justificarse.

El agente propone, edita y verifica. Migraciones, despliegues, catálogos nuevos y cargas reales los dispara una persona, con un ensayo en seco por defecto: deshacer un error del agente no debería depender de que el agente lo entienda.

La configuración, los textos de la interfaz, el prompt de un agente y la documentación describen lo que existe hoy, no lo que se planeó. Una promesa sin mecanismo detrás es un defecto, y se retira.

Descartar algo sin decir qué lo haría volver condena a repetir la discusión. Cada exclusión dice qué señal la revoca: así el «no» cierra el debate y deja la puerta puesta.

Antes de arreglar una fórmula, una redundancia o un código que parece muerto, compruebo por qué está así. Al rehacer el cálculo de un experto corrijo solo lo que puedo demostrar; lo intencionado se respeta aunque parezca raro.

Si algo puede cambiar sin tocar código —qué secciones se ven, un aviso, el modo mantenimiento, un vocabulario—, se controla desde los datos. Publicar una versión o migrar el esquema es el camino caro, y en una app de tienda, además, el lento.

Una conversación sobre modelos de datos no llega lejos con quien no es técnico; una pantalla con su trabajo de cada día permite preguntar «¿es esto?» en lugar de «¿qué necesitas?». Y pone a prueba el modelo: si la pantalla sale forzada, el modelo está mal.

Para un agente, la documentación es todo el contexto que tiene; para la persona que llega, el atajo. Por eso no se deja para el final: si un cambio toca el código y no su documentación, la documentación ya miente.

El primer día de un proyecto se despliega algo, aunque esté vacío. Así cada cambio posterior llega por el mismo camino, los problemas del entorno aparecen cuando aún son pequeños y no hay un gran despliegue final.

Un campo que nadie publica, una interfaz que nadie implementa o una protección que nunca se conectó no son neutros: invitan a usarlos y cuestan mantenerlos. Lo que no tiene quien lo use no entra, y si ya está, se quita.

El modelo de datos describe el negocio y no se deforma para la pantalla. La interfaz hace lo contrario: parte de la tarea de cada perfil, de cómo busca, dónde está y con qué trabaja ya. Pedir a alguien que piense como la base de datos es la forma más rápida de que no la use.

Un dato que no se recoge no se puede filtrar, perder ni reclamar. Lo que no hace falta, no se guarda o se degrada antes de guardarlo; lo que sí hace falta tiene un propósito, un plazo de caducidad y la menor cantidad posible de destinatarios. Y la página de privacidad cuenta lo que de verdad ocurre.