El contexto es el nuevo código

Hay un punto de partida que hoy comparten todos los equipos de tecnología: la inteligencia artificial generativa es una realidad operativa. Los agentes de código, los asistentes en el entorno de desarrollo, los modelos corriendo en producción ya son moneda corriente. Y cuando algo se vuelve moneda corriente, cuando todos los competidores tienen acceso a las mismas herramientas, deja automáticamente de ser un diferencial.

Eso es lo que empieza a incomodar a quienes lideran equipos de IT. Lo que está pasando no es un cambio tecnológico más, de esos que la industria absorbe cada tanto. Es una reconfiguración de cómo se produce, se gestiona y se valora el trabajo técnico. Y si la herramienta ya no alcanza para distinguirse, ¿qué es?

Lo que aparece cuando uno mira de verdad

La primera respuesta llega cuando los equipos de IT dejan de suponer y empiezan a mirar con detenimiento el uso real de la IA en su trabajo. Ahí aparece un primer hallazgo: la diferencia de resultados entre una persona y otra, usando exactamente el mismo modelo, es enorme.

El problema central no es el costo del uso o la cantidad de tokens para una tarea, sino la falta de visibilidad sobre cómo se está trabajando y de criterio unificado para dirigir la herramienta en nuestros equipos de tecnología. Y cuando uno busca qué explica que unas personas le saquen más provecho que otras, la respuesta no está en el prompt puntual sino en todo lo que lo rodea.

El contexto como activo

Eso que rodea al prompt es lo que emerge con más fuerza cuando los líderes técnicos comparan lo que les funciona: los skills, las especificaciones, los patrones de arquitectura documentados, las decisiones y restricciones que una organización tiene escritas y disponibles. En una palabra, el contexto. Es el activo más difícil de replicar que un equipo puede construir hoy.

La lógica es contundente cuando se la mira de cerca. No es lo mismo poner a trabajar con IA a alguien que no conoce la arquitectura sobre la que está parado, que termina escribiendo veinte veces el mismo pedido, a los tropezones, que a alguien que dispone de marcos de contexto ya preparados y sabe dirigir el modelo con precisión. La consecuencia es casi paradójica: una tarea técnica simple, mal especificada, puede costar más y salir peor que una tarea compleja bien definida. La dificultad ya no está en el problema, sino en la calidad de la especificación.

Algunos equipos técnicos llevaron esta idea hasta el final y la volvieron método: la especificación deja de ser un paso previo al código para convertirse en el artefacto primario, el contrato que se escribe primero, se acuerda y gobierna cada decisión que viene después. El código pasa a ser una consecuencia de la especificación, no al revés. Es una inversión conceptual profunda. Durante décadas el código fue el producto y la documentación un accesorio que casi nunca se mantenía al día. Ahora el contexto es el producto, y el código, cada vez más, se deriva de él de forma iterativa y supervisada.

Por eso el contexto es el nuevo código. Las organizaciones que invierten en documentar bien cómo piensan y cómo deciden están construyendo una ventaja que no se compra con una licencia ni se copia de un día para el otro. Es un capital que se acumula.

La decisión no es técnica, es de criterio

Este desplazamiento cambia, de fondo, qué quiere decir ser técnicamente valioso. La IA hace hoy, con soltura, buena parte de lo que antes hacían las personas junior para aprender el oficio (código de baja complejidad, tareas repetitivas). Eso reordena toda la escalera de crecimiento profesional y obliga a repensar cómo se forma a alguien cuando el primer peldaño lo ocupa una máquina.

Pero el efecto más importante está en otro lado. Cuando el modelo no solo genera sino que encadena pasos, delega en herramientas y ejecuta acciones, la pregunta deja de ser técnica y pasa a ser de criterio: qué se automatiza del todo, qué se asiste y qué se mantiene, sí o sí, bajo juicio humano. Esa es la decisión que de verdad importa y no la toma la herramienta. La toma quien la conduce. Sus consecuencias impactan en la calidad, en la deuda técnica y en la cultura del equipo. Decidir bien qué queda bajo criterio propio es, hoy, la habilidad senior por excelencia.

Ese desplazamiento trae un costo nuevo, todavía sin solución clara. Cuando el modelo produce en minutos lo que antes llevaba semanas, el cuello de botella se traslada a quien tiene que revisar. La velocidad de generación no cambió la velocidad de lectura humana, sigue haciendo falta leer con la misma profundidad, pero ahora contra un volumen mucho mayor y en mucho menos tiempo. La herramienta acelera la producción, pero la responsabilidad de sostener la calidad no se aceleró. Ese desajuste es una de las tensiones más reales que enfrentan los equipos de tecnología.

Sostener algo que no se comporta como el software de siempre

Queda el examen más difícil, y es el que de verdad separa a los equipos maduros. Poner un modelo en producción es apenas el comienzo. Lo que viene después es mantener el control sobre algo que no se comporta como el software tradicional.

El cambio de naturaleza se vuelve tangible en el momento en que uno deja de pedirle al modelo que sugiera y empieza a dejar que ejecute. Cuando los agentes se conectan a sistemas internos y realizan acciones, el escenario cambia por completo. Aparecen problemas que el software tradicional no tenía: pedidos maliciosos incrustados en el contexto, información sensible que se filtra, dependencia de proveedores externos sobre los que no se tiene gobierno. Y la seguridad, que en casi todos los casos llegó tarde a la conversación (después de tener algo funcionando o después de un incidente), se revela como una capa que había que pensar desde el principio.

A eso se suma que las herramientas de medición de siempre dejaron de alcanzar. El monitoreo tradicional no ayuda, la latencia y el tiempo de actividad no dicen nada sobre si el modelo respondió bien o mal, sobre la calidad de su respuesta.

Nada de esto tiene todavía un manual. Y quizás esa sea la conclusión más honesta: estamos frente a una incertidumbre que no se resuelve en soledad ni comprando la herramienta correcta. Se trabaja conversándola entre pares, contrastando lo que a cada uno le funcionó y lo que no, dándole dirección a algo que ni siquiera los grandes jugadores que lo crearon tienen del todo claro. 

La herramienta se democratizó y está al alcance de todos. Lo que no se democratiza, lo que cada organización tiene que construir con paciencia, es el contexto, el criterio y la gobernanza para convertir esa herramienta en ventaja. Ahí, y ya no en el código, se juega la próxima diferencia.