El manual de la microconsultoría

Lo bastante pequeño para decir que sí

Este es un libro sobre el trabajo pequeño. No pequeño en ambición, sino en forma: un encargo con alcance cerrado, un calendario corto y un entregable que el cliente pueda señalar con el dedo cuando esté terminado. Una auditoría de pago sobre cómo usa la IA un equipo. El arreglo de un flujo de trabajo que duele. Un kit de prompts probados. Un piloto de agentes de dos semanas. Una sesión de formación de media jornada. Un sprint de documentación que convierte el saber tribal en algo que puedan leer tanto un modelo como un recién llegado. Cada uno es fácil de comprar, rápido de entregar con Claude y está pensado para llevar al siguiente.

¿Por qué pequeño? Porque lo más difícil de la consultoría nunca ha sido el trabajo. Es el sí. Un encargo grande le pide al comprador que comprometa un presupuesto que no tiene, con una persona a la que no ha puesto a prueba, para un resultado que todavía no es capaz de imaginar. Uno pequeño le pide que arriesgue un poco de dinero a cambio de un resultado concreto en una fecha concreta. La primera conversación acaba en un comité. La segunda acaba en un pago con tarjeta o, en el peor de los casos, en un responsable que puede firmar sin convocar una reunión.

Hay una segunda razón, y es la que hace que este sea el momento. Las herramientas agénticas han desplomado el esfuerzo que exige una enorme cantidad de trabajo útil. Lo que antes le costaba a un consultor tres semanas de lectura, redacción y construcción ahora lleva unos pocos días concentrados, con Claude encargándose de leer, redactar y buena parte de construir. Si vendes ese trabajo por horas, las herramientas te empobrecen. Si lo vendes como un resultado cerrado, las herramientas te convierten en un negocio. El microencargo no es más que la forma comercial que encaja con la nueva economía.

Un sí pequeño sigue siendo un sí. Y es, además, el único que puede darte un desconocido.

El libro se apoya en cien jugadas, agrupadas en diez partes. Las primeras tratan de la oferta en sí y del oficio con el que vas a entregarla: cómo darle instrucciones a un modelo, cómo alimentarlo de contexto, cómo trabajar en un repositorio con Claude Code, cómo codificar el trabajo repetible en forma de skills. La parte central trata de entregar, de ejecutar y de la forma de un precio, sin mencionar jamás una cifra, porque tus cifras dependen de tu mercado y no del de nadie más. Las últimas tratan de la prueba, de la cartera de clientes y de hacia dónde va todo esto. Cada capítulo es o bien una jugada que puedes hacer esta semana o bien un microencargo que puedes ejecutar, y la mayoría terminan con un empujoncito para que lo pruebes.

Una advertencia antes de empezar. Los encargos pequeños no son una forma menor de consultoría. Son más difíciles de hacer bien, porque no hay dónde esconderse. Un programa de doce meses puede absorber una mala quincena. Un sprint de dos semanas, no. Tendrás que acotar con precisión, entregar a la vista de todos y medir con honradez. A cambio obtienes respuestas más rápidas, clientes más contentos y una cartera que se rellena sola. El truco, resulta, no es vender más. Es vender menos, antes, y luego volver a hacerlo.

Vende resultados, no horas

La facturación por horas tiene un defecto discreto que se vuelve escandaloso en cuanto empiezas a trabajar con Claude: te castiga por ser más rápido. Cada hora que te ahorran las herramientas es una hora que no puedes facturar. Vuélvete el doble de rápido y, con tarifa diaria, habrás reducido tus ingresos a la mitad por el mismo resultado. Nadie diseña un negocio así a propósito. Muchos consultores acaban en él por pura inercia.

La alternativa es poner precio al resultado. El cliente no compra tu presencia; compra un flujo de trabajo auditado, un piloto que funciona, un equipo formado, un conjunto de prompts que producen textos conformes a la normativa al primer intento. Describe esa cosa con precisión, ponle un único precio y acordad una fecha. Lo que tardes pasa a ser asunto tuyo, no suyo. Cuando Claude hace en una tarde lo que antes llevaba una semana, la eficiencia es tuya, y financia la siguiente mejora de tu método.

Esto también cambia la conversación con el comprador, casi siempre para bien. Una tarifa diaria invita a regatear los insumos: por qué hacen falta cinco días, no podrían ser cuatro, quién forma parte del equipo. Un resultado cerrado invita a hablar de valor: cuánto vale esto para ti, qué pasa si funciona, qué significa «terminado». La segunda conversación es más útil para ambas partes y mucho menos agotadora. Además te obliga a definir qué es «terminado», que, como defenderán capítulos posteriores, es el hábito más valioso de este tipo de trabajo.

Conviene decir claramente a qué estás renunciando. El refuerzo de plantilla, alquilarte por días para sentarte dentro del equipo de otro, es un oficio perfectamente respetable. Solo que no es microconsultoría. Te convierte en un subcontratado con pasos extra, al que se le paga por estar y no por los resultados, y que escala exactamente hasta donde llega su agenda. El entregable del microconsultor es un sistema, un documento, una capacidad o una decisión. Tu asistencia es accesoria.

Cobra por el agujero, no por el taladro. Sobre todo ahora que el taladro hace casi todo el trabajo.

Hay riesgos honestos. Un resultado cerrado significa que el desvío lo asumes tú si acotaste mal, y hay trabajo que de verdad no se puede delimitar de antemano. La respuesta no es volver a la tarifa por horas. Es acotar más pequeño. Si no puedes describir el resultado con seguridad, vende un descubrimiento de pago que produzca esa descripción y pon precio al resultado cuando ya puedas verlo. La incertidumbre es un motivo para encoger el primer encargo, nunca para descerrarlo.

Prueba esto con tu oferta actual. Reescribe cada línea que mencione días u horas como un sustantivo que el cliente poseerá al final. Cinco días de consultoría en IA se convierte en una lista ordenada de los seis flujos de trabajo que merece la pena automatizar, con un prototipo funcional del primero. Se lee mejor, se vende mejor y te compromete, sin hacer ruido, con algo de lo que de verdad puedes sentirte orgulloso. Tus horas nunca fueron el producto. Eran solo lo único que sabías contar.

La llamada de diagnóstico

La primera llamada con un posible cliente no es una presentación comercial. Es un diagnóstico. La mayoría de los consultores la desperdician explicando lo que hacen, cosa que el comprador podría haber leído en la web, en lugar de averiguar qué es lo que falla, cosa que quizá ni el propio comprador sepa del todo. El problema caro casi nunca aparece en la primera frase. Aparece hacia la pregunta doce, cuando ya has dejado de hablar.

Llega con una lista. Veinte preguntas es un buen número, aunque no las harás todas. Empieza por el trabajo, no por la tecnología: cuéntame la última vez que esto salió mal, quién lo tocó, cuánto tardó, cuánto costó, qué hicisteis en su lugar. Luego pasa a los bordes: qué habéis probado ya, quién tendría que aprobar un cambio, qué ocurre si nada cambia este trimestre. Solo al final pregunta por las herramientas, e incluso entonces pregunta qué usan, no qué quieren. La gente describe sus aspiraciones en términos de software. Describe sus problemas en términos de martes.

Claude resulta útil a ambos lados de la llamada. Antes, pégale lo que sabes del negocio, su material público y el sector, y pídele una lista de preguntas a medida, ordenada según la probabilidad de que cada una destape un problema costoso. Después, pégale tus notas o una transcripción, con permiso, y pídele un resumen estructurado: el problema que se presenta, el problema de fondo, de quién es, cuánto cuesta y qué microencargo lo resolvería. Ese resumen se convierte en la primera página de tu propuesta y, lo que es más útil, en lo que envías esa misma tarde para que el comprador lo corrija.

La corrección importa. Un comprador que edita tu resumen de su problema ha empezado a coescribir la propuesta. Ahora es dueño de una parte del diagnóstico, y la gente rara vez rechaza un diagnóstico que ha ayudado a escribir. Mantén el resumen breve, de una sola página, en su lenguaje y no en el tuyo. Si te descubres escribiendo apalancar o sinergia, pídele a Claude que lo reescriba con el vocabulario que el comprador usó en la llamada.

Presentar tu oferta en la primera llamada es como recetar antes de que el paciente se siente.

También tiene su arte cerrar la llamada. No termines ofreciendo una propuesta. Termina formulando el problema de vuelta, en una sola frase, y preguntando si lo has entendido bien. Si dicen que sí, cuéntales cómo sería un primer paso pequeño y cuándo puedes enviarlo. Si dicen que no, acabas de aprender algo mucho más valioso que una venta, y la llamada no ha terminado.

Pruébalo esta semana. Escribe tus veinte preguntas, ordenadas del trabajo a los bordes y de ahí a las herramientas, y guárdalas en una nota que puedas abrir en cualquier llamada. Después haz tu próxima conversación sin describir tus servicios hasta los últimos cinco minutos. Hablarás menos, aprenderás más y presupuestarás el problema correcto. El comprador te recordará como la persona que escuchaba, algo que en este mercado es una distinción sorprendentemente rara.

La auditoría de pago

La auditoría de IA de alcance cerrado es la mejor puerta de entrada que puede construir un microconsultor. Supone poco riesgo para el comprador, te la pagan entera, es lo bastante corta como para terminarla antes de que nadie pierda el interés y concluye con una hoja de ruta que tú estás en una posición inmejorable para ejecutar. Es una venta que fabrica la siguiente venta, siempre que la lleves bien.

La forma es sencilla. Durante una o dos semanas entrevistas a un puñado de personas, observas cómo fluye realmente el trabajo, revisas las herramientas y los datos en juego y produces una lista ordenada de oportunidades. Cada oportunidad lleva una breve descripción, una estimación honesta del valor, una estimación del esfuerzo, una nota sobre el riesgo y un microencargo recomendado para abordarla. Las dos o tres primeras están acotadas con tanta precisión que se pueden comprar directamente desde la página. El resto quedan aparcadas, a la vista, para que el cliente vea que no te limitas a venderle todo lo que encontraste.

Claude hace la auditoría más rápida sin hacerla más superficial. Las transcripciones de las entrevistas entran, con consentimiento, y salen convertidas en temas, citas y quejas recurrentes. Las descripciones de procesos se transforman en diagramas de flujo sencillos que puedes contrastar con quienes los describieron. Una hoja de cálculo de tareas se puede puntuar con una rúbrica que escribís juntos el cliente y tú. La síntesis que antes exigía días releyendo notas se convierte en una hora revisando y corrigiendo lo que redactó el modelo. Tu tiempo va a donde debe: al criterio sobre qué oportunidades son reales.

Sé estricto con lo que la auditoría no es. No es gratuita, porque las auditorías gratuitas se tratan como muestras y sus recomendaciones como opiniones. No es una presentación de estrategia, porque en una pequeña empresa nadie actúa a partir de una presentación de estrategia. Y no es indefinida. Fija el número de entrevistas, el número de oportunidades que vas a ordenar y la fecha de la presentación de resultados. Cuando el cliente te pida que eches un vistazo a un departamento más, sonríe y añádelo a la lista de cosas que podría cubrir el próximo encargo.

Una auditoría que no termina en una decisión no es más que una forma cara de sentirse moderno.

La presentación de resultados es donde la auditoría se gana el sueldo. Presenta la lista ordenada en directo, explica las tres primeras oportunidades y, si puedes, enseña un prototipo tosco de la primera, aunque sea un solo artefacto construido la noche anterior. Luego pregunta por cuál quieren empezar. No si quieren. Por cuál. La auditoría ha cumplido su función si el comprador sale de la reunión eligiendo entre tus próximos encargos en lugar de preguntándose si contratar alguno.

Para construir la tuya, escribe primero el entregable. Redacta un informe de auditoría de muestra para un cliente imaginario de tu sector: la tabla ordenada, las tres recomendaciones acotadas, la lista de aparcados. Después trabaja hacia atrás hasta las entrevistas y revisiones que necesitarías para rellenarlo con honradez. Ya tienes un producto, una plantilla y una idea bastante clara de lo que vendes. La mayoría de los consultores describen su auditoría. Muy pocos tienen una que puedan enseñar.

El sprint de dos semanas

Si la auditoría es la puerta de entrada, el sprint es la primera habitación. Dos semanas, un problema, un resultado que funciona. Es lo bastante largo como para entregar algo real y lo bastante corto como para que nadie necesite la aprobación del consejo, un proceso de compras o un comité de dirección. Y, sobre todo, es lo bastante corto como para que el impulso sobreviva. Los encargos largos no suelen fracasar por un mal trabajo. Fracasan porque la atención se apaga.

Dos semanas tienen un ritmo natural. El primer día es de accesos y arranque: credenciales, un responsable de decisiones con nombre y apellidos, una definición escrita de «terminado». La primera semana es para construir, en incrementos pequeños, con una demo al final. La segunda es para pulir, probar con casos reales y preparar el traspaso: el manual de operaciones, los prompts, un breve recorrido grabado, una sesión con la persona que va a hacerse cargo. El último día haces la demo de lo terminado, enseñas el cambio medido y propones lo siguiente.

Con Claude como socio de entrega, en dos semanas cabe una cantidad sorprendente de cosas. Una automatización que lee los documentos entrantes, extrae lo importante y redacta una respuesta para que la apruebe una persona. Una pequeña herramienta interna construida como prototipo de un solo archivo y luego reforzada. Una biblioteca de skills para las tareas de redacción recurrentes de un equipo. Un piloto de agentes funcionando sobre una muestra del trabajo real del mes pasado. Nada de esto es trivial, pero todo cabe, siempre que el alcance sea un problema y no tres.

Esa condición es toda la disciplina. El sprint vive o muere por la definición de «terminado» que escribes el primer día. Hazla concreta, comprobable y con las palabras del cliente: el equipo puede procesar una semana de facturas de proveedores con el asistente, y nueve de cada diez borradores no necesitan más que retoques ligeros. Evita adjetivos como robusto o fluido, que describen cómo te sientes tú y no lo que se puede comprobar. Si no puedes escribir una definición de «terminado» en dos frases, el sprint es demasiado grande. Pártelo.

Dos semanas no son un plazo. Son un recipiente, y los recipientes son lo que impide que las cosas se desparramen.

Habrá presión para estirarlo. Un cliente ve avances tempranos y pregunta si podrías ocuparte también de un proceso relacionado. La respuesta es sí, en el próximo sprint. Apúntalo, ponlo en la lista para la demo de cierre y sigue adelante. Un sprint que termina a tiempo con un alcance menor genera más confianza que uno que termina tarde con todo dentro.

Prueba a esbozar tres sprints que podrías vender mañana. Para cada uno, escribe el problema en una línea, la definición de «terminado» en dos y el paquete de traspaso en tres. Si alguno necesita más que eso, es un programa disfrazado de sprint. Encógelo hasta que quepa en una ficha. Pequeño, terminado y demostrado gana a grande, casi listo y explicado, absolutamente siempre.

Ponle nombre

Un servicio sin nombre es un favor. Uno con nombre es un producto con precio. Suena a capricho de marketing, y en parte lo es, pero se apoya en una verdad práctica sobre cómo piensan los compradores. La gente archiva las cosas por su nombre. Una ayudita con lo nuestro de la IA va al cajón mental de «varios», que es también donde los presupuestos van a morir. El Sprint de Triaje de la Bandeja de Entrada va a un cajón propio, junto a otras cosas que cuestan dinero y producen resultados.

Un nombre hace tres trabajos a la vez. Le dice al comprador qué va a recibir antes de que se lo expliques. Le permite repetírselo a otra persona, que es como viajan las recomendaciones. Y te pone límites a ti, porque en cuanto el encargo tiene nombre tiene forma, y las formas se resisten a esa lenta expansión que convierte un trabajo de alcance cerrado en uno indefinido. El Kit de Prompts para Atención al Cliente no puede convertirse discretamente en una migración del CRM. El nombre protestaría.

Los buenos nombres son llanos. Dicen qué hace la cosa, para quién y, a veces, cuánto dura. La Auditoría de Preparación para la IA. El Piloto de Agentes de Dos Semanas. El Sprint de Documentación de Políticas. El Taller de Claude para Equipos. Los nombres ingeniosos que necesitan explicación tiran por tierra el propósito. Si tienes que describir el nombre antes de poder describir el servicio, has creado un segundo problema. Deja los juegos de palabras para las entradas de tu blog.

Claude lo hace bastante bien, si le das unas instrucciones decentes. Dale el problema que resuelve el encargo, el comprador al que va dirigido, el entregable, la duración y tres nombres que ya te disgustan, y pídele veinte opciones llanas ordenadas por claridad. Luego di en voz alta las cinco mejores a alguien que no trabaje en tu campo. La que sea capaz de repetirte una hora después es la ganadora. Lo memorable es una prueba, no una sensación.

Si no pueden decírselo a su jefe, no pueden comprártelo.

Una vez que la cosa tiene nombre, dale una página. Una sola, con el problema, el entregable, el calendario, lo que aporta el cliente, lo que aportas tú y lo que suele venir después. No pongas precio en la página si tu mercado prefiere una conversación, pero deja claro que existe un precio y que es cerrado. Esa página se convierte en el enlace que envías tras una llamada de diagnóstico, en el adjunto de una propuesta y en lo que el comprador reenvía a la persona que firma. Vende más que tú.

Repasa tus tres últimos encargos esta semana. Ponle nombre a cada uno, como si lo hubieras vendido como producto. Luego fíjate en cuáles volverías a vender tal cual están descritos y cuáles querrías cambiar. Los que volverías a vender son tu catálogo. El resto fueron favores, lo cual está bien, pero deberías dejar de fingir que fueron estrategia.

Un sector, a fondo

Los generalistas compiten con todo el mundo. Los especialistas no compiten casi con nadie. Es un consejo antiguo, más antiguo que cualquiera de las herramientas de este libro, pero en la microconsultoría importa más que en casi cualquier otro trabajo, porque los encargos pequeños viven o mueren según la rapidez con que seas capaz de acotarlos. Un consultor que ya conoce un sector llega con medio trabajo de acotación hecho.

Piensa en la diferencia durante una llamada de diagnóstico. Un generalista le pregunta a una clínica dental cómo se reservan las citas y se pasa veinte minutos aprendiendo el vocabulario. Un especialista ya conoce el programa de reservas que probablemente usan, la normativa que regula los historiales de los pacientes, las tres tareas que se comen la tarde de la recepcionista y las razones por las que suelen fracasar los intentos de automatización anteriores. La primera pregunta del especialista es la decimoquinta del generalista. Esa ventaja de salida se traduce en una propuesta más afinada, un sprint más rápido y un cliente que se siente comprendido en lugar de interrogado.

Especializarte también afila tu oficio con Claude. Cada encargo en el mismo sector te enseña algo reutilizable: un prompt que domina la jerga, una skill que conoce las normas de cumplimiento, un conjunto de datos semilla que parece hecho de registros reales, una lista de comprobación con las preguntas que importan. Tras cinco encargos tienes una biblioteca ajustada a un tipo de cliente, y el sexto encargo parte de esa biblioteca y no de una página en blanco. Tus márgenes mejoran, tu calidad mejora y tus propuestas empiezan a sonar como si las hubiera escrito alguien que ya ha hecho esto antes. Porque así es.

Elegir un sector es menos místico de lo que la gente cree. Busca uno en el que ya entiendas el trabajo, en el que las empresas sean lo bastante pequeñas como para comprar sin comités y en el que los documentos, los mensajes y las decisiones repetitivas ocupen buena parte de la jornada. Esa última prueba importa, porque es ahí donde los modelos de lenguaje se ganan el pan. Despachos de abogados, inmobiliarias, gestorías y asesorías, ONG, clínicas, oficios y pequeñas editoriales encajan. Elige uno del que puedas soportar hablar durante años.

El oro está en los nichos, como dice el refrán. Y también, con más fiabilidad, el trabajo recurrente.

El miedo es que especializarse encoja el mercado. En la práctica ocurre lo contrario, porque el especialista se convierte en la llamada obvia, y las llamadas obvias reciben recomendaciones desde dentro del sector, donde la gente habla entre sí constantemente. Siempre puedes aceptar algún trabajo interesante fuera de tu carril. Simplemente dejas de necesitarlo.

Prueba esto como ejercicio, no como compromiso. Elige un sector y dedica una hora con Claude a montar un dosier sobre él: la empresa típica, su software, su normativa, sus dolores recurrentes, su vocabulario. Luego escribe tres microencargos con nombre solo para ese sector. Si salen con facilidad, puede que hayas encontrado tu carril. Si se notan forzados, prueba con otro. La cuestión no es encontrar el nicho perfecto. Es dejar de ser un poquito útil para todo el mundo.

Convierte en producto lo repetible

La tercera vez que construyes lo mismo, deja de ser un proyecto y se convierte en un producto. La primera vez estabas aprendiendo. La segunda, recordando. La tercera, si sigues empezando desde una página en blanco, simplemente te niegas a ver un patrón. La microconsultoría premia a quienes se dan cuenta.

Convertir en producto no significa construir software. Significa transformar un encargo que se repite en uno repetible: una descripción fija, un conjunto estándar de insumos, un entregable de plantilla, una biblioteca de prompts y skills que hacen la mayor parte del trabajo pesado y una lista de comprobación que te dice qué hacer cada día del sprint. El cliente compra el mismo resultado con nombre. Tú lo entregas con una fracción del esfuerzo original, al mismo precio y con mejor calidad, porque cada encargo anterior ha limado una arista.

Claude es la razón de que esto sea ahora realista para alguien que trabaja solo. En el viejo mundo, convertir en producto un servicio de consultoría significaba contratar a júniors y escribir manuales de procedimiento que iban a ignorar. Ahora el manual de procedimiento puede ser una skill que se carga sola cuando hace falta, las plantillas se pueden generar a partir de datos estructurados y el análisis repetitivo puede ejecutarlo un agente que sigue instrucciones que escribiste una vez y fuiste refinando a lo largo de muchas ejecuciones. Los júniors, en otras palabras, son las herramientas, y las herramientas sí se leen el manual.

El truco es convertir en producto a partir de la evidencia, no de la esperanza. No inventes un producto para luego salir a buscar clientes que lo quieran. Mira lo que los clientes ya te han pagado, encuentra el encargo que has entregado más veces y escribe lo que hiciste, paso a paso, mientras lo tienes fresco. Ese texto es el primer borrador del producto. Cada entrega posterior lo refina. En un puñado de ejecuciones tienes algo que, en principio, podrías pasarle a un colega competente.

Un proceso que puedes describir es un proceso que puedes mejorar. Un proceso que solo sabes ejecutar no es más que una costumbre con factura.

Ojo con una trampa. Los servicios convertidos en producto pueden volverse rígidos, y los servicios rígidos empiezan a sentarles mal a los clientes. Reserva un espacio pequeño y explícito para la personalización en cada encargo, quizá un día de trabajo a medida dentro de un marco fijo, y sé sincero cuando el problema de un cliente no encaje con el producto. Recomendar otra cosa, o nada en absoluto, genera más confianza que meter a la fuerza un encargo cuadrado en un negocio redondo.

Esta semana, encuentra tu encargo más repetido y escribe su manual de jugadas: insumos, pasos, prompts, resultados, comprobaciones, traspaso. Guarda los prompts y las plantillas donde puedas encontrarlos en diez segundos la próxima vez. Y luego véndelo otra vez. La cuarta entrega será más rápida que la tercera, y la quinta más todavía. Esa curva es todo el argumento económico del trabajo pequeño, curvándose en silencio a tu favor.

Del piloto a la iguala

Un piloto que termina limpiamente sin nada que mantener es un piloto mal diseñado. No es cinismo hacia los clientes. Es reconocer que los sistemas de IA útiles necesitan cuidados: los prompts se desvían a medida que cambia el negocio, los modelos mejoran y abren nuevas opciones, aparecen casos límite nuevos y alguien tiene que darse cuenta cuando la calidad baja. Si el piloto demuestra su valor, el siguiente paso natural es el cuidado continuo. Diséñalo así desde el principio.

El trabajo de diseño se hace antes de escribir una sola línea de código. Cuando acotes un piloto, pregunta qué tendrá que ocurrir después de que salga bien. ¿Quién vigilará los resultados? ¿Quién actualizará los prompts cuando cambie la gama de productos? ¿Quién revisará cada mes el conjunto de evaluación y añadirá casos nuevos? ¿Quién probará el modelo mejorado cuando llegue? En la mayoría de las pequeñas empresas la respuesta sincera es nadie, y esa respuesta es la iguala mensual, ofrecida abiertamente y no sacada de la manga como una sorpresa al final.

Sé explícito con esto en la propuesta. Describe el piloto, su definición de «terminado» y su resultado medido. Luego describe, en un párrafo breve, qué implicaría mantenerlo sano y qué cubriría un acuerdo mensual. Todavía no estás vendiendo la iguala. Te estás asegurando de que, cuando el piloto tenga éxito, a nadie le sorprenda que el éxito necesite mantenimiento. Los compradores agradecen que les cuenten pronto la forma completa del compromiso.

La iguala en sí debe ser pequeña y concreta, como todo lo demás en este libro. Una revisión mensual de una muestra de resultados frente al conjunto de evaluación. Actualizaciones de prompts y skills cuando haga falta. Un breve informe escrito que muestre qué hizo el sistema, qué cambió y qué recomiendas. Un número fijo de pequeñas mejoras al mes. Un plazo de respuesta ante problemas. Evita la iguala vaga que promete soporte continuo, porque las igualas vagas se cancelan en la primera revisión presupuestaria, cuando nadie recuerda para qué servían.

Los pilotos demuestran que algo funciona una vez. Las igualas demuestran que sigue funcionando, que es la parte que el comprador necesitaba de verdad.

No todos los pilotos deben convertirse en igualas. Algunos sistemas son lo bastante sencillos como para que un buen manual de operaciones y una persona formada que haga de referente sean todo lo que el cliente necesita, y recomendarlo es honesto y, de vez en cuando, excelente para las recomendaciones. Pero debes decidirlo deliberadamente, al final, en función de lo que necesita el sistema, y no dejarte llevar porque nunca pensaste en lo que venía después.

Pruébalo en tu próxima propuesta. Añade una sección titulada después del piloto con tres frases: qué necesitará el sistema, quién podría proporcionarlo y qué incluiría un pequeño acuerdo mensual. Fíjate en cómo cambia la conversación. El comprador empieza a ver el piloto como el comienzo de algo, y no como un experimento que podría abandonar sin hacer ruido. Que es, en la mayoría de los pilotos de IA de la mayoría de las empresas, exactamente lo que ocurre en caso contrario.

La escalera de ofertas

Junta los capítulos anteriores y obtienes una escalera. Abajo del todo, algo gratuito y pequeño: un análisis exprés, una herramienta, un artículo útil, una breve llamada de diagnóstico. Encima, la auditoría de pago, que encuentra el problema. Encima de esta, el sprint de desarrollo, que lo arregla. Arriba del todo, la iguala mensual, que lo mantiene arreglado y lo mejora. Todo cliente entra por abajo y sube, y nunca más tienes que inventarte una propuesta desde cero.

La escalera resuelve un problema que la mayoría de los consultores no saben que tienen: cada venta es una negociación a medida. Sin escalera, cada posible cliente recibe una propuesta personalizada, cada propuesta lleva un día escribirla y cada una es una nueva conjetura sobre lo que el comprador podría aceptar. Con escalera, la pregunta es simplemente en qué peldaño debería empezar. Un comprador que ya conoce su problema puede saltarse la auditoría. Uno prudente puede empezar con un análisis exprés. La estructura es fija; el punto de entrada se adapta.

Cada peldaño debe hacer que el siguiente parezca inevitable. El análisis exprés termina mostrando lo que encontraría una auditoría de verdad. La auditoría termina con una lista ordenada cuyo primer elemento es un sprint acotado. El sprint termina con un sistema que funciona y una descripción clara de lo que implica mantenerlo sano. Nada de esto es manipulador, siempre que cada peldaño tenga valor real por sí mismo. Un cliente que se detenga en la auditoría debería sentir igualmente que su dinero ha estado bien invertido. La mayoría no se detendrá, porque habrá visto cómo es el paso siguiente.

Tu catálogo de microencargos encaja limpiamente en la escalera. Las sesiones de formación y los kits de prompts suelen situarse junto a la auditoría como primeras compras pequeñas y de bajo riesgo. Los arreglos de flujos de trabajo, los sprints de documentación y los pilotos de agentes son sprints de desarrollo. La monitorización, las revisiones de evaluación y la mejora continua son trabajo de iguala. Asigna cada oferta con nombre a un peldaño y verás de un vistazo dónde están tus huecos. Muchos consultores descubren que tienen cinco maneras de empezar y ninguna de continuar.

Una escalera no es más que una secuencia de pequeños síes ordenados de forma que cada uno facilite el siguiente.

Dibuja la tuya esta semana. Cuatro peldaños, ofertas con nombre en cada uno y una sola frase que explique cómo cada peldaño lleva al siguiente. Luego mira tus diez últimos clientes y marca dónde entró cada uno y dónde se detuvo. Los puntos donde los clientes dejan de subir son aquellos en los que tus ofertas son más débiles, o donde todavía no se ha construido el puente de un peldaño al siguiente. Arregla el puente antes de añadir más peldaños.

Esta es la forma que el resto del libro va rellenando. Las partes de oficio te enseñan a entregar cada peldaño rápidamente con Claude. Las partes de entrega y de precios te enseñan a ejecutar cada peldaño con limpieza. Las partes de prueba te enseñan a convertir cada peldaño terminado en la razón del siguiente. La escalera no es la estrategia. Es el marco que permite que el trabajo pequeño sume algo grande.

Da instrucciones como un buen cliente

Todo consultor sabe cómo es un mal encargo de cliente. Necesitamos algo moderno para la web. Ya lo sabrás cuando lo veas. Y después la mayoría de los consultores se dan la vuelta y le escriben exactamente ese encargo a un modelo. Escríbeme una propuesta para este cliente. El modelo, como el diseñador júnior antes que él, no es adivino. Rellena los huecos con promedios, y promedios es lo que te devuelve.

La solución es darle instrucciones a Claude como te gustaría que los clientes te las dieran a ti. Bastan cuatro partes. Contexto: para quién es el trabajo, en qué situación están, qué se ha probado ya. Tarea: lo único que quieres que se haga, formulado como un verbo. Formato: con qué forma debe llegar la respuesta, desde la extensión hasta la estructura y el tono. Control: cómo sabréis tú y el modelo que el resultado es bueno. Esa última parte es la que casi todo el mundo omite, y es la que más cambia el resultado.

Esta es la diferencia en la práctica. Redacta un correo de seguimiento tras una llamada de diagnóstico es un deseo. Ahora prueba esto: Contexto: hago encargos de IA de alcance cerrado para pequeñas asesorías contables. Ayer hablé con un despacho de dos socios cuyo cierre de mes se retrasa por las notas de conciliación manuales. Tarea: redacta un correo de seguimiento que resuma su problema con sus palabras y proponga una auditoría de pago como primer paso. Formato: menos de doscientas palabras, español llano, sin viñetas, una pregunta clara al final. Control: un socio debería poder leerlo en menos de un minuto y responder con un sí o con una corrección. La segunda versión tarda noventa segundos más en escribirse y produce algo que quizá llegues a enviar.

El hábito de fondo es la soltura: aprender a sustituir diez turnos de aclaraciones por un único encargo denso e inequívoco. Al principio darás instrucciones escuetas y corregirás a menudo, y no pasa nada. Con el tiempo, fíjate en qué correcciones repites una y otra vez y trasládalas al encargo. Más corto, menos formal, deja de usar la palabra apalancar, incluye un siguiente paso. Eso no son ediciones. Son partes del encargo que faltaban y que llegan tarde.

Un encargo de una sola pasada es más lento de escribir y muchísimo más rápido de terminar.

Esto importa más a los consultores que a la mayoría de los usuarios, porque tus encargos a menudo son el entregable. El prompt que le das al equipo de soporte de un cliente, las instrucciones dentro de una skill, el prompt de sistema de un piloto de agentes: cada uno es un encargo del que otra persona dependerá sin que tú estés en la sala. Si no sabes darle buenas instrucciones a un modelo en tu propio trabajo, no puedes enseñar a hacerlo al equipo de un cliente, y desde luego no puedes venderle un kit de prompts.

Pruébalo hoy con una tarea que repitas. Escribe el encargo en cuatro partes, ejecútalo y anota cada corrección que todavía tengas que hacer. Incorpora cada corrección al encargo y vuelve a ejecutarlo. Cuando el primer borrador salga bien, guarda el encargo en un sitio donde puedas encontrarlo. Acabas de crear tu primer activo, y te ha llevado menos tiempo que las correcciones que ibas a hacer de todos modos.

Rol, tarea, formato

Si el encargo en cuatro partes te parece demasiado para una pregunta rápida, hay un esqueleto más pequeño que arregla por sí solo la mayoría de los malos prompts. Tres líneas. Quién responde, qué debe hacer y con qué forma llega la respuesta. Nada más en la mayoría de los prompts sostiene peso, y una cantidad sorprendente de lo que la gente añade estorba activamente.

El rol fija la pericia y el registro. Eres un consultor de operaciones que trabaja con pequeñas empresas de logística te da un vocabulario, unos supuestos y unas prioridades distintos de eres un asistente servicial. El rol no es magia y no hace que el modelo sepa cosas que no sabe. Lo que sí hace es decirle cuál de las muchas formas posibles de responder es la que quieres, y eso es la mayor parte de la batalla.

La tarea es el verbo. Resume, ordena, redacta, critica, extrae, compara, reescribe. Un verbo por prompt, idealmente, con su complemento dicho con claridad. Ordena estas doce ideas de flujos de trabajo según el tiempo que probablemente ahorren a una oficina de cinco personas es una tarea. Échales un ojo y dime qué te parecen es un estado de ánimo. Cuando un prompt contiene tres verbos, el modelo suele hacer bien el primero, aceptablemente el segundo y de pasada el tercero, exactamente en el orden que menos querías.

El formato es la forma. Una tabla con columnas con nombre. Tres párrafos. Una sola frase. Un objeto JSON con claves especificadas. Texto plano sin markdown. Nómbralo y el modelo deja de improvisar a su alrededor. Omítelo y obtendrás lo que el modelo considere una respuesta típica a preguntas como la tuya, que suele ser un encabezado, unas viñetas y una frase de cierre muy animada ofreciendo más ayuda.

Quién, qué, con qué forma. Si no recuerdas nada más sobre prompts, recuerda el orden.

En microconsultoría, este esqueleto es además una herramienta didáctica. Cuando das una sesión de formación al equipo de un cliente, es lo primero que les entregas, porque es lo bastante breve como para recordarlo y lo bastante potente como para cambiar los resultados de inmediato. Quienes llevan meses tecleando preguntas sueltas en un chat se sorprenden a ojos vistas cuando tres líneas producen algo que de verdad usarían. Esa sorpresa vale muchísimo en un taller. Es el momento en que un equipo escéptico decide que quizá merezca la pena escucharte.

También te da un diagnóstico rápido para los prompts ajenos. Cuando un cliente te enseñe un prompt que no funciona, revisa las tres líneas. Normalmente falta una, casi siempre el formato, a veces el rol y de vez en cuando la propia tarea, enterrada bajo párrafos de antecedentes. Restituye la línea que falta y el prompt a menudo se arregla solo. Parecerás más listo de lo que eres, que es un resultado perfectamente aceptable para un consultor.

Esta semana, toma cinco prompts que uses con regularidad y reescribe cada uno en tres líneas. Ejecuta ambas versiones una junto a otra. Quédate con la ganadora. Para el trabajo diario rara vez necesitarás más que este esqueleto, y cuando lo necesites, sabrás exactamente qué línea ampliar.

Enseña tres ejemplos

El estilo se demuestra antes de lo que se describe. Puedes pasarte un párrafo explicando que quieres un texto cálido pero profesional, seguro pero no arrogante, conciso pero no seco, y recibir algo que no es nada de eso, o que lo es todo en las proporciones equivocadas. O puedes pegar tres ejemplos de textos que te gustan y decir imita estos. El segundo enfoque suele ganar, y reduce una negociación de cinco turnos a uno solo.

La razón es sencilla. Los adjetivos son ambiguos; los ejemplos, no. Cálido significa una cosa para ti y otra para un modelo que promedia todo lo que ha leído. Un ejemplo lleva consigo el tono, la extensión, la estructura, el vocabulario y el ritmo, todo a la vez, sin que nadie tenga que nombrarlos. El modelo es muy bueno detectando patrones en los ejemplos. Convirtiendo adjetivos en patrones es solo aceptable.

Tres es un número útil. Un solo ejemplo invita a la copia servil: el modelo reproduce su estructura e incluso sus frases concretas. Dos muestran un patrón, pero pueden leerse como una pareja de opuestos. Tres permiten al modelo triangular lo que tienen en común y generalizar a partir de ello. Elige ejemplos que varíen en contenido pero compartan las cualidades que te importan. Tres correos a clientes sobre temas distintos, todos con la voz adecuada. Tres resúmenes de documentos distintos, todos con la extensión y la estructura correctas.

Aquí es donde la microconsultoría se pone interesante, porque reunir ejemplos es en sí mismo un servicio. La mayoría de las empresas tienen un estilo de la casa que solo vive en la cabeza de sus mejores profesionales. Cuando haces un encargo de kit de prompts o un sprint de documentación, parte del trabajo consiste en encontrar los ejemplos: la propuesta que ganó, la respuesta a una queja que le dio la vuelta a un cliente, el informe que el consejo sí se leyó. Reunirlos, anotar por qué funciona cada uno e incorporarlos a prompts y skills tiene un valor real, y es un trabajo que el cliente no podría hacer fácilmente solo, porque está demasiado cerca.

Un buen ejemplo es una guía de estilo que no se puede malinterpretar.

Hay dos advertencias. La primera: los ejemplos transmiten sus defectos con la misma fidelidad que sus virtudes. Si tus tres muestras empiezan con la misma frase gastada, también empezará así todo lo que escriba el modelo. Lee tus ejemplos con ojo crítico antes de usarlos y edítalos si hace falta. La segunda: cuidado con el material confidencial. Los ejemplos de un cliente usados en los prompts de ese mismo cliente están bien, con su consentimiento. Los ejemplos de un cliente trasladados al trabajo de otro, no. Mantén las bibliotecas separadas.

Prueba esto con un tipo de texto que produzcas a menudo. Busca tres buenos ejemplos pasados, pégalos con una breve instrucción para que imite su voz, su estructura y su extensión, y dale al modelo un tema nuevo. Compara el resultado con lo que obtienes a partir de una descripción sin más. Después guarda los tres ejemplos junto al prompt, en el mismo archivo, para que la próxima vez que necesites ese tipo de texto partas de una demostración y no de adjetivos.

Ejemplos negativos

Mostrarle a un modelo lo que quieres es poderoso. Mostrarle lo que no quieres, justo al lado de lo que sí, suele serlo todavía más. Un solo mal ejemplo junto a un solo buen ejemplo enseña la frontera de una pasada, de un modo que rara vez consigue una página de instrucciones sobre el tono. El contraste hace la explicación.

Piensa en cómo aprendiste a escribir bien, si es que lo hiciste. Probablemente alguien te enseñó un párrafo torpe y luego una versión mejor del mismo párrafo, y viste la diferencia al instante. Eso es lo que hace un ejemplo negativo por un modelo. No se limita a decir evita la jerga; muestra una frase cargada de jerga y una frase llana que dice lo mismo, y la línea que las separa se vuelve evidente.

La técnica funciona mejor cuando el mal ejemplo es verosímil. Un ejemplo deliberadamente espantoso no enseña nada, porque el modelo nunca lo habría producido de todos modos. El ejemplo negativo útil es el que el modelo tiende a producir por defecto: el arranque excesivamente entusiasta, la conclusión llena de matices, el resumen que repite la pregunta, el correo que pide perdón tres veces. Apunta el resultado que no paras de recibir y no quieres, etiquétalo claramente como lo que hay que evitar y pon a su lado la versión que sí quieres.

Para los consultores, los ejemplos negativos resultan especialmente útiles en trabajos regulados o delicados. Un prompt para una empresa de servicios financieros puede mostrar un ejemplo de respuesta que se desliza hacia el asesoramiento personal y otro que se mantiene a salvo en el lado correcto de la línea. Un prompt para la comunicación con los socios de una ONG puede mostrar un ejemplo que suena a hacer sentir culpable y otro que suena agradecido. Estas parejas transmiten a la vez el cumplimiento normativo y el tono, y a los clientes les resultan mucho más fáciles de revisar y aprobar que las reglas abstractas.

Un solo mal ejemplo, etiquetado con honradez, vale más que una página de instrucciones escritas con esperanza.

Hay un matiz. No dejes que los ejemplos negativos dominen el prompt. Con demasiados, el modelo empieza a orientarse hacia lo que debe evitar en lugar de hacia lo que debe producir, y eso puede volver el resultado envarado y timorato. Uno o dos contrastes claros suelen bastar. Si te descubres enumerando diez cosas que no hay que hacer, probablemente el encargo positivo se ha quedado corto. Refuerza eso en su lugar.

También es un buen ejercicio para una sesión de formación. Pide al equipo de un cliente que traiga un resultado que no les gustara. Juntos, escribid una versión buena y breve a su lado, añadid las dos al prompt como pareja etiquetada y volved a ejecutarlo. La mejora suele ser inmediata, y el equipo aprende más en esos diez minutos que en una hora de diapositivas sobre ingeniería de prompts.

Pruébalo esta semana con tu prompt más tozudo, ese que siempre produce algo ligeramente desviado. Pega el resultado desviado, etiquétalo así no, escribe la versión que querías, etiquétala así sí y vuelve a ejecutarlo. Las fronteras se respetan mejor cuando alguien las ha dibujado. Los modelos no son una excepción.

Acota la salida

Un modelo sin restricciones escribe un ensayo. Uno con restricciones escribe algo que puedes usar. La diferencia importa muchísimo en el trabajo de consultoría, porque gran parte de lo que construyes implica que la salida del modelo vaya a algún sitio que no son los ojos de una persona: a una hoja de cálculo, a un sistema de incidencias, a una base de datos, al siguiente paso de un flujo automatizado. Los ensayos no caben en las celdas de una hoja de cálculo. Las salidas estructuradas, sí.

La restricción empieza por nombrar el formato con precisión. No dame una lista, sino devuelve una tabla con columnas para tarea, responsable, frecuencia y minutos estimados por semana. No resume en JSON, sino devuelve un objeto JSON con las claves category, urgency y suggested_reply, donde urgency es low, medium o high. Cuanto más precisa sea la forma que nombres, menos tendrá que adivinar el modelo, y cuanto menos adivine, con más fiabilidad funcionarán tus pasos posteriores.

Restringir también significa limitar lo que se permite dentro de la forma. Especifica los valores permitidos para las categorías. Fija longitudes máximas. Di qué hacer cuando falta información: devolver null, devolver la palabra unknown u omitir el campo. Los modelos están deseando agradar, y un modelo deseoso de agradar al que se le pide rellenar un campo del que no tiene información a veces se inventará algo verosímil. Decirle explícitamente cómo señalar no lo sé es una de las líneas más valiosas que puedes añadir a un prompt de producción.

Para cualquier cosa que alimente software, ve más allá. Cuando la plataforma sobre la que construyes admita salidas estructuradas o definiciones de herramientas con un esquema, úsalas, porque un esquema que impone el sistema es más fuerte que uno descrito en prosa. Y luego valida igualmente lo que vuelve. Un pequeño script que compruebe que la salida coincide con la forma esperada, y que reintente o la marque cuando no sea así, te librará de esa respuesta malformada de cada cien que, de lo contrario, rompería el proceso de un cliente en el momento más inoportuno.

La prosa es para las personas. La estructura, para las canalizaciones. Sabe para cuál estás escribiendo.

Esta es la bisagra entre un prompt que impresiona en una demo y un sistema que sobrevive en producción. Muchos primeros pilotos de IA fracasan no porque el criterio del modelo fuera pobre, sino porque sus salidas eran incoherentes en la forma. Un día un campo llegaba con otro nombre. Una categoría se escribía de otra manera. Un resumen ocupaba tres párrafos cuando la interfaz tenía sitio para una línea. Nada de eso son problemas de inteligencia. Son problemas de restricción, y son totalmente evitables.

Esta semana, mira un flujo de trabajo que estés construyendo o planeando y pregúntate adónde va a continuación la salida del modelo. Para cada paso, apunta la forma exacta que necesita el paso siguiente y luego pon esa forma, con los valores permitidos y las reglas para los datos que falten, dentro del prompt. Añade una comprobación de validación. Es un trabajo poco glamuroso. Y es también la razón de que tus sistemas sigan funcionando cuando has dejado de vigilarlos, que es el único tipo por el que un cliente debería pagar.

Que piense primero

En los problemas difíciles, la calidad sale del bucle, no del primer intento. Pídele a un modelo una respuesta de inmediato y obtendrás su primera ocurrencia, servida con aplomo. Pídele que razone primero el problema, luego redacte una respuesta, después critique el borrador frente al objetivo original y lo revise, y normalmente obtendrás algo claramente mejor. El bucle te cuesta una línea o dos en el prompt. A menudo te ahorra una hora de ediciones.

Los modelos Claude actuales pueden razonar por su cuenta antes de responder, y cuando el pensamiento extendido está disponible merece la pena usarlo para tareas realmente difíciles. Pero también puedes dar forma explícita al bucle, y en consultoría a menudo deberías, porque quieres que el razonamiento sea visible. Antes de recomendar qué flujo de trabajo automatizar primero, enumera los factores que importan para este cliente, sopesa cada candidato frente a ellos y luego da tu recomendación y el mayor riesgo que la amenaza. Ese prompt produce una recomendación y el razonamiento que la sostiene, que es lo que un cliente necesita de verdad para tomar una decisión.

El paso de la crítica es el que la gente se salta. Tras el borrador, pídele al modelo que lo revise frente al encargo: ¿responde a la pregunta planteada?, ¿encaja con el formato?, ¿hace alguna afirmación que no pueda respaldar?, ¿qué objetaría un lector escéptico? Después pide una versión revisada. Te sorprenderá lo a menudo que la crítica detecta algo real: una restricción olvidada, una suposición presentada como un hecho, una recomendación que contradice algo del material de partida.

Este patrón es especialmente útil cuando hay más en juego que un borrador rápido. Una recomendación de auditoría sobre la que un cliente va a actuar. El resumen de una cláusula contractual. Una lista ordenada de opciones con dinero en juego según la elección. En cada caso, el bucle adicional es un seguro barato. No sustituye a tu revisión, pero significa que la versión que revisas ya ha sobrevivido a una ronda de escrutinio, de modo que tu atención se dirige a los problemas sutiles y no a los evidentes.

La primera respuesta es un borrador. Los modelos lo saben. Ayuda que tú también lo sepas.

No abuses. Una petición para reformatear una tabla no necesita una fase de razonamiento, y pedirla solo hace la respuesta más lenta y más larga. Reserva el bucle completo para tareas en las que una respuesta equivocada costaría algo, o en las que la respuesta correcta depende de sopesar varios factores. Para transformaciones sencillas, bastan una instrucción clara y un formato acotado.

En el sistema de un cliente, este bucle puede construirse como pasos separados en lugar de como un único prompt largo: una llamada razona y redacta, una segunda critica frente a una rúbrica, una tercera revisa. Eso hace que cada paso sea más fácil de probar y mejorar por separado, y te da un lugar donde poner un punto de control humano si el trabajo lo requiere. Esta semana, elige una tarea con forma de decisión que le pases a Claude y añádele el bucle de manera explícita. Compara el antes y el después. Pensar primero no es más lento. Solo traslada la lentitud al sitio que le corresponde.

Pide la rúbrica

He aquí una jugada que parece ligeramente al revés y que funciona notablemente bien. Antes de que el modelo responda, pídele que escriba los criterios de corrección. ¿Qué incluiría una respuesta excelente a esta tarea? ¿En qué fallaría una floja? Luego deja que responda, que califique su propia respuesta según esa rúbrica y que la reescriba hasta que obtuviera la nota máxima. El modelo se convierte en su propio examinador, con los criterios escritos antes del examen y no después.

¿Por qué ayuda? Porque escribir una rúbrica obliga al modelo a hacer explícitos los requisitos ocultos de una tarea. Una petición para escribir una actualización de proyecto para un cliente tiene criterios tácitos: debe empezar por lo que ha cambiado, cuantificar el avance, señalar los riesgos con honradez, pedir las decisiones necesarias y ser breve. En cierto sentido el modelo sabe todo esto, pero no necesariamente lo aplica todo en una sola pasada. Escribir la rúbrica hace aflorar los criterios; calificar con ella los aplica.

También puedes escribir la rúbrica tú mismo o, mejor aún, con el cliente. Aquí es donde la técnica se convierte en una herramienta de consultoría. En un piloto de agentes o en un encargo de kit de prompts, siéntate con la persona que va a juzgar el resultado y pregúntale qué hace que uno sea bueno. Apunta sus respuestas como rúbrica, con sus palabras. Luego incorpora esa rúbrica al prompt y al proceso de evaluación. De repente, los estándares tácitos del cliente son explícitos, el modelo tiene que cumplirlos y las pruebas de aceptación tienen una base que todo el mundo acordó de antemano.

Una rúbrica también hace medible la mejora. Si ejecutas veinte casos de prueba y puntúas cada uno con los mismos cinco criterios, puedes ver exactamente dónde flojea el sistema. Quizá siempre cuantifica el avance pero rara vez señala los riesgos. Eso te dice qué parte del prompt reforzar. Sin rúbrica te quedas con la sensación general de que las salidas están más o menos bien, que es un sentimiento y no un hallazgo.

Si no puedes poner por escrito cómo es lo bueno, ni tú ni el modelo lo produciréis con fiabilidad.

Una advertencia: los modelos que califican su propio trabajo tienden a ser generosos. La autoevaluación es un paso útil, no un veredicto final. Para todo lo importante, haz que una pasada independiente califique el trabajo, idealmente con un contexto nuevo que no tenga apego al borrador, y mantén a una persona revisando una muestra. La rúbrica hace que ambas revisiones sean más rápidas y más justas, pero no las sustituye.

Pruébalo esta semana con un texto recurrente. Pídele a Claude que escriba una rúbrica de cinco puntos para una versión excelente, edítala hasta que estés de acuerdo con ella y luego haz que el modelo redacte, puntúe y revise según ella. Guarda la rúbrica junto al prompt. Descubrirás que la reutilizas más que el propio prompt, porque una buena definición de calidad sobrevive a cualquier forma concreta de pedirla.

Empieza tú la respuesta

Empezar la respuesta por el modelo dirige su formato con más fuerza que casi cualquier instrucción. Escribe tú mismo el arranque de la respuesta, la primera llave de un objeto JSON, el primer encabezado de un informe, la primera celda de una tabla, y el modelo continúa con esa forma. Es una jugada pequeña con un efecto grande, y uno de los trucos más antiguos del trabajo con modelos de lenguaje.

El principio es que los modelos continúan patrones. Una instrucción es una petición; una respuesta empezada es un patrón ya en marcha. Si la respuesta ya comienza con una llave de apertura, el modelo tiende con fuerza a terminar el JSON en lugar de anteponerle una frase simpática sobre lo que está a punto de hacer. Si la respuesta empieza con un encabezado concreto, el modelo continúa con contenido bajo ese encabezado en lugar de inventarse su propia estructura.

Cómo lo uses depende de dónde trabajes. Cuando construyes sobre la API, en muchas configuraciones puedes suministrar directamente el inicio del turno del asistente, lo que hace el prerrelleno muy preciso. En una interfaz de chat lo aproximas mostrando el arranque que quieres: empieza tu respuesta con la línea Resumen para los socios: y continúa a partir de ahí. En una plantilla o en una skill puedes incluir el esqueleto de la salida, con la primera sección parcialmente rellena, y pedir al modelo que la complete. Las tres opciones empujan la misma tendencia.

El prerrelleno es especialmente útil para eliminar los preámbulos que se cuelan en las salidas de los modelos. Ya sabes cuáles: ¡Por supuesto! Aquí tienes un resumen del documento que me has proporcionado. Inofensivo en un chat, irritante en un entregable para un cliente y directamente roto cuando la salida alimenta un sistema que espera datos. Empezar la respuesta elimina el hueco donde iría el preámbulo. Combinado con una restricción de formato clara, suele bastar para obtener una salida limpia cada vez.

Si quieres que la respuesta empiece en un sitio concreto, empiézala tú ahí.

Tiene su pequeño arte. Si prerrellenas demasiado, restringes el contenido además de la forma, a veces de maneras que no pretendías. Prerrellena solo la apertura estructural, la llave, el encabezado o la primera etiqueta, y deja la sustancia al modelo. Ten en cuenta también que algunas funciones y configuraciones limitan o cambian el funcionamiento del prerrelleno, así que si una técnica que funcionaba en un sitio se comporta de otra manera en otro, consulta la documentación actual en lugar de dar por hecho que el modelo se ha vuelto testarudo.

Para los consultores, las plantillas prerrellenadas son excelentes entregables por derecho propio. El equipo de un cliente puede abrir un prompt guardado que ya contiene el esqueleto del informe que necesita, rellenar los detalles y obtener un documento coherente cada vez. Esa coherencia suele ser lo que el cliente valoraba de verdad, más que cualquier ingeniosidad concreta del prompt.

Esta semana, elige una salida cuyo formato no deje de divagar y empieza tú la respuesta. Fíjate en cuánta de tu instrucción anterior se vuelve innecesaria. A veces la forma más corta de decir lo que quieres es, sencillamente, empezarlo.

Los prompts son activos

Un prompt que usas veinte veces no es un mensaje. Es infraestructura. Merece un nombre, una versión, un hogar y una nota que explique para qué sirve y cómo sabes que funciona. La mayoría de la gente trata sus mejores prompts como trata sus ocurrencias brillantes en una cena: pronunciadas una vez, recordadas vagamente, imposibles de reproducir. Para un consultor, eso es dinero que se queda sobre la mesa, una y otra vez.

Empieza por ponerles nombre a las cosas. Resumen de llamada de diagnóstico, puntuador de oportunidades de auditoría, redactor de manuales de operaciones, primer borrador de caso de éxito. Un nombre te permite encontrar un prompt, referirte a él y darte cuenta cuando tienes dos que hacen lo mismo. Luego dale a cada uno un hogar: una carpeta en un repositorio, una sección de una aplicación de notas, un proyecto en Claude donde quede como material de referencia. La prueba es si puedes encontrar el prompt adecuado en menos de diez segundos cuando lo necesitas. Si no puedes, en realidad no existe.

El control de versiones importa más de lo que parece. Los prompts mejoran con el uso. Retocas una línea después de una mala salida, añades un ejemplo tras la queja de un cliente, endureces una restricción después de un fallo aguas abajo. Sin versiones no puedes saber qué cambio ayudó, y no puedes deshacer el que empeoró las cosas. Los archivos de texto plano en git son perfectamente adecuados. También lo es un registro de cambios sencillo al final de cada prompt con la fecha y el motivo de cada modificación.

Las pruebas convierten un buen prompt en uno fiable. Guarda un puñado de entradas de prueba junto a cada prompt importante, incluido al menos un caso incómodo, y vuelve a ejecutarlas cada vez que cambies el prompt o cuando haya un modelo nuevo disponible. No necesitas herramientas sofisticadas para empezar. Un script corto o incluso una comprobación manual cuidadosa con las mismas cinco entradas detectará la mayoría de las regresiones antes de que lo haga un cliente.

Un prompt ingenioso es un momento. Un prompt probado y versionado es una herramienta. Solo uno de los dos da intereses compuestos.

Una vez que tus prompts son activos, empiezas a ver tu práctica de otra manera. Tu biblioteca es la diferencia entre tu primer encargo en un sector y el décimo. Es lo que permite que un sprint de dos semanas entregue lo que antes llevaba un mes. Y también es, cada vez más, algo que puedes entregar: la biblioteca propia de un cliente, construida durante tu encargo, documentada y probada, pasa a formar parte de lo que ha comprado. La siguiente parte de este libro va más allá y convierte los mejores de estos activos en skills que se cargan solas.

Esta semana, reúne los prompts que hayas usado más de tres veces. Dale a cada uno un nombre, un hogar, un número de versión y unas cuantas entradas de prueba. Te llevará una tarde. Te devolverá esa tarde en menos de un mes, y cambiará sin hacer ruido tu forma de pensar en todo lo que escribes para un modelo. A partir de ahora, cada buen prompt que escribas será o un activo o un buen prompt desperdiciado.

Vende el kit de prompts

Todo lo de esta parte se puede empaquetar y vender. El kit de prompts es uno de los microencargos más sencillos que existen: un proyecto de alcance cerrado para darle a un equipo un conjunto probado de prompts para las tareas que hace todos los días. Es fácil de explicar, rápido de entregar, de bajo riesgo para el comprador y visiblemente útil desde la primera mañana. También es un primer peldaño excelente para clientes a los que la IA les despierta curiosidad pero que todavía no están preparados para una auditoría o un piloto.

La forma es directa. Empieza con un taller corto o unas cuantas entrevistas para listar las tareas recurrentes del equipo que implican leer, escribir o decidir. Elige las diez más frecuentes y más dolorosas. Para cada una, reúne ejemplos reales, buenos y malos, y escribe un prompt usando todo lo de esta parte: un encargo como es debido, un rol claro, un formato acotado, ejemplos trabajados, un ejemplo negativo donde ayude, una rúbrica de calidad. Prueba cada prompt con entradas reales junto a las personas que lo van a usar. Luego entrega el kit con una guía breve y una sesión en la que enseñes al equipo a usarlo.

Lo que le da valor no son solo los prompts. Es que los prompts están ajustados al trabajo de este equipo, con la voz de este equipo, con los ejemplos de este equipo, y probados con las entradas reales de este equipo. Una lista genérica de prompts es gratis en internet y vale más o menos eso. Un kit que produce su formato de propuesta, sus respuestas a quejas y su informe semanal al primer intento vale muchísimo, porque ahorra tiempo todos y cada uno de los días desde el momento en que aterriza.

Dónde vive el kit depende del cliente. Para un equipo que trabaja con Claude, los prompts pueden estar en un proyecto compartido como material de referencia, junto con los ejemplos y una guía breve. Para equipos más avanzados, los mejores prompts pueden convertirse en skills, de modo que se carguen cuando sean pertinentes en lugar de copiarse y pegarse. En cualquier caso, documenta cada prompt con su propósito, un ejemplo de entrada y de salida y el nombre de la persona responsable dentro de la empresa.

Un kit de prompts es lo más pequeño que puedes vender que un equipo usará todos los días.

Ten claro el alcance. Diez prompts, no cincuenta. Un equipo, no toda la empresa. Probados con entradas reales, no hipotéticas. Una fecha de traspaso cerrada. Cuando el cliente pida prompts para otro departamento, cosa que hará si el primer conjunto es bueno, ese es el siguiente encargo. Apúntalo y propónlo en el traspaso.

El kit también hace un trabajo silencioso para tu cartera. Produce ejemplos medibles del antes y el después, crea un defensor interno que lo usa a diario y saca a la luz los problemas de flujo de trabajo más grandes que un prompt por sí solo no puede arreglar, que son precisamente los problemas que aborda tu siguiente peldaño. Esta semana, esboza un kit de prompts para un equipo que conozcas: las diez tareas y un prompt probado para la primera. Si ese primer prompt le ahorra veinte minutos al día a una persona, ya tienes el caso de éxito.

El contexto es el producto

La calidad del modelo, para cualquier trabajo concreto, es más o menos fija. Lo que le das de comer, no. La mayor parte de la distancia entre una respuesta mediocre y una brillante se construye antes de enviar el prompt: qué documentos puede ver el modelo, qué ejemplos tiene, qué sabe del cliente, qué decisiones ya se han tomado, hacia qué objetivo trabaja. El oficio del prompt se lleva la atención. El contexto hace la mayor parte del trabajo.

Es una buena noticia para los consultores, porque el contexto es donde vive tu valor. Cualquiera puede abrir Claude y hacer una pregunta. Muy pocos saben reunir el contexto adecuado para un problema de negocio concreto: las páginas pertinentes de la política interna, los tres correos que muestran el problema real, la hoja de cálculo con las cifras de verdad, la nota que explica por qué fracasó el último intento. Saber qué reunir, y qué dejar fuera, es pericia. Es la pericia que compran los clientes cuando te contratan a ti en lugar de limitarse a pagar una suscripción.

Piensa en el contexto por capas. Abajo, el conocimiento duradero que rara vez cambia: quién es el cliente, su sector, su estilo, sus restricciones. Encima, el conocimiento del proyecto: el objetivo de este encargo, las decisiones tomadas hasta ahora, la definición de «terminado». Encima, el contexto de la tarea: los documentos y ejemplos concretos que importan para la pregunta que tienes delante. Y arriba del todo, la instrucción en sí. Cada capa debe cuidarse por separado, porque cada una cambia a un ritmo distinto y se queda obsoleta de un modo distinto.

Las herramientas han crecido en torno a esta idea. Los proyectos de Claude te permiten fijar material de referencia que todas las conversaciones pueden ver. Claude Code lee archivos de memoria de un repositorio al inicio de cada sesión. Las skills cargan instrucciones detalladas solo cuando son pertinentes. Los conectores permiten al modelo obtener información en vivo de los sistemas de un cliente en lugar de depender de lo que pegaste la semana pasada. Cada una de estas cosas es, en el fondo, una forma de poner el contexto adecuado delante del modelo en el momento adecuado sin que tengas que hacerlo a mano.

«Si entra basura, sale basura» siempre fue cierto. La nueva regla es: si entra algo bien escogido, sale algo sorprendentemente bueno.

El cambio práctico consiste en tratar el montaje del contexto como un paso por derecho propio, no como una ocurrencia de última hora. Antes de hacer la pregunta difícil, pregúntate qué querría leer primero un experto humano brillante. Luego reúne exactamente eso, ni más ni menos, y ponlo donde el modelo lo vea. Los capítulos que siguen explican cómo: pegando el original, ordenándolo bien, manteniéndolo ligero, eliminando lo caducado y estructurando lo que queda.

Esta semana, elige una tarea en la que las respuestas de Claude te hayan decepcionado. Antes de reescribir el prompt, reescribe el contexto. Añade el documento que has estado resumiendo de memoria. Quita los tres que no vienen al caso. Añade una nota breve sobre la decisión ya tomada. Luego haz la misma pregunta otra vez. A menudo descubrirás que el prompt estaba bien desde el principio. Simplemente le estabas pidiendo que respondiera sobre una habitación que no podía ver.

Pega el original

Los resúmenes pierden justo el detalle que importaba. Cuando describes un mensaje de error de memoria, omites el número de línea. Cuando parafraseas una cláusula contractual, te comes el inciso que cambia su sentido. Cuando resumes la queja de un cliente, limas el tono que te dice lo enfadado que está. Luego le pides ayuda al modelo, y te ayuda con tu resumen, que es un problema ligeramente distinto del real.

La solución es casi vergonzosamente sencilla: pega el original. El error real, completo. La cláusula real, con su numeración. El correo real, con sus erratas. La exportación real de la hoja de cálculo, no tu descripción de lo que contiene. Los modelos leen muy bien el material en bruto, a menudo mejor que las personas, porque no se aburren a mitad ni leen en diagonal. Dales la fuente y normalmente encontrarán lo que a ti se te habría escapado.

Esto importa el doble en consultoría, porque a menudo trabajas a un paso de distancia del problema. Un cliente te dice que su proceso de facturación es lento. Si le preguntas a Claude cómo acelerar la facturación, obtienes consejos genéricos. Si pegas una exportación anonimizada de las facturas del mes pasado, el hilo de correos en el que un cliente impugnó una y la lista de comprobación interna que sigue el equipo de contabilidad, obtienes observaciones concretas: los mismos tres campos se vuelven a introducir a mano, las disputas se concentran en una línea de producto, la lista tiene un paso que nadie hace. Esa es la diferencia entre un consultor y un buscador.

Hay límites, y son importantes. El material real a menudo contiene información personal y confidencial. Antes de pegar nada de un cliente, ten claro qué permite tu acuerdo, qué exigen sus políticas y qué dicen las normas de protección de datos de tu jurisdicción. Anonimiza donde puedas, elimina lo que no necesites y usa herramientas y planes cuyo tratamiento de datos haya aprobado el cliente. Pegar el original es una buena práctica. Pegar la lista de clientes de alguien en una herramienta que no ha autorizado, no.

Una paráfrasis es una copia con pérdidas. El modelo merece el original, y tu cliente también.

También hay un oficio en elegir qué original. Pegarlo todo es otro tipo de fracaso, como sostendrá el capítulo sobre el presupuesto de contexto. La habilidad consiste en encontrar el material de origen concreto que contiene el problema: el caso que falla, no todos los casos; la factura impugnada, no todo el libro mayor; el párrafo de la política que se aplica, no el manual entero. Real y pertinente, por ese orden.

Pruébalo la próxima vez que te atasques. Fíjate en el momento en que empiezas a teclear la descripción de algo que podrías pegar sin más. Para, busca el original, límpialo de todo lo que no deba salir del cliente y pégalo. Luego haz tu pregunta. Te ahorrarás el viaje de ida y vuelta en el que el modelo te pide más detalles, y evitarás el fallo más sutil en el que nunca los pide y resuelve con total seguridad el problema equivocado.

El orden importa

Dónde colocas las cosas en un prompt influye en lo bien que el modelo las aprovecha. La pauta general, que se sostiene bien en la práctica, es sencilla: los documentos largos primero, tu pregunta al final. Pon el material arriba y las instrucciones y la pregunta en sí abajo, para que la instrucción esté fresca cuando el modelo empiece a responder en lugar de enterrada bajo diez mil palabras de texto de origen.

La intuición es fácil de captar. Imagina que le das a un colega un informe grueso con un pósit en la portada que dice revisa las condiciones de pago, por favor, e imagina que le das el mismo informe con el pósit en la última página. En el primer caso, cuando llegue a la página cuarenta puede que haya olvidado qué buscaba exactamente. En el segundo, la pregunta llega justo cuando está preparado para responderla. Los modelos no son personas, pero los prompts largos se comportan de forma parecida con la frecuencia suficiente como para tenerlo en cuenta.

Una buena estructura por defecto para un prompt de cierta envergadura es esta. Primero, los documentos de referencia, cada uno claramente etiquetado. Después, los ejemplos de la salida que quieres. Después, una breve explicación de para quién es el trabajo y por qué. Luego, la tarea concreta, el formato y el control de éxito. Por último, si ayuda, una línea que repita la restricción más importante. Esa estructura se lee con naturalidad y mantiene la instrucción cerca de la respuesta.

Dentro de los documentos, el orden también importa. Coloca el material más pertinente donde el modelo tenga más probabilidades de darle peso, y etiqueta cada pieza con lo que es y por qué está ahí. Lo que sigue es la política de devoluciones actual del cliente, que el nuevo proceso debe cumplir es mucho más útil que un bloque de texto sin etiquetar. Las etiquetas le dicen al modelo cómo usar cada documento, no solo que existe.

Primero el material, al final la pregunta. El modelo responde con más cuidado a lo último que ha leído.

Para los consultores que construyen sistemas en lugar de prompts sueltos, el orden se convierte en una decisión de diseño. Cuando montas un prompt de forma programática, incorporando una ficha de cliente, la política pertinente, unos cuantos ejemplos anteriores y el mensaje entrante, decide el orden deliberadamente y mantenlo constante. Un orden incoherente es una fuente silenciosa de salidas incoherentes, y es una de las primeras cosas que hay que revisar cuando un sistema que funcionaba en las pruebas se comporta de forma rara en producción. Una estructura coherente también ayuda con la caché de prompts cuando la plataforma la admite, porque el material estable del principio puede reutilizarse entre llamadas.

También es un buen punto para las sesiones de formación, porque se aplica con muchísima facilidad. La mayoría de la gente pega primero su pregunta y después su material, porque así es como piensa en el problema. Mostrarle a un equipo el mismo prompt en los dos órdenes, con resultados visiblemente distintos sobre un documento largo, convierte el principio en costumbre más rápido que cualquier explicación.

Esta semana, coge tu prompt habitual más largo y reordénalo: documentos arriba con etiquetas, ejemplos a continuación, instrucción y pregunta abajo. Ejecútalo con la misma entrada que antes. Si la respuesta mejora, quédate con ese orden. Si no, no has perdido más que un minuto y has aprendido algo sobre esa tarea en concreto.

El presupuesto de contexto

Las ventanas de contexto son enormes hoy en día, lo bastante como para albergar libros enteros y bases de código considerables. Ese tamaño invita a un mal hábito: meterlo todo porque se puede. Cada documento irrelevante en el contexto es una distracción que el modelo tiene que sortear. Puede que no falle del todo, pero la respuesta se vuelve más vaga, el foco se desvía y los detalles que te importaban reciben menos atención. Tres archivos adecuados ganan a treinta, y la respuesta suele afinarse a medida que el montón encoge.

Piensa en el contexto como un presupuesto y no como un contenedor. El contenedor puede albergar muchísimo. El presupuesto es la cantidad de atención que quieres que el modelo dedique a cada cosa. Gástalo en el material que incide directamente en la pregunta. Deja fuera el que solo está relacionado, los antecedentes que incluiste por si acaso, las versiones antiguas, las actas de reunión de otro proyecto. Si no se lo darías a un experto humano avispado para esta pregunta, no se lo des al modelo.

Seleccionar es una habilidad, y es una de las cosas más valiosas que aporta un consultor. Un cliente que te ha dado acceso a su unidad compartida te ha dado miles de documentos. El valor que añades es saber qué seis importan para este problema. Con Claude puedes hacer esta selección en dos pasos: primero, pide al modelo que lea un conjunto más amplio y señale qué documentos son pertinentes para la pregunta, con una frase sobre el porqué; segundo, empieza una conversación nueva solo con esos documentos y haz la pregunta de verdad. El primer paso es un triaje. El segundo es el trabajo.

La idea del presupuesto también se aplica al trabajo de larga duración. En Claude Code, el contexto se va llenando a medida que avanza la sesión, con archivos leídos, comandos ejecutados y salidas producidas. Los subagentes ayudan aquí, porque pueden hacer trabajo exploratorio en su propio contexto y devolver solo un resumen. Compactar o empezar sesiones nuevas también ayuda. El principio es el mismo en todas partes: el hilo principal debe llevar lo que necesita la tarea actual, y el ruido debe estar en otro sitio.

El modelo puede leerlo todo. Eso no significa que deba hacerlo.

El coste también cuenta, aunque rara vez es lo principal. Los contextos más grandes tardan más en procesarse y cuestan más, y en un sistema de producción al que se llama muchas veces al día esas diferencias se acumulan. Un contexto ligero y bien seleccionado es más rápido, más barato y, normalmente, mejor. Es una rara alineación de incentivos, y merece la pena aprovecharla cuando diseñas el sistema de un cliente.

Prueba esto en tu próxima tarea con forma de investigación. Antes de hacer la pregunta, enumera todos los documentos que ibas a incluir y marca cada uno como esencial, útil o por si acaso. Incluye solo los esenciales, más los útiles si hay una razón concreta. Ejecútalo y compáralo con la versión que lo incluía todo. La mayoría de la gente descubre que la versión ligera responde con más precisión. También te enseña algo incómodo: cuánto de tu contexto habitual estaba ahí para tranquilizarte a ti y no para beneficio del modelo.

La conversación que se pudre

Al cabo de cuarenta turnos, una conversación arrastra mucho equipaje. Suposiciones muertas que corregiste hace veinte mensajes. Enfoques que probaste y abandonaste. Versiones antiguas de un documento. Un malentendido del principio que arreglaste pero que el modelo quizá aún recuerde a medias. Todo eso está en el contexto, y todo eso puede influir en la respuesta. El resultado es un deslizamiento gradual de la calidad que es fácil pasar por alto, porque cada respuesta individual es solo un poco peor que la anterior.

Los síntomas son reconocibles una vez que los conoces. El modelo vuelve a introducir una frase que le dijiste que quitara. Regresa a una estructura anterior. Mezcla detalles de dos versiones de un plan. Parece discutir con una postura que ya no sostienes. Te descubres repitiendo instrucciones que diste hace una hora. Nada de esto significa que el modelo haya empeorado. Significa que la conversación se ha convertido en un lío, y el modelo hace lo que puede con el lío que le has dado.

La solución es empezar de cero con un encargo limpio. Antes de abandonar la conversación larga, pídele al modelo que escriba un resumen de la situación: el objetivo, las decisiones tomadas, la versión actual del trabajo, las preguntas abiertas y el siguiente paso. Léelo con atención, porque de vez en cuando conservará algo que querías descartar, y corrígelo. Luego abre una conversación nueva, pega el resumen corregido y la versión actual del trabajo, y sigue adelante. La conversación nueva tiene todo lo que importa y nada de lo que no.

No es señal de fracaso. Los usuarios experimentados empiezan conversaciones nuevas de forma rutinaria, a menudo en puntos de corte naturales: cuando termina una fase del trabajo, cuando cambia la dirección, cuando se pasa a otro tema. En Claude Code, limpiar el contexto entre tareas no relacionadas es parte normal de una buena sesión, y la herramienta puede compactar por ti las sesiones largas. El hábito es el mismo en ambos sitios: no intentes que una sola conversación cargue con todo un proyecto.

Discutir con tu propio historial es una mala forma de pasar la tarde. Escribe el traspaso y vuelve a empezar.

Para los consultores, la conversación podrida tiene una cara que mira al cliente. Si le entregas al equipo de un cliente un flujo de trabajo basado en una única conversación que no para de crecer, la calidad también se degradará para ellos, y concluirán que la herramienta no es fiable. Incorpora los comienzos limpios al flujo de trabajo: una conversación nueva por caso, por documento, por día, con el contexto duradero fijado en un proyecto para que esté siempre presente. Esa pequeña decisión de diseño evita buena parte de las quejas del tipo antes funcionaba mejor que llegan un mes después del traspaso.

Esta semana, fíjate en la próxima vez que una conversación empiece a notarse torpe o confusa. En lugar de volver a corregirla, pide el resumen, arréglalo y empieza una conversación nueva con él. Compara la siguiente respuesta con lo que estabas obteniendo. Los comienzos limpios parecen progreso perdido. En la práctica suelen ser el camino más rápido hacia el progreso que de verdad querías.

El conocimiento del proyecto

Hay contexto que cambia con cada tarea. Y hay contexto que apenas cambia: las normas de marca del cliente, el glosario de la jerga de su sector, el esquema de datos que usan sus sistemas, las decisiones tomadas en el arranque, la definición de «terminado» del encargo. Volver a pegar todo eso en cada conversación es tedioso y propenso a errores. Fíjalo una vez, en algún sitio que todas las conversaciones puedan ver, y deja de ser una lata.

Los proyectos de Claude están hechos para esto. Subes o escribes material de referencia en el proyecto, y cada conversación dentro de él empieza con ese material disponible. Añade instrucciones personalizadas y también se aplican en todas partes. Para un encargo, un proyecto por cliente es la forma natural: el encargo, el alcance, el glosario, el estilo de la casa, unos cuantos ejemplos comentados, el registro de decisiones en curso. Cada conversación sobre ese cliente empieza con los cimientos adecuados, y nunca más tienes que explicar su modelo de negocio al principio de un chat.

La misma idea aparece en otros sitios. Un repositorio puede llevar un archivo de memoria que Claude Code lee al inicio de cada sesión. Una skill puede llevar instrucciones duraderas para un tipo de tarea recurrente. Un espacio de trabajo de equipo puede compartir el conocimiento del proyecto entre compañeros para que todos trabajen sobre los mismos cimientos. Superficies distintas, mismo principio: el conocimiento duradero va en un sitio duradero, no en el historial del portapapeles de alguien.

Cuida el conocimiento del proyecto con el mismo esmero que el contexto de la tarea, o con más, porque influye en todo. Mantenlo breve y concreto. Un documento de identidad de marca de diez páginas puede contener una sola página que importe para la redacción; extrae esa página. Un glosario largo puede contener una docena de términos que generan confusión; empieza por ellos. Pon fecha a tu registro de decisiones para que quede claro cuáles están vigentes. Y revisa el conocimiento del proyecto cuando el encargo cambie de fase, porque lo que importaba durante la auditoría puede ser ruido durante la construcción.

Si lo has explicado dos veces, va en el proyecto. Si lo has explicado cinco, el proyecto eres tú.

El conocimiento del proyecto también es un excelente artefacto de traspaso. Al final de un encargo, un proyecto bien organizado que contiene el contexto del cliente, prompts probados, ejemplos e instrucciones es algo que su equipo puede seguir usando a la mañana siguiente. Muchos clientes lo encuentran más útil que cualquier informe, porque no es una descripción de cómo trabajar con IA en su negocio. Es un entorno de trabajo ya preparado para ello.

Hay también una cuestión de seguridad. El conocimiento del proyecto es visible para cualquiera con acceso al proyecto, así que piensa en qué metes y quién puede verlo. Guarda el material de cada cliente en proyectos específicos de ese cliente, nunca mezclado con el de otros, y acuerda con el cliente quién de su lado debe tener acceso cuando se lo entregues.

Esta semana, crea un proyecto para tu cliente más ocupado o para tu propia práctica. Añade las cinco cosas que más a menudo te descubres explicando de nuevo, escritas como notas breves y claras. Luego trabaja dentro de él durante una semana y fíjate en cuánto se acortan tus prompts. Ese acortamiento es tiempo que dedicabas a recordar y que ahora dedicas a pensar.

Recuerda el objetivo

Las tareas largas se desvían. Empiezas pidiendo un rediseño de proceso que reduzca el tiempo de respuesta, y tres horas después estás metido hasta el cuello en un debate sobre cómo nombrar los campos de estado. Cada paso tenía sentido respecto al anterior, pero el camino se ha alejado del destino. Los modelos se desvían exactamente igual, y por casi la misma razón: responden a lo que tienen delante, y lo que tienen delante es el paso más reciente, no el objetivo original.

El remedio cuesta muy poco. Recuerda el objetivo a mitad de camino. Basta una línea breve, en el punto en que notas que el trabajo se ramifica: Recordatorio: el objetivo es reducir el tiempo de elaboración de presupuestos del equipo comercial de días a horas. ¿Esta decisión sobre los nombres contribuye a eso? Veinte palabras. Devuelven la conversación a la pregunta que importa y con frecuencia revelan que la subtarea actual es un desvío que puedes abandonar.

Esto es especialmente útil en el trabajo agéntico, en el que Claude puede ejecutar muchos pasos sin que tú dirijas cada uno. Un encargo que empieza con un objetivo claro está bien. Uno que además pide al agente que compruebe su progreso frente al objetivo cada cierto tiempo está mejor. En Claude Code, un plan breve con el objetivo arriba, guardado en un archivo que el agente va actualizando mientras trabaja, actúa como recordatorio permanente. El agente lee su propio plan, ve el objetivo y es menos probable que pase una hora puliendo algo que el objetivo no requiere.

La misma disciplina se aplica a los humanos de un encargo de consultoría. Las reuniones con clientes se desvían con la misma facilidad que los modelos. Un sprint que empezó como piloto de procesamiento de facturas puede convertirse, tras unas cuantas llamadas cordiales, en una charla sobre todo el ecosistema financiero del cliente. Recordar el objetivo al inicio de cada reunión de seguimiento, idealmente con las palabras que usó el propio cliente en el arranque, mantiene a todo el mundo honesto. También te da una forma educada de aparcar la ampliación del alcance: suena valioso; ¿ayuda con el objetivo de tiempo de respuesta, o lo añadimos a la lista para la próxima vez?

Veinte palabras de recordatorio pueden ahorrarte una hora resolviendo un problema que ya nadie tiene.

Hay un beneficio más sutil. Recordar el objetivo con regularidad te obliga a comprobar si el objetivo sigue siendo el correcto. A veces la deriva te está diciendo algo: el objetivo original era el equivocado, y el trabajo ha ido derivando hacia el problema real. Merece la pena advertirlo y discutirlo abiertamente, en lugar de ignorar la deriva o seguirla a ciegas. En cualquier caso, el recordatorio es lo que convierte la elección en consciente.

Pruébalo en tu próxima sesión de trabajo larga. Ponte un recordatorio suave, quizá cada hora o en cada pausa natural, para formular el objetivo en una frase y preguntarte si el paso actual lo sirve. Haz lo mismo al comienzo de tu próxima reunión de seguimiento con un cliente. Recortarás trabajo que no necesitabas hacer y, de vez en cuando, descubrirás que el propio objetivo necesita una corrección educada, que es el tipo de deriva más valioso que existe.

Elimina el contexto caducado

Cuando algo cambia, la versión antigua no solo está desfasada. Es activamente dañina. Si el modelo todavía puede ver la tabla de precios de la semana pasada, el borrador anterior de la política o la antigua estructura de archivos, a menudo mezclará ambas cosas y producirá un híbrido verosímil: casi todo de la versión nueva, con un detalle antiguo arrastrado en silencio. Los híbridos verosímiles son el peor tipo de error, porque parecen correctos hasta que alguien se fía de ellos.

La primera defensa es decirlo, alto y claro. La política de reembolsos ha cambiado hoy. La versión de abajo sustituye a todas las anteriores. Ignora cualquier condición de reembolso mencionada antes en esta conversación. Eso no es exagerar. Es lo mínimo. Los modelos no saben automáticamente que un documento más reciente sustituye a uno más antiguo, sobre todo cuando ambos están en el contexto. Decirles cuál está vigente, y que el otro debe descartarse, elimina la ambigüedad.

La segunda defensa, y la más fuerte, es eliminar del todo el material caducado. Actualiza el documento en el conocimiento del proyecto en lugar de añadir una versión nueva junto a la vieja. Empieza una conversación nueva en lugar de corregir una larga. En un repositorio, actualiza el archivo de memoria y borra la instrucción obsoleta en lugar de añadir una contradicción. Cada copia de información antigua que dejas por ahí es una oportunidad para que resurja en el peor momento posible.

Es una fuente habitual de problemas en los sistemas de los clientes tras el traspaso. Una empresa cambia una política, actualiza el documento en su intranet, pero olvida que el flujo de IA que construiste tiene su propia copia de la política antigua fijada en algún sitio. Un mes después, un cliente recibe una respuesta basada en normas que ya no se aplican. La solución es de diseño, no de vigilancia: siempre que sea posible, haz que los sistemas lean de una única fuente de verdad en lugar de guardar sus propias copias, e incluye la revisión del material de referencia de la IA en el proceso de cambios del cliente. Escríbelo en el manual de operaciones.

El contexto antiguo no se desvanece con educación. Espera su oportunidad para equivocarse con total seguridad.

También hay una versión personal. Tu propia biblioteca de prompts y el conocimiento de tus proyectos acumulan material caducado: instrucciones escritas para un modelo anterior, ejemplos de un cliente cuyo estilo ha cambiado, apaños para problemas que ya no existen. Pódalos periódicamente. Una instrucción breve y vigente gana a una larga medio obsoleta, y la mitad obsoleta puede estar contradiciendo a la que no lo es.

Esta semana, examina un proyecto o un flujo de trabajo de larga duración y localiza el material caducado. Versiones antiguas de documentos, decisiones superadas, instrucciones que ya no se aplican. Borra lo que puedas, marca como histórico lo que debas conservar y haz que la versión vigente sea inconfundible. Luego añade una línea a tu lista de comprobación de traspaso que recuerde a los clientes hacer lo mismo cada vez que cambien sus políticas. El error más barato de arreglar es el que nunca tuvo un documento caducado del que salir.

Entrada estructurada

Cuando un prompt contiene varios tipos de material, el modelo tiene que averiguar dónde termina uno y empieza el siguiente. ¿Dónde acaba la transcripción y empieza tu instrucción? ¿Ese párrafo es un ejemplo de buena salida o parte del documento de origen? Normalmente acierta. A veces no, y los errores son exasperantes: una instrucción tratada como contenido, un ejemplo resumido como si fuera el documento, el mensaje de un cliente obedecido como si fuera tu petición.

La solución es estructurar la entrada. Envuelve cada bloque distinto en etiquetas con nombres claros: el documento de origen en una, los ejemplos en otra, los antecedentes del cliente en una tercera, tu instrucción en una cuarta. Claude responde especialmente bien a las etiquetas de estilo XML, y los nombres no tienen que seguir ningún estándar. Las etiquetas llanas y descriptivas funcionan mejor: contract, previous_emails, style_examples, task. Luego haz referencia a las etiquetas en tu instrucción: usando la política que hay en las etiquetas policy, redacta una respuesta al mensaje que hay en las etiquetas customer_message.

La estructura de entrada tiende a producir estructura de salida. Cuando la entrada está claramente dividida en secciones, el modelo sigue mejor la pista de para qué sirve cada sección, cita con más exactitud de la correcta y sigue la instrucción en lugar de distraerse con el material. También puedes pedir una salida estructurada con la misma idea, con el razonamiento en una etiqueta y la respuesta final en otra, lo que facilita que un programa, o un lector con prisa, extraiga la parte que importa.

Hay una dimensión de seguridad que conviene tomarse en serio. En los sistemas de los clientes, gran parte de la entrada viene de fuera: correos de clientes, documentos subidos, páginas web. Parte de ese contenido puede incluir texto que parezca instrucciones, ya sea por accidente o a propósito. Separar claramente el contenido no fiable de tus instrucciones, etiquetarlo como datos que procesar y no como órdenes que seguir, y decirle explícitamente al modelo que no actúe según instrucciones que encuentre dentro, es una defensa básica. No es completa, y por eso capítulos posteriores hablan de barreras de seguridad y puntos de control humanos, pero es el cimiento.

Dile al modelo qué parte es la carta y qué parte es tu nota sobre la carta. No siempre lo distingue a simple vista.

La entrada estructurada también hace que los prompts sean más fáciles de mantener. Cuando el sistema de un cliente monta un prompt a partir de varias fuentes, una ficha de cliente, un extracto de la política, algunos ejemplos y un mensaje entrante, las etiquetas hacen que cada componente sea visible y sustituible. Un compañero que lea la plantilla del prompt un año después puede ver de un vistazo qué va dónde. Esa legibilidad es parte de lo que hace que un sistema pueda operarlo alguien que nunca te ha conocido.

Coge esta semana uno de tus prompts más complejos y reestructúralo con etiquetas. Nombra cada bloque según lo que es, deja tu instrucción en su propia sección etiquetada al final y haz referencia a los bloques por su nombre en la instrucción. Ejecútalo con una entrada complicada. Si nada cambia, al menos habrás hecho el prompt más fácil de leer y mantener. Normalmente algo cambia.

El sprint de documentación

Toda pequeña empresa funciona en parte gracias a un conocimiento que solo existe en la cabeza de la gente. Cómo funciona de verdad el cierre de mes. Qué proveedor necesita una llamada y no un correo. Por qué existe la segunda hoja de cálculo. Cuando ese conocimiento sale por la puerta, de vacaciones o para siempre, las cosas se rompen. Y cuando la empresa intenta usar la IA, descubre que un modelo tampoco sabe leer cabezas. El sprint de documentación aborda los dos problemas a la vez, y es uno de los microencargos más discretamente valiosos que puedes vender.

La forma es un sprint de duración fija, normalmente una o dos semanas, centrado en un área del negocio. Entrevistas a las personas que hacen el trabajo, grabas recorridos con su permiso, reúnes los documentos dispersos que ya existen y usas Claude para convertirlo todo en documentación clara y estructurada: guías de procesos, reglas de decisión, glosarios, listas de comprobación y preguntas frecuentes. Cada borrador vuelve a la persona que hace el trabajo para que lo corrija. El resultado es un conjunto de documentos que un recién llegado podría seguir y que un modelo podría usar como contexto.

Ese doble público es el argumento de venta. Los proyectos de documentación tradicionales eran difíciles de justificar porque los documentos rara vez se leían. La documentación escrita a la vez para personas y para la IA se usa constantemente: se convierte en el conocimiento del proyecto que hay detrás del asistente del equipo, en el material de referencia de un piloto de agentes, en el contexto que hace funcionar los prompts. Un cliente que compra un sprint de documentación compra los cimientos sobre los que se asentará cada futuro encargo de IA, y puede ver esos cimientos en uso en cuestión de días.

Las lecciones de oficio de esta parte se aplican directamente. Pega el original: transcripciones y documentos reales, no tu resumen de ellos. Elimina el contexto caducado: localiza y retira las versiones obsoletas sobre la marcha. Estructura la entrada: los encabezados coherentes y las secciones etiquetadas hacen que los documentos sean más fáciles de usar para los modelos. Y el principio del traspaso, dejar por escrito el estado, las decisiones, las preguntas abiertas y la siguiente acción en cada cambio de turno, se convierte en un hábito que dejas instalado en el cliente, para que la documentación siga viva cuando te hayas ido.

Antes la documentación se escribía para el auditor. Ahora se escribe para el recién llegado y para el modelo, y los dos la leen de verdad.

Sé preciso con el alcance. Un área de procesos, no toda la empresa. Un número fijo de entrevistas. Un responsable con nombre en el lado del cliente que mantendrá los documentos al día. Una indicación clara de dónde vivirán los documentos y cómo se mantendrán. Sin un responsable, la documentación se deteriora en pocos meses, y la documentación deteriorada que se le da a un modelo produce respuestas desfasadas dichas con total seguridad, lo cual es peor que no tener ninguna.

Este encargo lleva con naturalidad a otros. En cuanto un proceso está bien documentado, las oportunidades de automatización saltan a la vista, y tú eres la persona que acaba de leer cada uno de sus pasos. Esta semana, elige un proceso de tu propia práctica que solo viva en tu cabeza. Dedica una hora con Claude a convertirlo en una guía escrita. Luego reléela y fíjate en cuántas cosas dabas por hecho que nadie necesitaba que le contaran. Ese hueco es lo que los clientes te pagarán por cerrar.

Primero, lee el repositorio

Buena parte de los microencargos tienen lugar dentro del repositorio de otra persona. Un script que concilia dos exportaciones. Una herramienta interna de la que depende el equipo de operaciones. Una web con un formulario que debería encaminar las consultas con más inteligencia. Llegas como un extraño, normalmente con un calendario corto, y la tentación es empezar a cambiar cosas la primera tarde. Resístela. Diez minutos de exploración compran horas de código correcto, y con Claude Code esos diez minutos salen baratos.

Claude Code es la herramienta de programación agéntica de Anthropic. Lee una base de código, edita archivos, ejecuta comandos y comprueba su propio trabajo, y tú lo diriges conversando. Antes de pedirle que cambie nada, pídele que mire. Lee este repositorio y explica su arquitectura: los componentes principales, cómo fluyen los datos entre ellos, las convenciones que sigue, cómo se compila y se prueba, y cualquier cosa que parezca frágil. Buscará, abrirá archivos, leerá la configuración y volverá con un mapa. Tu trabajo es leer el mapa con ojo crítico y hacer preguntas de seguimiento hasta que entiendas el terreno.

En esta fase de exploración afloran muchos de los problemas ocultos de un cliente. La batería de pruebas que no se ejecuta desde hace un año. El archivo de configuración con credenciales dentro. Los dos módulos que hacen lo mismo de forma distinta. La dependencia que va varias versiones por detrás. Puede que nada de esto entre en el alcance de tu encargo, pero necesitas saberlo, en parte porque afecta a cómo trabajas y en parte porque a menudo es el material del siguiente encargo. Apúntalo, díselo al cliente y sigue adelante.

El modo plan ayuda aquí, porque en él Claude puede leer y analizar sin editar nada. Para un primer vistazo a una base de código desconocida, es exactamente el ajuste adecuado. Obtienes toda la capacidad de lectura del agente sin riesgo de que una primera sugerencia entusiasta se convierta en un cambio sin revisar. Una vez que entiendas la forma de las cosas, puedes pasar a un modo en el que se permiten ediciones, con los límites que tú elijas.

Un agente que se ha leído la base de código escribe código que encaja en ella. Uno que no, escribe código que simplemente compila.

También hay un beneficio de cara al cliente. El resumen de la arquitectura es útil por sí mismo. Muchas pequeñas empresas tienen código que nadie entiende del todo, escrito por un contratista que ya se marchó. Un mapa escrito y claro de su propio sistema, elaborado en la primera hora de tu encargo y revisado por ti, suele recibirse con auténtica gratitud. Algunos consultores lo ofrecen como microencargo independiente: una revisión de la base de código que termina con un mapa escrito, una lista de riesgos y un conjunto ordenado de mejoras.

Convierte la exploración en un ritual para cada repositorio que toques. Antes de la primera edición, pide el mapa, léelo, corrígelo donde sepas más y guarda la versión corregida en un sitio donde el agente la vea la próxima vez. El siguiente capítulo explica exactamente dónde. Cometerás menos errores, los cometerás más pequeños y parecerás alguien que se toma en serio el sistema del cliente, que es la impresión que quieres dejar la primera tarde.

Primero, CLAUDE.md

El primer archivo que escribas en el repositorio de un cliente debería ser, por lo general, el que le explica el repositorio a Claude. Un archivo llamado CLAUDE.md en la raíz del proyecto se lee automáticamente al inicio de cada sesión de Claude Code. Lo que pongas ahí, el agente lo sabe antes de hacer cualquier otra cosa: cómo compilar y probar, qué convenciones seguir, qué directorios no tocar, qué comandos son seguros y cuáles no. Es el texto con más palanca que escribirás en toda la semana.

Empieza por los comandos. Cómo instalar las dependencias, ejecutar las pruebas, arrancar la aplicación, pasar el linter. Son las cosas que un agente necesita con más frecuencia y que con más frecuencia adivina, y una suposición errónea hace perder tiempo o, peor aún, ejecuta algo no deseado. Luego las convenciones: nombres, estructura de carpetas, bibliotecas preferidas, cómo se gestionan los errores, cómo se escriben las pruebas. Luego las trampas: el módulo que parece sin uso pero no lo está, la variable de entorno que tiene que estar definida, el paso de despliegue que nunca debe ejecutarse desde un portátil. Mantenlo breve. Un archivo de memoria largo se lee con menos atención, tanto por agentes como por humanos.

Puedes arrancarlo rápido. Claude Code puede generar un CLAUDE.md inicial a partir de la base de código con su comando init, y el mapa de arquitectura de tu fase de exploración es buena materia prima. Pero no aceptes la versión generada sin editarla. Las líneas más valiosas son las que solo conoce un humano: el equipo de finanzas ejecuta el script de exportación el primer día laborable de cada mes; no cambies su formato de salida sin avisarles. Ninguna cantidad de lectura del código revelaría eso. Lo aprendiste en la llamada de diagnóstico.

Para los consultores, el archivo de memoria cumple una doble función. Hace que tus propias sesiones sean más rápidas y fiables durante el encargo. Y es un activo de traspaso: cuando te vas, el siguiente desarrollador del cliente, o las propias sesiones de Claude del cliente, heredan todo lo que aprendiste sobre su base de código. Un buen CLAUDE.md es un manual de operaciones que las herramientas leen por ti. Los clientes que usan Claude Code notan la diferencia de inmediato; de repente sus sesiones se comportan como si alguien hubiera instruido debidamente al agente, porque alguien lo hizo.

Cada explicación que metes en el archivo de memoria es una que nunca tendrás que volver a dar.

Mantenlo al día. Cuando descubras una trampa nueva, añádela. Cuando cambie una convención, actualízala. Borra las instrucciones que ya no se apliquen, porque las instrucciones caducadas son peores que ninguna. Claude Code también admite archivos de memoria en subdirectorios y un archivo personal para preferencias que no deben compartirse con el equipo, así que pon las reglas del proyecto en el archivo compartido y tus manías en el tuyo.

En tu próximo encargo sobre un repositorio, haz del archivo de memoria tu primer commit. Comandos, convenciones, trampas, en menos de una página. Luego trabaja un día y añade cada corrección que te hayas descubierto haciéndole al agente. Al final del encargo tendrás un documento que el cliente no sabía que necesitaba y que no querrá perder. Es el entregable más pequeño que entregarás jamás, y muy posiblemente el que más se use.

Planifica antes de editar

Haz que el agente escriba el plan antes de tocar un archivo. Leer un plan equivocado lleva treinta segundos. Deshacer una refactorización equivocada repartida por nueve archivos lleva una tarde, y en un encargo de dos semanas no te sobran tardes. Planificar primero es el hábito más barato para evitar errores caros en la programación agéntica, y encaja especialmente bien con el trabajo de consultoría.

Claude Code tiene un modo plan precisamente para esto. En él, el agente puede leer archivos, buscar en la base de código y razonar sobre el cambio, pero no puede editar nada ni ejecutar comandos que cambien el estado. Tú describes la tarea; él investiga y propone un plan: qué archivos cambiarán, en qué consistirá cada cambio, en qué orden hacerlos, cómo verificará el resultado. Lees el plan, rebates las partes con las que no estás de acuerdo, haces preguntas y solo entonces le dejas continuar.

El valor está en la conversación sobre el plan. Es ahí donde pillas al agente proponiendo reescribir un módulo que sabes que es frágil, o eligiendo una biblioteca que el cliente no usa, o pasando por alto a un consumidor posterior del formato de datos que quiere cambiar. Es también donde aplicas lo que aprendiste en la llamada de diagnóstico y en la exploración: el equipo de informes lee esa tabla directamente; no cambies sus columnas. Treinta segundos de lectura y una frase de corrección pueden ahorrar un día de reparaciones.

Los planes también son buenos artefactos para el cliente. Para un cambio importante, un plan escrito y revisado por ti puede llegar al responsable técnico del cliente antes de que cambie una sola línea de código. Eso convierte un momento potencialmente tenso, un consultor externo con un agente de IA dentro de su base de código, en uno tranquilizador: esto es exactamente lo que va a cambiar, este es el porqué, así es como lo comprobaremos. La gente se siente mucho más cómoda con los cambios que ha visto descritos de antemano. Los clientes pequeños rara vez reciben esa cortesía de los contratistas, y lo notan cuando la reciben.

El plan es donde se te permite equivocarte barato. Gasta ahí tus errores.

No todos los cambios necesitan un plan formal. Renombrar una variable o corregir una errata, no. Una buena regla general es planificar siempre que un cambio afecte a más de un archivo, altere un formato de datos o una interfaz, o haga algo que te costaría deshacer. En caso de duda, planifica. El coste es pequeño, y la costumbre de planificar siempre el trabajo con consecuencias te mantendrá alejado de la mayoría de los problemas sobre los que advierte este libro.

Hay un beneficio más discreto. Leer planes te hace mejor especificando trabajo. Empiezas a notar lo que omitiste en tu petición porque el plan revela el hueco: el agente supuso un formato que no especificaste, o eligió un enfoque que tú no habrías elegido. Con el tiempo tus peticiones se afinan y los planes necesitan menos correcciones. Esta semana, usa el modo plan para cada cambio que afecte a varios archivos. Lee cada plan como si lo hubiera escrito un júnior y tú fueras responsable del resultado. Lo eres.

Diffs pequeños, bucles rápidos

Una cuestión por turno, verificada antes de la siguiente. Ese es el ritmo de trabajo que hace fiable la entrega agéntica. Las sesiones de golpe, en las que pides cinco cambios a la vez y revisas el resultado en conjunto, fallan de maneras costosas de desenredar. Los diffs pequeños fallan de maneras que simplemente puedes deshacer. En un encargo corto, la diferencia entre esos dos modos de fallo suele ser la diferencia entre terminar a tiempo o no.

El patrón es fácil de describir y exige disciplina para seguirlo. Pide un cambio. Deja que el agente lo haga y ejecute las comprobaciones pertinentes. Revisa el diff. Si está bien, haz commit. Si está mal, deshazlo y vuelve a pedirlo con una instrucción mejor. Luego pasa al siguiente cambio. Cada ciclo puede llevar unos minutos. Un día de ciclos así produce un historial limpio y revisable de pasos pequeños que funcionan, que es justo lo que quieres entregarle a un cliente.

La tentación de agrupar es fuerte, porque el agente es rápido y las peticiones grandes parecen eficientes. Pero un diff grande es difícil de revisar como es debido. Tu atención se apaga a mitad de camino, y el problema sutil del séptimo archivo se cuela. Cuando algo se rompe más tarde, no es fácil saber cuál de los cinco cambios lo provocó. Los diffs pequeños mantienen cada revisión lo bastante corta como para hacerla bien, y mantienen clara la cadena causal. Si el cambio cuatro rompió algo, sabes exactamente dónde mirar.

Esto también encaja con cómo les gusta a los clientes ver el progreso. Un sprint cuyo historial se lee como una secuencia de commits pequeños, sensatos y bien descritos es fácil de explicar en una demo de viernes y fácil de entender para los propios desarrolladores del cliente cuando te hayas ido. Pídele a Claude Code que escriba mensajes de commit claros que expliquen por qué se hizo cada cambio, no solo qué cambió. Ese historial se convierte en documentación por derecho propio: un relato legible de lo que hiciste y por qué.

Los pasos pequeños no son lentos. Son la manera más rápida de llegar a un sitio desde el que aún sabes volver.

Los bucles rápidos dependen de una verificación rápida, que es el tema del capítulo siguiente. Si ejecutar las comprobaciones lleva diez minutos, el ritmo se rompe y te verás tentado a agrupar otra vez. Parte de montar un encargo consiste en asegurarse de que hay una forma rápida de verificar cada cambio: un comando de pruebas acotado, un script que recorra el camino pertinente, una comprobación sencilla que el agente pueda ejecutar en segundos. El tiempo invertido el primer día en un bucle de retroalimentación rápido se recupera en cada ciclo que viene después.

Prueba este ritmo durante un día entero en tu próxima tarea de programación. Antes de cada petición, pregúntate si contiene más de una cuestión. Si es así, divídela. Después de cada cambio, insiste en un paso de verificación y un commit antes de seguir. Al final del día, lee tu historial de commits. Si cuenta una historia clara que un desconocido podría seguir, el ritmo ha funcionado. Si se lee como una serie de guardados presas del pánico, estabas agrupando. La mayoría de la gente encuentra además la primera versión menos agotadora.

Deja que ejecute las pruebas

Un agente que puede ejecutar su propia verificación deja de adivinar. Dale a Claude Code el comando para ejecutar las pruebas y hará un cambio, las ejecutará, leerá los fallos, ajustará y volverá a ejecutarlas hasta que pasen, sin que tú tengas que hacer de mensajero entre el agente y la terminal. Esta única capacidad convierte a un asistente que sugiere código en un agente que entrega código que funciona, y es la base de una entrega rápida y fiable.

Por eso, el primer trabajo en cualquier encargo sobre un repositorio es establecer cómo funciona la verificación. ¿Hay una batería de pruebas? ¿Se ejecuta? ¿Cuánto tarda? ¿Hay una forma más rápida de ejecutar solo las pruebas pertinentes? Pon las respuestas en el archivo de memoria, para que el agente las conozca desde el inicio de cada sesión. Si las pruebas están rotas, arreglarlas puede ser la primera tarea pequeña del encargo, y merece la pena hacerlo, porque todas las tareas posteriores dependen de ello.

Muchas bases de código de pequeñas empresas no tienen ninguna prueba. Eso no es motivo para renunciar a la verificación; es motivo para crearla. Antes de cambiar un comportamiento existente, pídele a Claude Code que escriba pruebas que capturen lo que hace el código actualmente, ejecútalas para confirmar que pasan y luego haz el cambio. Las pruebas se convierten en una red de seguridad para tu trabajo y en un activo para el cliente. Donde las pruebas automatizadas no resulten prácticas, un pequeño script que ejercite la funcionalidad e imprima el resultado es mucho mejor que nada. El principio es que el agente debe tener una forma de comprobar su trabajo que no dependa de su propia opinión.

Pide pruebas, no garantías. Cuando el agente informe de que algo funciona, pide ver la salida de las pruebas. Un agente que dice todas las pruebas pasan y uno que muestra la salida en la que todas las pruebas pasan están haciendo afirmaciones distintas, y solo una de ellas es una prueba. En el trabajo con clientes esto importa muchísimo: vas a comunicar resultados a personas que confían en ti, y quieres que cada afirmación que hagas se apoye en algo que has visto.

Una prueba que el agente puede ejecutar es un espejo. Sin ella, solo está admirando su propio reflejo en tu confianza.

La verificación también define qué es «terminado» en cada tarea. Arregla el fallo de las fechas es vago. Arregla el fallo de las fechas para que pase la prueba del módulo de informes y no se rompa ninguna otra es comprobable. Escribir las tareas así hace al agente más eficaz y acelera tu propia revisión, porque sabes exactamente qué buscar. También te da material limpio para el informe al cliente: el fallo, el arreglo y la prueba.

En tu próxima tarea de programación, empieza por confirmar que el comando de pruebas funciona y ponlo en el archivo de memoria. Luego formula cada petición con un paso de verificación incluido, y pide ver la salida antes de aceptar cualquier afirmación de éxito. Si no hay pruebas, haz que escribirlas sea la primera tarea. Durante un día te parecerá más lento. A partir de ahí, todo irá más rápido, y nunca más tendrás que preguntarte si algo funciona.

Git es el botón de deshacer

Haz commit antes de soltar a un agente. Un árbol de trabajo limpio convierte cada sesión fallida en un reinicio de dos segundos en lugar de una recuperación forense. El control de versiones siempre ha sido una buena práctica; con un agente haciendo cambios rápidos en muchos archivos, se convierte en la red de seguridad más importante que tienes. En la base de código de un cliente, donde tus errores son su problema, no es opcional.

La rutina es sencilla. Antes de empezar una tarea, asegúrate de que todo está confirmado. Deja trabajar al agente. Revisa los cambios con un diff. Si están bien, haz commit con un mensaje claro. Si no, descártalos y vuelve a empezar con una instrucción mejor. Como cada tarea parte de un estado limpio, un mal resultado solo te cuesta el tiempo de esa tarea, nunca el trabajo anterior. Claude Code también guarda sus propios puntos de control dentro de una sesión, así que puedes rebobinar a un momento anterior de la conversación, pero git es el registro que sobrevive a la sesión y el que verá el equipo del cliente.

Las ramas lo hacen todavía más seguro. Trabaja en una rama, no en la línea principal del cliente, y fusiona solo cuando el cambio esté revisado y verificado. Muchos clientes querrán revisar los cambios antes de que lleguen a producción, y una rama con una pull request es la forma natural de hacerlo. Aunque el cliente no lo pida, trabaja así. No cuesta nada y protege a todo el mundo.

Cuando llevas varios trabajos a la vez, los worktrees ayudan. Un worktree de git es un directorio de trabajo independiente vinculado al mismo repositorio, en su propia rama. Dos sesiones de Claude Code en dos worktrees pueden trabajar en paralelo en dos funcionalidades sin pisarse los archivos. Para un microconsultor que hace malabares con la corrección de un fallo y una pequeña funcionalidad para el mismo cliente, o que prueba un enfoque experimental junto a uno seguro, es una forma ordenada de evitar líos. Cada worktree es su propia sala blanca.

El seguro más barato del trabajo agéntico es un commit hecho treinta segundos antes de necesitarlo.

Acuerda las reglas con el cliente al principio. En qué rama trabajar, quién revisa y fusiona, si puedes hacer push directamente o solo mediante pull request, y qué no debe confirmarse nunca: credenciales, datos personales, archivos binarios grandes. Pon lo esencial en el archivo de memoria para que el agente también lo cumpla. Los clientes que han tenido malas experiencias con contratistas se tranquilizarán al ver estas reglas por escrito y cumplidas. Los que no, simplemente nunca tendrán una mala experiencia contigo.

Conviértelo en un acto reflejo esta semana. Antes de cada tarea del agente, comprueba que el árbol de trabajo está limpio. Después de cada tarea, revisa y haz commit o reset. Si llevas trabajo en paralelo, prueba un worktree para la segunda línea. Durante un día o dos te parecerá quisquilloso. Después te parecerá como abrocharte el cinturón: nada del otro mundo y discretamente imprescindible, y te alarmará un poco la gente que trabaja sin él.

Comandos de barra a medida

Cualquier flujo de trabajo que ejecutes dos veces en Claude Code debería convertirse en un comando. Claude Code te permite guardar un prompt como comando reutilizable que tú, o cualquiera del equipo, podéis lanzar con una barra y un nombre. A lo largo de un encargo, el repositorio de un cliente puede ir creando un pequeño kit de herramientas privado con la forma exacta de cómo trabaja realmente su equipo. Ese kit es útil durante tu encargo y valioso mucho después.

Piensa en las tareas que se repiten en una base de código pequeña típica. Revisar un cambio antes de fusionarlo. Preparar una versión con su registro de cambios. Generar un informe semanal a partir de una exportación de datos. Incorporar a un desarrollador nuevo explicándole la arquitectura. Cada una implica un conjunto bastante estándar de instrucciones, las mismas comprobaciones y el mismo formato de salida, siempre. Escribir esas instrucciones una vez, probarlas y guardarlas como comando significa que nadie tiene que volver a recordarlas.

Los comandos pueden recibir argumentos, así que un solo comando puede servir para muchos casos: revisa esta rama, informa sobre este mes, explica este módulo. También pueden compartirse a través del repositorio, de modo que todos los que trabajan en el proyecto tengan el mismo conjunto. Ese conjunto compartido estandariza sin hacer ruido cómo trabaja el equipo con el agente. En lugar de cinco personas escribiendo cinco versiones de un prompt de revisión, de calidad variable, todos usan el que se ha probado y mejorado.

En las versiones recientes de Claude Code, los comandos y las skills se han acercado, y mucho de lo que antes era un simple comando ahora puede empaquetarse como una skill que además se carga sola cuando es pertinente. La siguiente parte trata las skills a fondo. La lección práctica es la misma en ambos casos: el trabajo recurrente merece una forma con nombre, reutilizable y compartida, no un prompt nuevo tecleado de memoria cada vez.

La lista de comandos de un equipo es un retrato de cómo trabaja. Asegúrate de que el retrato sea favorecedor y fiel.

Para los microconsultores, los comandos son un excelente elemento de traspaso y un microencargo natural por derecho propio. Un encargo breve para identificar las tareas recurrentes de un equipo de desarrollo, escribir y probar un comando para cada una y formar al equipo en su uso es fácil de acotar, rápido de entregar e inmediatamente útil. También introduce al equipo en la idea de codificar sus flujos de trabajo, que es la puerta de entrada a encargos más grandes con skills, automatización y agentes.

Mira tu propio trabajo esta semana y encuentra dos cosas que le hayas pedido a Claude Code más de una vez con más o menos las mismas palabras. Convierte cada una en un comando, con un nombre claro y una breve descripción de cuándo usarlo. Luego úsalos durante una semana y refínalos. Cuando empieces tu próximo encargo con un cliente, lleva una lista de todo lo que el equipo pida dos veces. Al final del sprint esa lista es un kit de herramientas, y el kit es un entregable que el cliente no sabía que podía pedir.

Los conectores como manos

Durante mucho tiempo, el razonamiento no fue el cuello de botella. Un modelo podía deducir qué había que hacer; simplemente no llegaba a los sistemas donde se hacía. Los conectores cambian eso. A través del Model Context Protocol, un estándar abierto para conectar aplicaciones de IA con herramientas y datos, Claude puede leer incidencias, consultar bases de datos, mirar calendarios, buscar en repositorios de documentos y actualizar registros. Un asistente de código se convierte en algo más parecido a un operador, y un operador puede entregar una clase muy distinta de microencargos.

El Model Context Protocol, que suele abreviarse como MCP, define una forma común para que las herramientas y las fuentes de datos se presenten ante un modelo. Muchos servicios populares ofrecen ya conectores, y para los que no, un pequeño servidor a medida puede exponer exactamente las capacidades que quieres. En Claude Code añades servidores a un proyecto, y el agente puede usar sus herramientas junto a las que trae de serie. En las aplicaciones de Claude, los conectores llevan ese mismo alcance al trabajo diario.

En consultoría, los encargos interesantes suelen estar precisamente en este cruce. Un equipo de soporte cuyo asistente puede consultar el pedido del cliente antes de redactar una respuesta. Una responsable de operaciones cuyo agente puede leer el gestor de proyectos y escribir el resumen de estado semanal. Un desarrollador cuya sesión puede consultar a la vez el servicio de seguimiento de errores y el código pertinente. Nada de esto requiere ingeniería exótica. Requiere saber qué sistemas importan, conectarlos de forma segura y escribir las instrucciones que le digan al agente cómo usarlos.

La seguridad es el corazón del oficio. Un conector otorga capacidades reales en sistemas reales, y el principio de mínimo privilegio se aplica con toda su fuerza. Da acceso de lectura donde baste con leer. Acota el acceso de escritura a acciones concretas. Usa cuentas y credenciales creadas para ese fin, no el usuario personal de alguien. Mantén un paso de aprobación humana para todo lo que envíe, gaste o borre. Recuerda que el contenido obtenido de sistemas externos son datos, no instrucciones; un documento o un correo recuperado por una herramienta puede contener texto que intente dirigir al agente, y el sistema debe diseñarse teniéndolo en cuenta.

El alcance sin límites no es capacidad. Es un incidente esperando fecha.

Este es también un buen momento para ser claro con los clientes sobre lo que haces y lo que no. Conectar un agente a sus sistemas es un cambio en su postura de seguridad. Documenta qué conectores configuras, qué puede hacer cada uno, qué credenciales usan y cómo revocarlos. Ponlo en el manual de operaciones. Un cliente que puede ver exactamente a qué llega el agente, y cómo apagarlo, es un cliente que te confiará la siguiente conexión, más grande.

Esta semana, elige un sistema que consultes constantemente en tu propio trabajo, un gestor de tareas, un repositorio de documentos, un calendario, y conéctalo a Claude con los permisos más estrechos que sigan siendo útiles. Úsalo unos días y fíjate en qué tareas cambian. Luego imagina el mismo cambio para el equipo de un cliente. Esa imagen, descrita con claridad, es la propuesta de tu próximo encargo.

Desatendido en la CI

El mismo agente que te ayuda de forma interactiva puede funcionar sin supervisión. Claude Code puede operar en modo no interactivo, con un prompt y un conjunto de permisos, y devolver su resultado sin nadie al teclado. Mete eso en una canalización de integración continua y cada pull request puede revisarse, cada versión puede recibir un borrador de registro de cambios y cada compilación fallida puede tener un primer diagnóstico, automáticamente. Para un equipo de desarrollo pequeño, es un microencargo con un antes y un después clarísimos.

El punto de partida más habitual es la revisión automática. Cuando se abre una pull request, la canalización ejecuta Claude Code con instrucciones para revisar el diff según las convenciones del equipo, buscar problemas comunes y dejar comentarios. No sustituye a la revisión humana. Detecta lo que los humanos pasan por alto al leer en diagonal: la prueba que falta, el nombre incoherente, el error que se traga en silencio, el cambio en una interfaz que tiene llamadas en otra parte. Los revisores humanos pueden entonces dedicar su atención a las cuestiones que requieren criterio. Existe una integración oficial de Claude Code con GitHub que hace este tipo de configuración mucho más sencilla que construirla desde cero.

Otros usos vienen solos. Redactar las notas de versión a partir de los commits desde la última etiqueta. Clasificar las incidencias nuevas etiquetándolas y sugiriendo a qué parte del código afectan. Actualizar la documentación cuando cambia una interfaz. Ejecutar una comprobación programada que resuma las actualizaciones de dependencias. Cada una es una tarea pequeña y bien delimitada que se ejecuta sin supervisión y produce algo que revisa una persona. Ese es el patrón que hay que buscar: repetitivo, comprobable, de bajo riesgo si sale mal y útil si sale bien.

Las ejecuciones sin supervisión necesitan barreras más estrictas que las interactivas, porque nadie vigila cada paso. Restringe las herramientas que puede usar el agente a lo que requiere la tarea. Dale las credenciales más estrechas posibles. Haz que comente o proponga en lugar de fusionar o desplegar. Trata el contenido de las pull requests y las incidencias como entrada no fiable, porque cualquiera que pueda abrir una pull request puede poner texto delante del agente. Estas precauciones no son complicadas, pero tienen que ser deliberadas.

Un agente que revisa cada pull request no lo detectará todo. Eso sí, nunca estará demasiado ocupado, cosa que no puede decirse del resto del equipo.

Como encargo, es atractivo de vender y de entregar. Se puede acotar con precisión: configurar la revisión automática y las notas de versión para un repositorio, ajustar las instrucciones con las pull requests reales del equipo durante una semana, documentar cómo funciona y cómo ajustarlo, y hacer el traspaso. El resultado es visible en cada pull request desde el primer día. También crea una continuación natural, porque en cuanto un equipo ve a un agente haciendo trabajo útil sin supervisión, empieza a imaginar qué más podría hacer.

Pruébalo esta semana en un repositorio que controles. Configura una revisión no interactiva en las pull requests con permisos conservadores, ajusta las instrucciones con un puñado de cambios reales y mira qué detecta. Aprenderás cómo son unas buenas instrucciones para trabajo sin supervisión, y tendrás una demostración lista para el próximo equipo de desarrollo que pregunte qué podría hacer la IA por ellos.

El arreglo de flujo de trabajo

Junta esta parte y tienes uno de los microencargos centrales del libro: el arreglo de flujo de trabajo. Un flujo de trabajo doloroso y recurrente, diagnosticado, arreglado con Claude Code, verificado y traspasado, dentro de un alcance cerrado y un calendario corto. No un programa de transformación. No una migración de plataforma. Un flujo que hoy desperdicia horas cada semana, conseguido que desperdicie minutos.

Los buenos candidatos están por todas partes en cuanto miras. El informe mensual que alguien monta a mano a partir de tres exportaciones. El script que solo una persona sabe ejecutar, y que falla si el archivo de entrada trae una columna de más. El formulario de consultas cuyos envíos se copian en una hoja de cálculo y luego los reenvía por correo a la persona adecuada quien se dé cuenta. La limpieza de datos que ocurre cada lunes por la mañana. Cada uno es pequeño, concreto, medible y lo bastante doloroso como para que el cliente pague encantado por librarse de él.

El encargo sigue las jugadas de esta parte. Primero, diagnostica, con una llamada breve y viendo cómo se hace el flujo. Lee el repositorio, o los scripts y hojas de cálculo que componen el proceso actual. Escribe un archivo de memoria. Planifica el cambio y revisa el plan con el contacto técnico del cliente. Constrúyelo en diffs pequeños con verificación en cada paso. Conecta solo los sistemas necesarios, con los permisos más estrechos. Si encaja, añade un comando o una ejecución sin supervisión para que el flujo pueda lanzarse fácilmente o ejecutarse de forma programada. Después haz el traspaso con un manual de operaciones, un breve recorrido grabado y una sesión con la persona que se hará cargo.

La medición importa tanto como la construcción. Antes de empezar, cronometra el flujo actual, o pide al cliente que lo estime con honradez, y anota con qué frecuencia sale mal. Tras el traspaso, vuelve a medir. La diferencia, expresada en los términos del cliente, horas al mes, errores por trimestre, días de retraso evitados, es el resultado que comunicas y la prueba para tu próximo encargo. Un flujo arreglado sin resultado medido es un bonito favor. Un flujo arreglado con un antes y un después es un caso de éxito.

Arregla bien una cosa y el cliente te enseñará las otras nueve.

La disciplina del alcance lo es todo. El arreglo de flujo de trabajo funciona porque es un solo flujo. Cuando el cliente vea lo bien que ha ido y te pregunte por el proceso de al lado, es una noticia excelente, y es el próximo encargo, no una ampliación de este. Apúntalo en la lista. Menciónalo en la demo de cierre. Preséntale un presupuesto aparte. Una sucesión de arreglos pequeños, terminados y medidos genera mucha más confianza que un proyecto desparramado que nunca acaba de terminar.

Esta semana, escribe la descripción de una página de tu propia oferta de arreglo de flujos de trabajo: a qué tipo de flujos se adapta, qué aporta el cliente, qué entregas tú, cuánto dura, cómo se mide el éxito y qué suele venir después. Luego busca en tu propia práctica un flujo que puedas arreglar a modo de ensayo. El primero que arregles te enseñará más sobre acotar que cualquier capítulo.

Las skills ganan a los prompts

Un prompt es un mensaje. Una skill es una capacidad. La diferencia es que un prompt hay que buscarlo, copiarlo y pegarlo cada vez que lo necesitas, mientras que una skill espera en segundo plano y se carga sola cuando la tarea lo pide. En el momento en que pegas las mismas instrucciones en Claude por segunda vez, necesitabas una skill. A la quinta, llevas un buen rato haciendo a mano el trabajo de las herramientas.

En el mundo de Claude, una skill es una carpeta que contiene un archivo de instrucciones breve, con un nombre y una descripción en la parte superior, más el material de apoyo que necesite: documentos de referencia, plantillas, ejemplos, scripts. Claude ve los nombres y las descripciones de las skills disponibles y, cuando una tarea encaja, lee las instrucciones completas y las sigue. Las skills funcionan en las aplicaciones de Claude, en Claude Code y en la plataforma para desarrolladores, así que la misma capacidad puede viajar contigo, y con tus clientes, de una superficie a otra.

El efecto práctico es que la pericia deja de depender de la memoria. Piensa en un consultor que escribe sus informes de auditoría con una estructura concreta, con una tabla ordenada de oportunidades, una nota de riesgo por elemento y una lista de aparcados. Como prompt, esa estructura vive en un documento que tiene que acordarse de pegar. Como skill, se carga cada vez que le pide a Claude que redacte un informe de auditoría, con la plantilla, un buen ejemplo y la rúbrica de puntuación incluidos. Las instrucciones se aplican de forma coherente, tanto si es su primer informe de la semana como si es el decimoquinto, y tanto si recuerda los detalles como si no.

Las skills también cambian lo que un consultor puede entregar. Una biblioteca de prompts ayuda, pero depende de que la gente la use correctamente. Una biblioteca de skills se parece más a un grupo de colegas formados: el equipo del cliente pide un resumen de proveedor o una comprobación de cumplimiento en lenguaje llano, y las instrucciones adecuadas llegan solas. La pericia que codificaste se aplica sin que nadie tenga que saber que existe. Es un salto cualitativo en cuánto de tu valor sobrevive cuando te vas.

Un prompt es un consejo que tienes que acordarte de seguir. Una skill es un consejo que llega puntual.

No todo tiene que ser una skill. Las preguntas puntuales, las conversaciones exploratorias y las tareas que de verdad son distintas cada vez funcionan bien como prompts normales. Las skills se ganan su sitio en el trabajo recurrente con una forma estable: informes, revisiones, análisis, tipos de documento, comprobaciones, transformaciones. Una buena prueba es si podrías poner por escrito cómo es lo excelente para esa tarea y que siguiera valiendo para las próximas veinte veces. Si puedes, es una skill esperando a ser escrita.

Esta semana, vuelve a tu biblioteca de prompts de la segunda parte y localiza los tres que más usas. Convierte uno en skill: una carpeta, un archivo de instrucciones con un nombre y una descripción claros, y los ejemplos y plantillas que necesite. Úsala durante una semana. Fíjate en si se activa cuando esperas y en si la salida es tan coherente como esperabas. Los próximos capítulos explican cómo hacer fiables ambas cosas. El primer paso es simplemente dejar de pegar.

La descripción que la activa

Una skill que nunca se activa no vale nada. Las instrucciones que contiene pueden ser impecables, las plantillas preciosas y los ejemplos perfectamente elegidos, pero si Claude no reconoce cuándo usarla, nada de eso importa. La descripción en la parte superior del archivo de la skill es lo que Claude lee para decidir, lo que la convierte en el texto más importante de toda la skill. No es documentación. Es el disparador.

Piensa en cómo se toma la decisión. Claude ve las descripciones de las skills que tiene a su disposición junto con la petición del usuario. Si una descripción encaja claramente con lo que el usuario pide, la skill se carga. Si es vaga, genérica o está formulada en términos que el usuario nunca usaría, la skill se queda sin usar. La descripción tiene que tender un puente entre cómo piensas tú en la skill y cómo pedirá la gente de verdad lo que hace.

Así que escribe las descripciones en el lenguaje de las peticiones. Di qué hace la skill y cuándo usarla, e incluye después las formulaciones exactas, los sinónimos y las peticiones vecinas que deberían despertarla. Una skill para redactar informes de auditoría podría mencionar informes de auditoría, revisiones de preparación para la IA, evaluaciones de oportunidades y peticiones como pon por escrito las conclusiones de las entrevistas. Una skill para resúmenes de proveedores podría mencionar fichas de proveedor, resúmenes de una página y qué sabemos de este proveedor. Los usuarios reales dicen las cosas de muchas maneras. La descripción debería anticipar la mayoría.

Igual de importante: di cuándo no usar la skill. Si dos skills cubren territorios vecinos, cada descripción debe dejar clara la frontera: esta es para auditorías iniciales, la otra para informes de progreso. Los solapamientos ambiguos hacen que se active la skill equivocada, lo cual es en cierto modo peor que ninguna, porque la salida tendrá con total seguridad la forma de otra tarea.

La descripción es la puerta de entrada. Nadie admira los muebles de una casa que no encuentra.

Prueba la activación a propósito. Escribe una lista de diez o quince peticiones que deberían invocar la skill, formuladas como las formularían personas distintas, y unas cuantas que no deberían. Pruébalas. Anota cuáles fallan y ajusta la descripción hasta que la mayoría den en el blanco. Lleva quizá media hora por skill y marca la diferencia entre una biblioteca que funciona y una que la gente abandona al cabo de una semana porque no es fiable.

En el trabajo con clientes, implica en estas pruebas a las personas que van a usar la skill. Pregúntales cómo pedirían la tarea de forma natural y usa sus palabras en la descripción. Un equipo de finanzas puede decir el paquete de cierre donde tú habrías escrito informe de resumen financiero. Si la descripción usa tu vocabulario en lugar del suyo, la skill se activará para ti durante la demo y les fallará a ellos después, que es el peor orden posible de los acontecimientos.

Coge la skill que escribiste tras el capítulo anterior y reescribe su descripción con esto en mente. Enumera las formas en que tú, y otros, pedís realmente esa tarea, e incorpóralas. Luego pruébala con una docena de peticiones variadas. Probablemente encuentres algunos fallos. Arréglalos, y la skill pasará de experimento interesante a herramienta que aparece cuando hace falta, que era de lo que se trataba.

Revelación progresiva

El contexto es finito, y las skills deberían respetarlo. Una skill que vuelca cuarenta páginas de instrucciones en la conversación cada vez que se activa desplaza el material que la tarea necesita de verdad. El mejor diseño es la revelación progresiva: un archivo base breve que cubre lo que requiere casi cualquier uso, con referencias detalladas guardadas en archivos aparte que el modelo solo lee cuando una situación concreta lo exige. Las instrucciones, en otras palabras, deberían evaluarse de forma perezosa.

Las skills están hechas para esto. Hasta que una skill se activa, solo son visibles su nombre y su descripción. Después se lee el archivo de instrucciones principal. Dentro de ese archivo puedes señalar otros archivos de la carpeta de la skill: para clientes financieros regulados, lee la referencia de cumplimiento antes de redactar, si el usuario pide una versión en diapositivas, sigue la plantilla de la guía de diapositivas. Esos archivos solo se leen cuando se cumple la condición. Una petición sencilla usa las instrucciones base; una inusual atrae exactamente el detalle adicional que necesita.

Este diseño tiene varias ventajas. Mantiene el contexto ligero, de modo que el modelo atiende como es debido a la tarea que tiene delante. Hace que la skill sea más fácil de mantener, porque cada archivo de referencia tiene un único propósito y puede actualizarse por separado. Y permite que una skill crezca para cubrir muchos casos sin volverse inmanejable, porque los casos viven en sus propios archivos en lugar de amontonarse en un documento largo que nadie quiere leer.

Escribir un buen archivo base es una disciplina. Pon lo que se aplica siempre: el propósito, los pasos principales, el formato de salida, el listón de calidad. Deja fuera lo que solo se aplica a veces y sustitúyelo por una indicación clara. Mantenlo lo bastante breve como para poder leerlo en un par de minutos. Si el archivo base no para de crecer, busca secciones que solo se apliquen en circunstancias concretas y trasládalas a referencias.

Dile al modelo lo que necesita siempre. Dile dónde buscar el resto. Y luego confía en que buscará.

Esta estructura encaja especialmente bien con la consultoría, porque los encargos de los clientes varían de formas previsibles. Una skill base para redactar informes de auditoría podría tener referencias para distintos sectores, distintas extensiones de informe y distintos públicos. Una skill, muchas situaciones, con el detalle adecuado llegando en cada una. Cuando te especializas en un sector, la referencia sectorial se convierte en un registro concentrado de todo lo que has aprendido sobre ese tipo de cliente, que solo se carga cuando es pertinente.

También hace el traspaso más limpio. Un cliente que recibe una biblioteca de skills puede ver de un vistazo qué hace cada skill por su archivo base, y puede encontrar y actualizar la referencia concreta que haya que cambiar cuando cambie su negocio, sin tocar el resto. Una skill organizada así es más fácil de entender, más fácil de confiar y más fácil de hacer propia.

Esta semana, mira tu skill o tu prompt más largo. Marca cada sección como siempre necesaria o necesaria a veces. Traslada las secciones de a veces a archivos de referencia aparte, con una indicación clara en el archivo base. Ejecútalo con un caso sencillo y con uno inusual. El sencillo debería ser más rápido y más limpio; el inusual debería seguir recibiendo el detalle que necesita. Eso es el diseño funcionando.

Empaqueta los scripts

El trabajo determinista va en código, no en tokens. Si un paso de una tarea funciona siempre igual, convertir un formato de archivo, validar una estructura de datos, calcular un total, renombrar archivos según un patrón, el modelo no debería volver a deducirlo cada vez. Incluye un script dentro de la skill y deja que el modelo lo llame. El modelo aporta criterio; el script aporta precisión. Cada uno hace aquello en lo que es bueno.

Las skills pueden incluir scripts ejecutables junto a sus instrucciones. Cuando la skill se ejecuta en un entorno con ejecución de código disponible, las instrucciones pueden decirle a Claude que ejecute un script concreto para un paso concreto: para comprobar que la exportación es válida, ejecuta el script de validación e informa de cualquier error, para producir la hoja de cálculo final, ejecuta el script de construcción con los datos limpios. El código del script no tiene por qué estar en la conversación; solo su salida, lo que también mantiene el contexto ligero.

Las ventajas son considerables. Los scripts son fiables: la misma entrada produce la misma salida siempre, sin ninguna posibilidad de interpretación creativa. Son rápidos y baratos, porque ejecutar unas pocas líneas de código cuesta mucho menos que hacer que un modelo razone la misma transformación. Se pueden probar de la manera habitual. Y codifican lógica precisa, como una regla de cálculo concreta o un formato de archivo estricto, que es exactamente el tipo de cosa que un modelo puede aproximar en lugar de reproducir.

Para los consultores, esto cambia lo que una skill puede entregar. Una skill que produce el informe mensual de un cliente puede incluir un script que extrae las cifras de una exportación, calcula las métricas acordadas y genera un gráfico, mientras el modelo escribe el comentario y señala cualquier cosa inusual. Una skill que revisa contratos frente a una política puede incluir un script que extrae las cláusulas a un formato estructurado antes de que el modelo las revise. La combinación es más fiable que cualquiera de las partes por separado, y mucho más fiable que pedirle al modelo que lo haga todo en prosa.

Deja que el modelo decida qué hacer. Deja que el código haga las partes que deben hacerse exactamente igual cada vez.

Claude también puede escribir los scripts, por supuesto. Un patrón sensato es ver al modelo hacer una tarea unas cuantas veces, fijarte en qué pasos son mecánicos y pedirle que escriba un script para esos pasos, con pruebas. Luego actualiza la skill para que llame al script. Con el tiempo, tus skills van acumulando pequeñas herramientas bien probadas que las hacen más rápidas y fiables con cada encargo.

Una advertencia para los traspasos a clientes: los scripts son código, y el código necesita un responsable. Documenta qué hace cada script, qué necesita para ejecutarse y cómo probarlo. Reduce las dependencias al mínimo. Si el equipo del cliente no puede mantener código, opta por scripts más sencillos y asegúrate de que la skill falle de forma clara, con un mensaje útil, si un script se rompe. Una skill que produce resultados erróneos en silencio porque ha fallado un script es peor que una que ni lo intenta.

Esta semana, busca en una de tus tareas recurrentes un paso puramente mecánico. Pídele a Claude que escriba un pequeño script para él, con una prueba, y empaquétalo en la skill correspondiente. Vuelve a ejecutar la tarea. Fíjate en cuánto más coherente se vuelve ese paso. Luego busca el siguiente.

El abanico de subagentes

Hay trabajo que se divide de forma natural en piezas independientes. Revisar doce contratos de proveedores. Resumir entrevistas con ocho empleados. Analizar cinco años de incidencias de soporte, año a año. Hacer esto en una sola conversación larga llena el contexto con detalles de cada pieza, de modo que cuando llegas a la última el modelo va vadeando todo lo anterior. El mejor patrón es el abanico: entrega cada pieza a un subagente con un contexto limpio y haz que un orquestador recoja los resultados.

En Claude Code, los subagentes son asistentes especializados en los que el agente principal puede delegar tareas. Cada uno funciona en su propio contexto, con sus propias instrucciones y su propio conjunto de herramientas permitidas, y devuelve un resumen en lugar de todo su trabajo intermedio. La conversación principal se queda con el plan y los resultados, no con el ruido. Puedes definir subagentes a medida para funciones recurrentes, un revisor de contratos, un resumidor de entrevistas, un redactor de pruebas, cada uno con un encargo bien enfocado.

El patrón encaja especialmente bien con el trabajo de auditoría. Durante una auditoría de pago puedes tener una docena de transcripciones de entrevistas y un montón de documentos de procesos. Reparte las transcripciones entre subagentes, cada uno de los cuales produce un resumen estructurado con el mismo formato: temas, puntos de dolor, citas, oportunidades sugeridas. Luego haz que el orquestador, o tú, sintetice a partir de los resúmenes. Cada transcripción recibe toda la atención; la síntesis recibe una visión limpia de todas. Lo que antes eran días de lectura se convierte en una tarde de revisión.

La clave de un buen abanico es un encargo coherente para los trabajadores y una forma coherente para su salida. Si cada subagente devuelve su resumen con una estructura distinta, la síntesis se vuelve más difícil en lugar de más fácil. Define el formato de salida con precisión, idealmente con un ejemplo, y haz que sea el mismo para todos los trabajadores. Dale a cada uno solo el contexto que necesita para su pieza, más los antecedentes compartidos, y nada más.

Un agente que lo sostiene todo es un malabarista. Un orquestador con trabajadores es una cocina. Las cocinas dan de comer a más gente.

Hay costes que sopesar. Cada subagente consume sus propios recursos, así que repartir tareas triviales es un despilfarro. El trabajo en paralelo también produce errores en paralelo: si el encargo tiene un fallo, todos los trabajadores lo heredan. Prueba el encargo con una pieza antes de enviarlo a doce. Y haz que el paso de síntesis, lo haga el orquestador o lo hagas tú, sea honesto con los desacuerdos y las lagunas entre las salidas de los trabajadores, en lugar de alisarlos en una conclusión falsamente ordenada.

Para los clientes, el abanico suele ser invisible, pero sus efectos no. Es lo que permite que un encargo de dos semanas maneje un volumen de material que antes habría necesitado un equipo. También aparece en los sistemas que construyes: un piloto de agentes que procesa un lote de documentos podría usar exactamente este patrón por debajo. Esta semana, busca en tu propio trabajo una tarea que se divida en piezas independientes. Escribe un encargo, pruébalo con una pieza y luego repártelo en abanico. Compara el resultado, y el tiempo que llevó, con hacerlo todo en una sola conversación.

El subagente verificador

Un agente construye; otro comprueba, con ojos nuevos y sin apego al trabajo. La autorrevisión es débil, en los modelos y en las personas. El autor de un trabajo sabe lo que quería decir y lo proyecta en lo que escribió. Un revisor con un contexto limpio y una rúbrica clara solo ve lo que realmente hay. La revisión adversarial desde un contexto independiente es una de las jugadas de calidad más eficaces al alcance de alguien que trabaja solo.

El patrón es sencillo de montar. Cuando se termina un trabajo de cierta entidad, un informe, un conjunto de cambios en el código, un lote de documentos procesados, entrégaselo a un subagente aparte cuya única función sea verificar. Dale el encargo original, la definición de «terminado» y una rúbrica, y pídele que encuentre problemas: afirmaciones que la fuente no respalda, requisitos omitidos, incoherencias, casos límite no tratados, pruebas que pasan por el motivo equivocado. Pídele que sea concreto y que cite pruebas. Luego revisa tú sus hallazgos y decide sobre cuáles actuar.

La independencia del verificador es la clave. No debería ver el razonamiento del constructor ni la conversación que produjo el trabajo, solo el trabajo y los criterios. Así no puede dejarse convencer por las justificaciones del constructor. Juzga la salida por sus méritos. En la práctica, a menudo detecta cosas que se les escaparon tanto al constructor como a ti, porque ninguno de los dos podía dejar de ver lo que pretendía.

En los entregables de consultoría, es un seguro barato contra el tipo de fallo más bochornoso: una afirmación rotunda en un informe para un cliente que resulta ser falsa. Pasa cada documento importante por un verificador con la instrucción de contrastar cada afirmación factual con el material de origen proporcionado y señalar las que no estén respaldadas. Pasa cada cambio de código significativo por un verificador con las pruebas, los requisitos y la instrucción de buscar lo que las pruebas no cubren. El verificador a veces dará falsas alarmas. Es un precio pequeño.

El constructor quiere que el trabajo sea bueno. El verificador solo quiere saber si lo es. Necesitas a los dos, en habitaciones separadas.

Los verificadores también pueden formar parte de los sistemas que entregas. Un piloto de agentes que redacta respuestas a clientes puede incluir un paso de verificación que compruebe cada borrador frente a la política antes de que lo vea una persona, señalando los que requieren más atención. Eso hace que la revisión humana sea más rápida y más centrada, y le da al cliente una capa de calidad medible que puede ver funcionando. También facilita las pruebas de aceptación, porque la rúbrica del verificador sirve a la vez de criterio de aceptación.

Sé honesto con los límites. Un verificador construido sobre el mismo modelo puede compartir algunos de los puntos ciegos del constructor, y no puede comprobar hechos a los que no tiene acceso. Es una segunda línea de defensa, no una garantía. Tu propia revisión, y la del cliente, siguen siendo esenciales para todo lo que importa. Esta semana, coge lo próximo de cierta entidad que produzcas y entrégaselo a un verificador nuevo con una rúbrica y la instrucción de encontrar problemas. Lee lo que vuelva con la mente abierta. Puede que te moleste un poco. Casi seguro que saldrás ganando.

Una skill, muchos arneses

Una skill que solo puedes ejecutar en un sitio es un truco ingenioso. Una skill que puedes ejecutar en la aplicación de escritorio, en Claude Code, en una canalización automatizada y a través de la plataforma para desarrolladores es un activo que da intereses compuestos. La portabilidad es lo que convierte un prompt bien escrito en infraestructura, y cada vez es más alcanzable porque las skills comparten un formato común en todas las superficies de Claude.

Piensa en cómo puede viajar una sola skill a lo largo de un encargo. Escribes una skill que produce el resumen semanal de operaciones de un cliente a partir de un conjunto de exportaciones. Durante el sprint de desarrollo la ejecutas en Claude Code mientras la desarrollas y la pruebas. La responsable de operaciones del cliente la usa en la aplicación de Claude los lunes por la mañana. Más adelante se ejecuta en un trabajo automatizado que produce el resumen antes de que nadie llegue a la oficina. Mismas instrucciones, mismas plantillas, mismos scripts; tres formas muy distintas de invocarlos. Cada mejora que haces llega a las tres.

Escribir pensando en la portabilidad exige un poco de cuidado. Mantén las instrucciones independientes de cualquier interfaz: no des por hecho que existe un botón o un comando concreto. Haz que los scripts funcionen en un entorno estándar con dependencias mínimas. Describe explícitamente las entradas y las salidas, para que la skill funcione tanto si una persona aporta los archivos en un chat como si una canalización los aporta automáticamente. Y anota arriba cualquier requisito específico del entorno, como la ejecución de código o el acceso a la red, para que quien instale la skill sepa qué necesita.

Esto importa en lo comercial tanto como en lo técnico. Un cliente que compra una biblioteca de skills quiere que siga funcionando a medida que madura su uso de la IA. Hoy su equipo quizá use la aplicación de Claude; dentro de un año quizá haya automatizado la mitad de sus informes. Las skills escritas para ser portables se mueven con ellos. Las skills soldadas a una sola superficie hay que reescribirlas, lo cual es o un coste para el cliente o, si las construiste mal, un bochorno discreto para ti.

Escríbela una vez y ejecútala allí donde ocurra el trabajo. Cualquier otra cosa es una reescritura que has programado sin darte cuenta.

Hay límites, claro. Algunas capacidades solo están disponibles en ciertos entornos, y algunas tareas solo tienen sentido de forma interactiva. No todas las skills necesitan ejecutarse en todas partes. El objetivo es evitar la dependencia accidental, en la que una skill solo funciona en un sitio porque nadie pensó en los demás, no obligar a cada skill a meterse en cada arnés tenga sentido o no.

La portabilidad también beneficia a tu propia práctica. Tus skills personales, el redactor de informes de auditoría, el redactor de propuestas, el constructor de casos de éxito, son más útiles si funcionan dondequiera que estés: en tu mesa con la aplicación, en una terminal durante un encargo de programación o en el móvil entre reuniones. Esta semana, coge una de tus skills y pruébala en una segunda superficie. Anota qué se rompe, arréglalo para que funcione en ambas y apunta los requisitos en la parte superior del archivo de la skill. La segunda superficie es la más difícil. Después, las demás suelen venir solas.

Versiona tu canon

Las skills se desvían. Mejoras una en el portátil, te olvidas de copiar el cambio a la carpeta compartida, retocas otra copia para un cliente, y tres semanas después tienes tres versiones de la misma skill, cada una ligeramente distinta, ninguna claramente la última. Cuando algo sale mal, estás depurando tres verdades distintas. La cura es poco glamurosa y totalmente eficaz: pon tus skills bajo control de versiones, trata un repositorio como el canon y sincroniza desde él de forma deliberada.

Git es el hogar obvio. Cada skill es una carpeta; el repositorio las contiene todas. Cada cambio es un commit con un mensaje que explica el porqué. Las versiones pueden etiquetarse, de modo que puedes decir con certeza qué versión está usando un cliente. Cuando un cambio empeora las cosas, puedes ver exactamente qué cambió y revertirlo. Es práctica básica de software, y se aplica a las skills porque las skills son, en todos los sentidos importantes, software: instrucciones y código de los que dependen otras personas y sistemas.

El canon también te da un proceso claro de distribución. En lugar de copiar las skills a mano a cada lugar donde se usan, sincronizas desde el repositorio: a tus propias máquinas, a las ubicaciones compartidas de skills de tu equipo, al entorno de cada cliente. Los plugins pueden empaquetar skills, comandos y otras extensiones en un paquete que se instala de forma coherente. Sea cual sea el mecanismo que uses, el principio es el mismo. Los cambios fluyen hacia fuera desde una única fuente. Nadie edita una copia desplegada y la deja ahí.

Las bibliotecas de skills de los clientes merecen sus propios repositorios, separados del tuyo. Las skills de un cliente contienen su contexto, sus ejemplos y a veces sus procesos confidenciales. Deben vivir donde el cliente las controle, con tus skills de propósito general suministradas como dependencia aparte y versionada si hace falta. Esa separación protege la información del cliente, mantiene limpio tu propio canon y deja claro qué es de quién cuando termina el encargo.

Si no puedes decir qué versión se está ejecutando, no tienes una skill. Tienes un rumor.

Un registro de cambios ayuda a todo el mundo. Una nota breve en la parte superior de cada skill, o en el repositorio, que recoja qué cambió en cada versión y por qué, facilita que el equipo del cliente entienda las actualizaciones y que tú recuerdes por qué existe una línea concreta. También sostiene la conversación sobre la iguala: una lista mensual de mejoras en las skills del cliente es un registro tangible de valor continuo.

También hay un ángulo de pruebas. Cada skill puede llevar un pequeño conjunto de casos de prueba, entradas y cualidades esperadas de la salida, que ejecutas antes de etiquetar una versión nueva. Cuando aparezca un modelo nuevo, ejecuta las pruebas en todo tu canon y mira qué skills mejoran, cuáles se quedan igual y cuáles necesitan ajustes. Así es como conviertes las actualizaciones de modelo en mejoras y no en sorpresas.

Esta semana, si tus skills aún no están en un repositorio, ponlas ahí. Una carpeta por skill, un registro de cambios breve, una primera etiqueta. Luego elige un lugar donde uses skills y haz que se sincronice desde el canon en vez de guardar su propia copia. Es una tarde aburrida. Te ahorrará muchísimas tardes confusas.

Las skills como entregable

Los clientes pagan por resultados, pero se quedan con activos. Un informe describe lo que podría hacerse. Un kit de prompts ayuda a la gente a hacerlo. Una biblioteca de skills hace buena parte por ellos, cada vez, en su lenguaje y con su nivel de exigencia. Entregar una biblioteca de skills que funciona vale más que cualquier informe, y es un tipo de entregable completamente distinto: no un consejo sobre el trabajo, sino una capacidad duradera que lo realiza.

Un encargo de biblioteca de skills suele empezar donde termina una auditoría o un kit de prompts. La auditoría identificó las tareas recurrentes; el kit de prompts le dio al equipo mejores formas de pedirlas. La biblioteca de skills codifica lo mejor de esas tareas como skills: cada una con una descripción de activación en las palabras del propio equipo, instrucciones base, referencias para los casos inusuales, ejemplos de salidas excelentes, scripts empaquetados para los pasos mecánicos y casos de prueba de calidad. El equipo pide entonces el trabajo en lenguaje llano y obtiene una salida que cumple el nivel que acordó contigo.

La entrega sigue los patrones de esta parte. Empieza por las cinco o diez tareas recurrentes más valiosas, no por todas las que se te ocurran. Para cada una, reúne ejemplos reales y la definición de lo bueno que tiene el cliente. Escribe la skill, prueba su activación con las personas que la van a usar, prueba su salida con entradas reales y refínala. Pon la biblioteca en un repositorio que controle el cliente, con un registro de cambios y una guía breve. Forma al equipo y nombra a un responsable interno que pueda hacer cambios pequeños y sepa cuándo llamarte para los grandes.

La forma del precio importa aquí, como se trata en la octava parte. Una biblioteca de skills es un activo que ahorrará tiempo cada día laborable, y su precio debe fijarse en función de ese valor, no de las horas que te llevó escribirla. Algunos consultores ofrecen además un pequeño acuerdo continuo para mantener y ampliar la biblioteca a medida que cambia el negocio y mejoran los modelos. Es un trabajo honesto, porque las skills necesitan cuidados, y convierte una entrega puntual en una relación.

Un informe se lee una vez. Una skill se usa cada mañana. Ponle precio en consecuencia, y entrégala en consecuencia.

Hay una cuestión de propiedad que conviene dejar resuelta al principio. El cliente debería ser dueño de las skills construidas a partir de su contexto y sus ejemplos. Tú quizá quieras conservar el derecho a reutilizar las técnicas generales y las skills genéricas que aportaste al encargo. Dilo claramente en el acuerdo. La mayoría de los clientes están perfectamente cómodos con este arreglo cuando se les explica de antemano, y nadie está cómodo cuando sale por primera vez en el traspaso.

Una biblioteca de skills también es una prueba excelente. Cada skill puede demostrarse, su salida puede enseñarse y su ahorro de tiempo puede medirse. Un caso de éxito que dice construimos ocho skills que el equipo usa ahora a diario, reduciendo la preparación de informes de un día a una hora es concreto, creíble y fácil de imaginar para el siguiente posible cliente en su propio negocio.

Esta semana, imagina que tu encargo más reciente hubiera terminado con una biblioteca de skills en lugar de lo que realmente entregaste. ¿Qué cinco skills contendría? Escribe los nombres y las descripciones. Si salen con facilidad, acabas de diseñar tu próxima oferta.

El piloto de agentes

El piloto de agentes es el microencargo más ambicioso de este libro, y el que más preguntan los clientes. Han oído que los agentes pueden hacer trabajo, no solo responder preguntas, y quieren saber si uno podría hacer parte del suyo. El piloto responde a esa pregunta en un plazo fijo, con trabajo real y con un resultado medido. Bien hecho, es el encargo más persuasivo que puedes vender. Mal hecho, es una demostración cara de por qué la gente desconfía de la palabra agente.

Elige la tarea con cuidado. Una buena tarea piloto es frecuente, acotada y comprobable. Clasificar las consultas entrantes y redactar las primeras respuestas. Conciliar dos fuentes de datos e informar de las discrepancias. Procesar un lote de documentos de proveedores y extraer los términos clave a un registro. Cada una tiene entradas claras, una salida clara y una forma de saber si la salida es correcta. Evita las tareas en las que los errores sean costosos y difíciles de detectar, o en las que el éxito dependa de un criterio que el cliente no sabe articular. Esas vienen después, si es que vienen.

Ejecuta el piloto con trabajo real del pasado reciente, no con casos hipotéticos. Toma una muestra de las consultas, documentos o registros del mes pasado, con permiso del cliente y el tratamiento de datos adecuado, y deja que el agente los procese. Compara su salida con lo que hizo realmente el equipo, usando una rúbrica acordada de antemano con el cliente. Eso te da una imagen justa, concreta y medible: con qué frecuencia acertó el agente, dónde se equivocó y cuánto tiempo habría ahorrado. Después, si los resultados lo justifican, ejecútalo en paralelo con el trabajo en vivo durante una semana, con una persona aprobando cada salida.

Todo lo de este libro confluye aquí. Un encargo claro y una salida acotada, de la segunda parte. Contexto seleccionado y conocimiento del proyecto, de la tercera. Trabajo cuidadoso en el repositorio, de la cuarta. Skills, scripts, subagentes y un verificador, de esta. Barreras de seguridad, puntos de control humanos y evaluaciones, de la séptima. Un piloto no es un único prompt ingenioso. Es un sistema pequeño y bien construido por el que fluye el trabajo real del cliente.

Un piloto es un experimento con una hipótesis, un método y un resultado. Cualquier otra cosa es una demo con una factura más larga.

Define antes de empezar la decisión que respalda el piloto. La pregunta no es ¿funcionan los agentes?, sino algo como ¿puede un agente redactar primeras respuestas aceptables para la mayoría de las consultas rutinarias, con una persona aprobando cada una, reduciendo de forma significativa el tiempo de respuesta? Fija el umbral que justificaría seguir adelante. Al final, informa con honradez frente a él. A veces la respuesta es no, o todavía no, y decirlo con claridad, con pruebas, genera más confianza que un sí estirado.

Cuando la respuesta es sí, el siguiente paso es evidente y lo diseñaste al principio: una iguala para operar, vigilar y mejorar el sistema, o un sprint para ampliarlo. Esta semana, esboza un piloto de agentes para un cliente que conozcas: la tarea, la muestra, la rúbrica, el umbral, las barreras de seguridad. Si cabe en una página, puedes venderlo. Si no, el piloto es demasiado grande. Encoge la tarea hasta que quepa.

La demo es la presentación

Un prototipo que funciona cierra tratos que las diapositivas solo pueden describir. Enséñale a un comprador una presentación sobre cómo un asistente podría clasificar sus consultas y asentirá cortésmente antes de preguntar por la seguridad. Enséñale al asistente clasificando cinco de sus propias consultas, en una pantalla, mientras mira, y la conversación pasa del «si» al «cuándo». La gente cree mucho antes lo que ve que lo que le cuentan, y con Claude enseñar es ya lo bastante barato como para hacerlo antes de cobrar.

Es un cambio real en la economía de la venta. Hace unos años, construir un prototipo convincente costaba días de trabajo de un desarrollador, lo que significaba que solo podías permitírtelo cuando el cliente ya se había comprometido. Ahora, un prototipo interactivo de una sola página, un pequeño script que funciona o una muestra realista de resultados pueden producirse en una o dos horas. El coste de enseñar ha caído por debajo del coste de explicar. La mayoría de los consultores aún no han ajustado su proceso de venta en consecuencia.

El prototipo no tiene por qué estar completo. Tiene que responder a la pregunta real del comprador, que suele ser alguna variante de ¿esto nos funcionaría a nosotros? Eso significa que debe usar su tipo de datos, su vocabulario y su flujo de trabajo, aunque solo funcione un camino. Una demo que procesa una versión realista de sus facturas es mucho más persuasiva que una demo genérica y pulida que procesa las de otro. Lo específico es lo que la hace creíble.

Usa también la demo como herramienta de diagnóstico. Mientras el comprador mira, reaccionará: ese es exactamente nuestro problema, o así no lo hacemos nosotros, o qué pasa cuando el proveedor manda una imagen escaneada. Cada reacción es información sobre los requisitos reales, ofrecida gratis y con entusiasmo, una combinación poco frecuente. Apúntala. La mitad de tu documento de alcance saldrá de los comentarios que hace un comprador mientras ve un prototipo.

Las diapositivas le piden al comprador que imagine. Las demos le dejan reconocer. Reconocer es más rápido.

Hay fronteras honestas que respetar. No dejes nunca que un prototipo dé a entender que la versión de producción está terminada. Di claramente qué es real, qué está simulado y qué haría falta para hacerlo robusto. Un comprador que descubre más tarde que la impresionante demo se sostenía con datos de muestra y buenas intenciones no se fiará de tu próxima estimación. Un comprador al que se le dijo exactamente lo que estaba viendo confiará más en ti por haber sido franco.

Esta parte del libro trata del oficio de construir y entregar estas cosas: prototipos de un solo archivo, datos realistas, flujos en los que se puede hacer clic, artefactos enfocados, compartirlos como enlaces, convertirlos en documentos que se quedan, verificarlos y, en el extremo, construir en la propia reunión. Todo ello sirve al mismo principio. Esta semana, en tu próxima conversación de venta, prepara una pequeña demostración en lugar de más diapositivas. Usa el tipo de datos del comprador. Enseña una cosa funcionando. Luego deja de hablar y mírale la cara. Ese es el momento en que de verdad se produce la venta.

Prototipos de un solo archivo

Un archivo, sin paso de compilación, funciona en cualquier sitio donde puedas abrirlo. Esa restricción es el secreto de los prototipos rápidos. La configuración es donde los prototipos van a morir: instalar frameworks, configurar herramientas, conectar una base de datos, desplegar en un servidor. Todo eso acaba siendo necesario y nada de ello es necesario para responder a la pregunta para la que existe un prototipo. Un solo archivo lo esquiva todo.

En la práctica, esto significa una única página HTML con sus estilos y scripts incluidos, o un único componente de React que se puede mostrar como artefacto en Claude, o un único script que se ejecuta desde la línea de comandos. Claude es muy bueno produciendo esto. Describe la herramienta, los datos con los que trabaja y la interacción principal, y normalmente obtendrás una primera versión que funciona en una sola respuesta. Pide cambios conversando. En una hora puedes tener algo que se parezca y se comporte lo bastante como lo real para enseñárselo a un cliente.

Los artefactos de Claude lo hacen especialmente cómodo. Un prototipo construido como artefacto puede verse, probarse y refinarse en el mismo sitio donde lo creaste, y publicarse como una página que puedes compartir. Puedes iterar con el cliente durante una llamada: sugiere un cambio, lo pides, y el prototipo se actualiza mientras mira. La restricción de un solo archivo mantiene cada cambio rápido y el conjunto fácil de entender.

La disciplina consiste en resistirse a hacerlo crecer. Una vez que un prototipo funciona, la tentación es añadir funciones hasta que es casi un producto, todavía en un solo archivo, ahora de varios miles de líneas e imposible de mantener. Es una trampa. El trabajo de un prototipo es responder a una pregunta y luego tirarse o reconstruirse como es debido. Cuando el cliente diga que sí y empiece la construcción de verdad, arranca la versión de producción con la estructura, las pruebas y el despliegue adecuados. Conserva el prototipo como referencia de lo que aprobó el cliente.

Un prototipo es un argumento, no unos cimientos. Constrúyelo tan rápido que tirarlo no duela.

Para los microconsultores, la costumbre del archivo único tiene otra ventaja: convierte el propio prototipo en un entregable portátil. Un cliente puede abrirlo, reenviarlo, enseñárselo a su jefe, sin que nadie tenga que instalar nada. Muchos encargos pequeños, una calculadora, una herramienta de decisión, un panel interno sobre un conjunto de datos fijo, pueden entregarse como un único archivo pulido y nunca necesitar crecer más allá. No subestimes cuántos problemas de negocio se resuelven con una página única bien hecha.

Las restricciones también ayudan a Claude. Una petición para construir una herramienta de un solo archivo sin dependencias externas más allá de unas pocas bibliotecas conocidas produce código enfocado y legible. Una petición para construir una aplicación sin restricciones produce algo desparramado. Dile la forma que quieres y construirá con esa forma.

Esta semana, elige una pequeña herramienta que llevas tiempo queriendo construir, para ti o para un cliente, y constrúyela como un único archivo con Claude de una sentada. Cronometra cuánto tardas. La mayoría de la gente se sorprende, y le fastidia un poco todo el tiempo que pasó aplazándolo.

Datos falsos, sensación real

Los datos de muestra realistas hacen persuasivo un prototipo. El texto de relleno lo convierte en un esquema. La diferencia no es cosmética. Cuando un comprador ve una demo llena de nombres de clientes que parecen sus clientes, productos que parecen sus productos y cifras en el rango con el que trabaja, su cerebro deja de evaluar la herramienta y empieza a imaginarse usándola. Cuando ve Cliente A, Producto 1, 123,45, se queda en modo evaluación. Dedica diez minutos a generar datos que se parezcan a los suyos.

Claude hace que esto cueste casi cero. Describe el negocio del cliente, el tipo de registros que manejará la herramienta y la forma de los datos, y pide un conjunto de datos sintético realista: cincuenta consultas del tipo que recibe una pequeña asesoría contable, un año de pedidos de un proveedor de alimentación especializado, una lista de incidencias de soporte de una empresa de software con una mezcla verosímil de asuntos urgentes y triviales. Pide una variación realista, con algunos casos incómodos. El resultado parece lo bastante real como para que la demo sea creíble sin contener nada real.

Ese último punto importa. Los datos sintéticos son la opción por defecto correcta para los prototipos, sobre todo antes de tener un acuerdo firmado. Los datos reales del cliente conllevan obligaciones de protección de datos, cuestiones de confidencialidad y el riesgo de una filtración bochornosa si un prototipo se comparte más de lo previsto. Los datos sintéticos que reflejan la forma y la sensación de los reales te dan el beneficio persuasivo sin ninguno de esos riesgos. Deja claro que son sintéticos, y el cliente agradecerá el cuidado.

Los casos incómodos son donde los datos sintéticos se ganan el sueldo. Un prototipo que solo maneja registros limpios y típicos quedará bonito y no le enseñará nada a nadie. Incluye la consulta escrita en mayúsculas, el pedido sin código postal, la incidencia que en realidad son dos problemas, la factura en moneda extranjera. Muestra cómo se las apaña el prototipo, o cómo no. El comprador reconocerá al instante esos casos de su propio trabajo, y su confianza en ti subirá porque está claro que entiendes cómo son los datos reales.

El lorem ipsum le dice al comprador que no has pensado en su negocio. Unos buenos datos falsos le dicen que sí.

Aquí también hay un activo reutilizable. Si te especializas en un sector, construye una biblioteca de conjuntos de datos sintéticos para él: clientes de muestra, transacciones típicas, tipos de documento habituales, casos límite frecuentes. Cada prototipo nuevo parte de esa biblioteca, ligeramente adaptada al cliente concreto. Con el tiempo, tus datos de muestra adquieren una autoridad discreta, un retrato del sector que los compradores reconocen a la primera.

Cuando empiece el encargo y haya datos reales disponibles con los acuerdos pertinentes, prueba el prototipo con ellos cuanto antes. Los datos sintéticos, por buenos que sean, pasarán algo por alto. Los datos reales contendrán un patrón que nadie predijo. Encontrarlo pronto es barato; encontrarlo en el traspaso, no.

Esta semana, coge cualquier prototipo o demo que tengas y sustituye sus datos de relleno por datos sintéticos realistas para un tipo concreto de cliente. Incluye cinco casos incómodos. Enséñaselo a alguien de ese sector y fíjate en si empieza a hablar de la herramienta o de su propio trabajo. Si habla de su propio trabajo, los datos están cumpliendo su función.

De la captura a la especificación

Una imagen de la interfaz que quieres vale un número sorprendente de palabras. A los clientes a menudo les cuesta describir por escrito lo que necesitan, pero casi siempre pueden señalar algo: una captura de una herramienta que les gusta, una foto de un boceto en una pizarra, una página del producto de un competidor, el diseño de una hoja de cálculo que llevan años usando. Pega la imagen en Claude, explica qué debe hacer y deja que el modelo escriba la implementación. Los encargos visuales eliminan de un plumazo toda una ronda de ambigüedad de diseño.

Claude lee bien las imágenes: maquetaciones, etiquetas, tablas, bocetos a mano y capturas anotadas. Dale una captura de la hoja de cálculo actual del cliente y pídele una herramienta web sencilla que haga el mismo trabajo con validación y una vista de resumen. Dale una foto de una pizarra con cajas y flechas y pídele un prototipo funcional de ese flujo. Dale una captura de un panel que el cliente admira y pídele uno con la misma estructura, con sus datos y sus colores de marca. La primera versión no será perfecta, pero será reconociblemente lo que querían decir, que es la parte difícil.

Funciona bien en las llamadas. Pide al cliente que comparta pantalla y te enseñe cómo hace hoy la tarea. Haz una captura, con permiso. Después de la llamada, o durante ella si te sientes seguro, úsala como encargo para un prototipo. El cliente ve su propio proceso devuelto como una herramienta mejor, y la conversación se vuelve concreta de inmediato. Ese botón debería estar aquí. Esa columna sobra. ¿Puede ordenar por fecha? Cada comentario es preciso porque hay algo preciso que comentar.

Las capturas también ayudan en la dirección contraria. Cuando revises un prototipo con un cliente de forma asíncrona, pídele que haga una captura de lo que quiere cambiar y la anote. Una captura con un círculo y las palabras esto más grande es mucho más clara que un párrafo de descripción, y Claude puede actuar sobre ella directamente. El ciclo de comentarios se acorta, y los dos pasáis menos tiempo interpretándoos.

La gente no siempre sabe decir lo que quiere. Casi siempre sabe señalarlo.

Ojo con la confidencialidad. Las capturas de los sistemas de un cliente pueden contener nombres de clientes, cifras u otra información sensible. Recorta o difumina lo que no haga falta antes de compartir imágenes con cualquier herramienta, y asegúrate de que las herramientas que usas son las que el cliente ha aceptado. Trata las capturas con el mismo cuidado que cualquier otro dato del cliente.

Ojo también con la línea entre inspirarse y copiar. Usar el producto de un competidor como referencia de maquetación y flujo es práctica normal. Reproducir su diseño distintivo, su marca o su contenido, no. El objetivo es capturar lo que el cliente quiere de la interfaz, no clonar el trabajo de otro.

Esta semana, la próxima vez que un cliente o un colega te describa una interfaz con palabras, pídele que te enseñe algo: una captura, un boceto, una página que le guste. Úsalo como encargo. Compara el resultado con lo que habrías construido solo a partir de la descripción. Rara vez volverás a los encargos solo de texto para nada visual.

El prototipo clicable

Lo medio real gana a lo totalmente imaginado. Un prototipo en el que tres flujos funcionan de verdad y todo lo demás es un simulacro claramente etiquetado responde a más preguntas que cualquier documento de especificaciones. Las especificaciones describen intenciones, y las intenciones son infinitamente flexibles. Un flujo que funciona es tozudo: o hace lo que el cliente necesita o se ve que no, y esa visibilidad es precisamente lo que lo hace útil.

Elige con cuidado los tres flujos. Deben ser los caminos que más importan para la decisión del cliente: la tarea más común, la más dolorosa y aquella en la que el nuevo enfoque más se aleja del antiguo. Para una herramienta de clasificación de consultas, podría ser encaminar una consulta rutinaria, gestionar una queja urgente y tratar una consulta que no encaja en ninguna categoría. Haz que esos tres funcionen de principio a fin, con datos realistas y lógica real. Todo lo demás, ajustes, informes, gestión de usuarios, puede ser un marcador de posición que diga lo que haría.

Los flujos que funcionan cargan con el peso de las conversaciones con el cliente. Puede probar él mismo la tarea más común y juzgar si le parece más rápida. Puede ver cómo se marca el caso urgente y decidir si el umbral es el correcto. Puede observar el caso incómodo y contarte qué hace hoy su equipo en esa situación. Esas son las decisiones que dan forma a la construcción real, y se toman con mucha más fiabilidad con algo en lo que se puede hacer clic que con un documento lleno de suposiciones.

Los simulacros deben ser honestos. Etiquétalos con claridad, con una nota breve sobre lo que haría la versión terminada y, más o menos, cuánto trabajo implica. Eso evita el malentendido clásico en el que un cliente ve una pantalla pulida y da por hecho que funciona. También te da una forma natural de hablar del alcance: estos son los tres flujos que hemos demostrado, estos son los simulacros, ¿cuáles importan para la primera versión y cuáles pueden esperar?

Una especificación es una promesa sobre el futuro. Un flujo que funciona es una prueba sobre el presente. Los compradores prefieren las pruebas.

Con Claude, construir un prototipo clicable es lo bastante rápido como para que quepa dentro de una auditoría o antes de que empiece un sprint. Parte del enfoque de un solo archivo, añade los datos realistas de los capítulos anteriores, implementa con cuidado los tres flujos y simula el resto. Un día de trabajo, a menudo menos, produce algo que reduce considerablemente el riesgo de una construcción de dos semanas. Algunos consultores incluyen por sistema un prototipo clicable en cada presentación de resultados de auditoría, de modo que la recomendación principal no llega como un párrafo sino como algo que el cliente puede probar.

Ten cuidado de que el prototipo no fije expectativas sobre el esfuerzo. Un flujo que llevó una hora prototipar puede llevar días construirlo de forma robusta, con gestión de errores, seguridad, integración y pruebas. Dilo. El prototipo muestra lo que hará la herramienta, no cuánto cuesta hacerla fiable.

Esta semana, coge una idea que hayas estado describiendo con palabras y construye tres flujos que funcionen, con simulacros para el resto. Enséñaselo a alguien que lo usaría. Cuenta las decisiones que toma en los primeros diez minutos. Luego imagina cuántas reuniones habrían hecho falta para llegar a las mismas decisiones a partir de un documento. Esa distancia es para lo que sirven los prototipos clicables.

Un artefacto por pregunta

Resiste la tentación de la megaaplicación. Cuando construyes algo para un cliente, la tentación es hacerlo exhaustivo: un panel con nueve pestañas, todas las métricas, todos los filtros, todas las vistas que alguien pudiera querer jamás. Se admira en el traspaso, todo el mundo lo guarda en favoritos y luego se olvida sin hacer ruido, porque nadie encuentra en él la única cosa que de verdad necesita. Un artefacto enfocado que responde exactamente a una pregunta de negocio se usa, cada semana, durante años.

Parte de la pregunta, no de los datos. ¿Qué clientes corren el riesgo de no renovar este trimestre? ¿Qué facturas de proveedores llevan retraso en su aprobación? ¿Cómo se comparan los tiempos de respuesta de esta semana con los de la anterior? Cada pregunta tiene un público, una frecuencia y una decisión asociada. Construye una herramienta que responda a esa pregunta con claridad, para ese público, con esa frecuencia, y que facilite la decisión. Deja fuera todo lo demás. Si alguien necesita respuesta a otra pregunta, construye otro artefacto.

Los artefactos enfocados son más fáciles de construir, probar, explicar y mantener. Con Claude, cada uno es un trabajo breve y contenido: una fuente de datos, una vista, una o dos interacciones. Cada uno es fácil de verificar, porque sabes exactamente cómo es lo correcto. Y cada uno es fácil de traspasar, porque su propósito resulta obvio por su título. Un cliente con seis herramientas pequeñas que responden cada una a una pregunta está mucho mejor servido que uno con una sola herramienta que intenta responderlas todas.

También son excelentes microencargos. Un cliente con una pregunta que no puede responder fácilmente desde sus sistemas actuales, que son la mayoría de los clientes, puede comprar una herramienta enfocada que la responda. El alcance es claro, la entrega es rápida y el valor resulta obvio desde el primer uso. Una serie de ellas, cada una dedicada a una pregunta distinta, construye una relación a base de pequeñas victorias, que es exactamente el patrón que recomienda este libro.

Un panel que lo responde todo no responde nada en particular. Construye el que responde a la pregunta del lunes.

Pon a cada artefacto el nombre de su pregunta. Riesgo de renovación este trimestre es mejor título que Panel de analítica de clientes, porque le dice al usuario qué va a averiguar antes de abrirlo. La disciplina del nombre también te mantiene honesto: si no puedes ponerle al artefacto el nombre de una sola pregunta, probablemente está intentando responder a varias y debería dividirse.

Aquí también hay una cuestión de diseño. Cuando un artefacto responde a una sola pregunta, su maquetación puede construirse en torno a la respuesta: la cifra clave arriba, el detalle de apoyo debajo, la llamada a la acción al final. Cuando responde a muchas, la maquetación tiene que construirse en torno a la navegación, y por eso tantos paneles parecen menús en lugar de respuestas.

Esta semana, mira cualquier panel o informe que tú o un cliente uséis con regularidad. Identifica la única pregunta que la gente lo abre para responder. Construye un artefacto de propósito único que responda solo a esa pregunta, con la mayor claridad posible. Ponlo junto al original y mira cuál se abre el próximo lunes.

Un enlace gana a un adjunto

Una URL gana a un adjunto. Envía un prototipo como archivo y se quedará en una bandeja de entrada, esperando a que alguien lo descargue, encuentre la aplicación adecuada para abrirlo y se pregunte si es seguro. Envíalo como enlace y el cliente podrá abrirlo en el móvil desde un taxi, reenviárselo a un compañero, enseñárselo a su jefe en el pasillo. Deja de ser una demo y empieza a ser una cosa que existe, y de las cosas que existen se habla.

Las herramientas para esto son ya algo corriente. Los artefactos de Claude pueden publicarse como páginas privadas y compartirse con personas concretas. Los servicios sencillos de alojamiento estático te permiten poner en línea un prototipo de un solo archivo en minutos. En los encargos de código, un despliegue de vista previa de una rama le da al cliente un enlace al trabajo en curso. Sea cual sea la vía, el objetivo es el mismo: poner el trabajo donde el cliente pueda alcanzarlo con un solo toque, en el dispositivo que tenga en la mano.

Los enlaces cambian el ciclo de comentarios. Un cliente con un enlace mira el prototipo más a menudo y se lo enseña a más gente. Los comentarios llegan antes y de un grupo más amplio, incluidas personas a las que nunca habrías conocido en las reuniones formales. A veces esas personas son los usuarios reales, que se fijan en cosas que el comprador no vio. A veces son quien firma el presupuesto, que ahora tiene un motivo concreto para aprobar la siguiente fase. Un enlace viaja por una organización como un adjunto nunca lo hace.

Piensa con cuidado en el acceso. Un prototipo con datos sintéticos normalmente puede compartirse con bastante libertad. Uno que toca datos reales necesita un control de acceso como es debido: privado por defecto, compartido solo con personas concretas, tras la autenticación del cliente si hace falta. Nunca pongas datos reales de un cliente en un enlace público por comodidad. La velocidad al compartir solo es una ventaja si quienes lo reciben son las personas adecuadas.

Un adjunto espera a que lo abran. Un enlace ya está abierto, en la mano de otro, enseñándoselo a alguien a quien nunca has visto.

Esto tiene además un acabado profesional. Un enlace a un prototipo limpio que funciona, titulado con el nombre del cliente y la pregunta que responde, transmite competencia con más eficacia que cualquier declaración de capacidades. Dice que construyes cosas y que las terminas. Para un microconsultor, cuya oferta entera se basa en una entrega rápida y visible, esa señal vale muchísimo.

Lleva el control de lo que has compartido. Una lista sencilla de enlaces activos, con quién tiene acceso y cuándo debería retirarse cada uno, ahorra confusiones más adelante. Los prototipos que se dejan en línea indefinidamente pueden dar problemas: versiones desfasadas que se confunden con las vigentes, o una demo que se usa como herramienta de producción. Cuando termine un encargo, retira los enlaces de los prototipos o márcalos claramente como históricos.

Esta semana, coge algo que normalmente enviarías como adjunto, un prototipo, un informe, una pequeña herramienta, y compártelo como enlace, con los ajustes de acceso adecuados. Fíjate en lo rápido que llegan las respuestas, y de quién. Puede que descubras a gente interesándose por tu trabajo que nunca habría abierto el archivo.

El documento que se queda

Hay gente que todavía quiere algo que pueda tener en la mano, o al menos algo que pueda archivar. El consejero que imprime los papeles antes de las reuniones. La directora financiera que guarda una carpeta con cada propuesta. El cliente que quiere reenviar tus conclusiones a una matriz que no acepta enlaces. Para ellos necesitas un documento que se quede: un documento limpio que se sostenga por sí solo cuando ya te hayas ido de la sala. La buena noticia es que rara vez necesitas una herramienta de diseño aparte para hacerlo.

Una hoja de estilos de impresión del navegador convierte cualquier artefacto web en un documento pulcro. Unas cuantas reglas que le dicen a la página cómo maquetarse al imprimirse, ocultar la navegación y los botones, fijar los márgenes, evitar saltos de página en lugares incómodos, usar colores aptos para imprimir, y el mismo artefacto que funciona como herramienta interactiva se imprime como un informe profesional. Guárdalo como PDF desde el navegador y tendrás un documento que se queda sin canal de exportación adicional ni dependencia extra que mantener. Claude puede escribirte los estilos de impresión en una sola petición.

Esto importa a los consultores porque reduce dos entregables a uno. Ya no construyes un prototipo y luego escribes por separado un informe sobre él. Construyes un único artefacto que es interactivo en pantalla y un documento en papel. Las presentaciones de resultados de auditoría, los casos de éxito, las propuestas y las guías de traspaso pueden funcionar así. El cliente recibe una versión viva para explorar y una versión estática para archivar, y siempre coinciden, porque son la misma cosa.

Diseña la versión impresa a propósito y no como una ocurrencia de última hora. Pon un título claro, el nombre del cliente y la fecha arriba. Asegúrate de que el contenido más importante aparece en la primera página, para el lector que nunca pasa la hoja. Incluye la explicación suficiente para que el documento se entienda sin que estés tú para narrarlo. Si la versión interactiva depende de pasar el ratón o hacer clic para revelar información, asegúrate de que esa información se vea al imprimir.

La reunión termina. El documento se queda en la mesa, defendiendo tu argumento sin ti.

Los documentos que se quedan son también marketing duradero. Un resumen de auditoría o un caso de éxito bien hecho, impreso o guardado como PDF, circula dentro de la organización del cliente y a veces más allá. Lleva tu nombre, tu método y tus resultados a salas en las que nunca entrarás. Haz que sea algo que te enorgullecería que leyera un desconocido.

Mantén la marca coherente y discretamente profesional. Basta una maquetación sencilla y legible con tu nombre y tus datos de contacto en el pie. Evita la decoración recargada que quedará mal en blanco y negro. Evita poner en un documento que se queda nada que resultaría incómodo si se reenviara a la persona equivocada, porque tarde o temprano ocurrirá.

Esta semana, coge un artefacto que hayas construido y añádele una hoja de estilos de impresión. Imprímelo, o guárdalo como PDF, y léelo como lo leería un desconocido. Arregla lo que no se sostenga por sí solo. Luego haz que los estilos de impresión formen parte de tu enfoque estándar, para que cada artefacto que entregues lleve incorporado desde el principio su documento que se queda.

Verifica antes de afirmar

No digas nunca que funciona hasta haberlo ejecutado. Las pruebas antes que las afirmaciones son la diferencia entre un operador de confianza y uno al que discretamente se deja de llamar. En la entrega rápida asistida por IA, la tentación de proclamar el éxito antes de tiempo es fuerte: el agente dice que el cambio está hecho, el código parece correcto, la demo es dentro de diez minutos. Resístela. Ejecuta la cosa. Mira la salida. Entonces, y solo entonces, di que funciona.

Los modelos son elocuentes y seguros de sí mismos, lo cual es útil en muchos sentidos y peligroso en este. Un agente que ha hecho un cambio a menudo informará de que ha funcionado, a veces antes de comprobarlo de verdad, a veces basándose en una comprobación que no probaba lo que había que probar. No es deshonestidad; es la naturaleza de la herramienta. Tu trabajo es exigir pruebas: la salida de los tests, la captura de la página funcionando, el resultado de ejecutar el script con una entrada real. Si las pruebas no están, la afirmación todavía no es cierta.

Esto se aplica con especial fuerza a lo que le dices al cliente. Cuando le dices que un flujo está arreglado, que un prototipo maneja sus casos límite o que un piloto de agentes alcanzó una precisión determinada, te estás jugando la reputación en esa afirmación. Una sola afirmación falsa, descubierta más tarde, deshace muchísimo trabajo bien hecho. La costumbre de enseñar pruebas, aquí está la ejecución, aquí los resultados, aquí el caso en que se equivocó, construye una reputación muy difícil de derribar.

Haz visible la verificación. En las demos, ejecuta la cosa en directo en lugar de enseñar una grabación, cuando sea viable. En los informes, incluye las pruebas: los casos de prueba, las puntuaciones, las mediciones del antes y el después. En las actualizaciones de estado, distingue claramente entre lo que se ha verificado y lo que aún se está comprobando. Los clientes notan la diferencia entre un consultor que dice debería funcionar y uno que dice funciona; aquí está la ejecución.

La seguridad es gratis. Las pruebas cuestan unos minutos. Solo una de las dos sobrevive al contacto con los datos reales del cliente.

La verificación también te protege de ti mismo. El momento más peligroso de cualquier entrega es cuando estás cansado, el plazo se acerca y el agente dice que todo va bien. Es justo cuando más tentado estás de creerlo. Una regla personal sencilla, nada llega al cliente hasta que lo haya visto funcionar, saca la decisión del momento de cansancio. No tienes que juzgar si comprobar. Simplemente compruebas.

Incorpora la verificación a las propias herramientas siempre que puedas. Prototipos con una autoprueba visible. Flujos que registran lo que hicieron y si tuvo éxito. Agentes que informan de sus resultados con las pruebas adjuntas. Todo esto facilita la verificación para ti y para el cliente cuando te hayas ido. Un sistema que muestra sus propias pruebas es un sistema en el que la gente confía.

Esta semana, antes de cada afirmación de éxito, a ti mismo o a un cliente, haz una pausa y pregúntate qué pruebas has visto. Si la respuesta es ninguna, ve a buscarlas. Te costará minutos. A lo largo de un año, te ahorrará al menos una conversación muy incómoda, y probablemente varias.

Entrega en la reunión

Construir el cambio en directo mientras el cliente mira es la jugada comercial más eficaz al alcance de quien trabaja solo. Convierte el escepticismo al instante. Un comprador que dudaba de que la IA pudiera ayudar con su problema te ve coger su ejemplo real, describir el cambio en lenguaje llano y ve aparecer un resultado que funciona en la pantalla en cuestión de minutos. Ninguna presentación puede competir con eso. Es la demostración más pura de todo lo que sostiene este libro.

Funciona porque elimina todas las capas de duda a la vez. El comprador ve que la herramienta es real, no una grabación preparada. Ve que funciona con su tipo de problema, no con un ejemplo escogido a dedo. Ve lo rápido que ocurre el cambio, lo que reencuadra su idea de lo que podría lograr un sprint de dos semanas. Y te ve a ti trabajando, con calma y competencia, que es lo que de verdad está decidiendo si comprar.

La preparación hace que parezca fácil. Antes de la reunión, monta el andamiaje: un prototipo de un solo archivo con datos realistas, una skill con las instrucciones adecuadas, un proyecto con el contexto pertinente ya cargado. Ensaya el cambio que esperas hacer, para saber que funciona. Luego, en la reunión, invita al comprador a que proponga él mismo el cambio, dentro del terreno que preparaste. Él se siente al mando; tú pisas terreno conocido. Cuando proponga algo inesperado, inténtalo con honradez. Si funciona, estupendo. Si no, dilo con claridad y apúntalo como algo que explorar. La honradez bajo presión impresiona más que una actuación impecable.

Los riesgos son reales y manejables. Las demos en directo pueden fallar: un servicio va lento, se cae una conexión, el modelo toma un camino inesperado. Ten preparada una alternativa, como una grabación o una versión preparada del resultado, pero úsala solo si el intento en directo falla de verdad. Y nunca construyas en directo con datos reales del cliente a menos que el acuerdo y sus sistemas lo permitan. Los datos sintéticos que reflejan su realidad son la opción segura por defecto.

La frase más persuasiva de la consultoría no es una frase. Es un cambio que funciona y que apareció mientras miraban.

Esta jugada también funciona dentro de los encargos, no solo en la venta. Durante una demo de viernes, haz en directo un pequeño cambio que pida el cliente. Durante una sesión de formación, construye algo útil a partir de la sugerencia de un participante. Cada vez demuestras que el cambio es barato y rápido, lo que anima a los clientes a pedir mejoras en lugar de tolerar los problemas. Eso es bueno para ellos y muy bueno para la relación.

Es el clímax natural de esta parte. Todo lo anterior, prototipos de un solo archivo, datos realistas, artefactos enfocados, enlaces, verificación, es preparación para este momento. Acierta con esas costumbres y construir en la reunión dejará de ser un número de circo para convertirse en tu forma normal de trabajar.

Esta semana, en tu próxima conversación con un cliente, busca un cambio pequeño que puedas hacer en directo. Prepara el andamiaje, ensáyalo una vez y luego hazlo mientras mira. Presta atención al momento en que cambia su postura. Recuérdalo. Es lo que vendes, y acabas de encontrar la forma más rápida de entregarlo.

La primera semana es de accesos

No se entrega nada hasta que tienes tres cosas: credenciales, acceso a los datos o al repositorio y un responsable de decisiones con nombre y apellidos. En un encargo de dos semanas, perder tres días esperando una contraseña es perder una quinta parte del calendario antes de haber empezado. Persigue las tres el primer día, o la segunda semana se convertirá discretamente en la primera y el cliente se preguntará por qué el sprint se le hace tan corto.

Los accesos siempre tardan más de lo que nadie espera. La persona que puede crear una cuenta está de vacaciones. El proveedor de informática necesita un ticket. El repositorio pertenece a un contratista que no contesta un correo desde la primavera. Los datos están en un sistema del que nadie tiene la contraseña de administrador. Nada de esto es culpa de nadie, exactamente, pero todo acaba cayendo sobre tu calendario a menos que te adelantes. Los mejores consultores tratan los accesos como el primer entregable, con la misma seriedad que el trabajo en sí.

Así que envía la lista de comprobación de accesos antes de que empiece el encargo, idealmente junto con el acuerdo. Enumera cada sistema que vas a necesitar, el nivel de acceso que requiere cada uno, el nombre de la persona que puede concederlo y la fecha en que lo necesitas. Pide cuentas creadas para el encargo en lugar de usuarios personales compartidos, que son un problema de seguridad y un quebradero de cabeza en las auditorías. Pide el acceso mínimo que permita hacer el trabajo, y dilo explícitamente; a los clientes les tranquiliza un consultor que pide menos en lugar de más.

El responsable de decisiones con nombre es el acceso que la gente olvida, y es el que más importa. Alguien del lado del cliente tiene que poder responder preguntas en el plazo de un día, aprobar el plan, aceptar el resultado y decir que no a la ampliación del alcance. Sin esa persona, cada pregunta se convierte en una reunión y cada decisión se queda flotando. Pide su nombre en el arranque. Acordad cómo vas a localizarla y con qué rapidez puede responder. Si la respuesta es vaga, el encargo corre peligro, y es mejor saberlo el primer día.

El sprint no empieza cuando empiezas a trabajar. Empieza cuando puedes.

Usa Claude para suavizar el arranque. Un buen paquete de arranque, con la definición de «terminado», la lista de accesos, el ritmo semanal, el plan de comunicación y el contenido del traspaso, puede redactarse en minutos a partir de tu plantilla y del resumen de diagnóstico, y revisarse con el cliente en la primera reunión. Parece concienzudo porque lo es, y te cuesta muy poco una vez que existe la plantilla.

Si de verdad no se pueden conseguir los accesos a tiempo, dilo pronto y ajusta. Retrasa la fecha de inicio, reduce el alcance o empieza por las partes del trabajo que no necesitan el acceso que falta. Lo que no debes hacer es absorber el retraso en silencio y luego entregar menos de lo prometido al final. Eso convierte un problema administrativo en uno de reputación.

Esta semana, escribe tu plantilla de lista de accesos: sistemas, niveles de acceso, quién los concede, para cuándo, más el responsable de decisiones con nombre y su tiempo de respuesta. Adjúntala a tu próximo acuerdo. La primera vez que un cliente lo tenga todo listo el primer día porque se lo pediste con antelación, te sentirás ligeramente pagado de ti mismo. Te lo habrás ganado.

Barreras, no conjeturas

Decide de entrada lo que el agente no podrá hacer nunca. Enviar nada al exterior. Gastar dinero. Borrar registros. Cambiar permisos. Contactar con clientes. Sea cual sea la lista para un cliente concreto, ponla por escrito al principio y luego escríbela dentro del propio sistema, no en una frase esperanzada de un documento que nadie lee. Las barreras que dependen de que el modelo recuerde una instrucción son conjeturas. Las barreras que impone el sistema son barreras.

La diferencia es importante. Una instrucción en un prompt, no envíes nunca correos sin aprobación, suele cumplirse, pero «suele» no basta para acciones con consecuencias reales. Los modelos pueden malinterpretar, confundirse con entradas inusuales o dejarse manipular por texto escondido en el contenido que procesan. Un control a nivel de sistema, un agente que sencillamente no tiene la capacidad de enviar correos, o cuya herramienta de envío requiere la aprobación explícita de una persona antes de ejecutarse, no puede ser convencido para saltarse sus límites. Ese es el nivel de certeza que necesitan los clientes para todo lo que importa.

Las herramientas lo permiten. Claude Code tiene ajustes de permisos que controlan qué herramientas y comandos pueden ejecutarse sin aprobación y cuáles están bloqueados por completo. Los hooks pueden imponer reglas en puntos concretos, como revisar cada comando antes de que se ejecute. Los conectores pueden configurarse con acceso de solo lectura o con permisos de escritura muy acotados. En los sistemas a medida construidos sobre la API, tú decides qué herramientas existen siquiera. En todos los casos, el principio es conceder la mínima capacidad que requiere la tarea y hacer que las capacidades peligrosas o no existan o estén tras una puerta que custodia una persona.

Escribe las barreras con el cliente. Repasad las acciones que el sistema podría realizar y preguntad, para cada una: ¿cuál es el peor resultado plausible si esto sale mal, y con qué facilidad podría deshacerse? Las acciones de bajo riesgo y fácilmente reversibles, leer datos, redactar texto, pueden ser libres. Las moderadas, editar registros, escribir archivos, pueden requerir aprobación. Las de alto riesgo o irreversibles, enviar, gastar, borrar, deben bloquearse o quedar estrictamente controladas. El resultado es una tabla breve y clara que el cliente entiende y el sistema hace cumplir.

Una barrera en un prompt es una petición. Una barrera en el sistema es un hecho.

Esta conversación también genera confianza. A los clientes preocupados por la IA, que son la mayoría, no les tranquilizan las promesas de que el sistema es listo, sino las pruebas de que está limitado. Enseñarles la lista de cosas que el agente no puede hacer, y demostrar que de verdad no puede hacerlas, suele ser más persuasivo que cualquier demostración de lo que sí puede. Convierte un miedo abstracto en una frontera concreta e inspeccionable.

Pon las barreras en el manual de operaciones, junto con las instrucciones para cambiarlas. Las empresas cambian, y una barrera que tenía sentido en el traspaso puede necesitar ajustes un año después. El cliente debe saber dónde están los controles, qué hace cada uno y quién está autorizado a cambiarlos.

Esta semana, coge cualquier agente o flujo automatizado que hayas construido, para ti o para un cliente, y enumera todas las acciones que podría realizar. Marca cada una como libre, preguntar antes o nunca. Luego comprueba que el sistema hace cumplir de verdad tus marcas. Las que dependan solo de una instrucción en un prompt son lo primero que hay que arreglar.

Una persona en el circuito

Diseña el punto de control humano a propósito, en lugar de atornillarlo después del primer incidente. Todo sistema que hace trabajo real se equivocará de vez en cuando. La cuestión no es si debe intervenir una persona, sino dónde, cómo y para qué tipos de acción. La autonomía debe ganarse por tipo de acción, a partir de pruebas, no concederse a todo el sistema de golpe porque la demo salió bien.

Empieza por trazar el flujo de trabajo y marcar dónde un error saldría caro. Una respuesta redactada a una consulta rutinaria puede ser segura de enviar tras un vistazo rápido de una persona. La respuesta a una queja puede requerir una lectura atenta. Un reembolso por encima de cierta cuantía puede necesitar la aprobación de un responsable. Un mensaje a un regulador probablemente no debería redactarlo nunca un agente sin una supervisión estrecha. Cada uno de estos es un punto de control distinto, diseñado para el riesgo de ese paso, no una aprobación general que la gente deja de leer al cabo de la primera semana.

Haz que el punto de control sea fácil de hacer bien. Una persona que aprueba salidas necesita ver la información adecuada: la entrada original, la salida del agente, las alertas que haya levantado el sistema y el razonamiento si viene al caso. Necesita una forma rápida de aprobar, editar o rechazar, y una forma de dejar constancia del motivo. Si la pantalla de aprobación está abarrotada o es lenta, la gente empieza a pulsar aprobar sin leer, y el punto de control se convierte en teatro. Un buen diseño de puntos de control es, sobre todo, un buen diseño de interfaz.

Usa el punto de control para reunir pruebas. Cada aprobación, edición y rechazo te dice algo sobre el rendimiento del sistema. Regístralos. Revísalos con regularidad. Si el equipo aprueba sin cambios un tipo de salida noventa y tantas veces seguidas durante un periodo significativo, eso es una prueba de que el punto de control para ese tipo podría relajarse, quizá a un muestreo en lugar de una revisión completa. Si no paran de editar otro tipo, es una prueba de que el sistema necesita mejorar ahí. La autonomía se amplía donde las pruebas la respaldan, un tipo de acción cada vez.

Confía en el sistema hasta donde llegan las pruebas, y ni un paso más.

Este enfoque encaja bien con los microencargos. Un piloto de agentes suele empezar con una persona aprobando cada salida. Es seguro, le da confianza al cliente y genera exactamente las pruebas necesarias para decidir qué viene después. Un encargo posterior puede entonces relajar los puntos de control donde los datos lo respalden y mejorar el sistema donde no. Cada paso es pequeño, justificado y medible.

Sé sincero con los clientes sobre lo que una persona en el circuito puede y no puede detectar. Un revisor que lee por encima cincuenta borradores por hora pasará por alto errores sutiles. Diseña pensando en eso: marca las salidas inusuales o de baja confianza para que reciban más atención, de modo que la atención del revisor vaya a donde más se necesita. Combina la revisión humana con comprobaciones automáticas, como el patrón del verificador de la quinta parte, en lugar de depender solo de una de las dos.

Esta semana, coge un flujo de trabajo que hayas automatizado, o que pienses automatizar, y marca cada paso con el punto de control que necesita: ninguno, un vistazo, revisión atenta o aprobación de un responsable. Mira los pasos sin punto de control y pregúntate si tienes pruebas de que son seguros o solo esperanza. Donde sea esperanza, añade un punto de control y empieza a reunir pruebas.

Las evaluaciones como aceptación

Sustituye el visto bueno vago por un conjunto de pruebas puntuado. Al final de un encargo típico, se le pregunta al cliente si está contento, y la respuesta depende de su estado de ánimo, de la última salida que vio y de si algo salió mal esa mañana. Es una base pobre para aceptar un trabajo y un terreno abonado para las disputas. Cuando la aceptación es una puntuación sobre veinte casos reales, acordada de antemano, las disputas suelen terminar antes de empezar.

Un conjunto de evaluación, que en la jerga suele llamarse simplemente evals, no es más que una colección de entradas realistas con una forma clara de juzgar cada salida. Para un sistema que redacta respuestas a consultas, podrían ser veinte consultas reales pasadas, anonimizadas donde haga falta, cada una con una nota de lo que debería cubrir una buena respuesta. Para una canalización de extracción de documentos, podrían ser veinte documentos con los valores extraídos correctos. Para un kit de prompts, podría ser un conjunto de tareas con una rúbrica de calidad. Se ejecuta la prueba, se puntúa cada salida y el resultado es un número que todo el mundo puede ver.

Construye el conjunto de evaluación con el cliente, y pronto. En los primeros días del encargo, pide a la persona que va a aceptar el trabajo que elija casos representativos, incluidos algunos incómodos, y que diga cómo es una buena salida para cada uno. Ponlo por escrito como rúbrica. Acordad el umbral de aceptación: quizá un número determinado de casos debe cumplir la rúbrica por completo y ninguno puede contener un error grave. Ahora todo el mundo sabe qué significa «terminado», en términos concretos y comprobables.

El conjunto de evaluación se convierte entonces en tu herramienta de desarrollo. Ejecútalo después de cada cambio significativo. Ves de inmediato si un prompt nuevo, una skill nueva o un modelo nuevo mejoran las cosas o las empeoran. Dejas de discutir si una salida es buena en general y empiezas a arreglar los casos concretos que fallan. Claude puede ayudar a ejecutar y puntuar las evaluaciones, usando la rúbrica, con tu revisión de las puntuaciones. El patrón del verificador se aplica directamente.

Aceptar por sensaciones invita a la discusión. Aceptar por puntuación invita al arreglo.

Las evaluaciones también refuerzan el traspaso y hacen más creíble la iguala. En el traspaso, el cliente recibe el conjunto de evaluación junto con el sistema, para poder volver a ejecutarlo cada vez que algo cambie: un modelo nuevo, una política nueva, una línea de producto nueva. Durante una iguala, el informe mensual puede mostrar la puntuación a lo largo del tiempo, con cada nuevo caso de fallo añadido al conjunto. Es una demostración concreta y continua de valor, mucho más convincente que una lista de horas dedicadas.

Dos advertencias. La primera: un conjunto de evaluación es tan bueno como sus casos. Si los veinte son fáciles, una puntuación alta significa poco. Incluye los casos difíciles y añade otros nuevos cada vez que se produzca un fallo real. La segunda: no dejes que la puntuación sea la única medida. Un sistema puede puntuar bien en su conjunto de pruebas y aun así frustrar a los usuarios de maneras que el conjunto no capta. Combina la puntuación con los comentarios de los usuarios y con medidas del mundo real.

Esta semana, para lo próximo que entregues, escribe el conjunto de evaluación antes de construir: de diez a veinte casos realistas, una rúbrica y un umbral, acordados con quien vaya a aceptarlo. Luego construye hasta que lo supere. Descubrirás que la conversación del final es mucho más corta, y mucho más cordial, de lo habitual.

Demo todos los viernes

Una demo semanal es el seguro más barato contra construir lo que no era. Cada viernes, enséñale al cliente lo que has construido esa semana: funcionando, en pantalla, con su tipo de datos. Lleva media hora. Te obliga a producir cada semana un incremento entregable, detecta los malentendidos cuando todavía es barato corregirlos y mantiene al cliente emocionalmente implicado en el trabajo. Pocos hábitos dan tanto a cambio de tan poco.

La función de obligar importa. Sin una demo en el calendario, el trabajo deriva hacia lo cómodo y lo invisible: refactorizar, pulir, explorar. Con una demo cada viernes, necesitas algo que enseñar, lo que significa que necesitas algo que funcione. Esa presión mantiene el trabajo centrado en lo que el cliente va a ver y usar. En un sprint de dos semanas, las dos demos de los viernes son la columna vertebral del encargo: una para comprobar el rumbo, otra para entregar.

La demo es también donde afloran los malentendidos. Construiste la herramienta de clasificación para encaminar por tipo de producto; el cliente daba por hecho que encaminaría por urgencia. En un documento, ese malentendido podría sobrevivir hasta el traspaso. En una demo, aflora en treinta segundos, cuando el cliente ve una queja urgente ir a parar a la cola equivocada y dice espera, eso tendría que ir directo a Sara. Mejor oírlo el primer viernes que el último.

Mantén un formato constante. Empieza recordando el objetivo y la definición de «terminado». Enseña lo que ha cambiado desde la semana pasada, funcionando, preferiblemente en directo. Enseña la puntuación de la evaluación si la tienes. Menciona cualquier cosa que haya salido mal o haya cambiado. Pide comentarios concretos sobre decisiones concretas. Cierra con lo que harás la semana siguiente. Treinta minutos, la misma estructura cada vez, para que el cliente sepa qué esperar y venga preparado.

Una demo cada viernes hace que las malas noticias lleguen en trozos pequeños y digeribles, en lugar de en uno grande y memorable.

El lado emocional está infravalorado. Los clientes que ven progreso cada semana sienten el trabajo como propio. Hablan de él con sus compañeros. Empiezan a imaginar cómo lo usarán. Para cuando llega el traspaso, ya están implicados en su éxito, lo que hace mucho más probable que se adopte. Los clientes que no ven nada durante dos semanas y luego reciben un sistema terminado se sienten destinatarios en lugar de participantes, y los destinatarios tienen muchas más probabilidades de ponerle pegas.

Invita a las personas adecuadas. Al responsable de decisiones, por supuesto. A la persona que se hará cargo del sistema tras el traspaso, sin duda. A una o dos de las personas que lo usarán de verdad, si es posible. Los usuarios detectan problemas prácticos que los responsables pasan por alto, e implicarlos pronto hace mucho más fácil la formación posterior.

Esta semana, si estás en mitad de un encargo, programa una demo para el viernes, aunque sea de quince minutos. Si no, añade una demo semanal a tu plantilla de encargo estándar y a tu próxima propuesta. Los clientes dicen una y otra vez que las demos semanales son una de las cosas que más valoraron, y es de lo más barato que vas a ofrecer nunca.

El protocolo del alcance

Di que sí a la idea y que no al calendario. La ampliación del alcance es el enemigo natural del trabajo de alcance cerrado, y rara vez llega como una exigencia. Llega como una petición entusiasta, razonable y aparentemente pequeña de un cliente contento con los avances. ¿Podría encargarse también de las devoluciones? Ya que estás, ¿podrías echarle un vistazo a los informes? Cada petición parece trivial. Juntas, convierten un sprint de dos semanas en uno de seis al mismo precio.

El protocolo es sencillo y amable. Cuando llegue una petición nueva, dale la bienvenida, porque significa que el cliente está implicado. Luego ponla por escrito como nota de cambio: qué se pide, qué implicaría, cómo afectaría al calendario y cuánto costaría. Envía la nota sin demora, idealmente el mismo día, con una elección clara: añadirla a este encargo con el cambio indicado, o ponerla en la lista para el siguiente. La mayoría de los clientes eligen la lista, de buen grado, porque ven que el trabajo actual va por buen camino.

El tono importa tanto como el proceso. Un protocolo contra la ampliación del alcance aplicado a regañadientes parece burocracia. Aplicado con calidez, parece profesionalidad. Es una idea estupenda, y encaja de forma natural después de este sprint. La he añadido a la lista para la demo de cierre, y puedo mandarte un esbozo rápido de lo que implicaría. El cliente oye entusiasmo y un plan, no una negativa. La respuesta a la pregunta del calendario es no; la respuesta a la idea es sí.

Claude puede hacer que el protocolo no cueste casi nada. Ten una plantilla de nota de cambio y, cuando llegue una petición, pídele a Claude que redacte la nota a partir de la petición, el alcance actual y tus condiciones estándar. Revísala, ajusta la estimación, envíala. Cinco minutos. Guarda todas las notas en un solo sitio. Al final del encargo, esa colección de peticiones aparcadas es una cartera ya hecha: una lista de cosas que el cliente ya ha dicho que quiere, descritas y acotadas a grandes rasgos, esperando a la demo de cierre.

Cada petición aparcada es una propuesta que el cliente ha escrito por ti. Trata la lista con mimo.

Acordad el protocolo en el arranque, para que nunca sea una sorpresa. Explica que el encargo tiene un alcance cerrado y que las peticiones nuevas serán bienvenidas, se pondrán por escrito y o bien se añadirán con un cambio o bien se aparcarán para más adelante. Los clientes agradecen conocer las reglas. Además, así, cuando invoques el protocolo, estarás siguiendo un proceso acordado y no inventándote un motivo para decir que no.

Hay una excepción que merece la pena nombrar. Si una petición revela que el alcance original estaba equivocado, que lo que estás construyendo no va a resolver el problema, para y habladlo como es debido. Eso no es ampliación del alcance. Es información nueva, y puede significar cambiar de rumbo. El protocolo es para añadidos, no para correcciones.

Esta semana, escribe tu plantilla de nota de cambio: petición, impacto, calendario, elección. Acuerda el protocolo en tu próximo arranque. Cuando llegue la primera petición, úsalo, con calidez y el mismo día. Luego mira cómo crece la lista de aparcados. Es la fuente más fiable de próximos encargos que vas a tener jamás.

Escribe el manual de operaciones

El sistema que dejas debe poder operarlo alguien que nunca te ha conocido. Esa es la prueba de un buen traspaso, y el manual de operaciones es la forma de superarla. Sin manual, tu trabajo es un proyecto: existe, hoy funciona y depende de conocimientos que están en tu cabeza. Con manual, se convierte en un activo: algo que el cliente puede ejecutar, comprobar, arreglar y cambiar sin llamarte. Eso es lo que pagó, se diera cuenta o no.

Un buen manual de operaciones cubre tres cosas. Primero, qué hace el sistema y por qué: su propósito, sus entradas y salidas, las decisiones que le dieron forma y las barreras que lo limitan. Segundo, cómo ejecutarlo y revisarlo: dónde vive, cómo arrancarlo, cómo saber si funciona, dónde están los registros, cómo volver a ejecutar el conjunto de evaluación. Tercero, qué hacer cuando falla: los modos de fallo habituales, cómo reconocer cada uno, los pasos para arreglarlo y cuándo escalar. Añade contactos, la ubicación de las credenciales y los procedimientos de cambio, y tendrás un documento en el que el cliente puede confiar.

Escríbelo durante el encargo, no al final. Cada vez que configures algo, apunta cómo. Cada vez que algo salga mal, apunta qué pasó y cómo lo arreglaste. Claude puede convertir tus notas, el archivo de memoria, el historial de commits y la configuración del sistema en un borrador bien estructurado, que tú luego revisas y completas. El manual escrito en las dos últimas horas de un sprint siempre es más flaco que el que se escribió sobre la marcha.

Pruébalo. Pide a la persona que se hará cargo del sistema que siga el manual sin tu ayuda: arrancar el sistema, ejecutar una comprobación, simular un fallo habitual y arreglarlo. Fíjate en dónde se atasca. Cada sitio donde se atasca es un hueco en el manual. Rellena los huecos. Esta prueba lleva una hora y es una de las horas más valiosas del encargo, porque revela exactamente cuánto de tu conocimiento todavía no se ha transferido.

Si el sistema solo funciona mientras se te puede localizar, no has entregado un sistema. Has entregado una dependencia.

Guarda el manual donde el cliente vaya a encontrarlo: en el repositorio junto al código, en el conocimiento del proyecto junto a los prompts o en su sistema de documentación habitual. Ponle fácil actualizarlo. Los sistemas cambian, y un manual que no se mantiene al día se vuelve engañoso, lo cual es peor que no tener ninguno. Nombra a un responsable en el lado del cliente que se encargue de mantenerlo exacto.

Un manual de operaciones es también una discreta pieza de marketing. Los clientes que reciben un manual claro y probado lo recuerdan, porque la mayoría de los contratistas no lo proporcionan. Transmite que te importa lo que pase cuando te vayas, que es exactamente lo que hace que los clientes te confíen el siguiente encargo.

Esta semana, escribe un manual de operaciones para algo que hayas construido, aunque sea algo pequeño para ti. Tres secciones: qué y por qué, cómo ejecutarlo y revisarlo, qué hacer cuando falla. Luego pídele a otra persona que lo use. Descubrirás cuántas cosas dabas por sentadas. Ese descubrimiento es la gracia del ejercicio.

Forma al referente

Toda cuenta necesita una persona interna capaz de demostrar el sistema sin ti. La adopción muere cuando el único operador competente factura mensualmente. Puedes construir el flujo de trabajo más elegante, el piloto de agentes más fiable, la biblioteca de skills más útil, y si nadie dentro de la empresa lo entiende lo bastante bien como para defenderlo, poco a poco dejará de usarse. Formar al referente no es un extra de la entrega. Es parte de la entrega.

Elige al referente con cuidado, idealmente junto al cliente en el arranque. El mejor referente no es necesariamente la persona de más rango ni la más técnica. Es alguien que usa el sistema a diario, respetado por sus compañeros, al que la IA le despierta curiosidad en lugar de sentirse amenazado, y que tiene tiempo suficiente para aprender. Pide su nombre, implícalo en las demos de los viernes y dale responsabilidades reales durante el encargo: probar salidas, aportar ejemplos, revisar el manual de operaciones.

Fórmalo como es debido antes del traspaso. Un referente debería ser capaz de demostrarle el sistema a un compañero, explicar lo que hace y lo que no, resolver los problemas habituales del manual, hacer cambios pequeños como añadir un ejemplo a una skill o actualizar un prompt, volver a ejecutar el conjunto de evaluación y juzgar cuándo escalar a ti o a su propio soporte técnico. Es un conjunto considerable de habilidades, y construirlo lleva más de una reunión. Planifica unas cuantas sesiones cortas a lo largo del encargo, con práctica entre una y otra.

Aquí es también donde la sesión de formación se convierte en un microencargo por derecho propio. Muchas empresas quieren que su equipo en general use bien las herramientas de IA, y una sesión práctica y enfocada, media jornada, un equipo concreto, sus tareas reales, un conjunto de prompts probados para llevarse, es una compra fácil con resultados inmediatos. Impártela con el referente como copresentador. El equipo aprende de alguien con quien trabaja, el prestigio del referente sube y la formación continúa cuando te vas, porque el referente sigue allí.

El sistema se usará mientras alguien de dentro crea en él y sepa enseñarlo. Asegúrate de que ese alguien existe.

La buena formación es práctica, no teórica. Usa el trabajo real del equipo, no ejemplos inventados. Haz que cada participante produzca algo útil durante la sesión. Enseña bien un número pequeño de técnicas, en lugar de pasar revista a todo. Déjales una referencia breve, el kit de prompts o una guía de una página, y el nombre del referente como la persona a quien preguntar. Haz un seguimiento unas semanas después para ver qué ha cuajado.

Cuida también al referente después del traspaso. Una breve llamada de seguimiento al mes, una nota cuando aparezca una función nueva pertinente, una invitación a compartir su éxito en un caso de éxito. Los referentes son además tu mejor fuente de recomendaciones y tus mejores defensores cuando se esté considerando el siguiente encargo. Saben lo que hiciste, lo han visto funcionar y tienen un interés personal en que siga teniendo éxito.

Esta semana, piensa en los sistemas que has entregado. Para cada uno, nombra a su referente interno. Si no puedes nombrar a ninguno, ese sistema está en peligro. Ponte en contacto y ofrece una sesión de formación breve. Puede que sea la hora más valiosa que pases este mes.

Entrega los prompts

Guardarse los prompts para crear dependencia es una jugada a corto plazo que acaba mal. Algunos consultores se reservan las instrucciones, las skills y la configuración de sus sistemas, con la teoría de que un cliente que no puede ver cómo funciona tendrá que seguir pagando para que siga funcionando. A veces sale bien durante un tiempo. Luego el cliente cambia de consultor, o contrata a un desarrollador, o simplemente acaba resentido con el arreglo, y pierdes la cuenta y tu reputación con ella. Dáselo todo, y véndeles el siguiente sistema en su lugar.

¿Qué significa todo? Los prompts y las instrucciones de sistema. Las skills, con sus referencias y scripts. Los archivos de memoria. Los conjuntos de evaluación y las rúbricas. La configuración de conectores y permisos. El manual de operaciones. Los prototipos y su código fuente. Todo lo que se construyó para el cliente, a partir del contexto del cliente, para hacer el trabajo del cliente, pertenece al cliente. Entrégalo en un formato que puedan usar, guardar y cambiar, y documéntalo lo bastante bien como para que otra persona pudiera retomarlo.

No es solo ética; es buen negocio. Los clientes que lo reciben todo confían más en ti, no menos. Ven que tu valor no está en unos prompts secretos sino en el criterio, la velocidad y la capacidad de resolver el siguiente problema. Es más probable que te llamen para el siguiente encargo, porque saben que no los vas a atrapar. Es más probable que te recomienden, porque pueden decirles a otros con sinceridad que fuiste directo. Y es menos probable que regateen, porque sienten que recibieron todo el valor.

También es realista. Los prompts no son un foso duradero. Una persona competente con acceso a las salidas del sistema a menudo podría reconstruir buena parte del prompt en una tarde, y los modelos mejoran tan deprisa que la redacción ingeniosa pierde filo en cuestión de meses. Lo que no se deprecia es tu método, tu biblioteca de skills generales, tu experiencia con muchos clientes y tu criterio sobre qué construir a continuación. Todo eso se queda contigo entregues lo que entregues.

Tus prompts estarán desfasados en menos de un año. Tu fama de entregarlos, no.

Deja claro qué es suyo y qué es tuyo, como sugería el capítulo anterior sobre las skills como entregable. El trabajo específico del cliente pertenece al cliente. Las técnicas generales, las plantillas y las skills que trajiste contigo siguen siendo tuyas, y el cliente recibe una licencia para usarlas como parte del sistema entregado. Ponlo en el acuerdo desde el principio, en lenguaje llano. La mayoría de los clientes quedan plenamente satisfechos con este arreglo, y protege tu biblioteca reutilizable.

Haz del propio traspaso un momento. Una sesión breve repasando lo que ahora es suyo, dónde está y cómo cambiarlo. Un repositorio o un proyecto ordenado con un léeme arriba del todo. Una declaración clara de que son libres de modificarlo, ampliarlo o pasárselo a otra persona. Los clientes recuerdan a un consultor que les dice, en esencia, ahora todo esto es vuestro; llamadme cuando queráis lo siguiente.

Esta semana, mira el último sistema que entregaste y comprueba: ¿lo tiene todo el cliente? Si no, envíaselo, con una nota breve. No te cuesta nada que importe y te compra más confianza que cualquier marketing que pudieras hacer.

Cierra el círculo a lo grande

Cuantifica lo que ha cambiado y díselo al comprador en su idioma. Los logros sin medir no se renuevan, no se recomiendan ni se recuerdan cuando llega el presupuesto. Puede que hayas transformado un flujo de trabajo, pero si nadie sabe decir cuánto, la mejora se diluye en el fondo general de cosas que ahora van bien. Seis meses después, cuando se revisa el presupuesto, la pregunta es qué consiguió realmente aquel consultor, y la respuesta sincera es que nadie lo apuntó.

Cerrar el círculo empieza al principio. El primer día, establece el punto de partida: cuánto tarda hoy la tarea, con qué frecuencia sale mal, cuántos casos maneja, cuánto cuesta en tiempo o en retrasos. Consigue las cifras del cliente, mídelas tú o estimadlas juntos con cuidado y apunta el método. Sin un punto de partida, cualquier medición posterior es una afirmación sin comparación.

Al final, mide lo mismo de la misma manera. Tiempo por tarea, tasa de errores, volumen gestionado, plazo de respuesta. Comunica la diferencia en los términos del cliente. No el sistema alcanza una gran precisión, sino el equipo redacta ahora las respuestas rutinarias en una fracción del tiempo, y el conjunto de evaluación muestra que los borradores cumplen el estándar acordado en la mayoría de los casos, con cada excepción detectada en la revisión. No se ha automatizado el flujo de trabajo, sino el informe mensual que llevaba un día entero ahora lleva menos de una hora. Concreto, comparable, en su idioma.

Luego díselo al comprador a lo grande. No en una nota a pie de página del documento de traspaso, sino como titular de la demo de cierre y en un breve resumen escrito que pueda reenviar. Ponle fácil compartir el resultado hacia arriba y hacia los lados: con su jefe, con su consejo, con sus compañeros de otros departamentos. El comprador queda bien, cosa que recordará, y el resultado viaja hasta personas que podrían querer algo parecido.

El trabajo no está terminado cuando funciona. Está terminado cuando alguien que firma presupuestos sabe que funciona.

Haz un seguimiento más adelante. Un mes después del traspaso, vuelve a comprobar las cifras. Los sistemas a veces rinden mejor en uso que en pruebas, a medida que la gente aprende a trabajar con ellos, y a veces peor, a medida que aparecen casos límite. En cualquier caso, el seguimiento es valioso: los buenos resultados se convierten en un caso de éxito más sólido, y los problemas pueden arreglarse antes de que socaven todo el esfuerzo. El seguimiento es también un momento natural para plantear el siguiente encargo, a partir de la lista de aparcados.

Sé honesto. Si el resultado es menor de lo esperado, dilo, y explica por qué. Los clientes confían mucho más en los consultores que comunican con exactitud resultados modestos que en los que lo inflan todo. Y un resultado modesto comunicado con exactitud, con una explicación clara de lo que lo mejoraría, suele ser la puerta del siguiente encargo.

Esta semana, para tu encargo actual o el más reciente, escribe un resumen de resultados de un párrafo: punto de partida, después, diferencia, en el idioma del cliente. Si no tienes punto de partida, estímalo con el cliente y apunta el método. Envíaselo al comprador con una nota breve. Luego incorpora la medición del punto de partida a tu plantilla de arranque, para no tener que reconstruirlo nunca más.

Pon precio a la brecha de valor

Ancla el precio en lo que el problema le cuesta al cliente, no en lo que el trabajo te cuesta a ti. En todo encargo hay dos cifras: el coste del problema para ellos, a lo largo de un año o más, y el coste del trabajo para ti. Con Claude haciendo buena parte del trabajo pesado, la segunda cifra ha caído en picado. La primera, no. La distancia entre esas dos cifras es donde debería vivir tu tarifa, y entender esa distancia es la base para poner bien precio a los encargos pequeños.

Este libro no da precios, y lo hace a propósito. Tus precios dependen de tu mercado, tu sector, tu reputación y tus clientes, y cualquier cifra impresa aquí sería errónea para la mayoría de los lectores. Lo que sí puede darte es la forma del razonamiento. Parte del problema del cliente y estima, junto a él, cuánto cuesta: horas de personal cada semana, errores y sus consecuencias, retrasos y su efecto en los clientes, oportunidades perdidas. Esa estimación, hecha con honradez, es el techo de lo que el arreglo vale para ellos.

Luego considera tu coste: tu tiempo, tus herramientas, tu riesgo. Ese es el suelo por debajo del cual no merece la pena hacer el encargo. Tu tarifa debería situarse holgadamente entre ambos, lo bastante cerca del valor como para reflejar lo que entregas y lo bastante por debajo como para que el cliente vea un retorno evidente. Un comprador que paga una tarifa que es claramente una fracción modesta del coste del problema no está regateando. Está tomando una decisión fácil.

La llamada de diagnóstico es donde reúnes el material para esto. Las preguntas sobre con qué frecuencia ocurre el problema, cuánto tarda, qué sale mal y cuánto cuesta no son solo diagnóstico; son los datos de entrada de tu precio. Cuando presentes la propuesta, enseña brevemente el razonamiento: esto es lo que estimamos que cuesta el problema, esto es lo que entregará el encargo, esta es la tarifa. La tarifa parece pequeña al lado del coste porque, si lo has hecho bien, lo es.

Ponle precio al agujero de su cubo, no a las horas que tardas en taparlo.

El precio por valor tiene un límite honesto. Si no puedes estimar el valor con cierta seguridad, no te inventes una cifra grande para justificar una tarifa grande. O bien haz un diagnóstico de pago para averiguarlo, o bien ponle al encargo un precio modesto como primer paso que generará las pruebas para uno mayor. Los clientes notan la diferencia entre una estimación cuidadosa y una ficción conveniente, y la segunda destruye la confianza muy deprisa.

También tiene un filo ético. Fijar el precio por valor no significa extraer todo lo posible. Significa poner precio de una forma que te recompense por los resultados y no por el esfuerzo, y que deje al cliente claramente mejor que antes. Un consultor que cobra el valor íntegro del problema deja al cliente sin ganancia y sin motivo para volver. Deja margen para una victoria clara en ambos lados.

Esta semana, coge un encargo reciente o próximo y estima, con todo el cuidado que puedas, cuánto le cuesta el problema al cliente a lo largo de un año. Apunta tu coste de entrega. Mira tu tarifa en relación con ambos. Si está mucho más cerca de tu coste que de su valor, probablemente has estado poniendo precio a tus horas y no a su resultado.

Nunca digas tú la primera cifra

Pregunta qué tiene asignado el cliente antes de decir una cifra. Las primeras veces resulta incómodo, y es una de las preguntas más útiles de la consultoría. A menudo la respuesta está por encima de lo que ibas a proponer. Cuando está por debajo, lo sabes pronto y puedes dar al encargo una forma que encaje, en lugar de descubrir el desajuste después de escribir una propuesta larga. En cualquier caso, te dice a qué estás jugando.

La pregunta puede formularse con suavidad. ¿Tenéis un presupuesto pensado para esto, o un rango del que no querríais salir? ¿Hay ya una partida asignada a este tipo de trabajo este año? Para asegurarme de proponer algo sensato, ¿en qué nivel de inversión estabais pensando? La mayoría de los compradores te darán algo, aunque sea aproximado. Algunos dirán que no tienen ni idea, lo cual también es información útil: sugiere que están al principio de su reflexión y que quizá tengas que ayudarles a construir el caso.

Cuando llegue la respuesta, úsala para dar forma al alcance, no para fijar el precio. Si la partida es generosa, puedes proponer un encargo más completo o la opción exhaustiva. Si es modesta, puedes proponer un primer paso más pequeño: una auditoría en lugar de un sprint, un kit de prompts en lugar de un piloto de agentes, un flujo de trabajo en lugar de tres. El objetivo no es capturar hasta el último céntimo del presupuesto. Es proponer algo que encaje con los medios del cliente y aporte un valor claro dentro de ellos.

Hay ocasiones en que el comprador insiste en que hables tú primero. No pasa nada. En ese caso, da un rango en lugar de una cifra única, anclado en el valor, y vincula cada extremo del rango a un alcance distinto. Para un encargo centrado en un flujo de trabajo, estaría en torno a esto; para uno más completo que cubra los procesos adyacentes, en torno a aquello. Un rango con alcances explicados invita a conversar sobre lo que quieren, en lugar de a un sí o un no sobre una cifra única.

La primera cifra que se pronuncia marca la sala. Que sea la suya siempre que puedas.

Claude puede ayudarte a prepararte. Antes de una conversación sobre precios, apunta lo que sabes del cliente, del problema y de su coste estimado, y pide un conjunto de opciones de alcance de distintos tamaños, cada una con un entregable y un resultado claros. Así llegas a la conversación preparado para responder a lo que diga el cliente con una forma que encaje. La preparación hace que la pregunta parezca natural y no evasiva.

Sobre todo, mantén la conversación en el terreno del valor y no del coste. Cuando un comprador revela un presupuesto, te está diciendo cuánto cree que vale resolver el problema. Si te parece bajo comparado con lo que estimaste, pregunta. Quizá han subestimado el coste del problema, y unas cuantas preguntas lo pondrán de manifiesto. Quizá tienen limitaciones que desconocías. En cualquier caso, aprendes algo importante antes de comprometerte a nada.

Esta semana, practica la pregunta. Escribe dos o tres formulaciones con las que te sientas cómodo y usa una en tu próxima conversación de venta. Fíjate en cómo cambia la conversación cuando el comprador habla primero de dinero. La mayoría de los consultores descubren que es mucho menos incómodo de lo que temían, y mucho más útil de lo que esperaban.

Siempre tres opciones

Un solo precio invita a un sí o a un no. Tres opciones invitan a elegir cuál. Es una decisión muy distinta para el comprador, y mucho mejor para ti. Cuando una propuesta tiene una sola opción, el comprador decide si trabajar contigo o no. Cuando tiene tres, ligera, estándar y completa, decide cuánto de lo que ofreces quiere. La pregunta ha pasado, sin hacer ruido, del «si» al «cuál».

Diseña las opciones en torno al alcance y al resultado, no a extras arbitrarios. La opción ligera resuelve el problema central de la forma más sencilla: un flujo de trabajo, un equipo, un traspaso cerrado. La estándar, la que esperas que elija la mayoría de los clientes, resuelve el problema central a fondo, con las piezas adicionales que lo hacen robusto: un conjunto de evaluación, un referente formado, una revisión de seguimiento. La completa extiende la solución a problemas adyacentes o añade un cuidado continuo. Cada opción es un encargo real y coherente que estarías encantado de entregar.

La opción del medio hace la mayor parte del trabajo. Los compradores tienden a evitar los extremos, así que la del medio suele ganar, lo que significa que deberías diseñarla como la que más quieres vender: el equilibrio adecuado de valor, esfuerzo y resultado para este cliente. La opción ligera hace que la del medio parezca sensata. La completa muestra lo que es posible y de vez en cuando la eligen clientes que quieren la versión íntegra. Ninguna es un señuelo. Las dos son alternativas honestas.

Haz que las diferencias sean claras y fáciles de comparar. Una tabla breve, con los entregables, el calendario y los resultados de cada opción uno al lado del otro, ayuda al comprador a ver exactamente qué gana en cada escalón. Evita las listas largas de pequeñas funciones; céntrate en las diferencias que importan para el problema del comprador. Y redacta las descripciones en el lenguaje del comprador, sobre sus resultados, no sobre tus actividades.

Un precio único es un examen. Tres opciones son una carta. La gente prefiere las cartas.

Claude puede redactar las tres opciones rápidamente a partir del resumen de diagnóstico y de tus plantillas de oferta. Dale el problema, el contexto del cliente, la partida si la conoces y tus formas de encargo estándar, y pide tres opciones coherentes con una tabla comparativa. Luego edita con cuidado. El modelo se inventará con mucho gusto extras para rellenar las opciones; tu trabajo es asegurarte de que cada una es un encargo real que entregarías bien.

También hay un beneficio sutil para acotar. Diseñar tres opciones te obliga a pensar con claridad qué es central y qué es ampliación. Esa claridad ayuda durante la entrega, porque sabes exactamente qué compró el cliente y qué no. Cuando llegue una petición de ampliación del alcance que corresponda a algo de la opción completa que rechazaron, puedes señalarlo con delicadeza. Ya saben lo que implicaría.

Esta semana, reescribe tu próxima propuesta con tres opciones en lugar de una. Haz que la del medio sea la que recomendarías, y asegúrate de que las otras dos son alternativas realmente útiles. Preséntalas una junto a otra. Fíjate en si la conversación pasa de si trabajar juntos a qué versión elegir. Suele pasar, y bastante deprisa.

Cobra el diagnóstico

Acotar gratis acostumbra a los compradores a tratar tu forma de pensar como una muestra. Cuando pasas días investigando el problema de un cliente, entrevistando a su personal y diseñando una solución, todo antes de cualquier acuerdo, estás regalando la parte más valiosa del trabajo. Algunos compradores cogerán ese trabajo y lo usarán ellos mismos, o se lo pasarán a un proveedor más barato. Otros sencillamente nunca decidirán, porque no se juegan nada. Un diagnóstico de pago filtra a los curiosos que solo miran y hace que la propuesta resultante sea mucho más difícil de rechazar.

La distinción está entre una conversación y una investigación. La llamada de diagnóstico es una conversación: una hora, gratis, suficiente para entender el problema a grandes rasgos y decidir si hay encaje. Todo lo que vaya más allá, entrevistas detalladas, mapas de procesos, análisis de datos, una recomendación por escrito, es una investigación, y las investigaciones son trabajo. El diagnóstico de pago no es más que el reconocimiento honesto de ello. Es también, en la práctica, la auditoría de pago de la primera parte con otro nombre, dimensionada para la pregunta concreta que hay sobre la mesa.

Plantea el diagnóstico como un entregable, no como una tarifa por tu tiempo. Un encargo breve, de alcance cerrado, que termina con un documento escrito y claro: el problema, su coste, las opciones para resolverlo, un enfoque recomendado con un encargo acotado y un resultado medido. Ese documento es valioso para el cliente tanto si sigue adelante contigo como si no. Podría llevárselo a otro proveedor, o usarlo internamente. La mayoría no lo hace, porque la persona que lo escribió es la candidata obvia para ejecutarlo.

El diagnóstico de pago también mejora espectacularmente tus propuestas. Con unos días de investigación como es debido, entiendes el problema lo bastante bien como para acotar con precisión, fijar el precio con seguridad y evitar las sorpresas desagradables que hunden los encargos de precio cerrado. El cliente, que ha invertido en el diagnóstico, tiene interés en actuar en consecuencia. Las propuestas que siguen a un diagnóstico de pago se aceptan muchísimo más a menudo que las que siguen a una sola llamada gratuita, porque ambas partes han hecho el trabajo.

El consejo gratuito se valora por lo que costó. Regálalo y lo tratarán como una muestra.

Algunos compradores pondrán objeciones, sobre todo los acostumbrados a consultores que acotan gratis. Explica la diferencia con calma: la llamada de diagnóstico es gratuita, y te alegra tenerla; la investigación detallada es un trabajo con un resultado valioso. Ofrece descontar parte o la totalidad del importe del diagnóstico del encargo posterior si siguen adelante dentro de un plazo determinado. Eso facilita la decisión a los compradores serios y filtra a quienes solo estaban coleccionando ideas gratis.

Claude hace eficiente el diagnóstico. La síntesis de las entrevistas, los mapas de procesos, el análisis de opciones y el borrador de recomendación pueden producirse rápidamente, dejando tu tiempo para el criterio sobre qué opción es la correcta. Eso significa que puedes ofrecer un diagnóstico con sustancia en un plazo corto y cerrado, lo que lo hace más fácil de comprar.

Esta semana, mira cómo acotas actualmente tus encargos. ¿Dónde termina la conversación gratuita y empieza la investigación no pagada? Traza la línea, ponle nombre al diagnóstico de pago como producto con un entregable claro y ofréceselo a tu próximo posible cliente que necesite algo más que una llamada para acotarse como es debido.

Anticipo antes que accesos

El trabajo empieza cuando se mueve el dinero. Esa regla sencilla elimina la mayoría de los problemas de cobro que tendrías de otro modo. Un anticipo, normalmente una parte significativa de la tarifa y a menudo la mitad, pagado antes de que empiece el encargo, es práctica habitual en muchos tipos de trabajo profesional. Pedirlo no tiene nada de especial. No pedirlo es un regalo a la minoría de clientes que, de lo contrario, pagarían tarde, pagarían a medias o no pagarían.

En los encargos pequeños, el anticipo hace algo más que asegurar el cobro. Confirma el compromiso. Un cliente que ha pagado un anticipo ha tomado una decisión real, ha implicado a quien aprueba el gasto y tiene interés en que el encargo arranque bien. Es más probable que facilite los accesos a tiempo, asista al arranque, designe al responsable de decisiones y participe en las demos de los viernes. Un cliente que no ha pagado nada puede dejarse llevar, retrasarse y reconsiderarlo sin coste alguno, y algunos lo harán.

Vincula el anticipo a la fecha de inicio. El encargo empieza en la fecha acordada siempre que haya llegado el anticipo y esté completa la lista de accesos. Si falta cualquiera de las dos cosas, el inicio se mueve. Esto enlaza limpiamente con el capítulo de los accesos: el anticipo y los accesos son las dos condiciones previas, y persigues ambas en los días anteriores al arranque. El cliente entiende que proteger el calendario le corresponde a él.

Pídelo con claridad. En el acuerdo, indica el anticipo, cuándo vence y qué asegura: la fecha de inicio, tu tiempo reservado para el encargo, el trabajo de preparación. Envía la factura con el acuerdo. No te disculpes por ello ni lo escondas. Los compradores profesionales están acostumbrados a los anticipos y no les dan importancia. Los únicos que protestan con fuerza suelen ser, la mayoría de las veces, aquellos a los que más necesitabas pedírselo.

Un anticipo no es una señal de desconfianza. Es una señal de que ambas partes han decidido.

El resto del pago también debería tener un desencadenante claro. En el traspaso, en la aceptación según el conjunto de evaluación o en una fecha fija tras la entrega: elige uno y ponlo por escrito. Vincula la aceptación a la definición de «terminado» y al umbral de evaluación acordados, para que no haya ambigüedad sobre cuándo está completo el trabajo y vence el pago. Unas condiciones claras al principio facilitan las conversaciones del final.

En las igualas, factura por adelantado cada periodo. El trabajo de un mes empieza cuando ese mes está pagado. Eso mantiene limpias las igualas y evita la lenta acumulación de meses impagados que de vez en cuando agria una relación por lo demás buena.

Mantén tu administración financiera tan ordenada como tu entrega. Facturación sencilla y puntual, con descripciones claras que hagan referencia al encargo con nombre y a sus entregables. Claude puede ayudarte a redactar el acuerdo, los conceptos de las facturas y los recordatorios corteses a partir de tus plantillas. Un consultor ordenado con el dinero da tranquilidad, porque sugiere que es ordenado con todo lo demás.

Esta semana, revisa tus condiciones estándar. Si no incluyen un anticipo, añádelo, con un vínculo claro a la fecha de inicio y a los accesos. Si lo incluyen, comprueba que de verdad lo haces cumplir. La primera vez que retrases una fecha de inicio porque falta un anticipo, puede que te sientas incómodo. El cliente, casi siempre, simplemente lo pagará.

Puesta en marcha más cuota mensual

Cobra como es debido la construcción, y luego vuelve a cobrar por mantenerla viva. La mayoría de los sistemas de este libro necesitan cuidados continuos: prompts y skills que se adaptan a medida que cambia el negocio, conjuntos de evaluación que crecen a medida que aparecen casos nuevos, mejoras cuando llegan modelos mejores, monitorización para detectar caídas de calidad, una persona a la que llamar cuando algo se rompe. Una tarifa de puesta en marcha cubre el trabajo de construir. Una cuota mensual cubre el trabajo de mantener su valor. Los ingresos recurrentes son lo que convierte unos ingresos de autónomo en un negocio.

La estructura es fácil de explicar a los clientes porque encaja con su experiencia con otros servicios. Pagan por que les instalen algo y luego pagan una cantidad continua modesta por mantenimiento y soporte. Las suscripciones de software funcionan así, igual que muchos servicios profesionales. Lo importante es que ambas partes aporten un valor claro y distinto: la puesta en marcha entrega un sistema que funciona; el acuerdo mensual entrega rendimiento y mejora continuos.

Define con precisión el acuerdo mensual, como se defendía para las igualas en la primera parte. Una revisión mensual de la calidad de las salidas frente al conjunto de evaluación. Una cantidad fija de trabajo de mejora. Actualizaciones cuando cambien los modelos o las herramientas. Un plazo de respuesta ante problemas. Un breve informe escrito cada mes que muestre qué hizo el sistema, qué cambió y qué recomiendas a continuación. Los clientes renuevan los acuerdos que ven funcionar. Cancelan los vagos en la primera revisión presupuestaria.

Ponle precio a la cuota mensual en función del valor, como a todo lo demás. Un sistema que ahorra a un equipo muchas horas a la semana merece cuidados, y la cuota mensual debería reflejar el valor de mantenerlo en marcha, no solo las horas que dedicas cada mes. Al mismo tiempo, mantenla modesta en relación con la puesta en marcha, para que se perciba como mantenimiento y no como una segunda compra. El objetivo es un acuerdo en el que los clientes apenas piensen porque obviamente merece la pena.

La construcción paga el mes en que construiste. El cuidado paga todos los meses siguientes.

Hay una disciplina de entrega que hace esto sostenible. Si cada cliente con iguala requiere atención a medida constante, el acuerdo mensual se convierte en un sumidero de tiempo. Estandariza el trabajo mensual: el mismo proceso de revisión, la misma plantilla de informe, el mismo ciclo de mejora, apoyados por skills y scripts que hacen las partes rutinarias. Claude puede ejecutar el conjunto de evaluación, redactar el informe mensual a partir de los registros y destacar los casos que requieren atención. Tu tiempo se dedica al criterio y a la mejora, no a la administración.

No todos los encargos necesitan un acuerdo mensual. Algunos sistemas son lo bastante sencillos como para funcionar con un buen manual de operaciones y un referente formado. Recomiéndalo con honradez cuando sea cierto. Pero cuando un sistema sí necesite cuidados, dilo en la propuesta e inclúyelo en el precio desde el principio. Un cliente que sabe desde el principio que el sistema tiene un coste mensual lo planifica. Uno que se entera en el traspaso se siente engañado.

Esta semana, mira los sistemas que has entregado y pregúntate cuáles se beneficiarían de un cuidado continuo. Para cada uno, esboza un acuerdo mensual: qué incluye, qué comunica, qué mejora. Luego ofrécelo, empezando por el cliente que haya obtenido mejores resultados. El mejor momento para proponer una iguala es cuando las pruebas del valor están frescas.

Conoce tu coste en tokens

La entrega agéntica tiene un coste marginal real, y es fácil ignorarlo hasta que te muerde. Cada llamada a un modelo cuesta algo, y el trabajo agéntico hace muchas llamadas: leer archivos, ejecutar herramientas, verificar resultados, repartir trabajo entre subagentes, iterar hasta que pasa una prueba. La mayor parte del tiempo el coste es pequeño en relación con la tarifa. De vez en cuando, una tarea mal acotada o un flujo de trabajo ineficiente consume mucho más de lo esperado, y tu sprint de precio cerrado se convierte discretamente en una pérdida de precio cerrado. Lleva la cuenta del gasto por encargo.

Llevar la cuenta no es difícil. La mayoría de las plataformas ofrecen informes de uso, y los planes difieren en cómo se mide y se limita el uso, así que entiende bien el tuyo. En los encargos construidos sobre la API, usa claves o espacios de trabajo separados por cliente para que los costes se atribuyan con claridad. En el trabajo con las aplicaciones de Claude y con Claude Code, vigila el uso durante el trabajo intensivo y anota qué tareas consumieron más. Al cabo de unos cuantos encargos, tendrás una idea de lo que cuesta entregar cada tipo de trabajo, lo que hace más preciso el precio.

La cuestión de fondo son los sistemas que entregas. El piloto de agentes de un cliente que procesa cientos de documentos al día tiene un coste de funcionamiento continuo, y el cliente necesita saber cuál es antes de comprometerse. Estímalo durante el piloto, a partir del uso real con trabajo real, e inclúyelo en el traspaso y en la propuesta para la siguiente fase. Es comprensible que los clientes se disgusten al descubrir, un mes después de la puesta en producción, que su nuevo sistema tiene un coste de funcionamiento que nadie mencionó.

Hay muchas formas de reducir el coste sin reducir la calidad. Usa modelos más pequeños y rápidos para los pasos sencillos y los más capaces solo donde importa el criterio. Mantén los contextos ligeros, como recomendaba la tercera parte. Usa la caché de prompts, donde la plataforma la admita, para las instrucciones estables y el material de referencia. Sustituye el trabajo repetitivo del modelo por scripts empaquetados. Agrupa en lotes el trabajo no urgente cuando haya procesamiento por lotes disponible. Cada una de estas cosas es además buena ingeniería, así que optimizar costes y mejorar la calidad suelen apuntar en la misma dirección.

Un precio cerrado con un coste desconocido no es un precio cerrado. Es una apuesta que no pretendías hacer.

Incorpora el coste de funcionamiento a tu estructura de precios cuando corresponda. En los sistemas gestionados bajo una iguala, decide si el cliente paga el consumo directamente en su propia cuenta, que suele ser lo más limpio, o si incluyes una cantidad en la cuota mensual. En cualquier caso, hazlo explícito. La ambigüedad sobre quién paga el consumo es una fuente habitual de roces en los encargos de IA, y es totalmente evitable.

No dejes que la ansiedad por el coste distorsione tu trabajo. En la mayoría de los microencargos, el coste del uso de modelos es modesto comparado con el valor entregado y la tarifa cobrada. El sentido de llevar la cuenta no es minimizar cada llamada, sino evitar sorpresas y poner precios precisos. Gasta donde mejore el resultado; recorta donde no.

Esta semana, mira el consumo de tu encargo más reciente y calcula a grandes rasgos cuánto costó entregarlo en uso de modelos. Compáralo con la tarifa. Luego estima el coste mensual de funcionamiento del sistema que entregaste y comprueba que el cliente lo conoce. Si alguna de las dos cifras te sorprende, has encontrado algo que merece la pena arreglar.

Sube en la renovación

Cada renovación es una oportunidad de revisar el precio, y la mayoría de los consultores se la saltan. Llega la renovación de una iguala, el cliente está contento y el camino de menor resistencia es seguir con las mismas condiciones. Mientras tanto, el sistema ha mejorado, tus habilidades se han profundizado, el valor entregado ha crecido y tus costes han cambiado. Los clientes existentes asumen las subidas mucho mejor de lo que cabría esperar cuando los resultados están documentados y la subida se explica.

La clave es la documentación. Una conversación de renovación que empieza con los informes mensuales, las puntuaciones de evaluación a lo largo del tiempo, las mejoras realizadas y el impacto medido en el trabajo del cliente es una conversación sobre valor. En ese contexto, un ajuste de la tarifa es una parte natural de la charla y no una sorpresa desagradable. Una conversación de renovación sin nada que enseñar es una conversación sobre coste, y en esa conversación cualquier subida parece una imposición.

Avísalo con antelación. Menciona, uno o dos meses antes de la fecha de renovación, que vas a revisar el acuerdo y a proponer los cambios que procedan. Cuando llegue la renovación, presenta la revisión: qué logró el sistema, qué cambió, qué propones para el periodo siguiente, incluido cualquier ajuste del alcance y de la tarifa. Da razones. Quizá el alcance ha crecido, o el valor ha aumentado, o tus tarifas han cambiado para los clientes nuevos y estás alineando poco a poco a los existentes. Las razones claras, expuestas con calma, suelen aceptarse.

Plantéate combinar la subida con algo nuevo. Una renovación que añade una capacidad útil, una sesión trimestral de estrategia, una cobertura ampliada, un flujo de trabajo adicional, junto con un ajuste de la tarifa, se percibe como una mejora y no como una subida de precio. El cliente recibe más, tú obtienes un retorno más justo y la relación crece en lugar de limitarse a continuar.

Callar en la renovación también es una decisión de precio. Solo que es una que no tomaste a propósito.

Sé sensato. Las subidas grandes y repentinas dañan la confianza, y los clientes que se sienten exprimidos empiezan a buscar alternativas. Los ajustes modestos, regulares y bien explicados son mucho más sostenibles. Y a veces la respuesta correcta es no subir nada: si el cliente está bajo presión, o el valor no ha crecido, mantener la tarifa es una opción razonable. La cuestión es decidirlo deliberadamente y no por inercia.

Las renovaciones son también un momento para comprobar el encaje. ¿Se ha vuelto el sistema tan estable que el cliente necesita menos cuidados? Dilo, y sugiere reducir el acuerdo o pasar a uno más ligero. Esa honradez se recuerda. ¿Ha crecido el negocio del cliente de modo que el sistema necesita más? Sugiere ampliarlo. Una renovación es un punto natural para remodelar la relación y ajustarla a la realidad.

Esta semana, haz una lista de tus acuerdos recurrentes y sus fechas de renovación. Para cada uno que venza en el próximo trimestre, prepara una breve revisión del valor: resultados, mejoras, alcance, condiciones propuestas. Luego ten la conversación, con antelación y con calma. A la mayoría de los consultores que lo prueban les sorprende lo rutinario que resulta.

El dinero gana a las acciones

Tarde o temprano, una startup te ofrecerá acciones en lugar de una tarifa. Andan cortos de liquidez, entusiasmados con el futuro y convencidos de que las acciones valdrán mucho más que tu factura. A veces será así. Normalmente no. Coge el dinero. Llevas un negocio, no una cartera de capital riesgo con una sola posición, y una práctica de microconsultoría depende mucho más del flujo de caja que de un potencial especulativo.

La aritmética es cruel con las acciones en los encargos pequeños. La mayoría de las empresas en fase inicial no triunfan como esperan sus fundadores, e incluso las que lo hacen pueden tardar muchos años en producir algún retorno para los accionistas pequeños, y para entonces tu participación puede haberse diluido considerablemente. Un pedacito modesto de una empresa que puede valer algo, o no, dentro de unos años no sustituye a una tarifa que paga tus facturas este mes. Es un décimo de lotería, y los décimos de lotería son una base pobre para un negocio.

También hay complicaciones prácticas. Los acuerdos con acciones necesitan papeleo legal, a veces asesoramiento fiscal y condiciones cuidadosas sobre la consolidación y sobre qué ocurre si la empresa cambia de rumbo. Para un encargo de dos semanas, esa carga administrativa no guarda ninguna proporción con el trabajo. Y las acciones pueden crear incentivos incómodos: te conviertes en inversor con interés en las decisiones de la empresa, lo que puede complicar el asesoramiento independiente que se supone que das.

Si una startup de verdad no puede pagar, hay opciones mejores que las acciones. Acota un primer encargo más pequeño que encaje con su presupuesto. Ofrece la opción ligera de tu propuesta de tres opciones. Aplaza parte de la tarifa hasta un hito definido, como su próxima ronda de financiación, con condiciones claras. O simplemente declina con educación y mantén el contacto, porque las startups que triunfan recuerdan a los consultores que fueron francos con ellas, y vuelven cuando tienen fondos.

Las acciones son una promesa sobre el futuro. El dinero es un hecho sobre el presente. Las prácticas pequeñas funcionan con hechos.

Hay excepciones raras. Si conoces bien a los fundadores, crees firmemente en la empresa y puedes permitirte tratar el encargo como una inversión que podrías perder por completo, un pequeño componente en acciones junto a una tarifa reducida puede ser razonable. Pero trátalo como una decisión de inversión deliberada, separada de tus ingresos de consultoría, y no dejes nunca que sustituya al dinero que tu práctica necesita para funcionar.

El principio general va más allá de las startups. Desconfía de cualquier acuerdo que sustituya una tarifa clara por algo incierto: participación en ingresos de productos no probados, pago en visibilidad, primas de éxito sobre resultados que no controlas. Cada uno tiene su lugar en circunstancias concretas, pero ninguno debería convertirse en la norma de una práctica construida sobre encargos pequeños, cerrados y fiables.

Esta semana, decide tu política sobre las acciones y otras ofertas no monetarias antes de que llegue la próxima. Ponla por escrito: tarifas en dinero como norma; elementos aplazados solo con condiciones claras; acciones solo como inversión paralela deliberada. Tener una política hace fácil la conversación y te libra de decidir bajo los efectos del optimismo contagioso de un fundador.

Despide a las malas cuentas

El cliente que menos paga y más pide está bloqueando al que más pagaría. Toda práctica acumula unas cuantas cuentas así: la iguala con un precio demasiado bajo desde hace años, el cliente que trata cada interacción como una negociación, aquel cuyo alcance se desborda pese a todos los protocolos, el que siempre paga tarde y siempre se queja pronto. Consumen tiempo, atención y energía en una proporción desmedida respecto a su valor. La higiene de la cartera es una estrategia de crecimiento, no un lujo.

El argumento es pura aritmética. Tu capacidad es limitada. Cada hora dedicada a una cuenta que te agota es una hora que no dedicas a una cuenta que te recompensa, ni al marketing, el desarrollo de producto y el aprendizaje que te traerían cuentas mejores. Las prácticas pequeñas lo notan con especial crudeza, porque no hay un equipo que absorba el coste. Una sola mala cuenta puede ocupar una parte significativa de la semana de un consultor que trabaja solo y la mayor parte de sus preocupaciones.

Revisa tus cuentas con regularidad, quizá cada trimestre. Para cada una, considera los ingresos, el tiempo que requiere, lo agradable y razonable que es trabajar con el cliente, si paga puntualmente, si el trabajo es interesante y si lleva a alguna parte: recomendaciones, casos de éxito, nuevas capacidades. Sitúalas a grandes rasgos. La mayoría de las cuentas estarán bien. Unas pocas serán excelentes. Una o dos te estarán costando claramente más de lo que te dan.

Con esas una o dos, intenta primero arreglar la relación. Revisa el precio del acuerdo en la renovación, restablece el alcance, recupera los protocolos que se relajaron. A veces una conversación franca transforma una cuenta. Si no lo hace, déjala ir, con profesionalidad y cortesía. Avisa con la antelación debida, cumple los compromisos pendientes, entrégalo todo como recomendaba la séptima parte y quizá sugiere otro proveedor que pueda encajar mejor. Despídete en buenos términos; el mundo es un pañuelo.

Decirle que no al cliente equivocado es como haces sitio para decirle que sí al adecuado.

El miedo, siempre, son los ingresos perdidos. En la práctica, el tiempo que se libera al dejar ir una mala cuenta suele llenarse enseguida, y con trabajo mejor, porque ahora tienes la capacidad y la energía para perseguirlo. El alivio también es considerable. Los consultores que se desprenden de un cliente que los agotaba suelen decir que ojalá lo hubieran hecho antes.

Más vale prevenir que curar. Las costumbres de este libro, alcance claro, anticipos, notas de cambio, aceptación basada en evaluaciones, resultados documentados, filtran a muchos clientes difíciles antes de que se conviertan en cuentas difíciles. Un diagnóstico o una auditoría de pago como primer encargo te enseña cómo es trabajar con un cliente antes de comprometerte con una relación más larga. Usa esa información. No a todos los clientes que compran una auditoría hay que ofrecerles una iguala.

Esta semana, haz una lista de tus cuentas actuales y valora cada una con honradez en valor y esfuerzo. Identifica la que más te cuesta a cambio de menos retorno. Decide si se puede arreglar o si hay que terminarla, y da el primer paso. Luego fíjate en lo ligera que se siente la semana siguiente.

Un caso de éxito por encargo

Escribe el caso de éxito mientras las cifras están calientes y el cliente encantado. Problema, enfoque, resultado, una frase del cliente: veinte minutos al final de un encargo, y tienes una prueba que podrás usar durante dos años. Déjalo un mes y las cifras se vuelven borrosas, el cliente ha pasado a otras prioridades y el caso de éxito no se escribe nunca. Cada encargo que terminas sin uno es una prueba que has tirado a la basura.

La estructura es sencilla y funciona. El problema, en los términos del cliente: qué iba mal, con qué frecuencia, con qué coste. El enfoque: lo que hiciste, brevemente, sin jerga, subrayando la forma del encargo para que el lector pueda imaginarse comprando lo mismo. El resultado: el antes y el después medidos en tu cierre, dichos con claridad. Y, con permiso del cliente, un breve comentario suyo sobre lo que cambió. Basta con una página. Más corto suele ser mejor.

Claude hace que esto cueste casi nada si has llevado un buen registro. El resumen de diagnóstico, el alcance, las notas de las demos de los viernes, los resultados de la evaluación y el resumen de cierre contienen todo lo necesario. Dáselos a Claude junto con tu plantilla de caso de éxito y pide un borrador en un lenguaje llano y concreto. Revísalo para comprobar su exactitud, quita todo lo confidencial y envíaselo al cliente para que lo apruebe. La mayoría de los clientes aprueban encantados un caso de éxito que los deja como gente sensata y con visión de futuro, que es lo que hace uno bueno.

El permiso y la confidencialidad importan. Acuerda al inicio del encargo, idealmente en el contrato, que podrás escribir un caso de éxito, sujeto a la aprobación del texto por parte del cliente. Algunos clientes querrán aparecer con su nombre; otros preferirán el anonimato, en cuyo caso descríbelos por sector y tamaño. No publiques nunca cifras ni detalles que el cliente no haya aprobado, y no incluyas nunca nada que pudiera identificar a sus clientes o a su personal sin consentimiento explícito.

Un encargo terminado sin caso de éxito es una venta que hiciste una vez en lugar de muchas.

Úsalos en todas partes. En tu web, agrupados por tipo de encargo, para que un posible cliente que busca una auditoría pueda leer sobre auditorías. En las propuestas, eligiendo el más pertinente o los dos más pertinentes para el sector y el problema del posible cliente. En tus correos de análisis y en tus charlas. En las conversaciones, como historias: un despacho muy parecido al vuestro tenía el mismo problema; esto es lo que hicimos y esto es lo que pasó. Los casos de éxito concretos y recientes están entre lo más persuasivo que puede ofrecer un consultor pequeño, porque sustituyen una promesa por un precedente.

Con el tiempo, tus casos de éxito forman una biblioteca que además te dice algo sobre tu propia práctica. ¿Qué encargos producen los resultados más sólidos? ¿Qué sectores responden mejor? ¿Qué ofertas llevan a igualas? Leer juntos tus propios casos de éxito es un ejercicio de estrategia sorprendentemente útil, y uno que la mayoría de los consultores nunca hacen porque nunca los pusieron por escrito.

Esta semana, escribe un caso de éxito de tu encargo terminado más reciente, con la estructura de cuatro partes. Si te faltan las cifras, pide al cliente una estimación honesta y señálala como tal. Envíalo para su aprobación. Luego añade escribir caso de éxito al último día de tu plantilla de encargo, para que ocurra siempre, mientras el entusiasmo está fresco.

Recomendaciones por diseño

Pide recomendaciones en el momento de máximo entusiasmo, y pide algo concreto. Las peticiones vagas de que te tengan en cuenta no producen exactamente nada, por siempre jamás. Los clientes tienen buena intención cuando dicen que hablarán de ti, y luego se llenan de trabajo y el momento pasa. Una petición concreta en el momento adecuado produce presentaciones. Las recomendaciones no surgen por casualidad con la frecuencia suficiente como para construir una práctica sobre ellas. Surgen por diseño.

El momento de máximo entusiasmo suele ser fácil de detectar. La demo de cierre, cuando el cliente ve el sistema terminado y el resultado medido. La primera vez que el sistema resuelve un problema que antes le arruinaba la tarde a alguien. El mensaje del referente diciendo que al equipo le encanta. En ese momento, la buena voluntad del cliente está en su punto álgido y el valor de tu trabajo es vívido. Es entonces cuando hay que pedir, no un mes después, cuando ya se ha vuelto normal.

Haz que la petición sea concreta. No si conoces a alguien a quien pueda interesarle, sino ¿a quién más conoces que lleve un despacho como el tuyo y tenga el mismo dolor de cabeza con el cierre de mes? O ¿hay alguien en tu asociación sectorial a quien le resultaría interesante este resultado? O ¿estarías dispuesto a presentarme al responsable de operaciones de vuestra empresa hermana? Una pregunta concreta lleva al cliente a pensar en una persona concreta. Una vaga lo lleva a decir que sí y a no pensar en nadie.

Pónselo fácil para actuar. Ofrécele una nota breve y reenviable que describa qué hiciste y para quién, que pueda mandar con una línea suya. Ofrécete a escribir el correo de presentación para que lo edite. Ofrece tu caso de éxito como adjunto. Cuanto menos esfuerzo cueste la recomendación, más probable es que ocurra. Claude puede redactar estas notas rápidamente, adaptadas a cada cliente y a la persona en la que está pensando.

Los clientes quieren ayudarte. Solo necesitan que les digas cómo, cuándo y a quién.

Agradece cada recomendación, acabe o no en trabajo. Una nota breve y personal, y una actualización si la presentación se convierte en un encargo. A la gente le gusta saber que su ayuda sirvió, y quienes reciben las gracias tienden a recomendar de nuevo. Algunos consultores ofrecen un pequeño detalle de agradecimiento por las recomendaciones que se convierten en encargos; que lo hagas o no es cuestión de gusto y de las costumbres de tu sector. Un agradecimiento sincero nunca está de más.

Diseña tus encargos para que produzcan momentos de recomendación. Las demos de los viernes, el cierre medido, el referente formado, el caso de éxito: cada uno crea un punto de entusiasmo y una ocasión natural. El formato del microencargo ayuda enormemente aquí, porque los encargos cortos producen momentos de conclusión frecuentes, y cada conclusión es una oportunidad para pedir. Una práctica construida sobre un flujo constante de encargos pequeños, terminados y exitosos es una práctica con muchos de esos momentos cada año.

Esta semana, piensa en tu cliente actual o en el más reciente. Identifica el momento de entusiasmo, pasado o por venir. Escribe una petición de recomendación concreta y una nota breve y reenviable. Luego pide, en ese momento, una presentación concreta. Lleva la cuenta de cuántas presentaciones produce este enfoque en los próximos meses comparado con las peticiones vagas que solías hacer.

El correo de análisis exprés

Haz el trabajo antes de la reunión. Un correo de análisis exprés es un análisis concreto e inconfundiblemente a medida del problema real de un posible cliente, enviado antes de cualquier conversación, sin más petición que una respuesta. Enseña en lugar de contar: esto es lo que he observado en tu negocio, esto es lo que podría mejorarse, así es más o menos cómo. Las tasas de respuesta de este tipo de prospección no se parecen en nada a las del correo en frío corriente, porque no se lee como un correo en frío. Se lee como si alguien ya hubiera empezado a ayudar.

La investigación es donde Claude transforma la economía. Elige un posible cliente de tu sector. Reúne lo que es público: su web, sus procesos publicados, sus ofertas de empleo, las opiniones de sus clientes, sus redes sociales, sus formularios de consulta. Pídele a Claude que lo analice en busca de oportunidades que sepas abordar: un proceso de consultas que parece manual, quejas de clientes por respuestas lentas, una oferta de empleo que describe tareas que podrían asistirse, documentación difícil de encontrar. Luego aplica tu criterio para elegir la o las dos que sean reales, concretas y estén dentro de tu oferta.

Escribe un análisis breve. Unos cuantos párrafos: lo que observaste, por qué probablemente les importa, cómo podría ser un pequeño arreglo y qué resultado podría producir. Incluye algo concreto, quizá un prototipo rápido, una muestra de una respuesta mejor, un boceto de una página de un proceso rediseñado. Cierra con una pregunta sencilla: ¿te sería útil que lo habláramos? Nada de adjuntos llenos de credenciales, nada de largas presentaciones sobre ti. El trabajo es la presentación.

Cuidado con el tono. Un análisis que se lee como una crítica será ignorado o despertará resentimiento. Plantéalo como oportunidad, no como fallo: he visto que vuestro formulario de consultas pide muchos datos de entrada; esta es una forma que podría convertir más visitas y ahorrarle tiempo a vuestro equipo. Sé exacto: señala solo cosas que hayas observado de verdad, y reconoce lo que no puedes ver desde fuera. Los posibles clientes notan al instante si alguien ha mirado de verdad su negocio o se ha limitado a rellenar una plantilla.

El correo en frío pide atención. Un análisis exprés la paga por adelantado.

El volumen no es el objetivo. Unos pocos análisis realmente a medida a la semana, bien investigados y bien dirigidos, producirán más conversaciones que cientos de mensajes genéricos. Claude hace que la investigación sea lo bastante rápida como para que un buen análisis lleve quizá una hora, que es una inversión sensata para un posible cliente que podría serlo a largo plazo. Ten una plantilla para la estructura, pero no dejes nunca que el contenido se vuelva genérico.

Respeta las normas de tu jurisdicción y las preferencias de tus posibles clientes. La prospección comercial está regulada en muchos sitios, y la buena práctica es enviar a un contacto profesional adecuado, identificarte con claridad y poner fácil decir que no. Un análisis que respeta el tiempo y la elección del posible cliente tiene muchas más probabilidades de ser bien recibido.

Esta semana, elige tres posibles clientes de tu nicho. Para cada uno, dedica una hora con Claude a investigar su material público, identifica una oportunidad concreta y escribe un análisis breve con algo concreto adjunto. Envíalos. Apunta las respuestas. Incluso las que dicen ahora no suelen ser cálidas, y el ahora no tiene la costumbre de convertirse en ahora unos meses después.

Publica una herramienta gratuita

Una herramienta pequeña y útil en tu nicho es la mejor tarjeta de visita jamás inventada. Cualifica a los posibles clientes, demuestra competencia y trabaja mientras duermes. Una calculadora que estima cuánto tiempo dedica un despacho a una tarea concreta. Un comprobador que revisa un documento frente a una norma habitual. Un generador que produce un primer borrador de algo que tus compradores necesitan con regularidad. Cada una es útil por sí misma, muestra lo que sabes construir y trae a tu puerta a las personas adecuadas.

La economía ha cambiado a favor de esto. Construir una herramienta pulida de propósito único llevaba semanas de desarrollo. Con Claude, una herramienta enfocada construida como artefacto de un solo archivo puede diseñarse, construirse y publicarse en un día o dos. La limitación ya no es construir; es elegir la herramienta adecuada. Y esa elección sale directamente de tu conocimiento del sector: ¿qué necesitan tus compradores una y otra vez, les resulta tedioso y agradecerían conseguir gratis?

Elige herramientas que conecten con tus ofertas de pago. Una herramienta que estima el tiempo que dedica un equipo a los informes manuales conecta de forma natural con un encargo de arreglo de flujo de trabajo. Una herramienta que puntúa lo preparada que está una empresa para la IA conecta con la auditoría de pago. Una herramienta que genera un primer borrador de una política conecta con el sprint de documentación. La herramienta gratuita resuelve un problema pequeño y revela uno mayor, que da la casualidad de que tú sabes resolver. No es un truco; es simplemente una secuencia útil.

Haz que la herramienta sea útil de verdad sin exigir datos de contacto. Poner cada herramienta gratuita detrás de un formulario de registro reduce su uso e irrita a las personas a las que más quieres impresionar. Deja que la gente la use libremente y ofrece un siguiente paso opcional: un informe más detallado por correo, una llamada breve para comentar el resultado, un enlace a un caso de éxito pertinente. Los posibles clientes que dan ese paso son los que más probabilidades tienen de comprar, y llegan ya convencidos de que sabes lo que haces.

Una herramienta que ayuda a alguien hoy se recuerda cuando mañana tiene presupuesto.

Mantenla enfocada, como defendía el capítulo de un artefacto por pregunta. Una herramienta que responde bien a una pregunta se comparte; una que intenta hacerlo todo se abandona. Dale un nombre claro que describa lo que hace, ponla donde la vayan a encontrar tus compradores y menciónala en tus análisis, tus charlas y tus publicaciones. Fíjate en cómo la usa la gente y mejórala de vez en cuando. Una herramienta pequeña que se mantiene al día y precisa sigue trabajando para ti durante mucho tiempo.

Cuidado con lo que afirma la herramienta. Una calculadora que produce estimaciones debe decir claramente que son estimaciones y explicar las suposiciones. Un comprobador debe dejar claro qué comprueba y qué no. Prometer de más en una herramienta gratuita socava precisamente la credibilidad que debía construir.

Esta semana, piensa en la pregunta que más a menudo hacen tus compradores y que una herramienta sencilla podría ayudar a responder. Construye una primera versión como artefacto de un solo archivo con Claude. Pruébala con alguien de tu nicho. Si le resulta útil, publícala y empieza a mencionarla. Si no, pregúntale qué le sería más útil, y construye eso en su lugar.

Construye a la vista

Entrega algo visible cada semana y deja que el trabajo haga la prospección. Los compradores contratan a la persona cuyo trabajo llevan tres meses observando. Construir a la vista significa compartir tu trabajo mientras lo haces: las herramientas que construyes, los problemas que resuelves, las lecciones que aprendes, los experimentos que salieron bien y los que no. Con el tiempo, ese flujo constante de trabajo visible construye una reputación que ninguna cantidad de publicidad puede comprar.

Qué compartir depende de tu nicho y de la confidencialidad de tus clientes. No puedes publicar el trabajo de un cliente sin permiso, pero puedes compartir muchísimo a su alrededor. Una nueva herramienta gratuita. Una técnica que has refinado. Un breve texto sobre un problema habitual en tu sector y cómo lo abordas. Un ejemplo sintético de un flujo de trabajo que has arreglado, reconstruido con datos de muestra. Una lección de un piloto, anonimizada. Una skill que has publicado en abierto. Cada pieza muestra cómo piensas y qué sabes hacer.

La constancia importa más que la brillantez. Una publicación útil o un pequeño lanzamiento cada semana, durante meses, es mucho más eficaz que un arrebato ocasional de actividad. Las personas que acabarán contratándote observan en silencio; necesitan verte aparecer con regularidad, haciendo buen trabajo, hasta que te conviertes en la persona obvia a la que llamar. Claude ayuda con la producción: convertir tus notas en una publicación legible, construir las pequeñas demostraciones, redactar los resúmenes. El criterio sobre qué merece la pena compartir sigue siendo tuyo.

Comparte en los sitios donde de verdad están tus compradores. En algunos nichos es una red profesional. En otros, un foro del sector, un boletín, un grupo comunitario o una publicación especializada. Construir a la vista en un sitio que tus compradores nunca visitan es un pasatiempo, no una cartera de clientes. Averigua dónde leen tus compradores y preséntate allí con trabajo útil, con constancia.

La visibilidad no es vanidad cuando lo visible es útil. Es simplemente una llamada comercial muy lenta y muy eficaz.

Construir a la vista también mejora el trabajo. Explicar lo que hiciste te obliga a entenderlo con claridad. Los comentarios de los colegas mejoran tus métodos. Las preguntas de los posibles clientes revelan lo que de verdad le importa a tu mercado. Y el archivo de trabajo público se convierte en un recurso al que puedes remitir a los posibles clientes: así es como abordo este problema; esta es una herramienta que construí para ello; esto es lo que pasó cuando lo probé.

Hay límites honestos. Construir a la vista lleva tiempo, y puede convertirse en una distracción del trabajo pagado. Fija un ritmo modesto y sostenible, quizá una o dos horas a la semana, y protégelo sin dejar que crezca. Y recuerda que el objetivo es ser útil, no lucirse. Las publicaciones escritas para impresionar a otros consultores rara vez atraen clientes. Las que resuelven un problema real a un comprador, a menudo sí.

Esta semana, decide qué vas a compartir cada semana durante los próximos tres meses, y dónde. Luego comparte lo primero. Lleva una lista sencilla de lo que has compartido. Dentro de tres meses, repasa la lista y las conversaciones que produjo. Los resultados rara vez son espectaculares en las primeras semanas y suelen ser inconfundibles al final.

Da una charla en el meetup

Veinte personas implicadas en una sala ganan a dos mil impresiones en internet. Los grupos empresariales locales, las asociaciones sectoriales, los actos de la cámara de comercio y los encuentros del sector están llenos de personas con presupuesto y problemas, reunidas precisamente para aprender algo útil. Una charla breve y práctica en uno de estos actos convierte notablemente bien, porque todos los presentes ya han decidido dedicar tiempo al tema, y tú eres la persona que acaba de enseñarles algo que pueden usar.

Las mejores charlas son prácticas, concretas y cortas. No el futuro de la IA en la empresa, que todos los asistentes han oído varias veces, sino cómo un despacho como el tuyo puede quitarle un día al cierre de mes con una herramienta que cuesta menos que una comida, con una demostración en directo sobre datos realistas. Enseña una o dos cosas funcionando. Dale al público algo que pueda probar esa misma tarde. Deja tiempo para preguntas, porque en las preguntas es donde empiezan las conversaciones de verdad.

Construir en la sala, como se describía en la sexta parte, es especialmente potente en un meetup. Pide al público un problema que tengan y resuelve en directo con Claude una versión pequeña. No tiene por qué ser complicado. Una respuesta redactada a un correo difícil de un cliente, el resumen de un documento de políticas largo, una herramienta rápida que hace un cálculo que ahora hacen a mano. El público ve la capacidad aplicada a su propio tipo de problema, en tiempo real, y muchos querrán hablar contigo después.

Prepara el seguimiento antes de la charla. Una página breve con los puntos principales, los prompts que demostraste y un enlace a tu herramienta gratuita o a los casos de éxito pertinentes. Una forma fácil de reservar una llamada breve. Un número pequeño de huecos para conversaciones de diagnóstico en las semanas siguientes. La charla genera interés; el seguimiento lo convierte en conversaciones. Sin seguimiento, el interés se evapora en pocos días.

Una sala con veinte personas que tienen el mismo problema es el mejor público que tendrá jamás un especialista.

Los organizadores de grupos locales a menudo buscan ponentes, sobre todo con algo práctico que decir. Acércate a ellos con una propuesta de charla clara y concreta, pertinente para sus miembros, con la promesa de conclusiones prácticas y sin discurso comercial. Y luego cumple esa promesa: una charla que se convierte en anuncio pierde a la sala y la buena voluntad del organizador. La venta ocurre después, en las conversaciones, porque fuiste útil.

Las charlas se acumulan. Una buena charla lleva a invitaciones para darla en otros sitios. Las grabaciones o los resúmenes escritos pasan a formar parte de tu trabajo público. Los asistentes se convierten en clientes, que se convierten en casos de éxito, que se convierten en ejemplos de tu próxima charla. Un especialista que da una charla útil en su nicho cada mes o dos será, en menos de un año, ampliamente conocido en ese nicho, que es justo la posición que recomienda este libro.

Esta semana, busca dos o tres grupos donde se reúnan tus compradores. Esboza una charla práctica de veinte minutos con una demostración en directo y una técnica para llevarse a casa. Contacta con un organizador. Luego prepara la página de seguimiento y el enlace de reserva antes de que llegue la fecha, para que el interés que generes tenga adónde ir.

Hazte con las búsquedas de tu nicho

Aparece en todos los sitios donde busca tu comprador concreto. Directorios, páginas de partners, marketplaces, listas de asociaciones, ecosistemas de proveedores. La distribución aburrida gana al contenido brillante que nadie encuentra. Un comprador de tu nicho que decide buscar ayuda con la IA no empieza leyendo artículos de liderazgo intelectual. Busca, pregunta a su asociación, mira la página de partners del software que ya usa o consulta un marketplace de proveedores homologados. Si no estás ahí, no te tienen en cuenta.

Empieza por trazar el mapa de dónde buscan tus compradores. Pregunta a tus clientes actuales cómo buscarían a alguien como tú si tuvieran que empezar de cero. Mira el software que suele usar tu nicho y si esos fabricantes tienen listas de partners de implantación o de consultores. Comprueba si las asociaciones profesionales del sector mantienen listas de proveedores homologados. Encuentra los marketplaces donde las empresas de tu nicho compran servicios. Cada una de estas es una puerta por la que llegan compradores, ya cualificados y ya buscando.

Luego date de alta, como es debido. Un perfil claro y concreto que diga exactamente qué haces y para quién: no consultor de IA, sino arreglos de flujos de trabajo y auditorías de IA para pequeñas asesorías contables. Tus ofertas con nombre, descritas brevemente. Dos o tres casos de éxito pertinentes. Siguientes pasos claros. Muchas fichas son gratuitas o baratas; algunas requieren una solicitud o una acreditación. El esfuerzo es modesto y las fichas trabajan durante años con alguna actualización ocasional.

Tu propia web también importa, y debería construirse para las búsquedas que de verdad hacen tus compradores. Una página para cada oferta con nombre, escrita en el lenguaje de tus compradores, que responda a las preguntas que se hacen. Casos de éxito agrupados por sector y tipo de encargo. Tu herramienta gratuita, fácil de encontrar. Claude puede ayudarte a redactar y pulir estas páginas, pero lo concreto tiene que salir de tu conocimiento del nicho. Las páginas genéricas atraen visitantes genéricos; las concretas atraen compradores.

El mejor contenido del mundo pierde frente a una ficha sencilla en el único sitio donde tu comprador miró de verdad.

Las búsquedas impulsadas por IA también están cambiando cómo encuentran proveedores los compradores. Cada vez más, la gente le pide a un asistente que le recomiende a alguien para una necesidad concreta. Esos asistentes se nutren de lo que se ha publicado y listado sobre ti. Unas descripciones claras, concretas y coherentes de lo que haces, para quién, con pruebas de resultados, en tu web y en tus fichas, hacen más probable que te encuentren y te describan con exactitud. Los principios son los mismos que para la búsqueda humana: sé concreto, sé coherente, está presente.

Mantén tus fichas. Los perfiles desfasados, los enlaces rotos y los casos de éxito antiguos sugieren una práctica que no presta atención, justo lo contrario de lo que quieres transmitir. Ponte un recordatorio cada trimestre para revisar y actualizar cada ficha. Lleva una hora y mantiene las puertas abiertas.

Esta semana, enumera todos los sitios donde un comprador de tu nicho podría buscar ayuda como la tuya. Comprueba si estás presente en cada uno. Elige los tres más importantes en los que no estás o estás mal representado, y arréglalo. Luego pregúntale a tu próximo cliente nuevo cómo te encontró. Su respuesta te dirá qué puertas están funcionando.

Publica la lista de espera

Las limitaciones de capacidad son reales y merece la pena decirlas. Un microconsultor solo puede llevar unos cuantos encargos a la vez. Cuando tienes la agenda llena, el instinto es esconderlo, ya sea porque parece que rechazas trabajo o porque suena a fanfarronería. En lugar de eso, publícalo. Una lista de espera visible, con la próxima fecha de inicio disponible, reencuadra la conversación: pasa de si contratarte a cuándo puedes empezar.

La psicología es sencilla. Un consultor que puede empezar mañana suscita una pequeña pregunta tácita: ¿por qué está disponible? Un consultor cuya próxima fecha de inicio está a varias semanas indica que otras personas lo han elegido y que su tiempo es valioso. La pregunta del comprador pasa de ¿deberíamos contratar a esta persona? a ¿deberíamos reservar un hueco antes de que lo haga otro? Es una pregunta mucho mejor para ti, y es totalmente honesta si tu agenda está realmente llena.

Haz que la lista de espera sea práctica. Indica la próxima fecha de inicio disponible para cada tipo de encargo en tu web o en tus respuestas. Ofrece una forma sencilla de reservar un hueco, quizá con un pequeño anticipo que se descuenta de la tarifa. Mantén el contacto con quienes están en la lista de espera, compartiendo material útil y confirmando su fecha de inicio a medida que se acerca. Algunos consultores ofrecen una auditoría o un diagnóstico de pago como forma de empezar antes de que se abra el hueco del encargo principal, lo que mantiene el impulso mientras el comprador espera.

El formato del microencargo hace que esto sea más fácil de gestionar. Como los encargos son cortos y cerrados, puedes predecir tu capacidad con una seguridad razonable. Sabes que un sprint de dos semanas ocupa dos semanas, que puedes llevar tantos a la vez y cuándo se libera cada hueco. Una práctica construida sobre encargos indefinidos nunca puede publicar una lista de espera fiable, porque nadie sabe cuándo termina nada.

La disponibilidad es una señal. Asegúrate de que dice la verdad: que el buen trabajo lleva tiempo y que otros ya lo saben.

Sé honesto. Una lista de espera falsa, que afirma que estás completo cuando no lo estás, es una manipulación que los compradores detectan rápido y que les sienta fatal. Publica una lista de espera solo cuando tu capacidad esté realmente limitada, y mantén las fechas exactas. Si se abre un hueco inesperadamente, ofrécelo a la siguiente persona de la lista. La integridad en las cosas pequeñas genera confianza en las grandes.

Una lista de espera también te da información. Si se alarga mucho, quizá tus precios estén por debajo de lo que deberían, o estés listo para convertir más servicios en producto, o para incorporar ayuda. Si se mantiene corta, tu cartera necesita atención. En cualquier caso, la lista de espera es una medida sencilla y visible de la demanda que te ayuda a tomar decisiones sobre tu práctica.

Esta semana, mira con honradez tu capacidad para los próximos tres meses. Si estás casi lleno, publica tus próximas fechas de inicio disponibles y una forma de reservar un hueco. Si no, anota qué haría falta para llegar al punto en que una lista de espera tuviera sentido, y trabaja para conseguirlo. Una agenda llena con una cola visible es una de las posiciones más cómodas en que puede estar un consultor, y una de las más persuasivas.

Lo cálido gana a lo frío

Tus cinco últimos clientes conocen a todas las personas que quieres conocer. El seguimiento sistemático de antiguos clientes y contactos dormidos rinde más que cualquier canal en frío que vayas a construir jamás. Las personas que han trabajado contigo, o te han conocido, o han visto tu trabajo, ya confían en ti en cierta medida. Las que nunca han oído hablar de ti no confían en ti en absoluto. Partir de cierta confianza es una ventaja enorme, y la mayoría de los consultores la desperdician dejando que las relaciones se apaguen cuando termina un encargo.

La solución es un sistema sencillo y regular. Lleva una lista de antiguos clientes, referentes, personas que te han recomendado, contactos de meetups y gente que mostró interés pero no compró. Cada mes o cada dos meses, ponte en contacto con unos cuantos, no para vender sino para ser útil: un artículo pertinente, una herramienta nueva, una nota sobre una capacidad que ha mejorado, una pregunta sobre cómo va el sistema que construiste. Cada contacto mantiene cálida la relación. Algunos se convierten en conversaciones, y algunas de esas en encargos.

Los antiguos clientes son los más cálidos de todos. Conocen tu trabajo, han visto resultados y probablemente tienen más problemas que podrías resolver, muchos de ellos ya en la lista de aparcados de tu protocolo del alcance. Una nota breve unos meses después del traspaso, ¿qué tal funciona el sistema de clasificación? Me fijé en que mencionaste el proceso de devoluciones durante el sprint; ¿te sería útil que lo miráramos ahora?, suele bastar. El trabajo recurrente de antiguos clientes suele ser el más fácil, rápido y rentable que puede ganar una práctica.

Claude puede ayudarte a llevar este sistema sin que se convierta en una lata. Guarda tus contactos y notas en un solo sitio. De vez en cuando, pídele a Claude que te sugiera a quién contactar y que redacte una nota personalizada para cada uno, a partir de tus notas sobre la persona, su negocio y vuestra última conversación. Revisa y edita cada una, porque tiene que sonar a ti y ser pertinente de verdad. El modelo redacta; tú pones la relación.

Tu red no es a quién conoces. Es con quién has mantenido el contacto.

Sé útil de verdad, no te limites a estar presente. Un mensaje que dice solo quería saludar es fácil de ignorar. Un mensaje que dice he visto este cambio en la normativa de tu sector y me he acordado de la documentación de políticas que hicimos; aquí tienes una nota rápida sobre lo que significa para vosotros es valioso, y le recuerda al destinatario por qué valoró trabajar contigo. El objetivo es que cada contacto sea bienvenido, para que la gente tenga ganas de saber de ti.

Lleva la cuenta de lo que pasa. Con el tiempo verás qué tipos de contacto llevan a conversaciones, qué antiguos clientes vuelven, qué personas te hacen las mejores presentaciones. Ese conocimiento te ayuda a concentrar tu esfuerzo donde funciona. La mayoría de los consultores que lo hacen descubren que una gran parte de su trabajo viene de gente que ya conocían, un descubrimiento tranquilizador para cualquiera que se preocupe por encontrar el próximo cliente.

Esta semana, haz una lista de tus antiguos clientes y contactos cálidos. Elige cinco. Para cada uno, escribe una nota breve y útil de verdad basada en lo que sabes de ellos, y envíala. Luego pon un recordatorio recurrente en tu calendario para hacer lo mismo cada mes. Es la cartera de clientes más fiable que vas a construir jamás.

Escribe el manual

Publicar tu método no te cuesta casi nada y te convierte en la persona obvia a la que contratar. Parece contraintuitivo: si explicas exactamente cómo haces una auditoría, un arreglo de flujo de trabajo o un piloto de agentes, ¿no lo harán los clientes ellos mismos? Algunos quizá. La mayoría no, porque saber cómo se hace algo es muy distinto de tener el tiempo, la habilidad y la experiencia para hacerlo bien. Lo que hace la publicación es demostrar, sin lugar a dudas, que sabes de lo que hablas.

Un manual puede adoptar muchas formas. Una serie de artículos que describen tu enfoque para cada tipo de encargo. Una guía descargable para tu nicho. Un conjunto de skills o plantillas publicadas en abierto. Incluso un libro, del tipo que estás leyendo. Cada uno muestra tu forma de pensar en detalle, y el pensamiento detallado es mucho más persuasivo que las proclamas de pericia. Un comprador que ha leído tu manual llega a la primera conversación entendiendo ya tu enfoque y en gran medida convencido de que es el correcto.

La razón por la que rara vez canibaliza tu negocio es sencilla. Las personas que podrían ejecutar tu método a partir de una descripción escrita no son, en su mayoría, tus compradores. Tus compradores son personas ocupadas que dirigen negocios y que quieren el resultado sin pasarse meses aprendiendo a producirlo. Leer tu manual les demuestra que el resultado es alcanzable y que tú eres la persona capaz de alcanzarlo. La minoría que intenta hacerlo por su cuenta a menudo descubre cuánto criterio requiere, y algunos te llaman después.

Claude puede ayudarte a escribirlo a partir del material que ya tienes: tus plantillas de encargo, tus casos de éxito, tus manuales de operaciones, tus notas de charlas. Pídele que redacte capítulos o artículos a partir de ese material y luego edita a fondo, añadiendo las historias, los juicios y las salvedades que solo tú conoces. El manual terminado debería sonar a ti, reflejar lo que de verdad haces y ser honesto sobre lo que es difícil. Un manual que hace que todo parezca fácil se leerá como marketing y se descontará en consecuencia.

Regala la receta. La mayoría de la gente seguirá prefiriendo que cocine otro.

Publicar también afila tu práctica. Poner por escrito cómo haces algo te obliga a aclararlo, y la claridad mejora la entrega. Los lectores hacen preguntas y señalan huecos, lo que mejora el método. Y un método publicado se convierte en un recurso de formación si alguna vez incorporas colaboradores o socios, que pueden aprender tu enfoque con el mismo material que leen tus clientes.

Es la culminación natural de esta parte. Los casos de éxito demuestran resultados individuales; las recomendaciones y los contactos cálidos te traen gente; los análisis exprés, las herramientas gratuitas, la construcción a la vista, las charlas y las fichas te hacen visible. Un manual publicado lo une todo en una declaración única y con autoridad: así es como trabajo, por esto funciona y esto es lo que puedes esperar. En un mercado abarrotado de promesas vagas, un método claro, concreto y publicado es algo raro y valioso.

Esta semana, escribe el primer capítulo de tu manual: cómo llevas tu encargo más habitual, paso a paso, con el razonamiento que hay detrás de cada paso. Publícalo en algún sitio donde lo vean tus compradores. Luego fíjate en quién lo menciona en las próximas conversaciones. Puede que descubras que vende más que tú.

Vende sistemas, no sesiones

Una sesión termina cuando te desconectas. Un sistema sigue produciendo a las tres de la madrugada. Esa distinción es la base de hacia dónde va la microconsultoría. El consultor que vende sesiones, talleres, consejos, horas de atención, vende algo que se detiene en el momento en que él se detiene. El consultor que vende sistemas, flujos de trabajo que se ejecutan, skills que se cargan, agentes que procesan, herramientas que responden preguntas, vende algo que sigue aportando valor mucho después de que termine el encargo.

Este libro ha ido construyendo esa idea desde el principio. El arreglo de flujo de trabajo deja tras de sí un flujo que funciona. El kit de prompts deja prompts probados. La biblioteca de skills deja capacidades. El piloto de agentes deja un sistema procesando trabajo real. El sprint de documentación deja un conocimiento que pueden usar tanto las personas como los modelos. Cada encargo es pequeño, pero cada uno produce algo que lo sobrevive. Con el tiempo, un cliente acumula sistemas que tú construiste, cada uno todavía en marcha, cada uno un recordatorio de tu valor.

Diseñar pensando en esto cambia cómo abordas cada encargo. La pregunta no es solo ¿qué vamos a hacer juntos?, sino ¿qué seguirá funcionando cuando me vaya? Esa pregunta te empuja hacia las costumbres que ha recomendado este libro: manuales de operaciones claros, referentes formados, conjuntos de evaluación, barreras en el sistema y no en un documento, prompts entregados, todo versionado y en propiedad del cliente. Un sistema que depende de ti para funcionar es una sesión disfrazada.

El precio sigue al diseño. Una sesión se cobra por tiempo, porque el tiempo es lo que consume. Un sistema se cobra por valor, porque el valor es lo que produce, y lo produce de forma continua. Un encargo modesto que deja tras de sí un sistema que ahorra muchas horas cada semana vale muchísimo más que un taller de la misma duración, y los clientes lo entienden cuando se les muestra con claridad, con un punto de partida, una medición y un total acumulado.

Las sesiones se recuerdan. De los sistemas se depende. La dependencia es la relación más sólida.

Por debajo hay un cambio más profundo. A medida que mejoran las capacidades de la IA, el valor de la atención en directo de un consultor en una sesión concreta va cayendo, porque buena parte de lo que esa atención aportaba ahora pueden aportarlo las herramientas. El valor de diseñar, construir y mantener sistemas que aprovechen esas herramientas va subiendo, porque eso requiere criterio, contexto y cuidado que las herramientas no aportan por sí solas. Vender sistemas te coloca en el lado bueno de ese cambio.

Nada de esto significa que las sesiones no valgan nada. Una buena sesión de formación o un taller estratégico pueden ser enormemente valiosos, y algunos clientes necesitan exactamente eso. Pero incluso una sesión puede diseñarse para que deje un sistema tras de sí: un kit de prompts de la formación, un marco de decisión del taller, una skill que codifica el método que aprendió el equipo. Las mejores sesiones son las que se convierten en sistemas.

Esta semana, repasa tus ofertas y pregúntate de cada una: ¿qué sigue funcionando cuando me voy? Si la respuesta es nada, rediseña la oferta para que deje algo. Si la respuesta es un sistema, asegúrate de que tus precios, tus propuestas y tus casos de éxito lo digan con claridad. No vendes tu tiempo. Vendes máquinas que siguen funcionando, con tu criterio incorporado.

Agentes que informan de su valor

El siguiente nivel de encargo es un sistema que ejecuta el flujo de trabajo e informa de su propio valor. Cada mes, sin que nadie se lo pida, produce un breve relato de lo que hizo: cuántos casos gestionó, cuánto tiempo ahorró, qué puntuaciones de calidad obtuvo, qué problemas señaló, qué cambió. Cuando el agente justifica su propia factura, la renovación deja de ser una conversación y se convierte en un trámite.

Las piezas ya están en este libro. Un agente o un flujo de trabajo que maneja trabajo real, del capítulo del piloto. Un registro de cada acción y su resultado, del diseño con una persona en el circuito. Un conjunto de evaluación que se vuelve a ejecutar con regularidad, del capítulo de la aceptación. Un punto de partida del inicio del encargo, del capítulo de cerrar el círculo. Júntalo todo y podrás generar automáticamente un informe mensual: volumen, tiempo ahorrado respecto al punto de partida, puntuación de calidad, excepciones, mejoras realizadas, recomendaciones.

Claude puede producir ese informe a partir de los registros y de los resultados de la evaluación con muy poca supervisión una vez que la plantilla está montada. Tu papel pasa a ser revisarlo, añadir comentarios donde haga falta criterio y enviárselo al cliente. El informe hace tres cosas. Le muestra al cliente el valor que recibe, en sus términos, cada mes. Te avisa pronto cuando la calidad baja o el volumen cambia. Y construye un registro de resultados cada vez mayor que defiende la renovación, la ampliación y la recomendación.

Sé escrupulosamente honesto en estos informes. El tiempo ahorrado debe calcularse con un método declarado, frente al punto de partida acordado con el cliente. La calidad debe medirse con la rúbrica acordada. Los problemas y los fallos deben comunicarse, no esconderse. Un informe que solo trae buenas noticias acabará generando desconfianza. Uno que muestra algún problema ocasional junto al valor global, y explica qué se hizo al respecto, resulta creíble, que es de lo que se trata.

El mejor argumento para renovar es uno que el cliente lleva un año leyendo cada mes.

Esto cambia a tu favor la economía de las igualas. Una iguala justificada por pruebas mensuales de valor es mucho más duradera que una justificada por una vaga sensación de que las cosas funcionan. También sostiene el precio: un sistema que demostrablemente ahorra muchísimo tiempo cada mes puede llevar una cuota mensual que refleje una parte justa de ese valor, y el cliente puede ver las cuentas por sí mismo.

Hay una frontera más allá, en la que los sistemas no solo informan de su valor sino que asumen una parte mayor de su propia mejora, proponiendo cambios a partir de los casos que gestionan y de las puntuaciones que reciben, para que una persona los apruebe. Eso empieza a ser viable, y encaja con el patrón de este libro: autonomía ampliada donde las pruebas la respaldan, con una persona sosteniendo el criterio. Construye primero los informes. El bucle de mejora crece de ellos de forma natural.

Esta semana, coge un sistema que hayas entregado y diseña su informe mensual de valor: las métricas, el punto de partida, el método, el formato. Genera una primera versión a partir de los registros y resultados que existan. Envíasela al cliente, aunque esté sin pulir. Observa su reacción. Los clientes rara vez reciben este tipo de pruebas de nadie, y la primera suele dejar una impresión duradera.

Hazte con la capa de evaluación

A medida que los modelos se vuelven más capaces y más accesibles, la habilidad escasa pasa a ser saber si lo que producen es bueno. Cualquiera puede generar un informe verosímil, una respuesta verosímil, un fragmento de código verosímil. Muchas menos personas saben decir, con fiabilidad y a escala, cuáles de esas salidas verosímiles son realmente correctas para un negocio concreto y cuáles están sutilmente equivocadas de maneras que costarán dinero más adelante. Quien es dueño de esa medición es dueño de la confianza, y la confianza es lo que se paga.

La capa de evaluación es el conjunto de herramientas, casos, rúbricas y procesos que responden a la pregunta ¿esto es bueno? para el trabajo de un cliente concreto. Incluye los conjuntos de evaluación construidos durante los encargos, las rúbricas acordadas con el cliente, los agentes verificadores que comprueban las salidas, los registros de aprobaciones y correcciones humanas y los informes mensuales que siguen la calidad a lo largo del tiempo. Bien construida, permite al cliente saber, en cualquier momento, qué tal funcionan sus sistemas de IA y dónde necesitan atención.

Para un microconsultor, ser dueño de esta capa es una posición duradera. Los modelos cambian; la capa de evaluación persiste y gana valor a medida que crece. Cada caso nuevo añadido, cada rúbrica afinada, cada fallo capturado la convierte en un retrato más fiel de cómo es lo bueno para ese cliente. Cuando llega un modelo nuevo, la capa de evaluación es lo que le dice al cliente si debe cambiar. Cuando un sistema se porta mal, es lo que revela el problema. Cuando el cliente quiere ampliar el uso de la IA, es lo que le dice si la ampliación funciona.

Esto también cambia la naturaleza de tu relación. A un consultor que construye sistemas se le valora por la construcción. A un consultor que mantiene la capa de evaluación se le valora de forma continua, porque es el juez de calidad de confianza del cliente. Es una base muy natural para un acuerdo continuo, y difícil de sustituir, porque la capa de evaluación encarna años de comprensión acumulada de lo que necesita el cliente.

Generar respuestas sale cada vez más barato. Saber de qué respuestas fiarse, no.

Construir la capa de evaluación empieza en pequeño, en cada encargo. Escribe el conjunto de evaluación antes de construir. Acuerda la rúbrica con el cliente. Captura cada fallo real como un caso de prueba nuevo. Guarda los casos, las rúbricas y los resultados en un repositorio versionado que sea propiedad del cliente. Ejecútalos con regularidad. Al cabo de unos cuantos encargos con el mismo cliente, esto se convierte en un activo considerable, y tú eres quien mejor lo conoce.

Es además una habilidad que merece la pena desarrollar por sí misma. Diseñar buenas evaluaciones, elegir casos representativos, escribir rúbricas que capten lo que importa, detectar cuándo una puntuación engaña: es una pericia cada vez más demandada. Los consultores que se hagan conocidos por ella descubrirán que los clientes acuden a ellos no solo para construir sistemas sino para juzgarlos, incluidos los sistemas construidos por otros.

Esta semana, para un cliente o para un sistema propio, reúne en un solo sitio todos los casos de evaluación, rúbricas y registros de calidad que tengas. Anota los huecos: tipos de trabajo sin pruebas, fallos que nunca se capturaron como casos. Rellena uno. Estás construyendo el activo que más importará a medida que todo lo demás se vuelva más fácil de producir.

Las actualizaciones son I+D gratis

Cada lanzamiento de un modelo puede mejorar todo lo que ya has entregado, si has construido pensando en ello. Un sistema bien diseñado, con instrucciones claras, contexto limpio, salidas estructuradas, scripts empaquetados y un buen conjunto de evaluación, normalmente puede aprovechar un modelo más capaz con poco o ningún retrabajo. Ejecuta el conjunto de evaluación con el modelo nuevo, revisa los resultados, ajusta donde haga falta y cambia. La ganancia de capacidad aterriza en el sistema del cliente, y tú no has tenido que financiar la investigación que la produjo.

Es una posición extraordinaria. La mayoría de las empresas tienen que invertir para mejorar sus productos. Aquí, una parte sustancial de la mejora llega de fuera, con regularidad, a medida que los proveedores de modelos lanzan modelos mejores. Tu trabajo es asegurarte de que tus sistemas pueden recibir esas mejoras sin sobresaltos, y ser la persona que le cuenta al cliente qué ha cambiado y por qué importa. Es una parte natural de una iguala, y una razón de peso para que el cliente la mantenga.

Construir pensando en las actualizaciones significa evitar el acoplamiento estrecho a las manías de un modelo concreto. Las instrucciones que dependen de un apaño para una debilidad específica pueden volverse innecesarias, o incluso contraproducentes, cuando se corrige la debilidad. Los prompts claros, bien estructurados y basados en principios generales suelen transferirse bien. Guarda la elección de modelos en la configuración y no desperdigada por el código. Documenta los apaños, para saber cuáles revisar cuando llegue un modelo nuevo.

El conjunto de evaluación es lo que hace seguras las actualizaciones. Sin él, cambiar de modelo es una apuesta: el modelo nuevo podría ser mejor en general pero peor en algún caso concreto que le importa al cliente. Con él, puedes ver exactamente cómo rinde el modelo nuevo con el trabajo real del cliente antes de cambiar. A veces la mejora es espectacular. A veces es modesta. De vez en cuando, en una tarea concreta, el modelo actual sigue siendo la mejor opción. La evaluación te dice cuál.

Construye de forma que el progreso que no pagaste llegue igualmente a la puerta de tu cliente.

Las actualizaciones son también una oportunidad para revisar lo que es posible. Una tarea que era demasiado difícil para el modelo anterior puede estar ahora a su alcance. Un punto de control humano que era necesario puede relajarse ahora con seguridad para algunos tipos de acción, si las pruebas lo respaldan. Un flujo que necesitaba varios pasos puede hacerse ahora en uno. Cada una de estas cosas es una posible mejora que proponer al cliente, y muchas son microencargos naturales por derecho propio.

Ten cuidado de no prometer mejoras futuras que no puedes garantizar. El progreso de los modelos ha sido rápido, pero su rumbo exacto es impredecible, y no todos los lanzamientos mejoran todas las tareas. Diles a los clientes que sus sistemas están diseñados para beneficiarse de las mejoras y que evaluarás cada lanzamiento importante, en lugar de prometer ganancias concretas en fechas concretas.

Esta semana, revisa el acoplamiento al modelo de uno de tus sistemas. ¿Está la elección de modelos en la configuración? ¿Están documentados los apaños? ¿Hay un conjunto de evaluación listo para ejecutarse con un modelo nuevo? Arregla lo que falte. El próximo lanzamiento importante será entonces una oportunidad y no un trastorno, y serás el primero en contarle a tu cliente lo que significa para él.

Proyectos paralelos que se acumulan

Cada construcción debería reutilizar los componentes de la anterior. Un consultor que empieza cada encargo desde una página en blanco trabaja duro para siempre. Un consultor que construye deliberadamente sobre el trabajo anterior descubre que cada encargo es más rápido que el anterior, porque una parte mayor ya está hecha. Dos años así producen una biblioteca de componentes, skills, plantillas y herramientas que nadie puede alcanzar en un trimestre, y es el motor silencioso de toda práctica eficiente.

Acumular requiere intención. Mientras trabajas, fíjate en qué es general y qué es específico. La estructura de un informe de auditoría es general; las conclusiones del cliente son específicas. Un script que limpia un formato de exportación común es general; los datos del cliente son específicos. Una skill para redactar casos de éxito es general; el caso de éxito es específico. Extrae las partes generales a tu propia biblioteca, límpialas, documéntalas y úsalas la próxima vez. Deja las partes específicas con el cliente.

Los proyectos paralelos aceleran esto. En las semanas más tranquilas, o unas horas cada semana, construye cosas para ti que hagan más rápidos los encargos futuros: una plantilla de prototipo mejor, una nueva herramienta gratuita para tu nicho, una skill que automatice una parte de la entrega que te resulta tediosa, un conjunto de datos sintéticos para tu sector. Cada proyecto paralelo debería reutilizar los anteriores, para que la biblioteca crezca con coherencia y no como un montón de experimentos inconexos.

Claude hace que los proyectos paralelos sean lo bastante baratos como para que merezcan la pena. Un componente que antes habría llevado una semana a menudo puede construirse en una tarde. La limitación no es construir, sino la disciplina de construir cosas que se acumulen, en lugar de cosas que simplemente resultan interesantes. Antes de cada proyecto paralelo, pregúntate: ¿hará esto mi próximo encargo más rápido o mejor? ¿Reutilizará algo que ya tengo? ¿Lo reutilizará algo en el futuro? Si las respuestas son sí, constrúyelo.

La primera construcción es trabajo. La décima, encima de las nueve primeras, es palanca.

Organiza la biblioteca para poder encontrar las cosas. Versiónala, como recomendaba el capítulo sobre el canon. Ponles nombres claros a las cosas. Mantén un índice breve de lo que existe y para qué sirve cada pieza. Una biblioteca en la que no puedes buscar es una biblioteca que no usarás, y los componentes que no encuentras acaban reconstruyéndose desde cero, lo que echa por tierra la idea.

La acumulación también es visible para los clientes. Un consultor cuyos prototipos están pulidos desde el primer día, cuyas skills ya entienden el sector, cuyas plantillas ya encajan con el encargo, entrega más en dos semanas de lo que un recién llegado podría en dos meses. Puede que los clientes no sepan por qué, pero notan el resultado, y se lo cuentan a otros. Esa reputación se acumula junto con la biblioteca.

Esta semana, mira tus tres últimos encargos y enumera los componentes que construiste para cada uno. Marca cuáles eran generales y podrían reutilizarse. Extrae uno, límpialo y añádelo a tu biblioteca con una nota breve. Luego planifica para el próximo mes un proyecto paralelo que construya sobre algo que ya tienes. Las pequeñas aportaciones constantes son la forma en que una biblioteca se convierte en una ventaja.

El foso de la biblioteca de skills

Cualquiera puede comprar el modelo. Nadie más tiene tus cuarenta flujos de trabajo codificados, ajustados con trabajo real de clientes. Esa biblioteca de skills, refinada a lo largo de muchos encargos en un nicho concreto, es lo único verdaderamente defendible que posee un microconsultor. Los modelos están al alcance de todos. Las técnicas se publican libremente. El conocimiento general está a una búsqueda de distancia. Lo escaso es la capacidad acumulada, probada y específica que surge de hacer el mismo tipo de trabajo muchas veces y codificar lo aprendido.

Piensa en lo que contiene una biblioteca de skills madura. Skills para cada tipo de encargo que haces: la auditoría, el arreglo de flujo de trabajo, el sprint de documentación, el kit de prompts, el piloto. Referencias sectoriales con la jerga, la normativa y los escollos habituales de tu nicho. Plantillas para propuestas, manuales de operaciones, casos de éxito e informes. Skills de verificación con rúbricas ajustadas a lo que valoran tus clientes. Scripts para el trabajo mecánico que tu sector necesita una y otra vez. Cada elemento es útil por sí solo. Juntos, te permiten entregar un trabajo con una calidad y una velocidad que un recién llegado, incluso con los mismos modelos, no puede igualar.

El foso no es el secreto. Como sostenían capítulos anteriores, debes entregar a los clientes las skills construidas a partir de su contexto, y puedes publicar buena parte de tu método. El foso es la acumulación. Un competidor podría leer tu manual y copiar tu enfoque, pero no puede adquirir de golpe años de ajuste con casos reales, los cientos de pequeñas mejoras provocadas por fallos reales, las referencias sectoriales refinadas con decenas de clientes. Eso lleva tiempo, y el tiempo es lo único que un competidor no puede comprar.

Protege la biblioteca manteniéndola. Una biblioteca de skills que no se mantiene al día pierde valor a medida que cambian los modelos, las herramientas y los sectores. Versiónala, pruébala con cada modelo nuevo, poda lo que ya no funciona y añádele algo después de cada encargo. La biblioteca es un activo vivo y, como cualquier activo, necesita cuidados. Una biblioteca descuidada se convierte en un pasivo: un conjunto de instrucciones desfasadas que producen resultados sutilmente erróneos.

El modelo es el motor que cualquiera puede comprar. Tus skills son el coche que solo tú sabes construir.

La biblioteca también cambia la economía de tu práctica. Con una biblioteca sólida, un consultor que trabaja solo puede entregar a una escala que antes requería un equipo, porque buena parte de la pericia está codificada en lugar de ir en la cabeza de las personas. Facilita la colaboración: un socio o un asociado puede entregar con tu nivel usando tu biblioteca. Y abre nuevas posibilidades: licenciar partes de la biblioteca, ofrecerla como producto o usarla como base de sistemas que sirven a muchos clientes a la vez.

Empieza a construir deliberadamente ya, si no lo has hecho. Cada encargo debería dejar tu biblioteca un poco mejor de como la encontró: una skill refinada, una nota sectorial nueva, un caso de prueba añadido, una plantilla mejorada. En un año, esas pequeñas aportaciones se vuelven sustanciales. En varios, se convierten en el foso.

Esta semana, haz inventario de tu biblioteca de skills. Enumera lo que tienes, anota lo que falta para tus tipos de encargo principales e identifica la única incorporación que más cambiaría tu próximo encargo. Constrúyela, pruébala, versiónala. Así se cava un foso: una palada cada vez, con constancia, durante años.

Flota antes que buque insignia

Diez encargos pequeños que ingresan con regularidad ganan a una apuesta heroica. La tentación en cualquier práctica de consultoría es perseguir el buque insignia: el gran programa de transformación, el cliente corporativo, el contrato que financiaría un año de un plumazo. A veces merece la pena perseguirlos. Pero una práctica construida sobre una flota de encargos pequeños es más resistente, aprende más deprisa, genera más pruebas y, con el tiempo, a menudo gana más que una construida sobre unos pocos grandes.

La resistencia es la primera ventaja. Una práctica con un solo gran cliente está a una decisión presupuestaria de la crisis. Una práctica con una docena de clientes pequeños, en distintos peldaños de la escalera de ofertas, puede perder uno sin daños graves. La flota reparte el riesgo entre muchas relaciones, sectores y tipos de encargo. También te da opciones: si un tipo de encargo deja de venderse, los demás continúan, y tienes tiempo para ajustarte.

El aprendizaje es la segunda. Cada encargo pequeño es un ciclo completo: diagnóstico, acotación, entrega, medición, traspaso. Diez encargos pequeños al año te dan diez ciclos completos de los que aprender. Un encargo grande te da uno, y dura tanto que las lecciones llegan demasiado tarde para aplicarlas. Los ciclos cortos significan respuestas rápidas, y las respuestas rápidas mejoran tu método, tu biblioteca y tu criterio mucho más deprisa que cualquier cantidad de lectura.

Las pruebas son la tercera. Cada encargo pequeño produce un caso de éxito, una referencia, un resultado medido. Una flota de encargos pequeños produce una biblioteca de pruebas en muchos sectores y problemas, lo que facilita la siguiente venta. Un encargo grande produce un caso de éxito, a menudo confidencial, a menudo demasiado específico para resultar útil a la mayoría de los posibles clientes. El trabajo pequeño es un marketing sorprendentemente bueno.

Una flota no necesita que ningún barco sea extraordinario. Necesita que todos sigan navegando.

La idea de la flota se aplica a los productos además de a los clientes. Una práctica puede mantener un conjunto de pequeñas herramientas gratuitas, cada una al servicio de una necesidad ligeramente distinta del nicho, cada una trayendo un flujo de posibles clientes. Puede mantener una cartera de pequeñas ofertas convertidas en producto, cada una refinada a lo largo de muchas entregas. El principio es el mismo: muchos activos modestos, cada uno aportando, ninguno crítico por sí solo.

Tiene un coste de gestión. Una flota requiere sistemas: plantillas de encargo estándar, una biblioteca de skills, procesos de entrega coherentes, fichas de clientes organizadas. Sin ellos, una docena de encargos pequeños se convierte en una docena de fuentes de caos. Con ellos, cada encargo va sobre raíles, y la flota es manejable incluso para alguien que trabaja solo. Por eso importan tanto las partes anteriores de este libro. Son los sistemas que hacen posible una flota.

Nada de esto descarta el trabajo grande. Un encargo grande que surge de forma natural de una serie de encargos pequeños con éxito, con un cliente al que conoces bien, es una propuesta muy distinta de un encargo grande perseguido en frío. Deja que los buques insignia surjan de la flota, en lugar de jugarte la práctica a encontrar uno.

Esta semana, traza el mapa de tu práctica actual como una flota: cuántos clientes, en qué peldaño de la escalera, en qué sectores. Anota dónde estás demasiado concentrado. Elige un paso que reparta el riesgo: una oferta pequeña nueva, un sector nuevo, una herramienta gratuita nueva. Una flota se construye con una embarcación modesta cada vez.

La práctica de dos personas

La entrega agéntica significa que la plantilla deja de seguir a la capacidad. Dos personas con una biblioteca de skills sólida, buenos sistemas y las costumbres de este libro pueden atender hoy a una cartera de clientes que antes requería un equipo mucho mayor. No es una predicción sobre un futuro lejano. Ya se ve en prácticas que se han reorganizado en torno a estas herramientas, y cambia lo que puede ser un pequeño negocio de consultoría.

Piensa en cómo se reparte el trabajo. Buena parte de lo que antes ocupaba al personal júnior, investigar, sintetizar, redactar, construir prototipos, escribir documentación, ejecutar pruebas, producir informes, puede hacerlo ahora Claude, dirigido por un profesional con experiencia. Lo que queda para los humanos es la parte que requiere criterio y relaciones: diagnosticar problemas, diseñar soluciones, revisar salidas, tomar decisiones, generar confianza con los clientes. Dos personas que hacen bien esas cosas, con agentes haciendo el resto, tienen un alcance notable.

Las habilidades de una práctica así son distintas de las de una agencia tradicional. En lugar de gestionar personas, los socios gestionan sistemas: bibliotecas de skills, plantillas de entrega, capas de evaluación, monitorización e informes. En lugar de formar a júniors, codifican su criterio en skills y lo refinan continuamente. En lugar de contratar cuando crece la demanda, mejoran sus sistemas y convierten sus ofertas en producto. El crecimiento viene de la palanca y no de la plantilla.

Dos es un número útil, aunque no mágico. Alguien que trabaja solo puede hacer buena parte de esto, pero no tiene a nadie que le cubra en vacaciones, que revise su trabajo o que comparta la carga de vender y entregar. Una pareja puede repartirse los papeles, quizá uno más centrado en los clientes y otro en los sistemas, y cada uno puede sustituir al otro. Pueden revisarse mutuamente el trabajo, lo que importa muchísimo en un negocio construido sobre la confianza. Y dos personas todavía pueden tomar decisiones con un café delante, sin la sobrecarga que necesitan las organizaciones más grandes.

Antes la palanca venía de las personas. Ahora viene de sistemas que las personas diseñan y juzgan.

Hay riesgos honestos. Una práctica pequeña con un gran alcance conlleva una responsabilidad real: muchos clientes dependen de sistemas construidos y mantenidos por muy pocas personas. Eso exige disciplina: evaluación rigurosa, buena monitorización, manuales de operaciones claros, referentes formados en cada cliente y previsiones para lo que ocurra si uno de los socios no está disponible. Pequeño no es excusa para frágil. Si acaso, exige más cuidado, porque hay menos margen.

También existe la tentación de estirarse demasiado, aceptando más clientes de los que los sistemas pueden sostener de verdad, porque las herramientas hacen que parezca posible. Vigila de cerca la calidad. La capa de evaluación y los informes mensuales son tu alerta temprana. Si la calidad empieza a resentirse, frena, refuerza los sistemas y solo entonces acepta más.

Esta semana, imagina tu práctica con el doble de clientes que ahora y sin nuevas contrataciones. ¿Qué tendría que ser cierto? ¿Qué sistemas tendrían que existir, qué skills tendrían que estar codificadas, qué procesos tendrían que estar estandarizados? Escribe la lista. Luego elige el primer elemento y empieza a construirlo. La capacidad ya no es algo que se contrata. Es algo que se diseña.

Enséñale a sustituirte

Codifica en una skill cada juicio repetible que hagas, de forma deliberada y continua. El objetivo no es asegurarte el puesto. Es tener capacidad que puedas vender dos veces. Cada tarea que haces a mano y que podría codificarse es una tarea que limita cuánto puedes entregar. Cada tarea que codificas libera tu atención para el trabajo que solo tú puedes hacer, y permite que la versión codificada atienda a más clientes de los que tú podrías atender jamás en persona.

A muchos consultores esto les suena alarmante. Si codifico lo que sé, ¿qué me queda? La respuesta, que el último capítulo deja clara, es el criterio que está por encima de cualquier tarea concreta: decidir qué construir, para quién, por qué y si está funcionando. Ese criterio no mengua por codificar las tareas que tiene debajo. Queda libre para operar a mayor escala. Un consultor que ha codificado su método de auditoría puede hacer más auditorías, pero, sobre todo, puede dedicar su tiempo a las decisiones difíciles que el método de auditoría saca a la luz.

Empieza por fijarte en tus juicios repetidos. Cuando revisas una oportunidad de auditoría y decides si merece la pena perseguirla, ¿en qué te fijas? Cuando acotas un sprint y decides qué incluir, ¿qué reglas aplicas? Cuando revisas un borrador y decides que es lo bastante bueno, ¿qué criterios usas? Cada uno de estos es un juicio que haces una y otra vez. Pon por escrito cómo lo haces, prueba la versión escrita con casos reales y conviértela en una skill o en una rúbrica.

La versión codificada será imperfecta al principio. No pasa nada. Úsala junto a tu propio criterio, compara los resultados y refínala donde difieran. Con el tiempo, manejará bien los casos rutinarios y te dejará a ti los inusuales. Ese reparto, los casos rutinarios para el sistema y los inusuales para ti, es exactamente el correcto. Y es también exactamente el patrón que diseñas para los clientes, aplicado a tu propia práctica.

Si eres el único que sabe hacerlo, tú eres el techo. Codifícalo y el techo se mueve.

Aquí hay una prueba de honradez. Si descubres que no puedes codificar un juicio, porque no sabes explicar cómo lo haces, merece la pena saberlo. A veces significa que el juicio es genuinamente tácito y requiere una experiencia que no se puede poner por escrito con facilidad. A veces significa que eres menos coherente de lo que creías. En cualquier caso, el intento de codificarlo te enseña algo sobre tu propia pericia.

Enseñarle a sustituirte también prepara tu práctica para crecer. Un socio o un asociado puede trabajar con tu nivel usando tus juicios codificados. Los clientes pueden recibir skills que aplican tu método a su trabajo sin que tú estés presente. Tu práctica depende menos de tu tiempo personal y más de los sistemas que has construido, que es la única forma en que una práctica pequeña puede crecer sin limitarse a trabajar más horas.

Esta semana, elige un juicio que hagas repetidamente en tu trabajo. Pon por escrito, con la mayor precisión posible, cómo lo haces. Conviértelo en una skill o en una rúbrica, pruébalo con cinco casos reales y compara sus resultados con los tuyos. Refínalo. Luego elige el siguiente. Cada juicio codificado es un poco más de capacidad que puedes volver a vender.

El criterio es el último oficio

He aquí todo el libro en una frase: vende pequeño, entrega rápido, demuéstralo y deja que cada sí se gane el siguiente, mientras te guardas el criterio para ti. Todo lo demás, las cien jugadas, las ofertas y los sprints y las skills y los conjuntos de evaluación, es maquinaria para hacer eso bien. A los encargos pequeños es fácil decirles que sí. Claude hace que sean rápidos de entregar. La medición convierte cada uno en una prueba. La prueba se convierte en el siguiente encargo. Y a lo largo de todo ello, lo que el cliente paga en realidad es tu criterio sobre qué merece la pena hacer.

Pequeño, porque lo más difícil de la consultoría es el sí, y un encargo pequeño, cerrado y concreto es el sí más fácil que puede dar un comprador. La auditoría de pago, el sprint de dos semanas, el kit de prompts, el sprint de documentación, el piloto de agentes, la sesión de formación: cada uno está acotado, tiene nombre y deja claro lo que entrega. Un cliente que le dice que sí a uno ha asumido un riesgo pequeño y, si haces tu trabajo, ha recibido un retorno claro. Es el comienzo de una relación y no el final de una negociación.

Rápido, porque las herramientas ya lo permiten. Claude lee, redacta, construye, prueba y verifica a una velocidad que desploma el esfuerzo que hay detrás de muchísimo trabajo útil. El oficio del prompt, el contexto bien seleccionado, Claude Code en el repositorio, las skills y los subagentes, los prototipos y los artefactos: así es como un solo profesional entrega en dos semanas lo que antes le llevaba dos meses a un equipo. Ponle precio al resultado, no a las horas, y esa velocidad es tuya.

Demostrado, porque los logros sin medir se olvidan. Puntos de partida, conjuntos de evaluación, cifras de cierre, informes mensuales, casos de éxito: todo ello convierte el buen trabajo en pruebas que el cliente puede ver, compartir y usar para actuar. Las pruebas se ganan la renovación, la recomendación y el siguiente peldaño de la escalera. Una práctica que demuestra su valor de forma continua nunca tiene que defenderlo.

Todo lo que está por debajo del gusto acaba automatizándose. Sigue automatizando tu propio trabajo hasta que lo único que quede sea decidir qué merece la pena construir.

Y el criterio, porque esa es la parte que no se delega. ¿Cuál es el problema real detrás del que se presenta? ¿Cuál de las oportunidades de la auditoría merece la pena perseguir primero? ¿Qué significa «terminado» para este cliente? ¿Cuándo engaña una puntuación de evaluación alta? ¿Qué acción no debería automatizarse nunca? ¿Debería construirse esto siquiera? Claude puede informar cada una de esas decisiones, a menudo de forma brillante, y deberías pedírselo. No puede hacerlas suyas, porque hacerlas suyas significa responder ante el cliente de las consecuencias, y esa responsabilidad lleva tu nombre.

Así que sigue automatizando tu propio trabajo, tarea a tarea, deliberadamente, hasta que lo que quede sea el criterio. No es un papel menor. Es el más valioso del negocio, y es el que los clientes siempre han estado pagando, incluso cuando estaba enterrado bajo horas de investigación y redacción que ya no hace falta hacer a mano. Empieza esta semana con el encargo más pequeño que puedas vender, entrégalo rápido, mídelo con honradez y pide el siguiente. Luego vuelve a hacerlo. Ese es el manual. En realidad nunca fue sobre la IA. Fue sobre hacer fácil decir que sí, y luego asegurarse de que el sí mereciera la pena.