tesis de apertura
El mismo Claude responde distinto en chat.claude.ai, en Cowork y en Claude Code. La diferencia no es el modelo: es qué contexto carga, qué herramientas tiene y qué permisos respeta. Aprender Cowork y Code antes de tocarlos sobre el repo evita confundir limitaciones de la herramienta con limitaciones del modelo.
tres formas de usar Claude
Conversación libre. Sin proyectos persistentes. Sin permisos sobre archivos. Útil para preguntas puntuales.
Projects con instrucciones y archivos persistentes. Sesiones reusables. No edita archivos directamente — propone.
CLI con permisos sobre tu sistema de archivos. Ejecuta comandos, edita código, llama tools. Tu repo es el contexto.
Esta sesión cubre Cowork. La sesión B cubre Code. El workshop principal usa ambos.
qué entrega esta sesión
No es una clase teórica. Es 4h de práctica con 8 ejercicios sobre material real. Cada ejercicio termina con un artefacto que vas a usar en el workshop principal.
Tres palabras que se usan como sinónimos en marketing. No lo son. La diferencia entre ellas decide qué puedes y qué no puedes pedir a la herramienta.
tres niveles de capacidad
| capacidad | LLM crudo | asistente | agente |
|---|---|---|---|
| memoria entre turnos | no | sí (sesión) | sí (sesión + repo) |
| contexto persistente | no | project / files | repo entero + CLAUDE.md |
| acceso a herramientas | no | limitado | completo (read/write/exec) |
| cambia el mundo | nunca | vía humano | vía permisos |
| ejemplos | API directa | claude.ai · Cowork | Claude Code · Cursor agent |
la diferencia operativa
Los archivos, instrucciones, conversación previa, system prompt y memoria que el modelo "ve" antes de responder. Si no está en el contexto, para el modelo no existe.
Las acciones que el modelo puede ejecutar — leer un archivo, ejecutar un comando, escribir un commit, hacer un push. Sin permisos, el modelo solo emite texto.
Cowork da contexto rico, permisos limitados. Code da contexto rico y permisos amplios. Ese es el split.
qué cambia al pasar de chat a asistente
cada conversación arranca limpia. cada vez le explicas: · qué stack usas · qué convenciones tienes · qué archivos importan · qué decisiones ya tomaste el costo es la repetición.
el project guarda: · system instructions · archivos relevantes · sesiones previas cada conversación nueva ya sabe quién eres y dónde estás trabajando.
qué cambia al pasar de asistente a agente
Un asistente puede decir "deberías editar este archivo así". Un agente lo edita. Esa diferencia parece sutil. No lo es.
Cuando el modelo puede actuar, las preguntas correctas dejan de ser sobre código y pasan a ser sobre gobernanza: qué permisos, qué auditoría, qué reversibilidad.
Lo que necesitas tener listo antes de los ejercicios. No instalamos Claude Code todavía — eso es para la sesión B. Aquí solo Cowork.
paso 01 · cuenta
El acceso es por claude.ai. Login con Google o email corporativo. La cuenta corporativa de Credicorp da acceso a Cowork, Code y a la API.
Si tu cuenta no tiene plan, abre un ticket con el lead técnico antes de los ejercicios. Sin cuenta activa, Cowork bloquea las funciones de project.
matriz de decisión
| tarea | chat web | cowork | code |
|---|---|---|---|
| pregunta puntual | ✓ | — | — |
| explorar un repo nuevo | — | ✓ | ✓ |
| redactar documento técnico | — | ✓ | — |
| refactor real con archivos | — | — | ✓ |
| audit conversacional | — | ✓ | parcial |
| correr tests / build | — | — | ✓ |
| generar Memory Pack | — | ✓ | ✓ |
| commit / push / PR | — | — | ✓ |
qué traer a esta sesión
primer login
Tres clicks separan el chat puro del modo asistente. La diferencia operativa la vas a sentir desde el primer ejercicio.
El asistente que conserva contexto. La interfaz de claude.ai cuando trabajas con projects, archivos y sesiones reutilizables. Hasta aquí la teoría — desde aquí, cómo opera.
definición operativa
No es una app distinta. Es claude.ai en modo "project". Lo que lo hace distinto del chat puro es que cada conversación arranca con un contexto que tú diseñaste — instrucciones + archivos — en lugar de partir de cero.
Lo que escribes ahora. Cada turno tiene uno.
Carpeta de contexto persistente: instrucciones + knowledge.
Conversación dentro del project. Tienes muchas. Se guardan.
anatomía de Cowork
Texto que define rol, dominio, restricciones, formato de respuesta. Se carga en cada turno.
Archivos persistentes del project. Indexados — el modelo cita y referencia.
Hilo de conversación. Tiene historial. Se puede retomar.
El turno actual. Único elemento que cambia en cada interacción.
el project como unidad de trabajo
Mal patrón: un project gigante con todo. Buen patrón: un project por capacidad concreta — "audit de arquitectura", "redacción de ADRs", "revisión de PRs", "research de librerías".
Cuando el project tiene foco, las instrucciones son específicas y el contexto es relevante. Eso eleva la calidad de cada respuesta sin tocar el modelo.
system instructions del project
Eres un asistente útil para mi equipo de ingeniería. Ayúdame con código.
Sin foco, sin restricciones. Respuestas genéricas, formato impredecible.
Rol: arquitecto senior · banca digital Stack: TypeScript · Hexagonal · Postgres Audiencia: tech leads · CTO Restricciones: · Citar archivo:línea cuando referencias · Marcar [supuesto] cualquier inferencia · Antes de proponer, lista 3 opciones · Idioma de respuesta: español Formato: bullets · no narrativa larga
qué subir como knowledge
cómo trabajar con sesiones
Sesiones largas con muchos cambios de tema confunden al modelo. La señal se diluye. Mejor: una sesión por objetivo claro, cierre con resumen, abre nueva.
// cuatro sesiones · cuatro objetivos · mismo project
cómo Cowork ensambla el contexto
Cuando algo "no se entiende", el problema casi siempre está en uno de los primeros tres bloques. El prompt actual es lo último que falla.
la ventana de contexto
El modelo lee miles de tokens — pero no infinitos. Cuando llenas el project con todo el repo, lo importante compite con lo decorativo. La curaduría de knowledge files es trabajo de arquitecto, no de junior.
tokens de ventana en Claude Sonnet 4.6
útiles tras descontar instructions, knowledge y historial
// 1M tokens en modo extendido (cuando aplica)
buenas prácticas · prompt
Las formas en que Cowork compone con tu trabajo. Cada patrón es una manera de operar que cambia el rol del asistente — explorador, redactor, comparador, extractor, decisor.
patrón 01 · exploración
Cargas el knowledge con README, architecture.md y los entry points. Le pides al asistente que dibuje el mapa: qué hay, dónde, cómo se conecta. Útil cuando entras a un repo nuevo o cuando regresas a uno que no tocas en meses.
patrón 02 · reescritura iterativa
"propón estructura · 3 opciones · sin texto"
"redacta el borrador con la opción 02 · sin pulir prosa"
"pulé la prosa · mantén estructura · idioma técnico ejecutivo"
Pedir todo de una vez produce un draft mediano. Iterar produce un documento publicable.
patrón 03 · análisis comparativo
Cuando hay 2-4 opciones reales (librería, patrón, topología, plan de migración), Cowork brilla forzando una matriz comparativa explícita. La clave: tú defines las dimensiones, el modelo llena las celdas.
Compara <A> vs <B> vs <C> en estas dimensiones: · esfuerzo de adopción · acoplamiento con stack actual · riesgo operativo · costo a 12 meses · equipo necesario Tabla. Una recomendación al final con un único criterio decisor.
patrón 04 · extracción / síntesis
PDFs de RFC, transcripciones de reuniones, decks de proveedor, threads de Slack — material crudo. Le pides al modelo que lo convierta en un artefacto estructurado: tabla, ADR, glosario, checklist.
PDF de RFC de proveedor de pagos · 40 páginas
"extrae los 5 contratos de servicio. Tabla. Métricas, penalidades, escalabilidad."
Tabla de 5 filas · 4 columnas · lista para revisar con legal
A partir de aquí, todo es práctica. Cada ejercicio tiene un objetivo verificable y un artefacto de salida que vas a usar después en el workshop principal. Cowork abierto, project listo, knowledge cargado.
ejercicio 01 · primer prompt útil
Probar la diferencia entre chat puro y un project con system instructions. Mismo prompt, dos veces. Comparar.
Eres mi compañero técnico. Necesito elegir entre Postgres y MySQL para una base de datos OLTP de transacciones bancarias. Dame las 3 dimensiones que debería evaluar primero, en orden de prioridad, con una sola línea de justificación por cada una. No me digas la respuesta. Dame el marco.
ejercicio 02 · subir archivo y conversar
Confirmar que el modelo realmente leyó tu archivo. Forzar respuestas con citaciones a archivo:línea. Detectar cuándo inventa.
Lee el archivo adjunto. Devuelve: 1. Una línea: qué hace este archivo 2. Tres funciones más importantes formato: nombre · línea · qué hace 3. Tres dependencias externas formato: import · línea · uso Si no puedes citar línea, di "sin evidencia". No inventes.
ejercicio 03 · project con instrucciones contractuales
Construir un project "Architecture Audit · <tu sistema>" listo para que cualquier persona del equipo pueda hacer auditorías contra él.
Rol: arquitecto senior · banca digital Stack: <tu stack real> Audiencia: tech leads del equipo Restricciones: · Citar archivo:línea siempre · Marcar [supuesto] toda inferencia · Antes de proponer, listar 3 opciones · Idioma: español Formato: markdown · bullets · sin narrativa larga · máximo 600 palabras
ejercicio 04 · análisis de un PR sin clonarlo
Tomar el diff de un PR de la última semana del equipo. Pedir a Cowork un review estructurado contra los criterios del project (boundaries, naming, complejidad).
Diff adjunto. Devuelve un review en cuatro ejes: 1. Boundaries · ¿algún import cruza capas que no debería? 2. Complejidad · ¿alguna función con ciclomática > 10? 3. Tests · ¿cobertura de comportamiento o solo de implementación? 4. Naming · ¿términos del glosario o inventados? Severidad por hallazgo. Cita archivo:línea.
ejercicio 05 · comparativa de enfoques
Forzar una decisión estructurada sobre 3 alternativas reales. La salida es una matriz comparativa con recomendación argumentada.
Compara <lib A> vs <lib B> vs <lib C> para <problema> en este stack. Dimensiones (en orden de prioridad): 1. Acoplamiento con tu stack actual 2. Costo de adopción a 4 semanas 3. Riesgo operativo 4. Comunidad y mantenimiento 5. Costo a 12 meses Tabla. Una recomendación. Criterio decisor: "menor riesgo operativo".
ejercicio 06 · audit conversacional de un módulo
Detectar boundaries violados, complejidad excesiva y deuda técnica sin abrir el editor. Salida: lista priorizada de remediación.
Audita el módulo <nombre> (archivos adjuntos). Reporte en este orden: 1. Estructura · capas detectadas, ¿claras? 2. Complejidad · funciones con ciclomática alta o cuerpo > 50 líneas 3. Acoplamiento · imports sospechosos o side-effects no documentados Por hallazgo: ruta:línea · severidad · remediación mínima viable. Ordena por severidad descendente.
ejercicio 07 · memory pack mini para una feature
Practicar la generación de un Architecture Memory Pack reducido — el ejercicio principal del workshop. Aquí solo para una feature, como precalentamiento.
Genera 3 documentos solo para esta feature (archivos adjuntos): 1. architecture.md · módulos internos y comunicación. Marca [?] si dudas. 2. boundaries.md · qué importa de qué. Marca acoplamientos sospechosos. 3. domain-glossary.md · términos del dominio. Conteo y ubicaciones. No inventes. "Sin evidencia" si falta. Output: markdown. Listos para pegar en /ai-system/architecture/<feature>/.
ejercicio 08 · extracción de glosario de dominio
Producir un glosario inicial que sirva de base para alineación con el equipo de negocio. Detectar dónde el código y el negocio hablan idiomas distintos.
Extrae los 30 términos de dominio más
frecuentes en los archivos adjuntos.
Por cada término:
· forma canónica
· aliases detectados
(Cliente / User / Account)
· ubicaciones representativas
· clasificación: estado · evento ·
agregado · valor
Marca con [normalizar] los términos
con > 1 alias. No renombres aún.
Output: tabla markdown.
Reconocer los límites de Cowork es prerrequisito para usarlo bien. Forzarlo donde no encaja produce código que parece correcto, plan que parece sólido y respuestas que parecen útiles — pero no lo son.
limitación 01
El asistente devuelve diff o snippet. Tú lo aplicas. Para cambios reales sobre archivos múltiples, mover lógica entre módulos, correr tests entre intentos — necesitas un agente que opere el sistema de archivos. Eso es Code, no Cowork.
limitación 02
No tiene shell, no tiene runtime, no tiene acceso a tu sistema. Cuando la tarea requiere ejecutar algo — npm install, vitest, docker, dependency-cruiser — Cowork puede sugerir, pero no ejecuta. Code sí.
decisor rápido
| tarea | cowork | code |
|---|---|---|
| redactar ADR | ✓ ideal | posible · innecesario |
| audit conversacional | ✓ ideal | parcial |
| comparar 3 librerías | ✓ ideal | posible |
| refactor real entre módulos | insuficiente | ✓ ideal |
| correr tests · build · linters | no | ✓ ideal |
| aplicar cambios al repo | no | ✓ ideal |
| auditoría con dependency-cruiser | no | ✓ ideal |
cuando Cowork no alcanza · llega Code
En la sesión B vas a operar Claude Code: el agente con permisos sobre tu repo. Ejecuta comandos, edita archivos, corre tests, abre PRs.
Lo que aprendiste aquí — prompts contractuales, projects, knowledge, ventana de contexto — se aplica igual. Lo que cambia es el set de capacidades.
Cinco minutos de retrospectiva. Tres entregables que llevarse. Un check antes de pasar a la sesión B.
qué llevarse
Tu primer project con system instructions contractuales. Listo para reusar.
Architecture · boundaries · glossary acotados a un feature. Listo para escalar al repo entero en el workshop.
Sabes pedir formato, restricciones, límites. Sin esto el workshop no compone.
antes de la sesión B
El asistente que conserva contexto cambia cómo piensas.Pre-workshop · Sesión A · Cowork
El agente que opera con permisos cambia qué entregas.
Esta sesión te dio el primero. La sesión B te da el segundo.
acciones inmediatas
Pasa el project "Sandbox · workshop" a tu equipo. Verifica que dos colegas pueden abrirlo y obtienen resultado equivalente.
Commitea los 3 documentos en una rama workshop/memory-pack-feature. Aún sin merge — solo guardado.
Verifica los 5 pre-requisitos de la slide 46. Si algo falla, escribe al lead técnico antes de la sesión.
En la sesión B nos vemos con Claude Code abierto. La continuidad es directa: los mismos prompts contractuales, ahora con permisos sobre el repo.