Hay una etapa del trabajo con IA por la que pasa casi todo el mundo. Usted descubre que un modelo puede producir un primer borrador útil, responder una pregunta mejor que un buscador o resumir un documento en segundos. Lo integra en su flujo de trabajo. Gana velocidad. Funciona.
Nosotros también pasamos por esa etapa — y pronto nos topamos con algo para lo que esa etapa no prepara.
El problema del contenido
El canal de YouTube producía contenido Agile. Un video al día. Y el contenido Agile tiene una dificultad específica: casi toda IA ha sido entrenada con un corpus que entiende Agile de manera profundamente equivocada.
El problema no es que los modelos sean incompetentes. El problema son los datos de entrenamiento. Durante décadas se han escrito libros, blogs y guías de certificación sobre las “metodologías Agile” — una expresión que es en sí misma una contradicción, ya que Agile es una mentalidad, no una metodología. Esos textos son detallados, abundantes y están seguros de sí mismos al equivocarse sobre lo que Agile realmente es. Y los modelos lo han absorbido todo.
Así que usar IA para escribir contenido Agile significaba nadar constantemente contra la corriente de todo aquello que los modelos habían sido entrenados para decir. Pida un borrador sobre los valores Agile y obtendrá algo estructurado, fluido y sutilmente desviado — que presenta Agile como un conjunto de prácticas que adoptar y no como una forma de pensar el trabajo complejo.
Cada resultado exigía curaduría. Cada borrador había que leerlo contra la tesis real: que la mentalidad Agile es lo que importa y que las prácticas existen para sostenerla — no al revés.
Lo que la curaduría reveló
Aquí fue donde el patrón de copiar y pegar empezó a mostrar sus límites reales.
La IA de copiar y pegar es una carrera de relevos en la que usted es siempre el testigo. Toma el resultado de un modelo, lo evalúa, lo ajusta, lo pasa al siguiente, y vuelta a empezar. Para tareas simples, el relevo es rápido y los resultados son aceptables. Para tareas complejas — aquellas en las que la respuesta no es evidente, en las que el encuadre importa, en las que hay que corregir activamente los supuestos incorporados del modelo — el relevo se convierte en el trabajo.
La carga de curaduría creció a medida que el contenido se volvía más preciso. Explicar la distinción entre Agile-como-mentalidad y Agile-como-prescripción exige sostener una posición clara frente a un peso contrario muy grande en los datos de entrenamiento. Exigía rebatir los valores por defecto que el modelo daba por seguros, explicar por qué el encuadre habitual era erróneo y luego dirigir el resultado hacia algo más exacto.
Con el tiempo ocurrió algo interesante. Los modelos aprendían — dentro de una conversación, una vez explicada la posición y atendida la objeción, el modelo podía cambiar. Claude podía sostener la distinción en cuanto entendía por qué importaba. ChatGPT podía reformular en cuanto entendía el argumento.
Y a veces los modelos rebatían, lo cual también resultaba útil. Una objeción bien razonada del modelo obligaba a articular la posición con mayor claridad. El desafío afinaba el pensamiento.
El límite del enfoque
El límite no era la capacidad. El límite era la estructura.
Cada idea que surgía en una conversación había que llevarla a mano a la siguiente. Cada corrección de los valores por defecto del modelo había que restablecerla cada vez. El entendimiento compartido que se formaba a lo largo de una buena sesión no persistía — había que reconstruirlo.
Y el relevo entre modelos — que producía resultados demostrablemente mejores que cualquiera de los dos por separado — pasaba por una sola persona. Cada mensaje intermediado a mano. Cada síntesis ocurriendo dentro de una sola cabeza.
Ese fue el momento en que el modelo de copiar y pegar dejó de ser suficiente. No porque dejara de funcionar, sino porque lo que intentábamos hacer había crecido más allá de lo que podía sostener. La pregunta empezó a asomar: ¿cómo es la estructura cuando el relevo ya no es manual?
Comentarios 0