La mayoría de los desarrolladores todavía usan la IA de la misma manera que usaban ChatGPT en 2023.
Abren un chat. Hacen una pregunta. Copian algo de código. Lo pegan en el editor. Repiten.
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 en este momento. No están usando la IA como asistente de codificación como lo hacen 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 la verdadera palanca 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 constantemente en diferentes formas.
¿Qué modelo es mejor?
Claude contra GPT. GPT contra Gemini. Gemini contra DeepSeek. Código abierto contra propietario. Todos comparando benchmarks, puntuaciones de codificación, ventanas de contexto y evaluaciones de razonamiento como si el modelo en sí fuera donde termina la competencia.
Esa conversación se está volviendo menos importante de lo que quienes la tienen creen.
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 a pedido. Un sistema de ingeniería real que sea 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 benchmarks.
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 por completo 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 solían estar listos para producción con edición mínima.
Por un tiempo, pareció que toda la industria estaba corriendo 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 trabajo real, 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 incompletos o contradictorios; investigar soluciones en una base de código que tiene años de historia y decisiones incorporadas; tomar decisiones arquitectónicas que se convertirán en ventajas o en deuda técnica según lo bien pensadas que estén; gestionar esa deuda técnica una vez que se acumula; probar casos extremos en los que nadie pensó 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, 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 con precisión porque la diferencia es fácil de subestimar.
En lugar de tratar a la IA como algo a lo 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 como una distinción sutil. No es nada sutil.
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 la verdadera palanca en la ingeniería.
Los desarrolladores que más provecho están obteniendo de Claude Code hoy no son los que escriben los prompts individuales más inteligentes. Son los que construyeron los sistemas más pensados 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, historial del proyecto, estándares de codificación, registro de decisiones arquitectónicas previas ni conocimiento de los errores que ya se han encontrado y corregido. Ese ingeniero tendría enormes dificultades. No porque sea incapaz. Sino porque está operando sin el contexto que hace útil la capacidad.
Los modelos de IA enfrentan exactamente 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 exacto y obtener resultados que parecen provenir de herramientas completamente diferentes. Uno obtiene resultados genuinamente útiles y listos para producción. El otro obtiene resultados mediocres que requieren más corrección que el código original habría necesitado.
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 la producción mucho más que la capacidad bruta del modelo en su interior.
El contexto se está convirtiendo en la nueva infraestructura
La mayoría de las discusiones sobre IA se centran en los prompts porque los prompts son la capa visible. Es lo que escribes. Es lo que ves. Se sienten como lo que estás controlando.
Pero los prompts son solo la superficie.
Debajo de cada flujo de trabajo de IA consistentemente exitoso hay 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 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 saca a la superficie la información correcta en el momento adecuado sin abrumar al modelo con todo a la vez; orquestación de flujo 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 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 desarrolladores individuales que están construyendo estas capas hoy están, en efecto, construyendo 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 agéntico y por qué refleja cómo se construyen los grandes equipos
Hacia aquí 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 que son profundamente hábiles 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 puede salir mal de formas que escapan a los ingenieros centrados en el producto. Ingenieros de QA 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 agéntico bien diseñado hoy podría pasar por 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 extremos, luego un Agente de Seguridad que revisa las 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 enfoca 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 de su tiempo creando prompts individuales. Pasan su tiempo diseñando flujos de trabajo. El prompt 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 importar más que la capacidad del modelo
Este es el cambio que la mayoría de la gente no se está tomando 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á estrechando. Los benchmarks entre los modelos punteros 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 y 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 visionarios se están enfocando fuertemente en la persistencia de sesión 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í mismo 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 vuelvo constantemente cuando pienso en dónde reside la verdadera ventaja.
Tres desarrolladores pueden usar el mismo modelo exacto de 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 ningún tamaño de equipo hace unos años.
La diferencia entre esos tres resultados no es inteligencia. Ni siquiera es esfuerzo, al menos no directamente. Es infraestructura.
El stack técnico ganador se parece cada vez más a un pastel de capas donde el modelo se asienta en la parte superior, visible y discutido constantemente, y todo lo que está debajo es donde reside la ventaja competitiva real. Memoria debajo del modelo. Orquestación del flujo de trabajo debajo de eso. Sistemas de evaluación que verifican los resultados. Controles de seguridad que definen límites. Automatización que elimina pasos repetitivos. Tuberías de ejecución que encadenan todo.
La mayoría de la gente solo se enfoca en la capa superior. Se enfoca 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 paralelo 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 agénticos como un experimento interesante o una mejora de productividad que vale la pena explorar cuando haya tiempo. Así es exactamente como se veía la computación en la nube en 2008 y 2009. La gente pensaba que podía seguir ejecutando sus propios servidores. Los desarrolladores que construyeron sobre infraestructura en la nube temprano parecían estar sobreingenieriando las cosas. Luego, la nube se volvió estándar y los que no habían hecho el cambio se quedaron 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 y el despliegue continuos. Cada cambio de infraestructura inicialmente parece un truco de productividad opcional para personas que tienen 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 tratando de ponerse al día.
El desarrollo agéntico sigue la misma trayectoria. Hoy es experimental y practicado por una minoría de desarrolladores que están desproporcionadamente entusiasmados con él. 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 mismo 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 estuvo 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 frameworks 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 adecuadas en cada etapa. Gestionar el contexto para que los modelos tengan lo que necesitan para rendir bien sin verse abrumados. Construir sistemas de evaluación que verifiquen los resultados antes de usarlos. Crear arquitecturas de memoria que acumulen conocimiento y mejoren con el tiempo. Coordinar agentes especializados que se centren cada uno en problemas específicos. Definir procesos de verificación que mantengan la calidad a medida que aumenta el volumen de producción. 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.
Eso 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 definición anterior 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 pasar por 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 a pedido 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 manejando 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 benchmarks en evaluaciones que pueden o no reflejar el rendimiento en el mundo real.
Esos debates son interesantes y no carecen completamente 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 agéntico. La estructura de cómo se construye el software está cambiando a un nivel fundamental, no solo volviéndose más rápida 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 del flujo de trabajo es donde reside la verdadera palanca. 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 manejado 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 están construyendo 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 es lo suficientemente grande.
Todavía estamos en los capítulos más tempranos de esto. Las decisiones que se tomen en los próximos dos o tres años importarán durante mucho tiempo después.
