Estoy de acuerdo con la idea principal de este artículo. Últimamente se está abusando demasiado de JS, así que hay muchos casos en los que un sitio se traba incluso usando un i9-9900k. Puede que sea una especificación algo ambigua para gaming o trabajo, pero la realidad es que abundan las computadoras de oficina con especificaciones peores que esa.
Por eso me gustan Astro y Hotwired, frameworks con la filosofía de usar JS solo cuando de verdad hace falta, como en las partes interactivas o en una navegación de página interactiva. También me gusta SSR, es decir, renderizar del lado del servidor. En cambio, detesto mucho CSR (incluyendo cuando solo se renderizan del lado del servidor las meta tags y el resto se maneja con CSR). Porque lo veo como trasladarle al cliente trabajo que debería hacer el servidor. Personalmente, creo que el enfoque tradicional de SPA que usa CSR debería usarse cuando el frontend se ejecuta localmente en una app como Electron. Claro, si el frontend se carga desde el servidor, entonces sí debería usarse SSR.
Creo que, por la estructura de los LLM, será imposible garantizar por completo la seguridad. Pienso que es inevitable que los LLM sean inestables, y que lo importante será cómo otorgarles autoridad sobre acciones físicas, como en agentes o en conducción autónoma.
Con solo ver el nombre, ya parece poco confiable.
¿Por qué habrán puesto dos puntos en medio del nombre? ¿Habrá alguna razón de significado? ¿O acaso creen que eso se ve genial?
Y además, si es 믿:음, ¿no deberían escribirlo en alfabeto latino como mid:m?
Últimamente, por el juego de mesa SETI, estuve buscando cosas relacionadas con SETI, así que también da gusto verlo ahora como noticia.
El juego de mesa SETI es realmente muy divertido. También quisiera recomendárselo a quienes no conocen mucho los juegos de mesa.
Como hay amigos jóvenes que ni siquiera conocen el propio SETI, primero les presento el proyecto, así que el contexto también resulta interesante y la temática del juego le queda perfecta.
Como este juego de mesa de 2025 ya subió hasta el puesto 43 en el ranking general de juegos de mesa, parece que pronto entrará al top 10.
Creo que se puede ver como el rendimiento de un modelo con poco proceso de alignment, pero probablemente lo recorten y no termine bajando el rendimiento.
Bueno, supongo que habrá que probarlo en uso real para saberlo, pero con 200 mil GPUs y ese pool de talento, sí es posible crecer de forma tan agresiva.
Me pregunto cuánto más mejorará cuando Colossus llegue a 1 millón de GPUs.
Si calculamos cada H100 en 50 millones de wones, solo el precio de las GPUs serían 50 billones de wones. Y como además hay que construir el centro de datos y se necesita suministro eléctrico alrededor, dicen que habría que sumar hasta unos 20 billones más, así que serían 70 billones de wones en total. Parece que la IA cada vez se está convirtiendo más en una guerra de dinero.
> Yo pienso que hacer wrappers que dicen ser servicios de IA usando APIs externas es un trabajo sin ninguna productividad y un negocio de cobrar comisiones,
Sumando a eso, incluso si se usan APIs, si se aprovechan tan bien como Manus puede considerarse un logro, pero todavía no parece haber en Corea un wrapper de ese nivel.
Estoy parcialmente de acuerdo.
Yo pienso que crear wrappers que se hacen pasar por servicios de IA usando APIs externas no tiene ninguna productividad y es un negocio de cobrar comisiones,
pero si las empresas al menos afinan modelos y luego los publican, al final los están haciendo públicos invirtiendo sus propios recursos, así que no creo que haya motivo para verlo negativamente.
Eso sí, si empiezan a recibir dinero de afuera, por ejemplo del gobierno, creo que ya no se podría ver de manera tan positiva...
Cuando uso Gemini CLI, la experiencia de usuario se siente en otro nivel gracias al contexto de 1M.
Poder meter toda la base de código en el contexto sí que cambia las reglas del juego.
Me da curiosidad cuánto influye realmente el tamaño del contexto en el uso del modelo; que todavía se diga quién es el número 1 solo por benchmarks y apariencias, ¿en qué se diferencia eso de hacer marketing viral para gente que no sabe?
Puede haber opiniones diversas, pero yo básicamente creo que todos los proyectos relacionados con IA que se intentan dentro del país tienen significado. Más que evaluar su nivel comparándolos con los demás, creo que estamos en una situación en la que hay que reconocer el intento en sí.
Es cierto que la respuesta llegó tarde, y que también estamos en desventaja en dinero y GPU frente a Estados Unidos y China, pero ¿no mejorará si lo reconocemos, lo usamos juntos y lo vamos perfeccionando?
Si te quedas atrapado en el derrotismo de pensar, culpando a la realidad, que "de todos modos no se puede", no cambiará nada. Encontrar aunque sea una sola idea útil en el texto e intentarlo es el camino para aumentar tu propio valor.
A continuación se presenta un resumen que clasifica las reacciones en los comentarios sobre la publicación en 5 tipos:
1. Acuerdo y apoyo total
Características principales: Coinciden plenamente con el argumento del texto y reconocen los problemas de una pila de JS compleja.
Ejemplos de opiniones:
“Por fin alguien dijo lo que había que decir.”
“Es un excelente texto que enfrenta la realidad.”
“El rendimiento web y la accesibilidad son indispensables.”
2. Preocupación por el abuso de frameworks
Características principales: Critican el uso excesivo de frameworks como React y Angular, y opinan que con tecnologías simples es suficiente.
Ejemplos de opiniones:
“React no es necesario para un blog.”
“Con Vanilla JS se resuelve la mayoría de los casos.”
“Alternativas ligeras como Svelte y Eleventy son mejores.”
3. Acuerdo parcial + consideración de la realidad
Características principales: Empatizan con el argumento, pero también existe una postura realista que ve la complejidad como algo inevitable o necesario.
Ejemplos de opiniones:
“La complejidad es un problema, pero en algunas situaciones es inevitable.”
“Para colaborar y dar mantenimiento, los frameworks también son necesarios.”
“HTML/CSS también es imperfecto, así que no queda otra que usar JS.”
4. Crítica a la cultura de desarrollo y a la estructura de la industria
Características principales: Señalan que el exceso de frameworks no es solo un problema técnico, sino el resultado de estructuras de contratación, cultura y marketing.
Ejemplos de opiniones:
“Los frameworks se han convertido en una habilidad para el currículum.”
“Los desarrolladores solo siguen las exigencias de la empresa.”
“Este es un problema de cultura organizacional y del mercado laboral.”
5. Crítica o desacuerdo
Características principales: No están de acuerdo con la premisa del texto o lo critican por ser una postura unilateral.
Ejemplos de opiniones:
“No hay pruebas de que la web se haya vuelto más lenta.”
“El texto es demasiado parcial.”
“Resolver el problema de JS con WordPress es más bien un retroceso.”
Usa Rails, sé feliz
Apoyo el intento, pero...
Ojalá no hagan cosas como crear una nueva organización y tirar por la borda la 1.0.
¿Se trata de la vida en la empresa (coreana)? Jajaja
Ojalá también salga en YCD~
Estoy de acuerdo con la idea principal de este artículo. Últimamente se está abusando demasiado de JS, así que hay muchos casos en los que un sitio se traba incluso usando un i9-9900k. Puede que sea una especificación algo ambigua para gaming o trabajo, pero la realidad es que abundan las computadoras de oficina con especificaciones peores que esa.
Por eso me gustan Astro y Hotwired, frameworks con la filosofía de usar JS solo cuando de verdad hace falta, como en las partes interactivas o en una navegación de página interactiva. También me gusta SSR, es decir, renderizar del lado del servidor. En cambio, detesto mucho CSR (incluyendo cuando solo se renderizan del lado del servidor las meta tags y el resto se maneja con CSR). Porque lo veo como trasladarle al cliente trabajo que debería hacer el servidor. Personalmente, creo que el enfoque tradicional de SPA que usa CSR debería usarse cuando el frontend se ejecuta localmente en una app como Electron. Claro, si el frontend se carga desde el servidor, entonces sí debería usarse SSR.
Pedir ayuda también es una habilidad.
Creo que, por la estructura de los LLM, será imposible garantizar por completo la seguridad. Pienso que es inevitable que los LLM sean inestables, y que lo importante será cómo otorgarles autoridad sobre acciones físicas, como en agentes o en conducción autónoma.
Con solo ver el nombre, ya parece poco confiable.
¿Por qué habrán puesto dos puntos en medio del nombre? ¿Habrá alguna razón de significado? ¿O acaso creen que eso se ve genial?
Y además, si es
믿:음, ¿no deberían escribirlo en alfabeto latino comomid:m?Últimamente, por el juego de mesa SETI, estuve buscando cosas relacionadas con SETI, así que también da gusto verlo ahora como noticia.
El juego de mesa SETI es realmente muy divertido. También quisiera recomendárselo a quienes no conocen mucho los juegos de mesa.
Como hay amigos jóvenes que ni siquiera conocen el propio SETI, primero les presento el proyecto, así que el contexto también resulta interesante y la temática del juego le queda perfecta.
Como este juego de mesa de 2025 ya subió hasta el puesto 43 en el ranking general de juegos de mesa, parece que pronto entrará al top 10.
Creo que se puede ver como el rendimiento de un modelo con poco proceso de alignment, pero probablemente lo recorten y no termine bajando el rendimiento.
Bueno, supongo que habrá que probarlo en uso real para saberlo, pero con 200 mil GPUs y ese pool de talento, sí es posible crecer de forma tan agresiva.
Me pregunto cuánto más mejorará cuando Colossus llegue a 1 millón de GPUs.
Si calculamos cada H100 en 50 millones de wones, solo el precio de las GPUs serían 50 billones de wones. Y como además hay que construir el centro de datos y se necesita suministro eléctrico alrededor, dicen que habría que sumar hasta unos 20 billones más, así que serían 70 billones de wones en total. Parece que la IA cada vez se está convirtiendo más en una guerra de dinero.
> Yo pienso que hacer wrappers que dicen ser servicios de IA usando APIs externas es un trabajo sin ninguna productividad y un negocio de cobrar comisiones,
Sumando a eso, incluso si se usan APIs, si se aprovechan tan bien como Manus puede considerarse un logro, pero todavía no parece haber en Corea un wrapper de ese nivel.
Estoy parcialmente de acuerdo.
Yo pienso que crear wrappers que se hacen pasar por servicios de IA usando APIs externas no tiene ninguna productividad y es un negocio de cobrar comisiones,
pero si las empresas al menos afinan modelos y luego los publican, al final los están haciendo públicos invirtiendo sus propios recursos, así que no creo que haya motivo para verlo negativamente.
Eso sí, si empiezan a recibir dinero de afuera, por ejemplo del gobierno, creo que ya no se podría ver de manera tan positiva...
Cuando uso Gemini CLI, la experiencia de usuario se siente en otro nivel gracias al contexto de 1M.
Poder meter toda la base de código en el contexto sí que cambia las reglas del juego.
Me da curiosidad cuánto influye realmente el tamaño del contexto en el uso del modelo; que todavía se diga quién es el número 1 solo por benchmarks y apariencias, ¿en qué se diferencia eso de hacer marketing viral para gente que no sabe?
Puede haber opiniones diversas, pero yo básicamente creo que todos los proyectos relacionados con IA que se intentan dentro del país tienen significado. Más que evaluar su nivel comparándolos con los demás, creo que estamos en una situación en la que hay que reconocer el intento en sí.
Es cierto que la respuesta llegó tarde, y que también estamos en desventaja en dinero y GPU frente a Estados Unidos y China, pero ¿no mejorará si lo reconocemos, lo usamos juntos y lo vamos perfeccionando?
Si te quedas atrapado en el derrotismo de pensar, culpando a la realidad, que "de todos modos no se puede", no cambiará nada. Encontrar aunque sea una sola idea útil en el texto e intentarlo es el camino para aumentar tu propio valor.
Oh, al dividirlo por tipos queda cómodo de ver y está bueno.
La traducción al coreano está abajo.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…
A continuación se presenta un resumen que clasifica las reacciones en los comentarios sobre la publicación en 5 tipos:
1. Acuerdo y apoyo total
Características principales: Coinciden plenamente con el argumento del texto y reconocen los problemas de una pila de JS compleja.
Ejemplos de opiniones:
2. Preocupación por el abuso de frameworks
Características principales: Critican el uso excesivo de frameworks como React y Angular, y opinan que con tecnologías simples es suficiente.
Ejemplos de opiniones:
3. Acuerdo parcial + consideración de la realidad
Características principales: Empatizan con el argumento, pero también existe una postura realista que ve la complejidad como algo inevitable o necesario.
Ejemplos de opiniones:
4. Crítica a la cultura de desarrollo y a la estructura de la industria
Características principales: Señalan que el exceso de frameworks no es solo un problema técnico, sino el resultado de estructuras de contratación, cultura y marketing.
Ejemplos de opiniones:
5. Crítica o desacuerdo
Características principales: No están de acuerdo con la premisa del texto o lo critican por ser una postura unilateral.
Ejemplos de opiniones: