Salirse del medio

El trabajo de un dev siempre fue estar en el medio: entre alguien que quiere algo y el producto digital que lo resuelve. Traducir deseos a software, con el código como herramienta.

Ese medio está desapareciendo. Y lo sano, creo, es salirse antes de que te saquen.

Este post es la prueba

Arriba está el audio. Son 26 minutos de pensar en voz alta, bastante caótico. Lo grabé, se lo pasé a Claude en la terminal y le pedí tres cosas: que lo transcribiera, que mi web tuviera un reproductor para escucharlo, y que armara este texto a partir de lo que dije.

La transcripción la hizo un modelo que corre en mi propia compu. El reproductor lo pidió Claude a mi fábrica: un sistema que armé para que los pedidos de software se conviertan en misiones. Cada misión corre en su propio entorno, con un agente que coordina y otros que programan, y tiene reglas que le di yo: qué puede decidir sola (mergear, publicar, verificar que quedó andando) y qué me tiene que preguntar. Esa misión programó el reproductor y lo publicó. Después Claude subió el audio y publicó el post a través de un acceso que mi web les da a los agentes.

Nadie me preguntó cómo quería el botón de play.

Hace dos años eso era un ticket, una reunión, un dev y una semana. Hoy es un audio y una tarde.

Pero que sea fácil no quiere decir que no haya trabajo. Hay dos trabajos, y los dos son míos.

El primero fue antes: armar la máquina. La fábrica, sus reglas, los permisos, que mi web tenga una puerta por donde un agente pueda publicar, que la transcripción esté a mano para cualquier proyecto. Nada de eso es el post, pero sin eso el post era una semana de trabajo.

El segundo es el criterio. Tuve que tener algo para decir. Tuve que leer la primera versión y darme cuenta de que era fiel al audio pero no decía lo que yo quería. Pedí que fuera más contundente, elegí qué versión me gustaba, vi en una captura que el título salía duplicado, pedí que las frases fuertes se destacaran. Cada una de esas cosas la resolvió un agente en minutos. Ninguna se le hubiera ocurrido sola.

Ese es, para mí, el trabajo de un dev hoy: disponer mecanismos para que el software se genere con más o con menos intervención, según lo que esté en juego. Este post estaba en el extremo fácil: un audio, un par de opiniones, unas cuantas idas y vueltas. Otros pedidos necesitan más de uno. Pero la pregunta es siempre la misma: dónde hace falta que esté yo, y dónde no.

Lo que muere y lo que nace

Lo que se termina es el trabajo de traductor. Todas las convenciones, los estándares y el conocimiento en el que se apoya un dev, junior o senior, un modelo ya los domina. El software típico (una base de datos con usuarios, relaciones entre entidades y una UI encima) es un problema resuelto. Aunque sea gigante. Aunque lo vayan a usar millones de personas.

Lo que nace es otro trabajo: armar y conducir la máquina que hace el software.

A un modelo no le falta saber programar; le falta orquestación.

Cuándo correr los agentes, con qué contexto, en qué entornos, con qué políticas y qué evals. Eso es software también, y es nuevo, y hoy ahí sí hay trabajo.

Por qué todavía no se ve

Hace un tiempo escribí sobre la paradoja de Wix: que algo sea técnicamente posible no quiere decir que llegue a la vida de la gente. Entre la tecnología y el producto hay un camino de adaptación, y lo recorren las empresas que hacen software. Recién cuando no les queda otra, el cambio llega.

Por eso hoy parece que no pasa tanto. Las empresas que viven del software recién están adoptando en serio lo agéntico, pero para hacer lo mismo de siempre: formularios y botones, con un asistente agregado. Nadie está cuestionando la idea de software. A las que ya tienen toda su estructura armada, además, no les conviene empujar un mundo donde esa estructura deja de ser especial.

Estamos en el ojo del huracán, que es el momento más confuso. Pero que no se vea no quiere decir que no esté pasando. Cuando esas empresas se adapten, van a necesitar una fracción mínima de la gente que tienen hoy.

Lo que queda cuando sacás lo operativo

Cuando le cedés lo operativo a la IA, le terminás cediendo cada vez más. Lo que le queda al humano es lo que hace bien: criterio, pensamiento crítico, decisiones.

Y ahí aparece algo incómodo: se nota mucho cuánta gente no decide nada. Lleva el mail de acá para allá, mueve el pixel, va a reuniones a acompañar lo que otro ya decidió. Lo que falta es gente que diga «esto tiene que ser así, porque así quiero que se use».

Yo también estuve en el medio, y me costó soltarlo. Es cómodo: es un lugar que conocés, que te pagan bien y donde sos necesario.

El aporte de un dev nunca fue escribir código. Era que lo que alguien quería existiera.

Si eso ya no necesita a alguien en el medio, quedarse ahí es defender la herramienta y olvidarse del objetivo.

Lo que sí sirve

Lo que traemos los que venimos del palo técnico no es solo saber de computadoras. Es una forma de pensar: metódica, estructurada. Diseñar el experimento antes de largarte (lo que antes era TDD y hoy son los evals) no es la norma en todas las industrias. Mucha gente lanza una idea al mercado y después lee los números como le conviene.

Esa forma de pensar sirve para conducir un sistema de agentes a buen destino, para entender a quien lo usa y para convertir su feedback en algo accionable. Eso no lo reemplaza un modelo; lo potencia.

Lo que no sirve es creer que uno sigue siendo indispensable en el medio.

Salirse

Salirse del medio es armar una máquina que recibe pedidos, los procesa, te involucra solo en lo que nada más vos podés decidir y llega a producción sola. Es lo que hizo este post.

La próxima vez que te pidan una feature, preguntate si tu trabajo es hacerla o armar lo que la hace.