Desde que las LLMs llegaron al público general a mediados de 2021, era cuestion de tiempo hasta que se integraran cada vez más en nuestra rutina. Lo que no esperábamos era que esta adopción fuera tan rápida, impactando prácticamente todos los sectores. Desde entonces vimos Codex, Copilot, Claude y, día tras día, nos dirigimos al escenario que observamos hoy: agentes capaces de ejecutar aplicaciones enteras usando lenguaje natural.
La popularización del vibe coding
Aplicaciones que usan “vibe coding” — término popularizado por Andrej Karpathy, cofundador de OpenAI, a principios de 2025 — se volvieron comunes en la rutina de muchos desarrolladores. Para muchos, se presentó como un gran facilitador. La idea era simple: cualquiera podría generar código; bastaba conversar, tener voluntad, y tendrías una aplicación de millones en tus manos. A primera vista, esto puede parecer verdad. Al fin y al cabo, en programación es frecuente que algo funcione aunque no esté hecho de la manera ideal.
Si una consulta tarda 1200ms o 25ms, ambas funcionan, ¿no?
¿Hasta cuándo funciona realmente “hacer que funcione”?
Aquí reside el riesgo. Cuando se vende la idea de que “funcionar” es suficiente, la discusión sobre arquitectura, rendimiento, seguridad, mantenimiento y buenas prácticas comienza a parecer secundaria. Y no lo es. En los últimos meses hemos tenido varios casos de influencers que proclamaban que “se acabó para los devs”, siendo hackeados poco después. Y no es solo ese caso.
La alerta de seguridad
El equipo Escape Research encontró, entre 5.600 apps públicamente disponibles, más de 2.000 vulnerabilidades, más de 400 secretos expuestos y muchos otros datos sensibles filtrados. Este tipo de hallazgo es un recordatorio de un punto simple: acelerar entregas sin criterio técnico tiene un costo.
Qué nos exige este escenario
No podemos saberlo todo, ni siempre tener tiempo para entregar de la manera ideal. Pero debe quedar claro que, ahora más que nunca, necesitamos conocimientos sólidos sobre fundamentos de arquitectura, buenas prácticas, diseño de sistemas, Big O, etc. Para lograr buenos resultados necesitamos guiar bien a los agentes. Pero no solo eso: también debemos revisar, cuestionar, validar y sostener técnicamente lo generado.
¿Facilitador o comprometedor?
En este escenario nos corresponde a los desarrolladores entender cómo aprovechar los avances de las LLMs sin renunciar a la mantenibilidad, la seguridad y las ventanas de entrega. Al final, el vibe coding puede ser un facilitador. Pero sin base técnica, compromete.
Spec Driven Development ayuda a responder esta duda — pero ese es tema para otro post.
Referencias
- Cloudflare | What is vibe coding?
- Andrej Karpathy | Vibe coding
- Escape | The State of Security of Vibe Coded Apps
Los agentes evolucionaron — ¿y cuándo serás tú?
El inicio del desarrollo con IA fue bastante caótico: el chat estaba separado del código, la “ingeniería de prompts” no se tomaba en serio y el contexto que se daba al robot era: “arréglalo”. Luego Copilot se integró a nuestro flujo y las cosas se simplificaron, especialmente por el autocompletado. La integración no era totalmente fluida, pero ayudó a tener una LLM más cercana al código.
Cursor lanzó después y ofreció una integración mucho más robusta: arrastrar archivos, referencias más fáciles, elegir modelos, y un editor que comprendía archivos adyacentes. Hoy, con Cursor 3.0, el código tiene un papel secundario: el objetivo es conversar, explicar, corregir y mejorar, y todo sucede detrás de escena.
La evolución del flujo
A diferencia de hace algunos años, nuestro problema ya no es puramente capacidad tecnológica: los agentes no son tontos ni incapaces — al contrario. El punto es que necesitamos modernizarnos también. Madurar procesos, mejorar metodologías. ¿Cuál es el siguiente paso?
Spec Driven Development
Los agentes trabajan mejor cuando reciben directivas claras y sin ambigüedad: casos de éxito, casos límite, resultados inválidos y especificaciones bien definidas.
El desarrollo basado en especificaciones, como su nombre indica, estructura el proceso para que, antes de implementar, exista una especificación clara del problema, qué hacer para resolverlo y cómo implementaremos las soluciones. No es un enfoque formalmente definido, por lo que los nombres pueden variar, pero la idea es la misma. La finalidad es eliminar dudas que suelen surgir durante el desarrollo porque el briefing no fue claro. Mejor aún: generar documentación de esa implementación para discusión interna o como historial.
El ciclo de la spec
En líneas generales, el ciclo de la spec se define como:
Especificación: definir el problema, el contexto base y qué corregir.
Planificación: definir cómo resolverlo — tecnologías, arquitectura, librerías y contratos, modelos/entidades, etc.
Análisis: revisar el plan para detectar brechas, ambigüedades o defectos.
Dividir en tareas: separar la solución en pequeñas tareas implementables.
Implementación: ejecutar el proceso: en esta etapa todos los requisitos, escenarios, tareas y tecnologías están documentados para el agente.
Con este proceso podemos obtener resultados más rápidos, documentados, testeables y predecibles. En futuros posts veremos distintos frameworks y cómo se diferencian.
