Investigación Automática Con Claude Code: El Bucle de Karpathy Que Funciona Mientras Duermes

Andrej Karpathy subió un script de Python de 630 líneas a GitHub el 7 de marzo de 2026. Se fue a dormir. Cuando despertó, su agente de IA había ejecutado más de 100 experimentos de machine learning, descubierto 20 optimizaciones que realmente funcionaron y compilado los resultados en un registro limpio — todo sin una sola pulsación de tecla humana durante la noche. El repositorio alcanzó 25.000 estrellas en cinco días. El CEO de Shopify, Tobi Lutke, lo apuntó a su motor de plantillas y obtuvo un renderizado un 53% más rápido con 93 commits automatizados. Y de repente, un concepto que había estado circulando en los círculos de investigación de IA — el bucle de mejora autónomo — tenía un nombre que todos podían recordar: auto research. He estado observando esto desde mi terminal de Claude Code. Y lo que me entusiasma no son los experimentos de ML. Es lo que ocurre cuando tomas el mismo patrón — cambiar una cosa, medir el resultado, conservar o descartar, repetir — y lo diriges a problemas de negocio. Conversiones de landing pages. Asuntos de correos electrónicos. Textos publicitarios. Diseños de páginas de precios. Cualquier cosa con un número asociado. Esa es la versión que Jack Roberts desglosó recientemente en un tutorial detallado, y es la versión que he estado probando durante las últimas dos semanas. Los resultados no son tan espectaculares como los de Karpathy — no estoy entrenando modelos de lenguaje durante la noche. Pero sí estoy viendo cómo Claude mejora autónomamente mis textos de conversión a través de un bucle estructurado que se ejecuta semanalmente sin que yo lo toque. Y la matemática compuesta de eso es genuinamente impresionante. Aquí te explico cómo funciona todo el sistema, cómo configuré el mío y los errores específicos que cometí para que no los repitas.

El Modelo Mental: Por Qué el 1% Se Compone Hasta 37x

Antes de tocar cualquier código, necesitas interiorizar por qué este enfoque funciona — porque el instinto que tiene la mayoría de la gente es erróneo. La mayor parte de la optimización ocurre en ráfagas. Rediseñas una landing page cada seis meses. Reescribes secuencias de correo una vez por trimestre. Actualizas textos publicitarios cuando el rendimiento se desploma. ¿Entre esas ráfagas? Nada cambia. Estás ejecutando los mismos textos, el mismo diseño, los mismos titulares durante semanas o meses. Auto research invierte ese modelo. En lugar de cambios grandes e infrecuentes, haces pequeños cambios continuos. Y la matemática de la mejora continua es contraintuitiva. Una mejora del 1% diaria — compuesta durante un año — no te da una ganancia del 365%. Te da una ganancia de 37x. Eso es 1,01 elevado a la potencia 365. James Clear popularizó esto en Atomic Habits, pero Karpathy lo convirtió en un patrón de ingeniería. El bucle de auto research es el mecanismo que hace que la mejora compuesta sea mecánica en lugar de aspiracional. Lo inverso es igual de brutal. Una caída diaria del 1% se compone hasta un 97% de pérdida. El estancamiento no es neutral — es una erosión lenta mientras los competidores iteran a tu alrededor. El número de 37x es teórico. No vas a mantener mejoras del 1% diario en ninguna métrica individual para siempre. Los rendimientos decrecientes son reales. Pero el patrón de iteración automatizada continua, eso es lo transformador. Incluso una mejora promedio del 0,1% por iteración, ejecutándose dos veces por semana, produce ganancias significativas a lo largo de un trimestre. Y la parte crítica: la IA maneja la iteración, no tú. La historia de WD-40 lo captura perfectamente. El producto recibió su nombre porque se necesitaron 40 intentos para conseguir la fórmula correcta de desplazamiento de agua. Cuarenta iteraciones. La mayoría de la gente habría parado en cinco. Auto research elimina la tendencia humana de abandonar temprano haciendo que cada iteración sea prácticamente gratuita. Esa es la teoría. Así es como se ve el sistema real.

Tres Componentes, Un Bucle: La Arquitectura de Auto Research

El framework de auto research — ya sea que lo apliques al entrenamiento de ML como Karpathy o a métricas de negocio como yo — siempre se reduce a tres componentes: Una cosa para cambiar. Una sola variable o elemento que estás dispuesto a dejar que Claude modifique. Un titular. El texto de un botón CTA. Un asunto de correo electrónico. El orden de beneficios de una página de precios. No cinco cosas a la vez — una cosa. El aislamiento importa porque si cambias tres variables y el rendimiento mejora, no sabes cuál cambio lo causó. Una métrica para medir. Un número objetivo y cuantitativo que te dice si el cambio ayudó o perjudicó. Tasa de conversión. Tasa de clics. Tasa de rebote. Tasa de apertura. No "vibras." No "se siente mejor." Un número. Un método para leer los resultados. Una forma para que Claude realmente acceda a los datos de rendimiento sin que tú los copies manualmente en un prompt. Aquí es donde la mayoría se atora, y te mostraré la solución que encontré en la sección de implementación. El bucle en sí es extremadamente simple:

1. Claude lee los datos de rendimiento actuales (el "control")
2. Claude genera una variante (el "retador")
3. Tú despliegas el retador
4. Espera a que se acumulen datos
5. Claude lee los nuevos datos de rendimiento
6. Si retador > control → el retador se convierte en la nueva línea base
7. Si control > retador → revertir, probar un enfoque diferente
8. Repetir desde el paso 1

Esto es lógica de A/B testing, pero con la IA manejando los pasos 1, 2, 5, 6, 7 y 8 de forma autónoma. Tu trabajo se reduce al paso 3 (desplegar el cambio) y al paso 4 (esperar). Y con las herramientas adecuadas — la automatización del navegador de Claude Co-work, por ejemplo — incluso el despliegue se puede automatizar. El repositorio original de Karpathy implementa esto para entrenamiento de ML. Sus tres archivos se mapean directamente a este framework:

• prepare.py — Preparación de datos fija y utilidades. El agente nunca lo toca. Es la base estable.
• train.py — El único archivo que el agente edita. Contiene la arquitectura del modelo, hiperparámetros, optimizador y bucle de entrenamiento. Todo es susceptible de modificación.
• program.md — El archivo de instrucciones. Le dice al agente qué optimizar, cómo medir el éxito y qué restricciones respetar. El agente modifica train.py, ejecuta un ciclo de entrenamiento de 5 minutos, verifica si la pérdida de validación mejoró, conserva o descarta el cambio y repite. En dos días, el agente de Karpathy ejecutó 700 experimentos y encontró 20 optimizaciones genuinas. Cuando esos 20 ajustes se aplicaron a un modelo más grande, la velocidad de entrenamiento mejoró un 11%. La versión de negocio sigue la misma estructura — archivos diferentes, mismo patrón. Permíteme explicarte cómo lo adapté.

Configurando Tu Entorno de Auto Research

Voy a describir la configuración que realmente uso, no un ideal teórico. Parte de esto es improvisado. Funciona.

Paso 1: Define Tu Métrica y Crea un Archivo de Contexto de Negocio

Elige una métrica. Yo elegí la tasa de clics en un botón CTA de landing page porque el bucle de retroalimentación es rápido (tengo suficiente tráfico para lecturas semanales) y la variable está aislada (texto del botón y contexto circundante). Luego crea un archivo business.md que le dé a Claude el contexto que necesita para tomar decisiones inteligentes. Esta es la parte que la mayoría salta, y es la parte que más importa. Sin contexto de negocio, Claude genera textos de marketing genéricos. Con él, Claude genera textos que realmente encajan con tu audiencia. Aquí hay una versión simplificada del mío:

# Business Context
## Who We Are
Ramlit Limited — software development agency serving B2B clients.
Primary service: custom web application development.
Average project size: $15K-$50K.
## Target Audience
- CTOs and engineering leads at mid-size companies (50-500 employees)
- Evaluating build-vs-buy for internal tools
- Pain points: slow development cycles, technical debt, unreliable freelancers
## Current Landing Page Performance
- Monthly visitors: ~2,400
- Current CTA click-through rate: 3.2%
- Primary CTA: "Get a Free Quote"
- Traffic sources: 60% organic, 25% referral, 15% direct
## Brand Voice
Professional but direct. No buzzwords. Results-focused.
Reference tone: ramlit.com existing copy.
## Constraints
- Do not change the core value proposition
- Do not use urgency tactics ("limited time", "act now")
- Keep CTA under 6 words
- All changes must maintain professional tone

Cuanto más específico sea tu archivo de contexto, más inteligentes serán las sugerencias de Claude. Aprendí esto de mi trabajo con sistemas de IA auto-mejorables — la calidad del documento de contexto determina directamente la calidad del output de la IA. Contexto genérico produce resultados genéricos.

Paso 2: Configura Tu Pipeline de Datos

Aquí es donde la cosa se pone seria — y donde la mayoría de las configuraciones de auto research fallan. La versión de Karpathy lo tiene fácil. La métrica (pérdida de validación) es calculada por el propio script de entrenamiento. El agente ejecuta el script, lee la salida y sabe inmediatamente si el rendimiento mejoró. Limpio, contenido, sin dependencias externas. Las métricas de negocio no son tan ordenadas. Tus datos de conversión viven en Google Analytics. O Stripe. O un dashboard de plataforma que no tiene API. Obtener esos datos en un formato que Claude pueda leer es el primer desafío técnico real. Probé tres enfoques: Opción A: Integración directa con API. Si tu plataforma de analytics tiene una API (Google Analytics 4, Mixpanel, Amplitude), puedes escribir un script que extraiga la métrica relevante y la vuelque en un archivo que Claude pueda leer. Este es el enfoque más limpio pero requiere algo de configuración.

# Example: Pull GA4 data into a metrics file
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import RunReportRequest
import json
from datetime import datetime
client = BetaAnalyticsDataClient()
request = RunReportRequest(
    property=f"properties/YOUR_PROPERTY_ID",
    dimensions=[{"name": "pagePath"}],
    metrics=[
        {"name": "screenPageViews"},
        {"name": "conversions"},
    ],
    date_ranges=[{"start_date": "7daysAgo", "end_date": "today"}],
)
response = client.run_report(request)
# Format for Claude consumption
metrics = {
    "date_pulled": datetime.now().isoformat(),
    "period": "last_7_days",
    "landing_page": "/services",
    "pageviews": int(response.rows[0].metric_values[0].value),
    "conversions": int(response.rows[0].metric_values[1].value),
    "conversion_rate": round(
        int(response.rows[0].metric_values[1].value)
        / int(response.rows[0].metric_values[0].value) * 100, 2
    )
}
with open("metrics/current_performance.json", "w") as f:
    json.dump(metrics, f, indent=2)

Opción B: Automatización del navegador con Claude Co-work. Cuando las APIs no están disponibles — y para un número sorprendente de plataformas, no lo están — Claude Co-work puede hacer scraping de datos del dashboard directamente. Cubrí esto en mi artículo sobre tareas programadas con Claude Co-work. Configuras una tarea programada que abre tu dashboard de analytics, lee los números relevantes y los escribe en un archivo o página de Notion. Opción C: Asistida manualmente (la versión honesta). Durante mis primeras dos semanas, simplemente copié los números en un archivo metrics.json cada lunes por la mañana. Tomaba 90 segundos. No es glamuroso. Pero me permitió validar el bucle en sí antes de invertir tiempo en automatización. No dejes que la infraestructura perfecta te impida empezar. Empecé con la Opción C y pasé a la Opción B después del primer mes cuando confirmé que el bucle estaba produciendo ganancias reales. Si estás empezando, haz lo mismo. Automatiza la pipeline de datos después de haber demostrado que el bucle de optimización funciona.

Paso 3: Crea Tu Archivo de Programa

Este es tu program.md — el conjunto de instrucciones que le dice a Claude cómo ejecutar el bucle. Aquí está la estructura que uso:

# Auto Research: Landing Page CTA Optimization
## Objective
Improve the click-through rate on the /services landing page CTA.
## Current Baseline
- Control CTA: "Get a Free Quote"
- Control CTR: 3.2% (last 7 days, from metrics/current_performance.json)
## Rules
1. Read the current metrics from metrics/current_performance.json
2. Read the business context from business.md
3. Analyze why the current CTR might be underperforming
4. Generate ONE challenger variant — a new CTA copy and 2-3 sentences
   of surrounding context
5. Explain WHY you expect the challenger to outperform (hypothesis)
6. Write the challenger to variants/challenger_[date].md
7. After deployment and data collection, compare challenger vs control
8. If challenger wins: update baseline in this file
9. If control wins: log the failed hypothesis and try a different approach
## Change Constraints
- CTA must be under 6 words
- Surrounding copy changes limited to the 3 sentences nearest the CTA
- No urgency language, no discount offers
- Maintain professional B2B tone
## Experiment Log
| Date | Variant | Hypothesis | Result | CTR |
|------|---------|-----------|--------|-----|
| Baseline | "Get a Free Quote" | — | Control | 3.2% |

El registro de experimentos al final es crítico. Le da a Claude memoria a través de las iteraciones. Sin él, el agente podría sugerir el mismo cambio dos veces o no aprender de fallos anteriores. Cada vez que el bucle se ejecuta, Claude lee el registro, ve qué se ha probado, qué funcionó y qué no — y luego genera una variante que se basa en ese conocimiento acumulado.

Paso 4: Configura la Frecuencia del Bucle

¿Con qué frecuencia debería ejecutarse el bucle? Depende de tu tráfico y velocidad de retroalimentación. Para mi landing page con ~2.400 visitantes mensuales, las iteraciones semanales me dan suficientes datos para medir diferencias significativas. Los sitios con alto tráfico (10.000+ visitantes diarios) podrían ejecutarse diariamente. Las campañas de correo podrían ejecutarse por envío. La restricción clave: necesitas suficientes datos entre iteraciones para distinguir señal de ruido. Si estás probando un cambio de CTA y solo 50 personas lo ven antes de la siguiente iteración, tus datos no tienen sentido. Espera significancia estadística — o al menos significancia práctica. Configuré el mío como una tarea programada semanal de Claude Co-work. Cada lunes a las 8 AM, Claude lee las últimas métricas, compara con el control de la semana anterior y genera el siguiente retador si los datos son concluyentes. Si tienes curiosidad sobre la mecánica de programación, explico la configuración exacta de Claude Co-work en mi guía de automatización de tareas programadas. La versión corta: creas una tarea programada en el panel de Co-work, la apuntas a tu directorio de proyecto y configuras la recurrencia.

Lo Que Realmente Pasó Cuando Ejecuté Esto Durante Dos Semanas

Aquí dejo de hablar de teoría y te muestro la realidad. Incluyendo las partes vergonzosas. Semana 1: La Línea Base Métricas iniciales: 3,2% CTR en "Get a Free Quote." 587 páginas vistas. 19 clics en CTA. Claude leyó el contexto de negocio, analizó la línea base y generó su primer retador:

CTA Retador: "See What We'd Build For You" Hipótesis: El CTA actual implica una interacción de venta transaccional ("cotización"). La audiencia objetivo (CTOs, líderes de ingeniería) está en modo de evaluación, no de compra. Reformular el CTA como una invitación a ver una solución personalizada reduce el compromiso percibido y aumenta la curiosidad. Cambié el texto del CTA el lunes por la tarde. Tomó dos minutos en el CMS. Resultados Semana 1: 612 páginas vistas. 27 clics. 4,4% CTR. Una mejora del 37,5% sobre la línea base. Mi reacción inmediata fue sospecha. ¿Un aumento del 37,5% por cambiar cinco palabras? Eso parecía demasiado alto. Podría ser ruido. Podría ser una mezcla de tráfico diferente esa semana. Lo anoté y seguí adelante. Semana 2: El Retador Sobreconfiado Claude leyó los resultados de la Semana 1, notó la mejora y se puso — voy a antropomorfizar aquí — ambicioso. La siguiente sugerencia: CTA Retador: "Your Custom Build Starts Here" Hipótesis: Construyendo sobre el éxito del marco de personalización ("What We'd Build For You"), esta variante añade impulso hacia adelante ("Starts Here") mientras mantiene bajo compromiso. El posesivo "Your" aumenta la psicología de propiedad. Hipótesis razonable. Lo desplegué. Resultados Semana 2: 591 páginas vistas. 22 clics. 3,7% CTR. Mejor que la línea base original, pero peor que el retador de la Semana 1. Así que Claude revirtió al ganador de la Semana 1 ("See What We'd Build For You") como la nueva línea base, registró el experimento fallido y anotó en el registro de experimentos: "El marco posesivo + lenguaje de acción rindió menos que el marco de curiosidad. La siguiente iteración debería explorar variaciones del enfoque de curiosidad en lugar de cambiar al lenguaje de acción." Esa nota — ese análisis autocorrectivo — es lo que hace que auto research sea diferente de un humano haciendo pruebas A/B. Yo no habría escrito esa síntesis. Habría mirado el número, pensado "eso no funcionó," y habría seguido adelante sin extraer la lección. Claude captura sistemáticamente por qué algo falló y lo usa para informar el siguiente intento. Los Resultados Acumulados Después de Dos Semanas: | Semana | CTA | CTR | vs. Línea Base | |------|-----|-----|-------------| | 0 (Control) | "Get a Free Quote" | 3,2% | — | | 1 | "See What We'd Build For You" | 4,4% | +37,5% | | 2 | "Your Custom Build Starts Here" | 3,7% | +15,6% | | 3 (actual) | "See What We'd Build For You" (revertido) | En curso | — | Dos iteraciones. Un ganador, un perdedor. El sistema aprendió de ambos. Y mi nueva línea base está un 37,5% por encima de donde empecé. Ahora imagina esto ejecutándose durante 26 semanas — medio año — con el efecto compuesto de que cada variante ganadora se convierte en el nuevo piso. Eso es auto research.

El Repositorio de Karpathy: Traduciendo Experimentos de ML a Uso Empresarial

Permíteme cerrar la brecha entre lo que Karpathy construyó y lo que tú realmente usarás, porque las implementaciones se ven diferentes aunque el patrón es idéntico. El repositorio autoresearch de Karpathy se enfoca en la optimización del entrenamiento de redes neuronales. El agente modifica decisiones de arquitectura, hiperparámetros, configuraciones del optimizador — decisiones técnicas que afectan una sola métrica: la pérdida de validación. Todo el bucle de retroalimentación es autocontenido. train.py se ejecuta durante 5 minutos, produce un valor de pérdida, y el agente decide si conservar el cambio. El repositorio se viralizó (49.800+ estrellas en GitHub al momento de escribir esto) porque demostró algo que la gente había teorizado pero no había visto funcionar limpiamente: un agente de IA que genuinamente mejora un sistema a través de experimentación autónoma, no solo prompting. Pero a menos que estés entrenando redes neuronales, necesitas adaptar el patrón. Aquí está la tabla de traducción:

El Problema de Datos del Que Nadie Habla (Y Mi Solución)

Aquí está la verdad incómoda sobre aplicar auto research a métricas de negocio: la mayor parte de tus datos importantes vive detrás de dashboards que no fueron diseñados para acceso programático. Google Analytics tiene una API. Stripe tiene una API. ¿Pero Skool? ¿Los datos detallados de engagement de ConvertKit? ¿Tu dashboard de WordPress? ¿Tu editor de temas de Shopify? La mitad de las herramientas que los fundadores realmente usan no exponen las métricas que necesitas a través de APIs limpias. Jack Roberts destacó exactamente este problema en su tutorial, y su solución es la correcta: automatización del navegador. Las capacidades de navegador de Claude Co-work pueden navegar a un dashboard, leer los números y escribirlos en un archivo. No es elegante. No es una integración apropiada. Pero funciona de manera confiable para el paso de "leer la métrica" del bucle. La configuración se ve así:

1. Crea una tarea de Co-work que navegue a tu dashboard de analytics
2. Inicia sesión usando credenciales guardadas (o, mejor, una sesión que permanezca autenticada)
3. Lee la métrica específica de la página — Claude puede identificar y extraer números de interfaces de dashboard
4. Escribe la métrica en un archivo JSON o página de Notion que tu bucle principal de auto research lea Probé esto con un dashboard de Google Analytics y una base de datos de Notion. Claude Co-work abrió la página de GA, encontró la tasa de conversión para mi página objetivo, extrajo el número y lo escribió en una tabla de Notion. Tomó unos 45 segundos por ejecución. No es rápido, pero ¿para una cadencia semanal? Perfecto. Para plataformas que requieren navegación más compleja — múltiples clics, filtros desplegables, selecciones de rango de fechas — necesitarás ser más explícito en tus instrucciones de tarea de Co-work. Describe cada clic. Especifica con qué elemento interactuar. Cuanto más precisas tus instrucciones, más confiable la automatización. Si prefieres que alguien construya toda esta pipeline de datos y bucle de auto research desde cero, acepto exactamente este tipo de proyectos de automatización con IA. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD. Una alternativa que vale la pena mencionar: Google Sheets como capa intermedia. Puedes configurar un Google Sheet que importe datos de varias fuentes (usando conectores integrados, Zapier o entrada manual), y luego hacer que Claude lea la hoja a través de la API de Google Sheets. Es un adaptador universal. Desordenado, pero universalmente compatible.

Eligiendo la Métrica Correcta: Dónde Funciona Auto Research (y Dónde No)

No toda métrica es buena candidata para auto research. Aprendí esto intentando optimizar lo equivocado primero. Candidatos de alto valor:

• Tasas de conversión de landing pages — Retroalimentación rápida, métrica clara, variable aislada. Mi principal recomendación para tu primer bucle de auto research.
• Tasas de apertura de asuntos de correo — Cada envío es un nuevo experimento. Alto volumen de datos si tu lista es de 1.000+.
• Tasas de clics de textos publicitarios — Plataformas como Google Ads y Meta ya proporcionan la métrica. Solo necesitas que Claude genere variantes y lea resultados.
• Tasas de finalización de página de checkout — Alto impacto empresarial, medible, y pequeños cambios de texto/diseño pueden mover la aguja significativamente.
• Tasas de adopción de funcionalidades en SaaS — Si puedes medir cuántos usuarios activan una funcionalidad, puedes optimizar el texto de onboarding o la UI que conduce a ella. Candidatos de bajo valor (evita estos para auto research):
• Rankings SEO — El ciclo de retroalimentación es demasiado lento (semanas a meses). Demasiadas variables confusas. No puedes aislar qué causó un cambio de ranking.
• Conocimiento de marca — No es cuantificable de manera significativa para bucles de iteración.
• Puntuaciones NPS — Demasiado subjetivas y demasiado infrecuentes para iteración rápida.
• Ingresos — Demasiado alto nivel. Los ingresos son un resultado de muchos insumos. Optimiza los insumos individualmente.
• Engagement en redes sociales — Demasiado ruidoso. Los cambios de algoritmo, la aleatoriedad viral y el humor de la audiencia confunden los datos. La métrica ideal de auto research tiene cuatro propiedades:

1. Alto volumen — Suficientes eventos por ciclo para medir diferencias
2. Retroalimentación rápida — Resultados disponibles en días, no meses
3. Variable aislada — Puedes cambiar una cosa y medir el impacto
4. Datos accesibles — Puedes leer la métrica programáticamente (o vía automatización del navegador) Si tu métrica elegida no cumple los cuatro criterios, elige otra. El bucle solo funciona si los datos son limpios, rápidos y atribuibles.

La Calidad de las Preguntas Importa Más Que la Calidad de las Respuestas

Esto es algo que Jack Roberts enfatizó y que merece su propia sección, porque es el insight más subestimado en todo el framework de auto research. Cuando escribes tu program.md, no solo le estás dando instrucciones a Claude. Estás definiendo el espacio del problema. Y la calidad de esa definición del problema determina el techo de lo que Claude puede descubrir. Mala definición del problema:

"Mejora la tasa de conversión de nuestro sitio web." Buena definición del problema: "Mejora la tasa de clics en el CTA de la página /services. La audiencia objetivo son CTOs evaluando decisiones de build-vs-buy. El CTR actual es del 3,2% con 600 páginas vistas semanales. El CTA aparece debajo de una sección de beneficios y arriba de un bloque de testimonios. El tráfico es 60% búsqueda orgánica." ¿La diferencia? La segunda versión le da a Claude suficiente contexto para formar hipótesis inteligentes. Conoce la mentalidad de la audiencia. Conoce la estructura de la página. Conoce la fuente de tráfico, lo que sugiere la intención de búsqueda. Cada uno de esos detalles moldea las sugerencias que Claude genera. He descubierto que invertir 30 minutos en escribir un business.md y program.md exhaustivos produce mejores resultados a lo largo de 10 iteraciones que invertir 5 minutos en un brief vago y ejecutar 50 iteraciones. El contexto es apalancamiento. Esto se conecta con un principio más amplio que he observado en todo mi trabajo con Claude Code: el cuello de botella casi nunca es la capacidad de la IA. Es la capacidad del humano para definir el problema con precisión. Auto research amplifica cualquier señal que le des — así que si la señal es vaga, obtienes optimización vaga. Si la señal es precisa, obtienes ganancias precisas.

Escalando Más Allá de Una Sola Métrica: La Arquitectura Multi-Bucle

Una vez que tu primer bucle de auto research está funcionando y produciendo ganancias, la pregunta natural es: ¿puedo ejecutar múltiples bucles simultáneamente? Sí. Pero con cuidado. El riesgo con múltiples bucles de optimización simultáneos son los efectos de interacción. Si estás optimizando el CTA de tu landing page y tu titular hero y tu sección de testimonios al mismo tiempo, un cambio en uno podría afectar el rendimiento de otro. Tu mejora del CTA podría parecer una regresión porque el cambio de titular arriba cambió la atención del usuario. Mi enfoque: secuencial, no paralelo. Ejecuta un bucle hasta que se estabilice (lo que significa que las mejoras se estancan y los retadores dejan de superar al control consistentemente). Luego bloquea esa variable, establece la versión ganadora como permanente y comienza un nuevo bucle en la siguiente variable. Para mi landing page, la secuencia se ve así:

1. Texto del CTA (ejecutándose ahora)
2. Titular hero (siguiente)
3. Sección de prueba social (después de que el titular se estabilice)
4. Orden del bloque de beneficios (último) Cada bucle se ejecuta durante 4-8 semanas antes de pasar a la siguiente variable. ¿Paciente? Sí. Pero preserva la claridad causal que hace que los datos sean confiables. Si absolutamente necesitas ejecutar bucles paralelos, hazlo en páginas diferentes o canales diferentes. Optimiza el CTA de tu landing page y los asuntos de tus correos simultáneamente — son sistemas independientes con métricas independientes. Solo no optimices dos elementos en la misma página al mismo tiempo.

Lo Que La Mayoría de la Gente Hará Mal

He estado probando esto durante dos semanas y hablando con otros tres builders que están haciendo lo mismo. Aquí están los patrones que veo fallar: Cambiar demasiadas variables por iteración. La tentación de "mejorarlo" cambiando cinco cosas a la vez es fuerte. Resístela. Necesitas aislamiento para aprender qué funciona. Un cambio. Una medición. Una decisión. Ignorar la significancia estadística. Si 50 personas vieron tu nuevo CTA y 3 hicieron clic (6% CTR) versus 2 haciendo clic en el antiguo (4% CTR), eso no es una diferencia significativa. Necesitas suficiente volumen de datos por iteración para confiar en el resultado. Para sitios de bajo tráfico, esto significa ciclos de iteración más largos — semanales como mínimo, quincenales para tráfico muy bajo. Usar métricas subjetivas. "La página se siente mejor" no es una métrica. "El nuevo texto está más alineado con la marca" no es una métrica. El bucle de auto research requiere un número. Si no puedes expresar tu objetivo como un número, el bucle no puede optimizar para ello. Saltarse el contexto de negocio. Ejecutar auto research sin un archivo business.md es como contratar un copywriter y no decirle quiénes son tus clientes. Claude generará algo. No generará nada particularmente útil. Rendirse después de la primera iteración fallida. El retador de la Semana 2 en mi prueba rindió peor que el ganador de la Semana 1. Si hubiera parado ahí, habría perdido el aprendizaje que informó el enfoque de la Semana 3. Los experimentos fallidos no son fracasos — son puntos de datos que reducen el espacio de búsqueda para la siguiente iteración. El agente de Karpathy ejecutó 700 experimentos. Muchos empeoraron las cosas. Eso es el proceso.

El Panorama General: Por Qué Esto Cambia Mi Forma de Pensar Sobre la Optimización

Antes de auto research, mi proceso de optimización se veía así: tener una idea, implementarla, verificar resultados en dos semanas, olvidar verificar, verificar un mes después, no recordar qué cambié, empezar de nuevo. Después de auto research, mi proceso de optimización se ve así: definir la métrica, definir las restricciones, dejar que Claude ejecute el bucle, revisar el registro de experimentos semanalmente, intervenir solo cuando algo parece raro. La diferencia en carga cognitiva es enorme. No gasto energía mental en "¿qué debería probar después?" Ese es el trabajo de Claude. Gasto energía mental en "¿está el framework correctamente definido?" — que es una pregunta con mucho más apalancamiento. Y el efecto compuesto es real. No el teórico 37x. Pero una mejora del 37,5% en dos semanas en una sola métrica, con un sistema que seguirá iterando? Proyecta eso seis meses hacia adelante. Incluso con rendimientos decrecientes, el impacto acumulado en una métrica de negocio que importa — conversiones, clics, registros — es significativo. El patrón de auto research no es complicado. Tres archivos. Una métrica. Un bucle. La parte difícil no es construirlo. La parte difícil es elegir la métrica correcta, escribir contexto preciso y ser lo suficientemente paciente para dejar que el efecto compuesto funcione. Karpathy demostró que esto funciona para investigación de ML a una escala que asombró a la industria. La versión de negocio es más lenta, más desordenada y menos dramática. También es accesible para cualquiera con una suscripción a Claude y una métrica que le importe. Empieza con una métrica. Escribe tu archivo de contexto esta noche. Configura el bucle este fin de semana. Luego déjalo ejecutarse mientras duermes. Dentro de seis meses, desearás haber empezado hoy — o te alegrarás de haberlo hecho.

Preguntas Frecuentes

¿Qué es auto research en Claude Code?

Auto research es un bucle de optimización autónomo donde Claude Code prueba iterativamente cambios contra una métrica medible, conserva las mejoras, descarta los fallos y repite. Andrej Karpathy popularizó el patrón en marzo de 2026 con su repositorio autoresearch en GitHub, que ejecutó 700 experimentos de ML en dos días. Para aplicaciones de negocio, el mismo patrón optimiza tasas de conversión, tasas de clics y otras métricas cuantificables.

¿Necesito experiencia en programación para configurar un bucle de auto research?

La gestión básica de archivos y comodidad con un editor de texto son suficientes para una configuración asistida manualmente donde copias métricas en un archivo JSON semanalmente. Para automatización completa — integraciones de API, scraping de navegador, tareas programadas — necesitarás habilidades intermedias de Python o familiaridad con las funciones de automatización del navegador de Claude Co-work. Los archivos program.md y business.md son Markdown puro.

¿Cuánto tráfico necesito para que auto research funcione?

Necesitas suficientes eventos por ciclo de iteración para distinguir señal de ruido. Para optimización de landing pages con ciclos semanales, 500+ páginas vistas por semana es un mínimo razonable. La optimización de correo necesita 1.000+ destinatarios por envío. Las pruebas de texto publicitario funcionan con volúmenes más pequeños porque las plataformas publicitarias proporcionan medición robusta. Los sitios de bajo tráfico deberían usar ciclos quincenales o mensuales.

¿Puedo ejecutar auto research en múltiples métricas a la vez?

Ejecuta bucles paralelos en sistemas independientes — optimiza tu landing page y tus asuntos de correo simultáneamente. Evita ejecutar bucles paralelos en la misma página o embudo, porque los cambios en un elemento pueden afectar el rendimiento de otro, haciendo imposible atribuir resultados. La optimización secuencial con una variable a la vez produce datos más limpios y confiables.

¿Cómo se relaciona el repositorio autoresearch de Karpathy con la optimización empresarial?

El repositorio de Karpathy optimiza el entrenamiento de redes neuronales dejando que un agente de IA modifique train.py, ejecute un ciclo de entrenamiento, mida la pérdida de validación y conserve o descarte cambios. La versión de negocio usa el mismo patrón de control-vs-retador pero intercambia el entrenamiento de ML por textos de negocio, la pérdida de validación por tasa de conversión y las ejecuciones de entrenamiento de 5 minutos por recolección semanal de datos. El framework central — cambiar, medir, decidir, repetir — es idéntico.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io