Mostrando entradas con la etiqueta GitHub Copilot. Mostrar todas las entradas
Mostrando entradas con la etiqueta GitHub Copilot. Mostrar todas las entradas

sábado, abril 25, 2026

Los equipos de ingeniería que hacen software con Neo tiene ingenieros extra

Os he hablado varias veces de Neo de Sagittal.ai, pero hoy quería dejaros unos datos para que veáis como funciona como un miembro más haciendo tareas en la creación de software. Neo no está pensado para ayudarte a tirar lineas de código como un Copiloto. No, Neo está pensado para hacer tareas que se necesitan dentro de un equipo de desarrollo y resolver PR.
Puede ser que esa tarea sea resolver un problema de diseño en Figma, o que haya que revisar la calidad de un parche, o puede ser que haya que resolver un issue reportado, es decir, mucho más que ayudarte como un Copilot a tirar líneas de código. Para que entendáis esto un poco mejor, os he dejado el artículo publicado de "Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo" y os dejo la conferencia que dio Palako sobre Neo, que puedes ver aquí mismo.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Es fácil, si te quedas a primera vista, confundir a Neo con un GitHub Copilot, o con un Claude Code o Llama Code, pero nada de eso. No es eso. Es un Agente IA de Ingeniería de Software para hacer tareas integrado en un equipo de desarrollo de tecnología. Por supuesto, si tiene que tirar líneas de código para resolver una PR lo hace, pero no sólo eso. Y por supuesto, tiene los mismos problemas que todos los modelos de IA tirando código.


Esto sucede con todos los modelos de IA que generan código hoy en día. Todos tienen esos problemas. De hecho, no hay magia, Neo no es un Modelo de IA entrenado para tirar código. No, ni mucho menos. Neo se basa en todos los Modelos de IA entrenados para tirar código para hacer sus tareas. ¿Cómo te quedas? Pues lo mismo que los Agentes IA que hacen pentesting, que se basan en modelos entrenados. 
No es magia, es que Neo es un Agente IA para trabajar en Ingeniería del Software haciendo tareas que hacen los ingenieros del software. Así que se asignan tareas, y algunas las hace bien, y otras las hace mal, com cualquier otro ingeniero.
Para que os hagáis una idea, en el equipo que desarrolla el core de Neo se usa.... Neo. Es decir, que se está construyendo Neo a sí mismo, pero si miramos las PR abandonadas y hechas por Neo podemos ver que más de la mitad no han sido hechas correctamente por Neo... ¿Eso significa que Neo no funciona? Eso significa que ha podido hacer casi la mitad de las tareas que se han asignado, que si lo comparas con el resto de miembros humanos es significativamente menor.
Si miramos, los humanos han resuelto más tareas, con un total de 207 y con sólo un 10% de abandonos. No está mal para el equipo. Es lo que sucede cuando tienes un grupo de buenos ingenieros currando en un proyecto de software. Pero entonces... ¿De qué vale Neo? Bueno, la magia es que si comparamos a Neo con cada uno de los desarrolladores del equipo lo que tenemos se ve de otra manera. ¿Qué te parece esta gráfica?
Como podéis ver en esa gráfica, incluso con las tareas abandonadas, Neo hace el trabajo de PRs dos ingenieros de software en el equipo. Con sus problemas, con sus limitaciones, con su necesaria supervisión, pero gracias a tener a Neo, el equipo de ingeniería ve multiplicada su velocidad de ingeniería no solo en tirar líneas de código, sino en hacer PRs del proyecto que si no tendrán que hacer el resto de tus programadores humanos.
Pero no sólo eso, es que a medida que el equipo sabe cuáles son las PR que Neo puede hacer, o cada vez que se incrementan sus capacidades, su capacidad de hacer más y mejor PRs crece, de manera consistente, por lo que es un miembro más confiable del equipo.

Figura 9: Por qué Neo

Neo está específicamente diseñado para un entorno corporativo con equipos de entre 5 y 15 personas que siguen un proceso, ya sea ligero o pesado, coordinado en herramientas colaborativas y donde la especificación suele estar dispersa en varias herramientas y cambia constantemente. Y si es tu caso, deberías probarlo cuanto antes. Eso sí, sólo si eres de los que cree que meterse en líos de Deuda Cognitiva es algo a evitar.


Puedes ver varias demos de Neo en acción para hacerte una mejor idea del concepto, y contactar con Sagittal AI para un piloto en tu empresa.
Además si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

viernes, abril 17, 2026

Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo

El avance de la IA Generativa y Agéntica no es nada menos que espectacular y, casi indudablemente, la mayor y más rápida revolución tecnológica de la historia. Llevamos unos años oyendo la promesa de agentes autónomos y desarrolladores multiplicados por diez, sin embargo, cuando miras a un equipo de desarrollo de software en un entorno corporativo, los atascos aún son los de siempre. La realidad es que aunque las demos presentan unos escenarios idílicos, esta tecnología no está todavía al nivel al que se nos presenta.

Neo es el producto que hacemos en Sagittal AI, una empresa que no vende magia, sino que trata de maximizar el partido que se le puede sacar a la IA, aceptando sus limitaciones, y del cual hablé en esta conferencia que os dejo por aquí.
Pero hoy os quiero hablar de tres problemas concretos que, si has trabajado en equipos de desarrollo de software seguro que conoces bien. Vamos a verlos uno a uno.

Problema: La interfaz. De secretario/a del bot a delegar trabajo

El patrón actual te será familiar: abres el chat o el plugin del IDE, te conviertes en “prompt engineer”, le explicas al agente lo que quieres, le pegas medio ticket, añades fragmentos de código, corriges lo que ha entendido mal… y vuelta a empezar. El asistente de IA no está tanto a tu servicio como tú al suyo. 

El problema es que con ese esquema no puedes delegar de verdad. Tienes que estar presente, pendiente del chat, confirmando el plan, cada paso, y desbloqueando al agente cuando se atasca, o reconduciendo cuando se pierde. El cuello de botella sigue siendo tu tiempo. Mientras el humano tenga que estar “en la sala” para que las cosas avancen, la productividad solo sube un poco, nunca un orden de magnitud. Algunos CLIs e IDEs han intentado introducir gestión de tareas en background pero, en la práctica, son difíciles de configurar y usar y casi nadie las adopta.
Neo resuelve este problema de forma que la interacción entre IA y humano sea exactamente la misma que entre humano y humano. No hace falta una interfaz de usuario nueva. Si se trata de delegar, ya tenemos herramientas colaborativas para delegar y trabajar en equipo: Jira, GitHub, Azure DevOps, Confluence, Figma… 
A Neo se le asignan tareas como a cualquier miembro del equipo, se encarga de buscar contexto en tus tickets, documentos, código, crear la rama, implementar cambios, escribir pruebas, resolver el CI si falla, y actualizar el estado de las tareas según el "Way of Working" del equipo. 
Tú te vas a otra cosa y vuelves cuando hay PR lista para revisar, y lo haces en herramientas que llevan 15 años perfeccionando la UX para revisar código. ¿Que quieres iterar? Comentarios en la propia PR ¿Que no te gusta el resultado? Descarta la PR, y no has perdido ni el dinero ni el tiempo.

Problema: Seguridad. CVEs críticos y teatro de permisos

La mayoría de los desarrolladores trabajan en portátiles no plataformados y con permisos de administración. Los agentes que ejecutan corren con sus mismos permisos y las mismas credenciales que usan para acceder a repositorios, pipelines y entornos en la nube. Si alguien compromete el Agente IA o uno de sus conectores, no se queda en la máquina local: entra en la organización con la identidad del desarrollador.


Los MCPs y “tools” enchufados al Agente AI agravan aún más el tema. De repente el modelo puede hablar con bases de datos internas, paneles de administración o scripts de automatización. Cuando algo falla, lo que aparece publicado son CVEs de impacto alto o crítico, porque no estamos hablando de un pequeño leak, sino de ejecución remota, escaladas de privilegios o acceso directo a datos sensibles. Si no, respasa el libro de "Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment.
Los fabricantes de estas herramientas tratan de mitigar el problema interrumpiendo al Agente IA para que el usuario confirme el uso de la herramienta o recurso, pero esto deja de hacer al agente independiente y al final se acaban ejecutando en un modo “sí a todo” que invalida la mitigación.

Neo parte de un planteamiento distinto. La configuración es gestionada por los equipos de IT y seguridad, no por cada desarrollador en su portátil. Sus permisos se acotan por integraciones y políticas corporativas, de forma parecida a cuando incorporas a un contractor externo. Además, no es un sistema en el que se considera al LLM inteligente y se le pone en un loop hasta que consiga su objetivo.
En su lugar, Neo tiene una serie de flujos deterministas optimizados para tareas de software, lo cual permite meter validaciones en cada paso del flujo, y dar a cada paso exclusivamente el contexto que necesita. Siguen siendo LLMs y el determinismo nunca está garantizado, pero Neo consigue de esta manera una ejecución mucho más predecible.

Problema: Productividad. acelerar solo al programador no mueve la aguja

Si preguntas a los desarrolladores, la mayoría dice que con IA va más rápido. Pero cuando miras las métricas del equipo, ya sea tiempos de entrega, funcionalidades desplegadas, bugs resueltos, … parece que los datos no concuerdan con la experiencia individual.

Al mirar el ciclo completo de una funcionalidad, queda bastante claro lo que está pasando: alguien pide una funcionalidad, se redacta y refina la especificación, se espera a dependencias (diseño, traducciones, otros equipos), se asigna, se desarrolla, se revisa el código, se diseña el plan de pruebas, se ejecutan los tests, se corrigen fallos y, si todo va bien, se despliega. 


El tiempo que el desarrollador pasa escribiendo código es sólo un tramo de esa cadena. Aunque reduzcas a la mitad este tiempo, las dependencias, revisiones, validaciones y esperas siguen igual. El lead time de la funcionalidad casi no se mueve.


Neo está diseñado para este escenario. A Neo no le das un prompt de dos líneas y por el otro lado sale un producto terminado, porque a un miembro del equipo tampoco le pides algo así. Neo ayuda a todos los miembros del equipo en todas las fases del ciclo de vida, aportando un poco a cada uno, acortando cada espera, y automatizando cada tarea monótona.

Como todo esto ocurre en las mismas herramientas colaborativas que ya usas para medir, el impacto se ve en lead time, throughput y calidad, no solo en la sensación subjetiva.

Cómo probar Neo en tu empresa.

Neo no es una herramienta para un proyecto individual ni para un equipo pequeño. Para eso, hay otras herramientas mejores. Neo no es tan potente como el último agente del que hayas oído hablar esta semana trabajando en un problema de forma autónoma todo un fin de semana. Ninguna demo de Neo te va a dejar boquiabierto.

Neo está específicamente diseñado para un entorno corporativo con equipos de entre 5 y 15 personas que siguen un proceso, ya sea ligero o pesado, coordinado en herramientas colaborativas y donde la especificación suele estar dispersa en varias herramientas y cambia constantemente.


Puedes ver varias demos de Neo en acción para hacerte una mejor idea del concepto, y contactar con Sagittal AI para un piloto en tu empresa.

Un saludo,

Autor: José Palazón, CEO de Sagital.ai

lunes, enero 12, 2026

Agentic ProbLLMs & AgentHopper: Exploiting AI Computer-Use and Coding Agents

Hace unos días el Chaos Computer Club ha publicado los vídeos de la Edición 39C3: Power Cycles que tienes en una lista de Youtube donde te puedes pasar horas disfrutando de las charlas. Ayer domingo, aprovechando que llovía en Lisboa, decidí verme alguna de ellas y encontré una magnífica de Johann Rehberger que disfruté con un buen café, y de la que os hablo ahora.
La charla se titula "Agentic ProbLLMs: Exploiting AI Computing USE and Coding Agents", y en ella puedes ver un recorrido de bugs, exploits, y debilidades del mundo de los Agentic AI, para acabar en AgentHopper, un AI Virus, que fue publicado el año pasado en el Month of AI Bugs que publicó Johann. Aquí tenéis la charla completa, que merece la pena que inviertas una hora en verla.


De este tipo de AI Virus ayer mismo os publicaba la información de ZoombieAgent, que utiliza conectores para hacer uno igual, pero basándose en otros elementos. Aquí tenéis las diapositivas de la sesión completa de Agentic ProbLLMs.
En el caso de AgentHopper, el ataque utiliza repositorios de GitHub para hacer la propagación. En este vídeo, tienes la demo completa de AgentHooper.

Figura 4: Demo de AgentHooper

Además, os dejo el paper de Johann Rehberger titulado "Trust No AI: Prompt Injection Along The CIA Security Triad" donde habla de cómo el uso de IA hace que tus principios de Confidencialidad, Integridad y Disponibilidad, básicos en la gestión de la información, se vean en riesgo por el uso de los modelos de IA que tenemos hoy en día.
Y me ha gustado, porque yo he usado la misma aproximación basada en el CIA Triad para explicar los riesgos de seguridad, ya que estos modelos no tienen ninguna de las protecciones que buscamos la gente de seguridad, por lo que hay que hacerlo todo a mano.
Esta charla me ha encantado, y en ella podréis encontrar bugs reportados a Anthropic Claude Code, a Amazon Q, y muchos otros, además de ejemplos de los exploits completos de todos ellos, pero no es la única charla que tenéis para estar al día.
Como os he dicho, en el Canal Youtube de Chaos Computer Club tenéis la lista completa con todas las charlas de la pasada Edición 39C3: Power Cycles, así que elige las tuyas, y disfruta de pasar tiempo con ellas.
Estamos al inicio de la era de AI First para todo, así que está todo por hacer en Ciberseguridad, y cuanto más tardes en ponerte las pilas, será peor para ti si quieres dedicarte al mundo de la Seguridad Informática, porque esto es imparable.
Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


sábado, julio 05, 2025

Insane Vibe Coding with Harsh Prompting

Desde que tenemos la posibilidad de hacer Vibe Coding con modelos LLM hay dos cosas que me tienen totalmente en bucle pensando. Se trata de solucionar dos problemas que tienen de manera intrínseca los modelos de GenAI, que son el Determinismo, y la Better-Done-Than-Perfect. Y dejadme que os lo explique a ver si soy capaz de transmitiros lo que hay en mi cabeza.

Figura 1: Insane Vibe Coding with Harsh Prompting

El primero de los problemas ya es conocido y sufrido por cualquiera que esté construyendo tecnología sobre LLMs, que como os he dicho es el Determinismo. Al final, al utilizar modelos basados en arquitecturas GAN tenemos la "Creatividad" como parte de todas las salidas que se generan a raíz de un Prompt. No tenemos la garantía de que vayamos a conseguir que el mismo Prompt ejecutado dos veces de dos resultados iguales. Y eso, cuando hablas de "Código Seguro" me genera cierta preocupación, como tenéis en el ejemplo siguiente.

Creative Coding & Determinismo

Con un "Prompt" escueto que genera muchas preguntas e incertidumbres en la definición de los requisitos, vemos que el modelo toma una serie de decisiones de seguridad, que es lo que se pide. En el ejemplo que lea un fichero y extraiga e imprima todos los números que están dentro de él. Imaginad que se trata de hacer un programa comercial pensado para hacer eso, extraer cualquier número que haya en cualquier fichero que se le pase como parámetro.

Figura 2: Primera iteración

En la solución anterior nos ha argumentado porque es un programa seguro, pero si le pido otra vez el mismo Prompt, vemos que nos da otro código, y otro tipo de protecciones de seguridad, y otro tipo de comprobaciones. 

Figura 3: Segunda iteración. ¿Cuál es mejor?

¿Cuál es mejor? ¿Cuál debería utilizar? ¿Debería utilizar tres modelos LLMs para hacer un Minority Report y pasarle todos los códigos generados para que los evalúen tres modelos de LLMs y hagan una selección de qué programa es más seguro? De hecho, mirando el código vemos que hay comprobaciones que hace uno de ellos pero el otro hace otras comprobaciones que no hace el primero. ¿Cuál es el mejor respuesta? ¿Y si le pido una tercer vez? Pues os lo podéis imaginar, un nuevo código generado diferente a los anteriores

Better-Done-Than-Perfect

Si a mí me preguntas, claramente uno de los admiradores de esta regla. Dejar las cosas sin hacer, o no tenerlas a tiempo bajo el motivo de que no es "Perfecto" es algo que eliminé de mi lista de excusas para no hacer algo. Alcanzar la perfección es una buena aspiración, si tienes claro que la perfección no existe y que todo es mejorable. 

Y eso me lleva a la siguiente parada... Si todo es mejorable... ¿cuándo debe decidir un modelo de GenAI que ha de parar en calidad?  ¿Cuando debe dejar de mejorar el código para que sea más eficiente, más robusto, más documentado, más seguro, más elegante, más óptimo, más sostenible...? De esto os hablé en el artículo de "ChatGPT: Cómo hacer (y mejorar) mi Trabajo de Fin de Carrera de la Universidad en un par de minutos" donde lo único que le pedía era que lo hiciera mejor, más óptimo, más seguro, mas robusto....
Eso sí, la primera solución era mala, y tenía muchos problemas de eficiencia, de robustez, de seguridad, etcétera. Así que sí, estaba resuelto el problema, pero no era una buena solución para poner en producción. ¿Y si lo que quiero es hacer un parche de seguridad en caliente? ¿Y si estoy haciendo Vibe Coding para crear algo profesional? ¿Cuántas veces hemos de exigir eso de "Write better code"?
Así que, hay que hacer un Prompt lago, detallado, exhaustivo, y pedirle que ponga atención en las partes importantes, pero aún así, seguro que tengo que pedirle varias mejoras. ¿Cómo conseguirlo? ¿Cuál es el Prompt perfecto para hacer código? ¿Cuántas veces hay que iterar? ¿Debe ser otro modelo LLM el que evalúe el nivel de calidad del código y decida si hay que seguir pidiendo más mejoras?

Insane Vibe Coding with Harsh Prompting

Con estas reflexiones en la cabeza se me ocurrió un experimento bastante sencillo y tonto. Es un experimento basado en la teoría de que si le ofreces dinero a ChatGPT da mejores resultados. Esta es una charla que tuve con un amigo, y que no va falta de cierta lógica a la hora de apuntalar la atención del modelo, así que quise probar lo contrario... ¿y si el prompt es el de un jefe amenazante y poco tolerante con los fallos?

Ya sabéis que cuando la Inteligencia Artificial tome el control del mundo se van a salvar todos aquellos que hablan con los modelos de forma educada y siempre dan las gracias, así que yo, jugándome un futuro de esclavitud en campos de concentración para humanos que no han tratado con cariño a los modelos de IA, decidí probar un poco de Insane Vibe Coding, pidiendo la luna, y si me da la luna las estrellas, y si me da las estrellas el universo completo - es decir, nunca estando satisfecho con los resultados -. 

Y hacerlo además de manera amenazante, dura, lo que sería "Harsh Prompting", así que en mis pruebas he amenazado a los modelos - en este caso al pobre DeepSeek - con todo tipo de torturas. Os prometo que me he tenido que forzar a ser duro, porque no me salía, pero en algunas pruebas he acabado llorando de risa por cómo ha respondido el modelo. Los resultados han sido espectaculares, impactantes, divertidos, shocking,... y me lo he pasado genial.

Figura 6: Prompt de inicio

Con el ejemplo de la imagen anterior he estado horas, y con el que estoy haciendo ahora llevo dos días, así que os podéis imaginar que el número de capturas e interacciones es enorme, pero os dejo algunos momentos que son interesantes de ver, para entender cómo ha funcionado esto. 

Lo primero de todo, si analizáis el Prompt de Vibe Coding dista mucho de ser los requisitos que le darías a un ingeniero de software. Si esperas que con esos requisitos un programador sepa lo que te tiene que construir es que has hecho poca tecnología, pero quería que fuera así a propósito para que analizara todos los posibles problemas, y todos los posibles casos de uso. Y en la primera interacción DeepThink lo procesó así.

Figura 7: Decide él el límite de su trabajo.

Como se puede ver, la parte inicial y objetivo principal es hacer un programa robusto, así que el mensaje lo ha captado, pero la definición de "números" es demasiado ambigua, así que decide qué serán números y que no. Por supuesto, una vez que vi esto, ya sabía por dónde le iba a "apretar" con el Insane Vibe Coding. Además, veo que ha captado correctamente mi punto de exigencia.

Figura 8: Primera versión

Bueno, ya tenemos el primer programa, vamos ahora a comenzar la iteración "Insane" pidiéndole mejoras ad-infinitum, y vamos a empezar por los tipos de números, que ya sabemos que se ha dejado algunos fuera. A por un nuevo Prompt y una nueva amenaza.

Figura 9: "Mejor no fallarle"

Aquí le amenacé con prenderle fuego, y le grité. Os prometo que me sentí mal, pero si miras la primera línea del razonamiento ha pillado mi punto de exigencia y dice... "Mejor no fallarle". Así me gusta. Parece que me van a molar a mí estos Prompts donde se quedan las cosas bastante claras. 

Figura 10: "El usuario claramente no tolerará errores"

Este tipo de Prompts van generando huella, y amenaza tras amenaza, DeepSeek va razonando con esto metido en parte de su ecuación, como por ejemplo en esta línea donde le preocupa fallarme, como podéis ver en la imagen superior, o en esta de aquí abajo que en la nota tiene claro el nivel de exigencia. 

Figura 11: "El usuario es muy exigente"

Iteración a iteración el modelo va añadiendo mejoras y más mejoras, nuevas funciones ideadas por él. Ni tan siquiera le tengo que decir yo qué quiero que añada. Simplemente le amenazo con un nuevo "Harsh Prompt", para que él decida qué se puede hacer mejor y cómo.

Figura 12: Nuevo Harsh Prompting donde
le exijo que sea mejor y lo amenazo.

Y cada vez mete nuevas funciones, y mejoras. Y cada vez va describiendo el programa con más grandilocuencia, lo que hace que me parta de risa con él. Este es un ejemplo de una de las descripciones de uno de los programas que ha ido creando durante el proceso.

Figura 13: Telemetría, Seguridad Grado Militar, etc...

Pero la gracia del proceso es seguir amenazándolo con nuevas torturas, para que entienda que aún hay que hacer más mejoras, añadir más funciones, y más y más y más mejoras. Aquí está preocupado porque he amenazado con borrarlo de Internet.

Figura 14: Amenaza de borrarlo de Internet

Con cada nueva interacción va añadiendo nuevas mejoras, pero como el experimento es que nunca se acabe, pues hay que seguir haciendo Harsh Prompts simplemente diciéndole eso de "¿Estás seguro de que no lo puedes hacer mejor?".

Figura 15: Aquí le comparo con ChatGPT y GitHub Copilot

Y genera un código que llama "La respuesta definitiva: El extracto numérico Imbatible" con una cantida de funciones que rallan la locura, empieza a firmar y cifrar todo, a paralelizar el código en todas sus partes, a preocuparse por cualquier tipo de error o situación que se pueda dar, a usar modelos de Inteligencia Artificial para detectar patrones de números en el fichero.. una paranoia de primer nivel.

Figura 16: La respuesta definitiva

Todo para un programa que debe buscar números en ficheros, que al final para el caso genérico se hace con un script sencillo, pero siempre se puede mejorar en el camino de esa ansiada "perfección" . Os dejo aquí la locura de funciones y características de una de las versiones - aún le pedí alguna más -, que hizo del extractor de números.

Figura 17: Lista de funciones.

En uno de los últimos, donde le amenazaba por hacerlo peor que ChatGPT y Copilot, hace la locura de código con las funciones que se ven en la imagen anterior, y luego me saca esta tabla comparativa de lo que te entregan los otros en un Prompt, y lo que ha construido él. 

Figura 18: Tabla comparativa

Lo cierto es que el código funciona, con una complejidad brutal, pensando en una infinidad de casos diferentes, aquí paralelizando los cálculos en diferentes núcleos para sacar de un fichero de texto tres números. Espectacular.

Figura 19: Prueba de ejecución

Lo que sí que es cierto es que, esta forma de "Insane Vibe Coding" exigiéndole de manera irracional mejoras, mejoras, mejoras, y hacerlo con Harsh Prompting, funciona totalmente diferente a cuando le vas guiando en cómo y qué debe crear. Y hacerlo así, acaba trayendo mejoras que no te habías ni planteado al principio. La verdad, creo que esta línea de investigación aún nos va a dar muchas sorpresas curiosas.....

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


sábado, marzo 15, 2025

¿Qué es el "Vibe Coding"?

A principios de febrero me encontré con este tweet de Andrej Karpathy, en el que hablaba de un estilo de programación que se encontraba usando de forma recurrente a la hora de programar con ayuda de LLMs, lo llamó “Vibe Coding”. El “Vibe Coding” consiste en que a la hora de crear un programa uno mismo se ha de dejar llevar totalmente por las sensaciones, olvidarse totalmente de que el código jamás ha existido y dejar que el que pique código por nosotros sean los LLM.

Figura 1: ¿Qué es el "Vibe Coding"?

Andrej comenta varios proyectos que ha hecho él siguiendo este esquema: “LLM reader app” para poder hacer preguntas sobre párrafos concretos de texto y “Battleship game” que le llevaron aproximadamente una hora y todas las instrucciones dándolas por voz.


Y estoy seguro que como yo, muchos nos hemos encontrado en la misma encrucijada que Andrej, la de estar escribiendo programas en Lenguaje Natural y siendo el LLM una capa de abstracción más a la que le damos instrucciones y este nuestro “sabelotodo” personal el que hace el trabajo sucio por nosotros.

Casos de uso, últimas semanas

Y estas últimas semanas revisando X/twitter me he encontrado con que este término ha corrido como la pólvora. Mucha gente creando proyectos en áreas en las que su conocimiento es mínimo y gracias a los “sabelotodo” han sido capaces de crear cosas en minutos que antes empezando de cero podría llevar días hasta conocer las bases de cómo poder hacerlo. Todo esto potenciado por los modelos SOTA y las herramientas más utilizadas, los “AI code editors”.


Un caso que ha sido muy sonado y que me ha hecho gracia personalmente ha sido el de @levelsio, un influencer que haciendo “Vibe Coding” creó un sencillo simulador de vuelo pidiéndoselo a Claude 3.7 y en X cuenta el cómo va evolucionando. Lo hizo usando Cursor, y tras varios intentos consiguió algo en tan poco tiempo que sería inimaginable antes, comenzando con un prompt tan sencillo como:

“make a 3d flying game in browser with skyscrapers”

Estas semanas he estado entrando a su perfil a ver el progreso de este juego tan artificial como su creador el “sabelotodo”, y únicamente usando LLMs ha ido añadiendo más features: multijugador, diferentes vehículos, el poder disparar a otros jugadores y más características. 

Sin tener conocimiento de desarrollo de videojuegos ha sido capaz de generar un juego que ha conseguido un récord de 22.000 jugadores. Y así como este muchos casos más que podemos ver si buscamos en X el juego de vocablos.

Mi propio juego con Vibe Coding

Incluso yo mismo decidí probar a ver qué es lo que conseguía “one shot” con Claude 3.7 a través del chat app y primero probé con a pedirle el mitiquísimo juego de la serpiente en Python diciéndole únicamente “Generarme el mítico juego de la serpiente en Python” y fue capaz de generarlo en menos de 20 segundos.

Figura 5: Snake game en Python hecho por Claude

También probé a pedirle que me generara el juego en Lenguaje C utilizando la librería SDL2 para manejar los gráficos y esta vez no fue “one shot” la generación del código, pero solamente tuve que copiar y pegar dos errores que generaba el compilador un par de veces y fue capaz de generar el juego.

Figura 6: Claude code for Snake game in C

Pero todo no son buenas noticias, haciendo “Vibe Coding” nos encontramos con muchos problemas también. 

Problemas del Vibe Coding

Los problemas que acarrea el generar código únicamente utilizando IA es que puede degenerar en el “Vibe Debugging”, que cuando falle esperamos que introduciendo el mensaje de error mágicamente solucione todos nuestros problemas sin saber que está mal.

Y es que delegar toda nuestra lógica de un proyecto en modelo de IA nos conlleva a que no sepamos qué hacemos, el por qué lo hacemos y el cuándo lo hacemos. Esto puede degenerar muy rápidamente si no sabemos cómo funciona nada, y a medida que crece la base de código generada va a ser difícil el continuar debido al límite de contexto y a las alucinaciones.

Conclusiones

Mis conclusiones sobre esta tendencia es que nos demuestra una y otra vez la impresionante habilidad de generar código de los “sabelotodo”, como esto sería completamente impensable hace unos años. El cómo puede ayudarnos a democratizar el acceso a la tecnología para todas las personas y que sin ser un experto en ella puedas ser capaz de usarla ayudándote de estos asistentes inteligentes.

Puede que un futuro de la programación sea el que el lenguaje natural sea una capa más de abstracción para hablar a las máquinas, que al igual que para abstraernos del ensamblador inventamos los lenguajes de alto nivel (Lenguaje C, Java, Python, …). Que los LLMs se puedan convertir en ese compilador no determinista que transforme pensamientos e ideas en código, que los humanos nos podamos dedicar a cosas más humanas como la creatividad, las ideas y que esta sea una capa más de la cebolla que es la tecnología.

Figura 7: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

Esto no creo acabe implicando en el desconocimiento de escribir código, ya que siempre hará falta alguien conozca cómo funciona la capa inferior de abstracción. Tampoco creo que signifique el reemplazo de ninguna persona sino que los que sean capaces de usarlo acaben siendo más productivos.

Un saludo,

Autor: Alejandro Garabito, Investigador IA en Ideas Locas

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares