Augmented Coding vs Vibe Coding

Hay una pregunta que me hago cada vez con más frecuencia. No cuando estoy escribiendo código, sino cuando estoy revisándolo: ¿qué parte de esto fue generada por una máquina, y qué parte fue decidida por una persona?

La pregunta no es trivial. Trabajo liderando equipos de desarrollo en Kranio, donde construimos integraciones para una gran diversidad de sectores: financiero, logístico, retail, manufactura y más. Son contextos donde un error de seguridad no es solo un bug; es un incidente con consecuencias regulatorias, financieras o incluso legales. En ese tipo de contextos, la distinción entre código que funciona y código que es seguro no es un matiz académico. Es la línea entre un deploy exitoso y una brecha.

Uso herramientas de IA a diario. Son muy útiles y sería deshonesto negarlo. Ahora bien, hay una tensión que rara vez se aborda con la profundidad que merece: la relación entre la experiencia del desarrollador que usa estas herramientas y la seguridad de lo que producen juntos. Este artículo explora esa tensión. No para demonizar la IA ni para celebrarla sin crítica, sino para invitar a una conversación que creo que necesitamos tener como industria.

El código que funciona y el código que es seguro no siempre son el mismo

Hace unos meses hice un ejercicio deliberado. Tomé un escenario de integración que conozco bien: conectar un servicio de pagos con un sistema de mensajería empresarial, procesar el mensaje y devolver la confirmación. Le pedí a tres asistentes distintos que generaran la solución. Los tres entregaron código funcional, con estructura razonable.

Y los tres cometieron los mismos errores. Parámetros de conexión hardcodeados que deberían venir de variables de entorno, nomenclatura desconectada del dominio de negocio, y una comprensión superficial de la arquitectura hexagonal que usamos en producción.

Ningún test falló. Todo estaba verde. Y alguien sin contexto de la arquitectura real lo habría aprobado sin dudar.

Ese es el problema de fondo: los asistentes no generan código malo. Generan código que funciona, y eso basta para que pase filtros que deberían ser más rigurosos.

45%

del código generado por más de 100 modelos de lenguaje contenía vulnerabilidades del OWASP Top 10. En Java, la tasa de fallo llegó al 72%. Las defensas contra XSS fallaron en el 86% de los casos. (Veracode GenAI Code Security Report)

Las LLMs para desarrollo son una especie en rápida evolución, así que estas cifras podrían bajar drásticamente en pocas semanas. Pero eso es parte también de lo que nos desafía: entender con profundidad qué está siendo implementado, poder dirigirlo correctamente, y criticarlo de forma aguda.

La diferencia entre un desarrollador con experiencia y uno que recién comienza, usando la misma herramienta, no está en la velocidad con la que aceptan sugerencias. Está en las preguntas que se hacen antes de aceptarlas.

Vibe Coding vs. Augmented Coding: más que una cuestión de semántica

Hay dos formas de trabajar con estas herramientas. Kent Beck las nombra bien: vibe coding y augmented coding. La distinción no es filosófica; tiene consecuencias directas en la calidad y seguridad de lo que se construye.

El vibe coding describe una forma de programar donde el desarrollador delega casi completamente la generación de código a un modelo de lenguaje. Se expresa la intención en lenguaje natural, se acepta la sugerencia, se ejecuta, se observa el error, y se repite. El foco está en el resultado visible. ¿Funciona? Listo.

El augmented coding parte de una premisa diferente: la IA amplifica la capacidad del ingeniero, pero no reemplaza su criterio. El desarrollador sigue siendo responsable de cada decisión arquitectónica, de cada tradeoff, de cada línea que llega a producción.

Más rápido no siempre significa mejor: la paradoja del 70%

Aquí la conversación se pone incómoda, especialmente para quienes hemos adoptado estas herramientas con entusiasmo.

Addy Osmani, del equipo de Chrome en Google, tiene un nombre para este fenómeno: el problema del 70%. Los asistentes entregan rápido el scaffolding, los patrones obvios, el boilerplate. El 70% inicial. Pero el 30% restante sigue requiriendo el mismo esfuerzo de siempre. Ahí viven la seguridad, las decisiones arquitectónicas, los edge cases de producción. Y ahora además hay que verificar lo que la máquina generó.

Para un desarrollador con poca experiencia, ese 70% se siente mágico. Para uno de larga trayectoria, el 30% restante es a menudo más lento que haberlo escrito desde cero.

Y es en ese 30% donde se define si el código es solamente funcional o si es verdaderamente seguro.

Beck va más lejos: su argumento central es que TDD es la red de seguridad esencial cuando se trabaja con agentes de IA, porque estos introducen regresiones que solo tests rigurosos detectan a tiempo. Si un equipo genera código con IA pero no escribe tests primero, está construyendo sobre arena.

El riesgo silencioso: lo que las herramientas pueden erosionar

Hay un aspecto de esta conversación que me preocupa más que las vulnerabilidades inmediatas, y tiene que ver con algo que valoramos mucho como desarrolladores: nuestra capacidad de entender lo que construimos.

Anthropic publicó en enero de 2026 un estudio controlado con 52 ingenieros aprendiendo una nueva librería de Python. Quienes usaron asistencia de IA obtuvieron un 17% menos en tests de comprensión, con las habilidades de debugging como las más afectadas. Pero lo más revelador no fue el número. Fue el patrón que encontraron:

17%

menos comprensión en desarrolladores que usaron IA de forma pasiva. Sin embargo, los que generaban código y lo estudiaban a fondo, alternaban entre código y explicaciones conceptuales, o hacían preguntas de diseño superaron el 65% en comprensión. El cómo importa más que el si. (Anthropic, enero 2026)

Identificaron seis formas de interactuar con la IA. Tres llevan a puntuaciones por debajo del 40%: delegación completa, dependencia progresiva, y usar la IA como muleta para debugging. Las otras tres superan el 65%: generar y estudiar a fondo, alternar código con explicaciones, y hacer preguntas conceptuales.

Esto no es un argumento contra la IA. Es un argumento a favor de usarla con intención.

Y hay una dimensión más amplia que merece atención. Las ofertas de trabajo entry-level en desarrollo bajaron un 60% entre 2022 y 2024. Si dejamos de formar juniors porque la IA hace su trabajo, ¿quién tendrá la experiencia necesaria para supervisar estas herramientas en cinco o diez años? No es una pregunta retórica. Es un desafío real para la sostenibilidad de nuestros equipos.

Lo que estamos aprendiendo a hacer: principios desde la práctica

No pretendo dar recetas. Cada contexto tiene sus particularidades. Pero hay principios que en nuestra experiencia funcionan y que la evidencia respalda.

Prevenir antes de generar

Herramientas como Claude Code permiten archivos de instrucciones donde se puede dejar por escrito: no hardcodees secrets, no implementes reintentos si eso lo maneja la infraestructura, las URLs vienen de configuración externa. Esa es la primera línea de defensa. La segunda son pre-commit hooks que escanean secrets antes de que lleguen al repositorio, y análisis estático en el pipeline de CI que detecta vulnerabilidades antes del merge. En equipos que usan IA de forma intensiva, esto deja de ser buena práctica y se convierte en necesidad.

Revisar con más rigor, no menos

ThoughtWorks colocó la complacencia con código generado por IA en su categoría de Hold, la advertencia más fuerte del Tech Radar, durante tres ediciones consecutivas. La razón es intuitiva: cuando sabemos que el código lo generó una máquina, le damos menos escrutinio sin darnos cuenta. El hábito contrario requiere esfuerzo deliberado.

Invertir en comprensión, no solo en producción

Este es, para mí, el principio más importante. Los patrones exitosos del estudio de Anthropic tienen algo en común: el desarrollador no delega su entendimiento. Genera, estudia, pregunta, y recién entonces integra.

He empezado a aplicar esto en mi propio flujo: cuando una herramienta de IA me genera una solución de integración, antes de aceptarla me obligo a explicar por qué funciona. Si no puedo, la descarto. Esa actitud de curiosidad activa, de no aceptar lo que no se comprende, es lo que separa el uso productivo de la IA del uso que erosiona habilidades.

La experiencia como pilar de seguridad

Martin Fowler comparó el impacto de los LLMs con la transición de assembler a lenguajes de alto nivel. La analogía es útil, aunque incompleta. Cuando pasamos de assembler a C, sabíamos lo que estábamos abstrayendo. Con la IA generativa, muchos equipos están abstrayendo cosas que nunca entendieron en primer lugar.

La próxima vez que veas código generado por IA que pasa todos los tests y se ve limpio, vale la pena hacerse las preguntas que la máquina no puede hacerse:

• ¿De dónde vienen esas credenciales?
• ¿Quién maneja los reintentos?
• ¿Esta lógica pertenece aquí o en la infraestructura?
• ¿Entendemos lo que estamos aprobando?

Esas preguntas no las genera ningún modelo. Las genera la experiencia. Y esa experiencia es lo que hace que un equipo sea seguro, con o sin inteligencia artificial.

Conclusión

La IA escribe código.
Nosotros decidimos si es seguro.
Esa responsabilidad no se delega.

Para profundizar

• Veracode GenAI Code Security Report — Evaluación de seguridad de 100+ modelos generando código
• OpenSSF: Security-Focused Guide for AI Code Assistants — Templates de instrucciones listos para usar
• Anthropic: How AI Assistance Impacts Coding Skills — El estudio sobre los 6 patrones de interacción
• ThoughtWorks Tech Radar: Complacency with AI-Generated Code — Por qué está en 'Hold' desde 2024
• OWASP Top 10 for LLM Applications 2025 — Los 10 riesgos principales al usar LLMs
• Kent Beck: Augmented Coding — Augmented Coding: Beyond the Vibes