Al terminar este módulo, vas a operar como profesional: el ciclo de élite, el hábito de la evidencia y tu checklist personal.
Hoy no aprendes nada nuevo. Ya tienes todas las piezas: la mesa, la constitución, los puestos, las recetas, los reflejos, tu equipo de empleados, los candados y la correa. Lo que falta no es una herramienta más — es ordenar lo que ya sabes en un solo modo de trabajar. Este módulo es la cosecha.
Y hay una sola idea que amarra todo el manual. La guía oficial de mejores prácticas de Anthropic la dice en una línea: "Claude's context window fills up fast, and performance degrades as it fills" — la mesa se llena rápido, y entre más llena, peor trabaja. ¿Te acuerdas de la mesa del módulo 2? Casi todas las prácticas de los profesionales — las oficiales y las que la comunidad descubrió a golpes — son maneras distintas de cuidar esa mesa y de no creerle nada sin comprobarlo. De eso se trata ser pro.
La guía oficial lo llama Explore → Plan → Implement → Commit. La casa le agrega el paso que separa a los que entregan de los que prometen: verificar antes de guardar la foto. Cinco pasos, todos los conoces ya — aquí solo se forman en fila:
1. Explorar. Antes de pedir, deja que Claude LEA. Que te diga qué hay en la carpeta, cómo están los datos, qué encontró — tú no dictas a ciegas y él no inventa. Dos afinaciones de pro: si la investigación es larga, despáchala a un subagente — ¿te acuerdas? — otro empleado con su mesa limpia que te regresa el resumen, no su desorden (módulo 9). Y ponle límite al paseo: "explora SOLO la carpeta de facturas" — la exploración sin frontera es uno de los cinco patrones de falla con nombre de la guía oficial (infinite exploration: investigar sin alcance hasta llenar la mesa).
2. Planear. Para encargos gordos: plan mode (módulo 4), y no aceptes el primer plan por cortesía — corrígelo, recórtalo, hazlo tuyo. Boris Cherny, el creador de Claude Code, lo cuantifica así: ir y venir sobre el plan antes de ejecutar "easily 2-3x's results for harder tasks" — fácilmente duplica o triplica el resultado en tareas difíciles. Y la jugada fina para proyectos grandes: pídele que ÉL te entreviste ("hazme las preguntas que necesites antes de proponer el plan") y que aterrice lo acordado en un archivo de especificación — Claude hace las preguntas técnicas, tú solo contestas de tu negocio.
El matiz oficial que nadie cuenta: el plan es para lo incierto y lo grande. Textual de la guía: "If you could describe the diff in one sentence, skip the plan" — si puedes describir el cambio en una frase, sáltate el plan. Corregir un teléfono en un documento no amerita junta de consejo.
3. Ejecutar. Una tarea a la vez, en pedazos chicos — la comunidad tiene una regla de dedo: nunca pidas de un jalón más de lo que a una persona le tomaría media hora hacer. Sé incómodamente explícito ("be uncomfortably explicit", dice un usuario veterano): contexto + objetivo + cómo se ve "quedó bien". Y alimenta con material rico: señala archivos con @, pega screenshots, pega el error completo — dirigir bien es dar buenos insumos.
4. Verificar. El paso que este manual te viene sembrando desde el módulo 4 y que aquí se corona (la sección 13.2 es toda para él). El punto #1 de la guía oficial de mejores prácticas es exactamente este: dale a Claude una forma de comprobar su propio trabajo, y pídele la comprobación, no el "ya quedó". Boris Cherny otra vez: darle verificación es "another 2-3x" — otro salto de dos a tres veces en la calidad. El mismo consejo, dos veces, del creador del producto: planear y verificar son donde se gana el partido.
5. Foto. Cierras guardando: checkpoint o commit con etiqueta (tu máquina del tiempo del módulo 4). La comunidad lo repite en todos los tonos: commits frecuentes en cada hito son tu red real — si la siguiente chamba sale mal, regresas a la última foto buena en vez de llorar sobre archivos rotos.
Síntoma: "Ese ciclo es mucha ceremonia — yo nada más quiero cambiar una palabra en un documento."
Causa: aplicar el protocolo completo a chambas de una frase. El ciclo es para lo gordo, no para el mandado.
Salida: usa el matiz oficial: si puedes describir el cambio en UNA frase, pídelo directo y verifica el resultado — dos pasos, no cinco. El ciclo completo se reserva para lo que toca muchos archivos, lo que no sabes cómo se hace, o lo que duele si sale mal.
Los foros están llenos de la misma queja, con las mismas palabras: "code contains bugs despite confident claims of correctness" — Claude afirma con toda seguridad que quedó, y no quedó. La guía oficial le puso nombre al hoyo: trust-then-verify gap — el resultado se ve plausible, tú confías, y el detalle roto aparece una semana después. Y remata con la regla que deberías tatuarte: "If you can't verify it, don't ship it" — si no lo puedes verificar, no lo entregues.
Pedir evidencia, no promesas. Lo vienes haciendo desde el módulo 4 sin ponerle nombre; hoy se vuelve tu hábito de jefe. A un empleado nuevo no le aceptas "ya quedó, jefe" — le dices "enséñamelo": ábreme el archivo, corre el reporte, muéstrame la pantalla. Con Claude es igual, con la ventaja de que enseñarte la evidencia le cuesta tres segundos y cero orgullo.
Frases listas para tu repertorio — cópialas tal cual:
La última frase tiene historia en la casa. La constitución de SmartProcess obliga al agente a etiquetar cada afirmación en una de tres: verificado (lo probé), inferido (se deduce de X) o hipótesis (suena bien, sin evidencia aún) — y "jamás te vendo la tercera como la primera". No necesitas implementar el sistema completo: necesitas la pregunta. Cuando Claude te afirme algo que importa, pregúntale de cuál de las tres es. La respuesta honesta te dice cuánto pesa la afirmación — y pedirla te convierte en el tipo de jefe al que no se le cuelan promesas disfrazadas de hechos.
Si no lo puedes verificar, no lo entregues. Antes de dar una chamba por cerrada — tuya o de Claude — responde: ¿QUÉ evidencia tengo de que quedó? Si la respuesta es "me dijo que sí", no tienes evidencia: tienes una promesa.
Síntoma: "Le pido evidencia y me suelta un párrafo explicando por qué SÍ debería funcionar."
Causa: pediste comprobación y te dio argumento. Explicar no es verificar.
Salida: exige el acto, no el razonamiento: "no me expliques por qué funciona — CÓRRELO y pégame lo que salga, tal cual". Si el resultado corrido no existe o da error, acabas de ahorrarte descubrirlo el viernes a las 6.
Si esto te suena a chino, bríncatelo: no lo necesitas para seguir. La guía oficial describe el patrón Writer/Reviewer: una sesión escribe el trabajo y OTRA sesión —con mesa limpia, sin el cariño del que lo hizo— lo revisa como auditor externo. Es el Perito de la casa en versión de a pie: abres una segunda sesión (o despachas un subagente revisor) con el encargo "revisa esto buscando qué está mal, no qué está bien". Para volumen, la misma guía documenta correr claude -p en modo headless sobre listas de archivos con herramientas restringidas (--allowedTools) — el módulo 12 te dio esas llaves.
¿Te acuerdas de la pregunta de los foros: "¿por qué se pone tonto después de horas?"? Ya sabes la respuesta: la mesa. La economía del pro empieza ahí:
/clear (la anterior no se borra: vive en /resume)./clear, y arranca con un prompt nuevo que YA incluye lo que aprendiste de los dos fracasos.Y el cierre del par que te acompaña desde el módulo 1: la renta y el taxímetro. La pregunta del pro no es "¿cuánto cuesta Claude?" — eso ya lo decidiste al elegir plan (módulo 3). Es "¿cuánto vale ESTA chamba?": antes de arrancar algo gordo, ponle presupuesto de tiempo y de consumo ("esto vale 40 minutos y una sesión"), y al cerrar, /cost te dice si saliste tablas. Con renta el límite es tu cuota de uso; con taxímetro son pesos — en ambos, la disciplina es la misma: chamba con presupuesto no se desborda.
Cuándo NO usar Claude Code. En el módulo 0 te prometí esta lista completa; con todo el manual encima, ya la puedes leer como operador y no como acto de fe:
Un dato honesto para calibrar expectativas: usuarios veteranos reportan que SIN estructura — sin constitución, sin ciclo, sin verificación — la tasa de éxito ronda el 50%, y la mitad mala cuesta más limpiarla que hacer el trabajo a mano. Con estructura, la historia cambia por completo. La estructura es todo lo que este manual te dio.
Detrás de casi toda queja de principiante en los foros viven tres preguntas: "¿por qué se pone tonto?" (mesa llena), "¿por qué rompió lo que ya jalaba?" (sin fotos) y "¿por qué dice que quedó y no jala?" (sin verificación). Estos son los diez errores concretos, cosechados de las listas de la comunidad y de los patrones de falla oficiales — con su síntoma, su antídoto y el módulo donde ya lo curaste:
/clear entre chambas que no se tocan; decisiones importantes a un archivo antes de limpiar. (M2 y M4.)Si reconociste tres o más tuyos: felicidades por la honestidad — ahora ya saben dónde vive su cura.
Media página. Imprímela, pégala junto al monitor — o mejor: pídele a Claude que te la deje en checklist-pro.md con tus ajustes. Es la cosecha del manual entero en formato de casilla:
Antes de arrancar la chamba
Al pedir
Durante
@archivo, screenshots, el error completo/clear y prompt nuevo con lo aprendidoAl cerrar
/cost: ¿saliste dentro de tu presupuesto?Y un último dato para que no camines solo: el directorio comunitario más grande de recursos de Claude Code (awesome-claude-code) rebasa las 49 mil estrellas en GitHub. Ser usuario pro también es esto: saber que hay una comunidad enorme puliendo las mismas mañas que tú.
El no-negociable #3 de la constitución de la casa, textual: "No declaro éxito sin probar. No le digo que algo jala hasta probarlo de verdad. Si falló, se lo digo con el output crudo." No es un consejo del agente hacia el humano — es una LEY que el humano le impuso al agente por escrito, después de aprenderla a la mala. Y el mismo principio a escala de proyecto se llama la Brújula: en la agencia, ningún proyecto serio nace sin sus 6 documentos de plan — el "planear antes de construir" del ciclo de élite, institucionalizado. Todo lo que este módulo te enseñó como hábito personal, en SmartProcess está escrito como regla de operación.
Qué vas a lograr: una chamba real tuya, de punta a punta, con el ciclo completo y presupuesto — la prueba de que ya no eres turista. Nadie te la califica: la evidencia habla sola.
Qué necesitas: tu organigrama del módulo 0 (aquel papel con tus 5 tareas repetitivas) y una carpeta de trabajo con máquina del tiempo activa (M4). Sin seeds: hoy es TU chamba de verdad.
Pasos:
/clear) parado en la carpeta correcta. Antes de pedir nada: "lee esta carpeta y dime qué hay, qué está incompleto y qué te llama la atención — no cambies nada todavía".@archivo y material concreto, no de memoria.Teclea (o pega) esto (dentro de Claude Code):
/costVas a ver algo así (cuenta de API — cita oficial):
Total cost: $0.55
Total duration (API): 6m 19.7so así (con suscripción Pro/Max/Team):
Session ████████░░░░░░ 52% used · resets 6:00pm
Weekly ███░░░░░░░░░░░ 23% usedQué significa: el consumo de ESTA sesión — el formato exacto varía según tu plan. Con API, es un costo real en dólares. Con suscripción (Pro/Max/Team), la documentación oficial es tajante: "el número de costo de sesión no es relevante para tu facturación" — ya pagaste tu renta; lo que ves son barras de tu plan, no un cobro. Lo que importa hoy no es el número: es compararlo contra el presupuesto que TÚ escribiste en el paso 1.
Si en vez de eso ves que no reconoce el comando: estás en la terminal normal, no dentro de Claude Code — abre claude primero; /cost (o su nombre moderno, /usage) vive adentro.
¿LO LOGRASTE?
/cost final quedó dentro del presupuesto que te pusiste — y si no, sabes exactamente en qué paso se fue.Si marcaste las tres: eso era el examen. No hubo calificación porque los pros no coleccionan diplomas — coleccionan chambas entregadas con evidencia.
verificación / evidencia — pedir el resultado corrido (el archivo, el comando con su output, el número comparado), no la promesa de que quedó.
ciclo de élite (explorar→planear→ejecutar→verificar→foto) — el orden de trabajo de los profesionales con agentes; el plan se salta solo cuando el cambio cabe en una frase.
La demo de 5 minutos: el engaño en vivo. Pídele a Claude una chamba con truco (un resumen de datos con un error sembrado por ti), deja que declare éxito, y pregúntale al grupo: "¿le creemos?". Luego pide la evidencia frente a todos y deja que el error aparezca solo. Nadie que vea ESO vuelve a aceptar un "ya quedó" a secas.
El error que el alumno VA a cometer: en el examen sin examen, saltarse el paso 5 e irse directo a la foto — porque el resultado "se ve bien". Déjalo pasar y pídele en frío: "¿qué evidencia tienes?". El silencio incómodo enseña más que tu slide.
La pregunta de arranque: "De las últimas 10 cosas que Claude (o cualquier persona) te dijo que ya estaban listas… ¿cuántas comprobaste? — hoy salimos siendo del otro tipo de jefe."
Verificado contra documentación oficial el 2026-07-12.