En un trabajo anterior con Claude, pedí que un espacio de gestión recién creado no obligara a empezar frente a un panel vacío. La instrucción era añadir datos de ejemplo básicos, para que quien entrara pudiera editarlos o completarlos. El problema no consistía solo en dibujar tarjetas: los ejemplos debían existir dentro del sistema y convivir con sus reglas.
La petición fijaba el propósito y algunos elementos iniciales. Claude tuvo que decidir cómo crearlos, cómo permitir que se omitieran y qué pasaría si el espacio no tenía capacidad para añadirlos. Esa parte de la conversación muestra cómo una mejora de bienvenida termina afectando la arquitectura, las autorizaciones y las pruebas.
Una opción visible y una conexión entre módulos
Claude propuso crear los ejemplos por defecto y ofrecer una opción para desactivarlos. Después reportó añadir una casilla marcada en el diálogo de creación. Así, la automatización no quedaba escondida: quien prefiriera comenzar vacío podía elegirlo. También indicó disponer de una opción equivalente por API.
Para conectar las piezas, eligió un gancho registrado en el ensamblado de la aplicación. Explicó que el módulo encargado de crear la entidad principal no debía conocer directamente los módulos de inventario y tarifas. El gancho permitiría coordinar el trabajo sin introducir esa dependencia dentro del módulo de origen.
Esa decisión condicionó el siguiente paso. Claude anunció un sembrador que utilizaba los servicios existentes y la misma autorización de la persona que creaba la entidad principal. En lugar de tratar los ejemplos como una excepción administrativa, los hacía pasar por los casos de uso habituales. Según su reporte final, eso conservaba los límites del plan.
Los ejemplos también necesitaban reglas
Claude planteó que, si el plan no permitía añadir todos los elementos, la entidad principal se crearía igualmente y se omitirían los ejemplos. Más tarde informó que había cubierto ese límite en las pruebas y que no quedarían datos a medias. La evidencia conserva esas afirmaciones del asistente, no las salidas completas de cada comprobación.
También reportó marcar cada elemento como ejemplo editable o eliminable. Esa etiqueta era relevante para el propósito original: ofrecer un punto de partida que pudiera completarse, sin presentar los datos iniciales como información real del usuario. Omito aquí los nombres, importes y estructura particulares del proyecto; el comportamiento que interesa es la relación entre ayuda inicial, elección y permisos.
Una prueba pendiente cambió el entorno
Durante la implementación, Claude indicó que no podía ejecutar las pruebas de integración porque Docker no estaba disponible. Después reportó haber ejecutado la suite contra una base de datos del servidor y ajustado las bases temporales para evitar colisiones y limpiar lo creado durante las corridas.
El cierre comunicó que el cambio estaba subido y probado, pero añadió una condición práctica: el proceso que seguía abierto utilizaba código anterior y debía reiniciarse para mostrar los ejemplos. No hay una confirmación humana posterior de ese reinicio ni una observación conservada del panel actualizado. Mantener ese límite evita confundir un reporte de implementación con una validación de uso.
La lección que extraigo es que un panel acompañado necesita decisiones explícitas sobre consentimiento, límites y persistencia. En esta experiencia, Claude convirtió la petición de ejemplos en una opción visible y una coordinación entre servicios. El resultado documentado llega hasta su informe de implementación y pruebas; la experiencia final de quien abriría el panel seguía sin quedar registrada.