El fin del ingeniero de apps: Por qué la próxima década pertenece a los constructores de agentes
Nos encontramos en un punto de inflexión histórico, comparable a 1999 o 2009. La era de las aplicaciones estáticas se desvanece; la era de los agentes autónomos ya está aquí. Si no eres capaz de construir un agente que tome decisiones, podrías quedarte obsoleto mucho antes de lo que imaginas.

La historia tiene una curiosa manera de rimar, generalmente justo cuando nos ponemos cómodos.
Imagínate finales de los 90. Si sabías pelearte con HTML y un poco de Perl o PHP para crear un sitio web funcional, eras un mago. Eras un Ingeniero Web y el mundo estaba a tus pies. Construías los escaparates de internet.
Avanzamos rápido hasta 2009. El iPhone acababa de abrir el mundo en dos. De repente, a nadie le importaba tanto tu sitio web estático. La energía se desplazó hacia Objective-C y Java. Si eras un Ingeniero de Apps Móviles, estabas escribiendo el futuro. Construías las herramientas que la gente llevaba en sus bolsillos.
Ahora, mira el 2024. El aire se siente denso y estático de nuevo. Las tiendas de aplicaciones están saturadas; la web está abarrotada. Pero bajo la superficie, está ocurriendo un cambio tectónico. Estamos dejando la era de la Interfaz y entrando en la era del Agente.
En la próxima década, el título más valioso no será "Desarrollador Full Stack" ni "Ingeniero iOS". Será Ingeniero de Agentes de IA.
El Nuevo Cambio Tectónico
Esto no es solo otra guerra de frameworks o un nuevo lenguaje de programación que aprender. Este es un cambio fundamental en quién hace el trabajo.
Durante los últimos veinte años, la ingeniería de software consistió en construir caminos claros y deterministas para que los humanos hicieran clic. Tú construías un botón; el humano hacía clic; el código ejecutaba una función. El humano era el cerebro; el software era el músculo.
Esa dinámica se está invirtiendo.
En la Era Agéntica, el software proporciona el cerebro. Tu trabajo ya no es construir el botón para que el humano haga clic. Tu trabajo es construir el empleado digital que decide cuándo hacer clic en el botón o, mejor aún, descubre que el botón ni siquiera es necesario.
Llevo más de diez años creando productos y puedo sentir cómo se mueve el suelo. Si puedes escribir un agente hoy —uno que te sirva a ti, automatice tu flujo de trabajo o sirva a tus clientes— tienes el mismo apalancamiento que ese chico en 1999 que acababa de aprender a poner un negocio en línea.
Pero aquí está la dura verdad: Si te niegas a aprender esto, si te aferras a la codificación puramente determinista, corres el riesgo de convertirte en el equivalente digital de un tipógrafo en la era de la autoedición.
Desmitificando la Magia: Herramientas y Contexto
Cuando la gente escucha "Agente de IA", se imaginan a Skynet o alguna arquitectura de red neuronal imposiblemente compleja. Vamos al grano y eliminemos el ruido.
Construir un agente no es magia. Es ingeniería. Y se reduce a dos cosas: Herramientas y Contexto.
He descubierto que la mayoría de los desarrolladores complican esto demasiado. Creen que necesitan entrenar modelos. No es así. Los modelos —Claude, GPT-4, Llama— ya son lo suficientemente inteligentes. Tu trabajo es darles manos y memoria.
1. Herramientas (Dándole Manos al Modelo)
Un Modelo de Lenguaje Grande (LLM) es solo un cerebro en un frasco. Puede pensar, pero no puede tocar el mundo. Un "Agente" es simplemente un LLM al que se le ha dado acceso a endpoints de API o comandos de CLI.
Tú le dices al modelo: "Aquí tienes una herramienta llamada list_files. Aquí tienes una herramienta llamada read_file. Aquí tienes una herramienta llamada send_email".
2. Contexto (Dándole Dirección al Modelo)
Luego defines el rol. "Eres un ingeniero de QA senior. Tu objetivo es arreglar los errores de tipado en este repositorio".
Eso es todo. Ese es el bucle central.
Si has usado Cursor o Claude Code, has visto esto en acción. No microgestionas las ediciones. Dices: "Arregla los errores de tipo en utils.ts".
El agente piensa: Vale, necesito ver el archivo primero. Decide usar la herramienta ls. Luego decide usar grep o read. Detecta el error. Decide escribir la corrección. Ejecuta el compilador para verificar su trabajo.
Este es el gran avance. Ya no es solo "chatear". Es un bucle de decisión. El modelo está eligiendo qué herramientas tomar para resolver el problema que le diste.

De Chatbots a Motores de Decisión
Durante los últimos dos años, hemos estado atrapados en la fase de "Chat". Tratamos a la IA como a un bibliotecario inteligente: hacemos una pregunta, nos da una respuesta.
Esa fase está terminando.
La fase Agéntica trata sobre la ejecución. Se trata de mirar una CLI no como un lugar para que tú escribas, sino como un patio de recreo para el modelo.
Piensa en las implicaciones para las startups. En el pasado, si quería construir un servicio para gestionar reembolsos de clientes, necesitaba construir una UI (interfaz de usuario), un backend, una base de datos y contratar un equipo de soporte para hacer clic en los botones.
Hoy, puedo escribir un agente. Le doy acceso a la API de Stripe (Herramienta) y a nuestro historial de correos electrónicos (Contexto). Le doy una política: "Reembolsar si el usuario no está satisfecho dentro de los 7 días". El agente lee el correo entrante, decide si cumple con los criterios, activa la herramienta de reembolso de Stripe y redacta una respuesta.
No se necesita UI. No hay cola de tickets de soporte. Solo un objetivo y un conjunto de herramientas.
El "Desordenado Intermedio" de Construir Agentes
No quiero pintar una utopía aquí. He pasado los últimos seis meses en las trincheras de la construcción de agentes, y déjame decirte: es un lío.
La programación tradicional es lógica. Si X entonces Y. Funciona o se rompe.
La ingeniería de agentes es probabilística. Construyes el agente, le das las herramientas y, a veces, decide usar un martillo para abrir una ventana. A veces alucina un parámetro que no existe.
Aquí es donde reside el nuevo conjunto de habilidades.
Ser un Ingeniero de Agentes no se trata solo de scripts en Python. Se trata de:
- Ingeniería de Prompts como Arquitectura: Diseñar los prompts del sistema para restringir el comportamiento del modelo.
- Desarrollo Guiado por Evaluaciones (Eval Driven Development): No puedes escribir pruebas unitarias para la creatividad, así que construyes pipelines de evaluación para medir con qué frecuencia el agente tiene éxito en una tarea.
- Diseño de Herramientas: Crear interfaces de API que sean lo suficientemente "limpias" para que un modelo las entienda sin confundirse.
He visto agentes quedarse atrapados en bucles infinitos tratando de arreglar un bug que ellos mismos crearon. Los he visto borrar con total confianza el archivo equivocado. Esta es la realidad. Pero resolver estos puntos de fricción es exactamente donde se crea el valor.
Conclusiones Prácticas: Cómo Empezar Hoy
Si estuviera empezando desde cero hoy, o buscando pivotar mi carrera, esto es exactamente lo que haría:
- Deja de Construir GUIs: Al menos para tus proyectos secundarios (side projects). Intenta resolver un problema sin un frontend. ¿Puedes resolverlo con una CLI y un LLM?
- Aprende el Protocolo de Interfaz: Entiende cómo funciona el "function calling" de OpenAI o el uso de herramientas de Anthropic. Este es el TCP/IP de la era de los agentes.
- Construye un "Hacedor", no un "Hablador": No construyas un bot que responda preguntas sobre tu calendario. Construye un bot que gestione tu calendario. Dale la capacidad de borrar eventos. Siente el miedo de darle acceso de escritura a una IA. Ahí es cuando realmente empiezas a aprender.
- Domina la Gestión del Contexto: Aprende cómo meter la información correcta en la ventana de contexto sin desbordarla. RAG (Generación Aumentada por Recuperación) es solo el comienzo.
La Oportunidad que Tenemos Delante
Estamos mirando hacia un futuro donde un solo desarrollador, armado con una flota de agentes especializados, puede hacer el trabajo de una startup de 20 personas.
Las barreras de entrada para la creación están cayendo a cero. Pero las barreras de entrada para la orquestación —para entender cómo conectar estos cerebros entre sí— se están convirtiendo en el nuevo foso defensivo (moat).
Hace diez años, te contrataban para escribir el código. Hoy, te contratan para arquitectar el sistema que escribe el código.
El tren está saliendo de la estación. Puedes quedarte en el andén aferrándote a tus viejos frameworks, o puedes subirte y ayudar a construir las vías.
A construir.
Compartir esto

Feng Liu
shenjian8628@gmail.com