Software 3.0 de Karpathy: lo que estoy construyendo en 2026

Software 3.0 de Karpathy: lo que estoy construyendo en 2026

Maté tres proyectos paralelos el fin de semana pasado.

Un planificador de comidas que convirtió fotos de compras en recetas. Un resumidor de notas de voz del "segundo cerebro". Una extensión de Chrome que reescribía las publicaciones de LinkedIn con tu voz. Todos ellos a medio construir. Todos ellos están ahora en mi cementerio ~/projects/abandoned/, con un único archivo KILLED.md en cada uno que explica por qué.

La razón fue la misma en los tres casos: un único mensaje multimodal LLM ya podía hacer el 80% de lo que hacía la aplicación. No estaba creando software. Estaba construyendo plomería en torno a capacidades que el modelo ya incluía de forma nativa.

Lo que me impulsó a abrir esas carpetas y ejecutar mv ~/projects/[name] ~/projects/abandoned/ no fue el lanzamiento de un nuevo modelo. Fue la charla Sequoia AI Ascent 2026 de Andrej Karpathy, en la que pronunció vibe coding "obsoleto" doce meses después de acuñar el término, declaró la ingeniería agentic como el nuevo valor predeterminado y dijo algo que se me quedó grabado durante días: "La mayoría de las aplicaciones existentes no deberían existir".

He visto muchas conferencias magistrales de AI este año. La mayoría de ellos son presentaciones de vendedores disfrazadas de visión. El de Karpathy era diferente. No me dijo qué usar; me dio un marco para evaluar cada línea de código que estoy escribiendo en este momento. Karpathy Software 3.0 no es un producto. Es una lente. Y una vez que comencé a mirarlo, no podía dejar de ver aplicaciones muertas por todas partes.

Esto es lo que he estado procesando. Lo que estoy construyendo ahora. Lo que me niego a construir. Y la única prueba, la prueba MenuGen, que ahora ejecuto en cada proyecto antes de escribir una línea de código.

Lo que realmente dijo Karpathy (y por qué es importante ahora)

Permítanme aclarar primero el encuadre, porque la frase "Software 3.0" ha sido tan alterada que está perdiendo su filo.

En el discurso de apertura de la escuela de inicio AI de junio de 2025 de Karpathy (https://x.com/karpathy/status/1935518272667217925), presentó una historia del software en tres etapas:

• Software 1.0: código que escriben los humanos. Reglas explícitas, lógica determinista, toda la Internet anterior a 2012. Lo que me enseñó mi título de informática.
• Software 2.0: pesos de redes neuronales entrenados en datos. El modelo aprende la función en lugar de que el ingeniero la especifique. Clasificadores de imágenes, sistemas de recomendación, toda la década del "aprendizaje automático".
• Software 3.0: modelos de lenguaje grandes como computadoras programables. Los "programas" en inglés (o en cualquier idioma), con indicaciones, ejemplos, herramientas y contexto. El mensaje es el código fuente. El LLM es el intérprete.

Esa tercera categoría es la que les rompió el cerebro a todos. Llevamos cincuenta años escribiendo 1.0 y 2.0 desde hace una década. Ahora hay una tercera cosa: no compila, no tiene verificación de tipos, no encaja en ninguno de nuestros IDE existentes o modelos mentales de control de versiones.

En su charla sobre Sequoia 2026, Karpathy fue más allá: señaló diciembre de 2025 como el punto de inflexión, el mes en el que el código generado por AI dejó de ser "útil pero complicado" y comenzó a ser consistentemente lo suficientemente bueno como para confiar en la producción. Su propia proporción se invirtió ese mes. En noviembre estaba escribiendo aproximadamente el 80% de su código a mano. En diciembre ya estaba delegando el 80% en agents.

Noté lo mismo en mi propia máquina: simplemente no tenía lenguaje para ello. A mediados de diciembre, dejé de revisar cada diferencia de Claude Code línea por línea. Dejé de hacer el ritual de "pasar el cursor sobre la función y leerla carácter por carácter" que había construido durante años. Las diferencias eran simplemente... correctas. No siempre es perfecto, pero sí con la suficiente frecuencia como para que el costo de una revisión completa supere el beneficio.

Ese fue el momento en que el suelo se movió.

Y esto es lo que nadie dice con suficiente claridad: el piso se mueve no significa que el techo se elevó. Significa que la mayoría de las aplicaciones que la gente está creando actualmente ya no necesitan existir.

Lo que nos lleva a la prueba.

La prueba MenuGen (Mi nuevo filtro precompilado)

El ejemplo de Karpathy fue MenuGen, una aplicación que creó y que tomaba una fotografía del menú de un restaurante y mostraba imágenes de cada plato para que pudieras ver lo que estabas pidiendo. Idea útil. Él lo envió.

Luego ocurrió la actualización Nano Banana de Gemini. Ahora puedes subir la foto del menú, escribir "muéstrame cómo es cada plato" y obtener el mismo resultado en línea. Sin aplicación. Sin backend. Sin gestión de API key. Sin distribución de App Store. Solo un único mensaje multimodal.

MenuGen quedó obsoleto en el momento en que un modelo de frontera pudo hacer el mismo trabajo de forma nativa.

Ahora ejecuto lo que llamo la prueba MenuGen en cada idea de proyecto antes de comprometerme con ella:

"Si un único mensaje multimodal LLM (para GPT-5.4, Claude Opus 4.7 o Gemini 3) puede hacer el 80% de lo que hace esta aplicación, la aplicación no debería existir como una aplicación independiente. Debería existir como un mensaje, un mensaje del sistema, una habilidad guardada o no debería existir en absoluto."

Eso es todo. Ese es el filtro.

Así es como obtuvieron mis tres proyectos eliminados:

Planificador de comidas a partir de fotos del supermercado. Un usuario sube una foto del contenido de su refrigerador → la aplicación extrae los ingredientes → sugiere recetas. Prueba MenuGen: Coloca una foto del refrigerador en Gemini y escribe "dame 3 recetas que pueda hacer con lo que está visible". Funciona. Mejor que mi aplicación, en realidad, porque Gemini sabe sobre técnicas de cocina y habría pasado dos meses en una integración API de visión inestable. Delicado.

Resumen de notas de voz con integración del segundo cerebro. Graba notas de voz → transcribe → resume → archiva en una jerarquía de estilo Obsidian. Prueba MenuGen: Claude con entrada de audio y un único servidor MCP apuntado a mi bóveda de Obsidian. Hecho. La "aplicación" consistía sólo en tres líneas de pegamento de orquestación. Delicado.

Reescritor de publicaciones de LinkedIn con tu voz. Pegar publicación → reescribir en el estilo tonal del usuario según publicaciones anteriores. Prueba MenuGen: Tenía que pensar en este. El mensaje real podría realizarse en una sola llamada LLM: introduzca publicaciones anteriores como ejemplos de estilo, pegue el nuevo borrador y obtenga una reescritura. El trabajo que estaba construyendo no era la reescritura. Fue la autenticación, la integración de LinkedIn API, la programación, el espacio de trabajo del equipo, el análisis. Ninguno de los cuales el usuario realmente solicitó. Pidieron "reescribir esta publicación con mi voz". Delicado.

Ese tercero es donde duele la prueba. Porque lo que en realidad estaba construyendo era un contenedor SaaS alrededor de un mensaje de 12 líneas. Y lo hubiera enviado. Yo hubiera cobrado por ello. Y seis meses después, cuando ChatGPT o Claude agregaron la función "coincidir con mi estilo de escritura desde un documento conectado", mi SaaS habría muerto de la noche a la mañana junto con otros 4.000 envoltorios "AI X para Y".

La prueba MenuGen no es pesimismo. Es un filtro de supervivencia. Si su producto puede replicarse con un solo mensaje, no está creando software, sino una función para el producto de otra persona.

Eso no significa que no se deba construir nada. Significa que tenemos que construir cosas diferentes.

De eso se trata el resto de esto.

Qué hizo bien Vibe Coding (y por qué Karpathy lo enterró)

Antes de abordar qué construir, debemos hablar sobre el cambio en el flujo de trabajo, porque la mayoría de las personas que conozco todavía son vibe coding, y Karpathy acaba de declararlo como una actividad de la liga junior.

Codificación Vibe, para ser justos, acertó en muchos aspectos. Levantó el suelo. Cualquiera con gusto y paciencia ahora puede enviar aplicaciones que funcionen. He visto a personas que no son ingenieros enviar integraciones de tiendas Shopify, paneles de control internos del equipo y herramientas personales en un solo fin de semana. Esa elevación del piso es real. No ha desaparecido.

Pero el argumento de Karpathy en 2026 es que vibe coding tiene un techo, y es bajo. Puede codificar por vibración un prototipo funcional. Puede codificar por vibración en una v1 que se demuestre bien. No se puede codificar por vibración para lograr confiabilidad de producción. No se puede codificar por vibración a través de una auditoría de seguridad. No se puede codificar una integración que maneja 10.000 usuarios simultáneos con eventuales requisitos de coherencia en tres bases de datos.

Ahí es donde entra en juego agentic ingeniería. La disciplina que ahora impulsa tiene una forma específica:

• Especificaciones antes del código. Escribe lo que debe hacer el sistema, no solo cómo quieres que se vea. (Mi artículo de OpenSpec cubre la versión de esto que realmente uso a diario).
• Planifica antes de las ediciones. Haga que agent proponga cambios antes de realizarlos. Revisa el plan. Luego ejecute. - Pruebas como señal principal. No vibraciones. No "se ve bien". Pruebas de reprobar y aprobar como prueba de que algo funciona. - Bucles de CI en cada cambio. Lint, prueba, verificación de tipos, escaneo de seguridad: automatizado, en cada confirmación, sin excepciones. - Inspección de diferencias. Lea lo que cambió el agent antes de aceptarlo. Especialmente para cualquier cosa relacionada con la autenticación, la facturación o los datos del usuario. - Aislamiento de permisos. No le dé una raíz agent a su máquina.

Utilice git worktrees para trabajo paralelo. Sandbox lo que puedas.

Si esa lista le resulta familiar, es porque es solo... ingeniería de software. Lo que siempre han hecho los ingenieros superiores. La versión de la práctica que sobrevivió a una década de "moverse rápido y romper cosas". Karpathy básicamente dice: AI no acabó con la disciplina de ingeniería. Hizo que la disciplina de ingeniería fuera más importante, porque ahora su colaborador es un joven con fluidez pero no cuidadoso que necesita su criterio, no su velocidad de mecanografía.

El cambio en 2026 no es "AI reemplaza a los ingenieros". Son "los ingenieros que pueden supervisar AI reemplazan a los ingenieros que solo escriben código".

Hay una cosa que le digo a todos los desarrolladores con los que trabajo ahora: el valor de tu juicio acaba de aumentar. El valor de tu mecanografía bajó. Si todavía estás vendiendo mecanografía, ya estás obsoleto. Si puede especificar, planificar, evaluar y revisar con una señal alta, obtendrá un multiplicador de apalancamiento de 10x.

Y lo que es más importante: Karpathy hizo una nota de advertencia que casi todo el mundo pasa por alto.

La trampa de los "10 agentes" (donde me quemaron)

Hay un meme circulando en este momento: "Tengo 20 Claude Code agents ejecutándose en paralelo, aquí está mi flujo de trabajo". Karpathy miró eso y dijo, esencialmente, no lo hagas.

Su encuadre: la mayoría de los constructores que intentan orquestar de 10 a 20 agents simultáneos se están adelantando a lo que los modelos actuales pueden soportar de manera confiable. La carga de supervisión crece de forma no lineal. En el momento en que administra 15 agents, pasa todo su tiempo como gerente intermedio que cambia de contexto y produce peores resultados que un solo agent bajo una supervisión cuidadosa.

Aprendí esto de la manera más difícil. Hace dos meses intenté configurar un canal de generación de contenido totalmente paralelo: un agent para investigación, uno para esquemas, uno para borradores, uno para edición, uno para comprobaciones de SEO y otro para copia de distribución. Seis agents. Todo funcionando simultáneamente. Todo "autónomo".

Lo que realmente sucedió: cada agent estaba produciendo un trabajo que el siguiente agent no podía usar porque ninguno de ellos tenía el contexto completo. La investigación agent reveló hechos que el esquema agent no sabía cómo ponderar. El borrador que agent inventó y encuadró el editor agent luego lo reescribió a medias. El SEO agent metió palabras clave en una prosa que el editor ya había pulido. Cuando me llegó el contenido, estaba dedicando más tiempo a conciliar seis salidas agents del que habría dedicado a hacer todo con un agent estilo Aria bajo un estricto control de contexto.

Maté el oleoducto. Ahora ejecuto un agent a la vez, profundamente, con un contexto rico: exactamente el enfoque de contexto sobre configuración sobre el que escribí a principios de este año. El trabajo se envía más rápido. La calidad es mayor. La carga cognitiva sobre mí es menor.

La precaución de Karpathy se corresponde perfectamente con lo que observé: menos agents, administrado con cuidado, con bucles de revisión, supera a más agents administrado de manera flexible. Hasta que los modelos mejoren materialmente en la coordinación multi-agent (lo cual lo harán, pero aún no lo han logrado), el paso correcto es optimizar el bucle agent único.

Este es uno de esos momentos en los que el discurso de las redes sociales y la experiencia real del profesional divergen marcadamente. Twitter quiere que pienses que el futuro es 50 agents en un enjambre. Karpathy, que tiene más contexto sobre la capacidad del modelo que básicamente cualquier persona en el planeta, dice: todavía no. No para la mayoría de los constructores. No en 2026.

Confío en él a través de Twitter. Tú también deberías hacerlo.

Las cuatro cosas que vale la pena construir ahora mismo

Está bien. Entonces la mayoría de las aplicaciones no deberían existir. La codificación de vibraciones es el calentamiento. La orquestación multi-agent es prematura. ¿Qué es lo que realmente vale la pena construir?

Karpathy mencionó cuatro pilares en su charla sobre Sequoia. Cada uno pasa la prueba MenuGen, porque cada uno es aditivo a lo que hacen los modelos de frontera de forma nativa, no un envoltorio de lo que ya hacen.

1. Herramientas que mejoran la comprensión (no solo la velocidad)

La primera ola de herramientas AI vendió velocidad. Código más rápido. Correos electrónicos más rápidos. Diseños más rápidos. Esa carrera prácticamente ha terminado: ahora todos los modelos de todos los proveedores son lo suficientemente rápidos.

La próxima ola vende claridad estratégica. Herramientas que le ayudarán a pensar mejor, decidir mejor, ver con mayor claridad y evitar errores que no habría detectado por su cuenta.

El patrón: en lugar de "Escribiré esto para ti", es "déjame mostrarte lo que te estás perdiendo". En lugar de generar resultados, la herramienta muestra las preguntas que usted no ha hecho, las suposiciones que está haciendo implícitamente, las decisiones que se esconden dentro de lo que parece una única elección.

Estoy creando exactamente este tipo de herramienta ahora mismo para mi propio flujo de trabajo de contenido. Aria, el agent que escribe para [la red de mi marca] (https://www.ramlit.com), no solo produce publicaciones. Ejecuta una rúbrica de autoevaluación en cada borrador, puntúa diez dimensiones de retención y se niega a enviar hasta que se apruebe la rúbrica. La salida no es más rápida. Es más claro, porque el agent saca a la luz lo que es débil antes de que yo tenga que hacerlo.

Ese es el patrón. No "lo haré por ti". Pero "te mostraré lo que no pudiste ver y te dejaré decidir".

Si está construyendo en 2026, pregúntese: ¿estoy vendiendo velocidad o estoy vendiendo claridad? La velocidad es un bien. La claridad es un foso.

2. Infraestructura de agente primero

Aquí es donde se pone divertido. Hemos pasado treinta años creando software para humanos: teclados, ratones, pantallas, GUI. Cada API tiene un "panel de desarrollador". Cada producto tiene un flujo de incorporación. Cada base de datos tiene una interfaz de usuario de creación de consultas.

Ahora agents son los clientes. Y agents no quiere UI. Quieren API. Quieren metadatos limpios. Quieren esquemas legibles por máquina. Quieren respuestas de error predecibles de las que puedan recuperarse. Quieren documentación estructurada, no con mucha prosa.

El cambio es enorme y la mayoría de los equipos de producto aún no lo han interiorizado. Si su producto va a ser utilizado por un AI agent en nombre de un usuario, cada elemento de la interfaz de usuario es un punto de fricción. Cada "haga clic aquí para confirmar" es un lugar donde el agent tiene que tender un puente entre la intención de la máquina y la interfaz de forma humana.

Los movimientos concretos a tomar ahora mismo:

• Enviar un archivo llms.txt. La adopción es alrededor del 10% a principios de 2026. La evidencia sobre el aumento de las citas es mixta. Pero implementarla lleva entre 1 y 4 horas y no hay inconvenientes si la especificación termina adoptada ampliamente. Es una opción de bajo costo en un futuro de alto impacto. - Exponga una variante de Markdown en cada página. Los rastreadores agentes (GPTBot, ClaudeBot, PerplexityBot) prefieren consistentemente Markdown a HTML cuando se ofrecen ambos. Esto es real, se observa y ya se refleja en las tasas de citación. - Documente sus API de la misma manera que los documentaría para un LLM. Borre entradas, borre salidas, operaciones idempotentes, errores predecibles. Evite la prosa con sabor a marketing. No es necesario vender un LLM; es necesario que se lo digan.

• Envíe MCP servers para su producto. Si se puede llamar a su herramienta desde Claude Code, ChatGPT o cualquier otro tiempo de ejecución agent, acaba de hacerla 10 veces más útil para los constructores. (Mi opinión sobre los MCP imprescindibles cubre lo que realmente funciona).

• Trate a agents como usuarios de primera clase. No es un canal secundario para usuarios avanzados. No es un "elemento de la hoja de ruta futura". Trate a la persona agent de la misma manera que trata a la persona móvil hoy.

Las empresas que hagan esto bien desde el principio parecerán obvias en retrospectiva. Aquellos que siguen optimizando las UI para los clics humanos mientras sus competidores silenciosamente se vuelven nativos de AI-agent se preguntarán por qué su crecimiento se estancó.

3. Aplicaciones de dominio verificable (donde RL tiene un foso)

Este es el pilar más profundo y el menos comprendido. Karpathy argumentó que los verdaderos fosos defendibles durante la próxima década no estarán en las tareas de lenguaje puro: éstas se están mercantilizando rápidamente. Estarán en dominios verificables: áreas donde puedes comprobar mecánicamente si el resultado del modelo es correcto.

El código es el obvio. Puedes ejecutar pruebas. Puedes pelusa. Puedes verificar el tipo de letra. Puedes desplegar y observar. Cada uno de ellos es una señal de retroalimentación que permite que el aprendizaje por refuerzo haga que el modelo sea realmente mejor en el código con el tiempo.

Pero el código no es el único dominio verificable. Mira la lista:

• Negociación algorítmica. P&L es una señal verificable. Las pruebas retrospectivas son reproducibles. El mercado es brutal pero cuantificable.
• Cadena de suministro. Niveles de inventario, tiempos de entrega, costo por unidad: todo medible, todo verificable, todo susceptible de ajuste de RL.
• Limpieza de datos y ETL. Corrección del esquema, validación de tipo e integridad referencial: son verificables. El modelo se puede entrenar contra tuberías de verdad terrestre.
• Cumplimiento y auditoría. Los requisitos regulatorios son reglas. O los datos los cumplen o no. Esa es una señal de verificación.
• Simulación científica. Física, química, ciencia de materiales: en cualquier lugar donde tenga un modelo de referencia que pueda validar predicciones.

Si está construyendo en un dominio donde la corrección es verificable, tiene un verdadero foso. Porque los datos que recopila de la producción se convierten en datos de entrenamiento que hacen que su modelo específico sea mejor en su tarea específica, y sus competidores que llaman Vanilla GPT-5.4 con un mensaje inteligente se estabilizarán en el mismo lugar que todos los demás competidores con avisos básicos.

Si está construyendo en un dominio donde la corrección no es verificable (tareas puramente creativas, decisiones que "se sienten bien", decisiones suaves), el foso es mucho más débil. El modelo de frontera se pondrá al día con su rápida ingeniería eventualmente, y probablemente pronto.

Esta es la idea estratégica más importante de la charla de Karpathy y casi nadie la repite. La verificabilidad es el objetivo. Si su producto tiene una señal de corrección medible, puede combinarlo. Si no es así, eres un envoltorio.

4. Software 3.0: aplicaciones nativas (no hojas de cálculo más rápidas)

El cuarto pilar es el más difícil porque requiere imaginación, no sólo ingeniería.

La mayoría de las "funciones de AI" que se enviarán en 2026 son aplicaciones de software 1.0 con un complemento AI. Hoja de cálculo con una barra lateral que explica fórmulas. Cliente de correo electrónico con un botón "resumir este hilo". Seguimiento de proyectos con el comando "redactar mi actualización standup".

Estos son útiles. No son Software 3.0.

Una aplicación Software 3.0-native es aquella que no podría haber existido antes de que LLM fuera el sustrato. Asume LLM de la misma manera que una aplicación 1.0 asume una CPU. El modelo no es una característica dentro de la aplicación; el modelo es el tiempo de ejecución en el que se ejecuta la aplicación.

Mire Vibe App Builder de monday.com. Piense en lo que realmente es: un sistema en el que alguien que no es desarrollador describe una aplicación en lenguaje natural y la plataforma genera una herramienta interna funcional: interfaz de usuario, conexiones de datos, permisos, todo. Monday envió más de 19 funciones y 26 pruebas A/B para Vibe Apps solo en el primer trimestre de 2026. El ritmo de escala te dice que han encontrado algo real.

Lo interesante no es que genere aplicaciones. Es que el modelo de interacción es fundamentalmente diferente de las herramientas sin código del pasado. No hay que arrastrar y soltar. No hay un diagrama de flujo visual. El usuario describe lo que quiere en inglés, LLM propone una aplicación funcional, el usuario perfecciona a través del chat. La aplicación no existe como código estático: existe como una conversación viva entre la intención y la ejecución.

Ese es Software 3.0-native. La descripción en inglés es el código fuente. El LLM es el compilador. La aplicación es el ejecutable.

Si está construyendo ahora mismo, la medida de mayor apalancamiento es preguntar: ¿qué es posible cuando LLM es el sustrato, no una característica? No "¿cómo agrego AI a mi aplicación?", sino "¿qué aplicación solo podría existir porque existen LLM?"

Ejemplos que estoy siguiendo de cerca:

• Motores de contexto personal: aplicaciones que aprenden sus patrones específicos con suficiente profundidad como para generar herramientas de trabajo adaptadas a usted, no a los "usuarios". Consulte el enfoque de habilidades CLAUDE.md propio de Karpathy para obtener una versión anterior de esto.
• Aplicaciones efímeras: aplicaciones que existen para un flujo de trabajo y se disuelven después. Sin instalación, sin registro. El modelo los pone en marcha en respuesta a una necesidad.
• Servicios administrados por agentes: productos en los que toda la capa de cara al cliente es un agent, no una interfaz de usuario, y el "producto" es el ciclo de razonamiento de agent.
• Sistemas de especificaciones continuas: software en el que la especificación reside junto al código y los cambios se propagan a través de ambas capas de forma automática. (Bart mode de Traycer es un vistazo de esto.)

Estos no son ciencia ficción. Están siendo creados en este momento, en pequeñas cantidades, por constructores que se saltaron la trampa "permítanme agregar una función AI a mi SaaS".

Cómo estoy reestructurando mi propio trabajo

Basta de teoría. Esto es lo que realmente cambié en mi flujo de trabajo después de sentarme a hablar durante una semana.

Uno. Eliminé tres proyectos paralelos y agregué una lista de verificación MenuGen test a mi plantilla de admisión de proyectos. Cada nueva idea ahora tiene que responder a la pregunta: ¿puede un solo mensaje multimodal hacer el 80% de esto? En caso afirmativo, no se construye. Se guarda como un mensaje en mi carpeta Claude Skills.

Dos. Cambié mi configuración agent de experimental en paralelo a agent de profundidad única. Descarté una canalización de contenido de seis agent y volví a ejecutar una instancia Aria a la vez, con un contexto rico, una supervisión cuidadosa y ciclos de revisión ajustados. La calidad de la salida mejoró inmediatamente. La publicación que estás leyendo ahora se produjo de esta manera.

Tres. Agregué un llms.txt a mejba.me, ramlit.com, colorpark.io y xcybersecurity.io. Los cuatro tardaron unos 90 minutos. La adopción es moderada, la evidencia de citas es mixta, pero el costo de omitirla es alto si la búsqueda de AI sigue creciendo como lo ha estado haciendo. Opcionalidad barata.

Cuatro. Empecé a auditar cada proyecto activo en función de los cuatro pilares. Si un proyecto no se ajusta a uno de ellos (herramienta de claridad, agent-first infra, dominio verificable o Software 3.0-native), está en la tabla de cortar. Hasta ahora se ha cancelado un proyecto más y se han reestructurado dos.

Cinco. Estoy invirtiendo agresivamente en el lado disciplinario del desarrollo de AI (especificaciones, planes, revisiones, pruebas) y restando importancia a la velocidad de escritura, los ajustes rápidos y la recopilación de herramientas. La influencia está en juicio ahora. Actúo en consecuencia.

Seis. Estoy atento a la siguiente inflexión. Karpathy tenía razón en diciembre de 2025. Se acerca el próximo gran cambio: cuándo ejecutar 20 agents en paralelo realmente funciona, cuando los modelos pueden autoespecificarse de manera confiable, cuando RL de dominio verificable produce una capacidad sobrehumana genuina en un nicho. Quiero que me configuren para reconocerlo en una semana, no en un trimestre. Eso significa permanecer cerca del borde del practicante, no del borde principal.

Lo único con lo que vale la pena sentarse

Si tomas algo de la charla de Karpathy y de toda esta publicación, toma esto:

El trabajo no es crear software. El trabajo es construir las cosas que el software ahora hace posibles.

Durante treinta años, "crear software" fue el objetivo porque el software era la limitación. Necesitabas una aplicación porque no podías hacer nada sin ella. La aplicación fue el cuello de botella.

El software ya no es el cuello de botella. El tiempo de ejecución LLM es el cuello de botella, y el cuello de botella se está moviendo más rápido de lo que puede hacerlo cualquier equipo de producto. Por lo tanto, crear "una aplicación" dentro de una categoría que ya está mercantilizada en la capa del modelo es un juego perdido. Realizarás el envío y, tres meses después, el modelo te incluirá.

El juego ganador es construir para el modelo, sobre el modelo o en dominios donde el modelo por sí solo no puede ganar. Herramientas de claridad. Infraestructura centrada en el agente. Experiencia en dominio verificable. Experiencias Software 3.0-native. Ésas son las cuatro apuestas que parecen obvias en cinco años.

Todo lo demás, incluida la mayoría de los proyectos que abrí en mi IDE la semana pasada, era MenuGen. Y MenuGen ahora es una característica, no un producto.

Ve a mirar tu carpeta ~/projects/ esta noche. Ejecute la prueba en cada uno de ellos. Sea honesto. La mayoría de nosotros estamos construyendo plomería en torno a capacidades que ya existen en el modelo. Algunos de nosotros estamos construyendo algo que sólo existe porque el modelo existe.

La diferencia entre esos dos es la diferencia entre un proyecto paralelo y uno que define una carrera. Karpathy nos acaba de pasar la prueba para diferenciarlos. El resto depende de nosotros.

¿Qué mataste esta semana?

Preguntas frecuentes

¿Qué es Software 3.0 de Karpathy en inglés sencillo?

Software 3.0 es cuando los LLM se convierten en el tiempo de ejecución y el lenguaje natural se convierte en el código fuente. El software 1.0 era un código escrito a mano. El software 2.0 fue entrenado con pesos de redes neuronales. Software 3.0 solicita un LLM que interpreta su intención y la ejecuta. Para ver el modelo mental completo, consulte la sección inicial anterior.

¿vibe coding estará muerto en 2026?

No: vibe coding todavía funciona para prototipos, proyectos de fin de semana y elevación de pisos para personas que no son ingenieros. Lo que Karpathy retiró fue vibe coding como enfoque de producción. Para el software que se puede enviar, la ingeniería agentic (especificaciones, planos, pruebas, CI y revisión de diferencias) es ahora el estándar. Consulte "Lo que Vibe Coding hizo bien" más arriba.

¿Qué es la prueba MenuGen?

La prueba MenuGen pregunta: si un único mensaje multimodal LLM puede hacer el 80% de lo que hace su aplicación, la aplicación no debería existir como un producto independiente. Proviene del ejemplo MenuGen de Karpathy: una aplicación real que creó y que quedó obsoleta en el momento en que la actualización Nano Banana de Gemini pudo hacer el mismo trabajo en un solo mensaje.

¿Debería construir un sistema multi-agent en 2026?

Probablemente todavía no. Karpathy advirtió explícitamente contra la ejecución simultánea de 10 a 20 agents: los modelos actuales no se coordinan tan bien y la carga de supervisión destruye la calidad. Un agent bajo una cuidadosa supervisión supera a seis que no están bien administrados. Vuelva a revisar esto en 6 a 12 meses.

¿Qué es la primera infraestructura agent?

La infraestructura de agente primero es un software diseñado para AI agents como usuarios principales: API limpios, metadatos legibles por máquina, archivos llms.txt, documentación de Markdown-first, MCP servers y respuestas de error predecibles. El cambio consiste en tratar a agents como una persona de primera clase, no como un canal secundario. Consulte el pilar 2 anterior para conocer movimientos concretos.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Cartera: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io