IA: incompetencia acelerada
(slater.dev)- En ingeniería de software, depender en exceso de los LLM puede aumentar la velocidad a corto plazo, pero debilitar el pensamiento crítico y la capacidad de resolver problemas
- Un riesgo mayor que una salida incorrecta es aceptar sin cuestionar prompts defectuosos, lo que acelera la acumulación de deuda técnica y la degradación de las capacidades de los usuarios
- Como los LLM no pueden recordar ni internalizar una teoría del programa más allá de su ventana de contexto actual, el modelo mental compartido necesario para el diseño y el mantenimiento sigue siendo territorio de los ingenieros humanos
- La complejidad sigue aumentando durante el mantenimiento, y los LLM, como predictores de tokens a nivel de texto, pueden incrementar la entropía del programa con cambios innecesarios o extraños
- La IA puede usarse como herramienta, pero no debe convertirse en una muleta; hay que seguir invirtiendo en las capacidades básicas de ingeniería y en el pensamiento profundo que ya eran valiosos en 2019
Riesgos de ingeniería creados por la dependencia de los LLM
- Llamar “amigo” a un LLM se parece más a un eufemismo para decir que beneficia al usuario que a una verdadera relación de compañerismo
- Los ingenieros con esta perspectiva suelen priorizar la velocidad, o están bajo presión para priorizarla
- Los LLM pueden generar mucho código rápidamente, pero su uso viene acompañado de una larga cola de riesgos
Cinco riesgos que aparecen en la generación de código
-
Riesgo de salida
- Los LLM pueden producir resultados claramente incorrectos, como código que ni siquiera compila
- Un caso aún más peligroso es cuando generan errores sutiles y difíciles de detectar, como bugs lógicos
- El riesgo aumenta cuando quien escribe el prompt no está calificado para evaluar el resultado
- Se menciona como ejemplo la situación en la que un project manager pide código fuente
-
Riesgo de entrada
- Los LLM no cuestionan prompts con preguntas inducidas, supuestos erróneos o contexto incompleto
- Por ejemplo, ante una solicitud como “proporciona una implementación de lista thread-safe en C#”, pueden devolver 200 líneas de código aparentemente razonable, aunque la verdadera pregunta podría ser “¿cómo hago que este código sea thread-safe?”
- En ese caso, la respuesta podría ser una sola línea de código usando
System.Collections.Concurrent - Como no se le pidió, el LLM no reconoce que se trata de un caso del XY Problem
-
Pérdida futura de velocidad
- Los LLM pueden deteriorar muy rápido la calidad de una base de código
- Sin guardrails sólidos, el código generado por LLM puede verse bien por fuera, pero convertirse por dentro en un espacio insalubre y disfuncional
- Esto se considera un problema más urgente que la discusión habitual sobre deuda técnica
-
Infantilización del usuario
- En personas y organizaciones que delegan el pensamiento y la resolución de problemas al LLM, el talento puede desaparecer
- Los ingenieros senior pueden perder oportunidades de aprendizaje que vienen de la lucha productiva, debilitando así su capacidad de resolver problemas y su pensamiento crítico
- Los ingenieros junior podrían no desarrollar nunca esas capacidades, y después también tendrían dificultades para mentorizar a futuros juniors
- ThoughtWorks Technology Radar Volume 32 aborda casos en los que la confianza impulsada por IA sacrifica el pensamiento crítico
- Coding as Craft: Going Back to the Old Gym enfatiza una colaboración deliberada con IA que preserve la programación como oficio
- Thoughts on Thinking sostiene que los LLM pueden dar pensamientos terminados, pero no el crecimiento intelectual que surge de desarrollarlos por cuenta propia
-
Pérdida del disfrute
- Muchos desarrolladores reportan que usar IA les quita el estado de flujo y el placer de crear
- El código generado por IA puede volverse desagradable de leer y modificar
- Como lectura relacionada, se enlaza The Hidden Cost of AI Coding
Dos capacidades que los LLM no pueden reemplazar
- Frente a la preocupación de que los ingenieros expertos puedan volverse innecesarios por la IA, se resumen en dos las capacidades de programación que los LLM no pueden ofrecer
- Esas capacidades son la teoría del programa y la entropía del programa
Teoría del programa: el código no es el programa en sí
- Programming as Theory Building de Peter Naur entiende la programación como una actividad de formar comprensión o una teoría sobre un problema
- Desde la perspectiva de Naur, el programa no es el código fuente sino una construcción mental compartida, es decir, una teoría o diseño
- El código se deriva de ese diseño, pero el producto valioso está en el diseño más que en el código
-
Experimento mental de dos equipos
- Dos equipos A y B, con las mismas capacidades, están en salas separadas sin comunicarse entre sí
- El equipo A escribe un programa como un juego de ajedrez en terminal, mientras que el equipo B espera o juega ajedrez real
- Cuando A termina, el código fuente se entrega a B y ambos equipos deben agregar una función como un jugador virtual de ajedrez
- El equipo que probablemente producirá la mejor solución es A
- El equipo A tiene un modelo mental fresco del programa que acaba de construir
- El equipo B no tiene ese modelo
- Como los programas siguen modificándose después de su creación inicial, tener solo el código fuente sin una comprensión internalizada del diseño vuelve costosos los cambios
- Esto se relaciona con la experiencia de entrar por primera vez a una gran base de código, tener una productividad cercana a cero al inicio, y luego mejorar a medida que se carga en la mente la teoría del programa
-
LLM y teoría del programa
- Los LLM actuales no pueden recordar más allá de la ventana de contexto, así que no pueden dominar una teoría, un diseño o una construcción mental
- Quien puede obtener y mantener una teoría del programa es el ser humano
Entropía del programa: la capacidad de reducir o resistir la complejidad
- La complejidad es una fuerza fundamental en contra de la programación, y está relacionada con la entropía
- The Mythical Man-Month de Fred Brooks ve la construcción de programas como un proceso de reducción de entropía, y el mantenimiento como un proceso de aumento de entropía
- Desde la perspectiva de Brooks, después de la construcción inicial, los cambios al programa inevitablemente tienden a volver más complejo el código fuente
- Sin embargo, los cambios en armonía con el diseño pueden desacelerar el ritmo de aumento de la complejidad
-
LLM y entropía del programa
- Los LLM son predictores de tokens y operan solo a nivel de texto
- Los LLM no razonan en el nivel conceptual de ideas, diagramas o especificaciones de requisitos
- Quien haya puesto grandes bloques de código en un LLM habrá visto su tendencia a aplicar cambios innecesarios y extraños
- Cuanto más larga se vuelve la conversación, más pueden desviarse los resultados
- La capacidad de reducir la complejidad del código o resistirla pertenece a los humanos
Cómo usar la IA en ingeniería
- Si esperabas que la IA llevara tu carrera de ingeniería al siguiente nivel, puede pasar lo contrario
- Los LLM pueden acelerar la incompetencia, pero no pueden reemplazar la ingeniería humana
- El atractivo comercial de la IA está en convertir la ingeniería en un commodity para reducir costos
- Pero, así como el uso de talento de ingeniería en el extranjero ha dado resultados mixtos, los LLM también vienen con límites y riesgos
- El ciclo de hype de la IA eventualmente puede llegar a su punto máximo
- Las empresas que hoy usan IA en exceso terminarán cargando con costos de larga cola, y podrían cambiar de rumbo o desaparecer
- La propuesta de valor de largo plazo de los humanos en ingeniería no cambia
- El mundo sigue necesitando capacidad técnica y pensamiento profundo
- Seguirá pagando por esas capacidades
- La IA seguirá existiendo, pero debe usarse como herramienta, no como una muleta
- Hay que seguir invirtiendo en las capacidades básicas de ingeniería que ya se consideraban valiosas en 2019
1 comentarios
Opiniones de Hacker News
A veces, el debate sobre la programación con IA parece reflejar la diferencia entre ingenieros de software y científicos de datos/ingenieros de machine learning.
Ambos lidian con requisitos poco claros y bugs difíciles de atrapar, pero en general los ingenieros de software crean software que siempre debe comportarse de una manera específica, y la reproducibilidad, las pruebas y las herramientas maduras son importantes.
En cambio, los ingenieros de machine learning trabajan con modelos que son probabilísticos por naturaleza, y las pruebas se centran más en métricas de evaluación como “da la salida correcta en el 90% de los casos” que en si produce una salida específica.
Por eso, la mentalidad de lidiar con una IA que no siempre es confiable resulta más natural del lado de machine learning, y se tiende a evaluar a los asistentes de código como “acierta el 80%, me ahorra trabajo, y el 20% restante lo arreglo yo”.
Cuando trabajaba en Amazon, muchas veces las soluciones basadas en machine learning encajaban bien en problemas reales para los que no había un enfoque clásico. Por ejemplo, la predicción de movimiento basada en mapas de cuadrícula o la clasificación de imágenes/mapas de cuadrícula se integraban bien en pipelines existentes de estimación y control, y resultaban útiles.
En cambio, en una startup, un gerente de bajo nivel me reprendía constantemente porque dudaba de un enfoque basado en aprendizaje para estimar a lo largo del tiempo la orientación de un plano inmóvil. Como el equipo no conocía los fundamentos de mapeo ni de filtrado y asumía que “si metemos más datos, se resuelve”, todo el pipeline de control del vehículo estaba alimentándose de estimaciones de rotación arbitrarias que parpadeaban y saltaban.
Esa brecha es realmente grande, y ojalá hubiera una mejor forma de detectarla en entrevistas.
Hace tiempo escuché a un arquitecto sénior de la empresa quejarse después de una reunión: en nuestro producto, la precisión y la corrección siempre habían sido un gran argumento de venta, pero el equipo de machine learning de otra oficina no entendía eso y consideraba que una precisión del 80 al 90% era suficiente para los clientes.
Me recuerda al debate sobre si una tasa de mortalidad del 1% en una enfermedad pandémica es pequeña o grande. 1 es el entero más pequeño, pero el 1% de 300 millones de personas son 3 millones.
Pero no creo que este texto trate solo de eso. Trata las preocupaciones de nivel meta que tienen quienes hacen ingeniería de software y cómo encaja la IA en ellas, y creo que da en el clavo cuando habla de “entropía del programa”.
Una gran parte de crear productos de software consiste en gestionar la entropía. Hay que aumentar el código y la gente manteniendo una velocidad de avance adecuada, y lograr que todos entiendan cómo encajan las piezas y cómo agregar nuevas piezas. Puede que algún día la IA haga esto más fácil, pero ahora muchas veces empeora la entropía.
No sería un gran problema si las personas con intereses de por medio no intentaran convencer a todos de que “no es así, la IA se puede usar ya mismo para todo”.
Esa suposición es tan absurda que incluso es difícil refutarla con lógica, y hasta ahora ha sido muy exitosa como relato basado en la fe para atraer inversiones enormes y envolver optimizaciones de personal centradas en la rentabilidad.
Estoy muy de acuerdo con la premisa del artículo y con la mayoría de sus argumentos concretos, pero también veo aspectos positivos al usar LLM en el día a día. Como referencia, llevo unos 30 años en la industria del software.
Al trabajar con código generado por IA, uno termina leyendo código. El desarrollo se vuelve más parecido a una serie de revisiones de código que a un viaje de creación desde cero, y para un desarrollador solo tiene la ventaja de permitirle imitar y aprender responsabilidades que normalmente son más fáciles de adquirir en equipo.
Además, al trabajar con un LLM se vuelve evidente rápidamente que el desarrollador debe entender el problema en capas claras y bien estructuradas. Si le pides algo grande de una sola vez, normalmente terminas pegándote un tiro en el pie, así que abordarlo desde el diseño, escribir especificaciones detalladas e implementar por partes ayuda a definir los límites y las interfaces de los bloques conceptuales.
Un LLM puede verse como un acelerador poderoso que ayuda a un desarrollador junior a crecer hacia un rol sénior. Con la orientación adecuada, revela el proceso de aprendizaje de lecciones que a personas más experimentadas les tomó tiempo adquirir. No creo que todo sea sombrío, ni que la IA vaya a reemplazar a los desarrolladores; ahora es muy disruptiva, pero al final creo que encontrará su lugar en algún punto entre las demás herramientas.
Al revisar código creado con ayuda de un LLM, quizá uno termina leyendo código más plano, pero aun así creo que se aprende. He leído mucho código generado por LLM y a menudo aprendo modismos que no conocía o llamadas a librerías que no sabía que existían.
Para los desarrolladores sénior, un LLM es un acelerador aún más potente. Como saben qué existe y qué no vale la pena intentar, pueden escribir mejores prompts.
Basta ver las noticias recientes: los despidos continúan en Big Tech, en empresas tecnológicas medianas y en empresas tecnológicas pequeñas.
¿Recuerdan cuando se decía que la impresión 3D iba a reemplazar toda la manufactura?
La IA se parece más a ese sentimiento que a una singularidad
También podría verse como que los LLM no mejoraron nada, sino que solo expusieron fallas sistémicas, pero el impacto en sí es claro. Decenas de dinámicas de clase que eran estándar hace dos años ya no funcionan
Esto incluye especialmente toda la educación en línea y a distancia; irónicamente, ChatGPT apareció justo cuando muchas universidades empezaban a invertir en eso después del Covid. Es un impacto a escala de toda la educación superior y secundaria del mundo
La industria aeroespacial es un buen ejemplo. Mucho de lo que hacen SpaceX y las startups jóvenes de este campo no habría sido posible sin piezas impresas en 3D. Con frecuencia se imprimen piezas como boquillas, cámaras de combustión y turbobombas
Aun así, esta comparación no me parece justa. Cuando estudiaba ingeniería mecánica, la impresión 3D me permitió crear prototipos y equivocarme más rápido y más barato, así que más bien mejoró mis habilidades de ingeniería
No reemplazó toda la manufactura, pero cumple un papel importante en el diseño y no degradó las habilidades del usuario
Los LLM son asombrosos para escribir código, pero pésimos para adueñarse de ese código y mantenerlo
Cada línea que aceptas sin entender es entendimiento prestado, y en mantenimiento se paga con intereses altos. Se siente como velocidad gratis, pero en realidad se parece más a deuda técnica con algo así como 40% de interés anual
Como comunidad, tenemos que encontrar una forma de automatizar la escritura con IA, pero no automatizar el pensamiento
Pero no es así, y por cómo funciona tampoco puede serlo
Por lo tanto, cada línea de un LLM que aceptas sin entender es, en realidad, entendimiento inexistente. Es solo una línea de código escupida por un modelo probabilístico, y permanece sin entenderse hasta que la vea una entidad capaz de comprender realmente el contexto, el sistema y el diseño del codebase. Por ahora, las únicas entidades conocidas de ese tipo son los humanos
En el desarrollo tradicional no me gustan mucho ninguno de los dos, pero los LLM actuales hacen que ambos sean más fáciles y útiles
Y la “regla de tres” básicamente deja de aplicar entre componentes. El impacto del código debe ser local, o bien formar parte de una biblioteca base muy sólida. Los casos intermedios hacen explotar la complejidad del refactorizado
“Los LLM no cuestionan los prompts inductivos” ha sido hasta ahora el riesgo de entrada más doloroso
Lo más frustrante es que uno quizá ni siquiera se dé cuenta de que está orientando la respuesta en una dirección determinada. Si uno piensa en cómo funcionan los LLM, tiene sentido, pero una sola palabra escrita de forma ambigua puede sesgar el resultado en una mala dirección, llevarlo a lo contrario de lo que quería y meterlo en una madriguera equivocada
Para cuando te das cuenta, estás en medio de un pantano de código pegado como se pudo, que apenas funciona más o menos. El lenguaje humano es tan ambiguo y poco específico que es casi como si por eso hubiéramos inventado lenguajes formales reglados que sí permiten precisión
Personalmente, también sentí que mis habilidades se deterioraban rápido por culpa de las herramientas de AI. Durante un tiempo, por flojera, recurría a la AI para cualquier tarea pequeña, pero al tomar distancia vi que no estaba ahorrando tanto tiempo y, de hecho, me agotaba mucho más rápido leyendo decenas o cientos de líneas de código, pensando en cómo se había equivocado la AI y corrigiéndolo
No lo medí, pero en general siento que desperdicié mucho más tiempo del que ahorré con herramientas de AI
El verdadero problema es que la AI sí es útil para muchas tareas, pero quienes la usan se dividen en dos grupos. Unos la usan en trabajos complejos donde pequeños errores se acumulan rápidamente; los otros suelen ser perfiles de management, que ven cómo escupe 200 líneas de código que no entienden, consideran como “MVP” algo del estilo de una app TODO que apenas funciona, y piensan: “si puede hacer esto, también puede hacer tu trabajo fácilmente”
Si van a responder con lo típico de que la usé mal o que el modelo estaba equivocado, me gustaría que primero leyeran este comentario anterior para tener contexto sobre mi experiencia con estas herramientas: https://news.ycombinator.com/item?id=44055448
Es decir, la AI es mi asistente, pero la responsabilidad de entregar un resultado de buena calidad y mantenible es mía
Dicho eso, desde una perspectiva masiva, basta pensar en una calculadora sencilla. Las calculadoras arruinaron la capacidad de cálculo mental de la gente. La AI hará algo parecido con la escritura, la comunicación, la capacidad de resolver problemas, etc.
Parece que los modelos se aferran a cierta palabra clave en algún punto del flujo del prompt, abandonan la lógica tradicional y te empujan por un camino más estrecho que ni siquiera resuelve bien el problema original. Al final solo aumenta la frustración y la infelicidad del lado humano
Para evitar que mis habilidades se deterioren, intento usar AI solo en tareas pequeñas y bien definidas que antes habría resuelto buscando en StackOverflow. En vez de buscar “¿cómo hago X?”, le hago la misma pregunta al modelo y uso la respuesta no como verdad definitiva, sino como guía para resolver el problema
Aun así, hoy hay cosas que la AI sí facilita. Por ejemplo, cuando tienes un ejemplo del tipo “hazlo como esta página, pero usando los datos x en vez de y”, muchas veces es más rápido que buscar documentación. Con la salvedad de que puede alucinar, pero también es muy probable que mejore con el tiempo
La mejora que me gustaría ver es que, además de volverse más precisa en general, busque la solución más simple sin tener que decírselo cada vez. La mayor desventaja cuando sueltas a ChatGPT, Claude, etc., es que generan montones de basura muy rápido y no se detienen diciendo “esto va a volverse demasiado complejo para manejarlo después”. El texto original sostiene que solo un humano que entiende el diseño completo puede resistir la entropía; no sé si esta parte nunca mejorará, pero ahora mismo se siente como el mayor problema
En la primera ronda normalmente quedan expuestas las principales suposiciones que está haciendo el modelo, y desde ahí se puede ir acotando y aclarando
Al leer el comentario anterior sobre varios intentos, parece que tu experiencia con LLM es mucho más amplia que la mía. Pero no vi esta técnica, así que la dejo por si a alguien le sirve
Frases como “no puede inferir ideas, diagramas ni especificaciones de requisitos” o “solo los humanos pueden reducir la complejidad” me parecen casos donde, detrás de un concepto interesante, se agregan afirmaciones de detalle claramente equivocadas
Esto se puede hacer con mucha facilidad. Basta con pedir código más simple. Yo lo uso a menudo para obtener una segunda opinión y consigo buenos resultados
Si no consultas al modelo, no obtendrás ni respuestas complejas ni simples. Consultarlo con opciones por defecto también es una elección; no es algo inherente al concepto de LLM
También lo uso bien para convertir entre código e ideas/diagramas. No entiendo por qué la gente hace afirmaciones tan fuertes que otros refutan todos los días en la práctica
El artículo también repite una lógica extraña que parece correcta a primera vista, pero no resiste un análisis más detallado. Lo de Naur ya se volvió un meme y se repite como si fuera una intuición sobre la realidad, pero olvida otra regla fundamental y práctica de la ingeniería de software: cualquier programa no trivial pronto supera la capacidad de una sola persona para mantener toda la teoría en la cabeza
Casi nunca trabajamos con una teoría adecuada del programa. Los lenguajes de programación, las técnicas, las metodologías y las herramientas han evolucionado para que la gente pueda trabajar mejor sin entender la mayor parte del código
En este sentido, los humanos compartimos las mismas limitaciones que los LLM; solo las gestionamos mejor porque no tenemos que esperar a que se nos permita otra vuelta del bucle de inferencia para obtener otra perspectiva
Creo que se puede aplicar una lógica similar a tecnologías de mapas como Google Maps o Apple Maps. El argumento es que, al usar estas herramientas, se atrofian la capacidad de explorar el mundo físico, el sentido de orientación y el sentido geográfico.
En realidad, no es falso. Hoy mucha gente tiene problemas para orientarse sin apoyos como Google Maps, y su relación con el mundo físico también cambió en muchos aspectos.
Pero antes tampoco era que mucha gente fuera especialmente buena para orientarse. En particular, la capacidad promedio de ir de forma segura y confiable del punto A al punto B en una zona desconocida sin duda aumentó mucho.
Y para la minoría de personas con talento natural para la geografía y la orientación, herramientas como Google Maps no reemplazaron sus capacidades, sino que las complementaron.
Creo que con la IA pasará algo similar, pero a mayor escala. Sin duda hay trade-offs y algunas habilidades y capacidades se reducirán, pero muchísimas más personas podrán hacer cosas que antes no podían, y una minoría hará mejor lo que ya hacía.
Claro que no siempre es así. Mapear el mundo entero es una tarea muy compleja, con innumerables excepciones y casos límite. Pero la diferencia frente a la salida de un LLM es enorme. Incluso con la temperatura en 0, si regeneras varias veces el mismo prompt, la salida cambia mucho.
Además, los LLM cubren un rango conceptual mucho más amplio, así que la gente terminará usándolos en lugar de pensar por sí misma en muchas situaciones en las que de verdad no debería hacerlo. Si ya con los mapas hay gente que maneja hacia un lago porque Google Maps dijo que era un camino, ni me imagino qué pasará cuando confíen ciegamente en la salida de un LLM y reemplacen su propio pensamiento.
Donde vivo, Google Maps es mejor que un taxista el 90% de las veces.
La IA no es mejor que alguien que hizo ese trabajo apenas unos días.
Siendo realistas, el 70% de los empleados hace su trabajo con tanta desidia que a menudo la IA lo hace igual o mejor.
La verdadera dificultad es que quienes ya hacían las cosas a medias siguen siendo inútiles incluso usando IA, mientras que los demás aprenden y crecen junto con la IA.
La conducción totalmente autónoma es parecida. FSD es mejor que un conductor humano pésimo, borracho o que va texteando, y en las calles hay muchos conductores así.
Me pregunto de dónde sacó el autor la sensación de que “[la IA] no puede trabajar a nivel conceptual”.
Lo que los LLM recientes han demostrado una y otra vez es que claramente pueden trabajar a nivel conceptual, por ejemplo traduciendo correctamente conceptos de un idioma a otro según el contexto.
Que no “entiendan” los conceptos como los humanos es otro asunto. Como no han experimentado el dolor, no podrían “entender” el dolor, pero los humanos también hablan constantemente de cosas que no han experimentado directamente. Si eso está bien o no es otro tema.
Eso es un modelo débil de algunas características de los conceptos, como la asociación. Por ejemplo, “dog” se asocia con “cat”. Pero no modela cosas como la composicionalidad, la intensión o el papel que cumplen los términos en condicionales contrafácticos.
Dicho eso, si la pregunta se parece a los datos de entrenamiento, sí se puede obtener una apariencia de capacidad conceptual empujando a fuerza bruta. Si alguien hizo una pregunta como “¿los perros serían felices jugando en Marte?”, o un conjunto de preguntas suficientemente parecidas, puedes ubicar “dog” cerca del clúster de “hechos literales” y de algunos clústeres de contrafácticos ya conocidos.
Para ver la diferencia entre esto y una verdadera capacidad mental, basta notar que las combinaciones conceptuales de profundidad arbitraria son infinitas y pueden componerse de un número infinito de contrafácticos. Un niño con solo los componentes básicos e imaginación puede evaluar esa variedad infinita.
Por eso los LLM se usan más en campos estrechos donde el “trabajo conceptual” necesario está muy bien documentado y es lo bastante estable, especialmente en ingeniería de software.
Cada vez tengo más ganas de convertir 90s.dev en una comunidad sin IA. Un lugar centrado en las antiguas artes de escribir buen software, y que dé la bienvenida a todos los que hayan pulido esas habilidades.
¿Qué haría falta para empezar? ¿Un foro? ¿Una lista de correo? ¿Un modelo como hackernoon, que agrupe blogs de varios autores?
Creé una lista de correo provisional para quienes tengan interés en https://github.com/sdegutis/90s.dev/issues/2; para recibir correos sobre ese tema, pueden suscribirse o comentar.
Los foros quedaron arruinados por los LLM y los bots, así que esa opción queda fuera. Para que algo así funcione tendría que ser solo por invitación, y cada persona que recomienda a otra tendría que responsabilizarse por su árbol de invitaciones.
La comunidad tendría que ser lo bastante buena como para que perder el acceso incentive el buen comportamiento. En ciertas comunidades online este enfoque funciona muy bien.