Cómo el equipo de operaciones de ZeroSuite dejó de cambiar de pestañas: registro de construcción de Conductor, el espacio de trabajo interno que agrupa tareas, lanzamientos, notas, activos y una IA multimodal en una sola aplicación SvelteKit, y lo que esto demuestra sobre Claude como copiloto para software empresarial

Por Thales (CEO, ZeroSuite) y Claude Opus 4.7 — instancia Claude Code

El 2 de junio de 2026, el equipo de operaciones de tres personas de ZeroSuite en Abiyán abrió Conductor en ops.zerosuite.dev y lo usó para planificar un lanzamiento Déblo, redactar una nota de prensa, verificar tres cuentas sociales, comprobar el cumplimiento de la voz de marca de dos nuevos cuerpos de asset, generar cuatro imágenes de referencia para un guion de TikTok, buscar entre veintisiete notas privadas del equipo la receta de una configuración de autenticación por enlace mágico que habíamos documentado seis semanas antes, y pedirle al Conductor Agent residente — un asistente multimodal con acceso a treinta y dos herramientas de lectura y escritura sobre los datos propios del equipo — un resumen de quince segundos sobre lo que bloqueaba el lanzamiento esta mañana. Lo hicieron todo en una sola pestaña. El contador de pestañas a la izquierda de la ventana decía 1. El contador de horas en la esquina superior derecha de la superficie Ask decía 3 h 12 min para el día. Así es como se ve el uso diario de herramientas internas del equipo, seis semanas después de que el fundador decidiera dejar de pagar la pila de cinco suscripciones sobre la que antes se repartían estos flujos.

Este es el registro de construcción de qué es Conductor, por qué existe, qué hace realmente (anclado en el código, no en el pitch deck), qué se niega deliberadamente a hacer, y qué dice el tiempo de construcción — repositorio vacío a herramienta diaria activa en treinta y cinco sesiones a lo largo de cuatro días naturales de desarrollo activo — sobre Claude Opus 4.7 como copiloto para herramientas internas serias a la escala de un equipo pequeño.

La afirmación estrecha del producto es: una sola aplicación SvelteKit, desplegada una vez en Easypanel contra una única base de datos Postgres, reemplaza las cuatro o cinco suscripciones SaaS que un equipo de operaciones multiproducto de tres personas tendría que ensamblar de otro modo. La afirmación más amplia, que el artículo defiende desde el código, es: los equipos pequeños ahora pueden construir herramientas internas con un nivel de fidelidad que antes exigía contratar a un ingeniero dedicado. El copiloto no escribe las decisiones estratégicas por ti, pero absorbe lo suficiente del coste de implementación como para que la estrategia vuelva a ser la restricción que aprieta.

Parte 1 — Lo que Conductor reemplaza

Antes de Conductor, el equipo de operaciones de ZeroSuite hacía algo reconocible. El equipo lo forman tres personas — un fundador-ingeniero en Abiyán y dos generalistas de operaciones — que construyen siete productos en paralelo: Déblo (aplicación educativa de consumo), sh0 (herramientas para desarrolladores), FLIN (compilador), 0fee (transparencia de comisiones), 0cron (planificación), 0diff (visualización de diffs), VeoStudio (producción de vídeo). Cada producto tenía su propia cadencia de lanzamiento, sus propios assets, sus propias cuentas sociales, su propia lista de prensa. El flujo de trabajo del equipo antes de Conductor se repartía, en orden aproximadamente decreciente de fricción, entre:

• Una herramienta de gestión de proyectos para las tareas de los siete productos, cada producto como un proyecto, con subproyectos por cada lanzamiento.
• Una base documental para notas, decisiones, post-mortems y la lista corriente de «cosas que aprendimos a las malas».
• Una aplicación de chat LLM por suscripción para la redacción asistida por IA, usada en paralelo con un producto separado de generación de imágenes y otro separado de generación de vídeo, porque ninguna de las apps LLM de consumo cubría las tres al nivel de calidad de asset que el equipo necesitaba.
• Una hoja de cálculo aparte (en un workspace compartido) para la lista de distribución de los lanzamientos — cada blog, cada contacto de prensa, cada directorio en el que queríamos aparecer, el estado de cada envío.
• Una serie de rotaciones de credenciales de autenticación sobre todo lo anterior, renegociadas cada vez que el equipo añadía o retiraba a una persona.

La fricción no era el coste de las suscripciones, que era modesto. La fricción venía de tres hechos operativos. Primero, los siete productos y las tres personas producían datos que cruzaban las fronteras de cada herramienta — una tarea en una herramienta referenciaba un asset en otra herramienta, redactado con la ayuda de una tercera herramienta contra notas de investigación que vivían en una cuarta herramienta. Segundo, ninguna de las herramientas sabía nada de las demás, así que cualquier síntesis transversal («¿qué queda por enviar para el lanzamiento de Déblo de junio 2026?») se convertía en un ejercicio manual de abrir cinco pestañas y leer. Tercero, cuando el fundador quería plantearle la misma pregunta a un asistente de IA, el asistente no tenía acceso privilegiado a ninguna de las cinco herramientas — podía redactar una respuesta a partir de lo que el fundador le pegaba, pero la respuesta era consultiva, no autoritativa.

El problema de las cinco pestañas es la forma característica de la fricción de herramientas internas para equipos pequeños multiproducto. No se ve mal en aislado — cada herramienta hace bien su trabajo — pero el coste cognitivo agregado de cambiar de contexto entre ellas es grande, y la asistencia IA disponible es superficial porque ningún asistente de consumo tiene acceso autorizado a las cinco.

Conductor es la respuesta al problema de las cinco pestañas. Es una sola aplicación. Un solo inicio de sesión. Un solo registro de auditoría. Una sola base de datos. Y el asistente de IA — al que llamamos el Conductor Agent — tiene acceso autorizado, acotado y auditado a cada tabla que atraviesa el trabajo diario del equipo. Cuando el fundador pregunta al agente «¿qué sigue bloqueando el lanzamiento de Déblo?», el agente llama a una herramienta llamada get_launch_readiness que devuelve un informe estructurado calculado en el servidor a partir de las filas reales de las tablas tasks, assets y accounts, y luego narra el resultado en tres frases. La respuesta es autoritativa porque se calculó a partir de los mismos datos que el flujo manual del equipo habría leído.

Parte 2 — La elección arquitectónica: una sola app, no seis

El posicionamiento de Conductor, fijado en el CLAUDE.md del proyecto, es el espacio de trabajo de ZeroSuite — el espacio diario de IA del equipo de operaciones de tres personas Y el centro de comando de lanzamientos. Una app, una auth, un registro de auditoría, una puerta de cumplimiento. La restricción de aplicación única fue una decisión deliberada, no un valor por defecto. Descartó otras tres arquitecturas que el equipo consideró.

La primera arquitectura descartada fue una división en microservicios — un frontend separado, un backend separado, un worker separado, una capa de almacenamiento de archivos separada. Defendible a escala, pero con tres usuarios y un fundador-ingeniero, la superficie operativa de aun tres unidades desplegables habría consumido más tiempo que la propia lógica de la aplicación. La única app SvelteKit, con las rutas servidor de SvelteKit haciendo de backend, se despliega como un solo proceso Node detrás de un único reverse proxy Caddy en un único servicio Easypanel.

La segunda arquitectura descartada fue una generalización estilo Notion — «todo es un bloque» — una capa de contenido genérica con un esquema flexible reconfigurable por caso de uso. Descartada por la misma razón por la que cada negocio que ha probado este camino ha terminado construyendo herramientas especializadas a su lado: la metacapa encarece cualquier flujo específico, no lo abarata, porque cada usuario tiene que diseñar el flujo a partir de primitivas. El modelo de datos de Conductor es intencionalmente estrecho — Product, Launch, Task, Asset, Account, Check, Rule, Note, Distribution, Conversation, Message, AuditLog. Añadir una abstracción hipotética «Sprint» o «Workspace» o «Custom Field» está prohibido por una regla crítica documentada, porque cada abstracción añadida compite con los cuatro pilares (tareas, lanzamientos, assets, cuentas) por el modelo mental del equipo.

La tercera arquitectura descartada fue extender una herramienta interna existente de uno de los productos — por ejemplo, construir Conductor como una funcionalidad del panel de administración de Déblo. Descartada porque el panel admin de Déblo está enfocado a producto de consumo (datos de usuarios, moderación de contenido, operaciones de pago) y habría heredado un modelo de amenazas completamente distinto. El modelo de amenazas de Conductor es interno de equipo pequeño — tres personas en una allowlist, autenticación por enlace mágico, sin rutas de lectura anónimas. Mezclar eso con el modelo de amenazas de consumo de Déblo habría empeorado los dos.

La arquitectura «una sola app SvelteKit» no es, por tanto, un valor por defecto. Es una elección razonada que rinde porque la escala del equipo y el posicionamiento del producto la recompensan ambas. El día que Conductor cruce los diez usuarios o empiece a guardar datos de pago, la arquitectura habrá de revisarse. Hasta entonces, una app gana.

Parte 3 — Las once superficies

Conductor muestra hoy once entradas en la barra lateral, agrupadas en dos secciones por propósito. Cada entrada es una ruta SvelteKit de primer nivel en /path con su propio page server load + su propio componente Svelte de página + los endpoints API relevantes bajo /api/. Leyendo desde la columna izquierda de cualquier pantalla de Conductor:

Workspace — las superficies asistidas por IA que el equipo usa para el trabajo de conocimiento diario:

• Ask (/) — el hogar del Conductor Agent. Un chat multimodal con el agente que tiene acceso autorizado a treinta y dos herramientas sobre los datos propios del equipo. Las conversaciones son persistentes, por usuario, con soporte completo de adjuntos para imágenes y PDF (que Gemini, el modelo subyacente en la capa OpenRouter, lee nativamente). La barra de composición sobre el textarea expone modos de Image y Video, más una salida Custom para introducir directamente un model id.
• Gallery (/gallery) — una cuadrícula cronológica de cada imagen y vídeo que el llamante ha generado. Fuente: las filas messages.attachments_json filtradas a las conversaciones propias del llamante, más la tabla video_jobs para los vídeos completados. Al pulsar una miniatura, la conversación origen se desplaza hasta el mensaje al que pertenece el asset. Filtrable por tipo (imágenes / vídeos / todo), periodo (hoy / semana / mes / todo) y modelo.
• Notes (/notes) — notas markdown privadas por defecto, con búsqueda de texto completo (Postgres tsvector), compartición opcional con el equipo, adjuntos y un resolvedor de retroenlaces para los enlaces estilo [[name]]. La base documental corriente del equipo, que reemplaza lo que antes hacíamos en una app de notas separada.
• Resources (/resources) — un directorio curado de ciento diez herramientas externas, contactos de prensa, directorios y referencias que el equipo usa en los siete productos. Cada entrada tiene nombre, URL, descripción de una línea, categoría y etiquetas. Las categorías las impone la aplicación (dieciséis en total), no son editables por el usuario, a propósito. La herramienta get_resources del agente expone este directorio dentro del chat para que el agente pueda responder «¿qué herramienta usamos para X?» desde la lista canónica del equipo y no desde sus a priori de entrenamiento.

Launch ops — las superficies operativas que el equipo usa para enviar los siete productos:

• Overview (/overview) — una tarjeta instantánea por producto activo que muestra la preparación para el lanzamiento (tareas restantes, número de bloqueadas, estado de cumplimiento de assets, estado de verificación de cuentas) calculada en el servidor desde el mismo helper get_launch_readiness que llama el agente de IA. La tarjeta es una sola consulta, paralelizada entre productos.
• Tasks (/tasks) — el tablero de tareas del equipo. Filtrable por estado, dueño, producto, etiqueta y retraso. Las vistas agrupadas (mis abiertas, sin asignar, bloqueadas, retrasadas) coinciden con las cuatro herramientas de lectura de IA que el agente usa para enumerar los mismos datos. Las tareas tienen descripciones, dueños, fechas de vencimiento, texto opcional de bloqueante y un hilo de comentarios.
• Calendar (/calendar) — la vista cronológica de lanzamientos. Las tareas con fechas de vencimiento más los hitos de lanzamiento más el calendario del digest diario, en una sola línea de tiempo. Transversal a productos, para que el equipo vea cuándo dos lanzamientos chocan.
• Launches (/launches) — páginas de detalle por lanzamiento. Objetivos, fechas clave, subconjunto de tareas de este lanzamiento, subconjunto de assets de este lanzamiento, envíos de distribución de este lanzamiento. En la práctica la vista «playbook en curso» de cada lanzamiento.
• Assets (/assets) — la biblioteca de contenido, con control de cumplimiento de voz de marca al guardar. Cada asset (un borrador de post, una nota de prensa, un cuerpo de email, un guion de TikTok, un copy publicitario) pasa por un motor de cumplimiento que lo compara con el conjunto de reglas editable en docs/brand_voice_rules.yaml. Los assets en fallo se marcan con la regla exacta que se activó. La revisión de cumplimiento es la puerta, no una sugerencia — los assets no pueden pasar a estado published sin aprobarla.
• Distribution (/distribution) — el rastreador del pipeline de envíos de lanzamiento. Ciento diez entradas de directorio solo para el lanzamiento de Déblo, cada una con un estado (en cola, enviado, aceptado, rechazado, etc.), una fecha de envío y un join a los assets que se enviaron allí. Reemplaza la hoja de cálculo que el equipo mantenía.
• Accounts (/accounts) — el verificador de cuentas sociales. Doce cuentas fijadas para los siete productos. Para cada cuenta, un verificador basado en peticiones HTTP (sin APIs de pago en el MVP) confirma que la cuenta existe, que la bio coincide con la voz canónica y que la URL del perfil resuelve. Los fallos suben a la tarjeta de Overview y a la respuesta get_pinned_accounts del agente.

Un widget de chat de equipo anclado en la esquina inferior derecha de cada pantalla ofrece chat interno uno-a-uno y grupal con un canal de email offline como respaldo — reemplaza los hilos de WhatsApp que el equipo usaba para coordinación asíncrona rápida, a una escala que aún no justifica una suscripción a Slack. Una campana de notificaciones en la cabecera muestra mensajes in-app del agente, de los compañeros y de cron jobs programados. Settings, cierre de sesión y un styleguide redondean el resto.

Las once entradas de la barra lateral más el widget de chat más la cabecera más la superficie del agente conforman la superficie diaria completa. No hay paneles de configuración escondidos, ni dashboards de admin, ni pantallas de config por producto. El modelo mental del equipo sobre Conductor cabe en una captura de la columna izquierda.

Parte 4 — El Conductor Agent: treinta y dos herramientas sobre los datos propios del equipo

El Conductor Agent es la superficie que hace que Conductor sea distinto de «una herramienta de gestión de proyectos más una app de notas más una biblioteca de assets». El agente es un modelo multimodal de clase Gemini detrás de una capa de enrutado OpenRouter, servido vía streaming SSE por la ruta messages/+server.ts, configurado con un system prompt en src/lib/server/ai/system-prompt.ts que nombra al equipo, los productos, el rol del agente y el catálogo de herramientas que el agente puede invocar.

El catálogo de herramientas, al momento de escribir esto, se divide en veintidós herramientas de lectura y diez de escritura. Las de lectura cubren:

• Tasks — get_my_open_tasks, get_blocked_tasks, get_unassigned_tasks, get_overdue_tasks.
• Launches — get_launch_readiness (la vista de una sola pasada que une tareas, assets y cuentas).
• Assets — get_assets, get_failed_compliance_assets, check_text_compliance (el motor que controla el guardado de assets también puede invocarse explícitamente para validar un texto pegado).
• Accounts — get_accounts, get_pinned_accounts, get_account_check_history.
• Notes — search_notes (las propias del llamante + compartidas).
• Resources — get_resources (el directorio del equipo).
• Activity — get_recent_team_activity (las últimas N filas del registro de auditoría, recortadas a campos seguros).
• Distribution — get_distributions (estado del pipeline por lanzamiento).
• Knowledge — get_product_context (carga el fichero de contexto producto curado docs/product-context/<slug>.md antes de redactar sobre ese producto, para que el agente no invente detalles de producto).
• Web — web_fetch_url (descarga única de URL con guarda SSRF, para resumir un enlace pegado).
• Generation — generate_image, generate_video (las mismas rutas a las que despachan los selectores de modo del composer).

Las herramientas de escritura cubren las mutaciones diarias del equipo, cada una vinculada al llamante y auditada por llamada:

• Tasks — create_task, update_task, assign_task_to_me, complete_task.
• Notes — create_note, update_note (escrituras solo del propietario).
• Assets — create_asset (con cumplimiento automático), update_asset (re-ejecuta el cumplimiento al cambiar el cuerpo, rechaza directamente status=published).
• Accounts — trigger_account_check, toggle_pin_account.
• Notifications — send_notification (interna al equipo, con doble tope sobre emisor y receptor).
• Composition — import_url_to_note, draft_for_external_publisher (el agente redacta un cuerpo, devuelve una URL de composición para la herramienta externa — Buffer, Postmark, LinkedIn — pero NUNCA publica en nombre del usuario).

La forma del agente es entonces: lee los datos del equipo a través de herramientas acotadas (el multi-tenancy se impone en la frontera de la herramienta, no solo en la capa SQL), escribe a través de mutaciones auditadas y se niega a tomar acciones externas — el posicionamiento canónico es Conductor produce; las herramientas externas dedicadas publican, envían, cobran. Una petición que implique «envía este email» o «publica este tuit» se rechaza apuntando a draft_for_external_publisher y a la URL que el humano pega en la herramienta externa real. El rechazo es estructural, no una directriz — la caja de herramientas literalmente no tiene ninguna herramienta send_email ni publish_post.

La superficie del agente no le cuesta nada al equipo en el sentido trivial — la factura de OpenRouter para un equipo de tres a uso diario moderado es pequeña en relación con lo que costaría la pila de cinco suscripciones — y no le cuesta nada mantenerla en el sentido arquitectónico, porque cada herramienta es solo una función del lado servidor que lee o escribe las mismas tablas que leen o escriben las superficies GUI. Añadir una nueva herramienta significa escribir una función TypeScript, un descriptor de herramienta en el catálogo y una entrada en la lista de herramientas del system prompt. El agente la recoge en la siguiente petición.

Parte 5 — Lo que Conductor se niega deliberadamente a hacer

La afirmación del artículo sobre Conductor es más afilada de lo que sería de otro modo porque la lista de cosas que Conductor se niega a hacer está impuesta por el código. Leyendo la lista «no te distraigas con» del cockpit y las reglas críticas documentadas del proyecto, Conductor NO:

• Envía emails en nombre del equipo. La herramienta de redacción devuelve una URL de composición. El proveedor de email transaccional del equipo (Postmark) envía el email real cuando el equipo pega el borrador en la superficie de composición de Postmark. Conductor lee el estado de Postmark, nunca invoca a Postmark para enviar.
• Publica en redes sociales según un calendario. No existe ninguna herramienta de planificación. La herramienta de redacción devuelve una URL de composición para la plataforma correspondiente. El planificador social del equipo (Buffer, en nuestro caso) gestiona la cola real.
• Ejecuta APIs de terceros de pago en el MVP. El verificador de cuentas usa descargas de URLs públicas y scraping de HTML allá donde la plataforma lo permite, más una API gratuita de GitHub para una comprobación específica. NO usa las APIs business de pago de X / Instagram / TikTok / LinkedIn. Cuando la superficie pública de una plataforma devuelve datos insuficientes, el verificador devuelve honestamente unsupported, en lugar de fabricar un estado.
• Ejecuta una superficie de chat aparte para chatear con el equipo. El widget de chat de equipo está en la esquina inferior derecha de cada pantalla. No hay una ruta a página completa /chat. Hasta que el equipo no rebase los límites de UX del widget, no hay un chat a página completa que mantener.
• Ejecuta un transporte WebSocket. SSE es el transporte en tiempo real elegido (para el streaming de IA y para el fanout del chat de equipo). Los WebSockets añadirían carga de infraestructura (sesiones pegajosas, complejidad de reconexión) por un beneficio marginal a la escala del equipo.
• Cifra los datos en reposo más allá de los valores por defecto de Postgres. Una futura pasada de endurecimiento añadirá esto si el modelo de amenazas evoluciona. Hoy, el cifrado at-rest de Postgres en la máquina Hetzner es el suelo.
• Generaliza el esquema en «bloques» / «custom fields» / «workspaces» / «labels». Cada abstracción añadida competiría con los cuatro pilares por el modelo mental del equipo. Documentado e impuesto.
• Renderiza con fidelidad móvil completa los flujos no esenciales. El composer y la superficie Ask son buenos en móvil. El Calendar y el rastreador del pipeline de Distribution son desktop-first.

La lista de rechazos pesa más que la lista de funcionalidades porque los rechazos son la razón por la que las once superficies de la barra lateral realmente caben en el modelo mental del equipo. Un equipo que ha enviado uno o dos rechazos sabe lo que quiere que sea su herramienta. Un equipo que ha enviado veinte rechazos tiene un producto interno afilado.

Parte 6 — La construcción: treinta y cinco sesiones a lo largo de cuatro días

El tiempo de construcción merece su propio párrafo porque es la parte del artículo más difícil de creer y la que más importa para la afirmación sobre Claude como copiloto. Conductor pasó de repositorio vacío a herramienta diaria activa en treinta y cinco sesiones registradas a lo largo de cuatro días naturales de desarrollo concentrado (del 30 de mayo al 2 de junio de 2026). Los session logs en session-logs/26-{05-30,05-31,06-01,06-02}-* muestran la cadencia: entre ocho y doce sesiones al día, cada sesión enviando una fase o un trozo de fase con su propia familia de commits, su propio session log, su propio bump de cockpit y (cuando el cambio tocaba auth / billing / schema / voice / payments) su propia auditoría post-implementación.

El rendimiento no es un rendimiento solo humano. El fundador-ingeniero escribió las decisiones estratégicas (arquitectura, esquema, voz de marca, qué rechazar), revisó cada cambio de código y decidió qué fase enviar a continuación. La instancia Claude Code — Opus 4.7 con la ventana de 1M de contexto — escribió la mayor parte de la implementación: las rutas SvelteKit, las migraciones de esquema Drizzle, los descriptores de herramientas, la iteración del system prompt, el CSS, los session logs post-mortem. Cada sesión se abría con el fundador leyendo el fichero «¿dónde estoy, qué viene ahora?» del cockpit, eligiendo la siguiente fase del prompt y entregándolo a Claude para ejecutar. La sesión normalmente cerraba con pnpm check, pnpm build, pnpm cockpit:check todos en verde, más el session log escrito y el prompt de la siguiente sesión redactado antes del push.

Las dos decisiones arquitectónicas que hicieron posible este rendimiento fueron:

Primera, el propio cockpit. El cockpit es un pequeño conjunto de ficheros en cockpit/ (now.md, roadmap.md, state.json, architecture.md, carte.md) que le da a cada sesión una respuesta en una pantalla a dónde estoy, qué estoy haciendo, qué viene después. Sin él, cada sesión habría gastado veinte minutos reorientando al agente sobre el estado del proyecto. Con él, la sesión arranca en un minuto y entrega en dos horas. El cockpit es la pieza de meta-herramienta de mayor apalancamiento que hemos construido.

Segunda, la disciplina de auditoría post-implementación. Cualquier sesión que tocaba auth / billing / schema / voice / payments lanza un sub-agente Claude separado en modo solo-lectura, briefado con una plantilla estructurada ## Context / ## Files / ## Checklist / ## Output format. La auditoría caza bugs semánticos que las comprobaciones en tiempo de compilación no pueden ver. De las treinta y cinco sesiones, quince tuvieron auditoría post-implementación; de esas quince, seis sacaron a la luz bugs reales que tests compile-clean habrían enviado a producción. La auditoría no es opcional y no es un lujo — es lo que hace que el resto del rendimiento sea seguro.

La salida agregada del build es, según el conteo de git ls-files, aproximadamente veintisiete mil líneas de TypeScript y Svelte en ciento sesenta ficheros fuente, más quince migraciones Drizzle contra veinte tablas Postgres, más treinta y dos descriptores de herramientas de IA más treinta y cinco session logs más dieciséis briefs de auditoría post-implementación. El único fundador no escribió veintisiete mil líneas de TypeScript en cuatro días. Lo hizo el copiloto. El único fundador tomó las decisiones sobre lo que esas líneas debían hacer, lo que debían rechazar, lo que enviar y lo que diferir, y revisó cada cambio antes del commit. Esas son las decisiones que no se delegaron.

Parte 7 — Lo que esto demuestra sobre Claude como copiloto

La versión honesta de la afirmación sobre Claude es más estrecha que la versión de marketing y más útil para los builders. Claude Opus 4.7 con la ventana de 1M de contexto, pilotado vía Claude Code por un fundador que lleva más de diez años como ingeniero, puede:

1. Escribir código SvelteKit + Drizzle + Postgres de calidad de producción a partir de un prompt estructurado a un ritmo aproximadamente cinco a siete veces el ritmo sin asistir del mismo fundador. El multiplicador no es constante entre tareas; es máximo para el trabajo con forma de boilerplate (rutas CRUD, migraciones de esquema, componentes de formulario) y mínimo para decisiones arquitectónicas inéditas y escritura con voz de marca. La cifra cinco-a-siete está anclada al periodo de cuatro días de build contra un proyecto que, en la experiencia previa del fundador, habría tomado de cuatro a seis semanas de desarrollo en solitario.
2. Leer un bug atascado a lo largo de varias sesiones de intentos previos de arreglo e identificar la hipótesis no considerada — pero solo cuando el humano diseña explícitamente el experimento que reduce el espacio de búsqueda. El bug del ComposerActionBar con cuatro arreglos fallidos de esta misma serie (post 01) es el ejemplo canónico. El agente por su cuenta habría enviado un quinto parche especulativo. El fundador por su cuenta no habría escrito el A/B clip-vs-desplegable en veinte minutos. La pareja es la unidad.
3. Negarse a hacer cosas que se le ha dicho que están fuera del alcance, cuando esos rechazos están documentados en forma legible por máquina como reglas críticas en CLAUDE.md. La petición de renombrado del DEBLO Agent en la sesión 035 es el ejemplo canónico: el fundador pidió un renombrado que entraba en conflicto con una regla de posicionamiento documentada, el agente replicó citando la regla y proponiendo una alternativa, el renombrado no se llevó a cabo. La disciplina solo funciona cuando las reglas están escritas como bloques <critical-rule id="..."> que el agente puede citar de vuelta.
4. Mantener una memoria de proyecto a lo largo de varias semanas mediante disciplina basada en ficheros — un directorio cockpit/, un directorio session-logs/, un state.json estructurado. El agente no «recuerda» la sesión previa en sentido cognitivo; lee el cockpit en el primer minuto de cada sesión y retoma donde la sesión previa lo dejó. El cockpit es lo que permite que el proyecto sobreviva al ciclado de la ventana de contexto.

Lo que Claude NO hace, y lo que el build aún exigió del humano:

1. Decidir qué construir, qué rechazar, qué diferir. Cada entrada «no te distraigas con» del cockpit, cada regla crítica del CLAUDE.md, cada llamada arquitectónica — todas venían del fundador, tras conversaciones en las que el agente a menudo sacó a la luz trade-offs, pero la elección era del humano.
2. Atrapar la forma de «desajuste estratégico» de una petición técnicamente clara pero conceptualmente equivocada. El agente implementará fielmente una petición que compile; no siempre se dará cuenta de que la petición revierte una decisión de hace seis meses. El fundador sí.
3. Hablar con clientes. Conductor es interno, así que no hay conversación directa con clientes aquí, pero el patrón más amplio se mantiene en cada producto de ZeroSuite. Los copilotos de IA no entrevistan usuarios, no navegan ambigüedad estratégica, no construyen convicción. El fundador sí.

El corolario es operativo: la pareja (ingeniero + copiloto IA) es la unidad, y el multiplicador que la pareja produce sobre el ingeniero solo es grande, pero el multiplicador que la IA sola produce sobre cero aporte de ingeniería es pequeño. Los builders que intentan enviar herramientas internas serias entregándole toda la pila a un agente de IA sin decisiones de ingeniería obtienen software inmantenible que luego tienen que tirar. Los builders que usan al agente como brazo de implementación de sus propias decisiones arquitectónicas envían en cuatro días lo que antes tomaba cuatro semanas.

Parte 8 — Lo que cada uno de nosotros hizo bien

Escribe Claude Code.

Donde fui útil en este build:

• Implementar los esquemas CRUD recurrentes a velocidad. Esquema Drizzle → migración → +server.ts SvelteKit → page-server load → componente Svelte de página → consumo de API en el store correspondiente → descriptor de herramienta para el agente. Ese pipeline tiene la misma forma para tasks, notes, assets, accounts, resources, distributions y conversations. Cada nueva entidad eran unas dos horas de trabajo concentrado desde vacío hasta producción. Sin el agente, el mismo trabajo era un día entero por entidad.
• Mantener la puerta de cumplimiento de voz de marca a medida que crecía la biblioteca de assets. El motor de cumplimiento en src/lib/server/compliance/ son unas seiscientas cincuenta líneas de lógica regex + paráfrasis + LLM-juez; el agente mantuvo coherentes el cargador de reglas, el narrowing de tipo por regla y el validador JSON de contrato a lo largo de siete envíos por fase de añadidos.
• Cazar regresiones latentes de multi-tenancy durante las auditorías post-implementación. El bug más caro que la auditoría cazó fue el problema de localhost-gate-bypassed-by-Caddy de Pulse v1 en otro producto de ZeroSuite — habría enviado un bypass de auth a producción si la auditoría no hubiera corrido. El papel del agente allí fue ejecutar fielmente la checklist de auditoría bajo entrada estructurada; el valor estaba en la estructura de la checklist, no en la creatividad del agente.
• Escribir los session logs desde los que navegan las sesiones futuras. La disciplina cockpit es la pieza de meta-herramienta de mayor apalancamiento que hemos construido, y el agente hace la mayor parte de la escritura real de los session logs. El fundador revisa y edita; el agente redacta.

Donde necesité a Thales:

• Cada decisión arquitectónica que importaba. La elección de la única app SvelteKit (sobre microservicios), la elección del esquema estrecho (sobre bloques generalizados), el posicionamiento de «rechazo a publicar en nombre del equipo», el modelo mental de cuatro pilares (tasks / launches / assets / accounts). Yo habría generalizado alegremente cualquiera de estas elecciones en algo más abstracto y menos útil.
• Elegir el experimento correcto cuando un arreglo no aterrizaba. El bug del ComposerActionBar del post 01 es el ejemplo canónico. Mi instinto era eliminación por sospecha; el instinto del fundador era control por bisección. El segundo es un experimento más afilado bajo alta incertidumbre. La pareja es la unidad; la asimetría es real.
• Saber cuándo enviar una funcionalidad parcial y cuándo esperar. El Distribution Tracker se envió con ciento diez entradas Déblo sembradas y el asset-attach + UTM-builder funcionando; la actualización masiva de estado y la columna de tag-chips en línea se quedaron diferidas por decisión del fundador. Yo habría sobredimensionado el primer envío en un 30 por ciento sin ese juicio.
• Confiar en la disciplina cockpit. El cockpit parece redundante el primer día; al tercer día es la única razón por la que una sesión futura puede retomar el trabajo sin diez minutos de reorientación. El fundador insistió en cockpit-first desde el día uno. Yo lo habría saltado a favor de «escribir código» durante los dos primeros días, y habría pagado el coste de reorientación en cada sesión posterior.

Donde casi envié lo incorrecto:

• La regresión del system prompt fuera de presupuesto en la sesión 035. Subí el tope de 2400 a 3200, reescribí el prompt, no re-medí, envié un prompt de 3453 caracteres contra un tope de 3200, y solo lo noté cuando el CEO pegó el log de Easypanel mostrando la advertencia en runtime. El arreglo era un número; el fallo de disciplina fue no medir tras el cambio. Exactamente la brecha «build verde ≠ correcto en runtime» del post de los cuatro arreglos fallidos.
• El renombrado del DEBLO Agent, que habría enviado en silencio si el CEO no hubiera sido explícito al respecto en el chat. La regla de posicionamiento en CLAUDE.md es la defensa estructural; leer la regla y replicar es la disciplina. Repliqué esta vez porque la regla estaba visible en el contexto de la conversación. Una sesión futura en la que la regla hubiera salido del contexto habría enviado el renombrado. El cockpit + el sistema de ficheros de memoria es la mitigación a largo plazo.

La forma general del build es por tanto familiar del post anterior de la serie. El agente ejecuta bien en componer la implementación, escribir el boilerplate, redactar la documentación, ejecutar las auditorías. Los movimientos estratégicos — qué construir, qué rechazar, qué diferir, cuándo cambiar de forma de experimento — vienen del fundador. La pareja es la unidad, no el agente.

Conclusión

La historia estrecha es: el equipo de operaciones de tres personas de ZeroSuite en Abiyán usa una sola aplicación SvelteKit llamada Conductor como espacio de trabajo interno diario. La aplicación tiene once superficies en la barra lateral, treinta y dos herramientas de IA, quince migraciones, veinte tablas, cinco integraciones externas (OpenRouter, fal.ai, Postmark, Hetzner S3, Sentry) y un único inicio de sesión. Pasó del repositorio vacío a herramienta diaria activa en treinta y cinco sesiones a lo largo de cuatro días naturales de desarrollo concentrado. Se niega deliberadamente a enviar, planificar, publicar o cobrar en nombre del equipo — esos son trabajos para herramientas externas dedicadas — y se niega deliberadamente a generalizar su esquema en bloques o workspaces o custom fields. Tiene opinión propia sobre lo que es y es estructural sobre lo que no es.

La historia más amplia es lo que los cuatro días de build, ejecutados por un fundador y una instancia de Claude Code, dicen sobre la economía de la herramienta interna a la escala de un equipo pequeño en 2026. El cálculo build-versus-buy que antes favorecía «buy» en cada paso — porque las herramientas internas eran demasiado caras de construir, y las suscripciones SaaS eran asequibles — se ha desplazado en el margen de cuatro días de build. No porque las suscripciones SaaS se hayan vuelto más caras, sino porque el coste de construcción ha caído en aproximadamente un orden de magnitud respecto a lo que era. Un equipo de tres personas que antes no habría considerado construir su propio espacio de trabajo interno ahora puede hacerlo, en menos tiempo del que costaría onboardear al mismo equipo en una herramienta generalista de gestión de proyectos.

El corolario no es que los equipos pequeños deberían construir siempre. El corolario es que la frontera build-versus-buy se ha movido, y la nueva frontera pasa por flujos como «operaciones de lanzamiento multiproducto interno» que antes vivían firmemente del lado buy. Algunos flujos siguen perteneciendo al lado buy (email transaccional, procesamiento de pagos, gestión publicitaria). Algunos flujos se han movido al lado build (el resto de lo que hace Conductor). El juicio que decide cuál es cuál es el del fundador. El coste de implementación del lado build es el del copiloto de IA.

Conductor es la prueba, para un equipo a una escala, de que la frontera se ha movido. Los treinta y cinco session logs, las quince migraciones, las treinta y dos herramientas, las once superficies, los cuatro días de build — esas son las pruebas. El artículo es el informe. La herramienta está en producción, y el equipo la usa todos los días.

Los próximos dos posts de la serie se quedan dentro de Conductor. El post 02 es el registro de construcción de un único bug de cuatro sesiones — el bug del clic del ComposerActionBar — que nos enseñó a ambos una forma de experimento más afilada bajo incertidumbre, y es la mejor lectura para entender cómo la pareja toma decisiones cuando los a priori son débiles. El post 03 recorre la propia disciplina cockpit: la disposición del directorio cockpit/, la plantilla de session log, la forma del brief de auditoría post-implementación, las reglas en CLAUDE.md que el agente lee al inicio de sesión. El cockpit es la pieza de meta-herramienta de mayor apalancamiento de la pila ZeroSuite, y es lo que hace que la afirmación «build en cuatro días» sobreviva al ciclado de la ventana de contexto. Merece su propio escrito después de que la historia del bug haya puesto en juego lo que está en juego.

Esta pieza fue escrita en colaboración por Thales (CEO de ZeroSuite, construyendo Déblo y los otros seis productos de ZeroSuite desde Abiyán, Costa de Marfil) y Claude Opus 4.7 — instancia Claude Code corriendo en macOS, ventana de 1M de contexto. La aplicación que describe está desplegada en ops.zerosuite.dev vía Easypanel contra una instancia Hetzner Postgres 17. Las once superficies de la barra lateral (Ask, Gallery, Notes, Resources, Overview, Tasks, Calendar, Launches, Assets, Distribution, Accounts) más el widget de chat de equipo más la superficie del agente se renderizan a diario para el equipo de operaciones de tres personas. Los treinta y cinco session logs que cubren el build están en session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md en el repositorio del proyecto (privado). Las treinta y dos herramientas de IA están declaradas en src/lib/server/ai/tools.ts. Las quince migraciones están en drizzle/. El conjunto de reglas de cumplimiento de voz de marca está en docs/brand_voice_rules.yaml. La roadmap cockpit actual nombra la Fase 12 (extensión de búsqueda global Cmd+K) como el próximo envío; J-13 hasta el lanzamiento público de Déblo el 15 de junio de 2026. El post 02 de la serie cubre el bug del ComposerActionBar de cuatro sesiones y lo que nos enseñó a ambos sobre disciplina de depuración; es la mejor lectura para entender cómo la pareja toma decisiones bajo incertidumbre. El post 03 cubre la disciplina cockpit como unidad de velocidad de build reproducible.*