Vai al contenuto principale
Ejemplo abierto · departamento de Desarrollo de software

Un AI Workflow Design, al completo.

No una consultoría que rehacer cada vez, sino un playbook reutilizable. Este es el ejemplo del departamento de Desarrollo de software, abierto y sin costes: qué automatizar de verdad a lo largo del ciclo de vida, con qué herramientas, en qué fases y con qué controles cuando quien escribe el código es la IA pero la responsabilidad del merge sigue siendo suya. Es también el departamento en el que vivimos: esta web y nuestros productos están construidos así, cada día. La forma exacta de lo que injertamos en su negocio.

01 · Casi d'uso

Qué automatizar de verdad

El patrón aquí no es el volumen repetitivo como en soporte: es la etapa. El error de perspectiva más común es reducir la IA para desarrolladores al autocompletado en el editor — en realidad toca el ciclo entero, de la arquitectura al código, a la revisión, a las pruebas, a la CI/CD, hasta las operaciones. Pero la madurez cambia de forma drástica de una etapa a otra: algunos mercados son reales y están concurridos, otros tienen un único proveedor serio, otros ni siquiera son una categoría de producto. Se automatiza donde la evidencia independiente aguanta, y se deja a la persona el juicio sobre el merge.

  • Escritura asistida de código (autocompletado y chat en el editor) al posto di: La escritura a mano de código repetitivo y de boilerplate
  • Primera pasada de revisión automática sobre las pull requests al posto di: La espera de un primer comentario del revisor humano
  • Generación de las pruebas como andamiaje al posto di: La escritura a mano del esqueleto de las pruebas y el mantenimiento de los selectores
  • Diagnóstico automático de los fallos de pipeline al posto di: La lectura manual de los logs de build para encontrar la causa
  • Resumen de los incidentes y ayuda a la causa raíz al posto di: La reconstrucción manual de la cronología durante una anomalía

En 2025 un estudio controlado sobre dieciséis desarrolladores open-source expertos los midió un 19% más lentos con las herramientas de IA sobre código que les resultaba familiar, pese a haber previsto una aceleración y a estar convencidos al final de haber ido más rápido; la propia METR relativizó después ese titular a principios de 2026 (el grupo de control se había autoseleccionado probablemente excluyendo a quienes más se benefician). El informe DORA 2025 registra una adopción del 90% y producción individual al alza, pero métricas de entrega de equipo planas e inestabilidad en aumento: «la IA amplifica las prácticas existentes, no repara la disfunción». Son indicaciones de dirección, no promesas de resultado. El dato que importa para una pyme es otro: la percepción de velocidad no es la velocidad — hay que medirla sobre su trabajo, no cogerla del folleto.

02 · Strumenti

Dos modelos, no una lista de la compra

El mercado de 2026 de las herramientas de IA para el desarrollo se divide en dos modelos útiles para una pyme. La elección correcta no depende del tool más citado, sino de cuánta disciplina de pruebas y de revisión tiene ya en casa. Las plataformas que prometen la autonomía completa siguen siendo un techo de referencia, no un punto de partida.

El punto de partida para una pyme

Asistente en el editor + primera pasada de revisión

La pareja que cubre las etapas más maduras y con la evidencia más sólida: un asistente de escritura dentro del editor y un agente que da la primera pasada sobre la pull request, dejando la aprobación y el merge a una persona. Es el corte adecuado para el tramo pyme porque es exactamente lo que recomienda el estudio independiente más riguroso: los agentes de revisión aumentan la revisión humana, no la sustituyen. La ganancia concreta es quitar la espera del primer comentario, no quitar al revisor.

Útil solo si el punto de control ya existe

Agente autónomo que escribe y aprueba

Un agente que coge una tarea y la lleva hasta la pull request — hasta la autoaprobación, en los casos extremos. Existe un contraejemplo real y documentado (una empresa que autoaprueba más del 19% de sus propias pull requests, con código de IA que introduce menos regresiones que el escrito a mano), pero con un asterisco enorme: arquitectura de control a medida, exclusiones explícitas para las rutas de alto riesgo, auditoría completa. Una pyme que adopta una herramienta lista para usar no hereda esas protecciones: es un escalón de madurez posterior, no una elección del primer día.

Nuestra opción por defecto para una pyme es partir del nivel aumentado — la IA que hace más rápida a una persona que sigue siendo responsable del merge — porque es el único nivel sobre el que la evidencia independiente aguanta. La autonomía se gana después, cuando ya existen pruebas sólidas y rutas sensibles excluidas, y son verificables. La selección del proveedor concreto, la due diligence sobre sus términos de tratamiento del código y sobre dónde acaban sus fuentes forma parte del injerto.

03 · Fasi

Las fases del injerto

Cada entrada del playbook lleva una fase, así a mitad de camino filtra por "qué viene después" en lugar de releer los pilotos que ya ha cerrado. En desarrollo el orden lo dicta la madurez de las etapas, no el deseo: se parte de la etapa con la evidencia más sólida y el riesgo más bajo, y se amplía solo donde el punto de control de revisión ya ha demostrado que aguanta.

  1. 1

    Pilot

    Primeros 30 días

    Una sola etapa, no el ciclo entero — por lo general la escritura asistida o la primera pasada de revisión. Un owner nombrado, la política de uso escrita (qué puede salir del perímetro de la empresa y acabar en un modelo de terceros), el merge siempre en manos de una persona, y el criterio de éxito definido antes que la herramienta: un número medido sobre su trabajo, no la velocidad percibida. Es la lección directa del estudio de METR.

  2. 2

    Scale

    Primeros 90 días

    Lo que ha funcionado se extiende a las etapas adyacentes: la generación de las pruebas como andamiaje y el diagnóstico automático de los fallos de pipeline — la etapa CI/CD más madura y, ya hoy, el caso de uso más extendido. Se amplía solo donde las pruebas y la revisión ya aguantan: las rutas sensibles siguen excluidas, no se fuerzan dentro del agente. La escritura automática de la configuración de pipeline no entra aquí: todavía no es una categoría de producto, y es una superficie de ataque documentada.

  3. 3

    Ongoing

    En régimen

    Monitorización continua sobre un número medido, no percibido — y sobre la deuda: churn, duplicación, porcentaje de código refactorizado. La disciplina es el multiplicador: la IA amplifica lo que ya tiene, así que el control no es la herramienta, es el cerco que la rodea. El playbook se actualiza en cada cambio de stack o de política, no se archiva.

04 · Governance

El overlay de conformidad, y quién lo gobierna

El código generado trae preguntas de propiedad y de secretos

Es el control más específico de este departamento, y no existía antes de la IA. Dos preguntas, las dos abiertas: de quién es el código que ha generado el asistente, y qué exposición crea el material con el que se ha entrenado; y dónde acaban sus fuentes — un asistente que manda código propietario a un modelo de terceros es un canal de fuga de secretos, distinto de las preguntas de privacidad del resto del playbook. La lectura del EU AI Act para las herramientas de desarrollo lleva con toda probabilidad a un perfil generalista de riesgo mínimo, no de alto riesgo: pero hay que verificarla proveedor por proveedor antes de recomendarla a un cliente, no darla por supuesta.

La disciplina de revisión no se delega

El código generado no es seguro por defecto. Una investigación académica ya clásica encontró vulnerabilidades en alrededor del 40% de los programas generados por un asistente sobre 89 escenarios; una investigación de 2026 midió que el código C++ generado por IA tiene alrededor del doble de probabilidad de producir una violación en tiempo de ejecución que el humano — y que el análisis estático por sí solo hace parecer a ambos igual de seguros, lo cual es engañoso. En el frente de las pipelines, un estudio de 2026 sobre más de 13.000 workflows «agénticos» encontró cientos de vulnerabilidades de inyección confirmadas, muchas de ellas zero-day. Por eso el punto de control humano antes del merge no es burocracia: es el control que importa, igual que lo es el anclaje a las fuentes en soporte.

Overlay de conformidad

Los repositorios contienen secretos, credenciales y a veces datos personales dentro de pruebas y fixtures: activa las mismas preguntas RGPD que el resto del playbook, más las propias de este departamento. Qué sale del perímetro hacia un modelo de terceros, minimización de lo que se le pasa al modelo, conservación de los prompts y de los logs, licencia y procedencia del código generado. La due diligence sobre el proveedor y sobre sus términos de tratamiento del código es parte no negociable de la elección de software.

El AI owner

Nada de Center-of-Excellence de gran empresa: bastan una o dos personas nombradas como AI owner. Se quedan con cinco responsabilidades — las prioridades, quién aprueba qué (qué rutas no toca nunca el agente, en primer lugar), la capacitación del equipo, los estándares reutilizables y la monitorización sobre números medidos. Es el owner quien mantiene vivo el punto de control: cuando la disciplina de pruebas y de revisión se deshilacha, la IA acelera la deuda en lugar de prevenirla. No lo decimos desde fuera: este punto de control es el mismo que mantenemos cerrado sobre nuestros productos, cada día.

Este es el ejemplo. Injertamos el suyo.

Los demás departamentos siguen el mismo esquema. Empiece por la evaluación gratuita para entender por dónde conviene empezar, o hablémoslo directamente.

Ejemplo con fines orientativos: no constituye asesoramiento legal, fiscal ni evaluación de conformidad.

Utilizamos cookies

Utilizamos cookies y tecnologías similares para mejorar su experiencia, analizar el tráfico y personalizar los contenidos. Puede aceptar todas las cookies o personalizar sus preferencias.

Preferencias de cookies

Cookies necesarias Siempre activas

Esenciales para el funcionamiento del sitio. No se pueden desactivar.

Nos ayudan a entender cómo utiliza el sitio para mejorar la experiencia.

Se utilizan para mostrarle anuncios relevantes y medir las campañas.

Permiten personalizar contenidos y funcionalidades.