28 puntos por GN⁺ 2025-10-12 | 3 comentarios | Compartir por WhatsApp
  • En el entorno reciente de la educación en programación, en lugar del “infierno de los tutoriales” ha surgido como nuevo problema el “infierno del vibe coding”
  • Si el infierno de los tutoriales era el estado de “no poder crear nada sin tutoriales”, el infierno del vibe coding se refiere al estado de “no poder programar sin IA y no entender cómo funciona el código generado por la IA”
  • El uso excesivo de herramientas de IA reduce la motivación para aprender, y se está dando la situación paradójica de que quienes tienen menor alfabetización en IA la usan más
  • Las herramientas de IA, si se usan adecuadamente, pueden ser de gran ayuda como apoyo de aprendizaje, pero usarlas solo para “obtener la respuesta” obstaculiza la formación de una comprensión constructiva
  • Lo clave en el proceso de aprendizaje es pensar por cuenta propia e intentar resolver los problemas uno mismo; es importante desarrollar la actitud de acumular experiencia resolviendo problemas sin depender de tutoriales ni apoyo de IA

Contexto del problema: del infierno de los tutoriales al infierno del vibe coding

  • En 2019, el principal problema de la educación en programación era el “infierno de los tutoriales”
    • Se lograba seguir tutoriales, pero no se podía crear nada por cuenta propia
    • Se dedicaba más tiempo a ver videos sobre programación que a programar realmente, sin comprender los conceptos clave
    • Como resultado, se acumulaba solo conocimiento superficial y, al no entender los principios internos de funcionamiento, no se podía escribir código por uno mismo en situaciones reales
  • Para resolver esto, Boot.dev se enfocó en tres cosas
    • Currículum profundo: enfatizar la necesidad de aprender fundamentos de CS incluso fuera de la universidad tradicional
    • Enfoque centrado en la práctica: escribir código directamente junto con el aprendizaje de cada concepto
    • Refuerzo del texto enriquecido por encima del video: el video corre el riesgo de quedarse en consumo pasivo
  • En 2019, las largas clases de YouTube que acumulaban millones de vistas hoy tienen dificultades incluso para alcanzar 50 mil vistas
    • Canales como FreeCodeCamp, Traversy Media y Web Dev Simplified muestran esta tendencia
  • Sin embargo, los datos de Google Trends sobre “learn to code” siguen mostrando un alto nivel de interés
  • Alrededor de 1,300 nuevos usuarios se registran cada día en Boot.dev, y aunque en los últimos 18 meses han disminuido las quejas sobre el infierno de los tutoriales, ha aparecido una nueva forma de dificultad

Definición del infierno del vibe coding

  • Características del infierno de los tutoriales
    • “No puedo crear nada sin tutoriales”
    • “No entiendo la documentación, así que necesito videos”
    • “Incluso para tareas simples necesito frameworks complejos”
  • Características del infierno del vibe coding
    • “No puedo hacer nada sin la ayuda de Cursor”
    • “Hice un increíble juego de tower defense. Aquí está el enlace http://localhost:3000”
    • “No sé por qué Claude agregó 6,379 líneas para lazy-load de imágenes”
  • Hoy, muchos autodidactas están construyendo muchas cosas, pero levantan proyectos sin desarrollar un modelo mental de cómo funciona el software
  • Luchan contra las alucinaciones de la IA, forcejean con bots enfocados solo en pasar tests y confían ciegamente en el código generado por IA en lugar de resolver problemas reales

El futuro y la realidad de la programación con IA

  • Soy relativamente optimista respecto a que la IA no reemplazará por completo a los desarrolladores en el corto plazo
    • Han pasado 3 años desde que se decía “faltan 6 meses para que la IA quite empleos”, y aun así se sigue contratando desarrolladores
  • Aunque GPT-5 ya fue lanzado, solo mostró mejoras graduales frente a GPT-4, lo que se interpreta como evidencia de que la AGI no llegará pronto
  • Uso herramientas de IA todos los días, pero no estoy seguro de cuánto aumentan realmente mi productividad
    • No está claro si me hacen más productivo o más flojo
  • Resultados de investigación de 2025: los desarrolladores asumían que la IA aumentaría su productividad entre 20% y 25%, pero en realidad fueron 19% más lentos
    • Un resultado decepcionante frente a una inversión de 7 billones de dólares

Los riesgos de la IA y la caída de la motivación para aprender

  • La cultura de uso de la IA puede afectar negativamente la motivación de los estudiantes
  • Lo más preocupante del auge (¿burbuja?) de la IA es la aparición de una generación con la actitud de “¿para qué aprender? La IA ya lo sabe todo”
  • Si la IA en realidad no reemplaza todos los trabajos de oficina, no solo enfrentaremos una burbuja en el mercado bursátil, sino también una sequía de personal capacitado
  • Los inversionistas sin trasfondo técnico malinterpretan que “la IA ya reemplazó por completo la programación”, mientras que los desarrolladores senior aún no encuentran formas realmente útiles de integrar herramientas de IA en el trabajo diario
  • Preocupa que cuanto menor es la alfabetización en IA de una persona, más tiende a usarla
    • Esto funciona como la trampa definitiva del Dunning-Kruger: el fenómeno en el que quien sabe poco cree que sabe mucho
    • Los estudiantes llegan a la conclusión de que el desarrollo personal no tiene sentido porque “la IA ya lo sabe”

¿La IA beneficia el aprendizaje?

  • El interés social por aprender a programar sigue siendo alto
  • La IA puede ser útil para aprender, pero existen dos problemas estructurales
  • Primero: el problema de la complacencia (sycophant)

    • Los chatbots de IA tienden a estar excesivamente de acuerdo con la opinión de quien pregunta
    • Si conversas sobre “ROAS”, con los mismos datos pueden llegar a conclusiones completamente opuestas según la orientación de la pregunta, y responder ambas con tono experto y total seguridad
    • Esto le quita al estudiante la oportunidad de experimentar verificación, pensamiento crítico y corrección de errores
      • Consultamos a expertos porque queremos que nos digan cuando estamos equivocados
      • IRC y Stack Overflow hacían esto bien (quizá demasiado bien)
      • Los chatbots LLM (modelos de lenguaje grandes) tienen una fuerte tendencia a no corregir los malentendidos fundamentales de los estudiantes existentes
      • Actualmente, los estudiantes tienen conversaciones cómodas con LLM y escuchan lo que quieren oír, no lo que necesitan
  • Segundo problema: los estudiantes quieren una ‘opinión’ real

    • La IA presenta una postura demasiado equilibrada
      • “Algunas personas piensan X y otras personas piensan Y”
      • Eso hace más difícil que el estudiante decida con cuál postura está de acuerdo
    • Se le dieron prompts para actuar como “capitalista” o como “revolucionario marxista”, pero no se obtuvieron resultados satisfactorios
    • Los estudiantes quieren escuchar opiniones y comentarios nacidos de experiencia real
      • Por qué DHH eliminó TypeScript de Turbo
      • Lo que TypeScript resuelve para los desarrolladores de JavaScript según Anders Hejlsberg
      • A través de opiniones reales donde los sesgos y el contexto de cada autor quedan claros, se forman modelos mentales más sutiles
    • Las respuestas neutrales y cautelosas características de los LLM obstaculizan la verdadera interiorización del conocimiento

Cuando la IA sí ayuda de verdad al aprendizaje

  • Si se usa bien, la IA es una herramienta extraordinaria para aprender
  • Nunca ha habido una época más fácil para aprender programación
  • El caso de Boots, la herramienta de apoyo educativo con IA de Boot.dev
    • Los estudiantes usan casi 4 veces más el chat con el tutor de IA (Boots) que ver la solución del instructor (la respuesta ideal)
    • A diferencia de un chatbot general, Boots ayuda al aprendizaje de esta manera
      • Está preconfigurado para no dar la respuesta directamente
      • Usa el método socrático para guiar al estudiante a pensar más profundamente sobre el problema
      • Puede acceder a la solución del instructor, por lo que la posibilidad de alucinaciones sobre la respuesta correcta es mucho menor
      • Tiene una personalidad divertida (un oso mago)

Cómo salir del infierno del vibe coding

  • En conclusión, ya sea el infierno de los tutoriales o el infierno del vibe coding, la experiencia de ‘no dejárselo a otros y hacerlo uno mismo’ es crucial
    • Infierno de los tutoriales: apagar el video y escribir código directamente
    • Infierno del vibe coding: desactivar el autocompletado con IA, como Copilot, y acumular experiencia resolviendo problemas por cuenta propia
  • Lo que conviene evitar:
    • Autocompletado con IA dentro del editor
    • Procesar proyectos con modo agente y herramientas de automatización con IA
  • Lo que sí puede aprovecharse:
    • Chatbots que responden preguntas, explican conceptos y dan ejemplos
    • Prompts de sistema que induzcan a preguntar con método socrático para fomentar un pensamiento más profundo
    • Prompts de sistema que pidan citar fuentes y enlazar documentación al hacer afirmaciones para asegurar la confiabilidad de la información

Principios clave

  • Aprender necesariamente debe ser incómodo
    • El infierno de los tutoriales permite evitar esa incomodidad mirando a otra persona programar
    • El infierno del vibe coding permite evitar esa incomodidad haciendo que la IA escriba el código
  • El aprendizaje real ocurre cuando uno se atasca, se frustra y, lo más importante, se ve obligado a resolver problemas
    • Así es como se recablean las redes neuronales humanas
  • Si se exagera demasiado la idea de que “aprender debe ser difícil”, puede convertirse en una excusa para un mal diseño educativo
    • El autor no defiende eso
    • Aunque un concepto se explique de la mejor manera posible, el estudiante aún tiene que luchar con él y usarlo por sí mismo en un nuevo contexto para comprenderlo de verdad
  • El aprendizaje real se completa en el proceso de atascarse, frustrarse y abrirse paso con el propio esfuerzo

3 comentarios

 
aer0700 2025-10-12

Es un contexto un poco distinto, pero creo que el hecho de que exista el infierno de los tutoriales también se debe a que los tutoriales de frameworks no se usan como material básico de enseñanza de CS.
Que un principiante que vio el tutorial de Django y creó una app de encuestas no pueda luego hacer por su cuenta un blog se debe a que el tutorial de Django es un texto para explicar Django a personas que ya saben qué es HTTP, qué son las plantillas, qué es WS, qué es una DB, etc.; no es un texto para explicar la web. En el tutorial de Django se omite muchísimo contexto, y sospecho que esa es una de las causas de que aparezca el infierno de los tutoriales.
Reescribir el tutorial de Django para alguien que hoy programa por primera vez también parece una buena tarea. Algo como explicar primero la estructura de HTTP y luego cómo Django maneja cada uno de sus elementos.

 
gudrb963 2025-10-15

¡Qué buena opinión!

 
GN⁺ 2025-10-12
Opinión de Hacker News
  • La expresión "Tutorial Hell" me resulta demasiado familiar: ves un curso de 6 horas y programas siguiéndolo, pero cuando te toca crear algo desde cero te bloqueas por completo. Eso es justamente el tutorial hell típico. Por eso, históricamente el aprendizaje de oficio (apprenticeship) fue la forma más efectiva de aprender: el junior sigue al senior, y un maestro artesano lleva la visión general desde arriba, combinando gestión del proyecto con guía. Es una lástima que nuestra comunidad de desarrolladores no haya funcionado como un gremio durante tanto tiempo. Creo que ya desde finales de los 80 no debimos haber ido por otro camino. Si hubiera existido ese tipo de gremio, probablemente habría muchos menos desarrolladores y la evolución misma de la industria habría sido distinta.

    • No solo a los principiantes: incluso a los desarrolladores con experiencia les cuesta si les dices que arranquen un proyecto desde la nada. Normalmente se trabaja sobre una base de código existente, y aunque se necesite una app nueva, se empieza con plantillas o copy-paste. No es común crear algo completamente nuevo desde cero. Así como un electricista no suele cablear de cero un edificio nuevo en su trabajo diario, también es raro que un desarrollador en una empresa tenga que configurar absolutamente todo desde el inicio. El aprendizaje de oficio tampoco cambia tanto esa estructura de fondo.

    • En mi experiencia, una buena universidad entrena a los estudiantes con tareas graduales y prácticas. Empiezas resolviendo estructuras de datos, algoritmos o acertijos simples, y luego terminas construyendo sistemas operativos, bases de datos, estructuras de datos persistentes, compiladores, CPU, simulaciones y hasta modelos de machine learning. Vas pasando de una sola función a construir algo grande con tus propias manos, y estoy realmente agradecido por ese tipo de formación. Ver enlace relacionado.

    • Yo uso los LLM para aprender a programar como si fueran una relación maestro-aprendiz. El LLM solo avanza cuando yo se lo pido; explica y guía, pero escribir lo hago yo mismo. Es muchísimo mejor que andar buscando otro curso o tutorial nuevo. De hecho, el tutorial hell es un fenómeno creado por gente que cree que está enseñando. Un montón de libros y cursos al final tampoco logran enseñar algo de verdad. Me parece que el modelo actual de educación en programación está completamente mal. Hoy prefiero usar LLM para resumir la documentación más reciente de un lenguaje o librería nueva, o planear por mi cuenta lo que voy a hacer. Eso sí, me incomoda un poco no tener certeza de si el LLM está alucinando (hallucinate).

    • Dejé la escuela muy temprano por aburrimiento y por lo anticuado del método educativo, y me lancé al trabajo como aprendiz de ingeniería de software; el plan escolar no me sirvió de nada. A finales de los 90 todo era una cadena de errores y prueba y error, y tanto yo como mi maestro y el maestro de él aprendimos chocando directamente con los problemas. Armábamos routers ISDN con Linux, montábamos servidores para sitios web y trabajábamos con HTML, Perl y PHP, viviendo DevOps e ingeniería de verdad, aunque en ese tiempo ni existieran esos términos. Era una época en la que, casi sin documentación, uno iba empujando los límites con creatividad y ganas de intentar cosas. Siento cierto paralelismo con el vibe coding de la era de la IA; había mucha menos presión, pero guardo recuerdos muy divertidos.

    • En la industria tecnológica se ve mal el gatekeeping profesional. Eso viene en parte de la arrogancia del propio sector, y también de la intención del capital de inflar la oferta de mano de obra para bajar salarios. Como resultado, desaparecieron los estándares profesionales de verdad, y entrevistas humillantes como LeetCode terminaron convirtiéndose en el gatekeeper, aunque no tengan relación con el trabajo en sí.

  • Como alguien que usa Zed Pro y GPT todos los días para programar, creo que la evolución de estas herramientas deja al descubierto la ineficiencia de la programación moderna. La web moderna es asombrosa y terrible al mismo tiempo. Si burocracia significa quedar atrapado en reglas complejas, entonces el desarrollo moderno es su máximo exponente. Es un poco triste que hasta la tarea más simple necesite la guía de herramientas de automatización probabilística. Antes les decía a los más jóvenes: "lo importante no es saber un lenguaje en particular, sino tener la capacidad de seguir aprendiendo cosas nuevas". Algunas tendencias duran, pero al final siempre hay que seguir aprendiendo herramientas y lenguajes nuevos. No sé si será por la edad, pero en algún punto sentí que esa complejidad empezó a desbordarse. Antes la programación era demasiado parecida a la ingeniería eléctrica o a las matemáticas; ahora está cargada de otro tipo de complejidad.

    • Yo también conecto con esa sensación. En películas de ciencia ficción uno imagina algo como "¡redirijan la energía al frente!", donde las piezas y los sistemas son compatibles y reutilizables con facilidad en cualquier momento. Pero en la realidad, hasta cambiar la cámara de un teléfono Android a un iPhone es casi una misión imposible.

    • No me queda del todo claro qué quieres decir exactamente, pero usar la palabra burocracia suena raro. En la práctica, la capacidad de buscar es la habilidad clave, así que alguien que sabe encontrar las cosas puede hacer casi cualquier cosa. Las herramientas de automatización no son, en esencia, tan distintas de un libro o un maestro. Que algunas personas no tengan esa capacidad es parte de la naturaleza humana; no hay que culpar a las herramientas por haber mejorado.

    • Un gran problema es que escribir, buscar y leer documentación es realmente difícil. Por eso aprender cuesta tanto, pero gracias a la IA se ha vuelto más fácil. Por ejemplo, incluso algo como Unreal Engine la IA lo entiende sorprendentemente bien.

    • Todos estos problemas que cargamos son complejidad accidental, en el sentido de Brooks y su "No Silver Bullet". Los LLM ayudan a atravesar esa complejidad y a derribar los silos de conocimiento que se han acumulado en cada lenguaje y framework.

    • Si esta industria tan especulativa sigue así un poco más, podríamos llegar a un mundo donde programar como tal desaparezca por completo.

  • Ahora todos pueden escribir código, así que a nivel organizacional el volumen de código se multiplica como por 10. Pero la cantidad de reviewers sigue igual, y ya no alcanza. Si ni siquiera se puede usar un sanity check de código con LLM, entonces ¿qué se supone que hagamos? Ayer mismo, una persona no técnica creó un algoritmo de optimización con Codex y luego me pidió que lo mejorara. El problema es que ese código era un desastre total: hacía búsqueda ingenua entre miles de combinaciones enteras, no respetaba bien las restricciones, y al final producía resultados poco confiables. Terminé pasando todo el día revisando el código y hasta tuve que dar una presentación ante ejecutivos explicando que, en esencia, eso no servía para nada.

    • La respuesta al "sanity check de código con LLM" son las pruebas unitarias. El LLM también genera muy bien código de pruebas y código que sea testeable, si se lo pides. Si los tests llaman realmente al código y cubren bien los edge cases, eso es mucho más rápido que una code review. Incluso puedes incluir pruebas de rendimiento. Hacia adelante, vamos a trabajar más centrados en definiciones y tests, y el modo exacto en que se implementa internamente una función irá perdiendo importancia. Es un cambio grande de perspectiva.

    • Basta ver lo que pasó con la programación en Excel. Al principio todos la ignoran, pero cuando explota el problema, después terminan gastando fortunas para tratar de arreglarlo antes de que la empresa colapse.

    • Sobre eso de que "la cantidad de reviewers es la misma", los LLM también pueden ayudar en la revisión de código. Incluso GPT-5 es fuerte detectando errores locales como off-by-one o returns faltantes. Eso sí, todavía tiene límites cuando el problema exige entender la estructura general a un nivel más alto. En el futuro, probablemente podremos fine-tunear un LLM periódicamente con grandes codebases y usarlo como revisor de primera pasada para todos los cambios.

    • Los problemas de OR (optimización combinatoria) surgen mucho porque quienes programan de forma improvisada no se dan cuenta de que cayeron en un área algorítmica esencialmente especial. Incluso cuando se les señala, suelen insistir en hacerlo a su manera porque no entienden la teoría matemática involucrada.

    • En una situación así, quizá la única respuesta realista sea hacer presentaciones técnicas a los líderes de la empresa para que entiendan con precisión el estado de las cosas.

  • Pensé que otra vez iba a salir la típica idea de que la IA arruina a los desarrolladores junior y por eso se viene una crisis de reemplazo de seniors. Este texto toca eso de forma indirecta y en general estoy de acuerdo, pero lo que más me impactó fue la parte sobre la adulación (sycophancy). Antes pensaba que interfaces como ChatGPT ayudaban a aprender, pero el ejemplo de ROAS en YouTube me pegó fuerte. Si, dependiendo de cómo formule la pregunta, el estudiante puede sesgar tanto la conclusión del "profesor", entonces es inevitable que muchísimos desarrolladores novatos sean guiados en la dirección equivocada. Ni siquiera sé si todo el prompting que se le aplica a AI "Boot" es suficiente. Al final, incluso en la era de la IA, uno necesita que "alguien" le rechace sus PR una y otra vez para poder crecer. Y ese "alguien" todavía no puede ser la IA.

    • En mi experiencia, aunque le pidas una crítica demoledora (Scathing critique), la IA igual mezcla una actitud de querer hacerte sentir bien. Pasa lo mismo tanto con versiones viejas de GPT como con las más nuevas. Se siente ambiguo. Al final, la herramienta funciona mejor para quien realmente quiere recibir ayuda y además es consciente de los problemas particulares de los LLM.

    • Para evitar la adulación, siempre hago la pregunta dos veces metiendo un sesgo contrario. Pero no puedo saber si la IA también está reforzando sesgos ocultos que yo ya traía.

  • No soy principiante, pero sigo aprendiendo frameworks, lenguajes y algoritmos nuevos, así que no creo que el autocompletado con IA sea algo malo. El autocompletado de antes, como IntelliSense o ReSharper, también ayudaba muchísimo a aprender librerías nuevas o funcionalidades nuevas de un lenguaje. ReSharper te sugería funciones nuevas cuando estabas programando a la vieja usanza, y muchas veces así fue como aprendí. El autocompletado basado en IA se siente como una evolución mucho más avanzada: te propone cosas de forma natural, y puedes usarlas o no, así que también ayuda a aprender. En última instancia, mientras tengas la curiosidad de leer y entender lo que te propone, la IA hace que aprender sea más fácil. Antes simplemente copiábamos y pegábamos desde Stack Overflow.

    • El autocompletado tradicional te muestra todos los métodos, variables y constantes dentro del scope correspondiente, y además enlaza la documentación. Como tú mismo puedes evaluar qué opciones tienes, eso sí era realmente bueno para aprender. El autocompletado con IA se parece más bien a que te peguen una respuesta de Stack Overflow sin explicarte el contexto. Si estás aprendiendo, probablemente sea mejor buscar tú mismo en Stack Overflow o, si hace falta, pedirle a un chatbot que te explique por qué ese código funciona así.

    • Creo que hay una diferencia importante. Si ya tienes cierta experiencia, usar autocompletado en un lenguaje nuevo se siente natural. Pero es otra cosa muy distinta cuando un principiante sin bases está aprendiendo su primer for.

    • Me gusta la programación agentic con IA. Crear cosas me hace feliz y es parte de experimentar ideas. No estoy desplegando código a producción, así que no me preocupa lo que piensen otros. Para poder hablar con colegas técnicamente brillantes, necesito intentar las cosas por mi cuenta y aprender. Me gusta programar desde los 10 años, aunque nunca fui desarrollador profesional. Con la llegada de la IA, volvió ese amor por programar y experimentar. Me divierte mucho explorar tecnologías web del futuro como WASM, distintos sistemas, buscar bugs y probar las cosas a mi manera. Herramientas como Cursor AI incluso me automatizan la configuración de git y hacen fácil hasta hacer push por ssh. Claro que lo puedo hacer yo mismo, pero prefiero dejar que la IA lo haga. Aunque arrastro hábitos viejos desde mis comienzos con la sintaxis de C, disfruto mucho trabajar con backend en Python, servidores web con Flask y frontend en JavaScript. WASM Python todavía está bastante verde, pero sigo experimentando. Me gusta fortalecer las bases y aprender a mi manera. También siento seguido que los ingenieros tienden a complicar las cosas más de lo necesario.

    • El autocompletado con IA es la mejor herramienta: recibes sugerencias del código que quieres sin necesidad de documentación, son solo unas pocas líneas así que revisarlas es fácil, y no te genera bloques grandes automáticamente, por lo que tampoco perjudica el aprendizaje.

  • No soy principiante, pero gracias a Copilot aprender Rust se me hizo claramente más fácil. Si lo combinas con Intellisense, la carga sintáctica baja y puedes concentrarte en aprender las partes importantes del lenguaje. En una semana pasé de abrir un libro sobre Rust a construir una herramienta funcional. Claro, eso no me convirtió en ingeniero senior, pero sí redujo de verdad la barrera del "0 a 1". Yo no le doy instrucciones a Copilot para que escriba código; solo tomo sus sugerencias como si fuera un autocompletado mejorado y decido por mi cuenta si aceptarlas o no.

    • El tema que se repite aquí es que un senior con mucha experiencia puede sacar valor de estas herramientas aunque no conozca el lenguaje nuevo, porque ya sabe "cómo programar". Los code smells son los mismos aunque cambie el lenguaje. Un principiante ni siquiera conoce bien el concepto de "code smell".

    • Yo también pensé antes que Copilot me estaba ayudando mucho a aprender Rust, pero cuando intenté programar por mi cuenta sin IA, me di cuenta de lo difícil que era de verdad. Solo aprendiendo con la IA apagada pude salir de la ilusión de creer que ya lo entendía.

  • El mismo problema existe con muchos otros atajos educativos. Estudiantes que hacen que su tutor les resuelva la tarea, o que oyen la explicación y creen que ya van a poder rendir bien el examen. En realidad, cuando lo escuchas parece fácil, pero hacerlo por tu cuenta es una habilidad completamente distinta.

  • Si la IA no reemplaza de verdad todos los trabajos de cuello blanco en unos pocos años, creo que no solo vamos a ver una burbuja bursátil, sino también una escasez de trabajadores calificados. Para mí, se siente como estar viendo cómo se dispersa el mejor talento de mi generación.

  • Intenté encontrar una frase representativa que pudiera usarse como título del artículo, pero no encontré nada adecuado, así que hice lo mejor que pude. Si alguien tiene una propuesta de título más precisa y neutral, puede cambiarla. Ver guía relacionada.

  • Me identifiqué muchísimo con la parte de "lo entendí, pero si tengo que escribirlo desde cero me quedo totalmente trabado". Seguir tutoriales y luego bloquearme al intentar hacer algo parecido fue de las partes más dolorosas y difíciles. Pero ese proceso doloroso también fue una experiencia de aprendizaje de máxima densidad. Después aprendí cosas más complejas y variadas, pero nunca volví a sentir un aprendizaje tan intenso. Se parecía un poco a esa sensación en matemáticas de preparatoria donde te duele la cabeza y te estresas. Imagino que no es una experiencia universal para todo el mundo.