Coincido. En sectores como el aeroespacial, el médico y el control de precisión, los datos clave de dominios altamente especializados están estrictamente cerrados dentro de redes internas, y para acceder a ellos hay que ser un insider clave o, si eres externo, apenas se abren tras pagar una suma considerable y firmar un NDA.
La mayor parte de los datos con los que aprende la IA son públicos en internet, y si se trata de servicios web/app basados en Python o JavaScript, la automatización completa es posible hasta cierto punto.
Como los algoritmos de gráficos 3D y basados en CAD que se usan en dominios avanzados están dispersos fragmentariamente en internet o directamente no están disponibles, incluso la IA no puede hacer más que producir resultados superficiales con vibe coding. Creo que, teniendo un agente principal y alimentándole de forma continua el contexto del dominio a un nivel de microgestión, desarrollar con un ciclo de Planning → Redirection → Review, no como automatización total dirigida por la IA sino como una forma de amplificación continua guiada directamente por el desarrollador, es un enfoque seguro y realista.
Me revienta ver a desarrolladores haciendo vibe coding sin pensar. Si la calidad de tu resultado es un desastre, a ver si lo vas a justificar diciendo que lo escribió la IA. La responsabilidad la tienes tú.
Gracias. Como Claude también consume muchos tokens y su trabajo me deja algo menos satisfecho en comparación con Codex, últimamente estoy trabajando más con Codex.
Gracias por compartir esta buena información. En realidad, siento que el uso de tokens en sí ya se ha reducido demasiado, así que ojalá lo aumentaran en Claude. Como el arnés se queda corriendo y se corta a la mitad...
Yo también coincido con esta opinión.
Al final, lo veo como una herramienta con un trade-off claro.
Me preocupa que, mientras más use IA, mis habilidades de programación puedan disminuir, pero también es cierto que me lleva a pensar en otras cuestiones que antes no abordaba (o no podía abordar).
Lo estamos usando en la empresa para resumir periódicamente todo tipo de alertas (nos llegan más de cien al día por Slack) y notificar automáticamente las importantes etiquetando al responsable. (También lo estamos probando de forma experimental en parte de la infraestructura dándole un rol de DevOps).
Al principio estaba bastante satisfecho, pero con las actualizaciones se reforzaron los requisitos de seguridad y cada vez siento que se volvió más tonto, snif snif... Estamos gastando como 100 dólares al día en tokens de Bedrock..
id
name
displayName
email
active
admin
guest
timezone
createdAt
updatedAt
lastSeen
También se dice que se filtraron datos y claves de API como tokens de npm o tokens de GitHub. Parece que incluso ya apareció alguien vendiendo los datos.
En la base de este colapso existe una limitación matemática de la "normalización softmax", el corazón de la arquitectura Transformer. Bajo el mecanismo de atención, la suma de los pesos de atención de todos los tokens debe ser necesariamente 1, siguiendo una distribución de suma cero. Por lo tanto, a medida que la longitud N de la secuencia de entrada se expande geométricamente, el peso informativo que puede asignarse a un token clave específico converge inevitablemente a 1/N y se diluye aritméticamente. Esto va más allá de una simple ineficiencia de cómputo: significa que el "noise floor" que el modelo debe procesar aumenta de forma abrupta.
Es un texto sin mucha sustancia: solo enumera argumentos, pero no aporta evidencia concluyente ni experimentos directos que respalden sus afirmaciones.
Se siente como una extensión aburrida de frases de Yann LeCun como: "Incluso si llegamos a GPT-5000, el modelo no aprenderá que si pones un objeto sobre una mesa y empujas la mesa, el objeto también se moverá con ella", o "Los modelos autorregresivos inevitablemente colapsan por la acumulación de errores a medida que la secuencia se hace más larga"...
Dicho mal y pronto, hasta da para sospechar si no será una publicación hecha para viralizar la empresa mencionada al final del libro blanco.
Me acordé de un post de humor que vi hace poco
Escribió el código a mano y luego le pidió a la IA que lo mejorara,
y le salió:
Phase 1: eliminar código basura
jajaja
No es algo limitado solo a la programación. La dificultad deseable no es simplemente un eslogan trillado, sino que se basa en diversos fundamentos científicos.
A veces me preocupa que un día se descomponga la calculadora y diga que 3 X 3 = 10, y que nadie se dé cuenta de que está mal... Si eso pasara en la computadora del programador que maneja mi cuenta bancaria... creo que no está de más ser cautelosos.
Yo también todavía siento que me falta mucho en mi área de especialidad, así que procuro ser cuidadoso pensando que en las áreas donde recibo ayuda el nivel probablemente sea más o menos ese. En cambio, como la velocidad de avance es bastante alta, sí intento usarlo en tareas donde seguir con más o menos esa calidad sea suficiente.
Tener una calculadora y aun así memorizar las tablas de multiplicar parece un apego a una forma de trabajo del pasado. De todos modos, esa parte la terminará haciendo mejor la calculadora. Lo importante ahora es ganar experiencia mejorando lo que no sale bien mientras usas la calculadora. Pero creo que incluso esto también será temporal.
Parece más bien el discurso sobre lo neuro-simbólico que viene de antes. Hubo una época en la que se le daba más significado a lo "determinista" que ahora. Pero, a medida que el rendimiento mejoró hasta el punto de que los modelos probabilísticos pudieron aproximarse a un nivel determinista, gran parte del espacio para el debate desapareció. Al final, lo que siempre quisimos no era algo determinista, sino una incertidumbre "aceptable". En ese sentido, al menos desde la perspectiva de la "industria" y no de la academia, no creo que haya necesidad de darle demasiado significado al determinismo. Como mínimo, aunque la integración avance cuando la incertidumbre de los modelos generativos actuales se haya estancado, no será para nada demasiado tarde.
Coincido. En sectores como el aeroespacial, el médico y el control de precisión, los datos clave de dominios altamente especializados están estrictamente cerrados dentro de redes internas, y para acceder a ellos hay que ser un insider clave o, si eres externo, apenas se abren tras pagar una suma considerable y firmar un NDA.
La mayor parte de los datos con los que aprende la IA son públicos en internet, y si se trata de servicios web/app basados en Python o JavaScript, la automatización completa es posible hasta cierto punto.
Como los algoritmos de gráficos 3D y basados en CAD que se usan en dominios avanzados están dispersos fragmentariamente en internet o directamente no están disponibles, incluso la IA no puede hacer más que producir resultados superficiales con vibe coding. Creo que, teniendo un agente principal y alimentándole de forma continua el contexto del dominio a un nivel de microgestión, desarrollar con un ciclo de Planning → Redirection → Review, no como automatización total dirigida por la IA sino como una forma de amplificación continua guiada directamente por el desarrollador, es un enfoque seguro y realista.
Me revienta ver a desarrolladores haciendo
vibe codingsin pensar. Si la calidad de tu resultado es un desastre, a ver si lo vas a justificar diciendo que lo escribió la IA. La responsabilidad la tienes tú.¿Cuál de los dos trabaja mejor, el buey negro o el buey amarillo?
El buey que recibe insultos es el que trabaja mejor.
Siento que siempre responden con un argumento parecido a este... Las calculadoras no se equivocan al calcular. Cumplen bien su función.
Gracias. Como Claude también consume muchos tokens y su trabajo me deja algo menos satisfecho en comparación con Codex, últimamente estoy trabajando más con Codex.
Gracias por compartir esta buena información. En realidad, siento que el uso de tokens en sí ya se ha reducido demasiado, así que ojalá lo aumentaran en Claude. Como el arnés se queda corriendo y se corta a la mitad...
Por eso, para preguntas que requieren objetividad, uso un prompt que le indica responder en 3 partes: "positivo/crítico/síntesis".
Guau......!
Yo también coincido con esta opinión.
Al final, lo veo como una herramienta con un trade-off claro.
Me preocupa que, mientras más use IA, mis habilidades de programación puedan disminuir, pero también es cierto que me lleva a pensar en otras cuestiones que antes no abordaba (o no podía abordar).
Lo estamos usando en la empresa para resumir periódicamente todo tipo de alertas (nos llegan más de cien al día por Slack) y notificar automáticamente las importantes etiquetando al responsable. (También lo estamos probando de forma experimental en parte de la infraestructura dándole un rol de DevOps).
Al principio estaba bastante satisfecho, pero con las actualizaciones se reforzaron los requisitos de seguridad y cada vez siento que se volvió más tonto, snif snif... Estamos gastando como 100 dólares al día en tokens de Bedrock..
id
name
displayName
email
active
admin
guest
timezone
createdAt
updatedAt
lastSeen
También se dice que se filtraron datos y claves de API como tokens de npm o tokens de GitHub. Parece que incluso ya apareció alguien vendiendo los datos.
Esto ya no es ni para bromear..
Es un texto sin mucha sustancia: solo enumera argumentos, pero no aporta evidencia concluyente ni experimentos directos que respalden sus afirmaciones.
Se siente como una extensión aburrida de frases de Yann LeCun como: "Incluso si llegamos a GPT-5000, el modelo no aprenderá que si pones un objeto sobre una mesa y empujas la mesa, el objeto también se moverá con ella", o "Los modelos autorregresivos inevitablemente colapsan por la acumulación de errores a medida que la secuencia se hace más larga"...
Dicho mal y pronto, hasta da para sospechar si no será una publicación hecha para viralizar la empresa mencionada al final del libro blanco.
Me acordé de un post de humor que vi hace poco
Escribió el código a mano y luego le pidió a la IA que lo mejorara,
y le salió:
Phase 1: eliminar código basura
jajaja
No es algo limitado solo a la programación. La dificultad deseable no es simplemente un eslogan trillado, sino que se basa en diversos fundamentos científicos.
A veces me preocupa que un día se descomponga la calculadora y diga que 3 X 3 = 10, y que nadie se dé cuenta de que está mal... Si eso pasara en la computadora del programador que maneja mi cuenta bancaria... creo que no está de más ser cautelosos.
Yo también todavía siento que me falta mucho en mi área de especialidad, así que procuro ser cuidadoso pensando que en las áreas donde recibo ayuda el nivel probablemente sea más o menos ese. En cambio, como la velocidad de avance es bastante alta, sí intento usarlo en tareas donde seguir con más o menos esa calidad sea suficiente.
Tener una calculadora y aun así memorizar las tablas de multiplicar parece un apego a una forma de trabajo del pasado. De todos modos, esa parte la terminará haciendo mejor la calculadora. Lo importante ahora es ganar experiencia mejorando lo que no sale bien mientras usas la calculadora. Pero creo que incluso esto también será temporal.
Parece más bien el discurso sobre lo neuro-simbólico que viene de antes. Hubo una época en la que se le daba más significado a lo "determinista" que ahora. Pero, a medida que el rendimiento mejoró hasta el punto de que los modelos probabilísticos pudieron aproximarse a un nivel determinista, gran parte del espacio para el debate desapareció. Al final, lo que siempre quisimos no era algo determinista, sino una incertidumbre "aceptable". En ese sentido, al menos desde la perspectiva de la "industria" y no de la academia, no creo que haya necesidad de darle demasiado significado al determinismo. Como mínimo, aunque la integración avance cuando la incertidumbre de los modelos generativos actuales se haya estancado, no será para nada demasiado tarde.
¿No sería mejor ordenar un poco las publicaciones que infringen el EULA?