Workslop: cómo uso la IA para no dar más trabajo a los demás

Uso IA para investigar repositorios, preparar documentos, desarrollar software y revisar mi trabajo. Con esa ayuda puedo explorar alternativas y preparar una primera versión sobre la que trabajar. Antes de dar una tarea por terminada, reviso qué estoy entregando y qué necesitará hacer después quien reciba el resultado.

Una propuesta puede llegar con su análisis, sus fases y unas estimaciones detalladas sin que nadie haya comprobado si todo eso tiene sentido para el proyecto. Sin criterio profesional, sin contexto, sin validar: todo copia y pega. A quien la recibe le toca averiguar de dónde salen las tareas, qué información falta y si esos plazos se pueden cumplir. Antes de valorar la propuesta, tiene que hacer buena parte del análisis que esperaba encontrar en ella.

Eso es lo que me interesa del workslop: contenido generado con IA que aparenta estar resuelto y deja a otros el trabajo necesario para poder utilizarlo. Si además aumenta el volumen, las revisiones se acumulan en las personas que conocen el proyecto. Su trabajo espera mientras completan entregas ajenas.

El contexto lo tengo que trabajar yo

Antes de pedir una solución, aclaro qué queremos resolver, quién utilizará el resultado y qué condiciones debe respetar. En desarrollo, eso me lleva a investigar el comportamiento actual antes de modificarlo. Al preparar un texto, parto de las ideas que quiero explicar, del lector al que me dirijo y de las afirmaciones que necesitan contraste. Así tengo una referencia para valorar lo que la IA proponga.

Selecciono la documentación pertinente y dejo claras las restricciones y las decisiones que la herramienta no debe tomar por su cuenta. Si falta un dato que puede cambiar la recomendación, esa ausencia debe seguir visible durante el trabajo.

En una propuesta con estimaciones, por ejemplo, una cifra necesita un fundamento que pueda explicarse. Hay que saber qué incluye el trabajo, qué dependencias tiene y qué disponibilidad existe para hacerlo. La IA puede ayudar a descomponer tareas o señalar algo que se ha olvidado; confirmar que ese desglose corresponde al proyecto requiere conocerlo y aplicar criterio profesional. Si todavía falta una decisión que condiciona la duración, lo razonable es explicar esa dependencia y mantener provisional la estimación.

En mi trabajo con agentes procuro comprobar el enfoque antes de extenderlo. Empiezo por un caso pequeño pero completo, reviso si responde a la necesidad y solo después amplío el cambio. Trabajar así me permite cuestionar una decisión cuando todavía es manejable, antes de que se haya propagado por el código, las pruebas y la documentación.

La revisión puede obligar a volver a elaborar. Entregar exige decidir qué se puede utilizar y qué necesita todavía colaboración; seguir el recorrido no garantiza que no haya errores.

Ver a tamaño originalCerrar

La revisión tiene que poder cambiar el resultado

Utilizo la IA también para revisar. Puede ayudarme a encontrar una contradicción, proponer un caso que falta o cuestionar un supuesto. Pero pedir otra respuesta y recibir un «todo correcto» me dice poco si no sé qué se ha examinado. En mi propio trabajo editorial he tenido que corregir procesos de revisión que compartían los mismos supuestos que la generación y acababan aprobando errores que debían detectar.

Compruebo las afirmaciones en la documentación que corresponde, vuelvo a los requisitos y examino lo que realmente se ha producido. Con código, leo los cambios y reviso las pruebas por separado: necesito saber qué comportamiento demuestran y qué podría seguir fallando aunque estén en verde. Una prueba puede confirmar una interpretación equivocada con tanta facilidad como la implementación que acompaña.

Con un texto, leo la versión completa. Dedico una lectura al castellano y la precisión, y otra al argumento, la voz y la utilidad de lo que cuento. Esa segunda lectura debe permitirme retirar un apartado que repite lo anterior o rehacer una estructura que ordena los párrafos sin explicar mejor la idea. Después compruebo la página: también importan la legibilidad, las figuras y lo que encuentra quien la abre desde el móvil.

Tener un procedimiento no me hace inmune al error. Si una revisión deja pasar un problema, hay que corregir el resultado y entender qué no se comprobó bien.

Antes de entregar algo hecho con IA, tengo que entenderlo, poder explicarlo, validarlo y responder por su contenido.

Me sirve una pregunta: ¿puedo explicar qué propongo y por qué sin leer la respuesta de la IA? Puedo consultar un dato o una cifra, pero necesito poder reconstruir el razonamiento con mis palabras. Si no sé justificar una decisión, todavía me falta trabajo antes de darla por válida.

La recomendación que haría a cualquier profesional es que concrete sus comprobaciones según lo que vaya a compartir:

Antes de compartir el resultado

«Lo he revisado» debería poder explicarse con comprobaciones como estas.

• En una propuesta o unas estimaciones: comprobar el alcance, justificar los supuestos y revisar las dependencias con quienes conocen el trabajo. Distinguir esfuerzo y plazo: una tarea puede necesitar pocas horas y esperar días hasta que alguien pueda hacerla.
• En un documento o un análisis: contrastar los datos y las afirmaciones que sostienen la conclusión; comprobar que la recomendación se desprende de ellos y responde al encargo. Retirar el contenido que no ayude a entender o decidir.
• En código: comprender el cambio, probar el comportamiento esperado y los fallos relevantes, revisar cómo encaja en el sistema y dejar información suficiente para mantenerlo.

Compartir algo incompleto puede ser una buena forma de colaborar. Hay trabajos que necesitan conocimiento que otra persona tiene y yo no, y esperar a tenerlo todo resuelto impediría avanzar. La condición es hacer explícito qué se está pidiendo: una valoración del enfoque, ayuda con una duda o una revisión de algo ya comprobado. Quien recibe el trabajo necesita conocer su estado para saber qué hacer con él.

La empresa también decide cuánto trabajo queda pendiente

Ese cuidado individual necesita unas condiciones que lo hagan posible. Si una empresa pide más propuestas y más entregas porque ahora hay IA, pero no reserva tiempo para comprenderlas y revisarlas, está creando un incentivo para dar por acabado el trabajo demasiado pronto. Tampoco basta con exigir «revisión humana» si la persona asignada carece del conocimiento, el tiempo o la autoridad para devolver una entrega que no está preparada.

Yo empezaría por acordar esas condiciones de entrega y dejar claro que quien presenta el trabajo debe poder justificarlo. La formación debería ayudar a ejercer ese criterio en cada profesión, además de enseñar a utilizar las herramientas.

También daría espacio a decir que falta información o que hace falta ayuda. Si reconocer una duda se interpreta como rendir menos que quien produce un documento impecable en apariencia, es fácil que la incertidumbre termine escondida en la entrega. Dirección tiene que aplicar el mismo cuidado a lo que envía: una propuesta poco trabajada puede generar tareas para todo un equipo.

Al aumentar la producción, miraría qué está ocurriendo con quienes reciben el trabajo: cuánto pueden aprovechar, qué tienen que devolver, dónde se acumulan las revisiones y qué dejan de hacer para atenderlas. Si se acumula material, habrá que decidir qué merece revisarse y qué puede esperar antes de pedir nuevas entregas. Para valorar si la IA está aumentando la productividad, ese recorrido cuenta tanto como la rapidez del primer borrador.

Si en tu equipo las propuestas salen cada vez más deprisa y las revisiones se acumulan, podemos trabajar sobre ese proceso: qué debe aportar cada entrega, qué comprobaciones necesita y cómo repartir la revisión sin concentrar todo el trabajo pendiente en las mismas personas.