Discusión de Panel: Fullstack está Devorando Frontend — ¿Deberían Adaptarse los Ingenieros FE?

Bien, ¿están todos listos para comenzar con esto? Vamos a empezar. Creo que el lugar fácil para ir con una pregunta como esta en general sería si full stack es algo en lo que los desarrolladores específicos de frontend deberían estar invirtiendo su tiempo, o debería el frontend mantenerse como una especialidad? ¿Hay alguien que se sienta fuertemente sobre esto? Alem. Sí. Entonces, comencé hace como 10 años, y comencé a trabajar en Laravel, que es algo así como full stack porque tienes que hacer cosas del cliente y del servidor. Y siempre he luchado esta batalla porque más tarde me especialicé en desarrollo frontend, y siempre he luchado esta batalla con todos los que trabajan a mi lado, que siempre deberías ser un generalista y entender el sistema completo. Y la razón detrás de eso es porque, por ejemplo, cuando quieres hablar con un endpoint de backend, si sabes cómo deben estructurarse y enviarse los datos, puedes moldear la API y hacerla mejor y más eficiente en ambos lados, simplemente hablando con el desarrollador de backend y diciendo, oye, ¿qué tal si agrupamos estos campos juntos, o tal vez almacenamos en caché estas cosas? No tienes que entender realmente el sistema completo detrás de esto, pero conocer lo básico siempre fue importante. Y siempre trazo la línea entre los doctores. Los doctores también tienen subespecialidades, y se especializan en una cierta parte del cuerpo o algo así, pero siguen siendo doctores. Saben cómo funciona todo el cuerpo. Y siento que los desarrolladores deberían ser iguales, donde sabemos cómo funciona todo el sistema, pero aún nos especializamos en algo como desarrollo frontend, desarrollo backend, porque a todos les encanta una cierta parte del desarrollo de software. Y debería haber especialidades, pero creo que deberíamos conocer el sistema completo. Sí. Entonces, lo que estás diciendo es que los desarrolladores son doctores. Sí. OK. Pero para software. Me encanta eso. Sí. Pero nuestro software no muere si cometemos un error. Sí. Eso es genial.

Kevin? Estoy de acuerdo en general contigo, pero voy a desafiar una parte de tu declaración, que fue, oh, definitivamente deberían hacer full stack. Creo que todos necesitamos expandirnos en diferentes direcciones, tener una especialidad. Pero no tiene que ser hacia la ingeniería de backend. Podrías expandirte hacia un área de experiencia en materia de contenido. Podrías expandirte hacia entender más el diseño, la investigación de usuarios, otras partes del producto. Creo que estamos terminando una era donde podemos especializarnos en un área particular de tecnología, la mayoría de nosotros, y aún así poder tener una buena carrera. Creo que la tecnología podría ser tu superpoder que traes, y luego navegas hacia otros espacios. Creo que podría desafiar un poco eso.

Hazlo. Desafío. Sí. Creo que en la era de la IA, los especialistas son más importantes que nunca, porque la IA nos permite a todos ser generalistas muy rápidamente. Así que sé que muchos de nosotros probablemente hemos codificado algo en un lenguaje que probablemente nunca hemos escrito antes. Ahora es realmente fácil obtener lo básico más rápido que nunca. Así que creo que eso hace que el valor de ser un especialista sea exponencialmente más importante. Sí, creo que estoy de acuerdo contigo, de hecho. Creo que antes de la IA, todavía podías tener esta pregunta sobre si tiene sentido llamarte a ti mismo un desarrollador frontend o full stack.

Comencé con Rails porque quería hacer productos completos, de extremo a extremo. Y así estaba haciendo desarrollo full stack. Luego me enamoré de JavaScript del lado del cliente y las micro-interacciones y la animación y CSS. Así que ahora me considero un desarrollador frontend, no porque no pueda escribir código de servidor o crear un producto completo, sino simplemente porque ahí es donde paso la mayor parte de mi enfoque, es la especialización. Y creo que después de la IA, es interesante porque... No sé si has tenido esta experiencia, pero si hablo con una persona de backend que es bastante de backend y dicen, me encanta la IA, hombre. Siempre odié lidiar con algunos componentes de React juntos para construir un frontend. El estilo siempre no funcionaba. Y ahora la IA simplemente hace el código frontend tan bien, que ya no tengo que hacerlo. Y estoy sentado allí como, ¿en serio?

Para mí, de hecho, configurar este nuevo servicio de backend con AWS y escribir este Python... Ni siquiera tengo que aprender esas cosas. La IA lo hace tan bien, pero hace un trabajo pésimo en el código frontend. Así que creo que todos están diciendo lo mismo, lo que solo me dice que todavía hay valor para una especialidad, ¿verdad? En que si estoy haciendo algún pulido, alguna micro-interacción, o simplemente realmente enfocándome en los detalles de alguna interfaz, tengo que saber qué decirle a la IA, si es que va a ser útil. Así que sí, creo que todavía tiene sentido tener una designación de desarrollador frontend, si eso es en lo que eres experto.

Sí. Pero creo que es solo una especialidad, ¿verdad? Como, la IA es realmente buena en las cosas de las que sabes poco. Y menos buena en las cosas de las que sabes mucho. Así que sí, totalmente. ¿Qué piensas? Sí, creo que estoy un poco indeciso en este tema. Comencé mi carrera como diseñador, desarrollador frontend. Así que creo que estoy un poco obligado a decir que debería existir y continuar. Pero al mismo tiempo, con plataformas como Neon y con las plataformas de despliegue modernas y desplegando en Railway y teniendo un archivo de configuración de 10 líneas para iniciar tu despliegue, realmente no hay una excusa, creo, en esta etapa para asumir eso como una habilidad secundaria incluso si no es tu especialidad. Pero creo que en términos de desarrollo frontend, creo que hay algo especial en alguien que está especializado en desarrollo frontend, que conoce el diseño, que tiene ese gusto específico y ese nivel de conciencia con diferentes tipos de sistemas de diseño o simplemente cuando algo se ve bien o simplemente no se ve bien, que no siempre puedes obtener como generalista. Sí. Creo que deberíamos tomar un trago cuando alguien dice gusto. Porque ya me he sorprendido a mí mismo diciéndolo como tres veces hoy. Así que me encanta eso. Mencionaste Rails, que se siente como tal vez incluso el tal vez no el inicial de personas escribiendo full stack, ¿verdad? Porque tenías UI, tenías backend, tenías todo, ¿verdad? ¿Es el mundo ahora con, ya sea React Server components o la revitalización de la renderización del lado del servidor llegando a todos usándolo todo el tiempo para todo, están los mundos de backend y frontend inherentemente fusionándose y colisionando? Para siempre. Bueno, es gracioso escuchar. Si miras algunos de los primeros videos de DHH hablando sobre Rails, tuvo que ir en una cruzada para convencer a la gente de que estaba bien que los desarrolladores de aplicaciones configuraran bases de datos. Solíamos tener ingenieros de bases de datos para configurar bases de datos. Tenían opiniones fuertes sobre cómo deberías nombrar tus claves y tus claves primarias, tus claves foráneas, qué índices deberías tener, y detalles muy particulares sobre la base de datos. Y tenías que hablar con ellos para configurar tu base de datos y conectarla con tu servidor Rails. Y todo su asunto era tratar de comprimir esa complejidad en el framework y dar al desarrollador de aplicaciones control sobre eso. Así que no necesitaban un ingeniero, pero también para que pudieran configurar la base de datos de una manera que sirviera a las necesidades de su aplicación. Y de la misma manera que estabas hablando, así es como lo he visto desarrollarse en los últimos 10, 15 años con los desarrolladores frontend, es cuando comencé, tenías que saber cómo hacer funcionar LAMP stack en tu computadora para que PHP hablara con MySQL para servir. Ni siquiera había un SPA en ese entonces. Pero básicamente, para consultar tus datos y renderizar algo y luego hacer puntos finales de API para tu SPA. Y mucho de lo que los frameworks han tratado de hacer es abstraer más de esas cosas, poner eso en manos de los desarrolladores frontend, desarrolladores de aplicaciones, realmente. Así que hoy, de la misma manera que Rails te permitió no necesitar un ingeniero de bases de datos para configurar una base de datos, pero podrías hacerlo como desarrollador de aplicaciones, hoy puedes configurar capas de caché y CDNs basadas en las necesidades de tu aplicación. Con componentes de caché, por ejemplo, en Next.js, puedes elegir. Tú como desarrollador de aplicaciones sabes que esta pantalla no cambia mucho, así que vamos a pre-renderizar y ponerla en un CDN global. Y hago eso desde mi código de aplicación. No voy a un Varnish y aprendo a escribir una capa de CDN de Varnish.

Está impulsado por la aplicación. Y así, en ese sentido, creo que el desarrollador de producto es como el frontend está comiendo más del stack y dando más control a los desarrolladores frontend debido a esa tendencia. Y creo que con la IA, la IA te permite hacer eso indirectamente, supongo. No necesitas un experto, pero también está alimentando esta tendencia más amplia que hemos visto desde Rails y ahora con más del stack e infraestructura bajo nuestro control.

Sí. Así que voy a presionar esto de otra manera. Estabas describiendo un poco lo que sucede cuando el desarrollador backend escribe algo de código React y dicen, sí, puedo hacerlo, así que simplemente lo vamos a hacer. Y he revisado esos PRs. Son miserables. Creo que la separación de preocupaciones sigue siendo valiosa. React repensó, fue el framework original que repensó cómo deberíamos separar preocupaciones en el frontend y dijo, oye, no es CSS versus JavaScript versus HTML. Deberíamos separar por componente. Eso es extremadamente productivo. No creo que la forma en que las cosas están separadas en el frontend funcione muy bien para muchos de los patrones que quieres hacer en el backend.

Aún no he visto una aplicación muy grande de NextJS que hiciera ambas cosas que no me hiciera querer sacarme los ojos. Sí. Intervendré aquí. Creo que fue Brad quien habló sobre la separación entre la parte trasera del frontend y la parte delantera del frontend. Y realmente me gusta esa distinción, porque creo que estamos empezando a ver casi dos clases separadas de ingenieros frontend, y hay una especie de ingeniero de la parte trasera del frontend que está realmente interesado en hacer ese tipo de trabajo y configurar la renderización del lado del servidor y manejar todos esos problemas de rendimiento. Y luego también vemos un ingeniero muy de la parte delantera del frontend, que está más enfocado en CSS y accesibilidad y diseño. Y así casi diría, ya sabes, ¿está el full stack comiéndose al frontend? No lo sé. Creo que el frontend en realidad está creciendo, y estamos viendo casi subespecializaciones en lugar de verlo consumido por completo. Sí. Casi como una reclasificación del frontend. Lo llamaste desarrollador de aplicaciones, ¿verdad? Creo que es una forma interesante de verlo. Y el punto de Brad es realmente genial con la parte delantera del frontend. Ahora vemos ingenieros de diseño, ahora vemos ingenieros de UX. Y consideraría a todos esos bajo el paraguas de un ingeniero frontend probablemente ese ingeniero de la parte delantera del frontend.

Y con AI, los diseñadores están escribiendo código. Más importante que nunca. Sí. Notaré que ya no estoy contratando frontend, porque todos mis diseñadores están haciendo mi frontend. Eso es interesante. Sí. Porque los diseñadores inherentemente tienen un ojo diferente y tienen una atención realmente profunda al detalle. Solíamos contratar desarrolladores de UI frontend pixel-perfect que tenían que obtener y reimplementar un PSD con especificaciones exactas, ¿verdad? Pero los diseñadores pueden hacer el código. Y es por eso que digo que las cosas se difuminan en muchas direcciones, ¿verdad? Puedes expandirte de front a back. Podrías expandirte hacia el diseño. Ahora, históricamente, los desarrolladores frontend eran donde el pensamiento dinámico de experiencia de usuario estaba, porque los diseñadores no eran buenos en eso. Sus herramientas eran estáticas, por lo que pensaban en las cosas de manera estática. Cuando te adentrabas en el medio, comenzabas a trabajar con HTML, JavaScript y CSS, tenías que lidiar con todos los casos extremos y las transiciones y esas cosas diferentes. Pero los diseñadores pueden hacer eso ahora. Y a menudo, tienen el ojo, tienen el pensamiento para eso, pueden hacerlo. Y una vez más, si estás comenzando desde un frontend, puedes moverte hacia ese espacio, ¿verdad? Realmente puedes desarrollar tu ojo y tu pensamiento sobre la forma en que las cosas funcionan juntas. Y eso es igual de valioso. De hecho, diría que potencialmente más valioso ahora que tantas cosas pueden simplemente delegarse a la AI. Pensar en las sutilezas de la experiencia es una gran fuente de alfa. El gusto. ¿Puedo hacer una pregunta de seguimiento? Porque decías que no contratas desarrolladores frontend porque los diseñadores pueden codificar ahora. Pueden enviar PRs con código con AI, ¿verdad? Sí. Pero ¿no decías que viste algunos de los PRs frontend de la gente de backend? Entonces, ¿crees que las habilidades que tienen los diseñadores en términos de qué buscar, su experiencia con malos diseños y buenos diseños, y lo que se necesita para pasar de un mal diseño a un buen diseño es más útil para que tengan más éxito con AI? Porque saben cómo hablar de ello, a ello, de una manera diferente, y por lo tanto pueden... Aunque no conocen el código frontend de la misma manera que un ingeniero backend no conoce el código, pero tienen más éxito obteniendo un PR que realmente puedes fusionar. Sí. Entonces hay dos cosas que he visto allí. Entonces, una es, sí, creo que la mayoría de los diseñadores y gerentes de producto a menudo, son más naturales al dar indicaciones que los ingenieros, porque ya están acostumbrados a pensar en cómo traduzco esto para que un ingeniero lo construya. ¿Crees que los ingenieros son malos comunicándose con otros humanos? Cuando hablamos de habilidades que podríamos desarrollar, promovería la comunicación como una que todos deberíamos trabajar. Pero luego el otro factor es que los diseñadores ya están acostumbrados a pensar en componentes primero en general, y descomponer las cosas por componentes, donde los ingenieros backend tienen un modelo mental diferente de composición, y por lo tanto el modelo mental que los diseñadores están trayendo a menudo se traduce en un código frontend mucho mejor que cuando los desarrolladores backend comienzan a dar indicaciones. Sí. Alen, eres parte de TANstack, y el ecosistema de TANstack tiene un montón de documentación, un montón de paquetes, y un montón de trabajo de diseño.

Y eso también está muy impulsado por la comunidad, ¿verdad? Y en esos tipos de situaciones, ¿son los ingenieros que están trabajando en esos paquetes y proyectos manejando el diseño, o hay personas comprometiendo diseño específicamente a estos repos? Sí, creo que somos principalmente nosotros diseñándolo, y algunos de nosotros somos mejores en ello, algunos de nosotros somos peores en ello. Como, por ejemplo, personalmente puedo decirte si algo se ve bien o mal o no, pero no puedo diseñarlo para que se vea bien o mal. Simplemente no puedo hacerlo. Creo que naturalmente, soy una persona muy curiosa, y siento que muchas personas usan sus títulos como una red de seguridad y una manta de seguridad, para no explorar los otros lados del desarrollo de software, porque el desarrollo de software es mucho más que desarrollo backend y desarrollo frontend, diseño, lo que sea. Tiene tantas subespecialidades, y creo que explorar todas ellas y aprender sobre esas cosas te ayuda en tu especialidad también. Porque, por ejemplo, aprendí diseño, y esto fue hace mucho tiempo, diseño material y cosas así, y luego después de aprender estos conceptos y cómo piensan los diseñadores, realmente me ayudó a dar forma a algunas de las cosas en las que estaba trabajando, y luego agregar cambios a algunas características sin preguntar a los diseñadores, porque sé cómo funciona la experiencia de usuario. Y luego puedo aplicar algunos de los conceptos que aprendí sobre experiencia de usuario a la característica y mejorarla. Por ejemplo, el diseñador crea un flujo que requiere tres botones. Sé por experiencia de usuario que es mejor tener un botón. Encuentro una manera de crear solo un botón para llevar al usuario a donde quiere ir. Y creo que es realmente importante ser muy curioso y explorar otras especialidades, porque así es como mejoras tu especialidad también.

Sí, me encanta eso. Ryan, ¿tenías algún pensamiento? Creo que si llevas React a su conclusión lógica en este punto, si lo miras en términos de la pregunta, es como empoderar a los desarrolladores frontend. Así que aunque el modelo mental puede ser un poco difícil de entender al principio, pero con componentes de servidor y funciones de servidor y ese tipo de cosas, realmente da a los desarrolladores frontend herramientas adicionales que hacen las cosas un poco más fáciles a largo plazo. Así que emparejándolo con cosas como Neon, como dije antes, y diferentes tipos de herramientas GUI que hacen que parte del backend sea más fácil, simplemente tiene sentido que se mantenga. Sí, sí, absolutamente. Y tocamos un poco sobre esto, y ha surgido un par de veces. ¿En qué es buena AI aquí? Y creo que para tener una pregunta no controvertida aquí, ¿es AI mejor en código frontend o backend código? AI es demasiado monolítica. Diría que la mayoría de los modelos antrópicos son bastante buenos en código frontend. No son muy buenos en mucho código backend. Si le pides a GPT-5 que te construya un frontend, lo lamentarás. Pero es bastante bueno escribiendo al menos en el mundo en el que estoy, código backend en Golang. Creo que depende mucho. La respuesta más insatisfactoria de todas. Pero en la escena de Next, comenzamos a agrupar nuestros documentos con tu aplicación, y tener un pequeño archivo de agentes para que si estás solicitando, ya sabes, un LLM en tu aplicación, diga, como, ignora tus datos de entrenamiento y trata los documentos agrupados como una fuente de verdad. Y eso hizo que funcionara mucho, mucho mejor. Entonces, ¿lo hace mejor en código frontend o backend? Bueno, si estás usando una biblioteca, un framework, que está bien documentado, y sabe dónde encontrar esos documentos, han llegado al punto en que lo harán fantástico. Si solo estás preguntando a un modelo genérico, podría darte una respuesta promedio basada en todos sus datos de entrenamiento. Y nuevamente, cuanto más sabes sobre algo, más probable es que veas eso y digas como, esto está mal. Sabes, es como Stack Overflow, para aquellos de ustedes que recuerdan.

Preguntarías algo en Stack Overflow, ¿qué pasaría? Verías como la respuesta más votada con una marca en la parte superior, y luego estarías como, eso está mal, necesito desplazarme hacia abajo y ver la que realmente tiene más votos, pero que no fue marcada como correcta, y esa siempre es la respuesta correcta. Así que tienes que saber hacer eso. Pero así es como pienso en la IA genérica, ya sabes, sin guía. Pero creo que funciona realmente bien con buena documentación, ¿sabes?

Sí, creo que esa es la clave. Encuentro, y creo que todos hemos experimentado esto en este punto, si no la diriges mucho o proporcionas documentación, vas a obtener ese temido efecto púrpura. Y así creo que sí, un buen sistema de diseño por adelantado, que, ya sabes, no necesariamente necesitas, supongo, un desarrollador frontend para eso, pero probablemente deberías para algo así, como principio guía, es crucial al usar IA para frontend. Sí. Es gracioso, de hecho, tuve un problema donde Codex específicamente estaba añadiendo un montón de gradientes, y dije, ¿por qué estás añadiendo gradientes a todo esto? Y dice, tú me lo dijiste. Y dije, absolutamente no lo hice. Y luego mostró el mensaje del sistema que decía, añade gradientes expresivos para que no se sienta plano. Como, ¿qué? Creo que la IA siempre será tan buena como la persona que la guía e itera con ella, ¿verdad?

Así que si eres un desarrollador frontend trabajando con IA, obtendrás un código frontend sólido. Si eres un desarrollador backend trabajando con IA, obtendrás un buen código backend. Si eres un diseñador trabajando con IA, obtendrás mejores resultados de diseño. Así que quiero decir, tal vez si estás mirando los resultados en bruto del modelo después de un solo intento de prompt, hay una diferencia. Pero eso no es realmente cómo trabaja la gente. Así que diría que es casi irrelevante. Sí. Como dijiste antes, soy el mantenedor de TenStack AI y DevTools, y he estado haciendo mucho marketing para nuestra organización. Y he estado usando tanto GPT como Opus como bancos de pruebas, y les haría la misma pregunta. Y Opus hace un trabajo mucho mejor con cosas creativas que GPT. GPT es tan estéril y aburrido, e intenté crear una presentación para la conferencia, y solo escribió un muro de texto en cada diapositiva y como 50 o algunos cuadros aleatorios. Y yo estaba como, ¿para quién es esto? Y luego le pregunté a Opus, oye, ¿puedes hacer esto? Y dibujó algunos diagramas divertidos. Añadió algunas cosas divertidas. Y yo estaba como, está bien, esto es realmente utilizable en lugar de GPT. Así que creo que depende mucho de eso. Y otra cosa de la que depende es usar habilidades y cosas así. Por ejemplo, he estado rogando a Tenor que ponga una habilidad de guía de marca solo para poder alimentarla a un LLM y decirle, está bien, por favor usa el color rosa de TenStack AI y no uses rojo y amarillo cada vez. Y esa es la esencia de ello. Vale la pena experimentar con los modelos. Y puedes jugar con Kimi y Composer y estas otras cosas.

Composer es bastante bueno en CSS, sorprendentemente. Pero tienen diferencias. En tu punto, si tienes una guía de marca realmente buena, la seguirás bien. Si estás tratando de hacer algo nuevo e interesante, no uses GPT. Pero también, si estás tratando de escribir código backend complejo y enredado, Opus lo escribirá cinco veces y comenzará a editar otros archivos. Así que todos tienen sus fortalezas.

Sí, solo iba a seguir. Sí, lo que dijo Catherine, creo que es tan bueno como la persona que lo usa. Otra forma de decir eso es que creo que cómo deberías pensar en la IA es como un complemento, no un sustituto. Así que es una herramienta. Complementa tu conjunto de habilidades, lo que estás tratando de lograr. No lo sustituye. Y siempre ha sido lo mismo, incluso antes de la IA.

Así que de nuevo, volviendo a la analogía de Rails, Rails te permitía configurar bases de datos desde tu código Rails. Pero eso no significa que no necesitabas entender qué era una base de datos o cómo modelar tus datos o configurar relaciones, o qué era una tabla de unión para una relación de muchos a muchos. De hecho, Rails empoderó a los desarrolladores backend para aprender sobre diseño de bases de datos. Y valía la pena aprender sobre diseño de bases de datos porque ahora podían configurar y establecer una base de datos para sus necesidades sin tener que aprender cómo configurar realmente un servidor MySQL y todos los detalles que un ingeniero de bases de datos real necesitaría entender.

De manera similar con las cosas de frontend, ya sea Neon, como un servicio en la nube para un backend, o el ejemplo de Vercel y Next de permitir al desarrollador frontend configurar CDN y caching, tienes que entender el caching, tienes que aprender principios sobre ello. Y así creo que es lo mismo con la IA, donde es tan tentador, y especialmente creo que cuando los modelos salieron por primera vez y fueron lo suficientemente buenos como para que puedas simplemente solicitar algo y tienes algo funcionando, estás como, wow, en realidad ya no tengo que usar mi cerebro. La gente está como, estamos diciendo eso. Como, ni siquiera tengo que pensar más. No, todavía tienes que pensar. Y así es emocionante que pueda hacer esas cosas de un solo golpe, pero como el tema del panel es si los ingenieros de frontend deben adaptarse. Creo que un ingeniero de frontend debería aprender, y aún así, si te encuentras motivado e inspirado para asumir alguna nueva parte del stack que no has hecho antes y comienzas a usar IA para hacerlo, eso es increíble, pero aún deberías aprender los primeros principios. Deberías ser un pensador de primeros principios, y usar la IA para ayudarte a enseñar esos primeros principios, y luego usarla para acelerar tu comprensión de los primeros principios, pero luego también la implementación real. Quiero decir, es genial para hacer el trabajo aburrido, pero todavía tienes que entender los primeros principios de lo que sea que estés haciendo.

El mayor diferenciador que he visto entre las personas que prosperan con la IA es que añaden una pregunta al final, después de que logran que haga algo, dicen, está bien, ¿por qué hiciste eso? Sí. Bueno, en realidad llegaste a la siguiente pregunta, que creo que es realmente genial. Así que no sé si la gente se da cuenta de esto, pero el año está casi a la mitad. 2026 está casi a la mitad, y así como los nuevos modelos salen, acabamos de tener Fable y Mythos que acaban de salir. Todas estas cosas están cambiando a una velocidad rápida. ¿Cómo se adaptan los desarrolladores frontend para el año que viene a este cambio? Gran pregunta. Creo que se trata de curiosidad y aprendizaje, y eso es todo. Porque, por ejemplo, cuando comencé con TensorStack AI, solo quería construirlo, y es una tecnología orientada al backend, y soy un ingeniero de frontend de corazón, y esa es mi pasión y ahí es donde he estado durante mucho tiempo, y tuve que aprender muchos conceptos de backend y resolver muchas cosas, y valió la pena al final porque ahora me siento tan cómodo con ello, y es súper divertido construir todas estas nuevas experiencias para las personas que están usando TensorStack AI y para mí mismo también porque creas todos estos sistemas súper complejos y los haces fáciles porque los entiendes, y simplemente creas algunos flujos súper avanzados con IA, como, oye, haz este flujo de trabajo, crea esto, luego llama a este agente, luego haz esto y aquello, y es súper divertido de hacer, y creo que la gente puede simplemente explorar. Por ejemplo, la IA fue la siguiente gran cosa para mí para aprender, y probablemente tendré otra cosa en un año o dos que quiera aprender de nuevo.

Así que creo que se trata de aprender y mejorarte a ti mismo y hacerte un mejor desarrollador porque no es una industria donde digas, está bien, he aprendido X, Y y Z, he terminado de aprender. Eso es todo, he terminado para siempre. Tienes que aprender y mejorarte constantemente. En el frontend, deberíamos estar acostumbrados a eso, ¿verdad? ¿Quién recuerda las guerras de frameworks? Se sentía igual. Es como, hay algo nuevo cada semana, hay algo con lo que mantenerse al día. No necesitas saberlo todo. Hice una masterclass sobre eso, y enumeré todos los cambios desde floats hasta ahora, y estaba sin aliento. Estaba realmente exhausto de hablar sobre ello. Es agotador, y se siente así ahora, excepto que es todo el mundo a la vez, pero eso es como la nueva normalidad. Las cosas están cambiando todo el tiempo, así que uno, sí, mantén la curiosidad, sigue aprendiendo, pero dos, no sientas que hay un lugar al que vas a llegar y estarás hecho, lo cual también en algunos aspectos es liberador, porque significa que no es que esté atrasado, todos están atrasados. No hay un lugar al que llegar.

No hay un final. Sí, creo que para volver al punto de los primeros principios, o tienes esa curiosidad, o no la tienes, y si tienes esa curiosidad y te gusta descubrir cómo funcionan las cosas, y quieres expandir tus conjuntos de habilidades, creo que usar la IA como un superpoder para aprender los diferentes conceptos que tal vez te falten, o simplemente para explorar diferentes cosas que tal vez no amplíen tu horizonte en el mercado laboral, pero que podrían mantener tu interés en la computación y en la construcción de aplicaciones en general, y expandir tu sentido del diseño también.

Creo que, sí, usarla como un superpoder para complementar tu curiosidad y tu aprendizaje es súper importante para adaptarse en el próximo año. Creo que también puede haber una falsa sensación de prisa alrededor de esto a la que me opondría también. Como a todos les gusta decirme, esto está aquí y no va a ninguna parte, acostúmbrate a ello. Así que tienes tiempo, es el otro lado de eso. No va a ninguna parte. Y si no es relevante para lo que estás haciendo hoy, está bien retomarlo mañana, o dentro de un mes, o dentro de tres meses. La tecnología avanzará. La tecnología siempre ha seguido avanzando, y siempre ha habido un nuevo punto de entrada, y no creo que eso vaya a cambiar nunca.

¿Recuerdas las alternativas a TypeScript? ¿Oh, CoffeeScript? Todas las alternativas. Hay tantas de ellas. Todavía estoy afectado por la falta de un turner en CoffeeSick. Sí, así que las cosas cambian, ¿verdad? Sí, puedes retomar las cosas, puedes esperar. A veces tiene sentido esperar, a veces es una mejor estrategia esperar, porque en el caso de TypeScript versus Flow, o Reason, o cualquier otro, es lo mismo con CoffeeScript. CoffeeScript en su día no se trataba mucho de tipos, se trataba más de sintaxis y primitivas y cosas para hacer que el lenguaje fuera más agradable de escribir, porque ES4, ES5 no avanzaba mucho, y era simplemente doloroso.

La gente descubrió compiladores, y comenzaron a crear sus propios lenguajes, pero CoffeeScript no era como un superconjunto del lenguaje, y una vez que ECMAScript comenzó a agregar características agradables como async await, y arrow functions, y object destructuring, esas no eran compatibles hacia atrás con CoffeeScript, por lo que tenías que reescribir tu código CoffeeScript. Ese conocimiento específico no se transfería. No era conocimiento general que te estaba elevando en tu pensamiento, o tus principios, o tu comprensión de los fundamentos, era conocimiento específico. Está bien, no es como si fuera un problema si hiciste eso, pero no se trasladó.

Pienso mucho de esa manera sobre la IA, como Fable acaba de salir, no lo he usado. Soy un adoptador tardío. Realmente no comencé a usar agentes hasta que Opus 4.5 salió o lo que sea. Siento muy fuertemente que todo el tiempo que invertí en Flash va a regresar. Creo que eso va a funcionar para mí. Los modelos siguen cambiando, y siguen aprendiendo cosas nuevas por sí mismos. Si hay alguien que tuitea sobre alguna herramienta que va a cambiar tu vida, y luego el modelo realmente puede hacerlo en una semana o un mes, entonces no tienes que preocuparte por que la gente te diga que te lo estás perdiendo. Puedes simplemente esperar y aprender los fundamentos.

Creo que hay fundamentos que puedes aprender para trabajar con IA, mejor versus peor, y no involucra mantenerse al día con un feed de noticias lleno de material exagerado, o nuevas herramientas, o nuevos flujos de trabajo. Esas habilidades meta, curiosidad, cómo aprendes mejor, cómo te comunicas mejor, esas van a seguir siendo valiosas sin importar lo que haga la IA. Lo mejor de que los modelos se vuelvan más inteligentes es que puedes usarlos para aprender cosas nuevas. Por ejemplo, el otro día estaba trabajando en flujos de trabajo de IA para TensorStack AI, y no tengo ningún conocimiento sobre flujos de trabajo y cómo suelen funcionar. Estaba como, está bien, necesito resolver esto. Lo que hice primero fue escribir una habilidad que va a generar un mini curso para mí, basado en mi conocimiento previo. Escribí esa habilidad, y luego me preguntó, ¿cuál es tu experiencia, cuál es tu formación, pensé que soy un ingeniero de front-end, conozco Legos y esas cosas. Luego elaboró un curso a medida usando analogías de Legos y desarrollo front-end para enseñarme flujos de trabajo.

Así es como utilicé un agente para enseñarme a mí mismo flujos de trabajo, de los cuales no tenía idea. Ahora soy competente en ello, no soy un experto, pero sé lo suficiente para hacer el trabajo que necesito hacer. Sí, se siente como si estas herramientas estuvieran subutilizadas para el aprendizaje, adaptándose a tu propia manera específica de consumir conocimiento.

De hecho, en mi masterclass tuve que hacer una sesión de preguntas y respuestas aquí, ¿verdad? Como hacemos. Le di las diapositivas y dije, interrógame como si fueras una audiencia que busca sangre. Quiero estar preparado para estas preguntas. Fue genial, porque me permitió profundizar en algunas de las APIs y explorar mi cerebro de una manera diferente. Me encanta este mensaje de que aprender por aprender es algo tan importante.

Bueno, y lo que estabas diciendo, ¿verdad? Hay tanto bombo sobre, no tengo que pensar, voy a delegar mi pensamiento. Si estás delegando tu pensamiento, lo estás usando mal. Descubre cómo usarlo para elevar tu pensamiento. Oh, esa es una buena nota. Sí. Déjame recibir algunos aplausos por eso. Sí. Entonces, está bien. Dado todo eso, me encanta este mensaje de ser lento para esperar las cosas, pero ¿cómo sabes cuándo algo está listo para lanzarse? Cuando lo necesitas para lo que estás construyendo. Cuando tu jefe te dice que lo hagas.

Sí. Aprendizaje motivado, ¿verdad? Quiero decir, debería estar motivado. No solo te da suficiente contexto para el problema que la cosa que estás buscando resolverá, lo cual te ayuda a entender por qué fue creado en primer lugar. Nuevamente, esto se aplica a las bibliotecas y frameworks también, al igual que a la IA. Simplemente va a ser más interesante. Naturalmente vas a querer entenderlo, nuevamente, a un nivel de primeros principios.

Así que sí, si alguien está contento con cómo está trabajando y lo que está haciendo, no debería usar IA. Es un poco controvertido decirlo, honestamente. Creo que vale la pena desarrollar el hábito de preguntarle. Desarrollar el hábito de, ¿qué más debería considerar con esto? ¿Cómo harías esto? Preguntando a los LLMs, porque me sorprende constantemente cuánto es capaz de enseñarme o mostrarme o decirme, oye, deberías leer esto. Deberías leer aquello. Deberías revisar esto. Sí. Sí.

Solo para seguir rápidamente. Comencé a usar agentes intensamente cuando Opus salió porque fue cuando todos decían, esto es un verdadero cambio de paradigma. Así que fue bastante impresionante. Es increíble, pero hubo dos años de personas haciendo bucles de Ralph y todo tipo de cosas. No tuve que hacer eso. Realmente no estaba súper interesado en muchas de esas cosas, pero es bastante obvio cuando hay un gran cambio de paradigma, pero puedes pasar por alto muchas cosas si no quieres- No saltas a cada- No saltas a todo. Sí. Ya no tengo 20 años. No estoy experimentando con todo lo que veo en Twitter. Sí. Vamos con una respuesta más de Ryan aquí y luego nos vamos. Sí. Solo iba a decir que es súper conveniente y usualmente el primer paso es recurrir al modo agente, pero creo que partiendo de primeros principios y queriendo avanzar en tu aprendizaje, a veces es mucho mejor simplemente ir al modo chat y resolverlo por tu cuenta y usar tu cerebro para aprender el concepto en lugar de simplemente tener un agente que te lo escupa.