De consumidor a constructor

La primera forma de relacionarse con la IA es la natural: preguntas, recibes, repites. Abres el chat, escribes lo que necesitas, y en diez segundos tienes una respuesta. Es rápido, es útil, y si haces buenas preguntas, da bastante de sí.

Pero tiene un techo. Yo me lo encontré, y creo que casi todo el mundo se lo acaba encontrando:

1. Cada conversación empieza de cero. La IA no sabe que llevas tres semanas con un proyecto, ni cómo te gusta trabajar. Cada sesión es presentarte otra vez.
2. Siempre tienes que estar tú. Trabaja cuando la llamas. Cierras la ventana, se para. Puedes pedir, pero no puedes delegar.
3. El valor se evapora. Esa respuesta brillante de las once de la noche se pierde en el historial. No hay acumulación.

Te lo digo ya: estos techos se notan hoy mucho menos que hace un año. Los harness modernos, los Claude y Codex de turno, vienen de serie con memoria, skills, automatizaciones y loops de ejecución, y cada vez te resuelven más de esto sin que pongas esfuerzo. Pero el salto de mentalidad que te quiero contar sigue siendo el mismo, y es justo el que te deja aprovechar todo eso de verdad.

Durante mucho tiempo asumí que aquellos techos eran lo que había. Y luego, casi sin darme cuenta, crucé una línea.

El cambio de pregunta

El salto de consumidor a constructor no es técnico. Es cambiar la pregunta que haces:

En lugar de "¿cómo uso la IA para resolver este problema?", te preguntas: "¿cómo construyo algo que resuelva este tipo de problema, una sola vez?"

Parece poca cosa. No lo es. El primer síntoma de que estás cruzando es que empiezas a pensar en sistemas en lugar de respuestas: ves un problema que resuelves con el chat cada semana y piensas "esto no debería tener que pedirlo cada vez".

Cómo lo viví yo, en tres pasos

Primero, el contexto persistente. Lo primero que hice fue escribir en unos cuantos ficheros quién soy, en qué estoy, cómo decido. Suena tonto. El efecto no lo es: el agente dejó de necesitar que le explicara mi vida en cada sesión y empezó a dar respuestas que parecían entenderme. No porque el modelo mejorara, sino porque el contexto mejoró. Esto, por cierto, fue más difícil de lo que esperaba: te obliga a saber qué quieres, y eso no siempre lo tienes escrito ni en la cabeza.

Segundo, la primera automatización. Pasar de "pide y recibe" a "diseña y confía". En mi caso fue un resumen matutino: cada día, sin pedirlo, un mensaje con lo que pasó, lo que toca, lo que llegó. La primera vez pareció magia. No lo es: es una tarea programada y unas instrucciones bien escritas. Pero la experiencia es completamente distinta a abrir el chat y preguntar.

Tercero, delegar de verdad. Este es el paso que más me costó, y el más raro de contar. Llegó un punto en el que dejé tareas preparadas para que un agente avanzara con ellas sin mí, con sus límites, sus verificaciones y revisión mía al final. La primera vez que me encontré trabajo hecho que yo no había iniciado, mi reacción fue ir a comprobarlo. No por desconfianza... bueno, sí, por desconfianza. Estaba bien. Esa mezcla de "esto es rarísimo" y "esto está bien" es la línea. Antes de eso usaba IA. Después, tenía un sistema.

Lo que te va a pedir a cambio

No es gratis, y prefiero contarlo claro:

Escribir cómo piensas. Con el detalle suficiente para que alguien que no te conoce pueda actuar en tu nombre sin hacer el ridículo. Es la parte más difícil y la más útil: aunque no montes nada, salir de aquí sabiendo qué quieres ya compensa.

Aceptar la ambigüedad (y acotarla). Los LLM son no deterministas por naturaleza: la misma petición puede darte hoy una salida y mañana otra. Eso no es un fallo, es su forma de funcionar, y pelearte con ello solo te va a frustrar. El trabajo de ingeniería está en otra parte: primero, conocerlo. Y segundo, acotarlo todo lo posible. ¿Cómo? Con guardarraíles que limiten por dónde se puede mover el agente, con verificación y validación en cada paso que importe, y dejando en manos de procesos deterministas (scripts, tests, comprobaciones de toda la vida) todo lo que pueda serlo. Y para lo que aun así se escape: revisión antes de aplicar nada importante, registro de lo que pasó y posibilidad de deshacer. No se trata de evitar todos los errores. Se trata de que, cuando lleguen, salgan baratos.

Invertir antes de ver resultados. Un buen prompt te da una respuesta en 30 segundos. Un sistema puede costarte un fin de semana, o bastante más si lo quieres bueno y bien definido. La curva se invierte después: el sistema trabaja cuando tú no estás. El prompt no.

Esto ya no es solo cosa de informáticos

Y aquí va la parte que resulta un poco incómoda para los de mi gremio: en esto del criterio entra hoy muchísima más gente de la que entraba cuando construir exigía saber programar. Cada vez lo veo más claro: alguien que no sabe (ni quiere saber) lo que es tirar una línea de código puede llegar a montar un producto en el que no se note la diferencia. Porque el criterio lo pone la persona, y el saber hacer lo pone el modelo.

¿Dónde queda entonces el conocimiento técnico? Pues mira, no lo termino de ver, y prefiero decírtelo tal cual: creo que va a seguir haciendo falta gente que sepa, pero ya no sé decirte exactamente por qué ni para qué cosas. En lo que sí me mojo es en esto: si estás leyendo esto y no eres técnico, la barrera que te separa de construir es hoy más baja que nunca. Y sigue bajando.

Por dónde empezar

No hace falta nada sofisticado, y desde luego no hace falta el setup de nadie (el mío incluido).

Identifica el problema que resuelves con IA al menos dos veces por semana. No el más importante: el más repetitivo. Escribe las instrucciones que le darías a un colaborador nuevo para hacerlo en tu lugar. Guárdalas donde puedas reutilizarlas. Y cuando eso funcione, haz que se ejecute solo.

Eso es todo. De ahí se construye.

La diferencia entre usar IA y construir con IA se reduce a una pregunta: ¿quieres mejores respuestas, o quieres un sistema que trabaje en tu nombre? Las dos opciones son válidas, en serio. Pero solo una te devuelve tiempo.