Claude Code como sistema operativo para founders: guía práctica 2026

La pregunta que cambia todo

Cuando usas Claude.ai en el navegador, le haces preguntas y recibes respuestas. Es útil. Pero tiene un límite: cada conversación empieza de cero, no tienes control sobre qué información está en contexto, y no puedes conectarlo directamente a tus archivos, proyectos o sistemas.

Claude Code es diferente. Corre en tu terminal, tiene acceso a tu sistema de archivos, puede ejecutar comandos, crear sub-agentes que trabajan en paralelo, y conectarse directamente a las herramientas que usas. Carl Votti, founder de CC4PMs y uno de los usuarios más documentados de la herramienta, lo describe como un sistema operativo personal para trabajar con IA.

La arquitectura que describe tiene seis capas, y ninguna requiere saber programar.

Las seis capas del OS

Knowledge: archivos de contexto sobre tu empresa, clientes, preferencias, reglas de trabajo. Claude los lee al inicio de cada sesión y trabaja con ese contexto desde el primer mensaje.

Projects: un directorio por proyecto activo con todos los artefactos relevantes. Si trabajas en 5 proyectos simultáneos, cada uno tiene su carpeta con su contexto específico.

People: notas sobre las personas con quienes trabajas. Cuando conectas esto con una herramienta de transcripción de reuniones (Granola, Fireflies), cada reunión alimenta automáticamente el perfil de la persona. Antes de un email o una llamada, Claude tiene el historial real de interacciones.

Data: análisis en notebooks Jupyter. Cualquier análisis de datos queda documentado paso a paso. Tu equipo puede verificar exactamente cómo Claude llegó a cada número.

Tasks: un archivo markdown de seguimiento de tareas activas. Claude lo consulta para saber en qué punto está cada cosa.

CLAUDE.md: el documento de identidad permanente. Siempre en contexto, define quién eres, cómo trabajas, qué reglas sigues. Es lo primero que Claude lee en cada sesión.

La combinación de estas seis capas hace que Claude tenga, en cada sesión, el contexto que necesita para ser útil de verdad. No un asistente genérico: tu asistente, con tu contexto.

Context engineering, no prompt engineering

Esta es la distinción más importante para entender por qué algunos usuarios obtienen resultados radicalmente mejores que otros.

El prompt engineering se enfoca en cómo formulas la pregunta. El context engineering se enfoca en qué información está disponible cuando Claude responde.

La calidad del output depende directamente de la calidad del contexto. Puedes tener el prompt perfecto con contexto pobre y obtener resultados mediocres. Puedes tener un prompt simple con contexto rico y obtener algo excelente.

Andrej Karpathy, uno de los investigadores de IA más respetados, tiene una regla práctica: preferir CLIs sobre APIs, y APIs sobre MCPs. Cada nivel añade overhead de contexto. GitHub CLI, por ejemplo, es una herramienta donde Claude opera con competencia nativa: sin configuración adicional, sin tokens desperdiciados en la capa de integración.

El problema del context rot

Cuanto más larga es una sesión de Claude Code, más contexto se acumula. Y a partir de cierto punto, ese contexto se convierte en ruido.

Es lo que se llama context rot: la degradación de la calidad de las respuestas cuando la ventana de contexto se llena con información que ya no es relevante para la tarea actual. Claude empieza a mezclar contexto de tareas anteriores con el trabajo presente.

La solución no es empezar una sesión nueva cada 10 minutos. Es diseñar el trabajo para que el contexto relevante esté presente y el irrelevante no.

Los sub-agentes resuelven esto de manera elegante. Una búsqueda web compleja delegada a un sub-agente consume un 0.5% del contexto principal, en vez del 9% que consumiría si se hace en la sesión principal. El sub-agente corre sus 30,000 tokens internamente, hace el trabajo, y devuelve solo el resultado.

La pregunta útil antes de cada tarea: ¿la sesión principal necesita ver el proceso, o solo el resultado?

Skills: instrucciones que Claude sigue sin que se las repitas

Los skills son lo que convierte Claude Code en un sistema con memoria de proceso, no solo memoria de contexto.

Un skill es un set de instrucciones que Claude aplica automáticamente cuando detecta cierto patrón de tarea. No requieren código. El skill de diseño frontend de Anthropic, por ejemplo, es texto en lenguaje natural: “piensa en el objetivo del usuario”, “no uses estilos genéricos”, “sigue estas reglas estéticas”. La diferencia en el output comparado con trabajar sin el skill es sustancial.

Para founders y PMs, los casos de uso más útiles son los procesos repetitivos con reglas bien definidas. Un brief de cliente que siempre sigue la misma estructura. Un reporte semanal con las mismas secciones. Un análisis de propuesta con los mismos criterios. El skill codifica esas reglas una vez, y Claude las aplica cada vez que detecta el patrón.

El builder-validator pattern amplifica esto: ejecutar la tarea una vez, luego hacer una segunda pasada validando el resultado contra las mismas reglas del skill. La razón es que Claude no tiene distancia crítica natural sobre su propio output. La segunda pasada fuerza esa reflexividad. La diferencia en calidad es consistente.

La jerarquía de integración

Cuando quieres conectar Claude a tus herramientas, hay tres opciones con características distintas.

CLI (Command Line Interface): la opción más eficiente. Si la herramienta tiene una CLI oficial, Claude la usa directamente sin overhead adicional de contexto. GitHub CLI y Vercel CLI son los más útiles para trabajo de producto y desarrollo.

MCPs (Model Context Protocol): conectores que convierten APIs complejas en intenciones naturales. Son útiles cuando no hay CLI disponible, pero consumen tokens solo por existir. Tavily MCP para búsqueda web consume algunos miles de tokens en una sesión vacía. La regla: activar MCPs solo cuando los necesitas, no mantenerlos todos encendidos.

APIs directas: la opción más técnica, para casos donde las dos anteriores no existen o no cubren el caso de uso.

Para la mayoría de los workflows de founders en LATAM, la combinación CLI + 2-3 MCPs específicos cubre el 90% de los casos sin desperdiciar contexto.

Un patrón concreto para empezar

En Kreante usamos una versión de esta arquitectura para los proyectos de clientes. Cada proyecto tiene su directorio con contexto específico: el brief, la stack técnica, las restricciones del cliente, las reglas de entrega.

Cuando un PM empieza una sesión sobre un proyecto, Claude tiene ese contexto disponible sin que nadie tenga que repetirlo. El resultado: menos tiempo en setup, más tiempo en trabajo real.

El punto de entrada más práctico: empieza por CLAUDE.md. Define quién eres, cómo trabajas, qué no quieres que Claude asuma. Ese documento solo, que siempre está en contexto, mejora la calidad de todos los outputs sin ningún otro cambio.

El segundo paso: crea un skill para tu proceso más repetitivo. No necesita ser perfecto desde el primer día. Los skills mejoran iterativamente.

Herramientas relacionadas

Si Claude Code te parece demasiado técnico como punto de entrada, Claude.ai con Projects y Skills cubre una parte importante de esta funcionalidad en una interfaz más accesible. Ver el artículo sobre cómo dominar Claude sin experiencia técnica para un enfoque paso a paso.