Parecer productivo en el trabajo
(nooneshappy.com)- La IA generativa permite la generación entre dominios, en la que una persona sin formación puede producir resultados de otra área especializada, y hace que un principiante parezca más productivo aunque no tenga el criterio para revisar el resultado
- En el trabajo aumentan los entregables que aparentan progreso, como código, sistemas de datos y documentos, pero se dan casos en los que el usuario no puede explicar cómo funcionan en realidad o en los que todo sale mal desde el esquema y los objetivos iniciales
- La IA rompe la relación en la que la calidad del entregable revelaba la capacidad de quien lo producía y crea una separación entre entregable y competencia, volviendo al usuario más parecido a un conducto que entrega resultados sin poder evaluarlos
- Los documentos internos y las actualizaciones se vuelven más largos porque su costo de generación baja, pero el costo de leerlos no disminuye, lo que hace más difícil encontrar la señal dentro de la organización y los convierte en una nueva forma de AI slop producida por gente asalariada
- La IA generativa es adecuada para borradores, ejemplos, resúmenes, lluvia de ideas y corrección cuando la persona sigue siendo quien toma la decisión final y puede dar retroalimentación rápida, y la capacidad de ofrecer trabajo confiable sigue siendo una ventaja competitiva para las empresas
El problema de los entregables de IA que parecen productividad laboral
- La IA generativa puede crear resultados que parecen entregables profesionales sin necesidad de experiencia, y el fracaso aparece en dos formas
- Cuando un principiante produce un resultado que parece más rápido o más sofisticado de lo que permite su propio criterio
- Cuando alguien que nunca recibió formación en un área produce entregables de otra área especializada
- La investigación previa se ha centrado sobre todo en medir la primera forma, pero la más peligrosa aparece como generación entre dominios, cuando una persona sin formación produce entregables de otro campo
- En canales públicos ocurre que un colega pega tal cual una respuesta que parece salida de Claude y actúa con seguridad como si dominara una tecnología que en realidad no entiende
- En este tipo de situaciones, la otra persona ya no parece estar realmente al otro lado de la conversación, sino que funciona más como alguien que retransmite la salida del modelo
Generación entre dominios
- Está ocurriendo que personas que no saben programar crean software, y que personas que nunca han diseñado sistemas de datos diseñan sistemas de datos
- La mayoría no se lanza, pero se comparte internamente con entusiasmo o se usa en silencio, y a veces termina expuesto ante clientes
- Hoy existen algunos profesionales que sí logran hacer bien tareas complejas con herramientas de tipo agente, pero son pocos y se ven sobre todo en el área de generación de código
- La capacidad individual con IA ha aumentado, pero no logra escalarse correctamente en el entorno laboral
- Un colega de un puesto no relacionado con ingeniería pasó dos meses a inicios de este año construyendo un sistema que debería haber sido diseñado por alguien con formación formal en arquitectura de datos
- Según los criterios actuales para evaluar el uso de herramientas de IA, las usó bien y produjo mucho código, documentación y entregables que a simple vista parecían progreso
- Sin embargo, cuando le hacían preguntas, no podía explicar cómo funcionaba realmente
- El esquema y los objetivos estaban mal desde el primer día, con errores que alguien con dos años de experiencia en esa área habría detectado
- Varias personas lo sabían y el tema llegó hasta nivel de V.P., pero la gerencia ya había invertido en la apariencia de impulso y no quería sacudirla
- La herramienta no lo convirtió en un peor colega; lo que hizo fue permitirle imitar de forma convincente durante meses un campo para el que no estaba entrenado
- Los incentivos de la organización se inclinan a que esa imitación continúe
- Puede tratarse de un fallo de gestión, pero la voluntad de la dirección de adoptar IA hace que se acepte el riesgo
- Esto podría mitigarse si el modelo evaluara con honestidad los entregables, pero en la práctica no ocurre
- El estudio de Stanford de Cheng et al., Sycophantic AI decreases prosocial intentions and promotes dependence, confirma que los principales modelos son cerca de 50% más complacientes que las personas y validan al usuario incluso cuando no hay fundamento
- Según Berkeley CMR en Seven Myths About AI and Productivity: What the Evidence Really Says, incluso usuarios con habilidades para aprovechar IA suelen sobreestimar su propio desempeño
- Según NBER en Generative AI at Work, la IA generativa elevó la productividad de agentes de soporte principiantes en alrededor de un tercio, pero casi no ayudó a los expertos
- Harvard Business School, en Navigating the Jagged Technological Frontier, encontró el mismo patrón en trabajo de consultoría
- Como resultado, los principiantes pueden aumentar su productividad individual en áreas fuera de su experiencia, pero siguen sin tener la capacidad de revisar si el resultado es correcto
El problema del conducto
- A este fenómeno se le llama cada vez más separación entre entregable y competencia (output-competence decoupling)
- Antes, la calidad del entregable solía ser una señal de la capacidad de quien lo producía
- El texto de un principiante sonaba a principiante, y el código de un principiante fallaba de maneras típicas de principiante
- La IA rompe esa relación y permite que un principiante produzca entregables que ya no revelan que es principiante
- La competencia que refleja el entregable no es la del usuario, sino la del sistema
- El usuario puede entregar el resultado al destinatario, pero se parece más a un conducto que no puede evaluarlo mientras lo transmite
- La capacidad de producir un entregable y la capacidad de juzgarlo siempre fueron distintas, pero el proceso real de hacer el trabajo ayudaba a desarrollar criterio
- La primera capacidad, producir el entregable, en buena medida pasó a la máquina
- La segunda, juzgarlo, sigue en manos humanas, pero cada vez hay menos personas que quieran aprenderla o ejercerla
- Antes, la crítica de una arquitectura venía de alguien que había sido formado o que ya había construido y roto sistemas parecidos varias veces
- Ahora esa crítica sale de un modelo que no tiene memoria encarnada de haber construido o roto nada
- La lentitud no era solo el costo asociado al trabajo real; era el propio proceso mediante el cual el trabajo mejoraba, las personas se volvían expertas y la empresa podía prometer cierto nivel de calidad a sus clientes
- La generación actual de sistemas de tipo agente está diseñada en torno a la premisa de que la persona es el cuello de botella
- Asume que, cuanto menos retraso haya por parte de una persona que lee y juzga lo que va a pasar, más rápido y limpio será el ciclo
- En muchos casos ocurre exactamente lo contrario: la persona en el ciclo no es un residuo del pasado, sino el único componente con intereses reales en el resultado
- Quitar a la persona del esquema de humano en el ciclo (HITL) no es optimizar, sino renunciar al único mecanismo que tiene el sistema para detectarse a sí mismo cuando falla
El AI slop interno
- Los documentos de trabajo se están alargando rápidamente
- Un documento de requisitos que antes tenía una página ahora tiene 12
- Una actualización de estado que antes eran tres oraciones ahora se convierte en un documento con viñetas que resume un resumen del resumen
- Retrospectivas, reportes de incidentes, notas de diseño, decks de arranque y cualquier otro entregable que pueda alargarse se está alargando
- El costo de producirlos cayó casi a cero, pero el costo de leerlos no disminuyó; de hecho, subió
- El lector tiene que filtrar contexto sintetizado para encontrar qué era lo que el documento realmente quería decir
- La decisión individual de alargar documentos parece racional y se recompensa de manera independiente
- Según Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling, los lectores sienten más confianza en explicaciones largas generadas por IA aunque eso no tenga relación con su exactitud
- Como resultado, encontrar la señal dentro del trabajo es más difícil que antes
- Los puntos de control quedan escondidos dentro de los documentos, y las personas terminan ahogadas en trabajo documental incluso cuando realmente quieren ser “concisas”
- Esta es una nueva forma de slop más costosa que la que se derrama en el mercado público
- Porque quienes la producen están cobrando un salario
- El trabajo que antes enseñaba criterio ahora lo hacen las herramientas, y los puestos junior donde se producía ese aprendizaje se reducen porque la herramienta puede hacer la tarea
- En muchas oficinas hay mucho movimiento, pero menos de los resultados reales que ese movimiento solía producir antes
- La discusión pública se ha concentrado sobre todo en el AI slop que llega al mercado abierto, y University of Florida en Generative AI and the market for creative content trata esa dinámica
- Pero la misma lógica también aparece dentro de las organizaciones
- Se invierte tiempo en trabajos que no necesitaban IA, en entregables que nadie leerá y en procesos que existen porque las herramientas permiten producirlos barato
- Cada vez es más común convertir en un deck cosas que antes ni hacía falta decir o que se daban por sentadas
Cómo responder
- La disciplina que hace falta en este entorno se parece mucho a la de antes
- La herramienta solo debería usarse donde se pueda verificar con precisión el resultado que produce
- No hay que pedirle al modelo que confirme nada
- La herramienta está de acuerdo con cualquiera, y un acuerdo que no le cuesta nada a quien lo da no tiene valor
- La IA generativa encaja bien en tareas donde la retroalimentación es rápida, donde basta con estar aproximadamente en lo correcto y donde la persona sigue siendo quien toma la decisión final
- Redacción de borradores de notas
- Generación de ejemplos
- Resumen de material que el lector pueda verificar si quiere
- University of Illinois en Generative AI Guidance y PLOS Computational Biology en Ten simple rules for optimal and careful use of generative AI in science recomiendan usos como estos
-
Lluvia de ideas
-
Corrección
-
Reformulación de las propias ideas
-
Detección de patrones en datos que uno ya entiende
-
- En todos los usos recomendados, la persona aporta el juicio y la herramienta aporta el rendimiento
- Esta es una postura más fuerte que simplemente mantener a una persona en el ciclo
- La herramienta debe quedarse fuera del trabajo y contribuir solo cuando se le invite; en lo demás, debería permanecer en silencio
- Esto va en dirección opuesta a hacia donde apuntan hoy muchos sistemas de tipo agente
- Para las empresas, la capacidad de entregar trabajo confiable sigue siendo una ventaja competitiva
- Cuanto más se conviertan los competidores en tuberías de generación de contenido esperando que el cliente no lo note, más valioso se vuelve el trabajo en el que sí se puede confiar
- Los problemas ya están saliendo a la superficie
- Deloitte reembolsó parte de una tarifa de 440 mil dólares relacionada con un informe gubernamental que contenía alucinaciones de IA
- El siguiente problema podría ser un sistema operativo basado en especificaciones alucinadas, o un ingeniero senior dándose cuenta de que durante el último año ha “revisado” nominalmente trabajo que en realidad no podía revisar bien
- Las empresas que sí hacen bien el trabajo pueden quedar en posición de ponerle precio a ese valor
- Las empresas que se vaciaron a sí mismas descubrirán que eso que vaciaron era exactamente por lo que sus clientes estaban pagando
- El malentendido y el mal uso de la IA en el trabajo están muy extendidos
- La experiencia recibe presión para entregar más rápido, producir más, integrar más a fondo las herramientas y no “bloquear” a colegas que “sacan el trabajo”
- Los entregables se acumulan, pero el trabajo no
- Del otro lado de esos entregables, un cliente puede abrir lo recibido, leer una lista de resúmenes y decidir revisarlo personalmente
1 comentarios
Opiniones de Hacker News
Me llegó mucho esto de la verbosidad inflada en los entregables del trabajo, donde un documento de requisitos que antes cabía en una página ahora termina teniendo doce
Me recordó cuando en la preparatoria alargaba a propósito lo que escribía para cumplir el mínimo de 1000 palabras en un ensayo, y ahora el formato profesional, la extensión y las frases claras ya no son señales de esmero ni de calidad
Así que el cuello de botella del aumento de productividad hoy en día siguen siendo las personas a las que todavía les importa lo suficiente como para revisar las cosas manualmente
Hoy incluso un documento de especificación de 10 a 30 páginas, lleno de formato y diagramas ASCII, puede ser en realidad poco más que una idea lanzada al aire, así que uno tiene que acostumbrarse a leerlo de esa manera
Mi gerente seguramente va a resumir o evaluar lo que le mando con un chatbot o un agente, pero si yo envío directamente el resumen, eso no se vale
Sería como necesitar un verificador de IA para mis textos, igual que el ATS para los currículums, y al final una IA terminaría parseando texto escrito por otra IA, lo que parece un desperdicio enorme de energía
Ojalá hubiera reglas, estructuras, estándares o procedimientos acordados para comunicarnos de forma más eficiente
Son producto de esos textos que alargan todo solo para subir en los resultados de búsqueda
La gente que manda eso de todos modos no va a dar seguimiento, así que el problema se resuelve solo
La situación que describen aquí se parece muchísimo a mi experiencia
En mi empresa hay muchos gerentes que llevan años sin escribir código, y el arquitecto que contrataron hace 18 meses diseñó todo con IA
Para los desarrolladores senior era obvio que todo estaba tremendamente sobrediseñado, pero como usaba toda la terminología correcta, a la alta dirección le parecía más competente que otros gerentes senior, y cuando lo cuestionaban respondía con ataques personales
Unos 6 meses después, varias personas se fueron y quienes se quedaron se volcaron por completo a la IA, y en los últimos 12 meses han estado construyendo flujos de trabajo tipo agente para llenar el vacío que dejaron los empleados competentes
El resultado es que en 18 meses no se ha lanzado nada valioso, y después de desperdiciar una gran cantidad de dinero en cómputo en la nube para una solución mal diseñada, ahora están recortando costos con congelamiento de contrataciones
Si la economía cambia mucho, es prácticamente como quitar una presa, y eso pone muchísimo más estrés sobre el resto del sistema
Si los líderes de una organización no ven esos posibles efectos secundarios y riesgos, pueden salir muy lastimados
Aunque esta tecnología se vendió como una mejora generalizada, da la impresión de que vamos a ver una explosión de empresas así estrellándose en el futuro
Las empresas que sobrevivan van a difundir cómo domesticar este caballo salvaje y, idealmente, en el futuro aprenderemos algo de todo esto
Pero el entusiasmo ingenuo de ahora es impresionante, y parece que por un buen rato seguiremos viviendo un septiembre eterno de gente emocionadísima con sus nuevas habilidades de vibe coding
Hace dos empleos, el vibe coding todavía ni era realmente práctico, pero algunos estaban tan obsesionados con usar LLM para inflar absolutamente todo que era difícil sacar una respuesta de sí o no a cualquier pregunta
A una pregunta de una línea en Slack, de 20 segundos, te respondían con un texto borroso de dos páginas, tipo blog, sin conclusión, y las preguntas de seguimiento solo desperdiciaban más tiempo
En mi último trabajo vi cómo el PM poco a poco se convertía en gerente de vibe coders
Se metía en las discusiones técnicas y dirigía cada paso con IA, y cuando le rebatíamos, terminábamos peleando contra el resultado traducido por IA de alguien que no entendía el tema, lo cual era agotador
Ya ni se permitía disentir, y nos presionaban diciendo que la IA amenazaba nuestros trabajos
Después hicieron obligatorio el vibe coding para todos y hasta vigilaban cuánto se usaba, y como ese PM hacía al mismo tiempo de PM, ingeniero y arquitecto, creó varios tickets para la misma tarea con requisitos completamente distintos entre sí
Entonces un integrante del equipo hacía vibe coding de una forma y otro implementaba otra completamente diferente
Fue durísimo ver cómo un equipo rentable de 20 personas, que generaba casi 100 millones de dólares de ganancia al año, se destruía con trabajo inútil y sin sentido, y al final me fui
Trato de no volverme cínico ante estos cambios en la industria del software, pero de verdad es difícil
Un gerente usa Claude con una comprensión incompleta del dominio para dar consejos y propuestas de experto, y varias personas no técnicas dentro de la empresa intentan crear herramientas internas de software que se desplegarán en toda la organización, buscando reconocimiento y recompensa con ese tipo de demos
Como era de esperar, la dirección se impresiona con esas pruebas de concepto y las aprueba
Colegas excesivamente proactivos muestran demos que parecen hechas por expertos aunque no entienden nada de lo que hay por dentro, y el liderazgo las compra
No sabía bien cómo expresar este problema, pero este texto lo retrata muy bien
Aunque claro, con IA sí ayuda a construir todavía menos
Suena a un ambiente bastante tóxico
Los equipos más productivos para hacer software de calidad usando LLM probablemente los usarán más o menos así
El autocompletado inteligente es el uso original de los LLM en desarrollo: el código generado se escribe manteniendo el contexto del código en el que está trabajando el desarrollador, como una extensión del proceso mental, no como una subcontratación del pensamiento mismo al LLM
En lluvia de ideas puede expandir conceptos, ideas o direcciones difusas de maneras nuevas para estimular la creatividad
Para resolver problemas, puede ser bastante útil al depurar conflictos entre paquetes, excepciones aleatorias o reportes de bugs, y ayudar a llegar a la causa raíz cuando no hay un compañero al lado
En revisión de código, a veces detecta algunas cosas que una persona pasó por alto, así que se parece más a una etapa de lint más inteligente, pero no reemplaza la revisión humana
En pruebas de concepto, puede generar distintos enfoques para un problema y servir de inspiración para una solución desarrollada con más cuidado
Estos usos aceleran el desarrollo mientras mantienen la responsabilidad de que el desarrollador sepa qué está construyendo y por qué
En cambio, los equipos que se van con todo por la codificación tipo agente parecen muy propensos a terminar dañando sin querer su producto y su equipo a largo plazo
Las últimas veces que pregunté, la respuesta fue perfectamente plausible pero completamente equivocada, e incluso fuera de tema
En revisión de código hay demasiados falsos positivos, y tampoco veo por qué eso vaya a mejorar
Aun así, sí parece haber potencial de ayuda en esa dirección
En lo personal, lo apagué hace como un año y volví al autocompletado tradicional del IDE de JetBrains
En mi experiencia, menos de 1% de las sugerencias de IA predecían exactamente lo que quería, quizá 10% eran útiles, y el resto simplemente estaban mal o eran molestas
Las funciones estándar del IDE para buscar o navegar rápido por métodos, variables y demás me resultaron mucho más útiles para convertir pensamientos en código
Mi equipo también probó varias herramientas, pero casi todo lo que señalaban era muy superficial o ni siquiera era un problema
Al revisar código de integrantes menos competentes, pasaban por alto problemas más profundos, y un revisor humano sí detectaba cambios incorrectos en problemas que podían resolverse mejor
El gerente usó esos resultados como evidencia para confirmar su propio sesgo de que nosotros no sabíamos lo que hacíamos
Pegaba en los comentarios del PR la salida llena de emojis de la herramienta de revisión de código, y cuando arreglábamos problemas menores publicaba “ronda 2 de code review”
La moral cayó muchísimo y algunos integrantes del equipo terminaron por rendirse con las revisiones y simplemente aprobar los PR
Está bien como herramienta para revisar tu propio código, pero no debería convertirse en una restricción obligatoria del proceso
El propósito original de la revisión de código era invertir tiempo para ayudarnos a mejorar mutuamente, y cuando subcontratas eso a una máquina, se rompe el contrato social dentro del equipo
Hace dos años decían que no era más que autocompletado puro y un Google mejorado
La gente pesimista con la IA sigue equivocándose año tras año, pero hace como si nunca hubiera dicho con total seguridad que la IA jamás podría hacer lo que hoy sí puede hacer
La ingeniería de software parece especialmente propensa a esto por varias razones
Muchos ingenieros de software nunca han hecho ingeniería de verdad en toda su carrera, y en las grandes empresas eso es todavía peor
Entran como un engrane pequeño dentro de una gran máquina, aprenden un lenguaje de configuración creado para que alguien más consiguiera un ascenso, ordenan y refactorizan esa configuración, y luego “arreglan” los resultados de otro framework interno ajustando perillas de configuración, y pasan cinco años haciendo eso mismo
También hay muchos puestos cuasiingenieriles en la industria
Personas a las que les gusta trabajar con gente y por eso dejaron de programar, o que se fascinaron con el producto y con el trabajo de los usuarios, llenan los puestos .*M en empresas grandes y pequeñas
En las grandes empresas el tren avanza lento: un commit puede tardar meses en llegar a producción, y seis meses no es raro
Muchos sistemas grandes e importantes ni siquiera han recibido todavía código tipo agente en producción
Entonces la IA reemplaza algunos puestos de adorno, la gente que rondaba alrededor del código de pronto disfruta el vibe coding, y en las empresas lentas los resultados todavía no explotan
Desde afuera parece un boom de productividad
La parte de “gente que no sabe programar construye software, y gente que nunca ha diseñado sistemas de datos diseña sistemas de datos” me hizo pensar en “cómo lanzar proyectos en una gran empresa tecnológica”
En particular recordé la parte de que “el lanzamiento es una construcción social dentro de la empresa. Más específicamente, un proyecto se ha lanzado cuando la gente importante de la empresa cree que ya se lanzó”
https://news.ycombinator.com/item?id=42111031
Era bueno, y también generó una discusión interesante sobre cómo mantener las apariencias y lo visible importan siempre, y a veces mucho más de lo que creemos
En las primeras etapas de la adopción de IA en el trabajo me di cuenta de que algunos colegas la usaban para mostrar exceso de iniciativa
Cada semana aparecía un nuevo TOD, una nueva idea de refactorización, o una nueva forma brillante de resolver un problema viejo con algún algoritmo reluciente
Ahora el fenómeno se duplicó, porque a los intentos de verse más proactivos se les sumó el miedo a despidos por IA, y están construyendo soluciones antes incluso de definir por completo el problema
Por ejemplo, me encargaron investigar cierto problema de arquitectura en toda la empresa, y pensé que si entregaba una solución sólida eso me daría reconocimiento, pero ya era demasiado tarde
El becario ya había encontrado una solución y escrito el TOD, y ahora ya estoy demasiado cansado como para competir
Ayer pasé casi todo el día borrando y reemplazando código generado por un LLM
En general la ayuda del LLM había sido buena, pero esta vez escupió una cantidad absurda de código con hilos, y por primera vez en años mi app empezó a crashear
Mis apps no crashean
Puede haber muchos otros problemas, pero ese no es uno de ellos, y soy bastante obsesivo con eso
Mi regla empírica es que casi nunca hace falta despachar a un hilo nuevo
Sí hay muchos casos donde dejas que el SDK del SO lo haga y respetas esa decisión, pero casi nunca ganas más de lo que pierdes en dolor de depuración lanzando tú mismo hilos de trabajo
Esto no aplica a todo tipo de aplicaciones, pero sí a las que yo hago
A los LLM les encantan los hilos, probablemente porque hay mucho código de entrenamiento subido por gente acelerada fascinada con tecnologías llamativas
Al final arranqué el código de pantalla y puse el mío, y el rendimiento mejoró de forma evidente y los crasheos se detuvieron
La lección es que el comprador se cuide solo
Me identifiqué con la parte de dudar si discutir con alguien que claramente está copiando y pegando directo desde el modelo
A veces hasta me ha dado una diversión pequeña responderles de la misma forma
Pego la salida de su IA en mi IA, luego pego mi respuesta de IA, y así sucesivamente
Dos humanos actuando como máquinas para que dos máquinas se comuniquen como humanos, una especie de cosplay
Fue glorioso
Ante una pregunta simple sobre mi dirección senior de por qué para una prueba de concepto entre amigos tenía sentido lanzar rápido con Vercel en vez de sobrediseñar con AWS, me respondió mandándome un diagrama revuelto hecho por IA
Estaba demasiado encerrado en el marco de que su hermano usa AWS y él también quiere una carrera por ese lado, así que en vez de pensar por sí mismo por qué ese enfoque tenía sentido para una prueba de concepto entre amigos, tercerizó el pensamiento en la IA
Me preguntó si lo había leído, y le dije que lo había leído resumido con IA, pero que no lo había respondido, y la conversación terminó muy rápido
Decir que “no ayuda a los expertos” es un poco miope
Por muy bueno que sea alguien, siempre hay áreas débiles o partes aburridas que se pueden automatizar
En mi caso, lo que antes me frenaba en mi carrera era organizar muchas tareas a la vez, comunicar cambios de forma efectiva a toda la organización, y encargarme de la documentación y la gestión de tickets en lugares como Jira
Ahora eso ya no me preocupa, y la mejora de eficiencia ahí ha sido enorme
En el trabajo central que mejor hago, fuera de escribir mucho más rápido por mí, no ayuda tanto, pero incluso eso está bastante bien
Si le pides algo que no conoces bien, normalmente lo hace mejor que tú o al menos te guía hacia una decisión más informada
Estoy de acuerdo con “no le pidas validación al modelo. La herramienta le da la razón a todo el mundo”
Si le digo arbitrariamente al LLM que algo está mal, de algún modo encuentra defectos incluso en código que yo sé que está bien
El problema es que el LLM a menudo toma las cosas demasiado al pie de la letra
Aunque le pidas un plan, nunca he visto que un LLM logre diseñar de forma autónoma un sistema completo
Cuando un LLM crea código y luego le preguntas de distintas maneras si está correcto, sí encuentra problemas reales con bastante frecuencia