DOMINICODE

Category: Vibe coding

  • Cómo garantizar la confiabilidad del código generado por IA

    Cómo garantizar la confiabilidad del código generado por IA

    Vibe Coding: la trampa del 84%

    Tiempo estimado de lectura: 3 min

    Ideas clave

    • El 84% de desarrolladores usa IA a diario, pero solo el 29% confía en el código generado — la brecha es riesgo operativo.
    • Los LLMs generan código verosímil pero frágil: happy-paths, alucinaciones de API y antipatrones a escala.
    • Auditoría práctica: validar dependencias, exigir sad-paths desde el prompt, tests humanos para edge cases, auditar queries y requerir métricas.
    • Aplicar Zero Trust: checklist de confianza y CI que impida merges sin cobertura e instrumentación.

    Introducción

    Vibe Coding: la trampa del 84% no es un titular sensacionalista: es una advertencia práctica. El 84% de los desarrolladores usa IA diariamente, pero solo el 29% confía en el código que obtiene. Esa brecha no es una estadística; es un agujero por donde entra la deuda técnica, la fuga de datos y las regresiones en caliente. (Fuente: Stack Overflow Developer Survey 2024)

    Este artículo te da un marco operativo: cómo revisar, auditar y —sobre todo— confiar en código generado por modelos de lenguaje sin que la velocidad mate la fiabilidad.

    Resumen rápido (lectores con prisa)

    Los LLMs generan código verosímil pero no garantizan manejo de errores ni adaptación al dominio. Valida dependencias, exige sad-paths desde el prompt, escribe tests humanos para edge cases y exige métricas y trazas antes de mergear.

    Vibe Coding: la trampa del 84% — por qué sucede y qué rompe

    El problema no es que la IA escriba mala sintaxis. Es que escribe código verosímil. Y lo verosímil engaña al ojo. Un LLM predice tokens; no entiende tu dominio, tus SLAs ni tu topología de datos. Eso genera tres fallos constantes:

    • Happy-path en serie: el código funciona cuando todo va bien. No maneja latencias, timeouts o datos corruptos.
    • Alucinaciones de API: métodos que “suenan” correctos pero no existen en tu versión de la librería.
    • Antipatrones a escala: consultas N+1, bloqueos por locks mal usados, o rutas críticas sin instrumentación.

    Aceptar ese output sin auditoría es como aceptar un merge request sin tests: rápido, pero peligroso.

    Auditoría práctica: pasos que aplicas hoy mismo

    Cambia tu rol: con IA, no recibes código; recibes la propuesta de un “junior hiperproductivo”. Revíalo como tal.

    1) Valida dependencias antes de instalar

    • No copies imports sin comprobar. Busca la API en la documentación oficial.
    • Consulta npm para fecha de publicación y descargas.
    • Ejecuta npm audit tras añadir paquetes y antes de mergear. Herramienta: docs.npmjs.com/cli/v9/commands/npm-audit

    2) Obliga el Sad Path desde el prompt

    • No pidas solo “la función”. Pide manejo de fallos, retries y logging contextual.
    • Prompt débil: “Genera una función que llame a la API de pagos”
    • Prompt fuerte: 
      "Genera una función que llame a la API de pagos. Incluye:
 - timeout y retry con backoff exponencial,
 - logging con requestId y contexto,
 - pruebas de unidad para timeouts y respuestas 5xx,
 - no devolver datos sensibles en la respuesta."

    3) Tests: el humano decide los edge cases

    • No dejes que la IA escriba tanto la función como los tests críticos.
    • Define tú los casos límite y las aserciones. La IA puede generar mocks y el setup repetitivo.
    • Cubre: inputs inválidos, latencias extremas, concurrencia (race conditions) y fallos de autenticación.

    4) Base de datos: audita las queries antes de producción

    • Habilita logging de queries en dev y revisa el número de hits por operación.
    • Verifica índices para columnas filtradas.
    • Comprueba serialización de objetos para no exponer campos sensibles.

    5) Métricas y observabilidad como contrato

    • Exige que cualquier cambio generado incluya: métricas (latencia, error rate), trazas correlacionadas y logs estructurados.
    • Si el PR no contiene instrumentación mínima, reviértelo.

    Checklist de confianza (Zero Trust aplicado)

    • [ ] Prompts que exigen Sad Path y límites de recursos.
    • [ ] Dependencias verificadas y npm audit limpio.
    • [ ] Tests escritos por humanos para edge cases críticos.
    • [ ] Logging y tracing incluidos en el cambio.
    • [ ] Revisión de queries e índices en DB.
    • [ ] Branch aislado y CI que rechaza merge sin cobertura mínima.

    Cuándo delegar y cuándo no

    Usa IA para acelerar tareas repetitivas y de bajo riesgo:

    • Boilerplate, DTOs, validaciones simples, plantillas de tests, conversiones de sintaxis.

    No delegues a la IA decisiones de criterio:

    • Modelado de dominio, reglas de autorización, diseño de esquemas, SLAs o decisiones que impacten seguridad y privacidad.

    Cierre directo

    La diferencia entre el 84% que usa IA y el 29% que confía en ella no es tecnología: es proceso y criterio. Si tu equipo aprende a auditar como si cada PR viniera de un “junior sin contexto”, reducirás fallos graves sin renunciar a la velocidad.

    La IA debe ahorrar tipeo; no debe asumir la responsabilidad arquitectónica. Haz que ese sea tu contrato interno hoy.

    Una continuación práctica y recursos relacionados están disponibles en Dominicode Labs, donde se publican frameworks y workflows para auditoría y observabilidad integrables en equipos que usan IA.

    FAQ

    ¿Por qué no confiar de entrada en código generado por IA?

    Porque los LLMs generan código verosímil sin comprender tu dominio, SLAs o topología de datos. Ese código puede funcionar en happy-paths pero fallar en latencia, datos corruptos o versiones de librerías.

    ¿Qué preguntas agregar al prompt para obtener código más fiable?

    Exige manejo de fallos, retries con backoff, timeouts, logging contextual (requestId), pruebas unitarias para errores 5xx y restricciones sobre datos sensibles.

    ¿Cómo validar dependencias antes de instalarlas?

    Comprueba la API en la documentación oficial, revisa fecha de publicación y descargas en npm y ejecuta npm audit tras añadir paquetes y antes de mergear.

    ¿Qué tests deben escribir los humanos?

    Los humanos deben definir y escribir tests para edge cases críticos: inputs inválidos, latencias extremas, condiciones de carrera y fallos de autenticación. La IA puede generar mocks y setups repetitivos.

    ¿Qué instrumentación mínima exigir en un PR?

    Métricas de latencia y tasa de error, trazas correlacionadas y logs estructurados. Si el PR no contiene instrumentación mínima, debería revertirse.

    ¿Cuándo es apropiado delegar tareas a la IA?

    Para tareas repetitivas y de bajo riesgo: boilerplate, DTOs, validaciones simples, plantillas de tests y conversiones de sintaxis. No para modelado de dominio, reglas de autorización, diseño de esquemas o decisiones que afecten seguridad y privacidad.

  • Aprende a escribir especificaciones efectivas para LLMs

    Aprende a escribir especificaciones efectivas para LLMs

    Por qué dejé de escribir código desde cero y empecé a hacer specs primero

    Tiempo estimado de lectura: 3 min

    • Menos correcciones manuales: las specs reducen el tiempo invertido en ajustar código generado por LLMs.
    • Contratos ejecutables: una spec bien definida evita ambigüedades y deuda técnica.
    • Escalabilidad y previsibilidad: la spec es la fuente de verdad para cambios y nuevos colaboradores.

    ¿Sabes qué consume más tiempo que escribir código? Corregir el código que generó la IA porque nadie le dejó claro qué hacer.

    Hace un par de años disfrutaba abrir un editor en blanco. Era adrenalina pura: estructura, imports, resolver problemas “sobre la marcha”. Parecía productividad. Era ilusión.

    La transición a escribir specs primero cambió eso por completo. No porque sea más elegante, sino porque es más efectivo. Aquí te cuento por qué dejé de escribir código desde cero y empecé a hacer specs primero, qué contiene una spec útil y cómo eso transforma la relación entre humanos, agentes y código.

    Resumen rápido (lectores con prisa)

    Spec‑Driven Development: definir specs precisas antes de implementar reduce ambigüedades, minimiza correcciones manuales y convierte la spec en la fuente de verdad. Útil cuando el producto se mantiene, la lógica es compleja o hay múltiples integradores. Implementación: especifica stack, datos, contratos de API, reglas de negocio y casos de aceptación.

    Por qué dejé de escribir código desde cero y empecé a hacer specs primero

    El catalizador fue simple: gastaba horas ajustando código generado por LLMs. No es culpa de la IA. Es culpa de la ambigüedad. Un modelo no conoce tus convenciones, tus límites ni las decisiones que tomaste el martes. Para un LLM, lo que no está escrito no existe.

    Cuando trabajas sin spec, cada prompt es un microcontrato mal redactado. Resultado: fragmentos que funcionan aisladamente y rompen la coherencia global. El coste no es solo tiempo; es deuda técnica que aparece en sprint 3 y se siente en el cuello del repo.

    Escribir specs primero no es volver a la documentación de los 90. Es escribir contratos ejecutables: lo suficiente para que un agente implemente sin inventar nada. Eso cambió mi productividad: menos correcciones, menos parches, más iteraciones reales.

    ¿Qué lleva una spec que funcione con IA?

    No basta con una descripción bonita. Una spec útil es precisa, limitada y accionable. Esto es lo que siempre incluyo:

    • Stack exacto con versiones. No “React moderno”. React 18.3, Next.js 14, etc.
    • Modelo de datos. Tablas, campos, tipos y restricciones. Si usas UUID, dilo.
    • Contratos de API. Endpoints, payloads de ejemplo, códigos de error y formatos.
    • Reglas de negocio explícitas. Qué hacer y, más importante, qué no hacer.
    • Casos de aceptación. Escenarios claros que definen el comportamiento visible.
    • Límites del MVP. Qué se queda fuera en esta iteración y por qué.

    El documento vive en el repo (spec.md), versionado. Si algo cambia, la spec cambia primero. No al revés.

    Si quieres una guía práctica para redactar specs que funcionen con LLMs, uso y recomiendo el libro Spec‑Driven Development.

    Cómo cambiaron mis sesiones con agentes

    Antes: abría un chat, pedía componentes, pegaba código. Después de dos horas, el sistema era Frankenstein.

    Ahora: escribo la spec, lanzo al agente en terminal con la instrucción clara—lee spec.md e implementa la Fase X—y reviso diffs. El agente crea archivos, instala dependencias y propone un conjunto coherente desde la raíz. Mi rol pasa de “peón que teclea” a “arquitecto que aprueba”.

    Regla de oro

    Nunca corrijo el código directamente para resolver una ambigüedad. Actualizo la spec y mando al agente a refactorizar. Si corriges el código sin tocar la spec, el día siguiente volverás a ver el mismo fallo cuando el agente regenera algo incompatible.

    Beneficios reales (sin poesía)

    • Menos tiempo en ajustes menudos. Más tiempo en decisiones estratégicas.
    • Menos deuda técnica porque las reglas de diseño se establecen antes.
    • Cambios más predecibles: si una feature cambia, la spec es la fuente de verdad.
    • Escalabilidad del equipo: nuevos desarrolladores o agentes arrancan en horas, no en días.

    Cuando esto no aplica

    No todos los proyectos necesitan SDD. Si estás escribiendo un script de 50 líneas o prototipando algo desechable para validar una idea, un prompt rápido tiene sentido. SDD brilla cuando el producto crece, hay datos críticos o múltiples integradores.

    Regla práctica: si la base de código será mantenida más de un mes o la lógica de negocio es compleja, escribe la spec.

    El cambio de rol del developer

    Adoptar specs no elimina el trabajo humano; lo eleva. Ahora se pide que tomes decisiones tempranas y explícitas: límites, trade-offs, casos borde. La ejecución se delega, la responsabilidad de diseño sigue siendo humana.

    Ese es el valor real: profesionales que saben diseñar sistemas se vuelven más valiosos porque delegan la repetición y retienen la toma de decisiones estratégicas.

    El libro Spec‑Driven Development recoge las plantillas, patrones y ejemplos que uso todos los días para que un LLM implemente sin inventos. Si estás cansado de arreglar lo que la IA rompe, empieza por escribir la spec. Es incómodo al principio, pero harás más en menos tiempo y sin excusas.

    La próxima iteración de tu proyecto debería empezar con un archivo spec.md, no con un editor en blanco. Hazlo y verás que tu trabajo deja de parecer frenético: se vuelve deliberado.

    Para equipos que adoptan automatización y agentes como parte del flujo de desarrollo, una práctica centralizada de especificaciones acelera la coordinación entre humanos y máquinas. Si estás explorando flujos donde agentes y workflows son críticos, mira iniciativas y recursos prácticos en Dominicode Labs para ejemplos aplicables y plantillas.

    FAQ

    Respuesta: Spec‑Driven Development es la práctica de definir especificaciones precisas y accionables antes de implementar. Las specs actúan como contratos ejecutables para equipos humanos y agentes.

    Respuesta: Escribe una spec cuando la base de código será mantenida más de un mes, la lógica de negocio es compleja o hay múltiples integradores. Para scripts pequeños o prototipos muy tempranos, un prompt rápido puede bastar.

    Respuesta: Una spec mínima incluye: stack y versiones, modelo de datos, contratos de API con ejemplos, reglas de negocio claras y casos de aceptación. También define los límites del MVP.

    Respuesta: Mantén la spec en el repo, lanza al agente con instrucciones que apunten al archivo (por ejemplo, “lee spec.md e implementa la Fase X”) y revisa diffs en lugar de editar código directamente.

    Respuesta: Si alguien modifica código sin actualizar la spec, la siguiente regeneración por parte del agente puede reintroducir el fallo. La regla de oro es: actualiza la spec y vuelve a ejecutar al agente.

    Respuesta: Guarda las specs en el repositorio como archivos versionados (ej.: spec.md). Cualquier cambio debe pasar por control de versiones para que la spec sea la fuente de verdad.

  • Identificando problemas de vibe coding en equipos empresariales

    Identificando problemas de vibe coding en equipos empresariales

    Problemas de vibe coding para equipos empresariales (2026)

    Tiempo estimado de lectura: 4 min

    • Vibe coding —iterar con un LLM hasta que el código “parece funcionar”— acelera entrega pero genera deuda técnica opaca.
    • Cinco problemas concretos: código huérfano, erosión arquitectónica, riesgos de seguridad en la cadena de suministro, degradación del criterio técnico y sobrecarga en code review.
    • La solución no es prohibir la IA: es imponer controles técnicos y procesos (Design-First, ADRs, testing liderado por humanos, CI/CD restrictivo, verificación de dependencias y rotación de ownership).
    • Permitir vibe coding solo en prototipos desechables, scripts aislados o mocks; evitarlo en autenticación, transacciones y caminos con implicaciones regulatorias.
    ¿Tu repositorio funciona hoy y nadie lo entiende mañana? Los problemas de vibe coding para equipos empresariales (2026) son eso: soluciones rápidas que se convierten en deuda técnica silenciosa. Para Tech Leads, Arquitectos y CTOs, esto ya no es una discusión teórica. Es mantenimiento que se vuelve imposible, incidentes que aparecen a horas raras y una superficie de ataque que crece sin control.

    Resumen rápido (lectores con prisa)

    Vibe coding: iterar con LLMs hasta que el bloque “parece funcionar”. Útil para prototipos; peligroso en código de producción. Obliga a controles: diseño previo, ADRs, testing liderado por humanos, CI/CD restrictivo y validación de dependencias. Evitar en caminos críticos.

    Problemas de vibe coding para equipos empresariales (2026): diagnóstico rápido

    1) Código huérfano: funciona, pero nadie lo mantiene

    La IA entrega un módulo que pasa tests básicos. Nadie lo escribió línea por línea. Nadie puede explicar el flujo en un incidente P1. Eso aumenta el tiempo de resolución dramáticamente: lo que se ahorró en desarrollo se pierde multiplicado en debugging.

    Ejemplo realista: un endpoint de autenticación generado que falla ante tokens caducados en escenarios de reintentos — el path feliz funciona, el resto no. Resultado: latencia, errores y horas de on-call.

    2) Erosión arquitectónica: soluciones locales que rompen el todo

    Los modelos no tienen una visión sistémica del repo. Producen utilidades reinventadas, acoplan capas y rompen contratos explícitos. Cuando varios devs usan prompts distintos, el cóctel es un monolito fragmentado con estilos y anti-patterns mezclados.

    3) Seguridad y cadena de suministro: vulnerabilidades sutiles

    No es solo SQL injection. Son flujos de autorización incompletos, validaciones omitidas en edge cases y dependencias “sugeridas” que están obsoletas o son inexistentes. La comunidad de seguridad ya documentó riesgos de typosquatting y abuso de paquetes; automatizar la adopción de dependencias sin verificación amplifica ese vector (ver OWASP).

    4) Degradación del criterio técnico

    Delegar la implementación en prompts empobrece el aprendizaje. Juniors que se vuelven “prompteadores” no construyen modelos mentales sobre complejidad, rendimiento o diseño de sistemas. A la larga, el activo más valioso —criterio técnico— se erosiona.

    5) Code review convertido en cuello de botella

    Revisar código generado exige más contexto y tiempo. Los patrones de error humano son predecibles; las soluciones de LLM son impecables sintácticamente pero opacas conceptualmente. Los leads pasan de decidir arquitectura a auditar toneladas de PRs.

    Cómo mitigar sin renunciar a la IA

    Prohibir la IA no es opción. Las empresas competitivas aplican control, no veto. Aquí un set de medidas prácticas y verificables.

    • Design-First: define contratos, diagramas y contratos de datos antes de cualquier generación. La IA implementa; no diseña.
    • ADRs obligatorios: cualquier módulo generado con complejidad no trivial debe acompañarse de un Architecture Decision Record. Plantilla y ejemplo: Plantilla y ejemplo
    • Testing humano-led (BDD): el desarrollador define casos, edge cases y aserciones. La IA genera el boilerplate de tests, no la lógica de cobertura.
    • CI/CD restrictivo: integra análisis estático y políticas que bloqueen PRs con saltos bruscos de complejidad ciclomática o inclusión de paquetes no verificados. Herramientas como Semgrep ayudan a automatizar reglas.
    • Verificación de dependencias fuera del flujo PR: antes de aceptar librerías sugeridas por un LLM, pásalas por un proceso de validación de licencias y reputación. Sigue guías de NIST sobre desarrollo seguro.
    • Pares y rotación de ownership: obliga a que otro ingeniero entienda y firme el ADR antes del merge. Pair-programming para integración crítica.
    • Entrenamiento deliberado: formación interna en diseño, debugging profundo y análisis de performance. No atajos educativos.

    Límites claros: cuándo permitir vibe coding y cuándo no

    Permite vibe coding en prototipos desechables, scripts aislados o generación de mocks. Evítalo en autenticación, transacciones, migraciones de estado y cualquier camino con implicaciones regulatorias o legales.

    Conclusión: la IA potencia, pero el criterio no se automatiza

    Los problemas de vibe coding para equipos empresariales (2026) no son culpa de las herramientas. Son consecuencia de adoptarlas sin procesos. La diferencia entre un equipo que escala con IA y uno que se ahoga en deuda técnica está en una palabra: criterio. No lo externalices. Defínelo, mídelo y exige documentación. La IA hará el trabajo pesado; los humanos deben seguir decidiendo qué trabajo merece hacerse.

    Apúntate al newsletter de Dominicode para la siguiente entrega: hablaremos de políticas concretas de CI/CD y reglas Semgrep para detectar “sospecha de generación automática” en PRs.

    Encuentra una continuación práctica y recursos experimentales en Dominicode Labs. Allí publicamos plantillas de ADR, reglas Semgrep y ejemplos de pipelines seguros que complementan este artículo.

    FAQ

    ¿Qué es exactamente “vibe coding”?

    Es el patrón de trabajo donde un desarrollador itera con un modelo de lenguaje (Copilot, Claude, Cursor u otros) hasta que el código “parece funcionar”, sin aplicar diseño previo ni verificación humana exhaustiva.

     

    ¿En qué escenarios es aceptable usar IA para generar código?

    Aceptable en prototipos desechables, scripts aislados y generación de mocks. No es recomendable en autenticación, transacciones, migraciones de estado o caminos con implicaciones regulatorias.

     

    ¿Cómo se evita que las dependencias sugeridas por LLM introduzcan riesgo?

    Implementando un proceso de validación de dependencias fuera del flujo PR que verifique licencias, reputación y coincidencia con políticas internas antes de su aceptación.

     

    ¿Qué debe incluir un ADR cuando el código fue generado por IA?

    Descripción de la decisión, alternativas consideradas, riesgos identificados, responsables y link al módulo generado. La plantilla recomendada se puede consultar en Plantilla y ejemplo.

     

    ¿Cómo cambia el proceso de code review con uso intensivo de LLMs?

    Requiere más contexto en las revisiones, énfasis en arquitectura y pruebas, y posibles políticas de pares y rotación de ownership para asegurar que otro ingeniero pueda explicar y mantener el código.

     

    ¿Qué herramientas ayudan a automatizar políticas que mitiguen vibe coding?

    Herramientas de análisis estático y reglas en CI/CD (por ejemplo, Semgrep), y procesos de verificación de dependencias siguiendo guías como las de NIST.