DEV Community: Sebastian peralta

La paradoja de la velocidad: La ilusión de la productividad infinita y el cansancio invisible de la IA.

Sebastian peralta — Fri, 11 Sep 2026 14:30:00 +0000

Hace unos días, tuve que hacer algo que hacía mucho tiempo no consideraba necesario en mitad de una jornada laboral: apagar la pantalla, ponerme los zapatos y salir a caminar a la calle. No salí a buscar un café, ni a despejar una duda técnica compleja. Salí porque sentía que mi cabeza iba a colapsar, abrumada por una fatiga densa y difícil de explicar. Un cansancio que no proviene de haber escrito miles de líneas de código lógico complejo, sino de algo mucho más sutil y moderno: el desgaste cognitivo de trabajar codo a codo con una Inteligencia Artificial.

Mientras caminaba, un monólogo comenzó a estructurarse en mi cabeza. Y es que hoy en día, la IA generativa ya es una herramienta completamente estandarizada en el desarrollo de software. Es casi imposible vislumbrar nuestro flujo de trabajo diario sin ella. Nos ha hecho olvidar, con una rapidez pasmosa, aquellos años en los que el razonamiento puro, la lucha directa contra el compilador y los pequeños triunfos cotidianos frente al código estructuraban nuestra profesión. Parece que esa época fuera un pasado prehistórico, pero si hacemos retrospectiva, la realidad es que no llevamos más de tres años utilizando modelos de IA de manera verdaderamente productiva en nuestro día a día.

La tecnología es fantástica, de eso no hay duda. Pero detrás de la euforia colectiva y los feeds repletos de promesas de productividad infinita, se esconde una realidad incómoda de la que muy pocos están hablando: trabajar con IA es profundamente agotador.

La ilusión de la abundancia estética y el MVP infinito

Si entras a LinkedIn, X o cualquier comunidad de programadores, el panorama es idéntico: decenas de personas celebrando cómo construyeron un MVP (Producto Mínimo Viable) en dos horas, un clon de un juego clásico en una tarde o una landing page vistosa en cuestión de minutos. Al principio resulta asombroso, pero después de un tiempo, empieza a ocurrir algo curioso.

Empezamos a ver los mismos estilos visuales, las mismas tipografías repetitivas, las imágenes súper saturadas y sin una identidad real. Todo se produce en masa, con el mismo molde invisible. Ver lo mismo una y otra vez, bajo la fachada de la innovación constante, agota. Esta saturación no solo inunda el mercado de productos que se sienten vacíos, sino que también altera nuestra propia psicología sobre cómo construimos soluciones. Nos desconecta del propósito original de crear cosas únicas.

Recuerdo (y lo digo casi con una nostalgia extraña, como si hablara de una era lejana) cuando resolver un problema implicaba sentarse a pensar minuciosamente en cada componente. Nos tomábamos el tiempo para diseñar los flujos de datos, estructurar los contratos entre servicios y detallar las interacciones lógicas. En ese flujo, escribir código era el catalizador de las ideas. El editor no era un receptor pasivo; la propia sintaxis y la interacción con la terminal hacían que las ideas fluyeran, mostrándonos de manera interactiva e inmediata en dónde estábamos fallando.

Hoy, la satisfacción de ver nacer algo tangible desde tus propios dedos se siente diferente. Trabajar con IA a menudo significa enfrentarte a un lienzo en blanco en formato Markdown y redactar, de forma casi burocrática, un contexto gigante, un objetivo ultra específico, una lista de tareas detalladas y un paso a paso rígido.

Sí, sigue siendo ingeniería de software, los contratos, los componentes y flujos estan alli pero trasladar ideas fluidas del cerebro al lenguaje natural de forma tan meticulosa para que una máquina no se pierda es un proceso mentalmente agotador. Requiere un nivel de detalle absoluto sobre cosas que antes descubríamos y resolvíamos de forma orgánica mientras escribíamos el código.

El colapso de la inferencia: la iteración que nos drena

El gran problema radica en que los modelos de lenguaje funcionan mediante inferencia. Y por más detallado, estructurado y claro que sea tu prompt, la IA no deja de inferir.

En esa inferencia, el modelo inevitablemente puede terminar obviando detalles que para ti eran fundamentales. En lugar de seguir el flujo arquitectónico que planificaste con cuidado, la IA decide tomar un atajo creativo y se desvía del camino planteado.

Es verdad que, de vez en cuando, esa inferencia te sorprende con una solución ingeniosa. Pero en la mayoría de los casos cotidianos, cuando has invertido un tiempo considerable diseñando contratos de entrada, contratos de salida, flujos de datos y componentes, ver que esa planificación colapsa es frustrante.

El proceso de creación ya no ocurre en tu editor, sino que se reduce a una experiencia claustrofóbica: observar una pequeña pantalla, una terminal o un chat que te escupe líneas interminables de texto explicativo, denso y muchas veces sin sentido real para tu contexto específico. Al final, miras el resultado en pantalla y la sensación que te queda no es la del triunfo del creador, sino un frío: "Esto no es lo que yo quería. Esto no lo hice yo".

La paradoja de la velocidad y el "Brain Rot" de la productividad

Hagamos números sinceros. Desarrollar y entregar tres features que antes te tomaban una semana o dos, y poder completarlos hoy en día en apenas uno o dos días es, en términos de métricas de negocio, algo absolutamente fantástico. Cualquier mánager o cliente estaría saltando de la felicidad. Pero el costo biológico es devastador.

Nunca antes en mi carrera como ingeniero de software —habiendo vivido ya varias transiciones tecnológicas— había terminado mis jornadas laborales con este nivel de desgaste mental. Es un agotamiento tan particular que la única analogía moderna que encuentro es el fenómeno del "Brain Rot" (deterioro cerebral) que provocan las redes sociales.

Trabajar iterando constantemente con IA se siente exactamente igual a pasar horas haciendo scroll infinito en tu celular. Es una batalla campal por tu atención. Tu mente está expuesta a estímulos rápidos, cortes abruptos de información, textos generados a la velocidad de la luz y fragmentos de código que debes validar en microsegundos. Escroleas, lees, pruebas, corriges, vuelves a escrolear. Al final del día, has visto y procesado una cantidad descomunal de información, pero sientes que no le encuentras un sentido real a nada. Estás profundamente cansado de la tecnología, pero la inercia te impide detenerte porque sigues esperando que en la próxima iteración, en el próximo prompt, aparezca esa solución mágica que te devuelva el control.

Apagar la máquina y ver el mundo fluir

La inteligencia artificial es una herramienta magnífica y ha llegado para quedarse; negar su utilidad sería absurdo e hipócrita, tambien trajo consigo una manera distinta de trabajar y generar soluciones. Sin embargo, no podemos seguir vendiendo la narrativa de que todo en esta era es perfecto, fluido y maravilloso. Aunque he logrado construir cosas fantásticas gracias a ella, también he tenido días donde el desgaste cognitivo me ha dejado completamente vacío.

Es fundamental que empecemos a hablar abiertamente de este agotamiento. Quizás, al visibilizarlo, la industria comience a diseñar mejores interfaces, flujos de trabajo más humanos o estándares de desarrollo donde la creación tecnológica no demande una factura mental tan elevada.

No sé si soy el único ingeniero de software que termina su jornada con una fatiga que va más allá de un simple dolor de cabeza; un verdadero "off creativo" que te quita las ganas de seguir experimentando o construyendo proyectos personales en tu tiempo libre.

Pero he aprendido que está bien aceptar ese límite. Está bien admitir que la velocidad infinita no siempre es sostenible. Cuando ese cansancio invisible aparece, lo mejor que podemos hacer por nuestra salud mental y nuestra propia creatividad es cerrar la computadora, desconectarnos por completo de la tecnología y darnos el permiso de, simplemente, salir a caminar y ver el mundo fluir.

Contenido vs Interactividad: Como elegir tu siguiente Framework Web

Sebastian peralta — Wed, 21 Jan 2026 23:05:16 +0000

Catedral de sal, Zipaquirá, Colombia

Hoy en día, el frontend está más vivo que nunca. Y aunque suene arriesgado afirmarlo en el momento que vivimos, la irrupción de la Inteligencia Artificial (IA) ha convertido a la Web en una de las plataformas más rápidas y accesibles para crear soluciones, productos y todo tipo de ideas. La facilidad con la que podemos visualizar cambios, sumada a miles de proyectos de código abierto, artículos y libros, ha alimentado a los modelos de IA con un enorme volumen de datos para entrenarse.

No quiero decir que el entorno web sea la única opción viable, pero es muy probable que la IA generativa obtenga mejores resultados allí que en otros entornos. Sin embargo, esto parece tener un costo: cada vez más, es la propia IA la que empieza a influir —y en muchos casos a determinar— las herramientas con las que construimos software.

Recuerdo que mis primeros pasos en la “programación real” fueron con Java. Por aquellos años, 2016/17, era lo que dominaba en la universidad —o al menos eso nos hacían creer—. Un día asistí a una clase de semestres superiores y vi la exposición de un proyecto construido con HTML, CSS, JavaScript y jQuery. Para mí fue un shock: una aplicación moderna, con animaciones, efectos y una estética que jamás había visto en mis proyectos. En comparación, mis aplicaciones en Java se sentían rígidas, llenas de código, casi estáticas y difíciles de personalizar, claramente el problema no era Java, sin embargo, para el contexto en el que me encontraba me era imposible imaginar dicho elementos visuales allí. Ese día decidí que quería entrar al mundo del frontend web.

Algo maravilloso fue lo rápido que podía aprender —y también lo fácil que era adoptar malas prácticas—. Me pasaba horas clonando mis páginas favoritas, creando formularios (por alguna razón me obsesioné con ellos) y dando vida a elementos gracias a jQuery. En esa etapa pensé genuinamente que no existía nada mejor. Pero toda mi “web” vivía en local, y cuando intenté publicar mi primera página me encontré con una barrera técnica que, en ese momento, simplemente no podía cruzar.

Tiempo después, en mi primer trabajo, tuve que usar Angular. Apenas sabía qué era un framework, pero todos hablaban de React y de las SPA. No tenía claro qué significaba ese concepto; solo entendía que estaba en todas partes y que era “lo moderno”. Recuerdo pensar: “Wow, al parecer ya no se necesitan archivos HTML, CSS y JavaScript separados”.

Angular seguía una idea similar, pero se notaba distinto: las plantillas tenían su propia sintaxis y reglas, y era evidente que había un enfoque más estructurado detrás.

Con los años —y varios errores— fui entendiendo que no todo es un clavo ni todo se resuelve con el mismo martillo. No quiero recordar el e-commerce que construimos en React vanilla y al que luego tuvimos que agregar SEO, o aquella aplicación en Vue que necesitaba tiempos de carga casi instantáneos, o la landing page que intentamos hacer en Angular. Al final, comprender las bases, los requerimientos y la filosofía detrás de cada tecnología me llevó a una conclusión inevitable: muchas veces elegí mal una tecnología, o participé de malas decisiones; pero sin esos tropiezos jamás habría investigado el por qué y el para qué de cada herramienta, por eso, en este escrito quiero compartir una de las claves que me ayudaron a entender mejor este sinuoso mundo.

MATRIX

Matrix ha sido una de esas películas que me marcaron. La considero un hito en muchos aspectos, y una de las escenas que más recuerdo es cuando Neo debe elegir entre la píldora roja y la píldora azul. Aunque suene curioso, en el mundo del frontend podemos encontrar algo similar, con una pequeña variación: Contenido o Interactividad. Estas dos palabras serán nuestro punto de partida para tomar decisiones sobre tecnologías del lado del cliente. Y aunque parezcan simples, esconden muchos patrones detrás. Así que tomemos una “píldora” y avancemos.

Cada tecnología soluciona uno o varios problemas y, aunque en la simulación parezcan adecuadas para todo, la realidad es que suelen responder a una arquitectura y, por ende, a un nicho específico dentro de las soluciones web. Esta elección determinará nuestra DX (Experiencia de Desarrollo), y en un equipo de software esto es vital: si elegimos algo inadecuado, podemos terminar enfrentando retos interesantes… pero que probablemente no deberían ser el centro de nuestro desarrollo.

Empecemos por Contenido. Si elegiste esta palabra, existen muchos patrones arquitectónicos de renderizado que la toman como referencia, Estos patrones están presentes en tecnologías como Next.js, Nuxt, SvelteKit, Astro o Gatsby etc. Algo que puede sorprenderte —o no— es que este tipo de soluciones no son nuevas; al contrario, son de las más antiguas. Así fue como construimos la web en sus inicios.

Normalmente, este enfoque aparece cuando queremos construir blogs, portfolios, documentaciones o sitios de divulgación de contenido vía streaming. En estos casos, el mayor valor suele estar en el contenido que se ofrece al usuario: textos, imágenes o videos. Ahí se encuentra su punto de retención. Dependiendo del objetivo, una tecnología puede ser más adecuada que otra. Si el contenido cambia poco con el tiempo y requiere bajo mantenimiento, Astro o Hugo pueden ser muy buenas opciones. Muchas de estas herramientas ya cuentan con integraciones con CMS como Strapi o Sanity. Si necesitas algo de interactividad (muy mínima), Astro o HTMX podrían ser una mejor elección. Para documentación, herramientas como Storybook o Docusaurus pueden sacarte de más de un apuro. Lo importante aquí es entender el requerimiento y, a partir de eso, seleccionar la herramienta.

Por otro lado, tenemos la Interactividad. Aquí se sitúan las aplicaciones y plataformas cuyo valor principal está en la interacción del usuario. Aunque la UX también juega un papel clave, en este tipo de aplicaciones importan métricas como los clics, las transiciones suaves, la respuesta inmediata, la alta disponibilidad y la capacidad de reaccionar a cualquier estímulo del usuario.

Ejemplos claros son Google Drive, Notion, Excalidraw, aplicaciones administrativas o dashboards internos.

Es en este contexto donde entran en juego las SPA, que siguen un patrón de renderizado conocido como Client Side Rendering. Al manejar gran parte de la lógica en el cliente (el navegador), a la aplicación le resulta más sencillo responder a este tipo de interacciones. Aquí el “recetario” es mucho más amplio: React, Vue, Svelte, Solid, Angular, Next.js, Nuxt o SvelteKit.

Notarás que vuelvo a mencionar algunas de estas herramientas, y es porque muchas veces nos enfrentamos a problemas donde tanto el contenido como la interactividad tienen un peso similar. Estas tecnologías, al soportar distintos patrones de renderizado (tema que no profundizaremos aquí), permiten combinar lo mejor de ambos mundos. Sin embargo, como casi todo en software, los casos son específicos y dependen profundamente del producto y de cómo debe responder al usuario.

Si llegaste hasta aquí, gracias por leer. Este es mi primer artículo. Posiblemente no se cubrieron todos los casos, pero espero haberte dejado algunos conceptos —o al menos una semilla de intriga— que te ayuden a indagar mejor y a evitar algunos errores que, en su momento, yo no pude evitar, recuerda que elegir un framework no es elegir una tecnología, es elegir qué problema estás dispuesto a priorizar.