¿La IA está haciendo que el frontend repita su década perdida?
(mastrojs.github.io)- La descalificación sustituye trabajo especializado por operación tecnológica de menor especialización, reduciendo costos y barreras de entrada, pero también debilitando el poder de negociación de los trabajadores
- En los últimos 10 años, el frontend ha desplazado la especialización del front of the frontend a medida que frameworks y herramientas ocultaron conocimientos sobre navegadores, accesibilidad y rendimiento
- La IA agéntica eleva la programación a un nivel más alto de abstracción, pero es una abstracción con fugas (Leaky): no determinista y capaz de producir resultados muy distintos ante pequeños cambios en la entrada o en el modelo
- Los LLM son una continuación del copiar y pegar de Stack Overflow: hacen más rápidos a los expertos y permiten que los principiantes también logren resultados funcionales, pero alguien tiene que entender y corregir lo que producen
- La IA puede generar más AI slop y reducción de costos, pero eso no elimina la necesidad de personas que entiendan la calidad, a los usuarios y los compromisos
El frontend y la programación con IA vistos desde la descalificación
- La descalificación (deskilling) es el proceso de sustituir trabajo especializado por tecnología que puede ser manejada por trabajadores semicalificados o no calificados; reduce costos y baja las barreras de entrada, pero debilita el poder de negociación de los trabajadores
- En los últimos 10 años, el desarrollo frontend ha pasado por una descalificación impulsada por frameworks y herramientas de JavaScript, y en la programación en general la IA agéntica está provocando un cambio parecido
- Como sugiere la expresión Frontend’s Lost Decade, la especialización frontend que antes implicaba entender a fondo el navegador y la experiencia de usuario fue desplazada por el desarrollo centrado en frameworks
La especialización que desapareció del frontend
- Antes, el desarrollo frontend requería conocimientos especializados en HTML semántico, CSS, diferencias entre navegadores, accesibilidad, mejora progresiva, rendimiento de red, diseño de interfaces y pruebas con usuarios
- Algunas personas en la práctica distinguen estas áreas del “frontend” actual y las llaman front of the frontend
- La descalificación del frontend avanzó con la introducción de frameworks y herramientas que tratan al navegador como un simple objetivo de compilación, igual que una JVM o iOS como runtime de aplicaciones
- Si importas un componente como Shadcn radio button, puedes crear funcionalidad sin entender a fondo el HTML subyacente, los matices entre navegadores, el rendimiento de carga de la página o la accesibilidad
- Las empresas pueden asignar programadores generalistas con más facilidad a tareas frontend y así reducir costos
- “Desarrollador full stack” muchas veces ya no significa alguien que entiende profundamente frontend y backend, sino un perfil generalista que puede resolver ambos lados con un framework de JavaScript
- Es más fácil mover al mismo desarrollador entre distintos proyectos y hasta ponerlo a trabajar en apps nativas con React Native y Electron
- Junto con la ventaja de bajar la barrera de entrada, también se debilita el poder de negociación de los trabajadores
Programar con IA es una abstracción más alta y también una abstracción con fugas
- Lo que hoy está ocurriendo en la programación en general se parece a lo que el desarrollo web ya vivió antes
- Se está avanzando hacia sustituir el trabajo especializado de escribir código a mano por tecnología manejable por trabajadores semicalificados o no calificados
- Aún no está claro qué capacidades terminarán siendo necesarias para quienes trabajen con IA agéntica, ni hasta dónde llegarán los precios del trabajo y los costos de LLM locales o remotos
- Sí parece claro que las empresas pueden usar esta tecnología para recortar costos y debilitar el poder de negociación de los trabajadores
- La caída del valor de mercado de habilidades desarrolladas durante años se parece al cambio en que artesanos y oficios manuales fueron sustituidos por trabajadores de líneas de ensamblaje
- La descalificación también puede verse como una mejora de eficiencia vía automatización: trabajar en un nivel de abstracción más alto
- La nueva tecnología oculta detalles y permite que el operador se concentre en el panorama general, pero decidir qué detalles “ya no importan” es un juicio crucial
- Los detalles de una abstracción terminan filtrándose tarde o temprano
-
Las fugas de la abstracción en el frontend “moderno”
- Las abstracciones suelen tener un costo de rendimiento, y sacrificar parte del rendimiento en runtime para ganar productividad de desarrollo puede ser razonable con servidores potentes y cargas normales
- En teléfonos móviles sobre redes lentas, ese mismo compromiso se convierte en un problema muy distinto
- El uso intensivo de frameworks pesados de JavaScript del lado del cliente, como React, junto con paquetes del ecosistema, abstrae problemas de accesibilidad y rendimiento en teléfonos de baja gama y redes lentas
- Como resultado, esas cuestiones dejan de pensarse y terminan sin recibir atención
-
La no determinación de la programación agéntica
- Cuando construyes una función o corriges un bug con IA agéntica, en vez de escribir tú mismo todo el código describes cambios de alto nivel con menos palabras
- La IA observa los datos de entrenamiento y el contexto circundante para completar los detalles omitidos; a veces acierta y a veces falla
- Que esto sea útil depende en gran medida de qué consideres importante en la programación
- La programación agéntica no es determinista como un compilador: pequeños cambios en la entrada o en el modelo pueden producir resultados muy distintos, así que tiene muchas más fugas que las abstracciones tradicionales de programación
- La razón por la que se compara la IA con un “ingeniero junior” también tiene que ver con esa no determinación, aunque con una diferencia: las personas pueden aprender sin que tengas que estar ajustando eternamente archivos AGENTS.md o SKILL.md
Los LLM son una continuación del copiar y pegar de Stack Overflow
- La analogía más cercana al uso de LLM es la forma en que antes se usaba la búsqueda en Google
- Saber elegir palabras clave precisas para hacer aparecer el post correcto de un foro o una respuesta de Stack Overflow en la primera página de resultados también era una habilidad que los desarrolladores tenían que aprender
- Un prompt para un LLM también busca devolver la combinación adecuada de datos de entrenamiento y se parece más a una consulta en un espacio de muy alta dimensión, como una búsqueda web difusa
- Los resultados de búsqueda eran sensibles a pequeños cambios en la redacción y a cambios en el índice de Google; los LLM también son sensibles a cómo se expresa la entrada y a cambios en el modelo
- Hace poco Google modificó la búsqueda para normalizar más agresivamente los términos de entrada; eso hizo la búsqueda más fácil para quienes no dominan el Google-fu, pero menos poderosa para los expertos
- Google y Stack Overflow cambiaron la programación de manera irreversible y permitieron obtener resultados que sorprendentemente funcionaban con bastante frecuencia simplemente copiando y pegando respuestas en vez de leer el manual
- Los LLM continúan esa misma tendencia
- Hacen un poco más rápido a quien sí sabe lo que está haciendo
- Permiten que quien no sabe muy bien lo que hace también construya algo que más o menos funciona
- Las abstracciones terminan filtrándose, y cuando eso pasa alguien tiene que entender a fondo qué está ocurriendo realmente y corregirlo
- Así como antes se enseñaba a los desarrolladores junior a leer y entender una respuesta de Stack Overflow antes de usarla, ahora hay que enseñarles a leer y entender la salida de un LLM y a ver cómo encaja en el codebase existente
La distancia entre calidad y negocio
- Algunos programadores nunca llegaban a entender de verdad las respuestas de Stack Overflow y consideraban suficiente que el resultado funcionara
- Muchas empresas, aunque no lo admitieran públicamente, estaban satisfechas con ese enfoque
- Ahora hemos llegado a un punto en que las empresas presumen públicamente cuánto usan IA sin siquiera fingir que revisan los resultados
- Existen claramente casos de uso válidos para los LLM, pero también muchas formas nuevas de arruinar el código y dañar la comunicación y los procesos de una organización
- Igual que con el code review, hay grandes diferencias de criterio sobre cómo usar e integrar LLM en el flujo de trabajo, y si eso no coincide con lo que valora el equipo puede generar problemas serios
- Muchas empresas siguen funcionando bien aunque produzcan software pésimo
- Aunque a los programadores les gustaría creer lo contrario, el éxito del negocio y la calidad del software solo rara vez están correlacionados
- Por lo general influyen más otros factores, como la marca o el precio, y los proyectos de software se tratan como cajas negras donde el éxito y el fracaso parecen igual de probables
- También en frontend, un sitio lento y lleno de banners de cookies puede perjudicar la conversión, pero ese impacto suele ser menor que factores como la lealtad a la marca o el precio, y muchas veces los sitios de la competencia también son lentos
- En un ambiente del tipo “nadie fue despedido por elegir React”, se priorizan decisiones seguras por encima de la calidad
- Esto no significa que haya que dejar de preocuparse por los usuarios y por el oficio, pero sí que se ha vuelto más difícil encontrar trabajos donde eso sea posible
- Cuando pase el sobrecalentamiento y se entienda mejor para qué tareas realmente encajan los LLM y para cuáles no, podría volver cierto equilibrio, pero el trabajo en sí ya no será igual que antes
Las habilidades que permanecen después de la industrialización
- Cuando los productos cotidianos y los edificios empezaron a poder fabricarse masivamente mediante procesos industriales, una de las respuestas fue producir en fábrica objetos y construcciones que imitaran estilos del pasado para parecer artesanales
- Frente a este historicismo, a inicios del siglo XX la Bauhaus desarrolló un enfoque que no enfrentaba a obreros de fábrica y artesanos, sino que buscaba que trabajaran juntos y rehacer el arte y la artesanía partiendo de los procesos de fabricación industrial
- La Bauhaus exigía que el diseñador volviera al taller y trabajara directamente con los materiales, pero con el objetivo final de crear diseños aptos para producción masiva
- El software se parece a la artesanía en que el programa escrito se entrega al usuario “tal cual”, sin pasar por una etapa de manufactura; pero también se parece al diseño industrial porque lo mismo se distribuye a miles de usuarios
- La capacidad de escribir código a mano sigue siendo necesaria y, así como un diseñador industrial debe conocer los materiales de un producto, un diseñador web debe dominar muy bien HTML y CSS
- Google, Stack Overflow, bibliotecas listas para usar y los LLM facilitan que los principiantes empiecen, pero también siguen reduciendo la barrera natural para hacer que algo funcione
- La industrialización produjo muchos objetos baratos de plástico pensados sin suficiente consideración por su uso y sus usuarios, pero el buen diseño industrial sigue existiendo
- Los procesadores de texto generaron muchísimos documentos con formato horrible, pero la tipografía y el diseño gráfico siguen existiendo
- Wix y Next.js hicieron posible crear muchísimos sitios lentos y poco accesibles, pero los profesionales del front of the frontend siguen existiendo
- La IA hace posible mucho AI slop, pero eso no significa que ya no se necesite a personas que saben lo que hacen y que se preocupan por su trabajo
Cambios y compromisos hacia adelante
- Como en otras industrias, es posible que la proporción del trabajo bien hecho se vuelva más pequeña dentro del total
- Al mismo tiempo, como será más fácil y barato construir cosas, el tamaño total del mercado seguirá creciendo
- Hoy es difícil saber si el número absoluto de personas pagadas por hacer bien el trabajo aumentará o disminuirá
- A veces producir rápidamente un prototipo o un MVP sí es la decisión correcta
- Si todavía no encuentras product-market fit, suele ser más importante iterar y aprender rápido que intentar dejar todo preparado para el futuro
- Pero sí necesitas saber qué estás tratando de aprender y cómo vas a validar ese aprendizaje
- Cuando llega el momento adecuado, normalmente conviene dar un paso atrás y rehacer las cosas bien desde el principio
- Por ejemplo, más adelante es muy difícil lograr buen rendimiento en un frontend con mala arquitectura
- Es más fácil empezar con un stack simple y agregar capacidades después que hacer lo contrario
- Mastro promueve explícitamente comenzar con un stack simple y buen rendimiento
- Ya sea que elijas comprar un servicio, usar una biblioteca open source, generar con LLM o escribirlo tú mismo, necesitas saber qué compromisos estás aceptando en cada parte del sistema
- Cuando baje la euforia, la industria terminará entendiendo que la IA es solo otra herramienta más en la caja de herramientas
- Hasta entonces, pueden seguir apareciendo código feo, comunicación rota y despidos terribles bajo el nombre de la IA
¿Quieres seguir recibiendo temas de tecnología seleccionados?
Sigue el canal de Telegram. @GeekNewsES
1 comentarios
Comentarios en Hacker News
Creo que la especialización profunda que OP extraña en realidad era bastante incómoda para mucha gente
Entiendo eso de vivir de dominar peculiaridades entre navegadores, implementar componentes accesibles a mano y la especificidad de CSS, pero para la mayoría eso se acerca más a la complejidad accidental. Que más gente pueda crear cosas claramente es algo bueno, y si parte del resultado es más lento o menos accesible, ese es un compromiso que se puede elegir
Se puede decir que las abstracciones imponen resultados que el usuario no eligió, pero también creo que un LLM podría entender mejor que yo las convenciones de accesibilidad
Pero los frameworks de altísimo nivel y ahora también los LLM han facilitado sacar rápido un MVP a medio cocinar mientras arruinan esas partes, y por eso la distancia entre lo “aceptable” y lo “bueno” se está haciendo mayor. Para quienes buscan hacer algo “bueno”, cada vez es más difícil competir contra quienes empujan lo “aceptable”
Al final eso se traduce en más horas extra y en una caída en la calidad del software, y quizá también en una baja general de la satisfacción laboral. Últimamente ya está pasando que hay que arreglar sitios web rotos o quitar estorbos con las herramientas de desarrollo y uBlock para recuperar funciones básicas, y he visto a otros aquí diciendo que hacen lo mismo (https://news.ycombinator.com/item?id=47042747). Antes, ni siquiera en la era de Flash o de los navegadores iniciales hacía falta meter mano así
También hay ejemplos menos anecdóticos: https://news.ycombinator.com/item?id=47390945
Peor aún, la mayor parte del dinero ahorrado con estos recortes termina solo en la cúpula de la organización
El AI mode de Google también tenía algo así, y otros sitios claramente parecen haber metido cosas parecidas por vibe coding
Al principio me confundía por qué se disparaba el uso de GPU y los ventiladores sonaban tan fuerte, pero ahora veo que es un error típico de la IA y que nadie prueba nada como se debe. Un humano también puede cometer ese error, pero hasta ahora casi nunca me había tocado verlo en toda mi vida
Como uso un monitor de 240 Hz, el navegador intentaba repintar 240 veces por segundo, y no me quedó otra que bloquearlo con uBlock Origin. Es absurdo
Lo peor es que a mitad de camino terminan contradiciendo su propio argumento
Por ejemplo, dicen que “decidir qué detalles importan o no es una decisión muy importante, a veces subjetiva, y al final los detalles siempre se filtran”; si es así, entonces esta nueva tecnología también termina recompensando la comprensión técnica profunda. Porque es inevitable. En eso estoy de acuerdo. Pero entonces, ¿por qué todo el tono general es “la IA está convirtiendo mis habilidades en una mercancía barata”?
Técnicamente, los sitios web en general han mejorado frente a hace 10 años. Tienen más funciones, son más rápidos, y SSL/accesibilidad/diseño responsivo se han vuelto valores por defecto más sólidos. Los problemas de las fábricas de contenido, el SEO y los sitios de noticias son otro patrón horrible de fracaso creado por la publicidad y los incentivos corporativos, no culpa de React
A veces un LLM puede aprovechar eso. Pero si la gente deja de escribirlas, ¿qué pasa después?
Estoy de acuerdo en que es bueno que más personas hagan cosas. Si todo lo demás fuera igual, mientras más mejor. Si la “IA” se hubiera metido en todas partes por mejoras innegables, la situación y el ánimo serían muy distintos
Aun así, la gente no tiene un derecho automático sobre el conocimiento “generado” a través del trabajo ajeno. Si la atribución y la compensación se trataran seriamente, y solo se pudiera entrenar con material pagado a quienes lo produjeron, quizá sería mucho más rápido y barato simplemente aprender CSS
Claro, a nadie le importa el uso de computadora/memoria del usuario, la degradación de la experiencia, el ancho de banda desperdiciado, ni el costo energético y el impacto ambiental añadidos para 8 mil millones de personas
¿También es “claramente algo bueno” que más gente construya infraestructura pública? ¿Si el resultado son peores carreteras, peores puentes y sistemas que fallan? Con el software pasa lo mismo y, de hecho, con la mayoría de las cosas
Gran parte de eso que este texto dice que el “desarrollo frontend” está perdiendo relevancia consistía en abrirse paso por un campo minado lleno de excepciones poco intuitivas, incompatibilidades entre navegadores, carga histórica y excepciones de excepciones de excepciones
El frontend moderno, es decir, esa “torre de abstracciones con fugas”, por fin se acerca a un modelo mental sensato para desarrollar para la web. Está forzado encima de ese explosivo conjunto de rarezas que son los estándares y convenciones web, pero aun así funciona, y que solo tenga unas cuantas fugas ya es en sí un logro
Seguimos en un campo minado de excepciones, y cuesta ver que las tecnologías con las que hacemos frontend se hayan vuelto limpias, predecibles y libres de carga histórica
Lo único que hicimos fue ponerle yeso encima de errores e incompatibilidades en los cimientos; no los resolvimos. React no resuelve el hecho de que HTML no fue diseñado como una caja de herramientas para UI. Next.js no resuelve el hecho de que JavaScript está lleno de errores de diseño que impiden que sea un lenguaje razonable, seguro y cuerdo. Tailwind no resuelve el problema de que CSS fue introducido de forma improvisada para maquillar un marcado que no fue diseñado para estilizar
Lo que hacen los LLM ahora es simplemente “conocer” dentro de un modelo estadístico los horrores que hay debajo del yeso. Ese modelo fue entrenado con ejemplos de una era en la que el 99% de los casos consistían en volver a tapar grietas de capas anteriores de yeso
Si no te sales de un conjunto pequeño y razonable de buenas prácticas, puedes ofrecer una experiencia bastante buena solo con unas cuantas librerías aburridas y probadas
Pero en cuanto te enredas con el framework frontend de moda de hoy, o peor, con el framework de moda de ayer, o tienes que acomodarte a las extrañas preferencias de otros desarrolladores que insisten en una sola forma de hacer las cosas, o empiezas a lidiar con hacks “geniales” pegados con esperanza y cinta adhesiva, la complejidad y la forma en que interactúan las cosas aumentan exponencialmente
Yo viví esa época. El JavaScript puro solo para IE6 fue reemplazado por jQuery lleno de bugs, luego por aplicaciones de una sola página en Angular imposibles de mantener, y después por monstruosos codebases de React
En realidad es mucho más que eso
He visto demasiadas personas llegar a entrevistas diciendo que son expertas en Next.js, pero muchas veces no saben hacer nada más. Eso no es una habilidad, es solo conocimiento, y hoy está regado gratis por todos lados
Que algo no haya sido diseñado perfectamente desde el principio por un comité no significa que puedas olvidarte de todo, cerrar el libro y dejar que una máquina haga los cálculos
Yo también hago lo segundo, así que sé en qué se equivoca, pero eso no significa que me vaya a dejar engañar al punto de crear un desastre imposible de mantener. Cada vez que los agentes se descarrilan, mis habilidades de frontend resultan realmente útiles
La idea de que “el frontend era una disciplina altamente especializada que requería conocer HTML semántico, CSS, diferencias entre navegadores, accesibilidad, mejora progresiva, rendimiento de red, diseño de interfaces, pruebas con usuarios, etc.” probablemente les sonaría bastante graciosa a los desarrolladores frontend de la generación anterior, es decir, a los desarrolladores de C/C++
La web fue vista como algo que bajó muchísimo la barrera de entrada y desprofesionalizó la habilidad técnica. Los programadores de ensamblador probablemente pensaban algo parecido de los desarrolladores de C/C++
Pero todas las capas están equivocadas. Cada capa está construida sobre abstracciones de la capa inferior. Si bajas hasta la física y las matemáticas, ves que hasta los teóricos de conjuntos asumen ciertos axiomas. Nadie sabe qué hacen los lógicos
La lógica de “me entristece que el nuevo proceso produzca resultados de menor calidad y que a mucha gente no parezca importarle” parece apoyarse en la premisa de que antes de la IA, la mayor parte de este trabajo la hacían artesanos expertos comprometidos con la calidad
Cualquiera que haya trabajado de verdad en la industria y sea honesto sabe que esa no era la realidad. Había muchísimo trabajo por debajo de lo mediocre
Además, según cómo definas “calidad”, ni siquiera está claro que los resultados de la IA sean de menor calidad. La IA puede producir una uniformidad incómoda, pero al mismo tiempo también genera resultados bastante utilizables porque, para bien o para mal, las convenciones que aprendió el modelo “funcionan” para la mayoría de los usuarios finales
Ya existía mucha presión para hacer apenas lo mínimo que cumpliera con los requisitos y declararlo un éxito. Ahora esa presión se siente inmanejable
Aun así, coincido en que eso ya había desaparecido antes de la IA
Si hablamos de baja calidad, de hecho eso era lo más común en esa época
Últimamente yo también había pensado algo parecido.
Hace al menos 10 años que casi no hago desarrollo frontend, pero ya tengo la edad suficiente para recordar esa época de finales de los 2000 en la que, de repente, todo el mundo empezó a usar frameworks en vez de construir a mano una GUI web, y todavía se burlaban de quienes seguían escribiendo HTML/CSS/JS y consultas a la base de datos manualmente. Las ofertas de trabajo también empezaron de pronto a pedir Ruby on Rails, Django, Spring, GWT y más tarde Angular, en lugar de PHP/HTML/CSS/SQL/JS.
Se siente extrañamente familiar a lo de ahora. Aunque no tuvieras conocimientos profundos, podías hacer una aplicación web funcional en unos minutos, y parecía magia. Después ibas personalizando dentro del framework hojeando la documentación y buscando cosas, hasta que en algún punto ya no podías seguir, porque no tenías idea de cómo funcionaba internamente. Igual que con una webapp de vibe coding, una app web armada en una tarde pegando un framework estándar se reconocía desde lejos, pero a los gerentes les impresionaba bastante.
Lo interesante es que los desarrolladores hablan de su modelo de frontera favorito casi de la misma forma en que los desarrolladores de GUI de hace 15 o 20 años hablaban de los frameworks web que les gustaban. Personifican la herramienta e incluso se identifican con ella, se frustran porque algo que funcionaba en la versión X empeoró en la X.1, y vuelven a aparecer frases como “ahora desarrollo 10 veces más rápido” o “voy a volver a escribir XYZ a mano”.
Tampoco es una ventaja tener una GUI hecha en casa que nadie más sabe manejar.
Personalmente rechazo cosas que se “sienten” demasiado grandes, como Nuxt/Next, pero sí me gusta Vue. Aun así, ahora quiero eliminar la mayor parte posible de JavaScript e irme por soluciones del estilo HTMX o Alpine junto con plantillas del lado del servidor.
En lo personal, mientras menos tecnologías use, mejor. También hubo una época en la que las webapps ya venían llenas de todo tipo de cosas inútiles antes incluso de agregar una sola línea de código personalizado.
En 2004 también hice sitios con un enfoque básico de poner archivos txt en un árbol de directorios y hacer que PHP los insertara en HTML agregando etiquetas en vez de saltos de línea. La alternativa en ese momento eran sistemas de gestión de contenido pesados.
Llegué a Django después de pasar en el trabajo por dos horribles frameworks PHP hechos por los lead developers, así que un framework como Django fue una transición más gradual y mucho más agradable.
Claro, si seguías empujando más allá, por ejemplo agregando control de versiones a los objetos, se volvía muy complicado, dejaba de haber garantías de que funcionara y ya tampoco había forma de arreglarlo.
Aun así, la actitud en sí se ve parecida a la de ahora.
Estamos en la industria del software. El corazón de esta industria es automatizar tareas muy repetitivas.
Los proyectos frontend son muy repetitivos, y ahora la IA se encarga de eso. Es algo excelente, y libera mucho tiempo para crear cosas más interesantes.
Que una habilidad que ya no es tan relevante se desprofesionalice es algo que viene pasando en la industria desde que se inventaron las computadoras. Pasó porque resolvimos el problema, ya sea con IA o de otra manera.
Solo hay que seguir adelante y aprender la nueva tecnología. De hecho, usar la IA de manera efectiva también es una habilidad que a algunas personas les cuesta. Las cosas todavía no se construyen solas. Si das el prompt correcto, lo puede lograr, pero ¿realmente estás dando el prompt correcto? ¿La herramienta está haciendo lo que pediste? ¿Cómo lo sabes? ¿Lo verificaste? Yo también paso una enorme cantidad de tiempo dándole prompts a la IA, y sin duda estoy mejorando, pero sigue siendo casi un trabajo de tiempo completo.
Dentro de unos 10 años miraremos atrás y pensaremos que esta era una manera muy ineficiente de hacer software. Las herramientas van a mejorar y la IA será más autónoma. Si pasas todo el día repitiendo los mismos prompts, alguien o algo también tiene que automatizar eso.
La queja aquí es que esa automatización corre el riesgo de codificar algo que no querías.
El mundo necesita muchísimo más software del que hoy podemos construir.
Es una opinión tan mala que ni sé por dónde empezar a refutarla. ¿Lo repetitivo sería que todas las UI tienen botones?
Si de verdad la gente cree eso, se entiende por qué la UX está arruinada desde los 90 y luego fue empeorando.
La programación con IA ayuda mucho a crear prototipos de producto, pero al mismo tiempo también produce productos que se nota a la distancia que fueron hechos con IA.
Justo ahora una startup hizo una demo de su app, y la app tenía totalmente esa vibra de UI de vibe coding.
El feedback que recibieron fue frío, pero acertado: “Está bastante bien, pero se nota demasiado que está hecho con IA, y en ese caso cualquier otra persona que quiera esto también podría hacerlo muy rápido con IA, así que lo que están tratando de vender no tiene mucho valor”.
Pero la mayoría ni siquiera pone ese nivel básico de cuidado.
Las esquinas redondeadas siguen siendo una moda eterna, y parece que todo lo que ya no está bien definido termina infectado por esa forma.
Un inversionista de riesgo competente no daría un feedback tan vacío. Si es bueno, es bueno; ¿qué importa si lo hizo una IA? ¿Entonces habría estado bien si fuera un producto de la misma calidad pero no se notara el vibe coding? Eso solo le importaría a alguien ideológicamente opuesto a la IA.
A veces siento que las técnicas para crear interfaces de usuario complejas solo con HTML, sin AJAX ni manipulación del DOM, como se hacía a inicios de los 2000, prácticamente se perdieron como si fueran una técnica de construcción de pirámides.
Hay un aspecto de “desprofesionalización” en los desarrolladores full stack jóvenes; por ejemplo, muchos piensan que para validar formularios hace falta JavaScript.
Una vez que empiezas a usar AJAX y a manipular el DOM, la complejidad de la comunicación asíncrona casi inevitablemente termina convirtiéndose en algo de una escala parecida a React. Aunque puedas escribir algo como
document.title="A new title"y no necesites traer ninguna librería, incluso si ves el frontend simplemente como “actualizar la UI cuando llegan datos del servidor”, una aplicación compleja tiene que actualizar varias partes de la UI, y en algún momento terminas creando algo como un mecanismo de comunicación o un bus de manejo de estado. ¿Que si se podía construir de otra forma? Claro que sí.Si hay un problema con el ecosistema de React, no es que cree una abstracción sobre otra abstracción, sino que esa abstracción tiene fugas. Si haces algo muy simple y no te importa demasiado cómo se vea, puedes usar Bootstrap o MUI sin entender CSS. Pero si quieres entregar un trabajo de nivel profesional para poner frente a clientes, tienes que entender HTML, CSS, JS y todos los frameworks que use el proyecto.
La mayoría de quienes critican React en realidad no entienden qué problema resuelve. Si les muestras código fuente de una webapp lo bastante compleja que no dependa de React, pueden encontrar dentro una imitación de React hecha a mano.
No estoy de acuerdo con que operar una aplicación frontend usando renderizado del lado del servidor, carga diferida, etc. de NextJS sea “más fácil” que en la época en que solo se usaban HTML, JS y CSS.
El nivel de complejidad y las expectativas de los usuarios están en lugares completamente distintos.
Además, ahora hay como 1000 veces más ingenieros capacitados y hay que competir en un mercado global. A principios de los 2000 casi no había competencia. Las habilidades de los trabajadores suelen tener una correlación más bien laxa con el nivel que exige el mercado, pero ahora es extremadamente competitivo.