La mayoría de los desarrolladores siguen usando la IA de la misma manera que usaban ChatGPT en 2023.
Abrir un chat. Hacer una pregunta. Copiar algo de código. Pegarlo en el editor. Repetir.
Funciona. Nadie dice que no funcione.
Pero ya se está volviendo obsoleto de formas que la mayoría aún no ha notado. Y los desarrolladores que lo notan temprano están construyendo silenciosamente una ventaja que será muy difícil de cerrar después.
Está surgiendo una nueva categoría de desarrollador. No están usando la IA como asistente de codificación como todos los demás. Están construyendo sistemas operativos completos a su alrededor. Sistemas estructurados con memoria, contexto, agentes especializados, bucles de verificación y flujos de trabajo que se acumulan con el tiempo.
La brecha entre esos dos enfoques se está convirtiendo en una de las ventajas competitivas más significativas en el desarrollo de software. No porque un grupo sea más inteligente que el otro. Sino porque un grupo entendió antes que el verdadero apalancamiento nunca estuvo en el modelo. Siempre estuvo en el sistema que rodea al modelo.
Los desarrolladores que entienden este cambio hoy tendrán una ventaja que seguirá creciendo durante los próximos años. Porque el futuro del desarrollo de software no se trata de escribir código más rápido. Se trata de orquestar inteligencia a escala.
La conversación que todos tienen es la conversación equivocada
Durante los últimos dos años, toda la discusión sobre IA ha estado dominada por una pregunta que se repite en diferentes formas.
¿Qué modelo es mejor?
Claude contra GPT. GPT contra Gemini. Gemini contra DeepSeek. Código abierto contra propietario. Todos comparando puntos de referencia, puntuaciones de codificación, ventanas de contexto y evaluaciones de razonamiento, como si el modelo mismo fuera donde termina la competencia.
Esa conversación se está volviendo lentamente menos importante de lo que la gente que la tiene cree.
Una pregunta más valiosa está surgiendo silenciosamente debajo de todo el ruido.
¿Cómo convertir un modelo de lenguaje en un ingeniero de software productivo?
No un chatbot que responde preguntas. No un motor de autocompletado que ahorra pulsaciones de teclas. No un generador de código que produce funciones bajo demanda. Un sistema de ingeniería real capaz de planificar trabajo, investigar soluciones, revisar código, encontrar errores, escribir pruebas, actualizar documentación, gestionar contexto en proyectos largos, aprender de decisiones anteriores y mejorar sus propios resultados con el tiempo.
Esa transformación está ocurriendo ahora mismo en torno a herramientas como Claude Code. Y es mucho más grande de lo que sugieren los debates sobre puntos de referencia.
La primera ola de herramientas de codificación con IA resolvió el problema equivocado
La primera generación de herramientas de codificación con IA se centró casi exclusivamente en la generación de código. Ese era el problema obvio a resolver y era un problema real que valía la pena resolver.
GitHub Copilot demostró que la IA podía autocompletar código de formas genuinamente útiles. ChatGPT hizo que el desarrollo de software fuera conversacional por primera vez. Los modelos mejoraron rápidamente. Las ventanas de contexto se expandieron. La calidad del código aumentó hasta el punto en que los resultados a menudo estaban listos para producción con una edición mínima.
Durante un tiempo, parecía que toda la industria corría hacia un objetivo claro. Generar más código, más rápido, con menos errores.
Pero los ingenieros experimentados descubrieron rápidamente algo que debería haber sido obvio desde el principio.
Escribir código rara vez es la parte más difícil del desarrollo de software.
El verdadero trabajo, el que consume la mayor parte del tiempo de un ingeniero senior y la mayor parte de la energía de un equipo, generalmente se ve así. Comprender requisitos que son incompletos o contradictorios. Investigar soluciones en un código base que tiene años de historia y decisiones integradas. Tomar decisiones arquitectónicas que se convertirán en ventajas o en deuda técnica dependiendo de qué tan bien se hayan pensado. Gestionar esa deuda técnica una vez que se acumula. Probar casos límite que nadie consideró durante la planificación. Revisar implementaciones para verificar corrección, seguridad y mantenibilidad. Depurar problemas de producción bajo presión. Mantener documentación que siempre está ligeramente desactualizada. Coordinar proyectos complejos entre personas con diferentes modelos mentales de lo que se está construyendo.
La mayor parte del ciclo de vida de la ingeniería ocurre fuera del editor.
Y ahí es exactamente donde los flujos de trabajo tradicionales de IA, el enfoque de abrir un chat y copiar algo de código, comenzaron a fallar por completo.
Por qué Claude Code se siente genuinamente diferente a todo lo anterior
Claude Code introdujo una idea fundamentalmente diferente y vale la pena enunciarla precisamente porque la diferencia es fácil de subestimar.
En lugar de tratar a la IA como algo que consultas ocasionalmente en busca de ayuda, la coloca directamente dentro del flujo de trabajo como un participante activo en la ejecución.
Eso suena a una distinción sutil. No es sutil en absoluto.
Un chatbot espera instrucciones y responde a ellas. Un operador participa en la ejecución y realiza acciones dentro de tu entorno real. Esa distinción cambia toda la naturaleza de la relación entre el desarrollador y la herramienta.
Cuando los desarrolladores comenzaron a trabajar seriamente con Claude Code, la conversación pasó de preguntar si la IA podía escribir una función específica a preguntar si la IA podía manejar un flujo de trabajo completo de principio a fin. Una vez que esa pregunta aparece en tu mente, dejas de pensar en la generación de código como el objetivo. Empiezas a pensar en sistemas. Y los sistemas son donde siempre ha existido el verdadero apalancamiento en la ingeniería.
Los desarrolladores que más están aprovechando Claude Code hoy no son los que escriben los mensajes individuales más ingeniosos. Son los que construyeron los sistemas más reflexivos a su alrededor.
El cuello de botella casi nunca es la inteligencia
La mayoría de la gente asume que cuando la IA produce resultados mediocres, es porque el modelo no es lo suficientemente inteligente. Esa suposición lleva a una búsqueda constante de un modelo mejor que finalmente produzca los resultados que todos esperan.
En realidad, el cuello de botella es casi siempre el contexto. No la inteligencia. El contexto.
Piensa en contratar al mejor ingeniero de software que puedas imaginar y luego no darle documentación, ni historial del proyecto, ni estándares de codificación, ni registro de decisiones arquitectónicas anteriores, ni conocimiento de los errores que ya se han encontrado y corregido. Ese ingeniero tendría enormes dificultades. No porque sea incapaz. Sino porque opera sin el contexto que hace útil la capacidad.
Los modelos de IA enfrentan el mismo problema en cada conversación que comienza desde cero, sin memoria de lo que vino antes.
Esto explica algo que confunde a la gente cuando lo encuentra por primera vez. Dos desarrolladores pueden usar el mismo modelo y obtener resultados que parecen provenir de herramientas completamente diferentes. Uno obtiene resultados que son genuinamente útiles y están listos para producción. El otro obtiene resultados mediocres que requieren más corrección que el código original.
La diferencia casi nunca es el modelo. La diferencia es la gestión del contexto. Un desarrollador le dio al modelo lo que necesitaba para funcionar bien. El otro no.
Esta es una de las cosas más importantes de entender prácticamente sobre trabajar con IA a un nivel serio. No solo estás eligiendo un modelo. Estás construyendo un entorno en el que ese modelo puede operar de manera efectiva. El entorno determina el resultado mucho más que la capacidad bruta del modelo dentro de él.
El contexto se está convirtiendo en la nueva infraestructura
La mayoría de las discusiones sobre IA se centran en los mensajes porque los mensajes son la capa visible. Son lo que escribes. Son lo que ves. Se sienten como lo que estás controlando.
Pero los mensajes son solo la superficie.
Debajo de cada flujo de trabajo de IA consistentemente exitoso se encuentra una infraestructura mucho más grande en la que la mayoría de la gente nunca piensa explícitamente y casi nunca discute públicamente.
Esa infraestructura incluye sistemas de memoria que persisten la información entre sesiones en lugar de empezar desde cero cada vez. Almacenamiento de conocimiento que captura decisiones, estándares y patrones en una forma que el modelo pueda consultar. Recuperación de contexto que muestra la información correcta en el momento adecuado sin abrumar al modelo con todo a la vez. Orquestación de flujos de trabajo que secuencia tareas en el orden correcto con las entradas correctas fluyendo entre ellas. Bucles de evaluación que verifican los resultados contra los estándares antes de que pasen a la siguiente etapa. Controles de seguridad que definen lo que el modelo puede y no puede tocar. Tuberías de verificación que detectan errores antes de que se acumulen. Monitoreo de rendimiento que identifica dónde el sistema está produciendo resultados pobres para que esos puntos puedan mejorarse.
Estos sistemas determinan si una IA se vuelve genuinamente útil para una organización de ingeniería o sigue siendo un costoso motor de autocompletado que ahorra algunas pulsaciones de teclas e impresiona a la gente en demostraciones.
Las empresas y los desarrolladores individuales que construyen estas capas hoy están construyendo efectivamente los sistemas operativos de la era de la IA. No solo están usando las herramientas que existen. Están construyendo la infraestructura en la que se ejecutará la próxima generación de herramientas.
El auge del desarrollo agentivo y por qué refleja cómo se construyen los grandes equipos
Hacia ahí se dirige el desarrollo de software y es más fácil de entender si lo conectas con algo que ya tiene sentido intuitivo.
Piensa en cómo funciona una organización de ingeniería genuinamente efectiva. No contratas a una persona y le pides que haga todo. Tienes especialistas profundamente capacitados en áreas específicas. Investigadores que entienden el espacio del problema. Arquitectos que toman decisiones estructurales. Revisores que detectan problemas en la implementación. Ingenieros de seguridad que piensan en lo que podría salir mal de formas que los ingenieros centrados en el producto pasan por alto. Ingenieros de control de calidad que prueban las suposiciones contra la realidad. Redactores técnicos que hacen que el sistema sea comprensible para todos los que trabajan con él. Operadores que mantienen todo funcionando en producción.
El mismo patrón está surgiendo dentro de los flujos de trabajo avanzados de IA.
Un sistema agentivo bien diseñado hoy podría moverse a través de un Agente de Investigación que investiga el espacio del problema antes de tomar cualquier decisión, luego un Agente de Arquitectura que diseña el enfoque estructural basado en esa investigación, luego un Agente de Implementación que escribe el código según la especificación arquitectónica, luego un Agente de Pruebas que verifica la implementación contra los requisitos y casos límite, luego un Agente de Seguridad que revisa vulnerabilidades, luego un Agente de Documentación que captura lo que se construyó y por qué, luego un Agente de Despliegue que gestiona el proceso de lanzamiento.
Cada sistema tiene una responsabilidad específica. Cada sistema se centra en un problema específico. Juntos se comportan menos como un chatbot y más como una organización de ingeniería con roles definidos y traspasos claros entre ellos.
Por eso los usuarios más sofisticados de Claude Code ya no pasan la mayor parte del tiempo creando mensajes individuales. Pasan su tiempo diseñando flujos de trabajo. El mensaje es solo la entrada a una etapa en un sistema más grande. El sistema es lo que produce resultados consistentemente buenos.
La memoria puede terminar importando más que la capacidad del modelo
Este es el cambio que la mayoría de la gente no se toma lo suficientemente en serio y es el que creo que importará más en los próximos años.
Los modelos están mejorando rápidamente y la brecha entre los mejores modelos disponibles se está reduciendo. Los puntos de referencia entre los modelos fronterizos se están acercando, no alejando. Las guerras de modelos que dominan la conversación se libran por diferencias que se están reduciendo.
Pero la memoria crea ventajas compuestas que no se reducen. Crecen.
Piensa en lo que hace que un ingeniero senior sea genuinamente valioso en comparación con un ingeniero junior con inteligencia bruta similar. La experiencia. Y la experiencia importa porque la experiencia crea memoria. La memoria crea intuición sobre lo que funciona y lo que no. La intuición crea mejores decisiones tomadas más rápido con menos energía. Esas mejores decisiones se acumulan con el tiempo en un historial y una profundidad de juicio que no se pueden replicar rápidamente.
Sin memoria, cada proyecto comienza desde cero independientemente de lo que vino antes. Cada error se repite porque no hay registro de que se haya cometido. Cada lección aprendida desaparece al final de la sesión. Cada flujo de trabajo que funcionó bien tiene que ser reconstruido la próxima vez que se necesite. Esa es una enorme ineficiencia que se acumula invisiblemente en cada proyecto.
Por eso los constructores de sistemas de IA más innovadores se están centrando fuertemente en la persistencia de sesiones que lleva el contexto a través de conversaciones, la memoria a largo plazo que captura patrones y decisiones en una forma recuperable, la acumulación de conocimiento que se construye sobre sí misma en lugar de reiniciarse, y la evolución del flujo de trabajo que mejora el sistema basándose en lo que ha funcionado antes.
El futuro que realmente se avecina no son simplemente modelos más inteligentes. Son sistemas más inteligentes que recuerdan y mejoran. La ventaja compuesta pertenece a quien construya esos sistemas primero.
La capa oculta que la mayoría ignora por completo
Aquí está la observación a la que sigo volviendo cuando pienso en dónde vive la verdadera ventaja.
Tres desarrolladores pueden usar el mismo modelo Claude hoy. Uno obtiene resultados promedio que son marginalmente mejores que escribir el código manualmente. Uno obtiene resultados excelentes que aceleran significativamente su producción. Uno construye una empresa de software completa alrededor del modelo y produce cosas que no habrían sido posibles con un equipo de cualquier tamaño hace unos años.
La diferencia entre esos tres resultados no es la inteligencia. Ni siquiera es el esfuerzo, al menos no directamente. Es la infraestructura.
El stack técnico ganador se parece cada vez más a un pastel de capas donde el modelo se sienta en la parte superior, visible y discutido constantemente, y todo lo que está debajo es donde vive la ventaja competitiva real. Memoria debajo del modelo. Orquestación de flujos de trabajo debajo de eso. Sistemas de evaluación que verifican los resultados. Controles de seguridad que definen los límites. Automatización que elimina pasos repetitivos. Tuberías de ejecución que encadenan todo.
La mayoría de la gente solo se centra en la capa superior. Se centran en el modelo porque el modelo es con lo que interactúan directamente y lo que el marketing enfatiza.
El mayor apalancamiento, el lugar donde se están construyendo las mayores ventajas ahora mismo, existe en todo lo que está debajo de la capa visible.
Por qué este momento me recuerda a la revolución de la nube
El paralelismo vale la pena tomarlo en serio porque sigue siendo preciso en retrospectiva, aunque siempre parece opcional en el momento.
La mayoría de los desarrolladores hoy ven los flujos de trabajo agentivos como un experimento interesante o una mejora de productividad que vale la pena explorar cuando hay tiempo. Así es exactamente como se veía la computación en la nube en 2008 y 2009. La gente pensaba que podían simplemente ejecutar sus propios servidores. Los desarrolladores que construyeron sobre infraestructura en la nube al principio parecía que estaban sobreingenierizando las cosas. Luego la nube se volvió estándar y los que no habían hecho el cambio estaban repentinamente atrás de maneras que eran costosas de corregir.
El mismo patrón apareció con el control de versiones, con los contenedores, con la integración continua y el despliegue. Cada cambio de infraestructura inicialmente parece un truco opcional de productividad para personas con tiempo para experimentar. Luego se convierte en una ventaja competitiva para las organizaciones que lo adoptaron temprano. Luego se convierte en la forma predeterminada de trabajar y todos los demás están poniéndose al día.
El desarrollo agentivo está siguiendo la misma trayectoria. Hoy es experimental y practicado por una minoría de desarrolladores que están desproporcionadamente entusiasmados con ello. Mañana será esperado por las organizaciones de ingeniería que quieran seguir siendo competitivas. La ventana donde la adopción temprana crea una ventaja duradera está abierta ahora y no permanecerá abierta indefinidamente.
El conjunto de habilidades del desarrollador está evolucionando en una dirección específica
Durante la mayor parte de la historia de la ingeniería de software, el éxito estaba fuertemente correlacionado con la capacidad de implementación. Qué tan rápido podías escribir código correcto. Qué tan profundamente entendías lenguajes y marcos de trabajo específicos. Cuántos algoritmos podías recordar y aplicar. Esas habilidades importaban enormemente y todavía importan.
Pero los desarrolladores de mayor apalancamiento de la próxima década se centrarán cada vez más en un conjunto diferente de capacidades.
Diseñar flujos de trabajo que secuencien agentes de IA a través de tareas complejas en el orden correcto con las entradas y salidas correctas en cada etapa. Gestionar el contexto para que los modelos tengan lo que necesitan para funcionar bien sin verse abrumados. Construir sistemas de evaluación que verifiquen los resultados antes de que se utilicen. Crear arquitecturas de memoria que acumulen conocimiento y mejoren con el tiempo. Coordinar agentes especializados que se centren en problemas específicos. Definir procesos de verificación que mantengan la calidad a medida que aumenta el volumen de resultados. Estructurar tuberías de ejecución que se encadenen en sistemas automatizados confiables.
El trabajo está evolucionando de construir cosas a dirigir inteligencia. De escribir código a diseñar los sistemas que producen código. De implementación a orquestación.
Ese es un cambio significativo en cómo se ve el dominio. Los desarrolladores que lo reconozcan temprano y comiencen a construir esas habilidades ahora estarán posicionados de manera muy diferente a los que continúan optimizando para la vieja definición de excelencia en ingeniería.
Hacia dónde lleva esto y qué tan lejos podría estar
La evolución de la relación del desarrollador con la IA parece moverse a través de etapas reconocibles.
La primera etapa fue un desarrollador trabajando con un editor, produciendo todo manualmente con herramientas que organizaban y mostraban el código pero no contribuían a escribirlo.
La segunda etapa es un desarrollador trabajando con un asistente de IA que responde preguntas, genera código bajo demanda y acelera tareas específicas mientras el desarrollador sigue siendo el productor principal.
La tercera etapa, donde se encuentran los profesionales más avanzados hoy, es un desarrollador trabajando con algo más cercano a un equipo de IA. Múltiples sistemas especializados que manejan diferentes partes del flujo de trabajo con el desarrollador dirigiendo y revisando en lugar de producir cada resultado directamente.
La cuarta etapa, que se está volviendo visible en el horizonte, es un desarrollador trabajando con un sistema operativo de IA. Una infraestructura completa que maneja investigación, planificación, implementación, pruebas, seguridad, documentación y despliegue como funciones integradas con el desarrollador operando como el arquitecto y tomador de decisiones en lugar del ejecutor.
La mayoría de los desarrolladores en activo hoy están en algún lugar entre la etapa dos y la etapa tres. El movimiento hacia la etapa tres se está acelerando. La etapa cuatro no está tan lejos como podría parecer.
Lo que realmente vale la pena observar
La mayor parte de la conversación sobre IA en este momento se centra en las guerras de modelos. Claude contra GPT. Código abierto contra propietario. Puntuaciones de referencia en evaluaciones que pueden o no reflejar el rendimiento en el mundo real.
Esos debates son interesantes y no carecen de valor. Pero pueden importar mucho menos de lo que piensan quienes los tienen.
La historia más grande es que el desarrollo de software en sí mismo se está volviendo agentivo. La estructura de cómo se construye el software está cambiando a un nivel fundamental, no solo acelerándose en los márgenes.
Los ganadores en ese mundo no serán necesariamente los desarrolladores con acceso al modelo individual más inteligente. Serán los desarrolladores que construyeron los sistemas más inteligentes alrededor de esos modelos. Los que entendieron que la gestión del contexto importa más que la capacidad bruta del modelo. Que la memoria crea ventajas compuestas. Que el diseño de flujos de trabajo es donde vive el verdadero apalancamiento. Que orquestar inteligencia es una habilidad más valiosa que generar código.
Claude Code importa como señal, no solo como herramienta. Es uno de los primeros y más claros vistazos a cómo se ve la ingeniería de software cuando la inteligencia se convierte en infraestructura programable en lugar de una consulta ocasional.
Una vez que ese cambio aterrice por completo, la pregunta ya no es si la IA puede escribir código. Todos ya saben que puede escribir código.
La pregunta se convierte en cuánto del ciclo de vida completo del desarrollo de software puede ser controlado por sistemas de IA bien diseñados, dirigidos por desarrolladores que entienden cómo construirlos y ejecutarlos.
La respuesta a esa pregunta crece cada mes. Y las personas que construyen hacia esa respuesta ahora mismo están trabajando con una ventaja que se acumula silenciosamente y se vuelve muy difícil de cerrar una vez que se vuelve lo suficientemente grande.
Todavía estamos en los primeros capítulos de esto. Las decisiones que se tomen en los próximos dos o tres años importarán durante mucho tiempo después.
