# Por qué frustran las herramientas de IA: un mapa práctico de aprendizaje > Una metáfora del autor de cuatro etapas de aprendizaje, señales prácticas del flujo y un experimento de tres pilares para avanzar en un proyecto asistido por IA. Source: https://ailoot.ai/blog/es/why-you-quit-ai-tools/ Canonical: https://ailoot.ai/blog/es/why-you-quit-ai-tools/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-198 Revision: sha256-7724674294c27145d987a27f2059bfd99c28c0ee8f035c712a07ef8e65c8fea8
Punto clave Este artículo usa una curva popular de aprendizaje de cuatro etapas como metáfora del autor para trabajar con Claude Code o Cursor. El entusiasmo inicial puede dar paso a frustración y después a práctica deliberada y un flujo más estable. Son etiquetas para reflexionar, no una secuencia validada universal, una predicción de abandono ni un diagnóstico. Las listas y el marco de tres pilares son sugerencias prácticas para probar en un proyecto.
Encontrarás más instrucciones para trabajar con Ailoot en la [documentación](https://ailoot.ai/docs/). ## Una metáfora de aprendizaje, no una ley psicológica universal
Punto clave El efecto Dunning-Kruger trata de límites al juzgar el propio rendimiento. El dibujo de cima, valle, pendiente y meseta es una ilustración popular, no una prueba de que todo estudiante deba atravesar cuatro etapas en orden. Aquí solo organiza ejemplos de expectativas, frustración y práctica.
La pregunta práctica de este artículo es más acotada que un diagnóstico psicológico: ¿coinciden tus expectativas con resultados verificables? Compara lo que esperabas terminar con lo que realmente funciona y ajusta la tarea siguiente según esas pruebas. No uses solo la confianza como medida de habilidad; inspecciona un resultado real y las comprobaciones que lo respaldan. Desde entonces, la curva de Dunning-Kruger se ha convertido en una popular ilustración de cuatro etapas. Primero, la confianza se dispara hasta la «cima del monte Estúpido». Luego se desploma en el «Valle de la Desesperación». Después sube lentamente por la «Pendiente de la Iluminación» hacia la «Meseta de la Sostenibilidad». La curva es una metáfora del artículo. Ningún estudio de sus lectores acredita una tasa de abandono, un plazo fijo de aprendizaje ni un recorrido universal por esas etiquetas. ## Las 4 etapas del vibe coding: ¿en cuál estás?
Punto clave Las cuatro etiquetas siguientes describen situaciones que un aprendiz puede reconocer, no etapas obligatorias para todo usuario de Claude Code. La cima del monte Estúpido: lees un artículo sobre agentes y crees que ya haces vibe coding. El Valle de la Desesperación: empiezas a investigar MCP y Skills y te das cuenta de que no entendías nada. La Pendiente de la Iluminación: las reglas funcionan y la metodología da resultados. La Meseta de la Sostenibilidad: tus conocimientos están a la altura de tu confianza y construyes productos con constancia. Cada etapa tiene sus propios pensamientos y comportamientos.
Cada etapa se reconoce por pensamientos y comportamientos típicos. Aquí tienes el mapa. ### Etapa 1: la cima del monte Estúpido Lees un artículo sobre Claude Code. Quizá has visto un vídeo. Todo parece claro: instalar la herramienta, escribir un prompt y obtener código. Los autores cuentan que «crearon un SaaS en una tarde». Tú también quieres hacerlo en una tarde. Lo que piensas: - «Creo que ya lo entiendo». - «Es solo un chat, pero más inteligente». - «Soy emprendedor; no necesito programadores». - «Lo dominaré en un mes y me iré a Dubái». Lo que haces: - Descargas Claude Code y lo instalas. - Escribes «Build me a booking app» en el chat. - Obtienes código que no funciona. - Piensas que el modelo es el equivocado y compras una suscripción Max. En esta etapa, sobrevaloras tanto la herramienta como tus propias capacidades. Es un punto de partida posible. Si las expectativas no se conectan con un resultado funcional, puede crecer la frustración; un proyecto pequeño y comprobaciones explícitas dan algo concreto de lo que aprender. Para comprobarte en la práctica, pide a otra persona que inspeccione la misma salida con criterios explícitos. Describirse con confianza como «experto en IA» no demuestra la calidad de un resultado generado. Trata una impresión inicial segura como hipótesis. Ejecuta el código, inspecciona la salida y deja que el resultado cambie tu estimación de lo que puedes hacer. ### Etapa 2: el Valle de la Desesperación Profundizas más. Lees sobre MCP e intentas conectar un servidor. Descargas un Skill ya preparado y tratas de entenderlo. Inicias Plan Mode: el agente redacta un plan, pero se desvía en el tercer paso. Abres `~/.claude/`: hay 12 carpetas y no entiendes para qué sirve ninguna. Lo que piensas: - «No sé hacer absolutamente nada». - «Toda esa gente en las redes sociales solo miente». - «Lo que funciona para los demás no funciona para mí». - «Quizá me estoy metiendo en esto demasiado pronto». - «Me he gastado $200 en tokens, ¿y qué tengo que enseñar?». Lo que haces: - Abres 20 pestañas de documentación a la vez. - Todos los chats empiezan con «olvida el contexto anterior». - Navegas por foros y lees hilos como «X me rompió el proyecto». - Comparas Claude con Cursor, Cursor con Codex y Codex con Cline. Crees que tienes la herramienta equivocada. - Te sientas a programar por la mañana, pero a la hora de comer ya estás desplazándote por tu feed. Puede ser una situación frustrante. El artículo no tiene una tasa medida de abandono; usa las señales siguientes para identificar un cambio que merezca probarse. ### Etapa 3: la Pendiente de la Iluminación Paras. Bajas el ritmo. Dejas de ir detrás de cada novedad. Escribes tu primer CLAUDE.md y lo pones en el proyecto. Creas una carpeta `business/` y añades una descripción del producto, los precios y el público. Pasas por `/compact` diez veces y por fin entiendes qué partes del contexto debe conservar. Creas tu primer Skill: uno para una tarea concreta, de 30 líneas. Lo que piensas: - «Ah, así es como funciona». - «Hoy he conseguido hacer algo que hace una semana no podía». - «Creo que entiendo en qué se diferencian `business/` y `ai-clone/`». - «Ya tengo un prompt preparado para la tarea X». Lo que haces: - Vuelves a Plan Mode antes de cada tarea nueva. - Antes de escribirle nada a Claude, te preguntas: «¿Está esto en mi CLAUDE.md?». - Buscas la siguiente regla metodológica; una herramienta nueva ya no te llama la atención. - Ayudas a otros en los chats: «Yo también me atasqué con esto; prueba de esta manera». ### Etapa 4: la Meseta de la Sostenibilidad Este no es el momento en que todo se vuelve fácil. Es el momento en que tus conocimientos por fin están a la altura de tu confianza. Lo que piensas: - «Sé lo que no sé». - «Esta tarea me llevará tres horas; ya la he hecho antes». - «Esto necesita un Skill nuevo; voy a prepararlo ahora». - «Si Claude se desvía del plan, conozco tres posibles motivos». Lo que haces: - Construyes productos con constancia: uno en una tarde, otro durante un fin de semana. - Tienes tu propia carpeta de Skills, tus propios subagentes y tu propio `business/` para cada proyecto. - Contratas a profesionales de forma selectiva para las partes que fundamentalmente no puedes manejar tú. - Rara vez recurres a los videotutoriales de otras personas; sobre todo buscas ideas nuevas, no aprender lo básico. Lista de autoevaluación: ¿en qué etapa estás ahora? - Si aún no has probado Claude Code y piensas «Ah, puedo hacerlo en una tarde», estás en la etapa 1. - Si lo has probado, has abierto MCP, has intentado leer Skills y piensas «¿Por qué me metí en esto?», estás en la etapa 2. - Si has creado un CLAUDE.md y puedes ver cómo cambia realmente el comportamiento de Claude, estás en la etapa 3. - Si construyes productos con constancia y sabes exactamente qué herramienta usar y cuándo, estás en la etapa 4. ## 7 señales de que estás ahora mismo en el Valle de la Desesperación
Punto clave El Valle de la Desesperación se reconoce por siete señales de comportamiento, desde cambiar de herramienta sin parar hasta decir «esto simplemente no es para mí». Usa las siete señales para reflexionar, no como diagnóstico por puntuación. Elige la que más claramente dificulte terminar tu tarea actual y prueba el cambio correspondiente.
El valle no llega de repente. Se va instalando poco a poco. Estas son las señales: **1. Comparas herramientas en vez de construir.** Abres una pestaña «Cursor vs Claude Code». Terminas de leer. Abres «Cline vs Cursor». Después, «Codex vs todo lo demás». Con cada comparación piensas: «Quizá estoy profundizando en lo que no toca». Al final del día, no has escrito ni una línea de código y has perdido cuatro horas. **2. Empiezas cada chat nuevo con «olvida todo lo anterior».** No tienes un CLAUDE.md, no dominas `/compact` y no entiendes qué es una ventana de contexto. Cada sesión empieza desde cero. Una semana después, te darás cuenta de que le has explicado lo mismo a Claude por decimoquinta vez. **3. Coleccionas prompts, pero no los usas.** Has creado en Notion una carpeta llamada «Claude Code Prompts». Tiene 47 marcadores. No has usado ninguno dos veces. Cada vez piensas: «Este sí que es exactamente lo que necesito». **4. Crees que los demás «triunfan porque tienen contactos».** Abres las redes sociales y ves a alguien lanzar la primera versión de un producto durante un fin de semana. Piensas: «Tienen un equipo. Tienen contactos. Yo no puedo hacerlo». No tienes en cuenta que están en la etapa cuatro mientras tú estás en la dos. **5. Abandonas un proyecto el tercer día.** Todo proyecto nuevo empieza con entusiasmo («¡Esto va a ser genial!») y termina al tercer día. Cuando el reto pasa de «un saludo en el chat» a «procesar un pago», lo dejas. Da miedo hacer algo difícil. **6. Buscas respuestas en ChatGPT porque Claude no te ha funcionado.** Claude te dio una mala respuesta, así que abres ChatGPT. ChatGPT te dio una mala respuesta, así que abres Gemini. Nunca se te ocurre que la solicitud estaba mal formulada: siempre piensas que la culpa es de la herramienta. **7. Te dices: «Esto simplemente no es para mí».** Esta es la señal más insidiosa. Suena a frase final defensiva, tras la cual la persona se marcha. Ese pensamiento puede reflejar frustración, no incapacidad de aprender. El «valle» es una metáfora; no hay un porcentaje medido ni un plazo fijo de quién se siente así o qué ocurre después. Si encajan varias señales, elige un resultado pequeño y funcional como próximo objetivo. Registra lo que lo bloqueó y cambia una parte del flujo; la lista no predice cuánto tardará la mejora. ## Por qué la gente abandona en el valle y por qué no es pereza
Punto clave En esta metáfora, el valle nombra una brecha entre el progreso esperado y real. Una tarea que parecía rápida puede exigir configuración y depuración desconocidas; los ejemplos de redes sociales vuelven desalentadora la comparación. Es una descripción práctica de frustración, no un diagnóstico neurológico.
La frustración con una herramienta no mide de forma fiable tu capacidad. Examina tamaño de tarea, conocimientos que faltan y entorno de ejecución antes de tomar una decisión duradera sobre ella. En lugar de deducir un mecanismo cerebral de una semana difícil, registra hechos observables: qué intentaste, qué funcionó, qué error bloqueó el siguiente paso y cuánto tardó. Así tendrás un punto concreto que mejorar. En el valle recibes dos golpes a la vez. Primero, tu propio progreso no cumple tus expectativas. Segundo, las personas a tu alrededor publican resultados que tú no tienes. Abres las redes sociales: alguien ha lanzado la primera versión de un producto, alguien ha creado un agente, alguien ha ganado sus primeros cien dólares con la API de Claude. Tú llevas tres semanas sin poder siquiera conectar una base de datos. Registra el tiempo además de tu impresión de rapidez. Un agente puede parecer productivo y añadir revisión y trabajo repetido; compara una tarea representativa con el flujo anterior sin tratar una sensación como mejora medida. Avanzar despacio en una tarea desconocida no demuestra falta de capacidad. Separa el coste de aprendizaje de la salida de la herramienta y define un resultado menor que puedas inspeccionar. Sin un siguiente paso repetible es fácil cambiar de herramienta o abandonar la tarea. El marco de tres pilares siguiente es una propuesta del autor, no una explicación estadísticamente demostrada del abandono. ## 3 pilares: una metodología para salir del valle
Punto clave Una herramienta o un prompt nuevo no te sacará del Valle de la Desesperación. Lo que te saca es un marco de tres pilares: el clon de IA (Skills y metodología personal), el segundo cerebro (CLAUDE.md y una carpeta `business/`) y la ingeniería de contexto (Plan Mode y gestión de la ventana de contexto). Cada pilar por sí solo aborda un síntoma del valle. Juntos pueden hacer el proceso más fácil de inspeccionar y repetir. No eliminan las alucinaciones ni sustituyen la verificación del resultado.
Según la experiencia del autor que se describe aquí, salir del valle llevó tres meses; durante ese tiempo se probaron decenas de herramientas. Y entendí una cosa: Claude no era el problema. El problema era que cada vez empezaba desde cero. Sin memoria, sin reglas, sin límites. Después monté un marco. Lo llamé «los tres pilares». El nombre se refiere a tres tipos de componentes en los que se basa todo el flujo de trabajo de Claude Code. Si quitas cualquiera de ellos, el marco se viene abajo. ### Pilar 1: un clon de IA de ti Un clon de IA es tu experiencia empaquetada en un formato que Claude aplica automáticamente. En el Valle de la Desesperación, le escribes a Claude «Ayúdame con esta tarea» y explicas tu método desde cero cada vez. El pilar 1 lo resuelve: tus métodos están en la carpeta `ai-clone/`, como un conjunto de archivos. Un Skill para «cómo gestiono un caso de cliente». Un Skill para «cómo escribo una publicación de Telegram». Un subagente llamado «arquitecto de producto» que piensa como tú durante la fase de planificación. Así es el pilar 1 en la práctica: - Skills: archivos con instrucciones para tareas específicas (`/build-article`, `/build-reel-script`). - Subagentes: perfiles con distintas áreas de especialización, entre los que Claude delega subtareas. - La carpeta `ai-clone/feedback/`: reglas aprendidas de los errores. Cada regla sigue el formato Rule - Why - How. Lo he explicado en detalle en la [guía de Skills, Subagents, MCP y Plugins](https://ailoot.ai/blog/es/skills-subagents-mcp-plugins-claude-code/), un mapa para saber qué usar y cuándo. ### Pilar 2: un segundo cerebro Un segundo cerebro es un repositorio estructurado de conocimientos sobre un proyecto al que Claude puede acceder directamente. En el Valle de la Desesperación, le explicas a Claude en cada sesión qué es el producto, quién es el público y cuál es el modelo de negocio. Al final de la tercera semana, te das cuenta de que has explicado lo mismo por decimoquinta vez. El pilar 2 lo resuelve: organizas los conocimientos del proyecto en archivos junto al código. Claude los lee cuando los necesita. Así es el pilar 2 en la práctica: - `CLAUDE.md`: punto de entrada del agente. Reglas de comportamiento, rutas y enlaces a todo lo demás. - La carpeta `business/`: producto, público, economía, objetivos, planes de contenido y competidores. - La carpeta `plans/`: planes técnicos por fase, con el estado de cada uno. - La carpeta `retrospectives/`: lecciones de sesiones anteriores para evitar repetir los mismos errores. Para ver el desglose completo, consulta la [guía para configurar CLAUDE.md](https://ailoot.ai/blog/es/claude-md-template/) y la [guía sobre un segundo cerebro en Claude Code](https://ailoot.ai/blog/es/claude-code-second-brain/). ### Pilar 3: ingeniería de contexto La ingeniería de contexto consiste en gestionar lo que entra en la ventana de contexto de Claude antes de pulsar Enter. En el Valle de la Desesperación, no entiendes por qué Claude «olvida» las instrucciones después de cuarenta mensajes en un chat. No entiendes por qué hace falta `/compact`. No abres Plan Mode porque «sin eso es más rápido». El pilar 3 lo resuelve: diriges deliberadamente lo que cargas en el contexto. Esto aporta entrada más pertinente; todavía debes verificar sus afirmaciones y resultados. Así es el pilar 3 en la práctica: - Plan Mode: el agente redacta primero un plan para la tarea, tú lo apruebas y después lo ejecuta. Si no lo usas, el primer intento produce un resultado caótico. - `/compact`: compresión inteligente del historial del chat. Cuando el contexto empieza a llenarse, lo comprimes y conservas solo las decisiones clave. - Prompts estructurados: en vez de «ayúdame», escribe «este es el contexto A, esta es la tarea B, devuelve el resultado en el formato C». - Subagentes: delegar subtareas a contextos nuevos para no sobrecargar el contexto principal. Lo he explicado en la [guía de ingeniería de contexto](https://ailoot.ai/blog/es/context-engineering/) y la [guía de Plan Mode](https://ailoot.ai/blog/es/claude-code-plan-mode/). ### Por qué tres y no uno Puedes crear solo un segundo cerebro y Claude conocerá tu proyecto. Pero actuará como un becario sin reglas. Puedes crear solo un clon de IA y Claude asumirá tu experiencia. Pero sin memoria del proyecto, cada sesión empezará desde cero. La ingeniería de contexto puede mejorar la entrada de una tarea, pero no garantiza ejecución sin problemas ni conserva conocimiento por sí sola. Pero los conocimientos no se acumularán entre tareas. Solo al juntar los tres obtienes lo que yo llamo un «marco predecible». Claude recuerda tu proyecto. Aplica automáticamente tu metodología. Y no pierde el hilo durante una tarea. Ese es el momento en que sales del Valle de la Desesperación. ## 7 antipatrones que te mantienen en el valle
Punto clave Los patrones siguientes son ejemplos que usa el autor al reflexionar sobre un flujo frustrante. Trabajan sin un CLAUDE.md, mantienen largas conversaciones sin `/compact`, confían en la primera respuesta e ignoran el seguimiento de costes. Cada antipatron indica que estás probando la herramienta, pero te saltas la metodología. Elige un cambio pertinente y evalúa si ayuda a terminar una tarea real; la lista no tiene una puntuación de aprobado validada.
Antipatrones que conviene comprobar en tu propio flujo: **1. «Escríbeme una aplicación que funcione» sin un CLAUDE.md.** Abres un chat nuevo de Claude Code y le dictas la tarea de inmediato. Claude no tiene contexto sobre tu proyecto, tu metodología ni tus preferencias. Te da una plantilla genérica y te decepciona. Qué hacer: crea un CLAUDE.md y añade lo mínimo: tu stack, el modelo de negocio, el público objetivo y enlaces a los demás archivos. Todos los chats empiezan con este contexto. **2. Una conversación larga sin `/compact`.** Mantienes una sesión de 80 mensajes. Claude ya no recuerda lo que decidiste en el mensaje 12. La ventana de contexto está llena de historial que no contiene decisiones clave, solo indecisión. La calidad de las respuestas baja. Qué hacer: ejecuta `/compact` cada 30-40 mensajes e indica qué es importante conservar. El contexto queda más enfocado. **3. Confiar en la primera respuesta.** Claude te da una solución y la aplicas de inmediato. Una hora después descubres que ha roto otros tres archivos. Lo dejas porque «otra vez no está funcionando bien». Qué hacer: usa Plan Mode para tareas complejas. Primero el plan, luego lo comentas y después lo ejecutas. Así detectas los errores durante la planificación, no después de media jornada de trabajo. **4. Un prompt chapucero y sin estructura.** Escribes «hazlo bien», esperando que Claude lo entienda por su cuenta. No lo entiende. No sabe qué significa «bien» para ti. Lo adivina. Qué hacer: escribe prompts con la estructura «contexto - tarea - restricciones - formato». Así aumentan mucho las probabilidades de obtener un buen resultado al primer intento. **5. Ignorar el seguimiento de costes.** No sabes cuántos tokens estás gastando. Se agota tu plan mensual, abres el panel y ves que has consumido $200. Te sorprendes. Lo dejas. Qué hacer: configura herramientas de seguimiento del consumo de tokens. He analizado las herramientas en la guía de seguimiento de tokens. Cuando ves el gasto en tiempo real, dejas de quemar tokens sin sentido. **6. Buscar sin fin la «herramienta adecuada».** Sale Cursor y te cambias a Cursor. Aparece Cline y pruebas Cline. Codex se actualiza y vuelves a Codex. Cada dos semanas usas una herramienta nueva y empiezas de cero cada vez. Nunca alcanzas el nivel en que la herramienta empieza a trabajar a tu favor. Qué hacer: elige una herramienta. Úsala durante tres meses. No cambies a la primera excusa. Solo consulto comparativas cuando mi herramienta es fundamentalmente incapaz de hacer algo. **7. «No tengo tiempo para leer la metodología».** Crees que la herramienta debería funcionar sin preparación. Que escribir prompts es una habilidad innata. Que CLAUDE.md es «una capa extra». Como resultado, en tu segundo mes sigues haciendo algo que podrías haber terminado en una semana con una metodología. Qué hacer: acepta que Claude Code requiere aprendizaje, como cualquier herramienta profesional. Se aprende mediante una metodología; aquí la intuición no funciona. Relacionado: la [guía sobre la complacencia en Claude Code](https://ailoot.ai/blog/es/claude-code-sycophancy-prompts/) analiza cómo evitar la mayor idea equivocada del valle: que Claude siempre tiene razón cuando está de acuerdo con tu idea. ## 5 señales de que estás en la Pendiente de la Iluminación: cómo saber que ya has salido
Punto clave La Pendiente de la Iluminación se reconoce por unos pocos cambios tranquilos, no por la euforia. Tienes un CLAUDE.md de más de 200 líneas. Vuelves a Plan Mode sin que nadie te lo recuerde. Te sabes tus Skills de memoria. Tu ritmo de trabajo se ha estabilizado: ahora sabes cuánto tarda una tarea típica. Y los demás empiezan a pedirte ayuda porque estás obteniendo resultados.
Cinco señales de que estás en la etapa tres: **1. Tienes un CLAUDE.md de más de 200 líneas y lo has mantenido deliberadamente.** No lo copiaste de una plantilla: lo fuiste construyendo tú. Conoces cada sección y sabes por qué está ahí. Cuando detectas un patrón nuevo, añades una regla. **2. Activas Plan Mode antes de cada tarea que no sea rutinaria.** Sin recordatorios y no por disciplina, sino porque entiendes que, sin un plan, perderás una hora y obtendrás un resultado equivocado. Ha dejado de ser un «paso extra» y se ha convertido en un reflejo. **3. Tienes tu propio catálogo de Skills y Subagents.** No descargados de GitHub, sino tuyos. Para tus tareas concretas. Cuando una tarea nueva se parece a una anterior, recuerdas tu Skill en vez de escribir un prompt desde cero. **4. Tu ritmo se ha estabilizado.** Ahora sabes que «una tarea así me lleva 3 horas». Ni «oh, esto será rápido» ni «oh, tardaré una eternidad». Tienes una estimación realista del tiempo. Esto significa que has superado el efecto Dunning-Kruger en ambas direcciones: has dejado de sobrevalorar y de infravalorar. **5. La gente empieza a preguntarte.** Alguien pregunta algo sobre MCP en un chat y respondes con un ejemplo concreto: «Esto es lo que me pasó a mí». Alguien pregunta por Plan Mode y le enseñas tu ejemplo. Es un efecto secundario de dominar la metodología: la gente del valle reconoce su propia experiencia en la tuya y acude a ti. Usa estas señales para reflexionar sobre el progreso, no para puntuarte ni predecir cuándo llegarás a una meseta. Comprueba con el tiempo si tus estimaciones y resultados se vuelven más coherentes. En la meseta, cambia el papel del ser humano dentro de un marco con agentes. Ese es el resultado del recorrido para salir del valle: ya no estás «aprendiendo a escribir prompts». Gestionas un marco de agentes, eres el arquitecto del proceso, eres quien está al mando. ## Qué hacer AHORA MISMO si estás perdiendo el ánimo
Punto clave Si has leído este artículo y te has dado cuenta de que estás atascado en el valle, no cierres la pestaña. Da tres pasos: di en voz alta en qué etapa estás (diagnóstico), baja el ritmo (un proyecto y un pilar para empezar) y consigue estructura (propia o de otra persona). Prueba un flujo estructurado antes de suponer que otra herramienta resolverá el problema. Consérvalo solo si mejoran los resultados; ni esta metáfora ni un calendario garantizan progreso.
Tres pasos para probar en tu próxima tarea. **Paso 1: di en voz alta en qué etapa estás.** Dite: «Estoy en el Valle de la Desesperación. Esta parte de mi flujo actual es frustrante. Puedo nombrar el bloqueo concreto y elegir un siguiente paso menor». Cuando nombras la etapa, deja de ser «mi catástrofe personal» y pasa a ser «mi posición actual en la curva». **Paso 2: baja el ritmo.** Elige UN proyecto. Ni dos ni tres: uno. Elige UNO de los tres pilares, el que resuelva más puntos de dolor de este proyecto. Si el proyecto es nuevo y no tiene ningún contexto, elige el segundo cerebro (CLAUDE.md). Si el proyecto ya existe, pero Claude no actúa «como tú», elige el clon de IA (Skills). Si las tareas son largas y el contexto se está llenando, elige la ingeniería de contexto (Plan Mode + `/compact`). Un proyecto, un pilar, dos semanas. No intentes construirlo todo durante un fin de semana; eso te devolverá al valle. **Paso 3: consigue estructura.** Puedes construir la metodología tú mismo. Según la experiencia del autor descrita aquí, eso llevó de tres a seis meses.
### Fuentes - [Anthropic Engineering, ingeniería de contexto eficaz para agentes de IA (2025)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — por qué se degrada la ventana de contexto y por qué hay que gestionarla. - [Documentación de Claude Code - Memory](https://code.claude.com/docs/en/memory) — la jerarquía oficial de memoria de Claude Code.
Para seguir trabajando con modelos, puedes ir a [Ailoot](https://ailoot.ai/). ## Preguntas sobre el aprendizaje y la revisión de proyectos con IA ### ¿Las cuatro etapas predicen que abandonaré al cabo de un mes? No. El artículo usa una curva popular como metáfora, sin tasa medida de abandono ni plazo universal. Sus ejemplos sirven para identificar un obstáculo concreto, no para diagnosticarte o predecir cuándo mejorarás. ### ¿Qué paso práctico doy si cambio constantemente de herramientas de IA? Elige un proyecto y un resultado pequeño que puedas verificar. Mejora la parte que más dificulte avanzar —instrucciones, procedimiento reutilizable o contexto— y compara resultado real y tiempo con el intento anterior. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.