Por qué explico los términos técnicos con palabras sencillas

En este blog tengo una pequeña costumbre: cuando escribo un término técnico, siempre añado una explicación justo al lado.

Por ejemplo, si escribo «separación de poderes», lo sigo de inmediato con «aquí: la práctica de distribuir la ejecución, la revisión y la aprobación entre agentes distintos». Si escribo «subagente (aquí: agente secundario que ejecuta tareas dentro de un sistema mayor)», añado una palabra para que alguien que no conoce el término pueda seguir leyendo sin perderse.

Esta es una de las pequeñas reglas de este proyecto. Internamente la llamamos la «regla de lenguaje simple» (aquí: explicar cada término técnico con palabras que cualquier persona pueda entender).

En este capítulo voy a hablar de esa regla en sí misma. Por qué nos tomamos el trabajo de poner esas explicaciones al lado.

Dónde se detiene el lector cuando solo hay términos técnicos

Si lo pruebas, lo compruebas: cuando los términos técnicos se acumulan uno tras otro, el proceso de «construcción de contexto» en la cabeza del lector se detiene.

Imagina una frase como esta:

«En este proyecto, el subagente (aquí: agente que ejecuta tareas) Copywriter genera el contenido según el SPEC (aquí: documento de especificaciones), y el Brand Voice Editor realiza la verificación de tono antes de que pase por el control de calidad (QA).»

Para alguien que trabaja en diseño e implementación todos los días, es una frase completamente normal. Pero para alguien que recién está comenzando a usar IA, se detiene justo en «subagente» — y ya no puede seguir.

Cuando después aparecen «SPEC», «Brand Voice Editor» y «control de calidad (QA)» — palabras que tampoco conoce —, entiende la estructura de la frase, pero no logra imaginar qué es lo que está pasando.

Esto no es un problema del escritor. Es que el lector tiene un conjunto de referencias distinto. Y cuando aparecen tres o más palabras desconocidas seguidas, la cabeza humana no piensa «lo busco después». Piensa: «este artículo no es para mí».

Yo también reaccionaba así cuando era el que leía esos artículos.

Por eso pongo las explicaciones al lado.

No se trata de agregar párrafos explicativos. Solo se trata de insertar una palabra justo después del término. De la forma: «subagente (aquí: agente secundario)», «cron (aquí: mecanismo que ejecuta tareas automáticamente en un horario fijo)», «Kill Switch (aquí: mecanismo de interrupción inmediata)». Solo con eso, el costo de seguir leyendo para alguien que no conoce el término baja considerablemente.

Para quién son esas explicaciones

Si soy honesto sobre la motivación detrás de esta regla, al principio no pensaba demasiado en el lector. La razón era más bien personal: «si escribo con claridad, a mí también me ayuda a organizar las ideas».

Pero mientras escribía, me di cuenta de algo. El acto de «explicar un término al lado» termina ampliando el rango de lectores que puedes alcanzar.

El perfil de lector que tengo en mente para este blog es alguien con un nivel de conocimiento en tecnología relativamente alto, pero para quien el mundo de los agentes de IA (aquí: sistemas donde múltiples inteligencias artificiales trabajan en conjunto) es territorio desconocido. Alguien de entre 30 y 40 años, responsable de sistemas en una empresa mediana o pequeña, que ya está usando IA pero que se enfrenta a la pregunta de «¿cómo gestiono varios agentes y quién se encarga de qué?».

Si acumulo términos técnicos, el lector se queda en «suena difícil» y no avanza.

Pero si agrego una explicación al lado, el lector piensa «ah, ya entiendo» y sigue.

Y lo que considero más importante es el siguiente paso: «yo también podría intentar esto».

Cuando lees un texto lleno de términos técnicos, en el mejor caso terminas pensando «qué interesante». Difícilmente llegas a «quiero probarlo yo también».

En cambio, cuando el mismo proceso está escrito con palabras comunes — «hice esto y pasó esto» —, algo se mueve. «A lo mejor yo también puedo intentarlo.»

Ese efecto se alinea con el propósito de este proyecto, así que lo hago de forma deliberada.

Lo que el escritor descubre: un chequeo de comprensión propio

Después de un tiempo usando esta regla, noté algo que no había anticipado.

Cuando intentas explicar un término técnico con palabras sencillas, se hace evidente hasta qué punto realmente lo entiendes.

Por ejemplo, está el término «aprobación pasiva» (aquí: mecanismo donde la ausencia de una orden de interrupción dentro de un plazo determinado equivale a una aprobación automática). Es una práctica que usamos en este proyecto.

Cuando intenté explicarla con una frase simple, al principio no me salió bien. Escribí «el método donde el silencio equivale a aprobación», pero algo en el matiz no cuadraba. Después lo reescribí como «aprobación por vencimiento de plazo: si no llega una orden de interrupción antes del límite, se considera aprobado» — y ya se acercó más.

A través de ese proceso, la intención con la que diseñé el mecanismo, su funcionamiento real y la precisión con que lo puedo articular en palabras empezaron a alinearse.

Dicho de otro modo: cuando puedo escribir un término técnico tal como está, sin explicarlo, a veces solo me estoy apoyando en la palabra — y quizás no lo entiendo tan bien como creo.

Después de darme cuenta de que «poder escribir algo difícil sin explicarlo puede estar ocultando una comprensión superficial», comencé a usar la regla no como algo «para el lector», sino como un «chequeo de mi propia comprensión».

En este momento, ese efecto secundario me parece incluso más valioso que el efecto principal.

Si realmente entiendes algo, deberías poder explicarlo con palabras sencillas.

Si no puedes, es una señal de que todavía te falta entender mejor — así que vuelves al diseño.

Esta regla funciona como ese ciclo de retroalimentación.