29 de marzo de 2026 # La primera profesión que ya ha cambiado: el desarrollador de software  Quinto artículo de la serie sobre _trabajo cognitivo en la era de la IA_ Hace unas semanas, en una demo en la oficina, una compañera sacó su entorno de GitHub y abrió el panel de asignación de tareas de un proyecto. Había cuatro miembros en el equipo: ella y tres agentes de IA (Copilot, Claude y Codex). Ella asignaba issues. Los agentes los recogían y empezaban a trabajar de forma autónoma. Mientras tanto, podía abrir el razonamiento interno de cada uno, ver qué decisiones estaban tomando, qué alternativas evaluaban. Si algo no le gustaba, intervenía, corregía, redirigía. Los propios agentes comentaban en los hilos del repositorio, explicando su entendimiento del problema y los cambios propuestos. La zona de comentarios parecía la de un equipo humano colaborando en serio. Eso no es ciencia ficción ni una demo de laboratorio. Es el estado del arte en desarrollo profesional de software, hoy. ## De escribir código a dirigir agentes  Hasta hace poco, el trabajo de un programador consistía fundamentalmente en tres cosas: escribir código, leer código y modificar código. La mayor parte del tiempo se iba ahí. Pensar la solución, implementarla línea a línea, depurar errores, adaptar lo existente. Ese modelo está cambiando rápido. Hoy, una parte creciente del trabajo consiste en definir qué hay que hacer, pedirle a un agente que lo ejecute y revisar si el resultado es correcto. La interacción con el código sigue existiendo, pero cada vez se parece más a supervisión y menos a escritura directa. Es un cambio sutil cuando lo miras de cerca, pero bastante profundo cuando lo piensas desde la estructura del trabajo. El desarrollador pasa de ser quien ejecuta a ser quien define y valida. Y eso son dos trabajos distintos, con habilidades distintas. ## Un rol diferente, no solo más rápido  Lo interesante de este cambio no es que se produzca más código en menos tiempo. Eso es la consecuencia visible, pero no es lo importante. Lo importante es que el tipo de persona que necesitas ser para hacer bien este trabajo ha cambiado. Antes, un buen desarrollador se distinguía por su capacidad de escribir soluciones elegantes, depurar problemas complejos y mantener en la cabeza la estructura de un sistema mientras trabajaba en sus detalles. Ahora necesita, además, saber descomponer un problema en tareas que un agente pueda ejecutar, evaluar si lo que el agente ha producido es robusto o simplemente parece correcto, y detectar cuándo una solución generada automáticamente ha tomado un atajo peligroso. Eso requiere criterio técnico, pero de otro tipo. Ya no se demuestra escribiendo código, sino juzgando código. Y ahí hay una trampa que conviene ver con claridad: si alguien sin criterio técnico suficiente intenta hacer de gestor de agentes, puede aceptar soluciones que parecen correctas pero que no aguantan una revisión seria. La producción sale, pero la calidad es invisible hasta que algo se rompe. Es exactamente el dilema entre productividad y competencia que describíamos en el segundo artículo de la serie, pero aquí ya no es teoría. Está pasando. Hay desarrolladores que producen más que nunca y que, al mismo tiempo, entienden peor lo que están construyendo. ## Esto va más allá del software  Si solo fuera un cambio dentro del sector tecnológico, sería interesante pero limitado. Lo relevante es que este patrón tiene todas las características de algo que se va a extender. El software ha sido el primer caso porque es el dominio donde las herramientas de IA han madurado antes. Los modelos de lenguaje entienden código con bastante precisión, los ciclos de feedback son rápidos (el código funciona o no funciona) y la comunidad de desarrolladores adopta herramientas nuevas con naturalidad. Pero la dinámica de fondo es la misma que veíamos en los artículos anteriores: la ejecución se abarata, las herramientas se vuelven invisibles y el valor se desplaza hacia quien sabe definir el problema y validar la solución. Pensemos en la consultoría, por ejemplo. Un consultor hoy dedica una parte importante de su tiempo a producir el entregable: el informe, la presentación, el análisis. ¿Qué pasa cuando un agente puede generar un primer borrador razonable a partir de los datos y el contexto? El consultor pasa a ser quien define qué preguntas hay que responder, juzga si el análisis tiene sentido y decide qué merece llegar al cliente. Es el mismo desplazamiento: de ejecutar a supervisar. Y requiere las mismas condiciones: entender de verdad la materia para poder juzgar lo que produce la máquina. ## Una señal para todos los demás  El desarrollo de software funciona como un laboratorio adelantado. Lo que observamos ahí nos da pistas bastante claras sobre lo que viene en otras profesiones cognitivas. Si eres consultor, analista, abogado, diseñador o cualquier profesional cuyo trabajo implica pensar y producir algo a partir de ese pensamiento, el caso del desarrollador debería resultarte familiar. Porque la pregunta que ya se están haciendo los programadores es la que te vas a hacer tú dentro de poco: **si la máquina puede ejecutar gran parte de mi trabajo, ¿en qué consiste exactamente lo que yo aporto?** La respuesta, como en toda esta serie, tiene que ver con el criterio. Con la capacidad de entender lo que se está haciendo, de detectar lo que está mal aunque parezca correcto, y de tomar decisiones que requieren comprensión real del problema. Y si esa comprensión no se mantiene activa, se pierde. Da igual lo buenas que sean las herramientas. --- Publicado el 29 de marzo de 2026, [LinkedIn](https://www.linkedin.com/pulse/la-primera-profesi%25C3%25B3n-que-ya-ha-cambiado-el-de-david-hurtado-tor%25C3%25A1n-yn1ze), [Substack](https://open.substack.com/pub/davidhurtado/p/la-primera-profesion-que-ya-ha-cambiado?r=4uyjfg&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true), [X](https://x.com/dhtoran/status/2038159092632387847?s=20)