AI Engineering Bootcamp: Basta de hacer tutoriales y construye tu propio asistente con IA en producción

Vivimos rodeados de Inteligencia Artificial, pero la inmensa mayoría de la gente que trabaja "con IA" en realidad se limita a llamar a una API, copiar un prompt de Twitter/X o encadenar un par de bloques en una herramienta no-code. Saben usar la IA como usuario avanzado, pero no entienden qué pasa por debajo: cómo se sirve un modelo, cómo se diseña un agente que razona y actúa, cómo se protege un sistema LLM de un ataque de prompt injection o cómo se lleva todo eso a producción para que funcione 24/7 sin que se caiga a la primera de cambio.

Figura 1: AI Engineering Bootcamp: Basta de hacer tutoriales

y construye tu propio asistente con IA en producción

Esa distancia entre "usar IA" y "construir con IA" es, ahora mismo, la que separa a un consumidor de prompts de un auténtico AI Engineer. Y es precisamente esa distancia la que Ferrumox Academy ha diseñado para recorrer en 9 semanas con su AI Engineering Bootcamp.

Figura 2: AI Engineering Bootcamp

Cohorte 2: arranca la semana del 2 de septiembre

El AI Engineering Bootcamp de Ferrumox Academy no es un curso de vídeos a tu ritmo ni una colección de slides sobre "el futuro de la IA". Es un programa intensivo y práctico: una sesión en directo por semana de 2 horas (tú eliges grupo de lunes, miércoles o viernes, de 18:00 a 20:00) y el resto de la semana para construir, con material previo antes de cada directo y un entregable funcionando al final de cada semana.

Figura 3: Objetivos del Bootcamp

El objetivo final no es "terminar un curso". Es salir con tu propio asistente con IA corriendo en producción: accesible desde Telegram, con memoria persistente, capaz de orquestar varios agentes especializados vía MCP y conectado a tus propios documentos mediante RAG híbrido. Construido por ti, entendido por ti, no copiado de un repositorio de GitHub.

Un programa que va desde la inferencia hasta producción, semana a semana

A lo largo de las 9 semanas (con una sesión 0 bonus de preparación incluida) el temario progresa capacidad a capacidad, sin frameworks mágicos que oculten lo que está pasando por debajo:

• Semanas 1-2: Infraestructura de inferencia propia, local y en la nube (Ollama, vLLM, APIs de OpenAI y Anthropic), y adaptación de modelos con LoRA y QLoRA.

• Semanas 3-4: Context engineering, gestión de memoria persistente y diseño del bucle de agente (agentic loop) con el patrón ReAct y tool calling, implementado sin frameworks para entender de verdad el ciclo razonar-actuar-observar.

Figura 4: Semanas 00 a 03

• Semanas 5-6: RAG avanzado con recuperación híbrida y reranking, y sistemas multi-agente con orquestación vía MCP siguiendo el patrón supervisor.

Figura 5: Semanas 04 - 07

• Semanas 7-8: Seguridad de sistemas LLM, modelado de amenazas, prompt injection, jailbreaking y diseño de guardrails, y despliegue en producción con observabilidad, evals y control de costes.

• Semana 9: Demo day, presentación del proyecto ante toda la cohorte y hoja de ruta para seguir construyendo.

Figura 6: Semanas 8 y 9

Uno de los puntos diferenciales del programa es precisamente el módulo de LLM Security: menos del 1% de los AI Engineers sabe auditar un sistema LLM de verdad, y este bootcamp dedica una semana completa a aprender a atacarlo y a defenderlo, algo que a día de hoy no se encuentra en ningún otro bootcamp en España.

Quién está detrás del programa

El bootcamp lo imparto directamente yo, Manuel S. Lemos, fundador de Ferrumox y Claude Certified Architect de Anthropic (la primera certificación técnica oficial que ha emitido la compañía, sólo accesible por invitación), además de AI Engineer en NaizFit, coautor del libro Hacking IA (0xWord, 2026), contribuidor de OWASP GenAI Security y Vicepresidente de ANBAN. Anteriormente Director Académico de IA & Big Data en GeeksHubs Academy durante cuatro años. También he dado charlas en el GenAI Summit EU, Codemotion Madrid, TofuConf, el Máster de Ciberseguridad del CIPFP Cheste y el podcast de Hackers, entre otros escenarios. 

Figura 7: Una formación para poner en producción

Lo que se enseña en el bootcamp es, literalmente, lo que se construye en producción cada día. Ferrumox es el proyecto para unir dos cosas que normalmente van por separado: ingeniería de IA de verdad y formación de alto nivel. Por un lado está Fox, el motor de inferencia LLM en Rust, de código abierto y gratuito para siempre (sin planes de pago ni capital de por medio), pensado como sustituto directo de Ollama con hasta 4 veces más eficiencia gracias al prefix caching y al continuous batching.

Precio, plazas y un regalo que no falta en ninguna edición

La Cohorte 2 arranca la semana del 2 de septiembre de 2026 y tiene 36 plazas repartidas en 3 grupos de 12 (lunes, miércoles y viernes). Las primeras 12 plazas entran a 997 €; a partir de ahí el precio pasa a 1.200 €. Todas las sesiones se graban y quedan disponibles antes de 24 horas, así que si algún día no puedes conectarte en directo no te quedas fuera. 

Figura 8: Ejemplar de "Hacking IA" (0xWord, 2026), de regalo para cada alumno

Y, como no podía ser de otra manera en este blog, hay premio para los alumnos: cada persona de la Cohorte 2 recibe un ejemplar del libro Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment de 0xWord, incluido sin coste extra en la plaza, y habrá un chat en MyPublicInbox constante conmigo y con Chema Alonso.

Go for it!

Si necesitas un empujón más para decidirte, el 10 de Agosto haremos una clase gratuita que te puedes apuntar desde nuestra web. Además el bootcamp incluye feedback escrito de tus proyectos en 48 horas, repo privado con todo el código, comunidad privada de la cohorte, acceso a las grabaciones de futuras ediciones y más sorpresas.

¡Happy hacking!

Autor: Manuel S. Lemos, Fundador de Ferrumox y director del AI Engineering Bootcamp

Contactar con Manuel S. Lemos

DONKEY.BAS on the Edge: Cómo revivimos el juego de Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)

Hace unos días hablando con Chema Alonso me topé otra vez con uno de esos pequeños tesoros que la historia de la informática guarda en un cajón. DONKEY.BAS. Cuatro mil quinientos bytes de BASIC que vienen de 1981 y que, sin embargo, dan para hablar de muchas cosas. De cómo se hacía software cuando un PC tenía 16KB de RAM, de una de las polémicas más divertidas de la historia de Microsoft y, sobre todo, de algo que veo todos los días en mi trabajo, que es lo fácil que es hoy modernizar y desplegar cualquier aplicación gracias a la plataforma de Cloudflare.

Figura 1: DONKEY.BAS on the Edge: Cómo revivimos el juego de

Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)  

Así que cogí el código original, lo migré a la web y lo puse a correr en producción en Cloudflare Pages en cuestión de minutos. Os cuento la historia completa, que tiene su miga. De la historia de este juego, por lo visto, se habla en el libro de  "Microhistorias: anécdotas y curiosiades de la historia de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso en 0xWord, que os dejo por aquí.

Figura 2: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

Por cierto, antes de entrar en materia con DONKEY.BAS, os recuerdo que ya os publiqué un caso parecido con la migración del mítico Arkanoid en el artículo titulado: "Cómo migrar Arkanoid de C++ a TypeScript con OpenCode y desplegarlo en Workers de Cloudflare".

La historia: el juego que Bill Gates escribió... y por el que le pincharon durante años

DONKEY.BAS lo escribieron en 1981 Bill Gates y Neil Konzen para demostrar las capacidades gráficas (el flamante modo CGA) y de sonido (el mítico PC speaker) del IBM PC, junto con la potencia del intérprete de BASIC que Microsoft había desarrollado para IBM. Venía incluido en las primeras versiones de PC-DOS, así que millones de personas lo tuvieron delante.

Figura 3: El juego de Donkey.BAS Version 2.0 (Fixed Version)

¿El juego? Sencillísimo: conduces un coche por una carretera de dos carriles y solo puedes hacer una cosa, cambiar de carril con la barra espaciadora para esquivar a los burros que van apareciendo. Si chocas, ¡BOOM! y punto para el burro. Si lo esquivas, "Donkey loses!" y punto para ti. No hay más objetivo. No hay final.

Y aquí viene lo "polémico".

Que uno de los fundadores de Microsoft hubiera firmado un juego tan primitivo —con gráficos que parpadeaban y una jugabilidad de quince segundos— se convirtió con los años en una especie de chiste recurrente en la industria.

Cuando salió el Macintosh en 1984, desde el mundo Apple se usó DONKEY.BAS como ejemplo de lo tosco que era el software del bando IBM/Microsoft frente a la elegancia gráfica del Macintosh. Bill Gates, lejos de esconderlo, siempre lo defendió con orgullo: era una demo técnica de lo que se podía hacer, no una obra maestra del diseño de videojuegos.

Figura 4: Pantalla de título original de DONKEY.BAS con el famoso "Version 1.1O"

Hay un detalle que a mí me encanta y que demuestra que las prisas de 1981 eran las mismas que las de hoy: si miráis el código original, en la pantalla de título pone Version 1.1O... con una letra "O mayúscula" en lugar de un cero - tal vez por no mostrar a los usuarios el famoso 0 de las tipografías de los ordenadores con la raya cruzada que los no técnicos quizá nunca entendieron -. Usas una O en lugar de un 0 con la raya cruzada, era igual que en algunas máquinas de escribir donde en lugar de usar el 1 se hacía con la "l" minúscula.

O quizá es un typo que lleva más de cuarenta años viajando por copias y copias del fichero. Quien diga que nunca ha subido a producción con una errata, que tire la primera piedra. El código fuente original que usé como referencia está perfectamente conservado aquí:

Figura 5: DONKEY.BAS en GitHub

Merece la pena abrir el .BAS y leer esos GOTO, esos POKE 106,0 y esos SOUND 37+RND*200,4. Es arqueología pura, y para los amantes del BASIC, un placer visual. 

La migración: de GOTO y POKE a HTML5, Canvas y Web Audio

Lo bonito de un código tan pequeño es que se puede entender entero y replicar su lógica con fidelidad. El programa en BASIC original hace, en esencia, esto:

• Pinta la carretera con dos líneas verticales y una línea central discontinua que se desplaza para dar sensación de avance:
• (`LINE`, `STEP 20`).

• El coche solo tiene dos posiciones X. El truco de cambiar de carril es maravillosamente simple:
• `CX = 252 - CX` (línea 1730).

• El burro aparece en un carril al azar: 
• `DX = 105 + 42*INT(RND*2)` (línea 1700).

• La colisión esta en la línea 1750 con IF que dispara el BOOM! y la animación de fragmentos volando a las esquinas en las líneas 2060-2200.
•  `IF CX=DX AND Y+25>=CY` (línea 1750) 

• Y el sonido, esos pitidos monofónicos del PC speaker, salen de las instrucciones `SOUND`.

Para esta prueba lo reescribí desde cero en HTML5 + CSS + JavaScript puro (Vanilla JS), sin frameworks ni motores de juego pesados, porque la gracia era mantener el espíritu minimalista del original:

• Gráficos: con la API de Canvas, respetando la resolución y la paleta CGA (negro, cian, magenta, blanco), pero con escalado nítido (`image-rendering: pixelated`) para que se vea bien en una pantalla 4K de hoy.

• Sonido: con la Web Audio API, generando ondas cuadradas para emular el PC speaker, un pitido corto al cambiar de carril y una ráfaga aleatoria de tonos para la explosión, calcada del `SOUND 37+RND*200,4`.

• Controles: barra espaciadora para cambiar de carril y Esc para salir, tal cual el original... y, ya puestos a modernizar, soporte táctil para jugar desde el móvil.

Comenté cada bloque del JavaScript indicando qué línea del BASIC original estaba replicando, porque me parecía la mejor forma de honrar el código de Gates y Konzen: no reinventarlo, sino traducirlo.

Figura 6: DONKEY.BAS migrado a Cloudflare Pages

con la estética CGA intacta.

El despliegue: de cero a producción con Cloudflare Pages en minutos

Y aquí es donde, como Account Executive en Cloudflare, no puedo evitar ponerme un poco pesado, porque es justo lo que me enamoró de esta plataforma. Tenía tres ficheros (`index.html`, `style.css`, `game.js`) y quería ponerlos en internet, con HTTPS, en una red global y sin montar ni un solo servidor. Pues bien:

```bash

wrangler login

wrangler pages deploy .

```

Figura 7: Desplegando con Wrangler

Y ya está. Literalmente. Wrangler (el CLI de Cloudflare) subió los ficheros, creó el proyecto y me devolvió una URL de producción servida desde más de 330 ciudades repartidas por el mundo. Sin aprovisionar máquinas, sin configurar un balanceador, sin pelearme con certificados TLS. El juego de Bill Gates de 1981 corriendo en la red perimetral más grande del planeta, gratis y en edge.

Figura 8: DONKEY.BAS  migrado corriendo en la nube de Cloudflare.

Dale al Play y juega.

Para quien prefiera no tocar la terminal, Cloudflare Pages también permite el despliegue por Direct Upload: arrastras la carpeta al panel y listo. O lo conectas a tu repositorio de Git y cada Push despliega solo, con Preview Deployments por cada rama para revisar cambios antes de pasarlos a producción.

¿Y qué tiene esto que ver con modernizar de verdad?

DONKEY.BAS es un juguete, claro. Pero la historia que cuenta es exactamente la misma que vivo con empresas que arrastran aplicaciones de hace veinte o treinta años: hay un core de lógica de negocio valioso atrapado en una tecnología que ya nadie quiere mantener, y el reto no es reescribirlo todo de golpe, sino modernizar la capa de entrega y de ejecución para llevarlo donde están hoy los usuarios.

Y ahí la propuesta de Cloudflare es potentísima, porque no se queda en servir ficheros estáticos:

• Cloudflare Workers: ejecuta tu lógica de backend en JavaScript, TypeScript, Python o Rust (vía WebAssembly) directamente en el edge, con arranques en frío de milisegundos. Olvídate de pensar en servidores o en regiones; tu código corre cerca del usuario, donde esté.

• Cloudlfare Pages + Functions: para frontends modernos con su API integrada, sin coser dos plataformas distintas.

• Almacenamiento y estado en el edge: Workers KV, D1 (SQL), R2 (objetos, sin tarifas de salida) y Durable Objects para coordinación y estado en tiempo real. Tu aplicación heredada puede ir migrando piezas a estos servicios sin un Big Bang.

• Seguridad de serie: WAF, mitigación de DDoS, *bot management* y Zero Trust delante de todo. Modernizar también es poner la seguridad por delante, no como un parche posterior.

• IA en el edge con Workers AI y AI Gateway: por si a ese DONKEY.BAS del futuro queréis ponerle un rival que conduzca solo con IA.

La clave es que puedes hacerlo incremental. Pones Cloudflare delante de tu aplicación actual, empiezas a mover funcionalidad a Workers poco a poco (el patrón strangler fig de toda la vida) y, sin pararlo todo, acabas con una arquitectura distribuida, segura y rápida. Igual que yo no reescribí la lógica de DONKEY.BAS, sino que la trasladé a una plataforma moderna.

Conclusión: cuarenta años después, el burro sigue cruzando

Me hace especial ilusión que un trozo de código de 1981, escrito por dos genios con un IBM PC y muchísimo ingenio, pueda estar hoy en producción en una red global sin tocar un servidor. Es la mejor metáfora que se me ocurre de para qué sirve todo esto: 

La tecnología cambia, pero las buenas ideas —y los buenos cores de negocio— merecen viajar bien.

Si tenéis una aplicación heredada que os da miedo tocar, hablemos. A lo mejor vuestro "DONKEY.BAS" particular está a un `wrangler pages deploy` de tener una segunda vida. Y si solo queréis jugar y esquivar burros como en 1981, también os entiendo perfectamente. Puedes jugar a DONKEY.BAS en Cloudflare aquí.

Que gane el mejor conductor.

Autor: Carlos Luengo,  Senior Account Executive en Cloudflare. 

Contactar con Carlos Luengo

CONVEX 2026: 17 y 18 de Junio en Madrid

Tradicionalmente he hablado en la DotNetConference de mis amigos de PlainConcepts, pero este año el equipo ha querido unir tres eventos, como es la referencia DotNetConference, el Singularity Tech Day y el Global Software Architecture Summit en uno solo, con varios tracks en paralelo, al que han llamado CONVEX, y que tendrá lugar durante los días 17 y 18 de Junio de este año en Kinépolis de Madrid.

Figura 1: CONVEX 2026 - 17 y 18 de Junio en Madrid

El evento comienza el día de mi cumpleaños - ya lo sabéis, lo dice mi Wikipedia - y las keynotes principales de los dos días las daremos mi querido compañero y amigo de mil y una batallas, David Carmona, que abrirá el día 17 mientras que yo aplaudo desde el público. A mí me toca abrir el segundo día, el 18 de Junio, para hablar de mis temas favoritos de Ciberseguridad (slash) hacking (with slash the) Inteligencia Artificial. 

Figura 3: CONVEX 2026 - 17 y 18 de Junio en Madrid

Pero después de las Keynotes, el evento se abre cada día en tres tracks en paralelo para que puedas asistir a las charlas que más te motiven, o te interesen. Entre los ponentes, pues una autentica maravilla, desde el gran Midudev, hasta Luis Fraile, pasando por Carlos Medible o Manuel Sánchez, pero echa un ojo a la agenda completa en la web.

Figura 3: Speakers de CONVEX 2026

Además, este año, la organización va a entregar 100 Tempos a todos los asistentes al congreso. Y además, para poder conseguir tu entrada con un 40% de descuento, puedes conseguir un código en MyPublicInbox por 300 Tempos.

Figura 4: Canjear un 40% de descuento de la entrada

Y si no me equivoco, salvo error u omisión, creo que este será mi último evento antes del verano en España.... (creo), pero si hay cambios, seguro que os lo cuento por aquí, como hago siempre. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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.

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

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.

Figura 3: IA falla, a veces es frustrante y a veces alucina

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. 

Figura 4: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

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.

Figura 5: Tareas abandonas (rechazadas) y aceptadas a Neo

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.

Figura 6: Pull Requests hechas por humanos

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?

Figura 7: Neo es el mayor contribuidor al proyecto

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.

Figura 8: Consistencia de Neo a lo largo del tiempo

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.

Figura 10: Comienza a probar Neo desde hoy mismo

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.

Figura 11:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

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)  

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.

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

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í.

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

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.

Figura 3: Neo funciona integrado en tus plataformas de ingeniería del software

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… 

Figura 4: Tools con las que se integra Neo

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. 

Figura 5: Pull request diagrams

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.

Figura 6: Cosas que puede hacer Neo en tus equipos de ingeniería

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.

Figura 7:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

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.

Figura 8: Fix vulnerabilities before they happen

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. 

Figura 9: Project Plan de Ingeniería del Software

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.

Figura 10: Code and test plans in Azure DevOps

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.

Figura 11: Comienza a probar Neo desde hoy mismo

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

 Contactar con José Palazón

Vibe Coding en BASIC para AMSTRAD CPC sale (un poco) más caro

¿Qué otra cosa mejor que estar probando Vibe Coding en un sábado por la tarde en las oficinas de Cloudflare en Lisboa para comprobar cuánto de bueno es un modelo programando en BASIC? Sí, eso es lo que quería comprobar. Veréis, hace unos días publiqué el artículo de "Cuánto dinero cuesta hacerte el juego de Light-Cycles de TRON en Workers de Cloudflare usando IA" donde usaba como modelo LLM a Cloud Opus 4.5 para construir el juego de las motos de TRON en TypeScript y poderlo correr en Workers de Cloudflare, y el coste que tuvo hacer ese proyecto fue de 0.5 USD. Regalado.

Figura 1: Vibe Coding en BASIC para AMSTRAD

CPC sale (un poco) más caro

Pero, la pregunta que me rondaba era... ¿sería igual de barato hacerlo en lenguajes menos populares que Python o TypeScript? Ya me he pegado varias veces con el Vibe Coding, y supongo que muchos de vosotros habéis pasado por esa fase donde el código no funciona como quieres, da errores, o directamente una modificación te cuesta la vida. Así que en lenguajes menos "mainsteam" la cosa será peor. Esa era la pregunta con la que me puse a echar un rato ayer sábado. 

Figura 2: El Light Cycles creado en TypeScript con Vibe Coding

Basta con preguntar en cualquier sitio y se ve que Claude programa mejor en Python, JavaScript, TypeScript, y frameworks para tecnologías web, que en el resto de los lenguajes, lo que hace que le cueste un poco más, ¿pero cuánto de más?

Figura 3: Con qué lenguajes programan mejor los modelos de Claude

Para hacer la prueba, quise hacer el mismo juego de Light-Cycles - no está mal como Benchmark - pero en BASIC, así que le pedí un Pormpt, que optimizado por Gemini, es éste que tenéis aquí. Así que, una vez Prompted, se supone que el resto es probar y ver resultados. Primero hice las pruebas con el propio Gemini, así, ligeras, a ver si el código funcionaba bien a la primera, y la verdad es que no hubo suerte.

Figura 4: Prompt par hacer el Light Cycles en AMSTRAD

Además de TypeScript, había hecho una versión pequeña del mismo juego de Tron Light-Cycles con Bash usando Gemini para mi MacOS y me lo había hecho bastante bien y de forma rápida, pero con BASIC le estaba costando.

View this post on Instagram

A post shared by Chema Alonso (@chemaalonso)

Además, cada prueba que quería hacer la tendía que hacer en el emulador, así que el proceso incluía la creación de un disco virtual, usando Amstrad DSK Filesystem Manager.

Figura 6: Amstrad DSK Filesystem Manager

La verdad es que la herramienta funciona de maravilla, pero hay que asegurarse de que el código que subas tenga el formato CRLF para que no se trunque, y que el formato del DSK que crees sea compatible con AMSTRAD, así que hay que hacerlos de, por ejemplo, 40 pistas, 9 sectores, y 512 bytes por sector.  Una vez hecho esto, ya puedes subir el programa al disco, y descargarte una copia del fichero .DSK que luego vamos a poder meter en el emulador. El proceso no es complicado.

Figura 7: Los disquettes de AMSTRAD

Eso sí, por cada cambio que hagas tienes que repetirlo, así que si el Vibe Coding no funciona bien a la primera, pues hay que hacerlo muchas veces. 

Figura 8: Probando, probando, probando en CPCBox

Esto nos lo sabemos ya de cuando con el equipo de Ideas Locas hicimos el BASIC 1.0 Copilot para AMSTRAD CPC 6128 que os conté hace un par de años en la RootedCON.

Figura 9: BASIC 1.0 Copilot para AMSTRAD CPC 6128

En mi caso, una vez construido el DSK, el emulador que utilicé fue el de CPCBox que está online, y puedes cargarle el DSK fácilmente. Además, esta versión la tienes con muchos juegos. Aquí os dejo un vídeo de cómo funciona con los juegos clásicos con los que estuve enredando un rato.

Figura 10: Emulador Online de AMSTRAD CPC 464/664/6128

También con juegos clásicos como el Bombjack o el Ikari Warriors

Pero volviendo a la prueba. Haces el código con OpenCode/Gemini/ChatGPT, generas el DSK usando Amstrad DSK Filesystem Manager y luego cargas el disco en CPCBOX. Una vez allí, CAT para ver el contenido del disco, LOAD para cargar el programa, y RUN para ejecutarlo. Y a jugar. El resultado completo lo tenéis aquí.

Figura 11: El resultado final. El Light-Cycles en BASIC

para el AMSTRAD CPC 464/664/6128

En este caso, después de que Gemini me fallara varias veces, decidí ir a por OpenCode y así podría comparar bien los precios que me costaba hacerlo funcionar. Y el proceso tomó su tiempo. Si os digo que me tiré un par de horas para hacerlo funcionara, os podéis hacer una idea.

Figura 12: Los costes después de 2 horas

Al final dejé algo bastante digno, como podéis ver en el código, pero si miramos los costes que me llevó hacerlo con OpenCode a través del AI Gateway de Cloudflare, podéis ver que en comparación con TypeScript, el coste fue mucho más alto. 

Si he de ser justo, he de decir que también se lo puse difícil, porque Locomotive BASIC y para emuladores, no debe ser lo que más líneas de código tira y lo que más tokens consume. De hecho, creo que debería ser yo de los pocos que estuvieran con eso un sábado por la tarde.

Figura 13: OpenCode con Claude Opus 4.6 "sufriendo"

Eso sí, poder crear juegos para AMSTRAD CPC a golpe de Vibe Coding es mejor que tener que copiar los códigos de la MicroMania como hacíamos en la niñez, que os aseguro que eso sí que tomaba tiempo, hasta que lo tenías fino completo.

Figura 14:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que se han  escrito, citado o publicado en este blog 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)