Tu IDE ya no es donde construyes

Este mes se lanzó una pequeña función que, en mi opinión, marca un giro más grande de lo que sugirió su anuncio. Mistral renombró su app de chat a Vibe y le dio un "Code Mode" donde conectas un repo de GitHub, arrancas una sesión de programación que corre en un sandbox aislado en la nube y —esta es la parte clave— el agente trabaja, abre un pull request y te avisa, «para que revises el resultado en lugar de cada tecla que lo produjo». Las sesiones corren en paralelo, siguen avanzando mientras tu máquina está apagada y pueden dispararse desde Slack, no solo desde un editor.

Lee esa última parte otra vez. Puedes arrancar trabajo real de software desde un mensaje de Slack. El lugar donde sucede la construcción acaba de dejar de ser el IDE.

El editor nunca fue sagrado — solo lo parecía

Durante toda nuestra carrera, «dónde programas» tenía una respuesta obvia: el editor. Es donde tecleabas, donde vivía el trabajo, la cabina de mando. Vibe, y las Automations de Cursor, y una ola de agentes en segundo plano lo están degradando sin hacer ruido. La versión de Cursor levanta una VM aislada en la nube, clona tu repo, trabaja en su propia rama y te entrega un PR para revisar. Una herramienta llamada Tembo convierte a Slack en la interfaz principal —describe una tarea en un canal y recibe de vuelta un PR listo para producción en el mismo hilo.

La forma que comparten todas: el build corre en otro lugar, en la nube, en paralelo, y vuelve a ti como un diff para juzgar. El editor pasa a ser un lugar donde quizá revises ese diff —no el lugar donde sucedió el trabajo. La cabina de mando se convirtió en una notificación.

Esto es «dirigir, no teclear» llegando a su conclusión

He escrito que mi propio trabajo pasó de teclear código a dirigir agentes que lo escriben. Lo que este mes hace concreto es el siguiente paso: una vez que estás dirigiendo en lugar de teclear, no necesitas estar sentado en el editor para hacerlo. Si el trabajo real es especificar la tarea y juzgar el resultado, entonces el disparador puede estar en cualquier parte —un mensaje de Slack, una CLI, un gestor de issues, un temporizador— y la salida siempre es lo mismo: un cambio para que lo apruebes.

Eso replantea todo el oficio. La unidad de trabajo deja de ser «una tarde en el editor» y pasa a ser «una tarea que delegué y un diff que revisé». Es el mismo movimiento que ir de aprobar cada paso a revisar el resultado, llevado hasta el fondo, a cómo trabajas físicamente: lanzas, el agente se parte el lomo en la nube, y vuelves a un resultado. Las teclas que lo produjeron ya no son asunto tuyo, igual que no lees el ensamblador que emite tu compilador.

Qué cambia realmente para ti

Algunas consecuencias se desprenden de esto, y vale la pena adelantarse a ellas:

• La especificación se vuelve la verdadera interfaz. Cuando disparas desde Slack y recibes un PR de vuelta, lo único que de verdad escribiste fue la descripción de lo que querías. Cuanto más clara sea, mejor el diff. Esto es la especificación siendo el artefacto, hecho literal —lo que escribes en el canal es el trabajo.
• Revisar se vuelve la habilidad principal. Si el agente escribe y tú juzgas, entonces tu rendimiento está limitado por qué tan rápido y bien puedes leer un diff, no por qué tan rápido tecleas. El cuello de botella se movió de la producción a la evaluación —invierte ahí.
• El paralelismo se vuelve normal, y peligroso. Las sesiones corren a la vez, mientras tu laptop duerme. Eso es apalancamiento, pero cinco agentes abriendo cinco PRs que ojeas a medianoche es exactamente cómo llega a main código sin revisar y sutilmente equivocado. Más construcción en paralelo significa que necesitas más disciplina de revisión, no menos.
• Los no desarrolladores también tienen un disparador. Cuando la interfaz es Slack, un PM o un ingeniero de soporte puede arrancar un cambio etiquetando al agente. Eso es poderoso y es un problema de gobernanza —alguien todavía tiene que ser dueño de lo que llega a producción.

La conclusión

No exageres con esto: el IDE no está muerto, y hay un montón de trabajo que todavía te quiere en el editor, con las manos en el código. Pero el centro de gravedad se está moviendo. El modelo mental por defecto —«construir software significa estar sentado en mi editor tecleando»— se está convirtiendo en una opción entre varias, y cada vez menos en la principal.

El cambio que vale la pena interiorizar es que dónde construyes se está desacoplando del editor, y qué haces se está deslizando de producir código a especificarlo y juzgarlo. Quienes se adapten más rápido serán los que se sientan cómodos lanzando trabajo desde cualquier parte y, más importante, revisando lo que vuelve como si importara —porque la única cosa que no se mudó a la nube es la responsabilidad por lo que se publica. Esa se quedó exactamente donde siempre estuvo: contigo.