Bueno, es una suposición, pero creo que podría ser porque ya desapareció la barrera de entrada a Rust.
La mayor dificultad era que escribías código y la compilación seguía fallando, pero ahora la IA lo hace por ti.
DIY, el movimiento maker, lo indie, el punk y el código abierto son todos respuestas en contra de la industrialización, el capitalismo y el consumismo, y resulta que para superar sus límites hay que aceptar el consumismo.
Estoy de acuerdo en que el vibe coding encaja con un marco de consumo. Me da la impresión de que es la versión en programación de modas recientes como Temu-kkang y Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053).
Pero si se dice que ese marco de consumo es una forma de no repetir el fracaso del movimiento maker, entonces, como en los comentarios de HN, por varios motivos no puedo estar de acuerdo.
La vibecoding continúa la trayectoria histórica de los desarrolladores ciudadanos.
Creo que la vibecoding ahora avanza hacia convertir la programación en algo tan fácil, rápido e indispensable como la electricidad.
Incluso muchos programadores brillantes de numerosas empresas ya continúan programando con prompts y agentes sin escribir una sola línea de código.
Hay quienes intentan restarle importancia, pero creo que es difícil refutar que la vibecoding de Andrej Karpathy marcará un hito en la historia de la computación.
Buena pregunta. De hecho, la condición "híbrida" de nuestro experimento iba exactamente en esa dirección: una configuración que proporcionaba un resumen organizado junto con registros de experiencia en bruto.
Como resultado, el híbrido obtuvo la puntuación más alta, con 4.95/5.0. Si solo se daba el resumen, era 2.65, pero al agregar registros del proceso como "falló" o "causa desconocida", más bien se compensaban las debilidades del resumen.
Así que la conclusión es que "el problema no es el resumen en sí, sino que debe incluir también el proceso y la incertidumbre".
Sin embargo, como N=1, se necesita investigación posterior para saber si esto puede usarse de forma general con distintos tipos de usuarios.
Es cierto. Yo también al principio esperaba que la memoria sintética fuera al menos mejor que la línea base, pero me sorprendieron los resultados.
Al analizarlo, vi que la clave era la "preservación de la incertidumbre". En los logs sin procesar quedan rastros como "probé esto, pero no funcionó" o "no sé cuál es la causa", así que el agente responde que no sabe lo que no sabe; en cambio, en el resumen todo ese contexto se borra y termina dando respuestas incorrectas con seguridad.
Es interesante, pero también da la impresión de que simplemente evolucionó hacia el lado de usar muchos de sus propios tokens y cobrar más, y también pienso que, en realidad, hasta cierto punto hay bibliotecas que la IA ya aprendió y por eso simplemente las genera.
Pensar que solo ciertas bibliotecas van a desarrollarse por preferencia de los agentes también se siente un poco extraño.
Al final, el Departamento de Defensa de EE. UU. descartó a Anthropic y eligió a OpenAI, pero hay una diferencia en el wording, como suele decirse.
OpenAI propuso junto con ello mecanismos concretos de implementación como la construcción de salvaguardas técnicas, el despliegue de FDE (ingenieros de campo) y una implementación dedicada en la nube.
Anthropic pidió cláusulas de excepción a nivel de términos de uso.
Desde la postura del Departamento de Defensa de EE. UU., esto se vio como que "una empresa privada ejerce poder de veto sobre casos de uso individuales", y lo anunciaron casi como una sanción por resentimiento.
Este acuerdo se anunció poco después de que Anthropic fuera designada como riesgo para la cadena de suministro,
y si uno ve el artículo de Axios, el Departamento de Defensa usó su confrontación con Anthropic para marcar el tono en las negociaciones con otras empresas de IA,
y OpenAI, bajo esa presión, terminó cerrando un acuerdo en una forma que el Departamento de Defensa podía aceptar.
La diferencia en la manera de expresarlo oficialmente también es grande.
Sam Altman dijo que "el Departamento de Defensa mostró un profundo respeto por la seguridad",
mientras que del lado de Anthropic mantuvieron hasta el final un tono de "no podemos aceptar en conciencia las exigencias del Departamento de Defensa".
Parece que, aun partiendo de los mismos principios, la diferencia estuvo en si se le permitía o no al Departamento de Defensa salvar las apariencias,
y al final, como OpenAI aceptó, la situación quedó con una forma extraña,
así que Sam Altman al final añadió que "estas condiciones deberían ofrecerse por igual a todas las empresas de IA",
lo que parece haber sido un mensaje indirecto para que se suavizaran las medidas contra Anthropic.
Como desarrollador solista, estoy operando 7 proyectos, y este artículo me pegó durísimo.
Gracias a las herramientas de coding con IA, la velocidad de desarrollo inicial se volvió absurdamente rápida, pero el código que acumulé rápido sin tests terminó convirtiéndose en un infierno de refactorización. Sobre todo, cuando operas varios servicios al mismo tiempo, en los proyectos sin tests da miedo tocar cualquier funcionalidad porque siempre está el temor de que algo más explote en otro lado.
La metáfora de "tests = foso" es exacta. Un competidor puede copiar el código, pero es difícil que también replique una suite de tests que cubra miles de edge cases. Y esto es aún más cierto porque, aunque la IA genera código bastante bien, crear escenarios de prueba realmente significativos sigue siendo un área donde todavía hace falta el conocimiento de dominio de una persona.
Tengo una duda para los desarrolladores: ¿por qué últimamente la mayoría de los proyectos parecen desarrollarse más en Rust que en Golang? ¿La razón principal es la presencia o ausencia de GC?
Es una investigación interesante. En particular, me impresiona que en “Build vs Buy”, 12 de 20 categorías sean DIY.
Nosotros también hicimos una observación similar mientras creábamos el estándar de persona para agentes de IA (Soul Spec): si no se especifican herramientas para Claude Code en CLAUDE.md o AGENTS.md, tiene una fuerte tendencia a implementarlo a su manera.
Lo que sugiere el “Recency Gradient” de este estudio es que, para que una herramienta nueva entre al stack base de Claude, necesita suficiente exposición en los datos de entrenamiento o debe indicarse explícitamente en los archivos de contexto del proyecto. Al final, Context Engineering termina influyendo incluso en la selección de herramientas.
Para las herramientas para desarrolladores, ahora se ha vuelto importante convertirse en productos preferidos por los agentes.
Si el agente ni siquiera las menciona, cada vez se irán quedando más atrás.
Hace poco también agregaron Ralph loop, y viendo que también sumaron Financial skill, da la impresión de que si uno simplemente espera, las funciones que estaban en herramientas de terceros entran bastante rápido.
Bueno, es una suposición, pero creo que podría ser porque ya desapareció la barrera de entrada a Rust.
La mayor dificultad era que escribías código y la compilación seguía fallando, pero ahora la IA lo hace por ti.
Parece que era una prueba de Joke.
DIY, el movimiento maker, lo indie, el punk y el código abierto son todos respuestas en contra de la industrialización, el capitalismo y el consumismo, y resulta que para superar sus límites hay que aceptar el consumismo.
Estoy de acuerdo en que el vibe coding encaja con un marco de consumo. Me da la impresión de que es la versión en programación de modas recientes como Temu-kkang y Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053).
Pero si se dice que ese marco de consumo es una forma de no repetir el fracaso del movimiento maker, entonces, como en los comentarios de HN, por varios motivos no puedo estar de acuerdo.
La vibecoding continúa la trayectoria histórica de los desarrolladores ciudadanos.
Creo que la vibecoding ahora avanza hacia convertir la programación en algo tan fácil, rápido e indispensable como la electricidad.
Incluso muchos programadores brillantes de numerosas empresas ya continúan programando con prompts y agentes sin escribir una sola línea de código.
Hay quienes intentan restarle importancia, pero creo que es difícil refutar que la vibecoding de Andrej Karpathy marcará un hito en la historia de la computación.
Buena pregunta. De hecho, la condición "híbrida" de nuestro experimento iba exactamente en esa dirección: una configuración que proporcionaba un resumen organizado junto con registros de experiencia en bruto.
Como resultado, el híbrido obtuvo la puntuación más alta, con 4.95/5.0. Si solo se daba el resumen, era 2.65, pero al agregar registros del proceso como "falló" o "causa desconocida", más bien se compensaban las debilidades del resumen.
Así que la conclusión es que "el problema no es el resumen en sí, sino que debe incluir también el proceso y la incertidumbre".
Sin embargo, como N=1, se necesita investigación posterior para saber si esto puede usarse de forma general con distintos tipos de usuarios.
Entonces, ¿cambiaría algo si la memoria sintética se configurara para incluir el proceso, los fracasos y los éxitos de esas tareas?
Es cierto. Yo también al principio esperaba que la memoria sintética fuera al menos mejor que la línea base, pero me sorprendieron los resultados.
Al analizarlo, vi que la clave era la "preservación de la incertidumbre". En los logs sin procesar quedan rastros como "probé esto, pero no funcionó" o "no sé cuál es la causa", así que el agente responde que no sabe lo que no sabe; en cambio, en el resumen todo ese contexto se borra y termina dando respuestas incorrectas con seguridad.
Era algo que ya venía sintiendo empíricamente, pero la memoria sintética está incluso peor de lo desastrosa que imaginaba.
Quise probarlo, pero parece que solo soporta hasta Gemini 2.5... ¿La lista de modelos compatibles también la hicieron a punta de vibe coding?
Es interesante, pero también da la impresión de que simplemente evolucionó hacia el lado de usar muchos de sus propios tokens y cobrar más, y también pienso que, en realidad, hasta cierto punto hay bibliotecas que la IA ya aprendió y por eso simplemente las genera.
Pensar que solo ciertas bibliotecas van a desarrollarse por preferencia de los agentes también se siente un poco extraño.
Al final, el Departamento de Defensa de EE. UU. descartó a Anthropic y eligió a OpenAI, pero hay una diferencia en el wording, como suele decirse.
OpenAI propuso junto con ello mecanismos concretos de implementación como la construcción de salvaguardas técnicas, el despliegue de FDE (ingenieros de campo) y una implementación dedicada en la nube.
Anthropic pidió cláusulas de excepción a nivel de términos de uso.
Desde la postura del Departamento de Defensa de EE. UU., esto se vio como que "una empresa privada ejerce poder de veto sobre casos de uso individuales", y lo anunciaron casi como una sanción por resentimiento.
Este acuerdo se anunció poco después de que Anthropic fuera designada como riesgo para la cadena de suministro,
y si uno ve el artículo de Axios, el Departamento de Defensa usó su confrontación con Anthropic para marcar el tono en las negociaciones con otras empresas de IA,
y OpenAI, bajo esa presión, terminó cerrando un acuerdo en una forma que el Departamento de Defensa podía aceptar.
La diferencia en la manera de expresarlo oficialmente también es grande.
Sam Altman dijo que "el Departamento de Defensa mostró un profundo respeto por la seguridad",
mientras que del lado de Anthropic mantuvieron hasta el final un tono de "no podemos aceptar en conciencia las exigencias del Departamento de Defensa".
Parece que, aun partiendo de los mismos principios, la diferencia estuvo en si se le permitía o no al Departamento de Defensa salvar las apariencias,
y al final, como OpenAI aceptó, la situación quedó con una forma extraña,
así que Sam Altman al final añadió que "estas condiciones deberían ofrecerse por igual a todas las empresas de IA",
lo que parece haber sido un mensaje indirecto para que se suavizaran las medidas contra Anthropic.
¿No podrían dejarlo simplemente minimalista...?
O, ya que desapareció WordPad, podrían sacar algo nuevo y más liviano...
Como desarrollador solista, estoy operando 7 proyectos, y este artículo me pegó durísimo.
Gracias a las herramientas de coding con IA, la velocidad de desarrollo inicial se volvió absurdamente rápida, pero el código que acumulé rápido sin tests terminó convirtiéndose en un infierno de refactorización. Sobre todo, cuando operas varios servicios al mismo tiempo, en los proyectos sin tests da miedo tocar cualquier funcionalidad porque siempre está el temor de que algo más explote en otro lado.
La metáfora de "tests = foso" es exacta. Un competidor puede copiar el código, pero es difícil que también replique una suite de tests que cubra miles de edge cases. Y esto es aún más cierto porque, aunque la IA genera código bastante bien, crear escenarios de prueba realmente significativos sigue siendo un área donde todavía hace falta el conocimiento de dominio de una persona.
Tengo una duda para los desarrolladores: ¿por qué últimamente la mayoría de los proyectos parecen desarrollarse más en Rust que en Golang? ¿La razón principal es la presencia o ausencia de GC?
Esto está bueno.
Es una investigación interesante. En particular, me impresiona que en “Build vs Buy”, 12 de 20 categorías sean DIY.
Nosotros también hicimos una observación similar mientras creábamos el estándar de persona para agentes de IA (Soul Spec): si no se especifican herramientas para Claude Code en
CLAUDE.mdoAGENTS.md, tiene una fuerte tendencia a implementarlo a su manera.Lo que sugiere el “Recency Gradient” de este estudio es que, para que una herramienta nueva entre al stack base de Claude, necesita suficiente exposición en los datos de entrenamiento o debe indicarse explícitamente en los archivos de contexto del proyecto. Al final, Context Engineering termina influyendo incluso en la selección de herramientas.
También está bueno que el dataset original esté publicado: https://github.com/amplifying-ai/claude-code-picks
Estados Unidos “China”
Eso le llaman Assistive agent optimization (AAO).
Para las herramientas para desarrolladores, ahora se ha vuelto importante convertirse en productos preferidos por los agentes.
Si el agente ni siquiera las menciona, cada vez se irán quedando más atrás.
Hace poco también agregaron Ralph loop, y viendo que también sumaron Financial skill, da la impresión de que si uno simplemente espera, las funciones que estaban en herramientas de terceros entran bastante rápido.