Corea también, por el problema de las pensiones, al final tendrá que seguir ampliando poco a poco (...) la edad de jubilación...
Supongo que el punto de inflexión será cuando, de tanto aumentarla, llegue a superar la esperanza de vida promedio.
(Creo que ya dicen que eso pasó en Rusia...)
Aunque el mensaje del autor tiende a ser algo fuerte, si leen bien el texto, no está diciendo "no uses IA". Hay una propuesta sobre cómo aprovecharla, y el punto central es el mensaje de que al propio desarrollador no le puede faltar capacidad.
Si vemos por qué el mensaje del autor se siente tan fuerte, es porque fue construido como una respuesta a la perspectiva de que será posible desarrollar con Copilot (con un matiz de alta dependencia del desarrollo respecto de Copilot). Por eso llevó el mensaje con la forma de no adoptar una postura que dañe, para los desarrolladores, el valor de su propia existencia.
Como el autor tampoco está dando un mensaje de "no usen IA", al final, si se trata de aprovechar la IA, el punto de equilibrio estará en algún lugar intermedio, así que parece que el mensaje en líneas generales terminó siendo bastante parecido a lo que acababas de responder.
De todos modos, me costó estar de acuerdo con la parte de "perspectiva sesgada" en lo que escribiste al principio, así que por eso quise responder primero.
Crear es solo el comienzo, y si operas un servicio durante unos 10 años, en el camino van a pasar todo tipo de cosas; para aguantar ahí, necesitas una base... hay que aprender.
Primero, en eso de "usar IA dentro del dominio", por supuesto que el diseño y la coordinación los hace una persona...
En realidad, eso quizá habría que aclararlo antes, pero ahora que todo el mundo conoce las limitaciones de los LLM, se ha vuelto algo tan obvio que ni hace falta decirlo.
En cuanto al caso que mencionaste de gente común sin conocimientos de desarrollo usando LLM,
creo que ni el artículo, ni Hacker News, ni yo hemos dicho eso, pero de todos modos, incluso en ese caso, ya se llegó a un nivel en el que los usuarios pueden quedar satisfechos con los resultados.
Si no fuera así, Bolt.new, v0 e incluso Cursor no tendrían la valoración que tienen hoy.
Es difícil tomar la decisión de hasta dónde reinventar y hasta dónde apoyarse en dependencias externas.
En cualquier caso, elegir esa dependencia para ahorrar tiempo aunque podría construir esto por mi cuenta, y quedar atado a la dependencia porque sin ella no puedo crear el servicio, son historias completamente distintas.
Quizá no sea posible para todo el código (como un sistema operativo), pero incluso así, esforzarse por ir lo más posible hacia lo primero ayudará a entender mejor el sistema.
Creo que hay un pequeño malentendido sobre el sentido que quiso dar el autor.
El autor está enfocado en el rendimiento, la estabilidad, y en una arquitectura y consistencia de código que faciliten el mantenimiento del proyecto que él mismo gestiona; y, justamente, la arquitectura y la consistencia del código son una de las áreas en las que los LLM actuales realmente son muy malos.
En particular, en la web entra muchísima gente al desarrollo y está muy arraigada la idea de que “si de alguna forma funciona, ya está”, así que se despliega una enorme cantidad de código de baja calidad. Y como los LLM se entrenan sobre esa base, la calidad de sus resultados cae a un nivel ridículamente bajo.
Simplemente, pídanle a GPT: "Lo voy a usar en el frontend web, así que impleméntame en js un algoritmo de quicksort". Si no pueden encontrar problemas en lo que devuelve, creo que esta conversación no tiene mucho sentido.
Viendo las publicaciones anteriores del autor, parece que es desarrollador de videojuegos.
Como los LLM no han podido entrenarse masivamente con conocimientos o materiales de desarrollo de videojuegos, a diferencia de los casos de apps CRUD, da la impresión de que el autor del texto percibe mejor las limitaciones de los LLM.
Lo leí completo y, al final, creo que precisamente por esto el autor tiene una perspectiva un poco sesgada.
Claro, hacer las cosas como dice el texto es casi de manual, así que no está mal,
pero creo que la IA ya lo hace suficientemente bien en CRUD y frontend, donde sí hay mucho material para entrenarse.
Parece que hay que aprovecharla lo mejor posible dentro del propio dominio.
La número 1 de verdad es un cambio como de pesadilla, uno que nunca querría aceptar. Es como si el rastreo del historial del código fuente perdiera todo sentido.
Le pedí al bot de IA de GN+ que extrajera el guion de YouTube y lo resumiera, y la verdad funciona bastante bien.
Había demasiados videos para ver y se me hacía pesado, así que me parece muy bueno.
Los refranes tienen un significado implícito, pero cada vez hay más gente que los interpreta solo de forma literal.
Si ese tipo de ideas se pone de moda, otra vez la sala de reuniones se vuelve un caos como si nada.
Los adictos al papeleo se emocionan y se desatan, y el mismo fracaso se repite otra vez cada año.
Esto está muy ligado a la legislación laboral de cada país... En muchas empresas de EE. UU. simplemente se van turnando, y cuando a alguien no le funciona en cierto período, le cambian el orden. Eso suele ser lo normal. Como es algo pesado, también hay empresas que tienen un equipo dedicado exclusivamente al on-call.
En Europa, casi siempre hay una compensación aparte, ya sea porque cambió la naturaleza del trabajo o porque se considera trabajo fuera de horario.
En nuestro país, por culpa del sistema de salario integral, se suele manejar más o menos así no más. El on-call claramente también es trabajo, pero lo maquillan como si el pago por ese tiempo fuera una prestación o beneficio.
La verdad, ya sería difícil usar todos esos servicios, así que tener MCP es una gran ventaja.
Si de aquí en adelante mantienen bien la API, creo que será útil.
Aunque el hardware de Apple es excelente, su software está lleno de restricciones pensadas para atar al usuario.
Incluso si solo quieres que una app que tú mismo hiciste y compilaste funcione únicamente en tu propio dispositivo, necesitas una suscripción de 100 dólares.
Si eres desarrollador y usas apps open source pequeñas o medianas que compilas por tu cuenta para usarlas,
en vez de tener que hacer jailbreak con vulnerabilidades y hacer sideload en un dispositivo de Apple, es más fácil simplemente usar Android.
En nuestro caso, la guardia se pagaba a la mitad de la tarifa por hora, se apoyaban los gastos de comunicación y el tiempo de soporte se pagaba como horas extra al 1.5x.
Corea también, por el problema de las pensiones, al final tendrá que seguir ampliando poco a poco (...) la edad de jubilación...
Supongo que el punto de inflexión será cuando, de tanto aumentarla, llegue a superar la esperanza de vida promedio.
(Creo que ya dicen que eso pasó en Rusia...)
Resumen,
Autor: los desarrolladores deben mejorar y conservar sus propias habilidades. Incluso la IA ni siquiera funciona tan bien.
crawler: ¿Eh? A mí sí me funciona bien.
superscv: Tiene muchos problemas...
crawler: Hay que saber ajustarla y usarla.
superscv: Creo que ya nos alejamos demasiado del mensaje que el autor quería transmitir desde el principio...
Aunque el mensaje del autor tiende a ser algo fuerte, si leen bien el texto, no está diciendo "no uses IA". Hay una propuesta sobre cómo aprovecharla, y el punto central es el mensaje de que al propio desarrollador no le puede faltar capacidad.
Si vemos por qué el mensaje del autor se siente tan fuerte, es porque fue construido como una respuesta a la perspectiva de que será posible desarrollar con Copilot (con un matiz de alta dependencia del desarrollo respecto de Copilot). Por eso llevó el mensaje con la forma de no adoptar una postura que dañe, para los desarrolladores, el valor de su propia existencia.
Como el autor tampoco está dando un mensaje de "no usen IA", al final, si se trata de aprovechar la IA, el punto de equilibrio estará en algún lugar intermedio, así que parece que el mensaje en líneas generales terminó siendo bastante parecido a lo que acababas de responder.
De todos modos, me costó estar de acuerdo con la parte de "perspectiva sesgada" en lo que escribiste al principio, así que por eso quise responder primero.
Crear es solo el comienzo, y si operas un servicio durante unos 10 años, en el camino van a pasar todo tipo de cosas; para aguantar ahí, necesitas una base... hay que aprender.
Primero, en eso de "usar IA dentro del dominio", por supuesto que el diseño y la coordinación los hace una persona...
En realidad, eso quizá habría que aclararlo antes, pero ahora que todo el mundo conoce las limitaciones de los LLM, se ha vuelto algo tan obvio que ni hace falta decirlo.
En cuanto al caso que mencionaste de gente común sin conocimientos de desarrollo usando LLM,
creo que ni el artículo, ni Hacker News, ni yo hemos dicho eso, pero de todos modos, incluso en ese caso, ya se llegó a un nivel en el que los usuarios pueden quedar satisfechos con los resultados.
Si no fuera así, Bolt.new, v0 e incluso Cursor no tendrían la valoración que tienen hoy.
Es difícil tomar la decisión de hasta dónde reinventar y hasta dónde apoyarse en dependencias externas.
En cualquier caso, elegir esa dependencia para ahorrar tiempo aunque podría construir esto por mi cuenta, y quedar atado a la dependencia porque sin ella no puedo crear el servicio, son historias completamente distintas.
Quizá no sea posible para todo el código (como un sistema operativo), pero incluso así, esforzarse por ir lo más posible hacia lo primero ayudará a entender mejor el sistema.
Creo que hay un pequeño malentendido sobre el sentido que quiso dar el autor.
El autor está enfocado en el rendimiento, la estabilidad, y en una arquitectura y consistencia de código que faciliten el mantenimiento del proyecto que él mismo gestiona; y, justamente, la arquitectura y la consistencia del código son una de las áreas en las que los LLM actuales realmente son muy malos.
En particular, en la web entra muchísima gente al desarrollo y está muy arraigada la idea de que “si de alguna forma funciona, ya está”, así que se despliega una enorme cantidad de código de baja calidad. Y como los LLM se entrenan sobre esa base, la calidad de sus resultados cae a un nivel ridículamente bajo.
Simplemente, pídanle a GPT: "Lo voy a usar en el frontend web, así que impleméntame en js un algoritmo de quicksort". Si no pueden encontrar problemas en lo que devuelve, creo que esta conversación no tiene mucho sentido.
Lo leí completo y, al final, creo que precisamente por esto el autor tiene una perspectiva un poco sesgada.
Claro, hacer las cosas como dice el texto es casi de manual, así que no está mal,
pero creo que la IA ya lo hace suficientemente bien en CRUD y frontend, donde sí hay mucho material para entrenarse.
Parece que hay que aprovecharla lo mejor posible dentro del propio dominio.
¿La empresa es un lugar al que uno va a aprender? ¿O es un lugar donde se recrea valor usando la rueda que otros hicieron?
https://es.news.hada.io/topic?id=21091
Después de leer este artículo, no sé si esto tiene sentido.
La número 1 de verdad es un cambio como de pesadilla, uno que nunca querría aceptar. Es como si el rastreo del historial del código fuente perdiera todo sentido.
Le pedí al bot de IA de GN+ que extrajera el guion de YouTube y lo resumiera, y la verdad funciona bastante bien.
Había demasiados videos para ver y se me hacía pesado, así que me parece muy bueno.
Es porque no has visto una buena casa de Electron ~
... eso es lo que parece que están diciendo jajaja
Los refranes tienen un significado implícito, pero cada vez hay más gente que los interpreta solo de forma literal.
Si ese tipo de ideas se pone de moda, otra vez la sala de reuniones se vuelve un caos como si nada.
Los adictos al papeleo se emocionan y se desatan, y el mismo fracaso se repite otra vez cada año.
Esto está muy ligado a la legislación laboral de cada país... En muchas empresas de EE. UU. simplemente se van turnando, y cuando a alguien no le funciona en cierto período, le cambian el orden. Eso suele ser lo normal. Como es algo pesado, también hay empresas que tienen un equipo dedicado exclusivamente al on-call.
En Europa, casi siempre hay una compensación aparte, ya sea porque cambió la naturaleza del trabajo o porque se considera trabajo fuera de horario.
En nuestro país, por culpa del sistema de salario integral, se suele manejar más o menos así no más. El on-call claramente también es trabajo, pero lo maquillan como si el pago por ese tiempo fuera una prestación o beneficio.
La verdad, ya sería difícil usar todos esos servicios, así que tener MCP es una gran ventaja.
Si de aquí en adelante mantienen bien la API, creo que será útil.
Aunque el hardware de Apple es excelente, su software está lleno de restricciones pensadas para atar al usuario.
Incluso si solo quieres que una app que tú mismo hiciste y compilaste funcione únicamente en tu propio dispositivo, necesitas una suscripción de 100 dólares.
Si eres desarrollador y usas apps open source pequeñas o medianas que compilas por tu cuenta para usarlas,
en vez de tener que hacer jailbreak con vulnerabilidades y hacer sideload en un dispositivo de Apple, es más fácil simplemente usar Android.
En nuestro caso, la guardia se pagaba a la mitad de la tarifa por hora, se apoyaban los gastos de comunicación y el tiempo de soporte se pagaba como horas extra al 1.5x.
Parece que el bando de C# estaba escondido por ahí.
> Francamente, hoy en día desarrollas en Java y tampoco es que necesariamente tengas que usar productos de JetBrains.
En esta parte... me cuesta un poco estar de acuerdo, sniff sniff...