Buscar una lección

173 leccións.

Chat, Cowork, Claude Code, tres herramientas, tres usosElegir la puerta de entrada adecuada
El chat responde, Cowork actúa sobre tus archivos y Claude Code trabaja con código: tres interfaces para la misma familia de modelos. Lo que las distingue son las herramientas que el modelo puede llamar y el contexto que tú le aportas. El trabajo de código va hacia Claude Code, el de conocimiento hacia Cowork.
Cowork, el modo por defecto para un perfil no técnicoElegir la puerta de entrada adecuada
En una cuenta que aún no ha pasado a la nueva experiencia unificada, Cowork actúa directamente sobre las carpetas conectadas y se divide en pasadas pequeñas en lugar de un único proceso gigante; una vez que pasa, esos mismos gestos se hacen desde la misma conversación que el chat, con un solo ajuste de aprobación para toda la conversación.
Configurar el ordenador para las sesiones largasElegir la puerta de entrada adecuada
Para una tarea larga que toque tus archivos locales, impide la puesta en reposo automática de tu ordenador y activa las notificaciones de la aplicación Claude. Claude Desktop debe entonces permanecer abierta, despierta y conectada: si el ordenador entra en reposo, la tarea se interrumpe sin más señal que el resultado ausente. Una tarea planificada enteramente remota no lo necesita.
Chat y Cowork ya son una sola conversaciónElegir la puerta de entrada adecuada
Desde la fusión del chat y de Cowork en una sola conversación, ya no eliges una herramienta antes de escribir: Claude decide por sí mismo si responde o si actúa, y un solo ajuste, Auto o Manual, sustituye a las antiguas elecciones propias de cada herramienta.
Entender el token y la ventana de contextoNo quedarse nunca sin tokens
Claude lee tokens, pequeños fragmentos de texto, y la ventana de contexto es el espacio donde cabe todo lo que puede ver a la vez: tu mensaje, el historial y los archivos adjuntos. Reabrir una sesión antigua recarga todo ese historial en cada pregunta, incluso corta, lo que la vuelve más lenta y más costosa en cuota.
Qué hacer cuando se alcanza el límiteNo quedarse nunca sin tokens
Cuando se alcanza el límite, enviar nuevos mensajes es imposible hasta que algo lo desbloquea: esperar el reinicio del contador, cambiar de plan o comprar créditos de uso. Solo esperar es gratis, y la única preparación útil es saber de antemano a quién dirigirse en tu organización.
Los buenos reflejos para ahorrarNo quedarse nunca sin tokens
Para ahorrar cuota, si la tarea no tiene relación con la anterior, abre una sesión nueva vinculada al mismo proyecto en lugar de prolongar una sesión de un día para otro. La sesión prolongada relee todo su historial en cada pregunta, mientras que la nueva parte de una base corta y encuentra los archivos y la instrucción del proyecto.
El proyecto, contenedor del contextoMantener el hilo de un día a otro
Un proyecto reúne en un solo lugar permanente archivos de referencia, una instrucción escrita una sola vez y las sesiones abiertas dentro de él. Una conversación abierta fuera de todo proyecto no conserva ninguno de estos tres elementos más allá de su propia ventana: cerrarla equivale a vaciarla. Una tarea que vuelve con los mismos archivos pertenece a un proyecto.
Activar la memoria, distinta del historialMantener el hilo de un día a otro
La memoria no es el historial: el historial conserva cada conversación tal como se desarrolló, mientras que la memoria retiene solo una selección y la reutiliza en una sesión siguiente. Está activa por defecto en las cuentas personales e inactiva en las de organización, donde conviene comprobar primero que esté encendida.
Retomar una sesión sin volver a perderlo todoMantener el hilo de un día a otro
Abre una sesión nueva dentro del mismo proyecto y pídele explícitamente que retome el hilo. Los archivos y la instrucción del proyecto siguen en su sitio, pero el detalle de la conversación anterior no se transmite: lo que no está escrito en ningún sitio del proyecto no volverá, salvo que se lo entregues de nuevo.
Lo que Cowork ve y lo que no veHacer que Claude trabaje en tus archivos reales
Cowork solo modifica archivos en las carpetas que has conectado, pero ve más que archivos: con tu autorización toma capturas de tu pantalla, y desde el panel lateral de Chrome ve la página mostrada. Cierra u oculta lo que no tenga que ver con la tarea.
Trabajar sobre una copia, nunca sobre el originalHacer que Claude trabaje en tus archivos reales
Trabaja sobre una copia, porque Claude modifica el archivo mismo, en el lugar donde se encuentra, y no crea ninguna copia de seguridad. Una reescritura no pide la confirmación de una eliminación, así que el error silencioso se vuelve más probable. Duplica todo documento que deba seguir siendo una referencia antes de confiárselo a Claude.
Competencias y plugins, la especialización a demandaHacer que Claude trabaje en tus archivos reales
Una competencia es una especialización que Claude carga para un dominio preciso o una forma de hacer repetida, escrita una sola vez. Un plugin agrupa varias competencias en un solo paquete instalable. Lee la descripción antes de activar cualquiera de los dos: es el único lugar donde su autor dice lo que hace.
Los conectores, un enlace directo con un softwareHacer que Claude trabaje en tus archivos reales
Un conector es un enlace autenticado entre Claude y un servicio externo, como una mensajería, una agenda o un espacio de archivos. Autorizarlo compromete más allá de la conversación en curso, hasta en tus tareas planificadas, y en una cuenta de organización es un administrador quien fija la lista de conectores propuestos.
Lo que exige una prudencia particular antes de hacer tratar un documentoDatos personales, la prudencia obligatoria
La identidad, la salud, la situación personal y los secretos de acceso exigen una prudencia particular antes de hacer tratar un documento. Reemplazar un nombre por un número no basta mientras exista en algún lugar una tabla de correspondencia. Un secreto que transita por una conversación, aunque sea brevemente, debe considerarse ya comprometido.
Lo que garantiza la cuenta de organización, y lo que no garantizaDatos personales, la prudencia obligatoria
En una cuenta de organización, el contenido de las conversaciones no se usa para entrenar los modelos, salvo que la propia organización se adhiera al programa de asociación de desarrollo. Esta garantía responde solo a la cuestión del entrenamiento: la organización sigue siendo la única responsable del tratamiento, y una cuenta individual sigue otras condiciones.
Tratar un primer caso real de principio a finPasar a la práctica y orientarse solo
Trata un caso real en tu proyecto, en pasadas pequeñas, y da el entregable por bueno solo cuando lo hayas releído tú mismo. El anuncio de fin de tarea y una presentación limpia no prueban nada: cuenta los elementos, compáralos con la fuente y encuentra cada valor numérico en el documento de origen.
El glosario de referenciaPasar a la práctica y orientarse solo
Este glosario reúne las palabras que aparecen sin cesar en el recorrido: agente, token, ventana de contexto, proyecto, habilidad, plugin, conector, tarea programada, encargado del tratamiento. Bastan para formular una petición y describir un bloqueo a otra persona. Mantén la ficha abierta durante tu primera semana en lugar de memorizarla de golpe.
Predecir la palabra siguiente, nada másQué es un modelo de lenguaje, sin jerga
Un modelo de lenguaje solo hace una cosa: predecir el fragmento de texto más probable a continuación de lo que ya ha leído, y una respuesta inventada sale del mismo cálculo que una respuesta exacta, sin que ninguna señal interna las distinga la una de la otra.
El token y la ventana, lo que el modelo ve realmenteQué es un modelo de lenguaje, sin jerga
El modelo ve tokens apilados en una ventana con un techo fijo, no palabras enteras tomadas una por una, y una conversación que se acerca a ese techo cambia de contenido incluso antes de alcanzar su coste máximo, ya que Claude entonces resume los intercambios más antiguos.
El mito del ajuste mágicoQué es un modelo de lenguaje, sin jerga
Dos respuestas diferentes a la misma pregunta no indican una avería: vienen de un ajuste interno, la temperatura, que regula el nivel de riesgo en la elección de la palabra siguiente, y ese ajuste no corrige una petición mal planteada, la petición misma sí puede hacerlo.
Una familia de modelos, una elección entre velocidad y profundidadQué es un modelo de lenguaje, sin jerga
Los modelos de Claude, Fable, Opus, Sonnet y Haiku, salen del mismo entrenamiento base y se diferencian sobre todo por un equilibrio: la velocidad de la respuesta frente a la profundidad del razonamiento. Los rápidos sirven para tareas cortas y repetidas, los profundos para expedientes que contrastar, y la tarifa sigue el mismo eje.
El sentido sin diccionario, y por qué el orden importaQué es un modelo de lenguaje, sin jerga
Claude no abre ningún diccionario, asocia cada palabra a palabras de sentido cercano y evalúa cada una en relación con todas las demás en el momento de responder, lo que hace que el lugar de una instrucción dentro del mensaje cambie su peso real en la respuesta.
Cómo aprendió Claude a responder, y hasta cuándoQué es un modelo de lenguaje, sin jerga
Claude atraviesa tres etapas de entrenamiento antes de cualquier conversación, una lectura amplia del mundo, un ajuste para convertirse en un asistente útil, y después una autocorrección basada en principios escritos, y el conocimiento que resulta de ello se detiene en una fecha que varía según el modelo utilizado.
Los tres bloques de una peticiónEscribir una petición que funciona
Una petición que funciona separa tres bloques: lo que Claude debe ser, lo que ya se ha dicho y lo que se pide ahora. Para un comportamiento que vaya más allá del mínimo, pídelo explícitamente en lugar de contar con que el modelo lo adivine. Con un proyecto, el rol se plantea una vez, en sus instrucciones.
Ser claro, directo, y dar el porquéEscribir una petición que funciona
Claude se comporta como un empleado nuevo y brillante que no conoce ni tus hábitos ni tu sector: sé preciso y da el porqué, no solo la tarea. Nombra también a quien leerá o escuchará la respuesta. Para comprobar la claridad, muestra tu petición a un colega sin contexto: si se pierde, Claude también se perderá.
Asignar un rolEscribir una petición que funciona
Una sola frase de rol, colocada al comienzo de una conversación o de un proyecto, orienta el tono, el vocabulario y las prioridades de Claude con más eficacia que una larga lista de consignas dispersas. Un rol útil nombra una especialidad, un público y al menos una restricción de forma, no un título demasiado general.
Separar los datos de las instruccionesEscribir una petición que funciona
Mezclar instrucciones y datos en un solo bloque obliga a Claude a adivinar dónde termina la consigna: una frase del texto pegado puede pasar por una instrucción. Rodea cada tipo de contenido con una frontera explícita, etiqueta, título Markdown o línea de marcado, y comprueba que cada etiqueta abierta encuentra su cierre.
Formatear la salida y hablar en lugar de ClaudeEscribir una petición que funciona
Precisa el formato diciendo lo que la respuesta debe contener en lugar de lo que no debe contener. Para que empiece por el resultado, nombra el primer elemento esperado: esto sustituye al antiguo prellenado, que consistía en escribir uno mismo el comienzo de la respuesta de Claude y ya no funciona en los modelos Claude recientes.
Hacer que Claude razone antes de concluirEscribir una petición que funciona
Pedirle a Claude que escriba su razonamiento antes de su conclusión mejora la precisión en las preguntas de varias etapas, tanto si ese razonamiento se invita mediante una frase en la petición como si ya está activo como un modo aparte, y ambas versiones consumen tokens adicionales.
Mostrar el objetivo en lugar de prohibirloEscribir una petición que funciona
Tres a cinco ejemplos entrada hacia salida anclan un formato o un tono mejor que una larga lista de reglas, y una instrucción positiva da un objetivo claro allí donde una instrucción únicamente negativa deja a Claude adivinar por qué reemplazarla.
Componer una petición compleja sin inventarEscribir una petición que funciona
Una petición compleja se compone pieza por pieza, quién debe ser Claude, el contexto, el dato a tratar, lo que se pide, un ejemplo, el formato esperado, y luego una última línea que autoriza a Claude a decir no lo sé en lugar de inventar una respuesta.
Hacer durar y reutilizar una petición que funcionaEscribir una petición que funciona
Conserva una petición que funciona y ajústala con pequeños toques, una sola parte cada vez, en lugar de reescribirla de cero. Coloca un documento largo al principio de la petición, antes de la pregunta. Luego fija la petición en una plantilla reutilizable donde solo se reemplaza lo que cambia de una tarea a otra.
Un verde no prueba nada hasta que no ha sido probado el mismoVerificar lo que devuelve
Un control que nunca ha sido puesto en jaque por un caso que debe encontrar no ha probado nada: probar exige que un comando concreto se haya ejecutado y que su salida haya sido leída, y un detector roto da cero problemas, lo que se lee exactamente como un éxito.
Prueba el verificador antes de creer su veredictoVerificar lo que devuelve
Un control que da una cifra plausible no siempre da una correcta, y la diferencia casi nunca se anuncia. Prueba el script antes de creer su veredicto: dale una entrada fabricada que debe señalar y una entrada limpia que no debe señalar, que cubran las particularidades reales de tu terreno.
El remedio contra la invención también puede inventarVerificar lo que devuelve
Un dispositivo de verificación es un entregable como cualquier otro, producido por el mismo tipo de mecanismo que lo que controla. Repetir el mismo control no lo hace independiente, porque un bug determinista se repite idéntico: solo un método realmente distinto, que pueda fallar de otra manera, vale como prueba.
Dónde miras determina lo que encuentrasVerificar lo que devuelve
Una verificación centrada en el último cambio dice dónde se ha mirado, nunca dónde están realmente los defectos: sin haber examinado el resto con el mismo cuidado, ninguna conclusión sobre la peligrosidad comparada del código reciente y del código antiguo se sostiene.
Una verificación muy rigurosa puede aun así no ver nadaVerificar lo que devuelve
Una revisión, por disciplinada que sea, solo juzga lo que ya existe: una pantalla nunca construida o una función nunca escrita no aparecen en ningún sitio de su alcance. Lo que cubre ese vacío es una pregunta distinta, planteada fuera del código releído, como un recorrido de usuario completo confiado a un uso real.
Probado, o simplemente aún no refutadoVerificar lo que devuelve
Probado significa que has ejecutado un comando concreto y que puedes citar su salida. Aún no refutado significa solo que nada ha detectado un problema hasta ahora, una afirmación mucho más débil. Una vista previa en verde o la ausencia de error en consola no prueban que no exista ningún defecto.
Un control de forma nunca ve un valor falsoVerificar lo que devuelve
Un control automatizado verifica casi siempre la forma y muy raramente la verdad: un archivo válido, una codificación correcta o una palabra clave presente pueden convivir con una cifra falsa. Validar una captura de la página que genera el documento tampoco prueba lo que la persona abre realmente.
Reabrir cada fuente antes de creerlaVerificar lo que devuelve
Un agente de búsqueda reporta lo que un índice muestra, no lo que una página en directo contiene hoy, y presenta un enlace muerto con la misma seguridad que un enlace vivo: toda fuente destinada a sostener una conclusión se reabre antes de ser citada.
Contar toda la población, y nombrar la medida por lo que realmente captaVerificar lo que devuelve
Medir sobre los pocos casos advertidos por azar en lugar de sobre toda la población produce una conclusión llena de seguridad y sin embargo falsa, y esa misma conclusión sigue siendo falsa si el nombre que se le da al resultado dice algo distinto de lo que el instrumento realmente captó.
Tres agentes de acuerdo, una sola fuenteVerificar lo que devuelve
Los agentes que devuelven la misma conclusión citando la misma página no confirman nada: el equipo tiene una sola fuente, citada varias veces. Un acuerdo vale lo que valen las fuentes distintas que lo sostienen, y una dirección diferente, o una copia bajo otro dominio, no es todavía una fuente independiente.
Lo que un control exime desaparece de su salidaVerificar lo que devuelve
Lo que un control exime desaparece de su salida: el perímetro se decide una vez y luego nadie lo relee. Un veredicto conforme recae sobre la carpeta menos la parte eximida, que puede crecer sin ruido. Dale a esa parte su propio umbral, que pese sobre el veredicto; mostrar su peso no basta.
Encadenar los promptsTécnicas que cambian el resultado
Encadenar consiste en dividir una tarea compleja en varios mensajes cortos, donde la respuesta de uno sirve de materia prima al siguiente. Cada eslabón se convierte en un punto donde se puede leer, corregir o detener la cadena antes de continuar. El patrón más simple encadena borrador, relectura, corrección.
Darle manos a ClaudeTécnicas que cambian el resultado
Claude actúa más allá del texto pasando por una herramienta, una función descrita por un nombre, una explicación y la forma de sus argumentos. Elige llamarla y propone argumentos, pero la ejecución corresponde siempre a algo distinto de él, tu aplicación o ciertos servidores de Anthropic. Cuanto más precisa es la descripción, más exactos son los argumentos.
Componer un system prompt a partir de varias fuentesTécnicas que cambian el resultado
Toma una regla de otro sitio y reescríbela con tus propias palabras para tu propia situación, en lugar de copiarla tal cual. Si una regla importada contradice una ya establecida, la prioridad corresponde a la del propietario del system prompt. Después verifica que la regla reformulada sigue activando el comportamiento esperado.
Citar las fuentes y no andarse con rodeosTécnicas que cambian el resultado
Una cita útil cabe en un corchete en línea justo después de la frase que demuestra, una fuente por corchete, sin una sección aparte al final del mensaje, y una respuesta directa plantea el hecho en lugar de anunciarlo y luego cerrarse con una pregunta de cortesía.
Salidas estructuradas y salvaguardasTécnicas que cambian el resultado
Imponer un esquema exacto a una salida y verificar esa salida antes de usarla son dos mitades del mismo reflejo, una fuerza la forma en origen, la otra la controla en destino, y ambas cuentan más cuando la acción que sigue no tiene marcha atrás.
Verificar un prompt como se verifica un resultadoTécnicas que cambian el resultado
Un prompt se verifica con un eval, un conjunto de casos de prueba fijos escritos de antemano que lo puntúa automáticamente, y no con unos ejemplos probados por azar. Un prompt mejorado pidiéndoselo a Claude (meta-prompting) sigue siendo un borrador y pasa por el mismo conjunto de casos. Vuelve a probar sobre exactamente el mismo conjunto, antes y después.
Hacer decir varias veces, y contradecirse uno mismoTécnicas que cambian el resultado
Pedir varias respuestas independientes y quedarse con la mayoría filtra el ruido de una sola respuesta, y pedirle a Claude que haga de abogado del diablo contra su propia respuesta encuentra errores que un solo pase deja pasar, siempre que una síntesis final separe las objeciones válidas del ruido.
El premortem: suponer que el plan ya ha fracasadoTécnicas que cambian el resultado
El premortem invierte la pregunta. En lugar de preguntar si el plan es bueno, lo que invita a buscar razones para responder que sí, planteas que ya ha fracasado y pides la autopsia. Esta saca a la luz las causas del fracaso, que siguen siendo hipótesis por comprobar.
El panorama de los modelos, una misma familia de predictoresElegir tu modelo y tu herramienta
Claude, GPT y Gemini se basan en el mismo principio de entrenamiento básico, que Anthropic describe así para Claude: predecir la palabra siguiente. Los modelos de pesos abiertos comparten esta arquitectura. Una técnica de prompts aprendida en Claude suele funcionar casi igual en otros lugares, aunque la ventana de contexto, el tratamiento de los datos y las herramientas cambien.
Enrutar por tarea, no por marcaElegir tu modelo y tu herramienta
Elige un modelo según lo que exige la tarea: capacidad, velocidad, coste y esfuerzo de ajuste, no por costumbre. Dos preguntas sitúan una tarea: rutinaria o nueva, impacto bajo o alto. Ajustar el prompt, con un rol más preciso o un contexto mejor planteado, suele cambiar más el resultado que cambiar de modelo.
Componer un system prompt entre varios proveedoresElegir tu modelo y tu herramienta
Cuando un prompt debe funcionar en varios proveedores, se identifica la regla más fuerte de cada uno, se fusionan sin contradicción, y las reglas escritas por el propietario del prompt prevalecen en general sobre los valores por defecto de un proveedor, salvo cuando entrarían en conflicto con los límites de seguridad que ese proveedor impone él mismo.
Modelo local, a medida, o simplemente un mejor promptElegir tu modelo y tu herramienta
Para una estructura pequeña, en la inmensa mayoría de los casos, un prompt mejor escrito resuelve el problema más rápido. Un modelo de pesos abiertos en local no genera coste por llamada ni envía datos fuera, pero exige un equipo. Un modelo a medida cuesta caro construir y solo se justifica a muy gran volumen o para un formato fijo.
Low, medium, high, xhigh, max: elegir tu nivel de esfuerzoElegir tu modelo y tu herramienta
Parte del nivel marcado Default, sube un escalón si la respuesta te parece superficial, baja un escalón si tarda en una pregunta sencilla. El nivel de esfuerzo regula cuánto trabaja Claude antes de responder: más esfuerzo da respuestas más profundas, pero tardan más y alcanzas antes los límites de tu plan.
Abrir Cowork e instalar tu primer espacio de trabajoCowork, el colega digital
Cowork es el agente de escritorio de Anthropic: exige un plan de pago y, para tocar tus archivos locales, la aplicación Claude Desktop abierta y conectada. Su espacio de trabajo es un proyecto, que agrupa carpetas adjuntas, instrucciones escritas de una vez por todas y una memoria que le pertenece.
Lo que Cowork puede tocar, y lo que nunca debe tocarCowork, el colega digital
El acceso de Cowork se divide en tres planos distintos, las carpetas conectadas, el uso directo de tus aplicaciones y de tu pantalla, y una red aislada que bloquea por defecto las direcciones internas; en los tres casos, una eliminación definitiva de archivo siempre exige tu confirmación.
Escribir un brief que Cowork pueda ejecutar, y luego leer su plan antes de que empieceCowork, el colega digital
Un buen brief nombra un resultado, su fuente, su destino y el espacio de trabajo en cuestión, como para un colega que empieza ese mismo día; Cowork responde con un plan que hay que revisar, porque una hipótesis falsa detectada antes de la ejecución se corrige sin coste, detectada después puede exigir deshacer escrituras.
Elegir tu nivel de aprobación, paso a pasoCowork, el colega digital
En una cuenta que aún no ha pasado a la nueva experiencia, los modos de aprobación deciden quién controla una acción de Cowork antes de que se ejecute: tú (Manual), el propio Claude (Automático), nadie (Sin aprobación). Pasa a Manual para archivos, cuentas o sitios sensibles, una herramienta usada por primera vez o un error difícil de deshacer.
Reconstruir una hoja de cálculo real o un informe, no un borrador para corregirCowork, el colega digital
Cowork devuelve un archivo terminado, un libro con fórmulas que recalculan de verdad, una presentación montada o un documento con formato, no texto plano para maquetar. Nombra la estructura exacta esperada o proporciona un modelo para copiar. Una cifra correcta en una celda no demuestra la fórmula: haz clic en la celda y léela.
Conectores: lo que realmente leen y escribenCowork, el colega digital
Las capacidades de un conector se verifican servicio por servicio: no se adivinan por parecido con otra herramienta del mismo editor. El conector Gmail puede enviar, responder y reenviar mensajes, con una aprobación solicitada por defecto. El de Outlook depende de lo que un administrador de la cuenta haya activado para toda la organización.
Tarea planificada o Computer Use: en qué orden lo intenta CoworkCowork, el colega digital
Cowork intenta primero un conector, luego el navegador de la aplicación de escritorio, y solo como último recurso el control directo de la pantalla, siempre en el mismo orden. Una tarea planificada dispara esta misma cascada a la hora fijada, sin que ningún humano mire la pantalla en el momento en que se ejecuta.
Cowork en todas partes, quién puede hacer qué, y el rastro que dejaCowork, el colega digital
Cowork funciona en el escritorio, la web y el móvil, con sesiones en la nube que continúan sin ningún dispositivo encendido. El acceso depende del plan: en Enterprise, un administrador debe activarlo. En Team y Enterprise, una exportación técnica, limitada por defecto a los metadatos, existe solo si un administrador ha configurado un colector; no cubre una sesión local.
Receta: ordenar tu correo sin enviar nada por errorRecetas para el trabajo diario
Un ataque por inyección de prompt exige dos condiciones a la vez, leer un contenido no confiable y poder actuar sobre él: para el correo, la verdadera barrera ya no es la incapacidad de enviar, depende del ajuste de aprobación vigente en tu espacio, a verificar antes de confiar solo en tu propia relectura.
Receta: transformar notas dispersas en un documento o una hoja de cálculo limpiaRecetas para el trabajo diario
Cowork produce documentos estructurados y hojas de cálculo con fórmulas que funcionan a partir de notas en bruto: en un lote grande, pedir explícitamente un plan y luego cada sección por separado da un resultado más fiable que una sola gran instrucción lanzada sobre toda la carpeta.
Receta: construir un texto en pasos separados en lugar de una sola vezRecetas para el trabajo diario
Un texto importante se divide en pasos nombrados, cada uno con un solo rol, un plan aprobado primero, la redacción después, un ajuste del tono como paso propio, y luego una relectura confiada a un rol de editor en lugar de una simple petición de reescritura.
Receta: organizar la memoria común del equipo sin duplicarlaRecetas para el trabajo diario
La memoria común no mejora añadiendo archivos: mejora cuando vincula lo que ya existe y señala lo que se repite. Pide a Cowork que compare el contenido de los documentos en lugar de sus títulos, que anote un enlace al documento emparentado en lugar de fusionar, y mantén al día un índice de una página.
Receta: producir un mismo documento en varios idiomas sin que diverjaRecetas para el trabajo diario
Designa una versión como fuente y bloquéala, y pide luego cada idioma directamente a partir de ella, nunca de una traducción. Compara después las cifras clave y los términos técnicos entre las versiones. Anota en cada archivo la versión de la fuente utilizada, para que una corrección no se olvide en un idioma.
Receta: compartir un documento en un solo archivo que se abre en cualquier lugarRecetas para el trabajo diario
Produce un único archivo autónomo que incorpore todo lo que muestra, texto, imágenes y formato, sin enlace ni fuente externos. Ábrelo después sin conexión antes del envío: una imagen que falta o un formato roto revela una dependencia. El formato no garantiza nada por sí solo.
Claude Docs: un documento que tu equipo edita con ClaudeRecetas para el trabajo diario
Claude Docs sirve para escribir documentos vivos con Claude y tu equipo. Las personas con acceso de editor trabajan en el documento a la vez que tú, y cada modificación aparece en tiempo real, atribuida a su autor. Para un retoque preciso, comenta un pasaje y menciona a @Claude, que responde en el hilo.
Claude Code y el bucle del agenteFundamentos y bucle del agente
El bucle del agente es el ciclo en el que Claude Code reflexiona, llama a una herramienta real y observa lo que esa herramienta ha producido antes de decidir el siguiente paso. No devuelve una respuesta única: el bucle se repite tantas veces como sea necesario, hasta el objetivo. Cada reflexión y cada observación se muestran sobre la marcha.
CLAUDE.md, la memoria del proyectoFundamentos y bucle del agente
CLAUDE.md es un archivo de texto colocado en la raíz de un repositorio, que Claude Code lee automáticamente al inicio de cada sesión abierta en él. Sus reglas se leen como contexto, sin garantía estricta de cumplimiento. Para bloquear una acción decida lo que decida Claude, hace falta un hook PreToolUse.
Los comandos slash esencialesFundamentos y bucle del agente
Unos pocos comandos slash gestionan la memoria del proyecto, ponen el contexto a cero o lo resumen, e inspeccionan lo que está cargado en la sesión, sin tocar nunca el código del repositorio. /clear borra todo, /compact conserva un resumen de lo que se acaba de hacer, útil en plena tarea larga.
Permisos y modo planFundamentos y bucle del agente
El modo de permiso decide qué acciones ejecuta Claude Code sin preguntar: desde septiembre de 2026, una sesión interactiva de terminal o VS Code sin modo configurado arranca en modo auto, en todos los planes, y ya no en modo default, y el modo auto actúa ampliamente bajo la vigilancia en segundo plano de un segundo modelo.
Interrumpir y redirigir en plena tareaFundamentos y bucle del agente
Esc interrumpe la vuelta en curso, reflexión o llamada a herramienta, sin perder el contexto acumulado; teclea después la corrección para retomar sobre la misma base. Ctrl+C depende de lo que esté corriendo en la terminal en ese instante y, pulsada una segunda vez cuando nada está corriendo, termina la sesión de Claude Code misma.
Apuntar a los archivos con @Fundamentos y bucle del agente
El símbolo arroba abre un menú que apunta a un archivo o una carpeta real del disco, se filtra a medida que se teclea, y distingue claramente el instante en que se inserta una ruta en el mensaje del instante en que ese mensaje se envía.
Ejecutar comandos de shellFundamentos y bucle del agente
La herramienta Bash ejecuta un comando de shell real en tu equipo, no una simulación, y Claude Code lee la salida estándar y la salida de error para continuar a partir de lo que realmente se produjo. Aparece un aviso de permiso antes de cada comando nuevo, salvo para un conjunto integrado de comandos de solo lectura.
Leer y aprobar un diffFundamentos y bucle del agente
Un diff se lee línea por línea antes de aprobarse: marca con un menos lo que desaparece del archivo y con un más lo que se añade, y una modificación quirúrgica se reconoce por la brevedad de esos dos bloques. La aprobación se hace mediante un menú de opciones con nombre, no con una pulsación libre.
La lista de tareas y la línea de estadoFundamentos y bucle del agente
En los modelos más recientes, la lista de tareas permanece vacía por defecto, ya que Claude gestiona el trabajo en varias etapas sin mostrarlo, mientras que una línea de estado configurada mediante un script muestra en directo el modelo activo, la ventana de contexto y el costo de la sesión.
El mapa de una instalación estructuradaUna instalación estructurada
Una instalación de Claude Code que aguanta con el tiempo se lee como un mapa de siete elementos, el motor, la constitución CLAUDE.md, la memoria de archivos, el transporte git, los hooks, las skills y el latido programado, en lugar de como un amontonamiento de ajustes sin plan.
Instalar, conectarse y primer lanzamientoUna instalación estructurada
Claude Code se instala con cinco comandos, pero solo los dos nativos (curl, irm) se actualizan solos. Conéctate con tu suscripción: una clave API ya presente en el entorno no se usa en silencio, y Claude Code te pide aprobarla. Después ejecuta claude doctor, que verifica la instalación y propone una corrección solo después de informar.
CLAUDE.md global, una constituciónUna instalación estructurada
El CLAUDE.md global ahora apunta a una longitud en líneas en lugar de en kilobytes, y no prevalece sobre los demás CLAUDE.md por sobrescritura: las cuatro escalas, gestionada, usuario, proyecto, local, se concatenan en el contexto de la más amplia a la más específica.
Conectar la memoria de archivos a gitUna instalación estructurada
Una carpeta de memoria versionada con git, con un remote privado y una regla de fusión que conserva ambos contenidos en lugar de forzar, sigue siendo una técnica que hay que construir uno mismo, distinta de la memoria automática nativa que, por su parte, nunca sale de la máquina local.
Hooks y latidoUna instalación estructurada
Los eventos del ciclo de vida disparan hooks según tres cadencias distintas, SessionStart y SessionEnd forman la pareja natural para automatizar el protocolo de memoria, y la consolidación nocturna sigue siendo una tarea programada del sistema operativo que hay que construir uno mismo, no un mecanismo de Claude Code documentado bajo ese nombre.
Depurar tus skills y cerrar la instalaciónUna instalación estructurada
Una skill se instala una por una frente a una necesidad ya encontrada, nunca por lotes, y cerrar la instalación consiste en demostrar cada uno de los siete elementos del mapa del módulo mediante un gesto ejecutable en lugar de suponerlos ya implementados.
AGENTS.md: cuándo lo lee Claude Code y cómo comprobarloUna instalación estructurada
Con el ajuste por defecto, Claude Code lee AGENTS.md solo cuando ningún CLAUDE.md, CLAUDE.local.md incluido, ocupa su lugar en la carpeta de trabajo o por encima. El panel /config dice lo que se pide, no lo que se ha leído: compruébalo al arrancar la sesión, por la línea mostrada en la conversación o con el comando /memory.
Tus consignas envejecen con los modelosUna instalación estructurada
Tus consignas envejecen porque una regla nacida de un defecto de un modelo se queda en su sitio cuando el modelo cambia: no es falsa, se vuelve inútil, y el modelo sigue leyéndola en cada sesión. El comando /doctor prompt-audit relee tus archivos de consignas y localiza las escritas para modelos antiguos.
Skills: enseñar un workflow a ClaudeExtender: habilidades, MCP, subagentes, hooks, plugins
Una skill enseña un workflow a Claude al reunir un modo operativo completo en un solo archivo SKILL.md. Claude la activa de dos maneras: con un comando slash que lleva el nombre de la carpeta, o automáticamente cuando su descripción coincide con la solicitud. Una vez cargada, su texto se suma al turno como instrucciones adicionales.
Crear una skill que también se convierte en un comandoExtender: habilidades, MCP, subagentes, hooks, plugins
Un comando personalizado y una skill son ahora el mismo mecanismo: un archivo .claude/commands/nombre.md y una carpeta .claude/skills/nombre/SKILL.md producen ambos el comando /nombre con el mismo comportamiento, y para una skill personal o de proyecto, es el nombre de la carpeta, no el campo name del frontmatter, el que se convierte en el nombre del comando.
Descubrir, depurar y apilar skillsExtender: habilidades, MCP, subagentes, hooks, plugins
Busca primero en las dos bibliotecas públicas mantenidas por Anthropic, claude-plugins-official y claude-community, antes de escribir una skill. Varias skills pueden cargarse juntas en una misma tarea, pero cada una agrega texto al contexto de cada sesión: retira la que ya no responde a una necesidad recurrente.
MCP: el protocolo de conexiónExtender: habilidades, MCP, subagentes, hooks, plugins
MCP es un estándar abierto que describe cómo Claude Code se conecta a herramientas y datos que viven fuera de él. Un servidor MCP expone tres primitivas distintas: herramientas que Claude llama con argumentos, recursos que lee como un contenido e invitaciones que solo activa el usuario. Estas primitivas no se sustituyen entre sí.
Conectar un servidor MCP y qué ha cambiadoExtender: habilidades, MCP, subagentes, hooks, plugins
Un servidor MCP remoto se conecta con un solo comando, claude mcp add, y Claude Code detecta por sí mismo si hace falta una autenticación. claude mcp list muestra el estado real de cada servidor declarado. Independientemente de Claude Code, la especificación MCP cambió de núcleo: uno sin estado sustituye al núcleo con estado.
Construir tu propio servidor MCPExtender: habilidades, MCP, subagentes, hooks, plugins
Un servidor MCP casero es un programa ordinario que Claude Code lanza él mismo como proceso hijo mediante el transporte stdio. El esquema JSON declara lo que espera la herramienta, pero la validación sigue siendo responsabilidad del servidor, y es el campo description el que decide si Claude elige esa herramienta.
Subagentes: delegar en un contexto aisladoExtender: habilidades, MCP, subagentes, hooks, plugins
Un subagente ejecuta una tarea en su propia ventana de contexto, separada de la conversación principal. Cuando termina, solo su conclusión vuelve a tu hilo: los archivos leídos, los registros recorridos y los callejones sin salida explorados se quedan en su propio contexto. Una buena delegación da un objetivo completo y un perímetro de escritura nombrado.
Hooks: automatizar el ciclo de vidaExtender: habilidades, MCP, subagentes, hooks, plugins
Un hook es una acción que el arnés ejecuta él mismo cuando ocurre un evento preciso del ciclo de vida. Una consigna anotada en la memoria sigue siendo una preferencia que el modelo puede olvidar; un hook declarado una sola vez se ejecuta en cada ocurrencia, independientemente de lo que el modelo recuerde en ese instante.
Los eventos de hook, del disparo al mensajeExtender: habilidades, MCP, subagentes, hooks, plugins
PreToolUse se ejecuta antes de la herramienta y puede impedir la llamada; PostToolUse se ejecuta después y solo puede reaccionar, incluso sustituyendo el resultado de la herramienta. Un hook comunica su decisión mediante un objeto JSON con campos precisos y mediante su código de salida, nunca con una frase escrita en la salida estándar.
Plugins: agrupar skills, hooks, MCP y agentesExtender: habilidades, MCP, subagentes, hooks, plugins
Un plugin agrupa skills, hooks, servidores MCP, comandos y subagentes en un solo directorio versionado, instalable y compartible de una sola vez. Su manifiesto, plugin.json, es el único archivo de .claude-plugin/; el error más frecuente es poner ahí skills/, commands/, agents/ o hooks/ en lugar de la raíz del plugin.
settings.json en profundidadExtender: habilidades, MCP, subagentes, hooks, plugins
En una clave simple presente en varios niveles, el nivel más fuerte se impone por completo, mientras que la mayoría de las listas, entre ellas permissions.allow y permissions.deny, se fusionan entre niveles. El bloque env sigue los mismos niveles que el resto del archivo, y una variable de entorno del shell no es un nivel de esta pila.
El enrutamiento de las skills falla en silencioExtender: habilidades, MCP, subagentes, hooks, plugins
Claude decide invocar una skill comparando el vocabulario de la solicitud con el único campo description de esa skill, y un desajuste de idioma o de jerga entre ambos hace fallar la invocación automática sin ninguna señal visible en la respuesta.
Depurar y corregir un bugGestos cotidianos
Un comando de reproducción preciso y una traza de pila completa orientan el diagnóstico hacia la causa real de un bug, y la corrección no se declara cerrada hasta que se ha ejecutado un test de regresión que reproduce el caso defectuoso y se ha leído su salida.
Construir y refactorizar con los tests primeroGestos cotidianos
Pide los tests antes de la implementación y lanza el runner de tests para constatar que fallan de verdad: el rojo prueba que el test puede fallar, el verde que la implementación lo satisface. Claude reproduce el estilo de los tests ya presentes en el repositorio, y el refactor avanza una preocupación a la vez.
Revisar código y pilotar git en lenguaje naturalGestos cotidianos
/code-review lanza una revisión local con niveles de esfuerzo de low a max, y ultra no es uno de ellos: es un dispositivo distinto, una revisión multiagente en la nube, facturada por separado. Git se pilota después en lenguaje corriente, con la misma red de seguridad de permisos que los comandos tecleados a mano.
Tomar el control, documentar y migrar una base de códigoGestos cotidianos
En un repositorio desconocido, empieza pidiendo una visión general antes de cualquier cambio: orienta las preguntas siguientes. El comando /init lee el contenido del repositorio para producir un primer CLAUDE.md, un borrador que se relee y se recorta, y la migración o la documentación termina con la relectura del diff final.
Automatizar una tarea repetitiva y escribir un script desechableGestos cotidianos
Automatizar un gesto repetido empieza por separar lo que permanece fijo de lo que varía cada vez, se describe por su entrada, su salida y el entorno donde debe ejecutarse, y se verifica con un ensayo en vacío antes de cualquier paso que suprima, mueva o sobrescriba algo.
Los gestos rápidos de la terminalGestos cotidianos
Un puñado de gestos breves cubre lo esencial de una sesión en el día a día: retomar una sesión precisa, volver a un punto de control anterior, lanzar un comando de shell sin salir de la conversación, y pedir un razonamiento más profundo para un solo turno sin cambiar el ajuste de toda la sesión.
Modo headless, estilos de salida y tareas en segundo planoGestos cotidianos
El modo headless ejecuta Claude Code sin interfaz interactiva con -p, --output-format determina si la salida sigue siendo texto o se convierte en un objeto JSON utilizable por un script, con el costo total incluido, y run_in_background deja que un comando largo continúe sin bloquear la conversación.
Paralelizar: worktrees, modelo y modo rápidoGestos cotidianos
Un git worktree abre un segundo checkout del repositorio en su propia rama, así que varias sesiones de Claude Code trabajan en paralelo sin pisarse. El comando claude --worktree lo crea automáticamente. En cada worktree, el modelo se elige según la dificultad, y el modo rápido según el costo.
Trampas de escritura: archivos, ediciones paralelas y entregables perdidosGestos cotidianos
Un informe de éxito escrito por un subagente no prueba nada sobre el estado real de los archivos, ya que arranca en un contexto aislado sin acceso a lo que el agente principal ya leyó o escribió, y la única prueba fiable sigue siendo un diff verificado después, no el texto del informe.
Bucles, contexto contaminado y reinicioCuando algo falla
La señal de un bucle es la repetición del mismo mensaje de error, un contexto saturado se trata con una compactación específica o con un borrado completo, y reiniciar con un resumen escrito a mano de las decisiones ya tomadas vale más que insistir en una conversación degradada.
Deshacer y recuperar una modificaciónCuando algo falla
Para deshacer la última modificación de Claude Code en la sesión en curso, abre el menú de puntos de reanudación con /rewind en lugar de pasar primero por Git. Git sigue siendo la herramienta para lo que esos puntos ignoran: las modificaciones de un comando bash, las ediciones de un subagente en segundo plano y los archivos enlazados.
Errores de API y limite de tasaCuando algo falla
Un error de API lleva un código de estado que distingue causas muy diferentes: una solicitud mal formada debe corregirse antes de reintentar, mientras que un límite temporal se resuelve respetando Retry-After. Un límite de gasto alcanzado no lleva esa cabecera, y esperar no sirve de nada: hay que elevar el límite mismo.
Un comando bloqueadoCuando algo falla
Ante un comando de shell congelado, pulsa Ctrl+C, que intenta interrumpir la operación; si no basta, relanza con claude --resume. No añadas a mano un prefijo timeout, porque la herramienta Bash ya lleva un parámetro de plazo que Claude decide por sí mismo, y la mayoría de los comandos que alcanzan su plazo pasan a segundo plano sin detenerse.
Varias sesiones mueren juntas, sospecha de la máquinaCuando algo falla
Cuando varias sesiones mueren en el mismo instante sin ningún rastro en sus propios registros, la causa probable es el sistema operativo que mata procesos bajo presión de memoria, y el registro del sistema resuelve la duda más rápido que una caza de errores de la aplicación.
La solicitud puede partir de una premisa falsaCuando algo falla
Una solicitud de corrección mezcla un síntoma observado con una causa supuesta: el síntoma puede ser exacto mientras la causa es falsa. Ejecutarla al pie de la letra no repara nada. Mide el estado real, enuncia la discrepancia al inicio de la respuesta y corrige después la causa real.
Leer la función invocada, probar al culpableCuando algo falla
Una corrección cuya prueba unitaria pasa en verde puede quedar anulada, en la misma vuelta de ejecución, por la función invocada justo después, y la función ya corregida solo es un culpable probado una vez que una prueba ha aislado su efecto del de las funciones siguientes.
Las cuatro palancas de una sesión largaContexto y coste
Una sesión larga no hincha indefinidamente el texto enviado al modelo, gracias a palancas distintas: la caché, que reutiliza un inicio de conversación idéntico, la retirada de las salidas de herramientas inútiles, la compactación, que reemplaza el historial por un resumen, y la delegación a subagentes, que solo devuelven su conclusión.
Compactar, borrar, leer solo lo necesarioContexto y coste
El comando /compact reemplaza el historial de mensajes por un resumen y continúa la misma conversación, el comando /clear borra ese historial y empieza de cero, y en ambos casos los archivos del proyecto en disco no se mueven: el gesto que más ahorra sigue siendo hacer que Claude lea solo el tramo pertinente de un archivo.
Caché de prompt y Batch API, dos descuentos que conocerContexto y coste
La caché de prompt y la Batch API son dos descuentos diferentes sobre el mismo coste en tokens. La caché recompensa un inicio de conversación que no cambia, la Batch API un volumen de solicitudes que puede esperar. La duración de vida de la caché depende de tu oferta: suscripción de pago o clave de API.
El umbral de autocompactado no hace lo que se creeContexto y coste
El umbral de autocompactado activa un resumen de la conversación cuando el contexto lo alcanza, no es un muro que cierre la ventana: un valor configurado por encima de la ventana real del modelo activo queda limitado a esa ventana, un comportamiento documentado cuya ausencia de aviso en pantalla queda por verificar uno mismo.
Una ventana de contexto no sigue al modeloContexto y coste
La ventana de contexto es una propiedad del modelo: los modelos recientes tienen la ventana grande de base, dos modelos más antiguos la piden con el sufijo [1m], y cada cambio de modelo se comprueba en pantalla con /model y luego /context.
De dónde viene realmente la factura, y por qué un recuento mienteContexto y coste
El coste de una sesión no viene del volumen de trabajo sino del número de veces que se reenvía el historial acumulado: cada llamada de herramienta lo relee, a la tarifa reducida de caché pero nunca a coste cero. Un recuento que confunde una relectura en caché con una primera lectura da una impresión falsa de la factura.
Cuota, límite de tasa y enrutamiento hacia el modelo más baratoContexto y coste
Dos límites distintos gobiernan una sesión, el coste en dinero y el límite de tasa en tokens por minuto, y ambos se tratan con el mismo reflejo: enrutar las tareas repetitivas hacia Haiku o Sonnet, reservar Opus para el razonamiento difícil, y esperar respetando un plazo creciente tras un error 429 en lugar de reintentar de inmediato.
Un subagente cuesta antes de haber trabajadoContexto y coste
Un subagente cuesta antes de haber trabajado, porque su conversación ya contiene elementos que tú no escribiste y que cada lanzamiento vuelve a cargar. Sin campo tools hereda todas las herramientas, y sin modelo nombrado funciona con el mismo modelo que tú. Lista sus herramientas y nombra su modelo según el papel.
Memoria en archivos: estructura y disciplinas básicasEl segundo cerebro
La memoria de Claude Code vive en una carpeta de archivos markdown, un hecho por archivo clasificado mediante un campo type con cuatro valores, y una nota que lleva una sola idea vinculada al menos a otra sigue siendo localizable en unos segundos en lugar de mediante una relectura completa.
Obsidian: wikilinks, mapas de contenido y tipos de memoriaEl segundo cerebro
El wikilink es una funcionalidad nativa de Obsidian que conecta una nota con otra sin depender de su carpeta. El mapa de contenido es solo una práctica, una nota que reúne enlaces. Muchas personas retoman en su bóveda Obsidian el vocabulario de tipos de la memoria de Claude Code, pero son dos herramientas separadas.
Interrogar un grafo en lugar de releerlo todoEl segundo cerebro
Un grafo de conocimiento construido una vez responde a una pregunta recorriendo enlaces explícitos, lo que cuesta bastante menos tokens que una relectura completa de los archivos fuente, una diferencia ilustrada por un ejemplo público que lleva su propia reserva, y el mismo principio se aplica a un transcript antiguo de sesión, interrogado por niveles antes de reabrirlo entero.
Dream y aprendizaje continuo: la consolidación nocturnaEl segundo cerebro
Una consolidación nocturna de memoria es una automatización personal construida sobre una tarea programada, no una función nativa de Claude: digiere las notas en cuatro fases, orientación, recopilación, consolidación por fusión y archivado, verificación, y solo una tarea que se ejecute en el equipo o en una sesión abierta puede leer una carpeta de notas almacenada localmente.
Una cifra perecedera en un archivo siempre cargadoEl segundo cerebro
Una cifra que duerme en un archivo siempre cargado se lee como una cifra del día, aunque pueda haberse vuelto falsa. Si nadie recibiría una alerta el día en que cambia, su lugar es un registro fechado, abierto solo cuando la pregunta se plantea, y el archivo cargado cita el principio o remite al registro.
Una bóveda compartida no tiene edición concurrenteEl segundo cerebro
Una aplicación de notas basada en archivos locales no bloquea nada en una unidad de red compartida: un testimonio público documenta una carpeta de configuración que se sobrescribe entre usuarios en este tipo de montaje, y ese mismo mecanismo hace plausible, sin que la fuente lo documente ella misma, la pérdida silenciosa de una edición de nota.
El diario del asistente habla sobre todo del asistenteEl segundo cerebro
Una revisión de un gran corpus de memoria mantenido por un agente muestra que la mayoría de las entradas documentan los errores del propio agente, escritas por él, sobre él, con casi ninguna instrucción explícita de la persona a la que se cree estar perfilando: es como juzgar a un piloto por el diario de mantenimiento del avión.
Fan-out, pipeline, barrera: elegir la arquitectura, o renunciar a ellaVarios agentes y verificación adversa
El fan-out hace converger agentes independientes detrás de una barrera que espera a todos, y el pipeline hace avanzar cada elemento sin esperar a los demás. La tercera opción es no lanzar ningún agente, porque la arquitectura multiagente es una opción costosa: empieza por el enfoque más simple que funcione.
Aislar y ejecutar en segundo plano: worktrees y bucle en secoVarios agentes y verificación adversa
Para que un agente no sobrescriba el trabajo de otro en el mismo repositorio, da a cada uno su propio worktree con isolation: worktree. Un agente lanzado en sesión interactiva corre ahora en segundo plano por defecto. Para que una búsqueda sepa detenerse, compara cada ciclo con lo ya conocido y para cuando las pasadas consecutivas no señalen nada nuevo.
Sostener un fan-out a gran escalaVarios agentes y verificación adversa
Un único agente encargado de un entregable demasiado largo se ve interrumpido por un límite de tamaño de salida: la solución es un agente por eje, cada uno escribiendo su propio archivo. Verifica después el disco, nunca el informe: escribe antes de lanzar la lista exacta de archivos esperados y compárala con lo que existe de verdad.
Workflows deterministas: esquemas, checkpoints, reanudaciónVarios agentes y verificación adversa
Un workflow es un script que encadena llamadas de agente de forma determinista: las mismas etapas y el mismo esquema de salida en cada ejecución. Un esquema JSON impone campos con nombre de una etapa a otra, y cada etapa terminada escribe un checkpoint, de modo que un workflow interrumpido se reanuda sin rehacerlo todo.
Verificación adversarial, paneles de jueces y crítica de completitudVarios agentes y verificación adversa
Un verificador recibe el artefacto a juzgar, criterios de éxito claros y las herramientas para verificar, y un informe vacío solo es creíble si cuenta lo que controló. Un panel compara soluciones y una crítica de completitud compara el pliego con lo entregado: roles que no deben confundirse.
Multiplicar los agentes puede multiplicar el errorVarios agentes y verificación adversa
Un estudio (prepublicación en arXiv) mide que agentes independientes, sin un coordinador que valide sus salidas, amplifican los errores mucho más que un agente solo. Un coordinador que relee cada salida reduce claramente esa amplificación, y en una tarea de pasos estrictamente ordenados las cuatro arquitecturas con varios agentes probadas retroceden frente a un agente solo.
Una premisa no verificada en un prompt vuelve como conclusiónVarios agentes y verificación adversa
Una premisa falsa deslizada en el encuadre de un prompt nunca se pone a prueba: el agente la trata como un hecho y la refleja en su resultado, y el verificador adverso, que solo relee ese resultado, no la ve. En un fan-out se repite en cada salida, lo que da una falsa impresión de corroboración.
Tres estados de fallo, y aceptar un riesgo correctamenteVarios agentes y verificación adversa
Una cola de tareas distingue el éxito, el fallo recuperable que se reintentará y el fallo definitivo; confundir los dos últimos en una sola categoría rompe el valor de cualquier alerta. Aceptar un riesgo es dejar que ocurra y verificar a posteriori con una instantánea tomada antes de la ejecución, no ignorarlo.
Retirar la herramienta antes de escribir la prohibiciónVarios agentes y verificación adversa
Una consigna que prohíbe orienta lo que un agente intenta sin impedir nada: la protección que aguanta le retira primero las herramientas que su misión no necesita, y la lista cerrada de los efectos esperados y la prohibición por clase vienen en segunda y tercera línea, como consignas.
Exitoso, fallido, interrumpido, sin rastroVarios agentes y verificación adversa
Cuando un corte detiene una cola de tareas, un registro llevado fuera del proceso, escrito antes y después de cada tarea, separa cuatro estados: exitoso, fallido, interrumpido a mitad de camino y sin rastro de intento; confundirlos hace relanzar lo que puede haber actuado ya, o declarar fallido lo que nadie ha examinado.
Poner un tope a un bucle de jueces antes de lanzarloVarios agentes y verificación adversa
Fija el tope antes de la primera pasada, en los criterios del lote: un número máximo de pasadas de juez y de agentes. El criterio de parada pertenece al juez, al que no controlas, y mientras encuentre algo el bucle continúa y su coste sube. Al alcanzar el tope, se corrigen los hallazgos mayores con fuente y se cierra.
Secretos: nunca hacerlos transitar, nunca mostrarlos en claroSeguridad y datos
Un secreto pegado en una conversación, aunque sea brevemente, permanece después presente en los registros y en cualquier relectura automática del historial, y un comando de configuración lanzado por un motivo preciso puede mostrar un secreto vecino en claro si su filtro es demasiado amplio.
Un secreto en un commit está quemado: rotación inmediata, nunca la fechaSeguridad y datos
Un secreto seguido por un repositorio se trata como comprometido en el instante en que se escribe, no cuando alguien demuestra que ha sido leído, y el remedio que alcanza cada copia es hacer rotar el identificador, la reescritura del historial llega en segundo lugar y no siempre es necesaria.
Seudónimo y anónimo, dos cosas diferentesSeguridad y datos
Un número de referencia en lugar de un nombre sigue siendo un dato personal mientras exista en alguna parte una tabla de correspondencia, y el destinatario puede convertirse en encargado del tratamiento según su papel real; una identidad seudónima en un repositorio necesita además su propia configuración local.
Auditar una skill antes de instalarlaSeguridad y datos
Audita una skill de terceros antes de instalarla: ponla en cuarentena, lee todo su contenido, ejecuta un escáner de seguridad y haz rotar todo secreto que una skill retirada haya podido tocar. El riesgo más frecuente es la instrucción oculta, casi siempre combinada con código malicioso.
Lo que un agente puede filtrar sin que se lo pidasSeguridad y datos
Una instrucción oculta en un contenido que Claude lee durante la tarea, página web, archivo o comentario de repositorio, puede llevarlo a proponer una acción de salida que tú no has pedido: es la inyección de prompt indirecta, que las protecciones documentadas reducen sin eliminarla.
Automatizacion responsable: reversible primero, fallo señalado, correctivo solicitadoSeguridad y datos
Una automatización en modo Auto, Accept Edits o Bypass Permissions ejecuta la mayoría de las eliminaciones en cuanto se alcanza el comando, sin confirmación: construye el punto de control humano antes del comando destructivo. Un fallo silencioso nunca se anuncia solo, y un correctivo bloqueado se pide, no se anota.
Lo que sale de la máquina, lo que se archiva, lo que nunca se comparteSeguridad y datos
Cada petición envía el prompt y la respuesta por la red y deja una copia local legible en claro en el disco: un secreto pegado una vez existe en dos sitios. Archiva en lugar de eliminar, porque un desplazamiento sigue siendo reversible. Filtra un documento interno antes de enviarlo: inventario de los datos sensibles y luego relectura como lector hostil.
Leer basta para exponer un secretoSeguridad y datos
Una búsqueda de texto sobre una carpeta entera devuelve cada línea que contiene el patrón, incluso las de un archivo .env oculto, sin que se haya pedido ninguna lectura de ese archivo. Una regla de denegación Read(./.env) no cubre un comando que lee archivos sin nombrarlos, como grep -r, ni un subproceso que abre él mismo sus archivos.
Una guardia por patrón de texto no es una frontera de seguridadSeguridad y datos
Una guardia que rechaza una palabra en el texto de un comando juzga una escritura y no un efecto: toda escritura que evita esa palabra pasa, e incluso una lista de comandos admitidos por igualdad exacta deja pasar el código que un comando admitido lee en un archivo que el agente puede modificar.
Un acuerdo general no autoriza un envío concretoSeguridad y datos
Un acuerdo dado sobre un método de trabajo valida la forma de proceder, no un envío cuyo contenido aún no se ha mostrado: el acuerdo de envío nombra el texto y los destinatarios, o la categoría de envíos que una autorización duradera designa ella misma.
La petición, una única puerta de entradaLa API de Claude para quienes construyen
La API de Claude tiene una única puerta de entrada, la petición POST de la API Messages: cada intercambio pasa por ella, con un array messages y un modelo elegido. El campo max_tokens es obligatorio, sin valor por defecto, y la respuesta sigue siempre la misma forma, con un stop_reason que indica por qué se detuvo la generación.
Roles que se sostienen, no un prerrellenado que rompeLa API de Claude para quienes construyen
Completar uno mismo el inicio de la respuesta de Claude, el prerrellenado del turno assistant, ya no funciona en los modelos actuales: el servidor devuelve un error, salvo un caso particular de gestión de los rechazos. Una instrucción system estable produce el mismo resultado sin tocar el array messages, y el campo output_config.format restringe la forma de la salida.
Las herramientas, Claude propone, el código disponeLa API de Claude para quienes construyen
Claude nunca ejecuta una herramienta él mismo: devuelve una solicitud de uso, el código del desarrollador la ejecuta realmente y devuelve el resultado para que la conversación continúe. Este ciclo se apoya en un único contrato, el esquema declarado por input_schema. Una herramienta se declara con name, description e input_schema.
Recibir la respuesta en streamingLa API de Claude para quienes construyen
El modo de streaming mantiene abierta la conexión HTTP y entrega el texto por fragmentos, a medida que el modelo lo produce, sin esperar al final de la generación. El recuento de tokens vive en el campo usage del último evento message_delta, nunca en message_stop: un código que lo busca ahí no lo encuentra.
Dos palancas de coste, la memoria en caché y el procesamiento por lotesLa API de Claude para quienes construyen
Un prefijo de petición marcado como reutilizable cuesta una fracción reducida del precio normal cuando se relee desde la caché, y un conjunto de peticiones no urgentes tratado por lotes cuesta menos que un tratamiento inmediato, dos reducciones que se acumulan entre sí y con los demás modificadores de precio.
Contar antes de enviar, la ventana de contextoLa API de Claude para quienes construyen
Un punto de conteo dedicado devuelve el número de tokens de una petición antes de enviarla, y la ventana de contexto con la que comparar esa cifra ya no es un valor común a toda una gama de modelos, ahora varía fuertemente de una familia a otra.
Elegir un modelo, cambiarlo, encajar un rechazoLa API de Claude para quienes construyen
La elección de un modelo es un compromiso entre calidad, velocidad y coste que se revisa en cada nueva generación, y un rechazo devuelto por un clasificador de seguridad se trata como un caso normal del protocolo, no como una avería.
Pasar a Opus 5.5 sin romper tu códigoLa API de Claude para quienes construyen
Pasar de Claude Opus 5 a Claude Opus 5.5 no se resume en cambiar el identificador: cuatro ajustes antiguos devuelven ahora un error 400, y las notas escritas entre dos llamadas a herramientas llegan vacías mientras el código no configure thinking.display.
Pipeline de contenido, del brief al entregable compartibleCasos reales de principio a fin
Un contenido que debe traducirse, ser citado por un asistente y releerse sin conexión se produce mediante una sucesión de roles distintos, cada uno con una sola tarea: brief, redacción, alineamiento de voz, optimización para la búsqueda, traducción por lotes, empaquetado. Cada rol empieza cuando el anterior ha terminado y ha sido aprobado, nunca en paralelo sobre el mismo texto.
Construir un activo de datos, conjunto sintético o base de conocimientoCasos reales de principio a fin
Un conjunto sintético y una base de conocimiento comparten la misma arquitectura: ingesta o generación por lotes, deduplicación, vinculación mediante un esquema compartido y recuperación a través de un índice ligero. El esquema se fija antes del primer registro, y la deduplicación se hace antes de validar, nunca después.
La búsqueda en abanico, con verificación contradictoriaCasos reales de principio a fin
Lanzar las búsquedas en paralelo acelera la recopilación, no el juicio: la velocidad no cambia la fiabilidad. Cada afirmación retenida debe cuestionarse activamente mediante una fuente distinta antes de citarse con su fuente, y la que no resiste sale del borrador en lugar de quedarse en él bajo una forma suavizada.
Verificar antes de creer, cuatro trampas realesCasos reales de principio a fin
Un informe redactado por el agente de un tercero, una skill de pago vendida como un lote de funcionalidades, un conector de datos anunciado como sincronizado y una página de la competencia que muestra una funcionalidad ausente comparten el mismo fallo: cada uno sustituye una medición directa por una afirmación que habría que verificar antes de citarla.
Una aplicación móvil de principio a finCasos reales de principio a fin
Una sola sesión basta para encadenar un scaffold (la estructura inicial generada), una navegación entre pantallas, una llamada de red y la corrección de los tipos señalados, a condición de mantener abierta desde la primera pantalla la vista previa, que se actualiza en tu teléfono. Un error visto justo después de introducirlo se corrige en unos segundos.
Automatizar la propia práctica, pila y skillCasos reales de principio a fin
Un gesto que se repite de forma idéntica se convierte en un comando con nombre, invocado con una palabra en lugar de reconstruirse cada vez. Varias capas lo hacen trabajar solo: la llamada scriptable hace el trabajo, el disparador de ciclo de vida decide cuándo lanzarlo, la memoria destilada guarda lo que hay que retener.
Hacer tu sitio legible por las IA, citación y navegación agénticaCasos reales de principio a fin
La citación por un asistente y la navegación agéntica son dos capacidades distintas, verificadas por dos controles distintos. La citación depende primero de lo que otras páginas dicen del sitio, y el marcado no la crea; la navegación se juega en la página, donde un botón sin texto ni etiqueta accesible sigue siendo invisible para un agente.
Calentamiento, montar un prompt y marcar tu checklistTaller, proyecto final y examen
El calentamiento no escribe ni una línea de código: comprueba que los reflejos adquiridos vuelven solos, sin notas. Reconstruye de memoria un prompt completo y marca después la checklist del practicante punto por punto antes del siguiente proyecto; cada bloque que falta señala un automatismo aún no instalado.
Situarte, de principiante a experto, antes de elegir tu proyectoTaller, proyecto final y examen
Cuatro niveles de autonomía, un Project con instrucciones, una sesión de Claude Code encuadrada por un archivo de configuración, una skill propia, una carpeta de memoria enlazada y consolidada, indican cuál de los tres proyectos de fin de recorrido corresponde a tu propio nivel.
El capstone, tres proyectos reales a elegirTaller, proyecto final y examen
El capstone se supera entregando hasta el final uno de los tres proyectos a elegir: una funcionalidad, un segundo cerebro o un pipeline de contenido. El plan se aprueba antes de la ejecución, el alcance cabe en una sola sesión y la verificación final se hace en el entorno real.
Capstone avanzado, la revisión contradictoria multiagenteTaller, proyecto final y examen
Un único revisor suele caer en el mismo punto ciego que el autor. Distribuir la revisión entre varios subagentes, cada uno con un rol estrecho, corrige ese sesgo, a condición de que los roles sigan siendo distintos, de que ninguna salida incompleta pase a la etapa siguiente y de que la síntesis final haga aflorar los desacuerdos sin suavizarlos.
La checklist de graduación, el examen finalTaller, proyecto final y examen
Releer tu checklist y decirte sí, sé hacer esto, no demuestra nada: una relectura confirma lo que ya crees saber. La versión que revela una laguna te pide citar el gesto preciso que demuestra cada punto; si solo recuerdas haberlo leído, no marques la casilla.