Esferic Labs · Cómo trabajamos

Cómo trabajamos con Claude en Esferic Labs

Esta guía explica el método de trabajo del equipo: cómo se reparte el trabajo entre las personas y Claude, qué reglas sostienen ese reparto y, sobre todo, por qué existe cada una. Está escrita para todo el equipo. Al terminar de leerla deberías entender por qué trabajamos como trabajamos, y no solo qué pasos seguir.

El paso a paso de cada persona está en su propia guía, en el grupo «Tu trabajo diario» del apartado Guías. Esta guía no lo repite: explica lo que tienen en común.

Escrita el 24 de septiembre de 2026 · documento interno del equipo · admite una versión para terceros sin los apartados 2, 3, 8 y 9

1. La idea de fondo: tres personas y un asistente

CreaRack es un producto grande para un equipo de tres personas: una aplicación web, un programa que se instala en casa del cliente, varios servidores, una web interna y toda la documentación que lo acompaña. Mantener todo eso con tres personas solo es posible si una parte muy grande del trabajo de ejecución la hace otro. Ese otro es Claude, un asistente de inteligencia artificial que escribe código, redacta documentos, revisa el correo, consulta la contabilidad y lleva las tareas al día.

El reparto es sencillo de enunciar: Claude ejecuta y las personas deciden. Claude puede preparar casi cualquier cosa, pero hay decisiones que toma siempre una persona, porque sus consecuencias no se pueden deshacer con facilidad o porque son decisiones de negocio:

Todo lo que mueve dinero: pagos, cobros, contratos y cualquier gasto nuevo.
Publicar un cambio para los clientes. Claude puede hacer la publicación, pero solo cuando una persona se lo pide.
Tocar los servidores: reiniciarlos, cambiar su configuración o instalar algo en ellos.
Borrar algo que Claude no ha creado.
Cambiar el modelo de inteligencia artificial que usa el producto.
Lo que afecta a los tres a la vez, como cambiar las herramientas o las normas de trabajo del equipo.

Todo lo demás, si se puede deshacer y se desprende de algo que ya se ha aprobado, Claude lo hace sin preguntar a cada paso. Pararse a pedir permiso para lo evidente hace perder tiempo y no añade seguridad.

2. Dónde vive cada cosa

En un equipo pequeño, lo más fácil es que el conocimiento se quede en la cabeza de quien hizo el trabajo, y en cuanto esa persona no está, nadie sabe cómo seguir. Además, Claude no recuerda por sí solo las conversaciones anteriores: cada sesión empieza en blanco. Por eso todo lo importante se escribe en un sitio concreto, y Claude lo lee al empezar. La regla es que nada importante depende de que alguien se acuerde.

Sitio	Qué se guarda	Quién lo mantiene al día
El Workspace	La web interna del equipo: el tablero de tareas, el correo ordenado, la wiki con la documentación, las guías y los informes.	Todos, casi siempre a través de Claude.
GitHub	El código de CreaRack y de nuestras herramientas, con el historial completo de cada cambio y quién lo hizo.	Claude, cada vez que sube un cambio.
La documentación del proyecto	Notas sobre cómo está hecho cada módulo de CreaRack. Se consulta con el buscador del Workspace o preguntando a Claude.	Se actualiza sola cada vez que se publica un cambio.
Las dos notas de estado	Una dice en qué estado está el proyecto; la otra, qué toca hacer después. Son lo primero que lee Claude al empezar una sesión.	Claude, al cerrar cada sesión con «Apaga».
La memoria de Claude	Lo que Claude ha aprendido trabajando con cada persona: sus preferencias, las correcciones que le han hecho y las trampas técnicas ya conocidas.	Claude, cuando alguien le corrige o descubre algo nuevo. Se guarda una copia de seguridad al cerrar cada sesión.

3. Una jornada de trabajo

Cada vez que alguien abre Claude para trabajar empieza una sesión. Una jornada normal tiene tres momentos:

Al empezar, Claude lee las dos notas de estado y las tareas que vencen en los próximos días, y hace un resumen: qué se hizo en la última sesión, qué quedó a medias y qué propone hacer hoy. La persona decide por dónde empezar.
Durante la sesión, la persona pide el trabajo y Claude lo hace, preguntando solo cuando hay una decisión que no le corresponde.
Al terminar, la persona escribe Apaga y Claude cierra: actualiza las notas de estado, apunta en la bitácora lo que se hizo y guarda una copia de su memoria.

El cierre importa tanto como el arranque. Si una sesión termina sin «Apaga», la siguiente, sea de la misma persona o de otra, empieza con información vieja y puede proponer trabajo que ya está hecho. Ese minuto al final es lo que permite que tres personas trabajen sobre lo mismo sin tener que reunirse a contarse qué han hecho.

4. Cómo se le pide trabajo a Claude

A Claude se le habla como a un compañero que conoce bien el proyecto: con frases normales y completas, explicando qué se quiere conseguir y para qué. Cuanto más contexto tenga, mejor será el resultado. «El informe de un SAI tiene la tabla de alarmas ordenada de la más antigua a la más reciente, y quiero verla al revés porque lo que interesa es lo último que ha pasado» funciona mucho mejor que «invierte la tabla de alarmas».

Hay dos formas de pedir las cosas, y conviene no confundirlas:

Pedir un análisis

«Mira a ver si…», «analiza…», «¿qué opinas de…?». Claude investiga y devuelve un diagnóstico con su recomendación, pero no cambia nada. Lo que se entrega es su criterio.

Dar el visto bueno

«Adelante», «hazlo». Claude hace el trabajo de principio a fin: el cambio, su documentación, las pruebas, la publicación si se le ha pedido y la comprobación final. No se para a preguntar «¿sigo?» por pasos que ya están aprobados.

Cuando hay varias formas de hacer algo, Claude no presenta un menú neutro: da su recomendación primero, con el porqué, y la persona decide. Y antes de cualquier acción con consecuencias, de las que se enumeran en el apartado 1, explica lo que va a hacer y espera la confirmación.

5. Comprobar el resultado, no la señal

Este es el principio más importante del método, y el que más cuesta aplicar. Casi todas las herramientas informáticas avisan cuando terminan: «correcto», «publicado», «0 errores». Esos avisos dicen que el programa ha terminado, pero no que el resultado sea el que se quería. Un cambio puede publicarse sin errores y no verse en la pantalla, porque el navegador conserva la versión antigua. Una copia de seguridad puede terminar «correctamente» y estar vacía.

Por eso, entre nosotros, algo está hecho solo cuando se ha visto el efecto:

Un cambio en la aplicación está hecho cuando se ha visto funcionar en la pantalla de la web real, no cuando el programa de publicación termina.
Una tarea automática está hecha cuando se ha visto su primera ejecución real con su registro, no cuando queda programada.
Una alarma nueva está hecha cuando se ha provocado a propósito el fallo que debe detectar y se ha visto llegar el aviso.

Cuando no se ha podido comprobar el efecto, se dice con esas palabras, por ejemplo «publicado, sin comprobar en pantalla», y nunca «hecho y verificado». Una advertencia que falta se lee como si todo estuviera comprobado, y así es como llegan los errores a los clientes.

Una regla sin excepciones: si una prueba automática falla, se arregla el código o se explica el fallo. Nunca se modifica, se debilita ni se desactiva la prueba para que salga en verde. Una prueba que falla está avisando de algo.

6. Publicar un cambio con seguridad

CreaRack funciona en crearack.com, y cualquier error que llegue allí lo ven los usuarios. Por eso ningún cambio en el código se publica directamente: pasa dos rondas de pruebas y alguien decide publicarlo. Este es el recorrido de cualquier cambio, lo pida quien lo pida:

Se pide

Una persona describe el cambio. Si hay dudas, Claude pregunta antes de empezar.

Copia aparte

Claude lo hace en una copia de trabajo separada, la rama, que no afecta a nadie.

Primeras pruebas

En el ordenador, las pruebas de la parte tocada. Uno o dos minutos.

Propuesta y pruebas completas

Se sube como propuesta de cambio y un servidor pasa todas las pruebas del producto. Unos diez minutos.

Fusionar = publicar

Con todo en verde y la persona de acuerdo, se fusiona. Minutos después está en la web.

Desde que se sube la propuesta hasta que el cambio se ve en crearack.com pasan unos quince minutos. Lo más importante de este recorrido es el último paso: no hay un entorno de pruebas intermedio. Fusionar una propuesta la publica para todos los usuarios. Por eso solo se fusiona con todas las pruebas en verde, después de que una persona haya revisado el cambio, y después se comprueba en pantalla, como explica el apartado 5.

La guía de Dani cuenta este recorrido con más detalle, incluido qué hacer si las pruebas fallan.

Esto cambiará cuando abramos CreaRack al público. Hoy se puede comprobar en producción porque no hay clientes: si algo falla, solo nos afecta a nosotros. Con clientes reales hará falta un paso intermedio: fusionar publicará primero en un servidor de pruebas, con datos inventados y un Agente simulado, y una persona dará después la orden de pasar el cambio a producción. Ya tenemos un servidor de pruebas, pero hoy recibe los cambios a la vez que producción y además aloja piezas importantes que conviene no mezclar con las pruebas.

Dónde probaremos los cambios cuando abramos al público → Por qué cambia, la propuesta paso a paso, si el servidor de pruebas actual da abasto (medido el 24 de septiembre de 2026) y cuándo conviene hacerlo.

7. Cómo se toman las decisiones importantes

La mayoría de las decisiones del día a día son pequeñas y se pueden deshacer: se toman y se sigue. Pero algunas tienen consecuencias reales y varias salidas posibles, como elegir un proveedor de pagos, fijar un precio o decidir si construimos una función grande. Para esas, el método pide dos cosas que no son habituales.

La primera: antes de decidir, elegir cómo se va a decidir. No es lo mismo no tener todavía ninguna opción que tener una idea y querer ponerla a prueba. Claude tiene cuatro formas preparadas de ayudar, y propone la que encaja:

Situación	Qué hace Claude	Se pide con
Aún no hay ninguna opción elegida	Genera varios enfoques distintos, cada uno pensado por separado para que no se contagien entre sí, y los compara.	/method:divergir
Hay un plan elegido y falta afinarlo	Hace preguntas sobre el plan, una por una y con su propia recomendación en cada una, hasta que el plan queda claro.	/method:grill
Hay una idea concreta y se quiere un veredicto	Cinco revisores atacan la idea desde ángulos distintos y un juez decide: adelante, rehacerla o descartarla, con la prueba más barata para salir de dudas.	/method:roast
Hace falta investigar un tema con fuentes	Estudia el tema desde cinco perspectivas, cita las fuentes y señala dónde se contradicen. Entrega un informe.	/method:storm

La segunda: al decidir, escribir una apuesta. Antes de conocer el resultado se deja escrito qué esperamos que pase, medido con un dato concreto; comparado con qué; y cuándo lo comprobaremos. Llegada la fecha, se mira el dato real y se anota si acertamos, fallamos o acertamos a medias, con una línea de explicación. Las apuestas se guardan en una lista que nunca se reescribe. Sirven para dos cosas: obligan a concretar qué significa que una decisión salga bien, y con el tiempo enseñan en qué tipo de decisiones acertamos y en cuáles nos engañamos.

Ejemplo completo: cómo decidimos la pasarela de pago → Una decisión real de agosto de 2026 contada de principio a fin: la pregunta, el estudio, la decisión, la apuesta y lo que se descubrió al afinar el plan.

8. Tareas, plazos y avisos

Todo lo que hay que hacer vive como una tarea en el tablero del Workspace, con una persona responsable y, casi siempre, una fecha límite. Cada tarea tiene un hilo de comentarios donde se cuenta cómo va: qué se ha hecho, qué se ha descubierto y qué falta. Así cualquiera puede retomar una tarea ajena leyendo su hilo, sin preguntar.

Al empezar cada sesión, Claude avisa de las tareas vencidas y de las que vencen en los próximos siete días.
Una tarea vencida no se deja pasar. El mismo día se cierra, se le cambia la fecha o se comenta por qué sigue abierta.
Lo que no tiene plazo pero no se puede olvidar se queda sin fecha y se acompaña de tareas-aviso con fecha, que sirven solo para acordarse de repasarlo.
Nada se deja «apuntado para ya veremos». Cada trabajo termina con sus flecos resueltos, o documentados con responsable y fecha.

9. Un equipo sin jerarquías

Esferic Labs es un equipo de tres personas que se fían por completo unas de otras, y el método lo refleja:

Los tres tenemos acceso a todo: servidores, cuentas de servicios, contabilidad, código. En un equipo tan pequeño, la seguridad está en que cualquiera pueda cubrir a otro, no en restringir.
Cualquiera puede publicar un cambio sin pedir la aprobación de otra persona. Quien lleva la sesión es quien publica.
Lo que se acuerda entre todos es el plan, antes de construir algo grande, no el permiso para ejecutarlo.
Lo que cambia para uno cambia para los tres: cuando se mejora una herramienta o una norma de trabajo, llega a los tres perfiles a la vez.

10. Cuando algo sale mal

Algo saldrá mal, y lo importante es cómo se cuenta. En este equipo, lo que ha fallado, lo que ha quedado a medias o lo que no se ha podido comprobar se dice al principio y con la misma claridad que lo que ha salido bien. Una mala noticia escondida al final de un informe largo es peor que la mala noticia en sí.

Además, cada error se aprovecha para que no se repita:

Las trampas técnicas quedan apuntadas. Cuando algo falla por una causa que no era evidente, Claude la anota en su memoria con el síntoma y la solución, y la próxima vez la reconoce.
Las correcciones cambian las normas. Cuando alguien corrige a Claude por la forma de trabajar, la corrección se convierte en una norma que se carga en todas las sesiones de los tres. Por ejemplo, esta misma guía existe porque el 24 de septiembre de 2026 Edu corrigió la forma de redactar el material para el equipo: pedía mensajes sencillos, no cortos, y esa corrección es hoy una norma de redacción.
Antes de cambiar una norma se guarda una copia de la anterior, para poder volver atrás si el cambio no funciona.

11. Glosario

Claude: El asistente de inteligencia artificial con el que trabaja el equipo.
Sesión: Cada vez que se abre Claude para trabajar, desde que empieza hasta que se escribe «Apaga».
Apaga: La palabra con la que se cierra una sesión. Claude actualiza las notas de estado y guarda una copia de su memoria.
Workspace: La web interna del equipo (workspace.crearack.com).
GitHub: El servicio donde se guarda el código, con el historial de todos los cambios.
Rama: Una copia de trabajo separada del código, donde se hace un cambio sin afectar a nadie.
Propuesta de cambio: La petición de incorporar una rama a la versión principal. En GitHub se llama pull request.
Fusionar: Incorporar una propuesta a la versión principal. En CreaRack equivale a publicarla.
Pruebas automáticas: Programas que comprueban que el código hace lo que debe, antes y después de subir un cambio.
Apuesta: Lo que esperamos que pase tras una decisión, escrito antes de saberlo, con un dato, una comparación y una fecha para comprobarlo.
Tarea-aviso: Una tarea con fecha cuyo único fin es acordarse de repasar otra que no tiene plazo.

¿Algo no cuadra?

Esta guía describe cómo trabajamos, y escribirla ya sirvió para descubrir cosas que no encajaban. Si al leerla algo no coincide con lo que ves en tu trabajo, se ha quedado anticuado, no se entiende o se podría hacer mejor, dilo: así es como mejoran las guías y, con ellas, la forma de trabajar.

Pídeselo a Claude en cualquier sesión, diciendo qué guía, qué apartado y qué cambiarías. Por ejemplo: En la guía de bienvenida, el apartado 6 ya no es verdad porque…
O escribe un comentario en la tarea «Mejoras de las guías» del tablero del Workspace, que está abierta siempre para esto.

Claude también propone mejoras cuando detecta algo que no encaja. Cada propuesta se revisa y, si se acepta, la guía se actualiza con su nueva fecha de revisión.