Con la IA los programadores ya vivimos en SimCity

Si has jugado alguna vez SimCity, ya conoces a buen seguro algunas cosas de las que te voy a hablar. Si no, mejor échate una partida primero (aunque sea casual y en el móvil…) y luego vuelve por aquí a leer el post 😄

Si eres buen jugador de SimCity, te las arreglarás bien con la IA en los próximos años

Hay un momento en SimCity en el que dejas de intentar controlarlo todo al milímetro y empiezas a entender el juego.

No construyes las casas con tus propias manos. No conduces los coches de la gente. No llevas cubos de agua para apagar un incendio. Lo que haces es diseñar el sistema: zonas, infraestructuras, políticas, flujos… Y luego dejas que la ciudad funcione y crezca, ayudado por tus asesores. Tu papel es guiar y monitorizar todo, para intervenir y mejorar la ciudad (y ahí es cuando juegas y te diviertes, vaya)

Si en algún momento has liderado un equipo de ingeniería, estoy seguro que te suena.

Andy Grove (Intel) formuló la clave con precisión hace décadas: el output de un manager es el output de su equipo, más el de los equipos bajo su influencia. El manager no es el que más produce individualmente, es el que diseña el entorno donde otros producen más y multiplica su impacto.

Y estoy convencido que exactamente lo mismo aplica hoy al desarrollador que trabaja con agentes de IA. Tu rol es hacer que el sistema para desarrollar software en tu empresa funcione y produzca lo mejor posible.

El problema de la multitarea (propia)

La multitarea es una trampa bien documentada. El coste de cambio de contexto es real, el foco se fragmenta y el resultado final es siempre peor que si hubieras hecho una cosa a la vez.

Pero hay otro tipo de multitarea que nadie critica: la de los demás trabajando en paralelo para ti, de forma bien coordinada.

En SimCity, mientras tú lees un informe de tráfico, los bomberos apagan un fuego, los obreros terminan una carretera y los ciudadanos van al trabajo. No estás haciendo nada de eso en primera persona: tú estás pensando en el siguiente movimiento estratégico o bien atendiendo algún problema puntual urgente que solo tú puedes resolver.

Eso es exactamente lo que ocurre cuando tu equipo de software funciona bien. Y es exactamente lo que ocurre cuando los agentes de IA funcionan bien en tu proyecto: eres capaz de hacer más a la vez, porque delegas trabajo sustancial a los agentes de IA. Usa esa capacidad y los agentes, hasta el punto en el que sientas que controlas lo que haces (vigila tu carga cognitiva y nivel de energía), y esfuérzate en aprender cómo ampliar tu radio de impacto.

Gas Town y la IA

En SimCity es habitual, como en el Urbanismo en general, diseñar un distrito industrial, especializado en producir energía y recursos para el resto de la ciudad. De nuevo, tú no gestionas cada tubería o conducción eléctrica hacia él, solo te aseguras de que la zona esté bien conectada, financiada y sin conflictos con las zonas residenciales.

Y no creo que sea casualidad que a principios de 2026 Steve Yegge haya creado un software llamado Gas Town, un sistema para fabricar software con múltiples agentes IA orquestados, que pretender ser una alternativa a los IDEs tradicionales.

Gas Town sigue unos principios similares a SimCity: un alcalde que coordina a otros agentes (también antropomorfizados), hay factorías, refinerías... y tú trabajando con el sistema en un plano de control, necesariamente cada vez más abstracto y estratégico (como por otra parte siempre ha sucedido en el ámbito de la Informática).

Gas Town es (aún o tal vez será para siempre...) una herramienta bastante caótica y compleja y es una ciudad (perdón sistema) que gasta muchos tokens... Pero estoy convencido que varias de sus ideas guiarán las herramientas de creación de software en el futuro. Si te suena interesante, creo que merece la pena probarlo al menos y luego leer esta revisión crítica de Maggie Appleton, del área de innovación en GitHub: https://maggieappleton.com/gastown

El plano de control

En SimCity, el alcalde tiene un dashboard. No ve todo el tiempo cada tramo de tubería de gas, ve los indicadores que importan: tráfico, criminalidad, satisfacción ciudadana, presupuesto... Y actúa cuando algo requiere su atención directa e inmediata. Y probablemente el alcalde no se conforma con que su ciudad simplemente siga igual, sino que siempre tendrá uno o dos proyectos ambiciosos, para los que está preparando un plan y buscando financiación… así que trabaja en multitarea, repartido entre lo estratégico a medio largo plazo y lo operativo del día a día

Y yo en mi día a día como desarrollador siento algo parecido: interactúo con agentes de IA y compañeros, buscando esas señales correctas para actuar y a la vez mantener un buen equilibrio entre la multitarea y sacar bloques sólidos de trabajo (sea un plan para una nueva feature, un bug en producción o una actualización rutinaria de seguridad).

Actualmente uso herramientas variadas como la terminal con tmux (si algo en tech lleva casi 20 años vivo y la gente lo sigue usando, merece la pena echar un ojo, efecto Lindy en estado puro), Claude Code web / desktop, Craft Agents, MCPs contra Honeycomb, Postgres o Slack, y mi uso del IDE se ha reducido mucho (ahora uso Cursor, pero todos son similares)… pero siento que aún no he encontrado la configuración / herramienta ideal. Sigo buscando y se aceptan sugerencias, por cierto...

Estoy convencido que la industria de la IA y el desarrollo de software en general avanzarán en este plano de control pronto, es muy necesario.

Pero también estoy seguro que las señales para la acción, los dashboard de indicadores clave, mejorarán mucho con la IA: de simples dashboard técnicos con cientos de variables y gráficos no relevantes + dashboards de negocio con datos del trimestre pasado, a dashboards generados por agentes, con datos en tiempo real y mucho menos ruido y más señal:

• No "El sistema funciona".
• No "Hay 200 errores en el log", y búscate la vida...

Sino algo como "Esta es el Top 4 de los problemas de esta semana en tu SaaS", realizada con ayuda de agentes IA, por ejemplo:
- la latencia en la API XXX ha empeorado un 15% los últimos 10 días, y hay previsto el onboarding de un cliente grande a finales de mes, ¿arrancamos un proyecto de mejora?
- ¿Priorizamos la resolución de estos 5 bugs concretos, dado que afectan a 2 clientes con riesgo de churn que renuevan este mes?
- El tiempo medio de onboarding del último cliente ZZZ ha sido casi el doble de la media...¿ha comunicado algún problema concreto a customer success / ha habido algún bug o caída puntual de la plataforma que haya podido afectar a su experiencia?
- La competencia ha sacado esta feature el mes pasado, ¿merece la pena lanzar un prototipo rápido en nuestra plataforma para ver si somos capaces de incorporarla?

La crisis del programador, una cuestión de identidad

Hay algo de lo que quizá no se habla suficientemente en esta conversación sobre IA y el futuro del trabajo técnico: la identidad del trabajador inmerso en estos cambios. Tendemos a identificarnos con lo que hacemos: soy programador. Y cuando lo que hacemos cambia radicalmente, la pregunta se vuelve incómoda: si ya no programas línea a línea, ¿qué eres?

El término programador tiene un anclaje muy concreto y una tradición histórica amplia: escribir código todo el día. Si el código lo generan ahora los agentes, el anclaje se rompe. Y con él, parte de tu identidad. Por eso mucha gente se siente perdida, con pena o incluso miedo a los cambios de la IA.

Creo que se trata simplemente de abrir el foco y ver donde están ahora los verdaderos problemas, donde está "el juego". Y los problemas grandes ya no están tanto en programar algo o aprender un lenguaje para crear un sistema; están en planificarlo, diseñarlo con una visión humana y sobre todo comprobar que funciona y sacarle valor a escala.

Si necesitamos etiquetas, creo que hay otros términos que encajan mejor en esta etapa: ingeniero o simplemente desarrollador:

• ingeniero, en su sentido original, el de "ingeniárselas para resolver problemas".
• desarrollador: el creador de una solución técnica, de una idea de negocio... en definitiva de un sistema que funciona.

Los ordenadores nos dan la base para abordar problemas cada vez más complejos. Pero lo que importa es sobre todo lo que construyes, no el ritual específico o herramienta con la que lo construyes.

Creo que la IA no elimina al desarrollador. Elimina al programador cuyo valor está solo en teclear. El que sobrevive y prospera es el que entiende sistemas, toma decisiones y sabe orquestar las herramientas IA disponibles hacia un resultado tangible y útil.

Cuando lleguen los incendios...

Eso sí: prepárate. Porque de vez en cuando llegarán los incendios. En SimCity, los desastres no avisan. Incendio, terremoto, tornado o monstruo marino. De repente todo el sistema que habías diseñado necesita intervención directa, urgente y manual.

Con los agentes de IA pasa igual. Habrá momentos en que el contexto falle, la coordinación se rompa o el output sea basura. Y ahí tienes que estar tú, con las manos en el código y un conocimiento suficientemente profundo de lo que tienes entre manos, como para operar y corregir el sistema.

El objetivo no es desaparecer del sistema. Es tener el sistema lo mejor construido posible, y que tu intervención sea la excepción, no la regla.

Todo lo que vivimos ahora mismo en el mundo del software no es sino la avanzadilla de lo que en breve inundará toda profesión y no creo que tenga sentido tenerle miedo o intentar postponer lo inevitable.

Una de las personas que más admiro en el mundo del software es Kent Beck (creador de XP, TDD...). Bueno, pues este señor, con 65 años no para de experimentar y publicar cómo trabaja cada día mejor con la IA (o como el la llama "the Genie") para potenciar su trabajo... así que no hay excusas.

Abraza el cambio que supone la IA, el impacto de lo que vas a poder hacer se va a multiplicar, no tengas miedo.